LTX-2.5 en ComfyUI: Movimiento de Cámara I2V vs T2V (RTX 3090)

LTX-2.5 salió el 11 de agosto de 2026 — Lightricks lo presentó como un modelo de 22B de parámetros con pesos abiertos, generación nativa de audio-vídeo y soporte día uno en ComfyUI. Antes de fiarnos de la cifra de marketing (“clips de 10s en 6,8 segundos en superchips Nvidia”), lo probamos de verdad en el hardware que tenemos: una RTX 3090 de 24GB. Esta prueba no busca la mejor calidad posible — busca saber si el modelo corre en consumo real, cuánto tarda, y si el I2V y el T2V producen resultados distintos con el mismo prompt de movimiento de cámara.

De un vistazo: 8 pruebas reales

Las 8 a 960×544, 24fps, 20,04 segundos exactos, sampler distillado de 8 pasos (euler_ancestral, sigmas fijos), CFG 1.0. 0 fallos, 0 OOM. Duración total del hardware: RTX 3090 24GB, ComfyUI con ComfyUI-LTXVideo actualizado a la versión con soporte 2.5 (plantillas oficiales example_workflows/2.5/).

Reproducibilidad: entorno y parámetros exactos

Versiones exactas de esta sesión, para quien quiera reproducir los resultados:

Seed y prompt exactos de cada una de las 8 pruebas (idénticos en el manifest JSON completo, que además incluye los 4 fotogramas de partida usados en I2V):

Los 4 fotogramas de partida usados en I2V están disponibles individualmente: bullet-time, grúa, giro, empuje.

Por qué int8-convrot y no el modelo completo

LTX-2.5 en precisión completa (bf16) pide del orden de 66GB de VRAM — inviable en cualquier tarjeta de consumo. La variante que sí cabe en 24GB es la cuantización oficial comfy-int8-convrot, publicada por el propio Lightricks el mismo día del lanzamiento:

• ltx-2.5-22b-distilled-transformer-comfy-int8-convrot.safetensors — 21GB en disco
• gemma4-12b-with-proj-ltx-2.5-comfy-int8-convrot.safetensors — 15GB en disco (text encoder)

Los logs de ComfyUI confirman que la cuantización usa kernels nativos, no una emulación lenta:

Found quantization metadata version 1
Detected mixed precision quantization
Native ops: asym_w4a8_int8, int8_tensorwise, convrot_w4a4

Y confirman también que el transformer y el encoder nunca están cargados en VRAM a la vez — se cargan y liberan de forma secuencial, el mismo patrón de gestión dinámica de memoria que ya vimos con la arquitectura MoE de Wan 2.2:

Model LTXAVTEModel_ prepared for dynamic VRAM loading. 14612MB Staged.
[...]
Requested to load LTXAV
Model LTXAV prepared for dynamic VRAM loading. 20484MB Staged.

Sin esa carga secuencial, 20,5GB + 14,6GB (35,1GB) no cabrían en ningún caso en una tarjeta de 24GB. Con ella, la mayor reserva de modelo observada fue de 20.484MB (el transformer) — no medimos el pico total de VRAM del proceso (VAE + activaciones de la difusión de vídeo aparte), así que el margen real disponible podría ser menor de lo que sugiere esa cifra. No hay margen de sobra para subir resolución sin arriesgarse a un OOM; no lo probamos a más de 960×544 en esta serie.

Las 4 técnicas de cámara probadas

Elegimos cuatro movimientos de cámara clásicos del cine, aplicados a sujetos genéricos propios — sin vestuario, rostros ni diseños de personajes de ninguna película concreta. El objetivo era aislar la técnica de cámara, no recrear una escena protegida por derechos de autor.

1. Orbital / bullet-time: la cámara gira alrededor de un sujeto suspendido en el aire durante un salto, mientras el tiempo parece congelarse.
2. Grúa hacia atrás y arriba: la cámara se retira y eleva desde detrás de dos figuras con los brazos extendidos, revelando el entorno completo.
3. Giro hacia frontal: la cámara circula desde un lateral hacia un plano frontal de dos figuras enfrentadas.
4. Empuje bajo y ajustado: la cámara avanza baja y cercana hacia un detalle concreto (la mano cerca de una pistolera), con tensión deliberada.

Cada técnica se probó dos veces: una en I2V (con un fotograma de partida generado previamente con SDXL) y otra en T2V puro (sin ninguna imagen, solo el prompt de texto describiendo sujeto, escena y movimiento de cámara juntos).

