LTX-2.5, de 22.000 millones de parámetros, funciona en una RTX 3080 de 10 GB, pero tarda 5 minutos por plano

Un autor de Habr ha ejecutado en local el modelo de vídeo LTX-2.5, de 22.000 millones de parámetros, en una tarjeta RTX 3080 con 10 GB de memoria. Solo el transformer pesa 39 GB, y el codificador de texto Gemma ocupa otros 24,5 GB. El modelo funciona bajo Windows y está integrado en un flujo de trabajo para vídeos verticales de 6–8 planos. Pero la poca memoria de vídeo se pagó con memoria RAM, tiempo de carga y complicaciones con el entorno.

La tarea del autor es práctica: en un solo ordenador trabaja por turnos una cadena entera de modelos. Gemma, a través de llama.cpp, ayuda con el guion, FLUX.2 [klein] dibuja fotogramas con el rostro constante del protagonista y LTX-2.5 da vida a esos fotogramas. Después, Qwen3-TTS genera la voz, ACE-Step la música y ffmpeg se encarga del montaje. LTX recibe una imagen ya terminada y la convierte en un plano de vídeo corto.

Cómo pasan 39 GB de pesos por 10 GB de memoria de vídeo

El autor usa la versión distilled de LTX-2.5, que genera el vídeo en dos etapas. Primero se hacen 8 pasos de denoising en baja resolución (unos 1,4 s por paso). Después, un escalador latente amplía el resultado al doble y se ejecutan otros 3 pasos a resolución completa de 576×1024 (unos 5 s por paso). El autor califica estos tiempos de observaciones preliminares, no de un benchmark reproducible.

En el pipeline estándar de Lightricks/LTX-2 bastan dos parámetros. `--quantization fp8-cast` guarda los pesos en bf16 y los convierte a fp8 al cargarlos en la GPU: se necesita la mitad de memoria y no hace falta un checkpoint fp8 aparte. `--offload cpu` activa el modo de streaming: los bloques del transformer permanecen en la RAM y se envían a la tarjeta de uno en uno. Para los planos largos hizo falta además la variable `PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True`; sin ella, la fragmentación de memoria provocaba errores OOM.

La memoria, sin embargo, no desaparece, sino que se traslada de la tarjeta a la RAM. Según la estimación del autor, este esquema exige al menos 32 GB de RAM (mejor 64) y un archivo de paginación de 32 GB o más. Por eso la frase «funciona con 10 GB» no basta para describir los requisitos.

Dos trampas: safetensors en

Windows y una descarga que no descarga

La primera ejecución terminó con un access violation al abrir los pesos, sin un mensaje claro. En el entorno del autor, la biblioteca safetensors intentaba mapear en memoria de una vez los archivos de más de unos 2 GB y fallaba. La solución es sustituir safe_open: la cabecera del archivo se analiza a mano y los tensores se entregan como vistas sobre un np.memmap de solo lectura. La interfaz no cambia, así que el pipeline de LTX no nota nada, y ninguna copia aparte de los pesos consume memoria commit. El parche se engancha sin tocar código ajeno: el archivo está en site-packages y un archivo .pth con `import ltx_sft_patch` sustituye el módulo al arrancar el intérprete.

El segundo problema surgió al trabajar los modelos juntos. Al principio cada uno vivía en un proceso worker permanente y, tras usarlo, se descargaba con una llamada unload. Con CPU offload, parte de la VRAM y de la RAM fijada seguía ocupada después, y el siguiente modelo no cabía. La solución fiable fue terminar el proceso por completo. Ahora cada modelo funciona en su propio proceso y su propio venv, y LTX lanza un proceso distinto para cada plano. Beneficio secundario: los modelos requieren versiones incompatibles de torch y diffusers, y los entornos aislados evitan que se estorben.

Dónde se va realmente el tiempo

Los reinicios tienen un coste. Según mediciones preliminares, cada plano tarda unos cinco minutos, y el denoising en sí ocupa unos 25 segundos. Esto concuerda con la aritmética de los pasos: 8 por 1,4 s más 3 por 5 s dan unos 26 segundos. El resto del tiempo se gasta en leer y preparar unos 65 GB de pesos del transformer y del codificador Gemma, y se repite para cada plano.

La conclusión para quien monte un flujo parecido: antes de comprar una tarjeta más rápida, conviene medir la velocidad de carga de los pesos y el uso de memoria. Un vídeo de 6 planos se monta en media hora aproximadamente; uno corto, en unos minutos. El autor ve como siguiente paso mantener el codificador y el transformer en memoria entre planos, pero esa opción aún está por comprobar.

Por separado, el autor comparte trucos para sortear las debilidades del modelo. El fotograma inicial debe mostrar el estado previo a la acción: si la puerta ya está abierta y el prompt pide abrirla, el modelo se ve obligado a inventar lo que ocurre. El contacto de las manos con los objetos es mejor repartirlo en dos planos: en el primero la mano se estira; tras el corte, la puerta ya está abierta y el momento dudoso queda fuera de plano.

Si importa el final del movimiento, el fotograma final puede pasarse como segundo `--image`. Para la sincronización labial hace falta otro esquema: el modelo completo, no distilled, un LoRA distilled y la rama de audio a2vid_two_stage; del resultado solo se toma el vídeo, y el sonido sigue siendo el de la locución.

En resumen: un modelo de 22B en una tarjeta doméstica de 10 GB resultó una opción viable para vídeos cortos. Todo se ejecuta en local, sin nube ni suscripciones, pero a costa de mucha RAM, cargas largas y configuración manual del entorno.