Debugging MiniMax H3 Turbo: Solucionando el Error de Tensor Size en ComfyUI

Estoy intentando generar un video con ComfyUI usando el modelo MiniMax H3, pero he tropezado con un error muy específico en el nodo ComfyUI-MiniMax-H3-Turbo. Al principio pensé que era un problema de memoria o de los tipos de datos, pero tras revisar el traceback, el fallo es mucho más concreto.

Captura del traceback de Python mostrando la línea 166 y el error de tamaño de tensor en ComfyUI.
El traceback exacto donde el nodo Turbo falla al intentar sumar las matrices de conditioning.

El error se produce exactamente en la línea 166 del archivo __init__.py dentro de ese custom node. El mensaje dice: ‘RuntimeError: The size of tensor a (3) must match the size of tensor b (2)’. Al analizar el código, veo que el nodo intenta sumar una corrección LoRA calculada para dos timesteps a la salida del modelo, pero mi flujo de trabajo está entregando tres entradas de conditioning.

¿Por qué el Turbo falla?

Parece ser una incompatibilidad entre cómo este nodo específico procesa las referencias visuales y cómo calcula los embeddings temporales. El código del parche AdaLN no detecta correctamente la tercera modalidad que proviene de mi configuración R2V, lo que provoca esa discrepancia matemática al intentar ejecutar el cálculo.

Esto me hizo sospechar que quizás tenía algo mal en la instalación o que debía cambiar a un workflow más simple. Sin embargo, mientras revisaba los logs y el grafo del flujo de trabajo, noté algo importante: había tropezado con otros LoRAs diseñados específicamente para la inferencia acelerada de 4 pasos.

Diagrama del grafo de ComfyUI con los nodos de imagen y el sampler H3 Turbo conectados.
El flujo de trabajo R2V que genera las tres modalidades de conditioning antes del error.

La solución

Aquí está la clave: esos otros LoRA de 4 pasos son compatibles con el loader estándar de ComfyUI y no requieren usar el custom node ComfyUI-MiniMax-H3-Turbo. Esto es crucial porque significa que puedo aprovechar los modelos entrenados para una inferencia más rápida sin tener que depender de ese parche problemático.

Imagen dividida mostrando el loader LoRA funcionando bien a la izquierda y el nodo Turbo fallido a la derecha.
Comparación entre el uso de loaders estándar exitosos y el nodo Turbo fallido.

He probado a cargar esos nuevos LoRAs usando el loader normal y, al desactivar completamente el nodo Turbo, todo funciona perfectamente. El problema no era mi workflow base ni la configuración R2V en sí misma, sino exclusivamente esa implementación específica del Turbo que intenta inyectar aceleraciones incompatibles con los nodos actuales.

La lección aprendida es clara: cuando se trabaja con modelos de IA complejos como MiniMax H3 y herramientas como ComfyUI, a menudo hay múltiples implementaciones disponibles. Es vital distinguir entre el modelo base y las optimizaciones externas que pueden introducir bugs como este. Evitar el nodo Turbo para estos casos específicos y usar loaders estándar es la solución más limpia hasta que se solucione esa incompatibilidad.