Fluxo de trabalho da API de imagem para vídeo: Runway, Wan 2.7, Vidu e padrões de API em produção

Você tem uma imagem estática — uma renderização de produto, um visual principal aprovado, uma folha de personagem — e precisa fazê-la se mover. Não gerar uma cena nova parecida, mas fazer aquele quadro se mover. É exatamente isso que a imagem para vídeo (i2v) faz, e é um tipo de integração completamente diferente de "inserir um prompt e torcer para o modelo desenhar o que você tem em mente". Este é o artigo prático: preparar a imagem de origem, controlar onde o movimento começa e termina, escrever prompts que conduzam a animação em vez de redescrever a cena, e lidar com polling e callbacks para que uma renderização de vários minutos não derrube seu backend.

Ainda está em dúvida sobre se deve usar i2v em vez de texto para vídeo? Este artigo assume que você já decidiu e quer usar i2v bem.

Quando a imagem para vídeo é adequada

Use i2v quando o quadro inicial não é negociável. O modelo não está criando o sujeito do zero; ele recebe sua imagem e adiciona movimento, então qualquer coisa que precise permanecer consistente com a marca ou com a forma recebe uma garantia que o texto para vídeo não pode oferecer — imagens de produto de SKUs reais, transformar um visual principal aprovado em um loop de cabeçalho, folhas de personagem que mantêm a consistência facial, ou efeitos antes→depois com quadros inicial e final fixos, deixando o modelo preencher a transição. Se o sujeito é flexível, o texto para vídeo geralmente dá menos trabalho. O valor central do i2v é justamente o fato de a imagem estática ser fixa.

O cenário da imagem para vídeo em 2026

O campo do i2v é competitivo e de nível elevado. Vale conhecer como contexto, embora o fluxo de trabalho invocável abaixo rode sobre um conjunto selecionado de modelos:

• Runway Gen-4 / Gen-4.5. O sucessor do Gen-3 Alpha; impulsionou a "consistência de mundo" entre planos, além de movimento baseado em física e movimentos de câmera deliberados. O i2v do Gen-4.5 é amplamente considerado a melhor escolha para controle criativo rigoroso em anúncios ou entregáveis para clientes (Runway Research, "Introducing Runway Gen-4," 2026; resumo de modelos do ZNIX, 2026). O Gen-4.5 imagem para vídeo também já está disponível no HiAPI, com o ID de modelo runway-gen-4.5/image-to-video; veja o guia da API do Runway Gen-4.5.
• Vidu Q3. Construído em torno do condicionamento de primeiro e último quadro — quadro inicial, quadro final desejado, mudança de prompt, e ele preenche o meio — com suporte a até 16 segundos em 1080p com áudio (Vidu, "AI Image to Video," 2026).
• Kling 3.0. Excelente em gerar movimentos humanos complexos a partir de uma imagem estática de referência, com suporte nativo a 4K e sincronização labial (TeamDay.ai, "Best AI Video Models 2026," 2026).
• Seedance 2.0. Modelo da ByteDance (12 de fevereiro de 2026) capaz de manter detalhes de produto, logotipos e textos estáveis entre quadros — exatamente o que o i2v de e-commerce precisa (opencreator.io, "AI Video Models Comparison 2026," 2026).

O padrão entre os modelos fortes é consistente: o controle do primeiro quadro é requisito básico, o controle do último quadro deixou de ser raridade, e ancorar as duas pontas é o método mais confiável para evitar que o clipe derive no último segundo. O fluxo de trabalho abaixo é construído em torno desse princípio. No HiAPI, os dois modelos i2v que você pode invocar são Seedance 2.0 (ByteDance) e Wan 2.7 Imagem para Vídeo (Alibaba).

Etapa 1 — Preparar a imagem de origem

Esta é a etapa que as pessoas costumam pular e depois culpam o modelo. Com i2v, seu primeiro quadro é o teto de qualidade. Antes de enviar qualquer coisa, três coisas precisam estar certas:

• Combine a proporção com a saída. Renderizar a origem em 4:3 mas pedir um clipe em 16:9 obriga o modelo a cortar ou preencher — você perde o controle sobre o que será mantido no final. Defina primeiro a proporção de saída e depois produza a imagem estática nessa proporção. O Seedance também aceita a proporção adaptive, que corresponde automaticamente às dimensões da imagem de origem.
• Renderize na resolução de saída desejada. Uma origem em 480p não se transforma em um clipe nítido em 1080p; ampliar uma entrada desfocada só faz a desfocagem se mover.
• Enquadre o sujeito de forma limpa. Um sujeito nítido e sem bagunça faz o modelo errar menos. Fundos confusos e bordas desfocadas são a origem de movimentos estranhos.

