La forma más sencilla de automatizar la generación de imágenes a escala sin gestionar varias API distintas es separar el flujo de trabajo del proveedor del modelo. Coloca cada solicitud de imagen en una única cola, enruta cada trabajo a un ID de modelo actual y envía solicitudes compatibles a través de una única clave de CometAPI y la URL base compatible con OpenAI https://api.cometapi.com/v1.
Este tutorial construye ese pipeline en Python. Acepta trabajos de producto, publicidad y contenido desde una cola en JSON Lines; elige un modelo; limita la concurrencia; reintenta fallos transitorios; almacena resultados basados en URL o base64; y registra el uso por trabajo y el costo estimado. El ejemplo mantiene esos elementos esenciales de producción en un bloque compacto para que puedas probar el flujo sin convertir el artículo en una referencia de código.
Cómo una API de imágenes unificada simplifica la generación por lotes
Al final, el flujo de trabajo se verá así:
jobs.jsonl → bounded worker pool → CometAPI /v1/images/generations → object storage → manifest.jsonl
La cola y la capa de almacenamiento siguen siendo tuyas. Cambiar de modelo de imagen modifica el valor de model, no el sistema de autenticación ni la ruta principal de solicitud. Esa es la ventaja práctica de una API de imágenes unificada: la elección del modelo se convierte en una decisión de enrutamiento dentro de un solo pipeline en lugar de una integración separada por proveedor.
¿Qué necesitas para automatizar la generación de imágenes?
Necesitas Python 3.10 o posterior, el paquete requests, una clave de CometAPI, una ubicación de salida con permisos de escritura y al menos un ID de modelo de imagen vigente.
Instala la única dependencia:
pip install requests
Configura tu clave en el servidor, nunca en código del navegador ni en un repositorio:
export COMETAPI_KEY="your-key"
La URL base es https://api.cometapi.com/v1, y los trabajos de texto a imagen compatibles usan POST /images/generations. Antes de un despliegue, verifica cada modelo en el catálogo de modelos en vivo; el catálogo devuelve el ID actual, el endpoint compatible, las funciones y los metadatos de precios sin requerir cabecera de autorización.
A 20 de agosto de 2026, el catálogo en vivo listaba estas dos rutas útiles:
| Carga de trabajo | ID de modelo | Por qué encaja |
|---|---|---|
| Imágenes de producto con ajustes de salida | gpt-image-2 | Devuelve datos de uso y contenido de imagen en base64 en la ruta documentada compatible con OpenAI |
| Conceptos para anuncios y contenido a gran escala | doubao-seedream-4-5-251128 | Usa la misma ruta de generación y aparece con precio por solicitud |
La tabla es un punto de partida, no una afirmación de que los modelos tengan capacidades idénticas. El tamaño, la calidad, el formato, el soporte de imágenes de referencia y el comportamiento de respuesta siguen siendo específicos de cada modelo. Consulta el registro del modelo y su documentación vinculada antes de pasar parámetros opcionales.
Cómo construir un flujo de generación de imágenes por lotes en Python
1. Asigna a cada trabajo un ID duradero
Usa un objeto JSON por línea para que una cola, una exportación de base de datos o un trabajo de hoja de cálculo puedan alimentar al mismo worker:
{"id":"sku-1001","kind":"product","prompt":"Studio product photo of a ceramic coffee dripper on a warm neutral background"}
{"id":"campaign-204","kind":"ad","prompt":"Editorial summer travel image, vivid natural light, wide composition, no text"}
{"id":"blog-088","kind":"content","prompt":"Minimal illustration of a developer automating a creative workflow, no text"}
El ID se convierte en el nombre de archivo de salida y en la clave del manifiesto. En producción, úsalo como clave de idempotencia y omite los IDs ya marcados como correctos antes de reprocesar una cola.
2. Enruta por tipo de trabajo y luego valida contra el catálogo en vivo
El ejemplo asigna los trabajos de producto a gpt-image-2 y los de anuncios o contenido a doubao-seedream-4-5-251128. Un trabajo puede anular esa elección con su propio campo model. Al iniciar, el worker descarga el catálogo público y rechaza un ID que ya no figure.
Esto es más seguro que codificar un SDK específico de un proveedor en toda la aplicación. Puedes cambiar una ruta en un solo mapeo tras evaluar calidad, latencia y precio para tus propios prompts.
3. Acota la concurrencia en lugar de lanzar todo el lote
El worker comienza con cuatro solicitudes concurrentes. Ese número es una configuración conservadora de la aplicación, no un límite universal del servicio. Mide la latencia y las respuestas 429 de tu cuenta, y luego sube o baja MAX_WORKERS con criterio.
Solo se reintentan las respuestas 408, 429 y 5xx con backoff exponencial y jitter. Los errores de autenticación, los IDs de modelo no válidos y los parámetros no admitidos fallan de inmediato porque reintentar la misma solicitud incorrecta solo añade demora.
4. Normaliza el resultado antes de almacenarlo
Los modelos de imagen no siempre devuelven el mismo contenedor. La respuesta documentada de GPT Image contiene data[0].b64_json; otros modelos compatibles pueden devolver data[0].url. El worker maneja ambos, escribe la imagen en un archivo temporal y la renombra solo después de que la descarga o la decodificación se complete con éxito.
Para producción, sustituye el directorio local output/ por S3, R2, GCS u otro almacenamiento de objetos. No trates una URL alojada por el proveedor como almacenamiento permanente a menos que su política de retención lo indique explícitamente.
5. Registra uso, intentos y costo estimado
Cada resultado se convierte en una fila compacta del manifiesto con el ID del trabajo, el modelo, la ruta guardada, el estado y el costo estimado en USD cuando el catálogo en vivo proporciona suficientes datos de precios. Los trabajos fallidos conservan el error en lugar de desaparecer del lote.
Script completo de Python para generación de imágenes por lotes
Guarda lo siguiente como batch_image_pipeline.py, coloca la cola junto a él como jobs.jsonl y ejecuta python3 batch_image_pipeline.py.
import base64, json, os, random, time
from concurrent.futures import ThreadPoolExecutor
from pathlib import Path
import requests
BASE_URL = "https://api.cometapi.com/v1"
KEY = os.environ["COMETAPI_KEY"]
WORKERS = int(os.getenv("MAX_WORKERS", "4"))
OUT = Path("output")
ROUTES = {
"product": "gpt-image-2",
"ad": "doubao-seedream-4-5-251128",
"content": "doubao-seedream-4-5-251128",
}
catalog = requests.get("https://api.cometapi.com/api/models", timeout=30)
catalog.raise_for_status()
CATALOG = {model["id"]: model for model in catalog.json()["data"]}
def generate(job):
model = job.get("model", ROUTES[job["kind"]])
if model not in CATALOG:
raise ValueError(f"Unknown model: {model}")
payload = {"model": model, "prompt": job["prompt"], "n": 1}
if model == "gpt-image-2":
payload.update(quality="low", size="1024x1024", output_format="jpeg")
for attempt in range(4):
response = requests.post(
f"{BASE_URL}/images/generations",
headers={"Authorization": f"Bearer {KEY}"},
json=payload,
timeout=180,
)
if response.status_code not in {408, 429} and response.status_code < 500:
break
time.sleep(2**attempt + random.random())
response.raise_for_status()
body = response.json()
item = body["data"][0]
if item.get("b64_json"):
data = base64.b64decode(item["b64_json"])
extension = body.get("output_format", "png")
else:
download = requests.get(item["url"], timeout=120)
download.raise_for_status()
data = download.content
extension = {"image/png": "png", "image/webp": "webp"}.get(
download.headers.get("content-type"), "jpg"
)
path = OUT / f"{job['id']}.{extension}"
path.write_bytes(data)
price, usage = CATALOG[model].get("pricing") or {}, body.get("usage", {})
cost = price.get("per_request")
if cost is None and price.get("input") is not None:
cost = (usage.get("input_tokens", 0) * price["input"] +
usage.get("output_tokens", 0) * price["output"]) / 1_000_000
return {"id": job["id"], "model": model, "path": str(path),
"estimated_usd": cost * price.get("ratio", 1) if cost is not None else None}
def safe_generate(job):
try:
return {"status": "success", **generate(job)}
except Exception as error:
return {"id": job["id"], "status": "failed", "error": str(error)}
OUT.mkdir(exist_ok=True)
jobs = [json.loads(line) for line in Path("jobs.jsonl").read_text().splitlines() if line]
with ThreadPoolExecutor(max_workers=WORKERS) as pool:
results = list(pool.map(safe_generate, jobs))
with (OUT / "manifest.jsonl").open("w") as manifest:
manifest.writelines(json.dumps(result) + "\n" for result in results)
El script usa el catálogo actual en tiempo de ejecución, mientras que los dos mapeos de respaldo son ejemplos verificados el 20 de agosto de 2026. Vuélvelos a comprobar antes de publicar o desplegar el código en otra fecha.
Cómo probar el flujo de generación de imágenes por lotes
Empieza con un trabajo y un worker:
MAX_WORKERS=1 python3 batch_image_pipeline.py
Una respuesta correcta de GPT Image sigue esta estructura:
{
"created": 1776841943,
"output_format": "jpeg",
"quality": "low",
"size": "1024x1024",
"usage": {
"input_tokens": 16,
"output_tokens": 208,
"total_tokens": 224
},
"data": [{"b64_json": "<base64-image-data>"}]
}
El worker decodifica la imagen, escribe output/<job-id>.jpeg y añade una fila de éxito a output/manifest.jsonl. Si un modelo devuelve una URL en su lugar, el worker la descarga y almacena la ruta local en el mismo formato de manifiesto.
El código se revisó sintácticamente de forma local. Una llamada de generación en vivo aún requiere tu clave de CometAPI, así que ejecuta la prueba de humo de un trabajo antes de aumentar la concurrencia.
¿Cuánto cuesta la generación de imágenes por lotes?
Los precios deben llevar marca de tiempo porque las tarifas de los modelos cambian. A 20 de agosto de 2026, el catálogo de modelos en vivo de CometAPI devolvía los siguientes campos de precio base y una proporción de facturación de 0.8:
gpt-image-2: 5 USD por 1M de tokens de entrada y 30 USD por 1M de tokens de salida; aplicar la proporción indicada da tarifas efectivas de 4 y 24 USD por 1M de tokens.doubao-seedream-4-5-251128: 0,04 USD por solicitud; aplicar la proporción indicada da 0,032 USD por solicitud.
La guía de precios de CometAPI explica la facturación basada en tokens para modelos con precios oficiales y la facturación por llamada para modelos con precio por solicitud. El script lee el catálogo cuando se ejecuta y usa la misma regla:
token cost = ratio × (input tokens × input rate + output tokens × output rate) / 1,000,000
request cost = ratio × per-request price
Por ejemplo, la respuesta documentada de GPT Image anterior informa de 16 tokens de entrada y 208 tokens de salida. Usando los valores del catálogo del 20 de agosto, ese resultado ilustrativo se estima en unos 0,005056 USD. El total real cambia según el modelo, la calidad, el tamaño, el prompt, los reintentos y el uso de la respuesta. Considera la respuesta de la API y el panel de uso de la cuenta como el registro de facturación, no una suposición fija por imagen.
Presupuesta también el trabajo no exitoso. Un reintento tras un timeout no confirmado puede producir un segundo resultado facturable, y una imagen técnicamente correcta que no pase la revisión también consume presupuesto. Haz seguimiento tanto del costo de la API como de la tasa de aceptación:
effective cost per accepted image = total batch spend / approved images
Errores comunes de la API de generación de imágenes y cómo solucionarlos
| Síntoma | Causa probable | Solución |
|---|---|---|
| 401 | Falta la clave o no es válida | Comprueba la COMETAPI_KEY del lado del servidor |
| 400 | Modelo no válido u opción no admitida | Revisa el catálogo en vivo y elimina campos específicos del modelo |
| 429 | Concurrencia excesiva | Reduce MAX_WORKERS y mantén el backoff exponencial |
| 5xx repetidos | Falla temporal aguas arriba | Reintenta con un tope y luego mueve el trabajo a una DLQ |
| Sin imagen guardada | La respuesta usó otro contenedor | Inspecciona data[0] y admite tanto b64_json como url |
| Gasto duplicado | El trabajo se reejecutó tras un fallo parcial | Usa IDs duraderos y confirma solo después de almacenar |
No reintentes todos los errores. Una solicitud 400 permanente seguirá siendo inválida, mientras que un bucle de reintentos 429 sin límite puede convertir un pico de tráfico en un atasco.
Buenas prácticas para la generación de imágenes en producción a escala
Pasa de JSON Lines a una cola duradera cuando intervengan múltiples workers. Establece un tiempo de visibilidad mayor que el tiempo máximo de generación, confirma un trabajo solo después de que la imagen y el manifiesto estén almacenados y envía los trabajos agotados a una cola de muertos para revisión.
Mantén los controles opcionales en configuración específica del modelo. Una carga compartida debe contener solo campos comunes como model, prompt y n: 1; añade quality, size u output_format solo después de que la documentación del modelo seleccionado los confirme. Si agregas enrutamiento de respaldo, elige un modelo que admita la misma tarea y reconstruye la carga para ese modelo en lugar de reproducir a ciegas opciones específicas del proveedor.
Almacena la clave de la API en un gestor de secretos, restringe la entrada de prompts, analiza los recursos generados según tu política y no incluyas URLs del proveedor en registros de producto a largo plazo. Registra ID del trabajo, ID del modelo, latencia, intentos, uso, ruta de almacenamiento, resultado de revisión y fecha del snapshot del catálogo. Esos campos te permiten comparar modelos por costo de imagen aceptada en lugar de por precio por llamada.
Por último, establece barandillas presupuestarias: un tamaño máximo de lote, un límite de reintentos por trabajo, una alerta de gasto diario y una condición de parada cuando baje la tasa de aprobación. Escalar más rápido un prompt deficiente no es una optimización.
Preguntas frecuentes sobre la automatización de la generación de imágenes a escala
¿Cuál es la forma más fácil de automatizar la generación de imágenes a escala sin gestionar varias API?
Usa un solo flujo de cola y almacenamiento, luego envía solicitudes de imagen compatibles a través de una única clave de CometAPI y https://api.cometapi.com/v1/images/generations. Cambia el ID de modelo en tu capa de enrutamiento en lugar de mantener autenticaciones y SDKs por proveedor.
¿Puedo enviar una solicitud y pedir a varios modelos de imagen que generen a la vez?
El ejemplo envía un modelo por trabajo. El fan-out es un flujo a nivel de aplicación: duplica un trabajo con IDs y valores de modelo distintos y luego compara las salidas almacenadas. Esto mantiene el costo y el estado de revisión atribuibles a cada modelo.
¿Qué concurrencia debería usar?
No existe un número universal para todas las cuentas y modelos. Comienza con un pool acotado pequeño, como cuatro workers, monitoriza la latencia y las respuestas 429, y ajusta con base en la evidencia.
¿Debo almacenar la URL devuelta o la imagen en sí?
Almacena la imagen en tu propio almacenamiento de objetos. Una URL devuelta puede ser temporal, mientras que los modelos GPT Image pueden devolver contenido base64 en lugar de una URL.
¿Cómo elijo el modelo más barato?
Calcula el costo por imagen aceptada, no solo el precio por llamada. Incluye cargos por tokens o por solicitud, reintentos, descargas fallidas, recursos rechazados, posprocesado y revisión humana. Vuelve a comprobar el catálogo de modelos en vivo el día que publiques o despliegues.
¿Dónde debo verificar el endpoint y el formato de respuesta?
Usa el Quick Start de CometAPI, la documentación del catálogo de modelos, la referencia de generación de imágenes y la guía de precios.