De Checkpoints a Firmware: La Realidad de los Text Encoders y Nombres en ComfyUI

¿Puedes usar cualquier text encoder con cualquier modelo de difusión en ComfyUI? La respuesta corta es no. Al principio, puede parecer que los archivos son simplemente librerías sueltas que puedes mezclar y combinar a tu gusto, pero la realidad técnica es más restrictiva. Los text encoders están intrínsecamente asociados a la arquitectura del modelo de difusión con el que van a trabajar.

La Dependencia de la Arquitectura

Cada familia de modelos tiene sus propios requisitos. Por ejemplo, los modelos como Stable Diffusion 1.5 esperan un tipo específico de text encoder con una dimensión de embedding concreta, mientras que modelos más recientes como SDXL o SD3 requieren combinaciones mucho más complejas, como CLIP-L junto a CLIP-G o T5-XXL.

Esto significa que no puedes simplemente tomar el text encoder diseñado para un modelo y aplicarlo a otro diferente. Si intentas cargar un text encoder incompatible con el modelo de difusión, la generación fallará directamente o producirá resultados incorrectos porque las formas y tamaños de los vectores de texto simplemente no coinciden.

El Caso del LLaMA como Encoder

Un ejemplo claro de esta especialización es el uso de modelos de lenguaje como encoders. Al descargar un archivo como llama_3.1_8b_instruct_fp8_scaled.safetensors, no estás obteniendo una versión genérica del modelo LLaMA para chat o generación de texto, sino una instancia específica preparada exclusivamente para actuar como encoder semántico.

Este archivo transforma el prompt y genera embeddings que condicionan al modelo de difusión. No es un modelo estándar cargado a través de librerías de lenguaje común; está atado a una arquitectura, un tokenizer y un tamaño de embedding muy concretos. Cambiar este encoder rompería la compatibilidad dimensional del sistema.

La Verdad sobre los Nombres de Archivo

Pero el misterio no termina ahí. ¿El cambio de wan2.1 a wan2_1 en modelos como Wan2.1 es solo una cuestión cosmética para ordenar alfabéticamente las carpetas? La respuesta es definitivamente no.

El uso del guion bajo (_) frente al punto (.) tiene un significado técnico profundo relacionado con la robustez de los parsers y frameworks. Cambiar estos nombres, como en Wan2_1-I2V-ATI-14B_fp8_e4m3fn.safetensors, puede hacer que el loader no encuentre su configuración implícita o asigne un pipeline incorrecto.

Esto se aplica incluso a modelos más complejos como Wan2_2-Animate-14B_fp8_e4m3fn_scaled_KJ.safetensors. Aquí, el nombre incluye detalles críticos sobre el tipo de video (Animate), la arquitectura y los parámetros de escalado. Renombrar estos archivos para intentar un orden alfabético es una forma silenciosa de sabotaje.

De Checkpoints a Firmware

En conclusión, estamos viendo un cambio fundamental en cómo funcionan estos sistemas. Ya no podemos tratar los modelos como simples archivos sueltos; ahora son más parecidos al firmware de un dispositivo.

El nombre del archivo actúa como un contrato con el loader: define la configuración implícita, el pipeline y la arquitectura auxiliar necesaria para que todo funcione. La lección es clara: no intentes modificar los nombres ni asumir compatibilidad universal. En lugar de usar el sistema de archivos para ordenar, utiliza carpetas para mantener el control sin romper estos contratos técnicos.