Escalar la generación de vídeo con IA: lotes, webhooks y control de costes

La Nureta Developer API cobra el vídeo de forma lineal, así que el coste es segundos × tarifa. seahorse-480p: $0.1888 por segundo, $0.944 por 5 segundos. seahorse-720p: $0.2773 por segundo, $1.3864 por 5 segundos. seahorse-1080p: $0.5428 por segundo, $2.7139 por 5 segundos. Los clips únicos duran 5, 8, 10, 12 o 15 segundos, y los vídeos de varias tomas unidas, cualquier número entero de segundos entre 16 y 180, con la misma tarifa. Los guiones cuestan $0.01 fijos y las imágenes $0.05 fijos. El endpoint público GET /api/v3/models devuelve los precios vigentes, así que lee las tarifas de ahí en lugar de fijarlas en el código.

Estos son precios de la API, no de la app. La app para consumidores en nureta.ai cobra $1.29 por vídeo de 5 segundos, o 2 créditos por segundo, que con el paquete de $39.99 sale a unos $0.91 por 5 segundos. La app incluye un primer vídeo gratis y una interfaz lista a 480p; la API es un producto para desarrolladores con pago por uso, 720p y 1080p, que se cobra de un saldo prepago. Trátalos como productos distintos con precios distintos.

Ejemplos a precio de tarifa. Una película de 60 segundos: $11.33 a 480p, $16.64 a 720p y $32.57 a 1080p. Una película de 180 segundos a 480p: $33.98. Un lote de 100 clips de 15 segundos a 480p: 1.500 segundos × $0.1888 = $283.20; el mismo lote cuesta $415.95 a 720p y $814.20 a 1080p. 100 guiones de storyboard: $1.00. 100 imágenes de portada: $5.00.

La conclusión es que la resolución, y no el volumen de guiones o imágenes, es la principal palanca de coste. Pasar de 480p a 1080p casi triplica el precio de cada segundo, mientras que guiones e imágenes son casi gratis al lado del vídeo. Presupuesta un lote como segundos totales por resolución y añade un pequeño margen para volver a renderizar las tomas que descartes.

El rendimiento lo marca un límite por clave. Las claves nuevas tienen por defecto 10 solicitudes por segundo, ajustables entre 1 y 100 por clave. Cuentan todas las llamadas, no solo la creación de tareas: las consultas de estado, las ediciones del storyboard y las solicitudes de subida consumen el mismo cupo. La firma de subidas tiene además un tope fijo de 30 solicitudes por minuto por clave, así que sube las imágenes de referencia antes de que empiece un lote grande, no dentro del bucle principal.

Si superas el límite, la API devuelve HTTP 429 con el código RateLimitExceeded y las cabeceras RateLimit estándar. Lee las cabeceras, espera un poco y reintenta. Una cola que mantenga tu ritmo de envío algo por debajo del límite de la clave evita casi todos los 429, y usar claves separadas para cargas distintas, como renders masivos frente a un producto en vivo, impide que un lote deje sin servicio a los usuarios interactivos.

Consultar mil tareas en curso cada pocos segundos gasta tu límite en respuestas que casi siempre dicen que nada ha cambiado. En su lugar, indica un callback_url en cada tarea y la API te enviará por POST el objeto final de la tarea cuando termine bien o falle, el mismo objeto que devuelve un GET. Añade un callback_secret de 8 a 256 caracteres y cada entrega irá firmada con HMAC-SHA256, que verificas con una comparación de tiempo constante.

Diseña el receptor según las reglas de entrega. La entrega es al menos una vez (at-least-once), así que deduplica por id de tarea. Una entrega cuenta como correcta con cualquier respuesta 2xx en 5 segundos, no se siguen redirecciones y los fallos se reintentan hasta 5 veces, así que responde rápido y descarga el vídeo en una tarea en segundo plano. La URL debe ser HTTPS y no puede apuntar a direcciones privadas ni a localhost. Mantén una consulta lenta de respaldo para las tareas que nunca avisen.

El saldo prepago es un tope firme. Al crear una tarea se reserva su precio por adelantado, y si el saldo no alcanza, la API devuelve AccountOverdueError en lugar de ejecutarla, así que ni un bucle descontrolado puede gastar dinero que no hayas cargado. Las generaciones fallidas se reembolsan automáticamente: solo pagas los vídeos entregados. Carga un saldo por campaña y el lote no podrá superarlo.

Tres hábitos reducen aún más el desperdicio. Prueba ideas con un guion de $0.01, que devuelve el storyboard sin renderizar. Usa el modo edit como paso de aprobación en vídeos largos: el borrador queda en espera con imágenes de vista previa y cancelarlo antes del render reembolsa el importe completo al instante. Y haz los prototipos a 480p: la resolución la fija el modelo elegido al crear una tarea, así que, una vez aprobado un storyboard, envíalo como tus propios segments en una tarea nueva con seahorse-720p o seahorse-1080p. Los controles del storyboard en sí se explican en nuestra guía sobre control a nivel de storyboard.

Cada respuesta de una tarea de vídeo incluye un objeto step con un código estable para máquinas, como queued, generating_script, generating_visuals, pending_rendering, rendering, stitching, done, failed o cancelled. Durante el render también cuenta los clips terminados, por ejemplo {"code": "rendering", "done": 3, "total": 5}. Asigna esos códigos a tus propias etiquetas del panel y ten en cuenta que step puede ir hasta unos 30 segundos por detrás de la fase real.

De estos datos salen directamente métricas útiles del lote: tareas por estado, segundos renderizados por resolución, gasto reservado frente a reembolsado y tiempo desde la creación hasta el éxito. Vigila la tasa de reembolsos y la proporción de borradores cancelados: ambas indican si los prompts necesitan trabajo antes de la siguiente tirada. Las colas, el almacenamiento y el diseño del pipeline se tratan en nuestra guía para automatizar la producción de vídeo para adultos con una API.