Geração de vídeo com IA em massa: centenas de clipes sem sustos

Na primeira vez que você roda trezentas gerações de vídeo a partir de um script, algo quebra por volta do job quarenta. Um provedor devolve um 429, seu loop tenta de novo na hora, os retries colidem entre si e, quando a execução termina, você tem 280 arquivos, alguns duplicados pagos duas vezes e uma dúzia de jobs cujos links de saída já expiraram. Os modelos estão bem; a falha vem de tratar um lote como um simples loop for.

Esta é a infraestrutura que permite deixar um gerador de vídeo com IA em massa rodando sem supervisão: orçar o lote de antemão, enfileirar dentro dos limites de concorrência, tentar de novo sem pagar duas vezes, conciliar reembolsos e nomear as saídas para achá-las no mês seguinte.

Três limites que decidem a velocidade de um lote

As APIs de geração limitam em três eixos separados, que a documentação da Leonardo.Ai define com clareza:

• A concorrência é o número de jobs de geração processados em paralelo.
• O limite de fila (pending) é quantas requisições podem esperar quando todos os slots concorrentes estão ocupados.
• O rate limit da API é quantas requisições você pode fazer em uma janela de tempo, seja qual for o conteúdo delas.

A concorrência não limita o total de requisições: o trabalho extra espera na fila, se houver espaço. A concorrência define seu throughput; o rate limit define com que frequência você pode enviar e consultar.

Como são os valores padrão

Os padrões são baixos e costumam ser definidos por organização, e não por chave:

• fal: contas novas começam com 2 requisições concorrentes e crescem com as faturas pagas nas últimas quatro semanas até 40 em autoatendimento. Requisições em IN_QUEUE não contam para o limite; só as IN_PROGRESS.
• Vidu: até 5 tarefas concorrentes por organização, e o limite vale por organização, não por chave de API.
• LTX: segundo sua página de rate limits, até 2 gerações simultâneas por padrão, com as requisições acima do limite respondidas com um 429 e um header Retry-After.
• Replicate: 600 requisições por minuto para criar predições e 3.000 por minuto para os demais endpoints, com rajadas curtas toleradas antes do throttling.

Com concorrência 2, uma execução de 300 clipes ocupa uma noite inteira, por mais rápido que seja seu código. Trate-a como um job em segundo plano, com um manifesto e uma linha de chegada.

Calcule o custo do lote antes de apertar executar

Com preço por chamada, o custo de um lote é um produto de números que você já conhece. A fórmula para o seu runbook:

Custo do lote = clipes x segundos por clipe x preço por segundo + imagens x preço por imagem + (caracteres / 450) x preço por 450 caracteres de voz.

Usando os preços públicos da Aitachyon no momento em que escrevo (a lista completa está na página de modelos com o preço de cada chamada), veja quanto custam lotes realistas de ponta a ponta, com clipes de 5 segundos:

• 20 hooks no Hailuo 02 a $0.085/s: 20 x 5 x $0.085 = $8.50.
• Os mesmos 20 hooks no Kling v3: $16.00 sem áudio a $0.16/s, ou $32.00 com áudio nativo a $0.32/s.
• Os mesmos 20 hooks no Seedance 2.5: $20.00 em 480p ($0.20/s) ou $44.00 em 720p ($0.44/s).
• 50 fotos de produto no Seedream 4.0 a $0.057 por imagem: $2.85. No FLUX.2 [pro], de $0.057 a $0.086: de $2.85 a $4.30. No Nano Banana a $0.13: $6.50.
• Uma semana de shorts, sete vídeos feitos cada um de três clipes de 5 segundos do Hailuo 02 mais cerca de 900 caracteres de narração da ElevenLabs ($0.043 a $0.086 por 450 caracteres): por short, 15 x $0.085 = $1.275 de vídeo e de $0.086 a $0.172 de voz, ou seja, cerca de $9.53 a $10.13 pela semana.
• 300 clipes: 1.500 segundos de vídeo. São $127.50 no Hailuo 02 e $480.00 no Kling v3 com áudio.

O mesmo lote varia em torno de quatro para um entre os modelos, então a escolha do modelo pesa mais em volume. Um padrão comum: gerar todas as variantes em um modelo mais barato, escolher as vencedoras e renderizar de novo só essas no modelo com o visual ou o áudio nativo que você quer. O detalhamento de preços de API modelo a modelo cobre as trocas envolvidas.

Duas linhas que as pessoas esquecem. Os retries: com uma lógica de retry ruim, uma execução de 300 clipes fatura bem mais de 300. E a taxa de aproveitamento: se você fica com um clipe em cinco, um clipe utilizável custa cinco vezes o preço da chamada. A pergunta anterior é quantos anúncios você deveria de fato rodar.

