LTX-2.5 de 22 bilhões de parâmetros roda em RTX 3080 de 10 GB, mas leva 5 minutos por plano

O autor de um estudo no Habr rodou localmente o modelo de vídeo LTX-2.5, de 22 bilhões de parâmetros, numa placa de vídeo RTX 3080 com 10 GB de memória. Só o transformer pesa 39 GB, e o codificador de texto Gemma ocupa outros 24,5 GB. O modelo roda no Windows e está integrado a um pipeline de vídeos verticais com 6 a 8 planos. Mas, para compensar o pouco espaço de VRAM, foi preciso pagar com memória RAM, tempo de carregamento e muito trabalho com o ambiente.

A tarefa do autor é prática: uma cadeia inteira de modelos trabalha em sequência num único computador. O Gemma, via llama.cpp, ajuda com o roteiro; o FLUX.2 [klein] desenha os quadros com o rosto do personagem constante; o LTX-2.5 dá vida a esses quadros. Depois, a voz fica por conta do Qwen3-TTS, a música do ACE-Step e a edição do ffmpeg. O LTX recebe a imagem pronta e a transforma em um plano de vídeo curto.

Como 39 GB de pesos passam por 10 GB de VRAM

O autor usa a versão distilled do LTX-2.5, em que o vídeo é gerado em duas etapas. Primeiro vêm 8 passos de denoising em baixa resolução (cerca de 1,4 s por passo). Em seguida, um upscaler latente dobra o resultado, e mais 3 passos rodam na resolução total de 576×1024 (cerca de 5 s por passo). O autor chama esses tempos de observações preliminares, e não de um benchmark reproduzível.

No pipeline padrão do Lightricks/LTX-2, duas opções bastam para isso. O parâmetro --quantization fp8-cast mantém os pesos em bf16 e, ao carregá-los na GPU, converte-os para fp8: é preciso metade da memória, e não há necessidade de um checkpoint fp8 separado. O parâmetro --offload cpu ativa o modo de streaming: os blocos do transformer ficam na RAM e são enviados à placa de vídeo um a um. Para planos mais longos, foi preciso ainda a variável PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True; sem ela, a fragmentação de memória causava erros de OOM.

A memória, no entanto, não desaparece: ela migra da placa de vídeo para a RAM. Pela estimativa do autor, esse esquema exige no mínimo 32 GB de RAM (o ideal é 64) e um arquivo de paginação de pelo menos 32 GB. Por isso, a frase «roda com 10 GB» não basta para descrever os requisitos.

Duas armadilhas: safetensors no

Windows e o descarregamento que não descarrega

A primeira execução terminou em access violation ao abrir os pesos, sem uma mensagem clara. No ambiente do autor, a biblioteca safetensors tentava mapear inteiramente na memória arquivos maiores que cerca de 2 GB e falhava. O contorno foi substituir o safe_open: o cabeçalho do arquivo é analisado manualmente, e os tensores são entregues como views sobre um np.memmap somente leitura. A interface continua a mesma, então o pipeline do LTX não percebe nada, e uma cópia separada dos pesos não consome commit memory. O patch é aplicado sem alterar código de terceiros: o arquivo fica em site-packages, e um arquivo .pth com import ltx_sft_patch substitui o módulo na inicialização do interpretador.

O segundo problema surgiu no trabalho conjunto dos modelos. No início, cada um vivia num processo worker permanente e era descarregado com a chamada unload após o uso. No esquema com CPU-offload, parte da VRAM e da RAM fixada (pinned) continuava ocupada depois disso, e o modelo seguinte não cabia. A solução confiável foi encerrar o processo por completo. Agora cada modelo roda em seu próprio processo e em seu próprio venv, e no LTX um processo separado é iniciado para cada plano. Um benefício colateral: os modelos exigem versões incompatíveis de torch e diffusers, e os ambientes isolados impedem que um atrapalhe o outro.

Onde o tempo realmente vai

Os reinícios têm custo. Pelas medições preliminares, cada plano leva cerca de cinco minutos, e o denoising em si ocupa aproximadamente 25 segundos. Isso bate com a conta dos passos: 8 vezes 1,4 s mais 3 vezes 5 s dão cerca de 26 segundos. O resto do tempo vai para a leitura e a preparação de aproximadamente 65 GB de pesos do transformer e do codificador Gemma, e isso se repete a cada plano.

A conclusão para quem monta um pipeline semelhante: antes de comprar uma placa de vídeo mais rápida, vale medir a velocidade de carregamento dos pesos e o uso de memória. Um vídeo de 6 planos fica pronto em cerca de meia hora; um vídeo curto, em alguns minutos. O autor vê como próximo passo manter o codificador e o transformer na memória entre os planos, mas essa opção ainda precisa ser testada.

Separadamente, o autor compartilha truques contra as fraquezas do modelo. O quadro inicial deve mostrar o estado anterior à ação: se a porta já está aberta e o prompt pede para abri-la, o modelo precisa inventar o que acontece. O contato das mãos com objetos é melhor dividir em dois planos: no primeiro, a mão se estende; após a emenda, a porta já está aberta, e o momento duvidoso fica fora de quadro.

Se o final do movimento importa, o quadro final pode ser passado como um segundo --image. Para lip-sync é preciso outro esquema: o modelo completo, não o distilled, o distilled-LoRA e a ramificação de áudio a2vid_two_stage, e do resultado só se aproveita o vídeo, enquanto o som continua sendo o da locução.

Resumo: um modelo de 22B numa placa doméstica de 10 GB mostrou-se uma opção viável para vídeos curtos. Tudo roda localmente, sem nuvem nem assinaturas, mas ao custo de muita RAM, carregamento demorado e configuração manual do ambiente.