Modelo de vídeo de 22 bilhões de parâmetros roda em uma RTX 3080 com 10 GB de memória

O dono de uma RTX 3080 com 10 GB de VRAM rodou na própria máquina o modelo de vídeo LTX-2.5, de 22 bilhões de parâmetros, isto é, 22 bilhões de números treináveis chamados pesos. Só o transformer, a parte principal do modelo, ocupa 39 GB, e o codificador de texto Gemma soma mais 24,5 GB. No papel, esse conjunto não cabe em uma placa de dez gigabytes. Na prática, funciona, mas cobra o preço em memória RAM, tempo e trabalho para acertar o ambiente. O autor trata todas as medições de tempo do texto como observações preliminares, e não como um benchmark reproduzível.

Como 65 GB de pesos passam por 10 GB de VRAM

O autor monta vídeos verticais com 6 a 8 planos. Vários modelos trabalham em sequência no mesmo computador:

• o Gemma, via llama.cpp, ajuda com o roteiro; • o FLUX.2 [klein] desenha os quadros com o mesmo rosto do personagem; • o LTX-2.5 dá movimento aos quadros; • o Qwen3-TTS faz a narração; • o ACE-Step cria a música; • o ffmpeg monta a edição final.

O LTX recebe uma imagem pronta e a transforma em um plano de vídeo curto. O autor usa a versão distilled, ou seja, simplificada e mais rápida. A geração ocorre em duas etapas. Primeiro, 8 passos de denoising (limpeza gradual do ruído da imagem) em baixa resolução, a cerca de 1,4 s por passo. Depois, um upscaler latente dobra o tamanho do resultado. Em seguida, mais 3 passos na resolução total de 576×1024, a 5 s por passo.

Tudo isso cabe na memória graças a duas flags do repositório Lightricks/LTX-2:

• --quantization fp8-cast: os pesos ficam armazenados em bf16 e, ao serem carregados na GPU, são convertidos para fp8. Isso exige metade da memória, e não é preciso um checkpoint fp8 separado. • --offload cpu: os blocos do transformer ficam na RAM e são enviados à placa de vídeo um por vez, conforme o cálculo avança. • A variável PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True elimina os erros de falta de memória causados por fragmentação em planos longos.

A memória, no entanto, não desaparece: ela muda de lugar. São necessários no mínimo 32 GB de RAM, de preferência 64, e um arquivo de paginação a partir de 32 GB. Dizer que o modelo "roda com 10 GB" sem essas ressalvas induz ao erro.

Dois tropeços: safetensors no

Windows e a memória que não é liberada

A primeira execução nem chegou à geração. Ela terminou com um access violation (acesso inválido à memória) ao abrir os pesos, sem nenhuma mensagem clara. No ambiente do autor, a causa estava na leitura de arquivos grandes no formato safetensors no Windows. A biblioteca tentava mapear o arquivo inteiro na memória e falhava com arquivos maiores que cerca de 2 GB.

Ele contornou o problema substituindo a função safe_open. Em vez da leitura padrão, entra em ação um np.memmap somente leitura. O cabeçalho do arquivo é interpretado manualmente, e os tensores são entregues como views sobre o arquivo mapeado. Não há cópia separada dos pesos na memória commit, a interface continua a mesma e não foi preciso alterar o código do LTX. O patch 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 é a descarga dos modelos. No início, cada modelo vivia em um processo worker permanente: terminava o trabalho, recebia um unload e liberava a placa para o próximo. Porém, com o CPU offload, depois dessa descarga parte da VRAM e da RAM pinada continuava ocupada, e o modelo seguinte não cabia. Só funcionava de forma confiável encerrar o processo por completo. Agora cada modelo tem seu próprio processo e seu próprio venv, e no caso do LTX um processo é iniciado para cada plano. Os ambientes separados também resolvem outro problema: os modelos exigem versões incompatíveis de torch e diffusers.

Cinco minutos por plano, 25 segundos de cálculo

Reiniciar processos tem um custo. Pelas medições preliminares, um plano leva cerca de cinco minutos, e o denoising em si leva aproximadamente 25 segundos, menos de 10% do tempo. O resto vai para a leitura e a preparação de cerca de 65 GB de pesos do transformer e do codificador Gemma. Isso se repete a cada plano.

Conclusões para quem monta um pipeline parecido:

• O gargalo aqui é o disco e a RAM, não a GPU. Antes de comprar uma placa de vídeo mais rápida, vale medir a velocidade de carregamento dos pesos e o consumo de memória. • Um vídeo de seis planos fica pronto em cerca de meia hora, e um mais curto leva alguns minutos. • O próximo passo de otimização é manter o codificador e o transformer na memória entre os planos. O autor ainda não testou essa opção. Ela traria de volta o problema de liberar memória para os outros modelos.

O autor também compartilha técnicas para obter um movimento aproveitável:

• 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 começa a inventar o que acontece. • O contato das mãos com objetos é dividido em dois planos.

No primeiro, a mão se estende até a maçaneta; depois do corte, a porta já está aberta. O momento em que os dedos atravessam a maçaneta fica fora do quadro. • Se o final do movimento importa, o último quadro é passado como segundo parâmetro --image.

• Para lip sync (sincronização dos lábios com a fala), é preciso outro esquema: o modelo completo, não distilled, a distilled-LoRA e o ramo de áudio a2vid_two_stage. Do resultado, aproveita-se apenas o vídeo, e o som continua sendo o da narração.

Balanço: um modelo de vídeo de 22 bilhões de parâmetros em uma placa doméstica de 10 GB entrega resultado utilizável para vídeos curtos. Tudo roda localmente, sem nuvem nem assinaturas. As limitações são conhecidas: muita RAM, carregamento demorado dos pesos a cada plano e ambientes separados para cada modelo.