O manifesto de jobs: dê nome a cada job antes de enviá-lo

O hábito mais útil na geração em massa é escrever o lote inteiro em um arquivo de manifesto antes de qualquer requisição sair. Ele registra o que deve existir, o que foi enviado, o que terminou e quanto custou. Quando o script cai no job 140, você retoma a partir dele em vez de adivinhar.

Uma linha de manifesto que sobrevive a uma queda

1. job_key: um ID determinístico montado a partir de campanha, plano, modelo e variante, por exemplo spring-launch_hook-07_kling3_v2.
2. modelo e parâmetros: slug do modelo, duração, resolução, áudio ligado ou não, seed se o modelo aceitar uma.
3. prompt: o texto exato enviado, para reproduzir um vencedor.
4. estimated_cost: calculado pela fórmula acima.
5. status: planned, submitted, running, done, failed.
6. provider_id: o ID de requisição ou de job que a API devolve no envio.
7. output_ref e local_path: onde o arquivo fica depois que você o obtém.
8. actual_cost e attempts: preenchidos na conclusão.

Some o estimated_cost e recuse-se a iniciar acima do orçamento. Essa checagem pega o erro de digitação que transforma 30 clipes em 300.

Idempotência: a regra que impede a cobrança em dobro

O momento perigoso é um timeout de rede no envio: você não sabe se o job foi criado, e um retry às cegas pode cobrá-lo duas vezes. A Stripe documenta a defesa padrão para POSTs pagos: o servidor guarda o código de status e o corpo da primeira requisição para cada chave de idempotência, inclusive erros 500, e devolve esse mesmo resultado às repetições. As chaves podem ter até 255 caracteres, podem ser removidas após pelo menos 24 horas, e reutilizar uma chave com parâmetros diferentes retorna um erro.

Muitas APIs de geração não documentam idempotência; a página de confiabilidade da fal não trata explicitamente de garantias de idempotência. Quando o provedor não oferece chave, seu manifesto é a camada de idempotência: antes de reenviar um job cujo envio deu timeout, procure-o no lado do provedor e só reenvie depois de confirmar que ele não existe.

Enfileire o trabalho, limite o que está em andamento

As APIs de vídeo são assíncronas: você envia, recebe um ID e volta para buscar o resultado. A fila da fal devolve um request_id a guardar para consultas de status posteriores e move cada requisição por IN_QUEUE, IN_PROGRESS e COMPLETED. O guia de vídeo da OpenAI usava o mesmo formato, com os status queued, in_progress, completed e failed.

O padrão que evita rejeições em massa, segundo a documentação da LTX, é uma fila local que limita os jobs ativos à concorrência permitida. Na prática:

1. Carregue todas as linhas planejadas do manifesto em uma fila local.
2. Inicie um pool de workers do tamanho do seu limite de concorrência. Se o provedor conta apenas os jobs em execução, como a fal, você pode enviar adiantado para a fila dele; a fal afirma que requisições na fila nunca são descartadas por limites de concorrência, a menos que um start_timeout expire.
3. Cada worker envia um job, registra o ID do provedor no manifesto imediatamente e espera a conclusão.
4. Na conclusão, o worker baixa a saída, grava a linha e pega o próximo job.
5. Coloque na frente os jobs de que você precisa e marque as variantes em massa como baixa prioridade onde houver suporte; a fal aceita priority definido como low para isso.

Webhooks ou polling

Prefira webhooks quando puder recebê-los. A Replicate envia POSTs HTTP quando as predições são criadas, atualizadas e finalizadas, e a fal aceita um webhook_url no envio e posta nele o ID da requisição, o status e a saída na conclusão. Torne o handler idempotente: a mesma conclusão pode chegar mais de uma vez, então busque o job pelo ID e não faça nada se a linha já estiver em done.

Se você faz polling, faça devagar. A OpenAI sugeria a cada 10 a 20 segundos, com backoff exponencial se necessário. Consultar 300 jobs a cada segundo queima seu rate limit geral (o da Replicate é de 3.000 requisições por minuto para endpoints que não criam) e faz você ser limitado justamente nas chamadas que importam.

Retries que não multiplicam a conta

Tentar de novo após um atraso fixo sincroniza seus workers: eles acordam juntos e colidem de novo. A AWS mediu isso em seu estudo sobre exponential backoff e jitter. Com 100 clientes disputando, o full jitter reduziu o total de chamadas em mais da metade em relação ao backoff exponencial sem jitter, que demorou tanto que ficou fora do gráfico de tempo de conclusão.

A fórmula do full jitter:

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