Depois, hospede-a. A API recebe a imagem de origem como URL (first_frame_url), não como upload de arquivo, então ela precisa estar acessível via HTTPS — seu bucket, CDN, armazenamento de objetos assinado. Um caminho localhost ou um link que a API não consiga buscar fará a tarefa falhar.

Etapa 2 — Enviar a tarefa com o primeiro quadro

No HiAPI, todo modelo (inclusive vídeo) roda por uma API de tarefas assíncrona. Você cria uma tarefa, recebe imediatamente um taskId, e a renderização acontece no servidor. Transformar texto para vídeo em imagem para vídeo exige apenas um campo: adicionar first_frame_url. Abaixo está a chamada mínima, usando Seedance 2.0:

curl -X POST https://api.hiapi.ai/v1/tasks \
  -H "Authorization: Bearer sk-<your-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "seedance-2-0",
    "input": {
      "prompt": "Slow cinematic push-in, a soft light sweep travels across the surface, the subject holds steady and in focus",
      "first_frame_url": "https://cdn.your-domain.com/assets/product-front.jpg",
      "aspect_ratio": "16:9",
      "duration": 5,
      "resolution": "720p",
      "generate_audio": false
    }
  }'

Essa é a requisição completa de imagem para vídeo. Campos de entrada importantes:

• first_frame_url — a imagem estática a ser animada; sua presença é o que define o i2v.
• aspect_ratio — corresponde à imagem de origem (ou use adaptive).
• duration — segundos de saída; mais longo custa mais e também dá mais espaço para o movimento derivar.
• resolution — 480p / 720p / 1080p; o principal ajuste de custo.
• generate_audio — desligue para loops silenciosos e imagens de produto.

A estrutura completa de requisição e resposta está na documentação. O Wan 2.7 Imagem para Vídeo segue o mesmo fluxo de criar-consultar-baixar, mas suas entradas são diferentes — ele carrega os quadros de origem no array media e gera em 720p ou 1080p — então consulte a documentação para sua estrutura exata em vez de reaproveitar diretamente o corpo da requisição do Seedance.

Etapa 3 — Adicionar o último quadro quando o final importa

O controle do primeiro quadro define onde o clipe começa e deixa o modelo decidir como terminar — é aí que a deriva aparece silenciosamente, porque o modelo está improvisando a segunda metade. Se a continuidade com o último quadro for importante, fixe também ele:

{
  "model": "seedance-2-0",
  "input": {
    "prompt": "The product rotates a quarter turn and settles, light resolving to a clean studio key",
    "first_frame_url": "https://cdn.your-domain.com/assets/product-front.jpg",
    "last_frame_url": "https://cdn.your-domain.com/assets/product-three-quarter.jpg",
    "aspect_ratio": "16:9",
    "duration": 5,
    "resolution": "720p"
  }
}

Agora as duas extremidades estão fixas, e o modelo preenche apenas o movimento entre elas. Esse é o padrão principal para revelações de produto e transições antes→depois, e a correção única mais eficaz para o problema de "o clipe fica ótimo até o último segundo". Mantenha os dois quadros com o mesmo sujeito e composição — se as imagens de início e fim forem muito diferentes, o modelo precisará inventar um caminho entre elas, e você volta ao território do chute.

Etapa 4 — Escrever prompts de movimento para imagens estáticas

Os prompts têm uma função diferente no i2v, e errar isso desperdiça renderizações. No texto para vídeo, o prompt constrói a cena inteira. Na imagem para vídeo, o modelo já vê a cena — ela está no quadro que você forneceu —, então o papel do prompt é a mudança ao longo do tempo, não o conteúdo:

• Comece pelo movimento de câmera. "Slow dolly-in", "gentle pan left", "push-in then hold". Modelos de movimento seguem bem verbos de câmera; forneça um explicitamente.
• Descreva como o sujeito se move, não o que ele é. "Steam begins to rise", "the fabric sways", "the screen wakes and glows". Você está coreografando a animação, não enumerando objetos de novo.
• Não redescreva a cena. Reafirmar o que já é óbvio na imagem de origem briga com o modelo e pode puxá-lo para regenerar em vez de animar.
• Faça o movimento caber na duração. Um clipe de 5 segundos não comporta uma história de 20 segundos.

Um bom prompt de i2v soa como uma instrução de ação para um cinegrafista, não como a descrição de uma cena para um pintor.

Etapa 5 — Consultar por polling ou receber callback

Vídeo consome minutos de GPU, não milissegundos. A renderização é projetada como assíncrona justamente para nunca manter a conexão aberta. Depois de criar a tarefa, você tem duas formas de saber que ela terminou.

Polling até um estado terminal — bom para scripts e protótipos:

curl https://api.hiapi.ai/v1/tasks/<taskId> \
  -H "Authorization: Bearer sk-<your-key>"
# data.status: queued -> handling -> archiving -> success (or fail)
# on success, read data.output[0].url and download it promptly — the URL expires

