Coste de API de generación de imágenes: 5 modelos ($0.006–$0.039)
Contenido
Añadimos generación de imágenes a un gateway diseñado para LLM de texto y medimos cómo afectan al coste cuatro variables: modelo, resolución, número de imágenes y calidad. La que más influye es la calidad, un parámetro que ofrecen casi todas las API de imágenes y que la mayoría de los clientes deja con su valor predeterminado. La resolución, el prompt caching y el batching importan mucho menos de lo que suele pensarse.
TL;DR
- El ajuste
qualityde gpt-image multiplica la factura por unas 36 veces con la misma resolución: 196 / 1,756 / 7,024 tokens de salida facturados ($0.0060 / $0.053 / $0.211) para low/medium/high a 1024x1024. - Elegir el modelo puede multiplicar el coste por 6.4: $0.0060 por imagen con gpt-image-2 en calidad low, frente a $0.0387 con gemini-2.5-flash-image.
- La resolución apenas influye: pasar de 1024x1024 a 2048x2048 solo duplicó el coste por imagen de gpt-image-2.
- La generación de imágenes no admite prompt caching, y
n=4vuelve a facturar el prompt cuatro veces; la facturación por token sale mejor por debajo de unos 1,000 tokens de salida, mientras que la tarifa fija por imagen gana por encima.
En qué se diferencian los modelos de generación de imágenes
Los modelos de generación de imágenes no son intercambiables. Se diferencian en varios aspectos, y solo uno de ellos, el esquema de facturación, tiene que ver con el precio. Este es el catálogo activo de un vistazo:
| Familia | Facturación | Ajuste quality | Lotes n>1 | Resolución |
|---|---|---|---|---|
gpt-image (OpenAI) | por token | ✓ low/med/high | ✓ | hasta ≈2K |
gemini-image (Google) | por token | ✗ | ✗ 1/llamada | 1K (gemini-3: hasta 4K) |
qwen-image / wan2.7 (Alibaba) | tarifa fija/imagen | ✗ | ✓ | 512²–2048² |
seedream (BytePlus) | tarifa fija/imagen | ✗ | ✗ 1/llamada | ≥1920² (4.5/5.0) |
Estas son las diferencias que causan problemas si se presupone que todos los modelos funcionan igual:
- Esquema de facturación. Por token (
gpt-image,gemini) o con una tarifa fija por imagen (qwen,wan,seedream). Es el factor que determina la factura y el tema de la siguiente sección. - El ajuste
quality. Sologpt-imagelo ofrece (low/medium/high). Gemini cambia la fidelidad mediante el nivel del modelo (flashapro) oimage_size; los modelos con tarifa fija no tienen un control equivalente. Este único ajuste multiplica la factura por unas 36×, así que es el principal factor de coste y lo analizamos más adelante. - Los lotes (
n>1) no son universales.gpt-image,qwenywandevuelven varias imágenes por llamada. Todos los modelos de imágenes de Gemini y Seedream devuelven una sola imagen por llamada:n=2responde con un400, por lo que hay que enviar N solicitudes y orquestar el lote por cuenta propia. - Los límites de resolución restringen en ambos sentidos.
gemini-2.5-flash-imageestá limitado a 1K (1 MP), mientras quegemini-3llega a 2K/4K (y su factura aproximadamente se duplica entre 1K y 4K). Seedream 4.5/5.0 exige un mínimo de unos 1920² y rechaza resoluciones inferiores.qwen-imageadmite entre 512² y 2048². Una resolución más alta no siempre está disponible, y tampoco siempre se permite reducirla para ahorrar. - Los controles y las capacidades de imagen a imagen varían. Solo algunos modelos admiten
seed,negative_promptoguidance_scale, y el límite de imágenes de referencia para edición va de 3 (gemini-2.5) a 16 (gpt-image).
El ajuste quality tiene una particularidad poco evidente. En gpt-image, un token de salida es una unidad de facturación, no una medida del archivo recibido. OpenAI asigna el recuento mediante una tabla pública de tarifas por combinación de (quality × size) (272 / 1,056 / 4,160 tokens para low / medium / high a 1024² en gpt-image-1), por lo que el recuento depende de quality y no de los bytes devueltos. Lo comprobamos: el mismo prompt a 1024² en los tres niveles produjo archivos PNG idénticos de 1024×1024 y aproximadamente el mismo tamaño (unos 0.9 MB), pero facturó 196, 1,756 y 7,024 tokens. Misma resolución, mismo tamaño en bytes y un coste 36× mayor. Se paga por el trabajo de renderizado, no por los píxeles. Por eso hay que consultar usage en lugar de estimar el coste a partir del resultado.
Ninguno de estos modelos admite prompt caching, aunque suele ser la primera opción que se plantea para reducir costes. La generación de imágenes no mantiene estado: no hay ninguna conversación ni estado KV que reutilizar, el objeto usage no incluye campos de caché y, como medimos más adelante, los lotes tampoco comparten el prompt. El caching es una función de chat, no de generación de imágenes. Por tanto, una de las suposiciones más habituales para reducir el coste no se aplica aquí.
Lo medimos
Usamos el mismo prompt de producto de comercio electrónico y generaciones reales a través del gateway. Calculamos el coste a partir del usage devuelto y las tarifas publicadas de cada modelo. Obtuvimos cinco conclusiones, cada una a partir de una prueba independiente.
1. El coste está en la imagen, no en el prompt. En texto a imagen (entra un prompt y sale una imagen), entre el 97% y el 100% de la factura corresponde a tokens de salida: una generación de 1024² con gpt-image-2 consume 21 tokens de entrada y 196 de salida (unos $0.0001 más $0.0059), mientras que gemini-2.5-flash-image consume 10 de entrada. El coste del prompt es prácticamente despreciable, pero solo porque es texto. Si en su lugar se envía una imagen (imagen a imagen, por ejemplo, «haz que esta taza sea azul»), la tokenización de la entrada crece mucho:
| Modelo | Entrada t2i | Entrada i2i (1 referencia) | Salida |
|---|---|---|---|
gpt-image-2 (low) | 21 tok | 1,043 tok | 196 tok |
gemini-2.5-flash-image | 10 tok | 1,297 tok | 1,290 tok |
La entrada aumenta entre 50 y 130×, y lo hace de forma lineal: cada referencia adicional añade unos 1,025 tokens en gpt-image-2 (medimos 1,043, 2,068 y 3,093 con 1, 2 y 3 referencias). En calidad low, esos tokens de entrada quintuplican los de la salida generada. El principio se mantiene en ambos casos: el coste está en la imagen, tanto si se genera como si se proporciona; nunca está en el prompt. El resto del artículo se centra en texto a imagen. La economía completa de imagen a imagen merece otro artículo.
2. Elegir el modelo puede multiplicar el coste por 6×. Misma solicitud a 1024² y con la calidad predeterminada:
| Modelo | Facturación | Coste / imagen |
|---|---|---|
gpt-image-2 | token · ajuste quality | $0.0060 |
gpt-image-1-mini | token · ajuste quality | $0.0085 |
seedream-4-0 | tarifa fija por solicitud | $0.030 |
qwen-image-2.0 | tarifa fija por solicitud | $0.035 |
gemini-2.5-flash-image | token · sin ajuste quality | $0.0387 |
La diferencia entre la opción más barata y la más cara es de 6.4× y se debe por completo al número de tokens de salida que emite cada modelo.
3. La resolución apenas influye. Al probar gpt-image-2 desde 1024² hasta 2048², el coste por imagen se mantuvo relativamente estable ($0.0060 a $0.0121); los tokens de salida no son proporcionales al número de píxeles. gemini-2.5-flash-image devolvió los mismos 1,290 tokens con cualquier tamaño solicitado, porque está limitado a 1K y size solo cambia la relación de aspecto. (Los niveles de imagen de gemini-3 sí respetan image_size y aproximadamente duplican el coste entre 1K y 4K, pero 2.5-flash-image, el modelo cuyo coste analizamos aquí, no lo hace). Por definición, la resolución no afecta a los modelos con tarifa fija por imagen. Hasta aquí, el modelo por token parece difícil de superar.
4. La calidad marca el punto de cruce. Probamos gpt-image-2 en todos los niveles de calidad:
| quality | 1024² | 2048² |
|---|---|---|
| low | $0.0060 (196 tok) | $0.0121 (397 tok) |
| medium | $0.053 (1,756 tok) | $0.107 (3,568 tok) |
| high | $0.211 (7,024 tok) | $0.428 (14,272 tok) |
Los tokens de salida aumentan unas 9× de low a medium y unas 36× de low a high. Con calidad low, el modelo por token es la opción más barata; con medium o high, supera el precio fijo por imagen ($0.03–0.035). El punto de cruce está donde indica el cálculo, en torno a 1,000 tokens de salida ($0.03 ÷ $30/M): low queda por debajo y medium, por encima. Esto también corrige una conclusión anterior. Afirmar que «la facturación por token siempre es más barata» fue consecuencia de haber probado solo la calidad low predeterminada.