Com base = 1 segundo e cap = 60 segundos, a tentativa 3 dorme um tempo aleatório entre 0 e 8 segundos. A orientação da própria fal para clientes HTTP puros segue o mesmo formato, com backoff de 1 s, 2 s, 4 s, 8 s, e o SDK dela tenta até 10 vezes.

Uma regra de decisão para retries

Nem todo erro merece um retry:

1. 429 com header Retry-After: espere exatamente esse tempo, mais um pouco de jitter. A mensagem de throttling da Replicate informa quando o limite é reiniciado, em torno de 30 segundos.
2. 429 sem header, ou concurrent_requests_limit da fal (a fal também define X-Fal-needs-retry: 1): backoff com full jitter, e reduza um worker se continuar acontecendo.
3. 503, 504 ou erro de conexão: tente de novo com backoff. São os erros que a fila da fal repete automaticamente, junto com o 429.
4. Timeout no envio: não reenvie antes de checar se o job existe (veja idempotência acima).
5. Erros 4xx de validação ou de conteúdo: não tente de novo. Marque a linha como failed com a mensagem, corrija o prompt ou os parâmetros e reenfileire como uma nova variante.
6. Job concluído com status failed: tente uma vez com os mesmos parâmetros. Se falhar de novo, trate como problema de prompt e siga adiante.

Limite as tentativas por job (três é um padrão razoável) e o total de retries por execução. Quando um décimo dos jobs está em retry, algo está errado no provedor: pause a execução.

Falhas, reembolsos e conciliação

Em volume, alguns renders falham, e a questão é quem paga. A fal afirma que requisições com falha que retornam 5xx não geram cobrança. Na Aitachyon, um render que falha é reembolsado automaticamente, ao centavo, e cada job é detalhado com o modelo em que rodou e quanto custou. Seja qual for a política do seu provedor, concilie depois de cada execução em vez de confiar nela.

Checklist de conciliação pós-execução

• Conte as linhas por status. Planned menos done menos failed deve dar zero; o que sobrar está travado e precisa de uma consulta de status.
• Some o actual_cost e compare com o estimated_cost. Uma diferença acima de alguns por cento costuma indicar envios duplicados, ou um modelo ou duração diferentes do plano.
• Associe cada job cobrado a uma linha do manifesto. Uma cobrança sem linha é um duplicado de retry.
• Confira se todo job com falha mostra o reembolso ou cobrança zero, e se toda linha done tem um arquivo local com a duração esperada.
• Registre a seleção: quais saídas você manteve. Essa proporção alimenta o orçamento do próximo lote.

Com um script, isso leva minutos, e se transfere direto para produzir 50 variantes de UGC por semana, onde mantém o gasto semanal estável.

Tire os arquivos antes que desapareçam

As saídas hospedadas pelo provedor são temporárias. A Replicate apaga em uma hora os arquivos de saída de predições criadas por API e manda você guardar uma cópia; predições feitas pela interface web mantêm seus arquivos, então um fluxo que funcionava à mão pode perder arquivos depois de automatizado. As URLs de download de vídeo da OpenAI eram válidas por no máximo 1 hora após a geração.

Rode de madrugada, baixe de manhã e você encontra links mortos. Baixe no handler de conclusão, no passo que marca a linha como done.

Uma convenção de nomes em que dá para buscar

Renomeie cada arquivo no download para a sua job key, por exemplo spring-launch_hook-07_kling3_v2.mp4, e guarde a referência do provedor no manifesto. A Aitachyon dá a cada arquivo gerado uma ref estável (img_, scn_, vo_ e assim por diante) que o código pode buscar a qualquer momento com GET /api/generations/{ref}; assim a ref é a alça duradoura e o arquivo local é a sua cópia de trabalho. Com os dois no manifesto, uma pergunta como "qual prompt gerou o hook que venceu em março" vira um grep.

A dependência do provedor também é um risco do lote

O guia da OpenAI agora registra que os modelos Sora 2 e a Videos API foram descontinuados em 24 de setembro de 2026. Pipelines ligados a esse endpoint tiveram de ser reescritos. Com o modelo mantido como parâmetro do manifesto, uma descontinuação custa uma mudança de configuração.

Controle de custo por chave e lotes conduzidos por um agente

Um script com bug e saldo ilimitado é a combinação cara. A Replicate aplica limites progressivamente mais rígidos conforme o crédito diminui e recomenda manter o saldo acima de $20 com recarga automática, enquanto contas sem forma de pagamento ficam limitadas a 1 requisição por segundo. Suas próprias proteções devem ficar por cima:

Proteções de gasto para execuções sem supervisão

