Viggle abre duas LoRA para o MiniMax-H3: troca de pessoas em vídeo roda a partir de 12 GB de VRAM

A Viggle publicou o Viggle Remake, um par de LoRA abertas, ou seja, adaptadores compactos para o modelo de vídeo MiniMax-H3. Elas refazem um vídeo pronto e preservam o que costuma quebrar na edição generativa: movimento, posição da câmera, timing e som vêm do vídeo original. Só muda o que você desenhou explicitamente nos quadros-chave. Os adaptadores podem rodar localmente: no ComfyUI, basta uma placa de vídeo com 12 GB de memória (VRAM), em resolução 832×480 e com pesos quantizados Q4_K_M ou Q8_0. Os pesos estão no HuggingFace, e quem não tem hardware próprio pode testar o modelo no aplicativo da Viggle.

Dois modos e como trabalhar com eles

O conjunto tem dois adaptadores. O Swap cuida da substituição de pessoas e personagens, um só ou vários de uma vez. O Edit assume todo o resto: objetos, fundo, clima, iluminação e estilo.

As duas LoRA foram treinadas com rank 256 no transformer do H3, e cada uma pesa 2,67 GB. Para quem tem pouco espaço em disco ou pouca memória, há versões low-rank de 1,34 e 0,67 GB. Segundo os autores, a qualidade delas é quase a mesma.

A entrada é composta pelo vídeo original, de um a quatro quadros “desenhados” e um prompt de texto. O fluxo de trabalho é simples: você pega um quadro do vídeo-fonte e o retoca em qualquer editor, inserindo um novo herói, removendo um objeto indesejado ou acrescentando uma tempestade. O modelo transfere desses quadros a aparência e o estilo, e pega o movimento e a câmera do vídeo original.

Para projetos longos, a Viggle lançou um servidor MCP. Com ele, um agente baseado em Claude Code ou Codex divide o filme em janelas, desenha os quadros-chave, renderiza os trechos e os junta com o som.

O que é preciso em hardware

No ComfyUI, basta o pacote de nodes da Viggle: ele vai em custom_nodes, e as LoRA em models/loras. Os workflows prontos para swap e edit estão no repositório. As recomendações de VRAM são estas:

• 12 GB — Q4_K_M ou Q8_0 com a flag --reserve-vram 8, resolução 832×480;
• 16 GB — int8 sem flags adicionais, 832×480;
• 24 GB — int8 ou Q4 em 832×480; para 1280×736, é preciso Q4 ou Q8 com --reserve-vram 20;
• 48 GB — Q8_0 em 1280×736;
• 80 GB — bf16 junto com a LoRA.

A RAM necessária é de 47–55 GB em 832×480 e de 55–80 GB em 1280×736. Para bf16 em 1280×736, são necessários 127 GB. Uma ressalva importante: as configurações de 12–24 GB foram testadas por emulação em uma B200, e não em placas de consumo reais, então as flags podem ser diferentes em hardware de verdade.

Duração do clipe e velocidade

Uma janela comporta de 90 a 345 quadros. O parâmetro --frames é escolhido pela fórmula 17n+5, e os desenvolvedores recomendam não passar de 294 quadros, o que dá cerca de 12 segundos a 24 quadros por segundo. Vídeos mais longos precisam ser divididos em janelas, e essa tarefa repetitiva fica por conta do servidor MCP.

Nas medições em uma B200, um vídeo 832×480 de 226 quadros renderiza em cerca de 95 segundos no ComfyUI e em 58 segundos pelo script sample.py. A primeira execução no ComfyUI leva de 2,5 a 3 minutos. Em 1280×736, a renderização se estende para 510–585 segundos.

O que isso muda na prática

O ponto central do lançamento é a divisão de papéis. Movimento, câmera e som vêm da filmagem real, e a rede neural cuida apenas da substituição visual. Para editores e para quem produz publicidade e videoclipes, isso é mais prático do que gerar o vídeo inteiro do zero: o ritmo e a composição dos quadros não se perdem.

Os tempos foram medidos em uma B200, então em placas domésticas a renderização será bem mais lenta. Por outro lado, a barreira de entrada começa em 12 GB de VRAM e nas variantes quantizadas do modelo, de modo que a ferramenta não fica restrita a estúdios com GPUs de servidor. Os detalhes sobre prompting e configuração do ComfyUI estão em guias separados no repositório.