Callbacks funcionam para qualquer cenário além de protótipo. Em vez de ficar num loop de polling, forneça um callback e deixe o HiAPI enviar o estado terminal até você:

{
  "model": "seedance-2-0",
  "input": { "prompt": "...", "first_frame_url": "https://cdn.your-domain.com/assets/product-front.jpg", "aspect_ratio": "16:9", "duration": 5, "resolution": "720p" },
  "callback": { "url": "https://your-domain.com/hooks/hiapi", "when": "final" }
}

De qualquer forma, a URL de saída é temporária. Assim que a tarefa mudar para success, baixe imediatamente data.output[0].url para seu próprio armazenamento — não a incorpore por hotlink numa página nem a entregue ao cliente, pois ela expira.

Padrões de produção que resistem

Alguns hábitos separam um script de demonstração de algo que roda em escala:

• Prefira callbacks a polling em escala. Um loop de polling por tarefa é desperdício de computação e pressão de rate limiting. Um endpoint de callback que baixa o resultado e atualiza seu registro escala muito melhor do que centenas de pollers.
• Torne o envio idempotente. Retentativas e callbacks entregues ao menos uma vez acontecem. Use um ID estável por renderização (imagem de origem + prompt + parâmetros, com hash), para que uma retentativa não gere silenciosamente — e cobre — um clipe duplicado.
• O custo é resolução × duração. Vídeo é cobrado por segundo, e a tarifa sobe com a resolução, então um clipe de 10 segundos em 1080p é muito mais caro que um de 5 segundos em 480p. Itere em 480p, trave o prompt e a câmera, e só então re-renderize os clipes aprovados na resolução de entrega. Veja as tarifas em tempo real na página de preços — elas mudam, então não as hardcode no código.
• Orce por clipes aproveitáveis, não por renderizações. Se você mantém um em cada três clipes, seu custo real por ativo entregável é o triplo do preço de tabela — é essa razão, não a tarifa por segundo, que define seu orçamento, e é por isso que travar o prompt em 480p se paga.
• Valide cedo a URL de origem. Um primeiro quadro que a API não consegue buscar é a falha evitável mais comum — verifique se ele está acessível via HTTPS antes de enviar.

Perguntas frequentes

Na requisição, qual a diferença entre imagem para vídeo e texto para vídeo? Um campo. A chamada da tarefa é idêntica em todo o resto; adicionar first_frame_url (a imagem de origem) a transforma de texto para vídeo em imagem para vídeo. No HiAPI, ambas rodam pelo mesmo endpoint POST /v1/tasks.

Posso controlar o primeiro e o último quadro ao mesmo tempo? Sim. first_frame_url fixa o quadro inicial; adicionar last_frame_url fixa o quadro final, de modo que o modelo preenche apenas o movimento entre as duas extremidades fixas. Fixar as duas pontas é o método mais confiável para controlar transições e evitar que o clipe derive no final.

As APIs do Runway Gen-3/Gen-4 suportam imagem para vídeo? As séries Gen-3 e Gen-4 do Runway suportam imagem para vídeo e se destacam em controle cinematográfico — esse é o cenário mais amplo. O fluxo de trabalho invocável deste guia roda sobre Seedance 2.0 e Wan 2.7 Imagem para Vídeo, que o HiAPI hospeda por trás de uma única API de tarefas. O Runway Gen-4.5 Imagem para Vídeo roda na mesma API; há um exemplo de requisição funcional no guia da API do Runway Gen-4.5.

Quanto tempo leva uma renderização de imagem para vídeo? Minutos, não segundos — vídeo é computação de verdade. É por isso que a API é assíncrona: você cria a tarefa e depois consulta ou recebe um callback, de modo que uma renderização longa nunca bloqueia sua requisição.

Resumo dos pontos principais

A imagem para vídeo se aplica quando uma imagem estática específica precisa aparecer na tela exatamente como é e então se mover. O teto de qualidade é determinado antes de você escrever o primeiro prompt, pela resolução, proporção e composição da imagem de origem — então prepare-a primeiro e hospede-a num local estável. Fixe o primeiro quadro para controlar onde o clipe começa, adicione o último quadro quando o final precisar ser entregue, e escreva prompts como direção de movimento e câmera, em vez de redescrever o que o modelo já consegue ver. Depois trate o processo como a tarefa assíncrona que ele é: faça polling, ou melhor, receba callbacks; torne o envio idempotente; baixe antes que a URL expire; e orce por clipes aproveitáveis na resolução de entrega.

Quando estiver pronto, rode a imagem de origem pela página do modelo Seedance 2.0 ou pelo Wan 2.7 Imagem para Vídeo, conecte-se à API de tarefas acima e confira as tarifas por segundo em tempo real na página de preços antes de escalar. (Prefere primeiro uma opção sem chave? Veja as opções gratuitas de texto para vídeo.)