Orbital bullet-time: I2V vs T2V

Comparativa I2V (izquierda) vs T2V (derecha) de la técnica orbital bullet-time. Verificado muestreando 7 fotogramas repartidos por los 20s completos de cada clip — la cámara efectivamente gira alrededor del sujeto en ambos casos, con encuadres de partida distintos.

Grúa hacia atrás: I2V vs T2V

La cámara se retira y eleva revelando el entorno completo en ambas versiones.

Giro hacia frontal: I2V vs T2V

El giro de lateral a frontal se completa en ambos modos, con iluminación y encuadre inicial distintos.

Empuje bajo y ajustado: I2V vs T2V

El empuje hacia el detalle de la mano cerca de la pistolera, verificado en ambos modos.

Diferencia clave entre I2V y T2V en el grafo de ComfyUI

Ambos modos comparten el mismo UNETLoader, CLIPLoader (Gemma), LTXVConditioning y la misma cadena de sampler (RandomNoise → CFGGuider → KSamplerSelect → ManualSigmas → SamplerCustomAdvanced, sigmas fijos del preset distillado de 8 pasos). La diferencia real está en cómo se construye el latent_image de entrada:

• I2V: LoadImage → LTXVPreprocess → LTXVImgToVideoInplace (con el EmptyLTXVLatentVideo y el VAE) inyecta el fotograma real en el latente antes de samplear.
• T2V: se salta por completo esa cadena y el EmptyLTXVLatentVideo (latente vacío) va directo al sampler — el modelo decide toda la composición desde el prompt.

Música: instrumental original con ACE-Step, no una pista existente

Para el montaje generamos una pista instrumental de 165 segundos con ACE-Step v1 (3,5B), nativo en ComfyUI (comfy_extras/nodes_ace.py). Tags genéricos (“epic cinematic orchestral, dramatic strings, powerful brass…”) sin lyrics reales — solo marcadores de estructura ([instrumental], [intro], [build], [climax], [outro]). 102,6 segundos de generación, sin fallos. No es una recreación de ninguna banda sonora existente.

Limitaciones de esta prueba

• Una sola GPU probada: RTX 3090, 24GB. No se puede generalizar a otras tarjetas de 24GB (4090) ni a tarjetas más pequeñas — el margen de VRAM es tan ajustado que el resultado podría no ser el mismo.
• Solo la variante distilled: no probamos el modelo dev (sin distillation) ni la variante nvfp4 (necesita hardware con soporte FP4 nativo, que Ampere no tiene).
• Sin la LoRA de distillation: el repositorio oficial incluye ltx-2.5-22b-distilled-lora-450-bf16.safetensors (8,3GB); no la descargamos por espacio en disco. No sabemos si mejora el resultado.
• Sin repeticiones: cada combinación técnica×modo se ejecutó una sola vez. No hay dato de varianza entre ejecuciones con la misma seed.
• Sin comparación de calidad cuantitativa: no medimos ninguna métrica objetiva de calidad de vídeo (solo verificación visual por muestreo de fotogramas). “Funciona” y “se ve la técnica de cámara pedida” no es lo mismo que “es la mejor calidad posible”.
• Workflow API, no editor visual: montamos y ejecutamos el grafo vía la API de ComfyUI directamente (urllib + JSON), no a través del editor de nodos — una restricción de sandbox de red nos impidió usar el navegador contra el servidor local en esta sesión. El JSON descargable es formato API, no el grafo de UI con posiciones de nodo.

Changelog

2026-09-07 — Publicación inicial. Primera prueba real de LTX-2.5 en ComfyLab, 8 generaciones verificadas.

Fuentes

• LTX-2.5 en Hugging Face (Lightricks)
• Repositorio oficial ComfyUI-LTXVideo (Lightricks)
• Licencia LTX-2.x Community License Agreement

Sigue leyendo

Si quieres ver el mismo tipo de comparación real aplicada a Wan 2.1 vs Wan 2.2, consulta la comparativa real de 5 pruebas de vídeo IA local. Para transferencia de movimiento de cámara con un enfoque distinto (IC-LoRA sobre un vídeo de referencia en vez de prompt de texto), revisa la guía de IC-LoRA Cameraman v2 sobre LTX 2.3. Si quieres entender la cuantización GGUF/int8 en profundidad, la guía de GGUF en ComfyUI cubre los trade-offs.