Solucionar Errores de LTX-2 en ComfyUI: Soluciones para OOM, Fotogramas Negros y Parpadeo

I’ll now provide the translated Spanish article directly:

---

Oye, soy Dora aquí. No me propuse depurar LTX-2 en ComfyUI. Todo comenzó con una pequeña pausa: una ventana de vista previa negra después de un flujo de trabajo que había ejecutado una docena de veces. Sin fallos dramáticos. Solo… nada. Reintenté, observé la consola, ajusté un par de configuraciones. Al final de la semana (pruebas del 6 al 10 de enero de 2026), había recopilado un puñado de correcciones que se repetían una y otra vez. Esto no es un gran tutorial, más bien notas que le daría a un amigo que también intenta que LTX-2 funcione sin convertir su mañana en una reinstalación de controladores. Ya sabes, ese tipo de caos silencioso que todos conocemos demasiado bien.

Diagnóstico de 60 segundos (síntoma → mapeo de causa)

Cuando LTX-2 se comporta mal en ComfyUI, he descubierto que los patrones rápidos superan a las conjeturas. Aquí está el mapa de 60 segundos que ejecuto antes de tocar cualquier cosa pesada:

Síntoma: Parpadeo o desviación de fotograma a fotograma
Causa probable: orientación inestable (CFG demasiado alto), semillas cambiantes, configuraciones de movimiento demasiado fuertes.
Prueba rápida: fija la semilla, baja un poco CFG, reduce movimiento/denoise, añade un paso de consistencia temporal.

Síntoma: cambios de color extraños, “nieve” o bloques estirados
Causa probable: desajuste de peso/versión, VAE incorrecto, caché corrupto o descarga parcial.
Prueba rápida: reverifica los hashes, borra la caché del modelo, confirma compatibilidad de VAE.

Síntoma: errores de nodo sobre formas o NoneType
Causa probable: un nodo no produjo salida (fallo anterior) o versiones de nodo/modelo incompatibles.
Prueba rápida: aísla la rama defectuosa, ejecuta solo hasta ese nodo, verifica la consola de ComfyUI para la primera línea de error real. Si uno de estos sucede, me detengo. Un cambio a la vez. Luego vuelvo a ejecutar un clip de 2-3 segundos para no quemar tiempo en renders largos.

Corrección OOM: Orden de degradación de resolución / precisión / lote

Mi rutina LTX-2 OOM es aburrida, pero funciona. La hago en este orden y solo paso al siguiente paso si la OOM persiste:

1. Resolución primero

• Reduce altura/ancho entre un 20-30% en lugar de dividir por la mitad. Muchos gráficos de LTX-2 son sensibles al stride (múltiplos de 8 o 16). Mantengo dimensiones divisibles por 16 para evitar rellenos ocultos.
• Si apuntas a 1024×576, prueba 896×504. Te digo, se ve más cercano al original de lo que esperarías.

2. Precisión siguiente

• Cambia la precisión del modelo a fp16 (o bf16 si tu pila lo soporta) en el nodo cargador relevante. En las GPUs de consumo de NVIDIA, fp16 generalmente proporciona el ahorro de memoria más limpio.
• La precisión mixta está bien, pero evito alternar por nodo durante la ejecución. Comprométete con una precisión para las partes pesadas.

3. Tamaño del lote al final

• Establece lote a 1 para muestreo de video. Incluso lotes pequeños multiplican activaciones clave en memoria. Solo aumento lote para latentes rápidos o vistas previas.

También he notado una victoria sutil: bloquea la semilla mientras afinas OOM. La aleatoriedad puede enmascarar si tu último cambio realmente ayudó.

Pantalla negra: problemas de carga de modelo versus decodificación

Mi primera pantalla negra esta semana resultó no ser un fallo de modelo en absoluto. Fue una peculiaridad de decodificación.

Cómo separo los dos rápidamente

Verifica el tamaño del archivo y la duración

• Si el video tiene la duración correcta y aproximadamente el tamaño esperado, los fotogramas podrían estar ahí. Tu reproductor podría no gustar el formato de píxel o el espacio de color.

• Recodifica con una línea base segura:
  ffmpeg -i input.mp4 -pix_fmt yuv420p -c:v libx264 -crf 18 output.mp4
  (consulta la documentación de FFmpeg para más opciones de codificación) Examina la consola de ComfyUI

