Cascata de modelos de vídeo: quando um recusa, o próximo entra

O ponto único de falha que ninguém trata como tal

Quem produz vídeo com IA amarrado a um único gerador tem um ponto único de falha, e ele falha por motivos banais.

O filtro de conteúdo do provedor interpreta mal a descrição de uma cena inofensiva e recusa. A fila está cheia e o pedido expira. A cota do mês acabou. O serviço oscila por vinte minutos. Nenhuma dessas situações é culpa do roteiro, e nenhuma delas deveria derrubar a produção inteira.

Numa peça montada com oito blocos, basta um bloco recusado para não haver peça.

O que é a cascata

Em vez de um gerador, uma ordem de geradores. O pedido vai para o primeiro; se ele não entregar, vai para o segundo, e assim por diante, com o mesmo prompt e o mesmo tempo de bloco.

Do lado de fora, o que se vê é um bloco de vídeo pronto. Do lado de dentro, pode ter sido a primeira tentativa ou a terceira.

Na peça de 58 segundos que produzimos, isso não foi hipótese: os oito blocos saíram de quatro modelos de vídeo diferentes, porque nem todos aceitaram todos os pedidos. Sem cascata, aquela peça não existiria — ou existiria com buracos.

A distinção que evita trocar de modelo à toa

Há uma diferença que parece pequena e não é: recusa não é lentidão.

Um modelo que recusou o pedido não vai entregar por insistência: cair para o próximo é certo. Mas um modelo que está simplesmente demorando ainda vai entregar. Se o tempo de espera for tratado como falha, a cascata troca de modelo no meio de um trabalho que ia dar certo — e paga duas vezes pelo mesmo bloco.

Foi exatamente esse o erro que nos custou uma produção inteira: o limite de espera estava em 300 segundos e as tarefas levavam 298. Dois segundos de folga. Os oito vídeos foram marcados como falha por tempo, um a um, e a peça não saiu — sem que nenhum modelo tivesse recusado nada.

A correção teve duas partes. A primeira foi dar espaço real ao limite de espera, com folga sobre o tempo observado. A segunda, mais importante: espera não conta como falha do modelo. Só recusa e erro contam.

Saúde, não banimento

Modelo que falha três vezes seguidas numa janela de horas é rebaixado na ordem de tentativa — vai para o fim da fila, não para fora dela.

A diferença importa. Provedor de vídeo oscila. Se a primeira sequência ruim tirasse o modelo do jogo para sempre, em poucas semanas a cascata estaria rodando só com as últimas opções, que costumam ser as piores. Rebaixar e deixar voltar preserva a qualidade média sem travar quando um serviço tem uma tarde ruim.

O que a cascata não resolve sozinha

Trocar de modelo cria um problema novo: cada um entrega o arquivo do seu jeito.

Resoluções diferentes, taxas de quadro diferentes, base de tempo diferente. Juntar isso sem reprocessar produz aquele defeito que já registramos: uma peça que deveria ter 55 segundos saiu com 101,7 segundos, lenta e fora de sincronia com a narração, porque os carimbos de tempo de um clipe foram lidos na escala do anterior.

Então a cascata vem acompanhada de duas obrigações:

1. Prompt com base comum — a mesma descrição de luz, lente e paleta em todos os blocos, para que a diferença entre modelos não vire diferença visual.
2. Normalização antes de juntar — todos os clipes reprocessados para um padrão único de resolução, taxa de quadros, cor e áudio.

Com as duas, quatro modelos numa peça passam despercebidos. Sem elas, um só já denuncia.

Por que isso é uma decisão de arquitetura

Dá para contornar recusa na mão: percebe que o bloco 5 falhou, abre outro serviço, gera de novo, baixa, converte, coloca no lugar. Funciona uma vez.

O que não funciona é fazer isso toda vez, para todo cliente, dentro do prazo. A cascata existe porque a produção precisa continuar quando um fornecedor diz não — e essa é uma decisão de como o sistema é montado, não um passo do manual.