1. Uma chave de API por pipeline. O job noturno de shorts, o script de variantes de anúncio e a sessão do seu agente recebem cada um a sua chave, de modo que o gasto seja atribuível. Na Aitachyon cada chave tem o próprio gasto, um alerta quando gasta de forma incomumente rápida e revogação com um clique.
2. Um teto pré-pago. Um saldo pré-pago é, por construção, um limite rígido. O saldo da Aitachyon nunca expira, então recarregar para uma execução grande não cria pressão de usar ou perder. A comparação entre créditos e pagamento por chamada mostra onde cada modelo perde dinheiro.
3. Uma checagem de orçamento no código. O total do manifesto, conferido antes da execução e de novo a cada 50 jobs contra o gasto real.
4. Um botão de emergência. Se o alerta por chave disparar, revogue a chave. Os workers falham rápido em erros de autenticação, que é o que você quer.

O mesmo lote, conduzido por um agente

Cada vez mais, é um agente de código que escreve e roda o script. Com um servidor MCP hospedado conectado ao Claude Code ou ao Cursor, você descreve o lote ("vinte hooks de 5 segundos a partir destes prompts no Hailuo 02, salvos em ./hooks e nomeados pelo número do hook") e o agente envia, espera, baixa e reporta cada arquivo com seu custo. Conectar o Claude Code à Aitachyon é um único comando:

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

As execuções de agente pedem as mesmas proteções: uma chave dedicada, um orçamento declarado no prompt e o manifesto gravado em disco conforme avança. O passo a passo sobre gerar vídeo a partir do Claude Code via MCP mostra a configuração, e uma configuração de agente que funciona para produção de vídeo explica como encadear roteiros, clipes e voz até ter as peças prontas.

Checklist pré-execução de um lote em massa

Copie isto para o topo do seu script de lote ou do prompt do seu agente:

1. Manifesto escrito, uma linha por saída, job keys determinísticas.
2. Total estimado abaixo do orçamento.
3. Uma chave de API dedicada com alertas de gasto.
4. Workers limitados ao teto de concorrência.
5. Backoff com full jitter, Retry-After respeitado, no máximo três tentativas.
6. Envios com timeout checados antes de qualquer reenvio.
7. Handler de webhook ou polling lento, idempotente nos dois casos.
8. Download e renomeação na conclusão.
9. Um lote de teste de cinco, rodado de ponta a ponta.
10. Script de conciliação pronto.

O lote de teste é o passo que as pessoas pulam e o mais barato: no Hailuo 02, no momento em que escrevo, cinco clipes de 5 segundos custam $2.13, e eles pegam a proporção de tela errada antes que ela custe trezentas vezes mais.

Perguntas frequentes

Eu pago pelas gerações de vídeo com IA que falham?

Depende do provedor. A fal não cobra requisições que falham com erro 5xx, e a Aitachyon reembolsa automaticamente os renders com falha, ao centavo. Nos dois casos, concilie suas cobranças detalhadas com a lista de jobs depois de cada execução, porque um envio duplicado por um retry ruim é um job bem-sucedido que você pagou.

Por quanto tempo os arquivos de vídeo gerados ficam disponíveis?

Muitas vezes, pouco. A Replicate apaga os arquivos de saída da API após uma hora, e as URLs de download de vídeo da OpenAI duravam no máximo uma hora. Baixe cada arquivo assim que o job terminar e guarde com seu próprio nome. Na Aitachyon, cada saída também tem uma ref estável que você pode buscar depois com GET /api/generations/{ref}.

Quanto custa gerar 100 vídeos curtos com IA?

Para 100 clipes de cinco segundos nos preços da Aitachyon no momento em que escrevo, são $42.50 no Hailuo 02, $80 no Kling v3 sem áudio e $100 no Seedance 2.5 em 480p. Divida pela sua taxa de aproveitamento para obter o custo por clipe utilizável.

Fontes

1. Replicate: rate limits
2. Replicate: arquivos de saída
3. Replicate: webhooks
4. fal: limites de concorrência
5. fal: inferência assíncrona e fila
6. fal: confiabilidade
7. Leonardo.Ai: guia de concorrência, fila e rate limit
8. Vidu: uso e limites
9. Stripe: requisições idempotentes
10. AWS Architecture Blog: exponential backoff e jitter

Se você quer rodar esse tipo de lote sem abrir uma conta separada para cada modelo, a Aitachyon reúne Seedance, Kling, Veo, Hailuo, os modelos de imagem e a voz da ElevenLabs atrás de uma única chave, utilizável por uma API HTTP ou pelo servidor MCP hospedado, com cada job detalhado, renders com falha reembolsados e gasto acompanhado por chave. O guia rápido de API e MCP explica a configuração.