Coût des API de génération d'images : 5 modèles ($0.006–$0.039)

Nous avons ajouté la génération d’images à une gateway conçue pour les LLM textuels, puis mesuré l’impact de quatre variables sur le coût : le modèle, la résolution, le nombre d’images et la qualité. Le principal levier est la qualité, un paramètre proposé par la plupart des API d’images, mais que la majorité des clients laissent à sa valeur par défaut. La résolution, le prompt caching et le batching comptent bien moins qu’on ne le pense.

TL;DR

• Sur gpt-image, le paramètre quality fait varier la facture d’environ 36x à résolution identique : 196 / 1,756 / 7,024 output tokens facturés ($0.0060 / $0.053 / $0.211) en low/medium/high à 1024x1024.
• Le choix du modèle fait varier le coût d’un facteur 6.4x : $0.0060 par image avec gpt-image-2 en low, contre $0.0387 avec gemini-2.5-flash-image.
• La résolution a peu d’impact : passer de 1024x1024 à 2048x2048 n’a fait que doubler le coût par image de gpt-image-2.
• La génération d’images ne prend pas en charge le prompt caching, et n=4 refacture le prompt quatre fois. La facturation au token est plus avantageuse sous environ 1,000 output tokens, tandis que le forfait par image l’emporte au-delà.

Les différences entre les modèles d’images

Les modèles d’images ne sont pas interchangeables. Ils diffèrent sur plusieurs axes, et un seul d’entre eux, le mode de facturation, concerne directement le prix. Voici un aperçu du catalogue actif :

Voici les points qui posent problème si vous supposez que tous les modèles fonctionnent de la même façon :

• Mode de facturation. Au token (gpt-image, gemini) ou au forfait par image (qwen, wan, seedream). C’est ce qui détermine la facture, et le sujet de la section suivante.
• Le paramètre quality. Seul gpt-image le propose (low/medium/high). Avec Gemini, le niveau de fidélité dépend du tier du modèle (flash à pro) ou de image_size. Les modèles au forfait n’ont pas de réglage équivalent. Comme ce seul paramètre fait varier la facture d’environ 36×, il constitue le principal levier de coût, détaillé plus bas.
• Le batch (n>1) n’est pas disponible partout. gpt-image, qwen et wan peuvent renvoyer plusieurs images par appel. Tous les modèles d’images Gemini et Seedream sont limités à une image par appel : n=2 renvoie une erreur 400. Il faut donc envoyer N requêtes et orchestrer le batch soi-même.
• Les limites de résolution jouent dans les deux sens. gemini-2.5-flash-image est limité à 1K (1 MP), tandis que gemini-3 monte jusqu’à 2K/4K, avec une facture qui double approximativement entre 1K et 4K. Seedream 4.5/5.0 impose un minimum d’environ 1920² et refuse les résolutions inférieures. qwen-image accepte une plage de 512² à 2048². Une résolution supérieure n’est pas toujours disponible, et il n’est pas toujours possible de réduire la résolution pour économiser.
• Les paramètres de contrôle et l’image-to-image varient. Seuls certains modèles acceptent seed, negative_prompt ou guidance_scale. Pour l’édition, le nombre maximal d’images de référence va de 3 (gemini-2.5) à 16 (gpt-image).

Le paramètre quality présente une particularité peu intuitive. Avec gpt-image, un output token est une unité de facturation, pas une mesure du fichier obtenu. OpenAI définit ce nombre dans une grille tarifaire publique par combinaison (quality × size) : 272 / 1,056 / 4,160 tokens en low / medium / high à 1024² sur gpt-image-1. Le nombre dépend donc de quality, pas du volume de données renvoyé. Nous l’avons vérifié : à prompt et résolution 1024² identiques, les trois niveaux ont produit des PNG de 1024×1024 d’une taille comparable, autour de 0.9 MB, tout en facturant 196, 1,756 et 7,024 tokens. Même résolution, même taille de fichier, coût multiplié par 36. Vous payez l’effort de rendu, pas les pixels. Il faut donc lire usage au lieu d’estimer le coût à partir du résultat.

Aucun de ces modèles ne prend en charge le prompt caching, pourtant souvent envisagé en premier pour réduire les coûts. La génération d’images est stateless : il n’y a ni conversation ni état KV à réutiliser, l’objet usage ne contient aucun champ de cache et, comme nous le mesurons plus bas, le batching ne mutualise pas non plus le prompt. Le caching est une fonctionnalité de chat, pas de génération d’images. L’une des stratégies couramment envisagées pour réduire le coût des images ne s’applique donc pas ici.

