Generación masiva de vídeo con IA: cientos de clips sin sustos

La primera vez que lanzas trescientas generaciones de vídeo desde un script, algo se rompe hacia el trabajo cuarenta. Un proveedor devuelve un 429, tu bucle reintenta al instante, los reintentos chocan entre sí y, cuando termina la ejecución, tienes 280 archivos, algunos duplicados que pagaste dos veces y una docena de trabajos cuyos enlaces de salida ya caducaron. Los modelos funcionan bien; el fallo viene de tratar un lote como si fuera un simple bucle for.

Esta es la fontanería que permite dejar una generación masiva de vídeo con IA funcionando sin supervisión: presupuestar el lote de antemano, encolar dentro de los límites de concurrencia, reintentar sin pagar dos veces, conciliar reembolsos y nombrar las salidas para encontrarlas el mes siguiente.

Tres límites que deciden la velocidad de un lote

Las API de generación limitan en tres ejes distintos, que la documentación de Leonardo.Ai define con claridad:

• La concurrencia es el número de trabajos de generación que se procesan en paralelo.
• El límite de cola (pending) es cuántas solicitudes pueden esperar cuando todos los huecos concurrentes están ocupados.
• El límite de tasa de la API es cuántas solicitudes puedes hacer en una ventana de tiempo, sea cual sea su contenido.

La concurrencia no limita el total de solicitudes: el trabajo extra espera en la cola si hay sitio. La concurrencia marca tu rendimiento; el límite de tasa marca con qué frecuencia puedes enviar y consultar.

Cómo son los valores por defecto

Son bajos y suelen fijarse por organización, no por clave:

• fal: las cuentas nuevas empiezan con 2 solicitudes concurrentes y suben según las facturas pagadas en las últimas cuatro semanas hasta 40 en autoservicio. Las solicitudes en IN_QUEUE no cuentan para el límite; solo las IN_PROGRESS.
• Vidu: hasta 5 tareas concurrentes por organización, y el límite se aplica por organización, no por clave de API.
• LTX: según su página de límites de tasa, hasta 2 generaciones simultáneas por defecto, y las solicitudes que exceden el límite reciben un 429 con una cabecera Retry-After.
• Replicate: 600 solicitudes por minuto para crear predicciones y 3.000 por minuto para el resto de endpoints, con ráfagas cortas toleradas antes de aplicar throttling.

Con una concurrencia de 2, una tanda de 300 clips ocupa una tarde entera por rápido que sea tu código. Trátala como un proceso en segundo plano, con un manifiesto y una línea de meta.

Calcula el coste del lote antes de pulsar ejecutar

Con precios por llamada, el coste de un lote es un producto de números que ya conoces. La fórmula para tu runbook:

Coste del lote = clips x segundos por clip x precio por segundo + imágenes x precio por imagen + (caracteres / 450) x precio por cada 450 caracteres de voz.

Con los precios públicos de Aitachyon en el momento de escribir esto (la lista completa está en la página de modelos con el precio de cada llamada), esto es lo que cuestan lotes realistas de principio a fin, con clips de 5 segundos:

• 20 hooks en Hailuo 02 a $0.085/s: 20 x 5 x $0.085 = $8.50.
• Los mismos 20 hooks en Kling v3: $16.00 sin audio a $0.16/s, o $32.00 con audio nativo a $0.32/s.
• Los mismos 20 hooks en Seedance 2.5: $20.00 en 480p ($0.20/s) o $44.00 en 720p ($0.44/s).
• 50 fotos de producto en Seedream 4.0 a $0.057 por imagen: $2.85. En FLUX.2 [pro], de $0.057 a $0.086: de $2.85 a $4.30. En Nano Banana a $0.13: $6.50.
• Una semana de shorts, siete vídeos formados cada uno por tres clips de 5 segundos de Hailuo 02 y unos 900 caracteres de locución de ElevenLabs ($0.043 a $0.086 por cada 450 caracteres): por short, 15 x $0.085 = $1.275 de vídeo y de $0.086 a $0.172 de voz, es decir, unos $9.53 a $10.13 por semana.
• 300 clips: 1.500 segundos de vídeo. Son $127.50 en Hailuo 02 y $480.00 en Kling v3 con audio.

