Intenté Exprimir una RTX 3090 con el Modelo Dev Completo de LTX-2.3 — Reventó 4 Veces Seguidas
Hace poco decidí llevar mi RTX 3090 al límite ejecutando el modelo completo (no destilado) de LTX-2.3 en ComfyUI. La promesa era clara: más calidad de vídeo, más control sobre el proceso de generación. La realidad fue otra historia. Cuatro intentos, cuatro crashes, todos idénticos, todos en el mismo punto exacto de la ejecución. Lo interesante no fue que fallara, sino dónde y por qué falló.
Porque aquí viene el spoiler: mi GPU nunca se quedó sin memoria. El problema estaba completamente en otro lado. Y si tienes una RTX 3090 con 32 GB de RAM del sistema, probablemente enfrentes exactamente lo mismo.
De un vistazo: el problema en números
| Métrica | Valor |
|---|---|
| GPU disponible | RTX 3090 (24 GB VRAM) |
| RAM del sistema | 32 GB |
| RAM reservada por ComfyUI | 28.8 GB |
| RAM libre real | ~3.2 GB |
| VRAM usada en crashes | ~17-20 GB (sin saturación) |
| Punto de crash | Carga del VAE de vídeo |
| Causa raíz | Agotamiento de RAM del sistema (OOM killer) |
| Modelo que funcionó | LTX-2.3 distilled vía .safetensors ✅ |
| Modelo que falló | LTX-2.3 dev vía GGUF ❌ |
La configuración inicial: línea base exitosa
Antes de intentar lo imposible, establecí una línea base sólida. Usando el modelo transformer distilled de LTX-2.3 (ltx-2.3-22b-distilled-1.1_transformer_only_mxfp8_block32.safetensors) cargado vía DiffusionModelLoaderKJ desde un fichero .safetensors nativo, conseguí generar un clip de vídeo de 10 segundos con audio incluido en 463.39 segundos sin problemas.
Las especificaciones de la máquina fueron constantes en todos los intentos:
- GPU: RTX 3090 (24122 MB de VRAM reportados por ComfyUI)
- RAM del sistema: 32 GB (32014 MB reportados)
- Memoria reservada: 28812.0 MB (ComfyUI la reserva para su sistema de streaming asíncrono de pesos)
- Software: ComfyUI v0.27.0
💡 Consejo: ComfyUI reserva una cantidad significativa de RAM por adelantado. En esta configuración, dejaba solo 3.2 GB libres para el resto de procesos del sistema.
El modelo distilled utilizó 22.914 MB de VRAM, completó 8 pasos de sampling en la etapa base a cfg=1.0, 3 pasos de refinamiento a cfg=1.0, y terminó sin incidentes. Este fue mi punto de referencia.
👉 Lo importante: El modelo distilled funciona de forma confiable en esta configuración porque es más pequeño y se carga desde un formato nativo (.safetensors) sin necesidad de dequantización en tiempo real.
Los cuatro intentos fallidos: el patrón de crash
Cambié únicamente el nodo cargador de modelo, apuntando ahora a un quant GGUF del modelo dev de LTX-2.3. Mantuve el mismo prompt, seed y estructura de grafo. Esto debería haber funcionado. No fue así.
Intento 1: Q8_0 completo con offload
Usé ltx-2.3-22b-dev-Q8_0.gguf (22.75 GB en disco), 20 pasos de sampling en la etapa base, cfg=3.0 en ambos nodos CFGGuider.
El log de consola reportó: loaded partially; 19787.45 MB usable, 19774.67 MB loaded, 2193.30 MB offloaded. El fichero Q8_0 no cupo entero en VRAM, así que 2.19 GB se offloadearon a RAM del sistema.
- Etapa base (20 pasos): 6:40 (400 segundos, ~20 segundos/paso)
- Etapa de refinamiento (3 pasos): 7:04 (424 segundos, ~142 segundos/paso)
- VAE de audio: cargó correctamente (693.46 MB)
- Punto de crash:
Requested to load VideoVAE→Model VideoVAE prepared for dynamic VRAM loading. 1384MB Staged→ proceso muerto sin traceback de Python
Revisé journalctl -k para la misma marca de tiempo. El kernel me daba la respuesta:
Out of memory: Killed process 8468 (python3) total-vm:150768544kB, anom-rss:3138148kBEl OOM killer de Linux terminó el proceso. Esto fue un agotamiento de RAM del sistema, no de CUDA/VRAM. La GPU nunca se quedó sin espacio.
Intento 2: Q6_K para descartar offload
Cambié a ltx-2.3-22b-dev-Q6_K.gguf (17.77 GB en disco, cuantización más pequeña), reduje pasos base a 15, mantuve cfg=3.0.
El log reportó: loaded completely; 19889.70 MB usable, 17218.07 MB loaded, full load: True. El quant Q6_K cupo entero en VRAM con cero offload a CPU.
Esto descartaba la hipótesis del offload de raíz. Si el offload era el problema, esta versión debería haber funcionado.
- Etapa base (15 pasos): 5:18 (318 segundos, ~21.2 segundos/paso)
- Etapa de refinamiento (3 pasos): 7:05 (425 segundos)
- Crash idéntico en el mismo punto exacto
journalctlconfirmó el OOM killer matando el pid 14042
La causa no era el offload.
Intento 3: VAE tiling como variable
Mismo modelo Q6_K y ajustes que el intento 2, pero ahora sospechaba del nodo VAEDecodeTiled. Reduje los parámetros:
tile_sizede 384 a 256temporal_sizede 4096 a 64
El temporal_size original de 4096 era efectivamente sin chunking temporal para un vídeo de 251 frames. Confirmé que había 27-29 GB de RAM libre antes de la corrida.
Resultado: crash idéntico en el mismo punto exacto. El OOM killer fue invocado esta vez directamente por Thread-3 del proceso de ComfyUI, no por kswapd0, pero el resultado fue el mismo: pid 15297 terminado.
La causa no era el tamaño de tile del VAE.
⚠️ Importante: Aunque el tamaño de tile se redujo significativamente, el crash persistió. Esto sugería un problema más profundo en el pipeline de carga.
Intento 4: cfg reducido a 1.0
Mismo modelo Q6_K, mismos ajustes de tile, pero cfg vuelto a 1.0 en ambos guiders (igualando exactamente la línea base distilled exitosa).
El tiempo por paso volvió exactamente al ritmo del modelo distilled:
- Etapa base (15 pasos): 2:37 (157 segundos, ~10.5 segundos/paso, frente a ~21 segundos/paso con cfg=3.0)
- Etapa de refinamiento (3 pasos): 3:31 (211 segundos, ~70.5 segundos/paso)
Pese a que el cfg era idéntico a la corrida distilled exitosa, el resultado fue: crash idéntico en el mismo punto exacto. journalctl confirmó el OOM killer matando el pid 16517.
La causa no era el valor de cfg.
👉 Lo que aprendí: Cuatro variables diferentes (offload, tamaño de quant, tiling, cfg) se probaron sistemáticamente y todas fallaron de forma idéntica. El problema no está en ninguno de estos parámetros.
Tabla comparativa: los cuatro intentos frente a la línea base
| Aspecto | Línea Base (Distilled) | Intento 1 (Q8_0) | Intento 2 (Q6_K) | Intento 3 (Q6_K Tiling) | Intento 4 (Q6_K cfg=1.0) |
|---|---|---|---|---|---|
| Modelo | Distilled .safetensors | Dev Q8_0 GGUF | Dev Q6_K GGUF | Dev Q6_K GGUF | Dev Q6_K GGUF |
| Tamaño en disco | — | 22.75 GB | 17.77 GB | 17.77 GB | 17.77 GB |
| Carga en VRAM | 22.914 MB | 19774.67 MB (+ 2193.30 offload) | 17218.07 MB (0 offload) | 17218.07 MB | 17218.07 MB |
| Pasos base | 8 | 20 | 15 | 15 | 15 |
| cfg | 1.0 | 3.0 | 3.0 | 3.0 | 1.0 |
| Tiempo base | ~55s | ~400s | ~318s | ~318s | ~157s |
| Tiempo refinamiento | ~207s | ~424s | ~425s | ~425s | ~211s |
| VAE tile_size | — | — | — | 256 | 256 |
| VAE temporal_size | — | — | — | 64 | 64 |
| Resultado | ✅ Éxito | ❌ OOM RAM | ❌ OOM RAM | ❌ OOM RAM | ❌ OOM RAM |
| Causa OOM | — | kswapd0 | OOM killer directo | Thread-3 | Thread-3 |
El factor común: la ruta de carga GGUF vs. .safetensors
A través de cuatro intentos variamos sistemáticamente:
- Offload vs. carga completa en VRAM
- Tamaño del modelo (Q8_0 vs. Q6_K)
- Tamaño de tile del VAE
- Valor de cfg
Todas las combinaciones fallaron en el mismo punto exacto de la ejecución: justo después de que el VAE de audio termina de cargar, en el momento en que se pide cargar el VAE de vídeo.
La única variable que se mantuvo constante en los cuatro fallos, y que difiere de la única corrida exitosa, es el método de carga del modelo:
| Método | Resultado | Ruta de carga |
|---|---|---|
| ✅ Modelo distilled | Éxito | DiffusionModelLoaderKJ desde .safetensors nativo |
| ❌ Modelo dev (4 intentos) | OOM RAM | UnetLoaderGGUF desde .gguf |
La explicación más probable, basada en este patrón observado, es que la dequantización sobre la marcha de GGUF retiene memoria del lado de CPU a lo largo de las dos etapas de sampling que no se libera antes de que el VAE de vídeo necesite cargar. Ahora bien, hay que ser honesto: esto es una inferencia a partir del comportamiento observado, no una causa raíz confirmada trazada en el código fuente.
📌 A tener en cuenta: ComfyUI reserva 28.8 GB de los 32 GB disponibles, dejando solo 3.2 GB para el resto del sistema. Cuando el modelo dev se carga vía GGUF, el proceso de dequantización parece incrementar la presión de memoria más allá de esos 3.2 GB libres.
Lo que sí está confirmado es que en una máquina con 32 GB de RAM del sistema, ComfyUI reserva 28.8 GB por adelantado para su sistema de streaming asíncrono. Eso deja únicamente 3.2 GB disponibles para todo lo demás. Cuando el modelo dev se carga vía GGUF, aparentemente ese proceso de dequantización incrementa la presión de memoria más allá de esos 3.2 GB libres, y el kernel no tiene más remedio que invocar el OOM killer.
👉 Lo crítico: La ruta de carga GGUF parece retener memoria de CPU que no se libera a tiempo. Con solo 3.2 GB libres en el sistema, esto es insuficiente cuando el VAE de vídeo necesita cargar.
Lo que la GPU nunca fue el problema
Un detalle crucial: en cada uno de los cuatro intentos, el uso de VRAM nunca superó aproximadamente 20 GB de los 24 GB disponibles. La GPU tenía margen cómodo durante toda la ejecución. Los mensajes de error de CUDA nunca aparecieron. El problema no fue la GPU en absoluto.
Esto es lo opuesto a lo que muchos esperarían. Cuando un modelo “no cabe”, la intuición dice “necesito una GPU más grande”. En este caso, la GPU era suficientemente grande. La limitación real era la RAM del sistema, un cuello de botella que pasa desapercibido hasta que llega el momento crítico.
Esto tiene implicaciones importantes para cualquiera que construya una máquina para ejecutar modelos como LTX-2.3 o similares. No basta con tener una RTX 3090. Necesitas también suficiente RAM del sistema para soportar el overhead de dequantización y carga de modelos.
Comparativa: LTX-2.3 dev vs. distilled en esta configuración
| Característica | LTX-2.3 Dev (GGUF) | LTX-2.3 Distilled (.safetensors) |
|---|---|---|
| Tamaño del modelo | 17-22 GB | 22.914 MB |
| Método de carga | UnetLoaderGGUF (dequantización en tiempo real) | DiffusionModelLoaderKJ (carga nativa) |
| Overhead de RAM | Alto (retención de memoria) | Bajo |
| Funciona en 32GB RAM | No | Sí |
| Calidad de vídeo | Superior | Buena |
| Velocidad | Lenta (~20s/paso con cfg=3.0) | Rápida (~10s/paso) |
| Configuración recomendada | 64+ GB RAM del sistema | 32 GB RAM del sistema |
Preguntas frecuentes
¿El problema del modelo dev de LTX-2.3 es la VRAM o la RAM del sistema?
La RAM del sistema, según estas pruebas. A lo largo de 4 reproducciones del crash, el uso de VRAM nunca superó aproximadamente 20 GB de los 24 GB disponibles, pero el OOM killer de Linux terminó el proceso de ComfyUI cada vez por agotamiento de RAM del sistema en una máquina de 32 GB, justo cuando el VAE de vídeo intentaba cargar.
¿Reducir el cfg o el tamaño de tile del VAE arregla el crash OOM del modelo dev de LTX-2.3?
No en estas pruebas. Ambos se probaron como arreglos aislados (cfg 3.0 → 1.0, temporal_size del VAE 4096 → 64) y ninguno evitó el crash — ocurrió en el punto idéntico de la ejecución cada vez, independientemente.
¿Usar un quant GGUF más pequeño (Q6_K vs Q8_0) arregla el crash?
No. Q6_K (17.77 GB) cupo entero en VRAM con cero offload a CPU, a diferencia de Q8_0 que necesitó offloadear ~2.2 GB — pero ambos fallaron de forma idéntica, descartando el offload y el tamaño del quant como causa.
¿Por qué el modelo distilled de LTX-2.3 funcionó bien pero el dev falló?
La diferencia más clara que queda es la ruta de carga: el modelo distilled se cargó vía DiffusionModelLoaderKJ de KJNodes desde un fichero .safetensors nativo, mientras que el modelo dev se cargó vía UnetLoaderGGUF de ComfyUI-GGUF desde un fichero .gguf. Es una correlación fuerte a lo largo de 4 pruebas, no una causa raíz confirmada a nivel de código.
¿Significa esto que LTX-2.3 dev no se puede ejecutar en una RTX 3090?
No necesariamente. Significa que el pipeline de dos etapas con carga vía GGUF no funciona en una máquina con 32 GB de RAM del sistema cuando ComfyUI reserva 28.8 GB. Máquinas con 64 GB o más de RAM del sistema probablemente no enfrenten este problema. También es posible que una carga vía .safetensors nativo (si alguien convierte el GGUF de vuelta a safetensors) funcione mejor, aunque no lo probé.
¿Debería aumentar mi swap para evitar esto?
Aumentar swap podría posponer el crash, pero no lo resolvería. El problema real es que la RAM disponible es insuficiente para este pipeline en particular con este método de carga. Swap simplemente ralentizaría todo significativamente mientras el kernel intenta usar disco como memoria.
¿Qué debería hacer si tengo una RTX 3090 con 32 GB de RAM?
Antes de intentar el modelo dev de LTX-2.3 con carga vía GGUF, verifica tu RAM del sistema disponible. Si tienes exactamente 32 GB, es probable que enfrentes el mismo problema. Considera:
- Usar el modelo distilled en su lugar, que funciona de forma confiable
- Reducir significativamente los pasos de sampling (aunque esto no resolvió el problema en nuestras pruebas)
- Actualizar a 64 GB de RAM del sistema como mínimo
- Esperar a que alguien publique una versión .safetensors nativa del modelo dev sin necesidad de GGUF
Conclusión: la RAM del sistema importa más de lo que crees
Este ejercicio reveló algo que no es obvio cuando lees especificaciones de GPU: en pipelines de IA local complejos, la RAM del sistema puede ser la limitación real, no la VRAM. Una RTX 3090 con 24 GB es impresionante sobre el papel, pero si está acoplada a solo 32 GB de RAM del sistema, y ComfyUI reserva 28.8 GB de esos, estás operando con un margen de error muy estrecho.
El modelo dev de LTX-2.3 cargado vía GGUF requiere más memoria del lado de CPU durante la ejecución de lo que esos 3.2 GB libres pueden soportar. Esto no es un bug de ComfyUI, ni un problema de la RTX 3090, ni un fallo del modelo. Es una limitación de arquitectura: la combinación específica de hardware, software y método de carga simplemente no es compatible.
🏆 Nuestra recomendación
Si tienes una RTX 3090 con 32 GB de RAM del sistema y quieres generar vídeos con LTX-2.3: elige el modelo distilled. Funciona de forma confiable, es más rápido y no enfrenta problemas de OOM. Si necesitas específicamente la calidad superior del modelo dev, actualiza a 64 GB de RAM del sistema como mínimo antes de intentarlo. No es una sugerencia opcional — es una limitación arquitectónica del pipeline actual.
Sigue leyendo
Si la cuantización GGUF es terreno nuevo para ti, nuestra guía de GGUF en ComfyUI explica qué hace realmente a la calidad del modelo y a la memoria. Para la corrida exitosa que este artículo continúa, consulta nuestra guía de LTXV-2.3 + RTX Super Resolution, que tiene el pipeline completo funcionando con el modelo distilled. Y si estás valorando hardware para workflows de generación de vídeo en general, nuestra guía de Wan 2.2 en ComfyUI es otro punto de referencia de requisitos reales.
Siguientes pasos en ComfyUI
Primeros pasos
Preguntas frecuentes
- ¿El problema del modelo dev de LTXV-2.3 es la VRAM o la RAM del sistema?
- La RAM del sistema, según estas pruebas. A lo largo de 4 reproducciones del crash, el uso de VRAM nunca superó aproximadamente 20GB de los 24GB disponibles, pero el OOM killer de Linux terminó el proceso de ComfyUI cada vez por agotamiento de RAM del sistema en una máquina de 32GB, justo cuando el VAE de vídeo intentaba cargar.
- ¿Reducir el cfg o el tamaño de tile del VAE arregla el crash OOM del modelo dev de LTX-2.3?
- No en estas pruebas. Ambos se probaron como arreglos aislados (cfg 3.0 -> 1.0, temporal_size del VAE 4096 -> 64) y ninguno evitó el crash -- ocurrió en el punto idéntico de la ejecución cada vez, independientemente.
- ¿Usar un quant GGUF más pequeño (Q6_K vs Q8_0) arregla el crash?
- No. Q6_K (17.77GB) cupo entero en VRAM con cero offload a CPU, a diferencia de Q8_0 que necesitó offloadear ~2.2GB -- pero ambos fallaron de forma idéntica, descartando el offload y el tamaño del quant como causa.
- ¿Por qué el modelo distilled de LTXV-2.3 funcionó bien pero el dev falló?
- La diferencia más clara que queda es la ruta de carga: el modelo distilled se cargó vía DiffusionModelLoaderKJ de KJNodes desde un fichero .safetensors nativo, mientras que el modelo dev se cargó vía UnetLoaderGGUF de ComfyUI-GGUF desde un fichero .gguf. Es una correlación fuerte a lo largo de 4 pruebas, no una causa raíz confirmada a nivel de código.