Nos mesures

Nous avons utilisé le même prompt e-commerce de type photo produit et effectué de vraies générations via la gateway. Le coût est calculé à partir de la réponse usage et des tarifs publics de chaque modèle. Voici cinq constats, chacun issu d’une série de mesures distincte.

1. Le coût vient de l’image, pas du prompt. En text-to-image, avec un prompt en entrée et une image en sortie, 97–100 % de la facture provient des output tokens : une génération 1024² avec gpt-image-2 consomme 21 input tokens et 196 output tokens, soit environ $0.0001 plus $0.0059. gemini-2.5-flash-image consomme 10 input tokens. Le coût du prompt textuel est négligeable. En revanche, une image en entrée, comme pour demander « rendre cette tasse bleue » en image-to-image, produit beaucoup d’input tokens :

L’entrée augmente d’un facteur 50–130×, de façon linéaire : chaque référence supplémentaire ajoute environ 1,025 tokens avec gpt-image-2. Pour 1, 2 et 3 références, nous avons mesuré respectivement 1,043, 2,068 et 3,093 tokens. En low, ces input tokens sont cinq fois plus nombreux que les output tokens générés. Le principe reste le même : c’est l’image qui coûte, qu’elle soit générée ou fournie, jamais le prompt. La suite de l’article se concentre sur le text-to-image. L’économie propre à l’image-to-image fera l’objet d’un autre article.

2. Le choix du modèle fait varier le coût d’un facteur 6×. Même requête en 1024², qualité par défaut :

L’écart entre le chemin le moins cher et le plus cher atteint 6.4×. Il s’explique uniquement par le nombre d’output tokens produits par chaque modèle.

3. La résolution change peu la facture. En faisant varier gpt-image-2 de 1024² à 2048², le coût par image est resté relativement stable, de $0.0060 à $0.0121. Le nombre d’output tokens n’est pas proportionnel au nombre de pixels. gemini-2.5-flash-image a renvoyé les mêmes 1,290 tokens quelle que soit la taille demandée, car ce modèle est limité à 1K et size ne modifie que le ratio d’aspect. Les modèles d’images gemini-3 respectent bien image_size, avec un coût qui double approximativement de 1K à 4K. Ce n’est pas le cas de 2.5-flash-image, le modèle analysé ici. Par définition, la résolution n’affecte pas les modèles facturés au forfait par image. À ce stade, la facturation au token semble difficile à battre.

4. La qualité détermine le point de bascule. Voici les résultats de gpt-image-2 selon le niveau de qualité :

Les output tokens sont multipliés par environ 9× entre low et medium, et par environ 36× entre low et high. En low, le modèle facturé au token est le moins cher. En medium ou high, il devient plus coûteux que le forfait par image ($0.03–0.035). Le calcul place le point de bascule autour de 1,000 output tokens ($0.03 ÷ $30/M) : low est en dessous, medium au-dessus. Cela corrige aussi l’une de nos conclusions précédentes. Si nous pensions que « la facturation au token est toujours la moins chère », c’est parce que nos tests utilisaient la qualité low par défaut.

Même prompt, gpt-image-2, 1024². Les niveaux low / medium / high facturent 196 / 1,756 / 7,024 output tokens, soit $0.006 / $0.053 / $0.215 : un écart de 36× à résolution identique. Pour une photo produit simple comme celle-ci, les trois résultats sont difficiles à distinguer. Le niveau le moins cher suffit donc souvent. Adaptez quality au besoin au lieu de choisir high par défaut.

5. Un prompt ne peut pas être mutualisé entre plusieurs images. Générer n images en un seul appel ne répartit pas le coût du prompt. gpt-image-2 le facture N fois : les input tokens sont passés de 28 à 112 avec n=4, et un long prompt de marque est passé de 499 à 1,996. Le coût par image était identique pour n=1 et n=4. Sans caching, il n’existe aucun mécanisme permettant de mutualiser le coût du prompt pour la génération d’images. Chaque image produite est facturée séparément, avec le prompt à chaque fois.

La règle de décision

Pour le text-to-image, le critère décisif est la qualité, pas les paramètres auxquels on pense spontanément :