El mismo lote varía aproximadamente de uno a cuatro según el modelo, así que elegir modelo pesa más a volumen alto. Un patrón habitual: generar todas las variantes en un modelo más barato, elegir las ganadoras y volver a renderizar solo esas en el modelo con el acabado o el audio nativo que quieres. El desglose de precios de API modelo por modelo explica las contrapartidas.

Dos partidas que se olvidan. Los reintentos: con una mala lógica de reintento, una tanda de 300 clips factura bastante más de 300. Y la tasa de aprovechamiento: si te quedas con un clip de cada cinco, un clip utilizable cuesta cinco veces el precio de la llamada. La pregunta previa es cuántos anuncios conviene realmente lanzar.

El manifiesto de trabajos: nombra cada trabajo antes de enviarlo

El hábito más útil en la generación masiva es escribir todo el lote en un archivo de manifiesto antes de enviar ninguna solicitud. Registra qué debería existir, qué se envió, qué terminó y cuánto costó. Cuando el script falla en el trabajo 140, retomas desde el manifiesto en lugar de adivinar.

Una fila de manifiesto que sobrevive a un fallo

1. job_key: un ID determinista construido a partir de campaña, plano, modelo y variante, por ejemplo spring-launch_hook-07_kling3_v2.
2. modelo y parámetros: slug del modelo, duración, resolución, audio activado o no, seed si el modelo la admite.
3. prompt: el texto exacto enviado, para poder reproducir un ganador.
4. estimated_cost: calculado con la fórmula de arriba.
5. status: planned, submitted, running, done, failed.
6. provider_id: el ID de solicitud o de trabajo que devuelve la API al enviar.
7. output_ref y local_path: dónde está el archivo una vez que lo tienes.
8. actual_cost y attempts: se rellenan al terminar.

Suma estimated_cost y no arranques si supera el presupuesto. Esa comprobación detecta el error de tecleo que convierte 30 clips en 300.

Idempotencia: la regla que evita el doble cobro

El momento peligroso es un timeout de red al enviar: no sabes si el trabajo se creó, y un reintento a ciegas puede cobrarlo dos veces. Stripe documenta la defensa estándar para los POST de pago: el servidor guarda el código de estado y el cuerpo de la primera solicitud por cada clave de idempotencia, incluidos los errores 500, y devuelve ese mismo resultado a las repeticiones. Las claves pueden tener hasta 255 caracteres, pueden purgarse pasadas al menos 24 horas, y reutilizar una clave con parámetros distintos devuelve un error.

Muchas API de generación no documentan la idempotencia; la página de fiabilidad de fal no aborda explícitamente las garantías de idempotencia. Cuando el proveedor no ofrece clave, tu manifiesto es la capa de idempotencia: antes de reenviar un trabajo cuyo envío expiró, búscalo en el proveedor y reenvíalo solo cuando hayas confirmado que no existe.

Encola el trabajo y limita lo que está en curso

Las API de vídeo son asíncronas: envías, recibes un ID y vuelves a por el resultado. La cola de fal devuelve un request_id que hay que guardar para consultar el estado más tarde y mueve cada solicitud por IN_QUEUE, IN_PROGRESS y COMPLETED. La guía de vídeo de OpenAI usaba el mismo esquema, con los estados queued, in_progress, completed y failed.

El patrón que evita los rechazos en masa, según la documentación de LTX, es una cola local que limita los trabajos activos a la concurrencia permitida. En la práctica:

1. Carga todas las filas planificadas del manifiesto en una cola local.
2. Arranca un pool de workers del tamaño de tu límite de concurrencia. Si el proveedor solo cuenta los trabajos en ejecución, como fal, puedes enviar por adelantado a su cola; fal afirma que las solicitudes en cola nunca se descartan por los límites de concurrencia, salvo que venza un start_timeout.
3. Cada worker envía un trabajo, anota al instante el ID del proveedor en el manifiesto y espera a que termine.
4. Al terminar, el worker descarga la salida, escribe la fila y toma el siguiente trabajo.
5. Pon al principio los trabajos que necesitas y marca las variantes masivas con prioridad baja donde se pueda; fal acepta priority en low para esto.

Webhooks o polling

Prefiere los webhooks cuando puedas recibirlos. Replicate envía POST HTTP cuando las predicciones se crean, se actualizan y terminan, y fal acepta un webhook_url al enviar y publica en él el ID de solicitud, el estado y la salida al completarse. Haz el handler idempotente: la misma finalización puede llegar más de una vez, así que busca el trabajo por ID y no hagas nada si la fila ya está en done.

Si haces polling, hazlo despacio. OpenAI sugería cada 10 a 20 segundos, con backoff exponencial si hace falta. Consultar 300 trabajos cada segundo consume tu límite de tasa general (el de Replicate es de 3.000 solicitudes por minuto para los endpoints que no crean) y te aplican throttling justo en las llamadas que importan.

Reintentos que no multiplican la factura

Reintentar tras un retardo fijo sincroniza a tus workers: se despiertan a la vez y vuelven a chocar. AWS lo midió en su estudio sobre exponential backoff y jitter. Con 100 clientes compitiendo, el full jitter redujo el total de llamadas a menos de la mitad respecto al backoff exponencial sin jitter, y este último tardaba tanto que se dejó fuera de la gráfica de tiempo de finalización.

La fórmula del full jitter:

sleep = random(0, min(cap, base x 2^attempt))

Con base = 1 segundo y cap = 60 segundos, el intento 3 espera un tiempo aleatorio entre 0 y 8 segundos. La propia guía de fal para clientes HTTP sin SDK sigue la misma forma, con un backoff de 1 s, 2 s, 4 s, 8 s, y su SDK reintenta hasta 10 veces.

Una regla de decisión para reintentar

No todos los errores merecen un reintento:

1. 429 con cabecera Retry-After: espera exactamente ese tiempo, más un poco de jitter. El mensaje de throttling de Replicate indica cuándo se restablece el límite, en torno a 30 segundos.
2. 429 sin cabecera, o concurrent_requests_limit de fal (fal también envía X-Fal-needs-retry: 1): backoff con full jitter y quita un worker si sigue ocurriendo.
3. 503, 504 o error de conexión: reintenta con backoff. Son los errores que la cola de fal reintenta automáticamente, junto con el 429.
4. Timeout al enviar: no reenvíes hasta comprobar si el trabajo existe (ver idempotencia más arriba).
5. Errores 4xx de validación o de contenido: no reintentes. Marca la fila como failed con el mensaje, corrige el prompt o los parámetros y vuelve a encolarla como una variante nueva.
6. Trabajo completado con estado failed: reintenta una vez con los mismos parámetros. Si vuelve a fallar, considéralo un problema del prompt y sigue adelante.

Limita los intentos por trabajo (tres es un valor razonable) y el total de reintentos por tanda. Cuando una décima parte de los trabajos está reintentando, algo falla aguas arriba: pausa la tanda.

Fallos, reembolsos y conciliación

A gran volumen, algunos renders fallan, y la cuestión es quién paga. fal afirma que las solicitudes fallidas que devuelven 5xx no generan cargo. En Aitachyon, un render que falla se reembolsa automáticamente, al céntimo, y cada trabajo aparece detallado con el modelo en que se ejecutó y lo que costó. Sea cual sea la política de tu proveedor, concilia después de cada tanda en lugar de fiarte.

