LTX 2.3: Dev vs Distilled, ¿cuál modelo elegir para ComfyUI?

¿Qué significan esos nombres de archivo?

En el mundo de la generación con IA, los nombres de archivo a veces parecen simples etiquetas, pero en realidad representan diferencias fundamentales. Al hablar de ltx-2.3-22b-dev-fp8.safetensors y ltx-2.3-22b-distilled-fp8.safetensors, estamos hablando de dos versiones con filosofías de uso muy distintas dentro del ecosistema LTX 2.3.

Dos archivos de modelo LTX 2.3 mostrados lado a lado en un entorno digital oscuro.
Comparativa visual entre los pesos dev y distilled de LTX 2.3 en su entorno de generación.

Para empezar, dev-fp8 es el modelo base completo y más fiel. Es la versión ‘cruda’ que mantiene una flexibilidad mayor para responder a prompts complejos o experimentos raros. Por otro lado, distilled-fp8 ha sido sometido a un proceso de destilación: está afinado específicamente para pipelines rápidos, priorizando una salida más consistente y estable.

Diferencias técnicas entre Dev y Destilado

Aunque ambos usan la misma cuantización FP8, el dev es el hermano mayor del modelo: puede ser menos predecible en estilos bonitos por defecto porque no está forzado a un régimen tan restringido. El distilled, en cambio, funciona mejor con workflows optimizados como ComfyUI, sacrificando algo de libertad creativa para ganar velocidad y estabilidad visual.

Es común preguntarse si el archivo del modelo ‘dev’ debería ser más pesado que la versión ‘distilled’, pero eso no siempre es cierto. La compresión FP8 aplana las diferencias de almacenamiento, por lo que el peso en disco no refleja necesariamente la complejidad interna o el tiempo de inferencia.

Esquema interno mostrando métricas de estabilidad e inferencia en modelos de IA.
Diagrama técnico que ilustra las diferencias internas entre los modelos destilados y de desarrollo.

Lo interesante es que, aunque ambos pesen similar y se demoren casi lo mismo en procesar, el uso de memoria puede variar. Si un modelo como wan2gp consume más VRAM pero entrega mejores resultados en outpainting, suele deberse a cómo aprovecha la ventana de contexto o los schedulers activos durante la inferencia.

El caso del workflow oculto y el outpainting

Tu situación actual es muy reveladora: usas wan2gp (distilled) junto con un segundo workflow en ComfyUI que carga el modelo dev. Al no poder ver ese workflow de fondo, parece que ambos modelos se comportan igual en términos de tiempo y peso.

Sin embargo, la destilación a menudo gana en tareas como el outpainting porque está entrenada para cerrar huecos de forma más estética y rápida. El modelo dev, al ser más conservador, puede respetar más la distribución interna del prompt, dejando bordes menos convincentes o simplemente pareciendo más lento si el pipeline no lo empuja.

Proceso de outpainting y nodos de ComfyUI mostrando el uso de memoria.
Representación del proceso de outpainting en un lienzo digital con indicadores de uso de memoria.

Para confirmar esto sin necesidad de abrir ese workflow oculto, la mejor prueba es un test controlado. Si ejecutas ambos modelos con el mismo prompt, la misma seed y una resolución idéntica en un inpaint o outpaint con máscara idéntica, podrás ver si el distilled sigue cerrando mejor los resultados.

Aunque sería ideal poder analizar los logs de ComfyUI para reconstruir qué está haciendo exactamente ese workflow oculto, probar ambos modelos bajo condiciones controladas te dará la respuesta más directa y fiable sin depender de adivinanzas.