• Qualité low / brouillon / miniature : choisissez un modèle au token avec réglage de qualité (gpt-image, environ $0.006–0.012). C’est l’option la moins chère, quelle que soit la résolution jusqu’à environ 2K.
• Qualité medium / high : choisissez un forfait par requête (seedream / qwen, $0.03–0.035). La facture au token s’envole, de $0.05–0.43 dans nos mesures. Le forfait est moins cher et ne dépend pas de la qualité.
• gemini (environ $0.039 en 1K par défaut) est rarement le meilleur choix côté coût. gpt-image est moins cher en low, tout comme les modèles au forfait en medium et high. gemini n’a pas de réglage quality : son tier Pro ou une valeur image_size supérieure se choisissent pour la qualité du résultat, pas pour le prix.
• La résolution fait varier le coût d’environ 2× au sein d’un même niveau de qualité, ce qui ne suffit pas à modifier le choix. La qualité, elle, le modifie.
• n>1, le caching et le batching ne réduisent jamais le coût par image. Rien n’est mutualisé.
• Image-to-image : privilégiez par défaut le forfait par image. Une image de référence est comptée en entrée, et seuls les modèles facturés au token la surfacturent, à raison d’environ 1,025 tokens chacune. Les modèles au forfait l’incluent sans supplément. Pour l’édition, seedream / qwen sont généralement plus avantageux. gpt-image reste moins cher uniquement pour des éditions en low avec peu de références, autour de 5 avant de dépasser le forfait. Il perd cet avantage dès que la qualité ou le nombre de références augmente.

L’e-commerce en offre l’exemple le plus clair. Imaginons que vous génériez des photos produit en envoyant le même long prompt de marque pour chaque article du catalogue, en supposant que le caching de ce prompt répétitif réduira la facture. Cette stratégie échoue pour deux raisons : le coût n’a jamais été le prompt, mais l’image, et la génération ne prend de toute façon pas en charge le caching. Comme les visuels produit réels exigent généralement une qualité medium ou supérieure, le bon choix est un modèle au forfait par image. Il est à la fois moins cher et plus prévisible, quel que soit le degré de répétition des prompts.

Les contraintes fonctionnelles présentées au début peuvent néanmoins dicter un autre choix : modèles limités à une image par appel, résolutions minimales et maximales, exigences de résidence des données et paramètres exposés (seed, negative_prompt, guidance_scale). Choisissez d’abord selon le coût, puis vérifiez que les capacités répondent au besoin.

Pourquoi ces chiffres sont fiables

Ces chiffres proviennent de réponses usage réelles, calculées selon les tarifs publics de chaque fournisseur, et non d’estimations. La facturation des images sur notre gateway est sans session : elle n’est finalisée que sur une réponse 2xx, une génération échouée n’est jamais facturée, et le coût maximal est vérifié avant toute dépense. Si une réponse ne contient pas usage, elle est facturée au plafond plutôt qu’à $0 sans avertissement. Nous appliquons partout le même principe : fiez-vous au coût vérifié, pas au chiffre fourni par le vendeur. C’est aussi la méthode utilisée pour vérifier si une gateway ment sur le cache.

Conclusion

La génération d’images ressemble à un endpoint comme un autre, mais l’unité de facturation change. En text-to-image, le principal levier n’est ni le prompt, puisqu’il n’y a ni caching ni mutualisation par batch, ni la résolution. C’est la qualité : gpt-image est le moins cher en low, tandis que les modèles au forfait par image (seedream / qwen) l’emportent en medium et high. Le point de bascule se situe autour de 1,000 output tokens. Réglez volontairement la qualité, choisissez le modèle en conséquence et vérifiez le coût. En passant de la génération à l’édition avec une image de référence, refaites le calcul : l’image en entrée devient alors le principal coût.

FAQ

Le prompt caching réduit-il le coût de la génération d’images ? Non. La génération est stateless : l’objet usage ne contient aucun champ de cache, et le batching refacture le prompt pour chaque image. Le coût vient de l’image générée, pas du texte.

Facturation au token ou par image : laquelle est la moins chère ? Cela dépend de la qualité. Pour une qualité low ou brouillon, choisissez un modèle avec réglage quality comme gpt-image, à environ $0.006–0.012. En medium ou high, préférez un forfait par image comme seedream/qwen, à $0.03–0.035, car la facture au token s’envole. En image-to-image, l’avantage penche encore davantage vers le forfait : les images de référence sont incluses sans supplément, tandis que les modèles au token facturent environ 1,025 tokens supplémentaires par référence.

Sources

• OpenAI : API de génération d’images
• OpenAI : tarification au token de gpt-image
• Google : tarification de l’API Gemini pour les output tokens d’images
• OpenAI : prompt caching et raisons pour lesquelles il ne s’applique pas à la génération d’images

Toutes les informations ont été vérifiées le 2026-06-19. Ceci ne constitue pas un conseil financier ; vérifiez les tarifs en vigueur avant de vous y fier.

← Retour au blog