Checklist de conciliación tras la tanda

• Cuenta las filas por estado. Planned menos done menos failed debe dar cero; lo que quede está atascado y necesita una consulta de estado.
• Suma actual_cost y compáralo con estimated_cost. Una diferencia de más de unos pocos puntos porcentuales suele indicar envíos duplicados, o un modelo o una duración distintos de los previstos.
• Asocia cada trabajo cobrado a una fila del manifiesto. Un cargo sin fila es un duplicado causado por un reintento.
• Comprueba que cada trabajo fallido muestre su reembolso o un cargo cero, y que cada fila done tenga un archivo local con la duración esperada.
• Registra la selección: qué salidas te quedaste. Esa proporción alimenta el presupuesto del siguiente lote.

Con un script esto lleva minutos, y se traslada directamente a producir 50 variantes UGC por semana, donde mantiene estable el gasto semanal.

Saca los archivos antes de que desaparezcan

Las salidas alojadas por el proveedor son temporales. Replicate borra a la hora los archivos de salida de las predicciones creadas por API y te indica que guardes una copia; las predicciones hechas desde la interfaz web conservan sus archivos, así que un flujo que funcionaba a mano puede perder archivos cuando se automatiza. Las URL de descarga de vídeo de OpenAI eran válidas como máximo 1 hora tras la generación.

Lanza la tanda de noche, descarga por la mañana y te encuentras enlaces muertos. Descarga en el handler de finalización, en el mismo paso que marca la fila como done.

Una convención de nombres en la que se puede buscar

Renombra cada archivo al descargarlo con su job key, por ejemplo spring-launch_hook-07_kling3_v2.mp4, y guarda la referencia del proveedor en el manifiesto. Aitachyon da a cada archivo generado una ref estable (img_, scn_, vo_ y así sucesivamente) que el código puede recuperar en cualquier momento con GET /api/generations/{ref}, de modo que la ref es el identificador duradero y el archivo local es tu copia de trabajo. Con ambos en el manifiesto, una pregunta como "qué prompt produjo el hook que ganó en marzo" se resuelve con un grep.

La dependencia del proveedor también es un riesgo del lote

La guía de OpenAI señala ahora que los modelos Sora 2 y la Videos API se descontinuaron el 24 de septiembre de 2026. Los pipelines conectados a ese endpoint tuvieron que reescribirse. Si el modelo es un parámetro del manifiesto, una retirada cuesta un cambio de configuración.

Control de costes por clave y tandas lanzadas desde un agente

Un script con errores y un saldo ilimitado es la combinación cara. Replicate aplica límites progresivamente más estrictos a medida que baja el crédito y recomienda mantener el saldo por encima de $20 con recarga automática, mientras que las cuentas sin método de pago quedan limitadas a 1 solicitud por segundo. Tus propias salvaguardas deben ir encima:

Salvaguardas de gasto para tandas sin supervisión

1. Una clave de API por pipeline. El trabajo nocturno de shorts, el script de variantes de anuncios y la sesión de tu agente tienen cada uno su clave, de modo que el gasto es atribuible. En Aitachyon cada clave tiene su propio gasto, una alerta cuando gasta inusualmente rápido y revocación con un clic.
2. Un techo prepagado. Un saldo prepagado es un tope duro por construcción. El saldo de Aitachyon no caduca nunca, así que recargar para una tanda grande no crea presión de usar o perder. La comparación entre créditos y pago por llamada repasa dónde pierde dinero cada modelo.
3. Una comprobación de presupuesto en el código. El total del manifiesto, comprobado antes de la tanda y otra vez cada 50 trabajos contra el gasto real.
4. Un interruptor de emergencia. Si salta la alerta de la clave, revócala. Los workers fallan rápido con errores de autenticación, que es lo que quieres.

El mismo lote, dirigido por un agente