• Los problemas reales de carga de modelo se anuncian a sí mismos: pesos faltantes, claves incompatibles o un desajuste de hash de VAE/modelo.

• Si ves registros de muestreo exitosos y sin excepciones, probablemente sea una ruta de visualización/codificación.

Desajustes de dimensiones latentes

• Los pipelines de LTX-2 esperan ciertos strides (a menudo múltiplos de 16). Si tus entradas latentes o de control no coinciden, puedes obtener fotogramas en blanco o casi negros.
• Verifico que los nodos de cambio de tamaño ocurran antes de lo que el modelo espera, y que todas las ramas estén de acuerdo en ancho/alto.

Sorpresas de rango de color

• El rango completo versus limitado puede verse aplastado al negro en algunos reproductores. Una recodificación rápida (arriba) generalmente lo resuelve.

Si es un problema de carga de modelo, voy a la fuente: verifica que la ruta del punto de control de LTX-2 en el nodo cargador apunte al archivo real, confirma el checksum, y asegúrate de que el formato de peso esperado del nodo (safetensors vs ckpt) coincida con el archivo. La documentación oficial de ComfyUI y el README del modelo son las únicas páginas en las que confío para notas de versión/formato.

Corrección de parpadeo: parámetros de estabilidad y anclaje de indicación

El parpadeo no siempre es un bug. A veces es el modelo haciendo exactamente lo que se le dijo, con demasiada libertad.

Lo que me calmó las cosas:

• Fija la semilla
  Bloqueo la semilla para cualquier prueba A/B. Elimina una variable resbaladiza de inmediato.

• Baja CFG un poco
  Si estoy en 8-9, pruebo 6. La orientación demasiado alta puede tirar de fotogramas en diferentes direcciones.

• Denoise y fuerza de movimiento
  Reducciones suaves aquí (10-20%) a menudo ayudan más que aumentar pasos. He descubierto que un poco menos de denoise preserva mejor las señales temporales.

• Anclaje de indicación
  Mantén una indicación base estable y mueve cambios a una pequeña sección explícita (fotogramas clave o un breve paréntesis). Cambiar toda la oración entre fotogramas invita a la desviación.

• Paso de consistencia temporal
  Si tu gráfico tiene un nodo temporal/consistencia, ejecútalo suavemente. No inventará detalle, pero puede suavizar el temblor.

• Elección del muestreador
  Pruebo 2-3 muestreadores con la misma semilla. Algunos son más saltarines en video. Si uno calma los bordes en el mismo número de pasos, lo mantengo.

Nota pequeña: dejé de perseguir la “perfecta” coherencia de fotogramas. El objetivo para mí es menos fatiga mental mientras edito, algo que pueda cortar, no la perfección bajo un microscopio.

Salida corrupta: desajuste de peso / errores de ruta

La corrupción apareció para mí como bloques rosas, nieve brillante o bandas de color que no coincidían con la indicación. Cada vez, fue algo mundano:

• Pesos desajustados
  El cargador esperaba una variante específica de LTX-2: tenía una diferente con nombres similares. Ahora incluyo la fecha del modelo o hash en nombres de archivo.

• VAE incorrecto
  Cambiar VAE casualmente me golpeó. La corrección fue simple: usa el VAE especificado por la documentación del nodo LTX-2 o el README del modelo. Si ninguno se especifica, usa por defecto el incluido o recomendado por el autor del gráfico.

• Descargas parciales
  Un punto de control de 3-8 GB que falla al 95% se ve completo en una vista de carpeta. Verifico el tamaño del archivo contra la lista del repositorio y, cuando está disponible, verifico el hash.

• Problemas de ruta (especialmente Windows)
  Los caracteres no ASCII y las rutas muy largas me han roto las cargas en el pasado. Créeme, mantengo rutas de modelo cortas (por ejemplo, D:\models\ltx2\…) y evito espacios cuando puedo.

• Formatos mixtos
  safetensors vs .ckpt no es intercambiable en algunos nodos. Coincido con la expectativa del nodo.

