Ejecutan un modelo de vídeo de 22.000 millones de parámetros en una RTX 3080 con 10 GB de memoria

El propietario de una RTX 3080 con 10 GB de VRAM ha conseguido ejecutar en su equipo el modelo de vídeo LTX-2.5, de 22.000 millones de parámetros, es decir, 22.000 millones de números entrenables o pesos. Solo el transformer, la parte principal del modelo, ocupa 39 GB, y el codificador de texto Gemma suma otros 24,5 GB. Sobre el papel, este conjunto no cabe en una tarjeta de diez gigabytes. En la práctica funciona, pero a costa de RAM, de tiempo y de pelearse con el entorno. El autor califica todas las mediciones de tiempo del artículo como observaciones preliminares, no como un benchmark reproducible.

Cómo 65 GB de pesos pasan por 10 GB de VRAM

El autor monta vídeos verticales a partir de 6–8 planos. En un mismo ordenador trabajan varios modelos por turnos:

• Gemma, a través de llama.cpp, ayuda con el guion; • FLUX.2 [klein] dibuja los fotogramas con el mismo rostro del protagonista; • LTX-2.5 da movimiento a los fotogramas; • Qwen3-TTS pone la voz; • ACE-Step genera la música; • ffmpeg hace el montaje.

LTX recibe una imagen ya terminada y la convierte en un plano de vídeo corto. El autor usa la versión distilled, es decir, simplificada y más rápida. La generación se hace en dos etapas. Primero, 8 pasos de denoising (limpieza gradual del ruido de la imagen) en baja resolución, a unos 1,4 s por paso. Después, un upscaler latente duplica el resultado. A continuación vienen otros 3 pasos en resolución completa, 576×1024, a 5 s por paso.

Todo esto cabe en memoria gracias a dos opciones del repositorio Lightricks/LTX-2:

• --quantization fp8-cast: los pesos se almacenan en bf16 y se convierten a fp8 al cargarlos en la GPU. Hace falta la mitad de memoria y no se necesita un checkpoint fp8 aparte. • --offload cpu: los bloques del transformer permanecen en la RAM y se envían a la tarjeta gráfica de uno en uno, según se van calculando. • La variable PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True elimina los errores de falta de memoria causados por la fragmentación en planos largos.

La memoria no desaparece, sino que se traslada. Se necesitan al menos 32 GB de RAM, mejor 64, y un archivo de paginación de 32 GB como mínimo. La frase «se ejecuta con 10 GB» sin estas salvedades induce a error.

Dos trampas: safetensors en

Windows y la memoria que no se libera

El primer arranque ni siquiera llegó a la generación. Terminó con un access violation (acceso inválido a memoria) al abrir los pesos, sin un mensaje claro. En el entorno del autor, la causa estaba en la lectura de archivos grandes en formato safetensors bajo Windows. La biblioteca intentaba mapear el archivo entero en memoria y fallaba con archivos de más de 2 GB aproximadamente.

Lo resolvió sustituyendo la función safe_open. En lugar de la lectura estándar, funciona un np.memmap de solo lectura. La cabecera del archivo se analiza a mano y los tensores se entregan como vistas sobre el archivo mapeado. No hay una copia aparte de los pesos en la memoria commit, la interfaz sigue igual y no hizo falta modificar el código de LTX. El parche está en site-packages, y un archivo .pth con import ltx_sft_patch sustituye el módulo al iniciarse el intérprete.

El segundo problema es la descarga de modelos. Al principio, cada modelo vivía en un proceso worker permanente: hacía su trabajo, se llamaba a unload y la tarjeta pasaba al siguiente. Pero con CPU-offload, tras esa descarga parte de la VRAM y de la RAM fijada (pinned) seguía ocupada, y el siguiente modelo no cabía. Solo funcionó de forma fiable terminar el proceso por completo. Ahora cada modelo tiene su propio proceso y su propio venv, y en el caso de LTX se lanza un proceso por cada plano. Los entornos separados resuelven además otro problema: los modelos necesitan versiones incompatibles de torch y diffusers.

Cinco minutos por plano, 25 segundos de cálculo

Reiniciar procesos tiene un precio. Según las mediciones preliminares, un plano tarda unos cinco minutos y el denoising en sí, unos 25 segundos, menos del 10 % del tiempo. El resto se va en leer y preparar unos 65 GB de pesos del transformer y del codificador Gemma. Esto se repite en cada plano.

Conclusiones para quien monte un pipeline parecido:

• El cuello de botella aquí es el disco y la RAM, no la GPU. Antes de comprar una tarjeta gráfica más rápida, conviene medir la velocidad de carga de los pesos y el consumo de memoria. • Un vídeo de seis planos se genera en aproximadamente media hora; uno corto, en unos minutos. • El siguiente paso de optimización sería mantener el codificador y el transformer en memoria entre planos. El autor aún no ha probado esta opción. Volvería a plantear el problema de liberar memoria para los demás modelos.

Aparte, el autor comparte algunos trucos para conseguir un movimiento aprovechable:

• 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 empieza a improvisar lo que ocurre. • El contacto de las manos con los objetos se divide en dos planos.

En el primero, la mano se acerca al tirador; tras el corte, la puerta ya está abierta. El momento en que los dedos atraviesan el tirador queda fuera de plano. • Si importa el final del movimiento, el último fotograma se pasa como segundo parámetro --image.

• Para el lipsync (sincronización de los labios con el habla) hace falta otro esquema: el modelo completo, no distilled, distilled-LoRA y la rama de audio a2vid_two_stage. Del resultado solo se toma el vídeo; el sonido sigue siendo el de la locución.

En resumen: un modelo de vídeo de 22.000 millones de parámetros en una tarjeta doméstica de 10 GB da un resultado utilizable para vídeos cortos. Todo en local, sin nube ni suscripciones. Las limitaciones son conocidas: mucha RAM, una carga de pesos larga en cada plano y entornos separados para cada modelo.