Cada vez más, es un agente de código quien escribe y ejecuta el script. Con un servidor MCP alojado conectado a Claude Code o Cursor, describes el lote ("veinte hooks de 5 segundos a partir de estos prompts en Hailuo 02, guardados en ./hooks con el número de hook en el nombre") y el agente envía, espera, descarga e informa de cada archivo con su coste. Conectar Claude Code a Aitachyon es un solo comando:

claude mcp add --transport http aitachyon https://aitachyon.com/api/mcp --header "Authorization: Bearer ait_..."

Las tandas de agente necesitan las mismas salvaguardas: una clave dedicada, un presupuesto indicado en el prompt y el manifiesto escrito en disco sobre la marcha. El tutorial sobre generar vídeo desde Claude Code mediante MCP muestra la configuración, y una configuración de agente que funciona para producir vídeo explica cómo encadenar guiones, clips y voz hasta tener piezas terminadas.

Checklist previo a una tanda masiva

Copia esto al principio de tu script de lote o del prompt de tu agente:

1. Manifiesto escrito, una fila por salida, job keys deterministas.
2. Total estimado por debajo del presupuesto.
3. Una clave de API dedicada con alertas de gasto.
4. Workers limitados al tope de concurrencia.
5. Backoff con full jitter, Retry-After respetado, tres intentos como máximo.
6. Envíos expirados comprobados antes de cualquier reenvío.
7. Handler de webhook o polling lento, idempotente en ambos casos.
8. Descarga y renombrado al completarse.
9. Un lote de prueba de cinco, ejecutado de principio a fin.
10. Script de conciliación listo.

El lote de prueba es el paso que la gente se salta y el más barato: en Hailuo 02, en el momento de escribir esto, cinco clips de 5 segundos cuestan $2.13, y detectan la relación de aspecto equivocada antes de que te cueste trescientas veces más.

Preguntas frecuentes

¿Pago las generaciones de vídeo con IA que fallan?

Depende del proveedor. fal no cobra las solicitudes que fallan con un error 5xx, y Aitachyon reembolsa automáticamente los renders fallidos, al céntimo. En cualquier caso, concilia tus cargos detallados con tu lista de trabajos después de cada tanda, porque un envío duplicado por un mal reintento es un trabajo exitoso que sí pagaste.

¿Cuánto tiempo siguen disponibles los archivos de vídeo generados?

A menudo, poco. Replicate borra los archivos de salida de la API tras una hora, y las URL de descarga de vídeo de OpenAI duraban como máximo una hora. Descarga cada archivo en cuanto termine su trabajo y guárdalo con tu propio nombre. En Aitachyon, cada salida tiene además una ref estable que puedes recuperar más tarde con GET /api/generations/{ref}.

¿Cuánto cuesta generar 100 vídeos cortos con IA?

Para 100 clips de cinco segundos con los precios de Aitachyon en el momento de escribir esto, son $42.50 en Hailuo 02, $80 en Kling v3 sin audio y $100 en Seedance 2.5 en 480p. Divide por tu tasa de aprovechamiento para obtener el coste por clip utilizable.

Fuentes

1. Replicate: límites de tasa
2. Replicate: archivos de salida
3. Replicate: webhooks
4. fal: límites de concurrencia
5. fal: inferencia asíncrona y cola
6. fal: fiabilidad
7. Leonardo.Ai: guía de concurrencia, cola y límites de tasa
8. Vidu: uso y límites
9. Stripe: solicitudes idempotentes
10. AWS Architecture Blog: exponential backoff y jitter

Si quieres ejecutar este tipo de lote sin abrir una cuenta distinta por cada modelo, Aitachyon reúne Seedance, Kling, Veo, Hailuo, los modelos de imagen y la voz de ElevenLabs tras una sola clave, utilizable desde una API HTTP o desde el servidor MCP alojado, con cada trabajo detallado, los renders fallidos reembolsados y el gasto seguido por clave. La guía de inicio de la API y el MCP explica la configuración.