Une nouvelle fonctionnalité média commence rarement avec une file d'attente GPU régulière. Elle commence par quelques portraits, retouches de produits ou courtes vidéos, puis vient la question : l'application doit-elle continuer à payer une API ou exécuter un modèle elle-même ?
Utilisez une API média hébergée si la demande est irrégulière, si vous avez besoin de plusieurs familles de modèles ou si la fonctionnalité cherche encore ses utilisateurs. Envisagez l'auto-hébergement lorsqu'un pipeline à poids ouverts compatible répond à la tâche et qu'un usage soutenu couvre son coût d'exploitation complet. Un hybride est souvent pratique : faites tourner en local la génération d'images fixes régulière et gardez les vidéos occasionnelles sur une tâche hébergée.
Pour une facture de départ concrète, Z-Image Turbo coûte $0.010 par image avec l'expansion du prompt désactivée, et cinq secondes d'image vers vidéo avec MiniMax H3 en 768p coûtent $0.185. La comparaison utile part de ces livrables terminés, pas du tarif horaire affiché d'un GPU.
Comparez d'abord le même livrable
Une nouvelle image à partir de texte, la retouche d'un portrait existant et une vidéo à partir d'une image validée sont des capacités différentes. Un tarif GPU à l'heure bas ne fait pas d'un seul modèle le remplaçant des trois.
| Besoin | Exemple hébergé actuel | Coût client affiché | Ce qu'une alternative locale doit faire |
|---|---|---|---|
| Nouvelle image à partir de texte | Z-Image Turbo | $0.010/image, expansion désactivée | Exécuter un checkpoint texte vers image adapté à la taille requise |
| Retouche à partir de références | Qwen Image 2.1 edit | Une référence : 1K $0.036 ; 2K $0.048 (expansion désactivée) ; 1.5K $0.072 (expansion activée) | Accepter les images sources et préserver les détails que la révision exige |
| Animer une image d'ouverture | H3 image-to-video | $0.037/seconde en 768p ; $0.058 en 2K | Exécuter un pipeline vidéo compatible, pas seulement un modèle d'image |
La deuxième référence de Qwen porte une retouche 1K à $0.048 ; une retouche 2K était toujours facturée $0.048 avec une ou deux références. La retouche 1.5K exige actuellement l'expansion du prompt activée : $0.072 avec une référence, $0.09 avec deux.
Une fonctionnalité qui promet le même personnage fictif dans plusieurs scènes demande plus qu'un modèle texte vers image bon marché. Il faut un moyen de transporter l'identité d'une image à l'autre. Télécharger un checkpoint texte vers image n'ajoute ni retouche par référence ni conditionnement du personnage. Choisissez le contrôle avant de choisir où l'exécuter.
Ce qu'apporte la voie hébergée
Pour Z-Image, la tâche accepte un prompt jusqu'à 1 000 caractères, cinq rapports d'aspect, une sortie PNG et un seed facultatif. C'est une opération texte vers image étroite, pas une interface pour remplacer le sampler ou manipuler des latents intermédiaires.
H3 image-to-video accepte une image d'ouverture et un prompt, plus une image de fin facultative. Elle prend en charge 4 à 15 secondes en 768p ou 2K ; les clips de quatre secondes sont limités à la 768p. L'image d'ouverture fixe le format de sortie. La tâche n'expose ni seed ni champ de caméra verrouillée : préparez la composition avant l'animation et décrivez dans le prompt le comportement de caméra souhaité.
L'API de tâches gère le devis, la création asynchrone et la consultation du statut. Votre application doit toujours contrôler les envois en double et conserver les fichiers livrés, mais elle n'a pas à charger de poids de modèle, à relancer des workers GPU ni à maintenir un environnement de service.
Un petit budget image et vidéo
Dix essais Z-Image et deux clips H3 de cinq secondes donnent un exemple de départ utile :
- Dix images fixes : 10 × $0.010 = $0.100.
- Deux clips en 768p : 2 × 5 × $0.037 = $0.370.
- Génération totale : $0.470.
Budgétez séparément les retouches et les essais écartés par rapport aux livrables retenus.
Ce que l'auto-hébergement apporte, et ce qu'il ajoute
Le dépôt officiel de Z-Image fournit le code, les poids et les instructions d'inférence locale. Z-Image est une famille de 6B, et le README officiel indique que Turbo tient sur des appareils grand public avec 16 GB de VRAM. C'est un candidat plausible pour la génération locale d'images fixes, pas une raison de supposer que chaque résolution et chaque lot demandés tiendront sur votre GPU.
L'auto-hébergement vous permet de choisir un runtime compatible, d'ajouter des adaptateurs ou un prétraitement pris en charge, et de placer l'inférence dans une infrastructure que vous exploitez. Il vous rend aussi responsable de :
- Chargement du modèle et mémoire : les poids, les dimensions et les tâches simultanées déterminent si le worker tient.
- Capacité : une image unique rapide ne dit rien de la manière dont une rafale de requêtes fera la queue.
- Reprise : une erreur de mémoire insuffisante ou un plantage de worker demande une nouvelle tentative bornée et un remplaçant sain.
- Mises à jour : les changements de modèle, de dépendances et de runtime peuvent modifier le résultat ou casser le service.
Si vous avez besoin d'un graphe d'inférence personnalisé ou d'un adaptateur privé que la tâche hébergée n'offre pas, ce contrôle peut justifier l'auto-hébergement avant toute économie. Si la tâche est déjà prise en charge et utilisée seulement de temps à autre, le même contrôle peut ajouter du travail sans améliorer la fonctionnalité pour le client.
L'auto-hébergement ne signifie pas toujours un GPU inactif allumé toute la journée
Un handler autogéré peut tourner sur une instance dédiée ou sur des workers serverless. Runpod distingue les workers actifs des workers flex : les workers actifs restent prêts ; les workers flex peuvent descendre à zéro, avec des démarrages à froid quand la demande revient.
Comparez ces modes d'exploitation séparément. Une réservation permanente inclut de la capacité inactive ; un dispositif qui descend à zéro échange ce coût d'inactivité contre un délai de démarrage et une configuration de déploiement. Les deux exigent toujours un handler de modèle et une file d'attente qui sache si le worker a terminé la tâche.
Pour un travail de personnages sans censure, choisissez le contrôle avant l'hébergeur
Un personnage adulte récurrent est un bon exemple, car le premier portrait bon marché n'est qu'un début. Les scènes suivantes peuvent exiger le même visage, un changement de tenue ou une pose précise. Répéter une description textuelle peut produire de nouvelles variations alors que le produit a besoin de continuité.
La tâche Z-Image hébergée à $0.010 est uniquement textuelle : elle ne peut pas accepter le portrait d'une compagne comme référence d'identité, et une image bon marché d'une autre personne ne remplace pas un workflow de retouche par référence. Il en va de même en local : charger des poids ouverts n'ajoute ni conditionnement du visage, ni LoRA de personnage compatible, ni pipeline de retouche ; identifiez donc d'abord précisément le contrôle manquant. Si vous avez besoin d'un adaptateur de personnage entraîné, vérifiez que le checkpoint et l'adaptateur correspondent et que votre implémentation le charge.
Une chaîne hébergée peut rendre les contrôles et le coût explicites :
- Explorer un portrait : Z-Image Turbo à $0.010 par image, expansion désactivée.
- Le porter dans une scène voisine : Qwen Image 2.1 edit prend le portrait validé comme référence ; les retouches à une référence coûtent $0.036 en 1K ou $0.048 en 2K, expansion désactivée.
- Animer l'image validée : H3 image-to-video démarre à $0.037 par seconde en 768p.
En local, la même chaîne exige un pipeline texte vers image, une retouche par référence ou un conditionnement d'identité, et un pipeline vidéo distinct. Une tâche hébergée sans restriction supprime un filtre de plateforme supplémentaire ; elle ne garantit pas qu'un modèle préserve chaque visage ou chaque tenue. Exécuter des poids ouverts en local vous donne la maîtrise du pipeline d'inférence et vous rend responsable de sa gestion des contenus et de son déploiement. Pour du contenu destiné aux adultes, gardez trois questions séparées : la tâche choisie accepte-t-elle la demande, le modèle produit-il la catégorie voulue, et le résultat est-il exploitable. Une réponse d'achèvement peut accompagner une scène adoucie ou une identité modifiée, et l'exécution en local ne prouve pas que le checkpoint restitue bien la scène voulue. Vérifiez les conditions du modèle et du service pour votre déploiement réel et utilisez des sources autorisées d'adultes fictifs ; « poids ouverts » n'est pas une étiquette d'autorisation universelle.
Un hybride peut garder les images fixes de personnage à gros volume sur un pipeline local compatible, tout en envoyant l'image retenue à un modèle vidéo hébergé. Cela évite d'acheter de la capacité vidéo pour des clips occasionnels tout en conservant les contrôles locaux utilisés pour créer le personnage. Séparez les coûts image et vidéo pour qu'une image fixe bon marché ne masque pas l'étape suivante, plus chère. Évaluez séparément le comportement de la tâche vidéo face au contenu : que votre pipeline d'image accepte une image ne prouve pas que le modèle vidéo l'animera comme prévu.
Calculez le coût par résultat retenu
Pour le travail hébergé, divisez la facture de tous les essais de génération par les livrables que le projet peut réellement utiliser. Si douze essais d'image à $0.010 donnent huit portraits retenus, le coût de génération par portrait retenu est de $0.015. C'est un exemple chiffré, pas un taux d'acceptation mesuré.
Pour l'inférence locale :
local cost per accepted image =
(booked GPU hours × actual hourly rate + storage + transfer + allocated operations)
÷ accepted imagesUtilisez le temps de ressource payé, y compris le démarrage et l'inactivité lorsque le mode de facturation les facture. Supposons qu'une réservation de GPU soit cotée $1.20/heure :
| Images retenues dans l'heure | Coût de calcul par image retenue | Ce que le chiffre exclut |
|---|---|---|
| 80 | $1.20 ÷ 80 = $0.015 | Stockage, transfert et exploitation |
| 20 | $1.20 ÷ 20 = $0.060 | Les mêmes coûts supplémentaires |
Le tarif et les volumes sont des hypothèses. Le calcul montre comment le taux d'utilisation change le résultat : un GPU qui semble bon marché à l'heure peut coûter cher par livrable utilisable quand l'essentiel de l'heure est inactif ou consacré à des essais écartés.
Un exemple mensuel de seuil de rentabilité
Avec le même coût hébergé de $0.015 par image retenue et l'hypothèse de $1.20 par heure de GPU :
$1.20 ÷ $0.015 = 80 images retenues par heure de GPU payée.
En dessous de 80, l'hébergé est moins cher en coût de génération. Au-dessus de 80, le calcul local devient moins cher avant stockage, transfert et exploitation. Comptez les images retenues, pas chaque rendu tenté.
Une réservation mensuelle de 720 heures demande 57 600 images retenues pour égaler cette facture de génération hébergée avant ces coûts supplémentaires. Un worker qui descend à zéro s'évalue sur ses heures payées, y compris le démarrage et l'inactivité facturés, et non sur le mois entier. Ajoutez les coûts d'exploitation au numérateur avant de considérer l'un ou l'autre seuil comme un seuil de rentabilité pour l'entreprise.
Ne comptez que les coûts qui diffèrent entre les options. Une base de données applicative nécessaire aux deux ne devient pas un coût propre à l'auto-hébergement. Le stockage de modèles supplémentaire, la supervision des workers ou du temps de personnel en plus, si.
Alignez la comparaison sur le travail du client
Pour une fonctionnalité de portraits 9:16, gardez le même cadrage exigé et la même taille de livraison. Une image retenue peut devoir montrer le manteau bleu marine demandé, un visage lisible, les deux mains dans le cadre et aucun texte indésirable. Si la voie locale passe par une retouche par référence ou une reprise manuelle, comptez ce travail supplémentaire.
Les mesures les plus instructives sont :
- Nombre d'images retenues : combien de fichiers livrés répondent à l'exigence du produit.
- Attente complète : le temps entre l'envoi de la demande par le client et l'arrivée du fichier utilisable.
- Temps de ressource payé : ce que facture le fournisseur, et pas seulement la dernière passe d'inférence.
- Comportement en rafale : ce qui se passe quand dix clients envoient leur demande en même temps.
Séparez les exécutions à chaud des démarrages à froid. Un benchmark qui commence avec les poids chargés ne représente pas une fonctionnalité qui démarre un worker neuf après chaque période calme. Comparez aussi une qualité de livraison équivalente : un aperçu à peu d'étapes et une image finie sont deux produits différents, même si leurs dimensions coïncident.
Pour une application à personnage récurrent, incluez chaque retouche de scène dans la charge de travail au lieu de ne compter que le premier portrait. Si une scène demandée exige une première retouche puis une correction, cela fait deux essais d'image. Les essais vidéo sont une autre ligne de coût. Sur votre propre GPU, ces opérations consomment plus de temps d'exécution payé ; sur une tâche hébergée, elles génèrent des frais de requête supplémentaires. Un tableur qui valorise chaque photo client comme une seule génération sous-estime les deux côtés quand votre workflow réel enchaîne plusieurs passes.
Séparez l'avantage de coût de l'avantage produit. Un pipeline local peut coûter un peu plus cher et offrir un contrôle dont vos utilisateurs ont besoin. Un pipeline hébergé peut coûter un peu plus cher et faire gagner assez de temps d'exploitation pour lancer la fonctionnalité plus tôt. Aucun de ces compromis n'a besoin d'être déguisé en seuil de rentabilité universel.
La vidéo demande son propre calcul. Le débit en images ne permet pas de prévoir la vitesse à laquelle un pipeline vidéo livrera cinq secondes de mouvement et de son. Évaluez le pipeline vidéo séparément : son temps GPU payé et ses besoins en mémoire ne se déduisent pas du débit en images.
Questions fréquentes
L'auto-hébergement est-il moins cher qu'une API d'images ?
Il peut l'être avec une utilisation soutenue. Comparez le coût des fichiers retenus, y compris les essais écartés, l'inactivité payée et l'exploitation. Un tarif horaire de GPU bas ne suffit pas à établir une économie.
Un modèle Z-Image local peut-il remplacer un éditeur d'images ?
Le modèle texte vers image crée de nouvelles images à partir de mots. Préserver un portrait téléversé ou modifier une zone définie exige un pipeline de retouche ou de conditionnement qui prend en charge cette opération. Choisissez ce pipeline séparément.
L'auto-hébergement m'oblige-t-il à acheter un GPU ?
Non. Vous pouvez louer un GPU dédié ou déployer un handler autogéré sur des workers GPU serverless. Les modes dédié et à descente à zéro n'offrent pas les mêmes compromis entre coût d'inactivité et délai de démarrage.
Puis-je héberger les images en local et utiliser une API pour la vidéo ?
Oui. C'est un arrangement pratique quand les images fixes sont fréquentes et la vidéo occasionnelle. Enregistrez l'image validée, envoyez-la au mode vidéo choisi et budgétez séparément les étapes image et vidéo.