Cuando sospecho corrupción, vuelvo a ejecutar una indicación conocida y buena en resolución diminuta. Si eso está limpio, sé que el problema vive en mi combo actual, no en toda la instalación.

Lectura de registros: qué capa se bloqueó

La mayoría de mis ahorros de tiempo vinieron de leer la primera línea de fallo, no la última línea dramática. La consola de ComfyUI generalmente te dice lo suficiente si te tomas treinta segundos.

Lo que busco:

• CUDA sin memoria
  No es un bug. Reduce res/precisión/lote como arriba. Si falla en el mismo paso cada vez, estás golpeando un pico de activación específico, reduce pasos o habilita atención eficiente en memoria.

• CUDNN_STATUS_EXECUTION_FAILED o acceso a memoria ilegal
  A menudo desajuste de controlador o biblioteca. Anoto mis versiones de CUDA, PyTorch y controlador de GPU en un archivo de texto. Si recientemente actualicé uno, lo revierto o reconstruyo el venv. La documentación de ComfyUI tiene una pequeña matriz de combinaciones conocidas como buenas.

• Desajuste de tamaño / errores de forma
  Un tensor tiene la forma incorrecta. Esto es generalmente un problema del gráfico de nodos: un cambio de tamaño ocurre en una rama y no en otra, o una entrada de control espera una escala diferente. Trazo las dimensiones donde divergen.

• KeyError / claves state_dict faltantes
  Desajuste de peso-nodo. Compara las claves faltantes listadas con el README del modelo. Variante de punto de control incorrecta o nodo desactualizado.

• AttributeError: ‘NoneType’ …
  Un nodo anterior devolvió nada. Ejecuto el gráfico solo hasta ese nodo. El primer None es el culpable real.

Dos hábitos que ayudaron:

• Ejecuta clips cortos mientras debuggeas. Diez segundos de registros de fallo desperdicia mucho menos tiempo que un minuto de silencio.
• Habilita cualquier alternar debug/verbose disponible en el nodo sospechoso. Contexto extra supera a las conjeturas.

Mantengo una pequeña “tarjeta de entorno” en la carpeta del proyecto: modelo de GPU y VRAM, controlador, CUDA, PyTorch, commit de ComfyUI, versiones de paquetes de nodos, y hash de punto de control de LTX-2. Cuando algo se rompe, lo comparo con la tarjeta de la semana pasada antes de culpar al modelo.

Cuándo cambiar a la nube (atajo de solución de problemas de WaveSpeed)

No me apresuro a la nube para LTX-2, pero hay momentos en que es la forma más limpia de separar “el humor de mi máquina” de problemas reales.

Cuándo cambio

• VRAM inferior a 16 GB y necesito salidas de 1024p sin compromisos pesados.
• Veo bloqueos irregulares vinculados a mis versiones locales de CUDA/controlador, y no tengo tiempo para reconstruir.
• Quiero una segunda opinión: el mismo gráfico, hardware diferente.

Lo que hago en WaveSpeed (o cualquier espacio de trabajo GPU comparable)

• Elige una imagen conocida y buena (combo CUDA/PyTorch documentado). Eso importa más que TFLOPS sin procesar cuando estás debuggiendo.
• Sincroniza solo el gráfico mínimo, los pesos exactos de LTX-2 (con hash), y una indicación de prueba corta.
• Ejecuta el caso reproducible más diminuto primero. Si funciona en la nube y no localmente, probablemente sea entorno: si falla en ambos, es el gráfico o los pesos.

Costos y compensaciones

• Pagarás por computación, sí. Pero una repro limpia puede ahorrar una tarde de ruleta de controladores.
• Los discos en la nube también pueden ocultar problemas de ruta, solo de diferentes maneras. Aún mantengo rutas cortas y ASCII.

Esto no es un empujón para mover tu flujo de trabajo. Es solo un atajo silencioso cuando estás atrapado y la fecha límite es más fuerte que tu paciencia.

Construimos WaveSpeed para momentos exactamente como este — cuando solo necesitas un entorno GPU limpio para descartar cosas rápidamente. Si estás atrapado debuggiendo LTX-2, puedes probar nuestro WaveSpeed aquí.

---

¿Cuál es el error más loco de LTX-2 que has encontrado esta semana? Deja un comentario y cuéntame si es un nuevo peligro.