Mismo prompt, gpt-image-2, 1024². low / medium / high facturan 196 / 1,756 / 7,024 tokens de salida, o $0.006 / $0.053 / $0.215: una diferencia de 36× con la misma resolución. En una foto de producto limpia como esta cuesta distinguir los tres resultados, por lo que el nivel más barato suele bastar. Conviene ajustar quality al caso de uso en lugar de usar high de forma predeterminada.
5. No se puede compartir un prompt entre imágenes. Generar n imágenes en una sola llamada no amortiza el prompt. gpt-image-2 lo factura N veces: los tokens de entrada pasaron de 28 a 112 con n=4, y un prompt largo de marca pasó de 499 a 1,996. El coste por imagen fue idéntico con n=1 y n=4. Como tampoco hay caching, la generación de imágenes no ofrece ningún mecanismo para compartir el coste del prompt. Se paga por cada imagen de salida y el prompt vuelve a facturarse en cada una.
Regla para elegir
En texto a imagen, la decisión depende de la calidad, no de los factores que suelen darse por importantes:
- Calidad low / borrador / miniatura: un modelo por tokens con ajuste de calidad (
gpt-image, unos $0.006–0.012). Es el más barato en cualquier resolución hasta unos 2K. - Calidad medium / high: tarifa fija por solicitud (
seedream/qwen, $0.03–0.035). La factura por tokens se dispara ($0.05–0.43 en nuestras pruebas), mientras que la tarifa fija es más barata y no depende de la calidad. gemini(unos $0.039 con 1K predeterminado) rara vez es la opción más económica.gpt-imagees más barato en calidad low, y los modelos con tarifa fija por solicitud lo son en medium y high. No tiene un ajustequality; para mejorar la calidad del resultado se elegiría el nivel Pro o unimage_sizemayor, no para reducir el precio.- La resolución cambia el coste unas 2× dentro de un mismo nivel de calidad, una diferencia insuficiente para cambiar la elección. La calidad sí la cambia.
n>1, el caching y el batching nunca reducen el coste por imagen. No hay nada que compartir.- Imagen a imagen: la opción predeterminada debería ser una tarifa fija por imagen. Una imagen de referencia cuenta como entrada y solo los modelos por token aplican un sobrecoste (unos 1,025 tokens por referencia); los modelos con tarifa fija la incluyen sin coste adicional. Para edición,
seedream/qwensuelen ser mejores.gpt-imagesolo sigue siendo más barato para ediciones de calidad low con pocas referencias (alrededor de 5 se alcanza el precio fijo) y deja de serlo al aumentar la calidad o el número de referencias.
El comercio electrónico es el ejemplo más claro. Supongamos que se generan fotos de producto enviando el mismo prompt largo de marca para cada artículo del catálogo y se espera ahorrar mediante caching. Eso falla por dos motivos: el coste nunca estuvo en el prompt, sino en la imagen, y la generación tampoco admite caching. Como las imágenes de producto reales requieren calidad medium o superior, lo adecuado es un modelo con tarifa fija por imagen. Es más barato y su coste resulta más predecible, independientemente de cuánto se repitan los prompts.
Las limitaciones descritas al principio pueden imponer otra elección: modelos de una imagen por llamada, resoluciones mínimas y máximas, restricciones de residencia de datos y controles disponibles (seed, negative_prompt, guidance_scale). Primero hay que elegir por coste y después confirmar que el modelo cumple los requisitos funcionales.
Por qué estas cifras son fiables
Estas cifras proceden del usage real y de las tarifas publicadas por cada proveedor, no de estimaciones. La facturación de imágenes en nuestro gateway no depende de sesiones: solo se liquida tras una respuesta 2xx (una generación fallida nunca se cobra), comprueba el coste máximo posible antes de incurrir en gasto y, si falta usage en la respuesta, factura el límite máximo en vez de registrar silenciosamente $0. Aplicamos siempre el mismo principio: confiar en el coste calculado, no en una cifra proporcionada por el proveedor. Es el método que usamos para auditar si un gateway falsea el uso de caché.
Conclusión
La generación de imágenes parece otro endpoint más, pero cambia la unidad de facturación. En texto a imagen, el factor decisivo no es el prompt (no hay caching ni reparto entre imágenes de un lote) ni la resolución. Es la calidad: gpt-image es la opción más barata en low, mientras que la tarifa fija por imagen (seedream / qwen) gana en medium y high, con un punto de cruce cercano a 1,000 tokens de salida. Hay que elegir la calidad de forma consciente, usar un modelo acorde y comprobar el coste. Al pasar de generación a edición y proporcionar una imagen de referencia, hay que repetir el cálculo, porque la imagen de entrada pasa a ser el coste principal.
Preguntas frecuentes
¿El prompt caching reduce el coste de la generación de imágenes?
No. La generación no mantiene estado: el objeto usage no incluye campos de caché y los lotes vuelven a facturar el prompt por cada imagen. El coste está en la imagen de salida, no en el texto.
¿Qué sale más barato, pagar por token o por imagen?
Depende de la calidad. Para calidad low o de borrador, conviene un modelo con ajuste quality como gpt-image (unos $0.006–0.012). Para medium o high, una tarifa fija por imagen como seedream/qwen ($0.03–0.035), porque el coste por token se dispara. En imagen a imagen, la tarifa fija es aún más ventajosa: incluye las imágenes de referencia sin coste adicional, mientras que los modelos por token cobran unos 1,025 tokens por cada una.
Fuentes
- OpenAI: API de generación de imágenes
- OpenAI: precios por token de gpt-image
- Google: precios de la API de Gemini (tokens de salida de imagen)
- OpenAI: prompt caching (por qué no se aplica a la generación de imágenes)
Todo comprobado el 2026-06-19. Esto no constituye asesoramiento financiero; comprueba los precios actuales antes de basarte en ellos.