Cambiar tema

Solucionar errores de ComfyUI: nodos rojos, VAE y versiones

Easton editorial illustration: a large rounded workflow canvas with one red disconnected node, a compact terminal warning panel, and a restored connected node path

"La documentación oficial de ComfyUI explica --disable-all-custom-nodes, el aislamiento de extensiones frontend y la búsqueda binaria del nodo problemático."

Abres un workflow compartido y encuentras una fila de unknown nodes rojos. Ejecutas Install Missing Custom Nodes en Manager, reinicias ComfyUI y siguen en rojo. Manager no es una herramienta de reparación universal: administra el código de los nodos, pero no garantiza que todas sus dependencias se instalen correctamente ni descarga los archivos de modelo.

Los nodos rojos son solo una de las entradas al diagnóstico de ComfyUI. La aplicación puede quedarse en loading, la interfaz puede aparecer en blanco, un workflow que funcionaba puede romperse después de una actualización, la salida VAE puede volverse gris o negra o un modelo copiado puede no aparecer en el menú desplegable. Estos síntomas suelen apuntar a conflictos entre custom nodes, versiones de dependencias, rutas de modelos, opciones de precisión o picos de VRAM.

La ruta más corta parte del síntoma: identifica la capa probable y realiza la prueba más pequeña que permita confirmarla o descartarla.

Tabla rápida por síntoma

La tabla reúne seis puntos de entrada habituales. Localiza el síntoma en la primera columna, limita la causa con la segunda y empieza por la tercera.

SíntomaCausa más probablePrimera acción
Nodos rojos / unknown nodesFalta un custom node, el nodo cambió de nombre o falló el importBuscar el nombre en Manager o Registry y revisar Import failed en la consola
Bloqueo en loading / página en blanco / blank screenConflicto con una extensión frontend de un custom nodeProbar python main.py --disable-all-custom-nodes
Prompt execution failed después de QueueError de custom node, problema de modelo o VRAM insuficienteAbrir Show report e identificar el componente que falla
Salida VAE gris, blanca, teñida o negraVAE incompatible o precisión incorrectaRevisar la conexión del VAE loader, los archivos asociados y --fp16-vae
Workflow roto después de actualizarIncompatibilidad entre core y custom node o conflicto de dependenciasIdentificar qué se actualizó y revisar los scripts de update
Modelo copiado ausente del menúRuta incorrecta o definiciones de nodos sin actualizarRevisar la subcarpeta de ComfyUI/models/ y después reiniciar o actualizar

No elimines la instalación de inmediato. Guarda el workflow, los registros, la lista de nodos y las versiones antes de modificar el entorno.

Nodo rojo: ¿custom node o modelo?

Un unknown node rojo suele significar que ComfyUI no encuentra ese tipo de nodo. Puede faltar el custom node, haber cambiado de nombre, estar desactivado o fallar al importar sus dependencias. Un modelo ausente normalmente desaparece del menú del loader o genera un error de modelo al ejecutar. Separa estas dos clases de fallo.

1. Qué corrige Install Missing en Manager

Install Missing Custom Nodes de ComfyUI-Manager resuelve principalmente la ausencia del código de un nodo. Manager instala nodos desde Registry o un repositorio de origen, pero estos elementos pueden requerir intervención aparte:

  • Las dependencias de Python del nodo, como torch, numpy o xformers en requirements.txt
  • Los archivos de modelo: checkpoints, VAE, LoRA y ControlNet
  • Las rutas de modelo específicas del custom node, documentadas en su README

Comfy Desktop incluye Manager y lo activa de forma predeterminada. En las instalaciones actuales Portable y Manual, el Manager nuevo está integrado en el core de ComfyUI, pero debes instalar manager_requirements.txt e iniciar con --enable-manager. Si un nodo no aparece en Manager, quizá no esté registrado o un problema de red limite la lista a datos locales o en caché. Verifica el repositorio original antes de instalar un paquete con un nombre parecido.

Sigue este orden: buscar Import failed en la consola → buscar el nodo en Manager o Registry → revisar la ruta del modelo. El proceso completo de importación está en Reutilizar un workflow de ComfyUI.

2. Cómo interpretar Import failed

Cuando la consola muestra Import failed, el final del traceback normalmente contiene el módulo ausente o la versión en conflicto. La clase del error determina el siguiente paso:

Árbol de decisión:

  1. ModuleNotFoundError: No module named 'xxx' → falta un paquete de Python

    • No lo instales en el Python del sistema, sino en el entorno Python de ComfyUI
    • Portable: python_embeded\python.exe -m pip install -r custom_nodes\xxx\requirements.txt
    • Desktop y Manual usan otras rutas; identifica el ejecutable de Python que realmente utiliza ComfyUI
  2. Errores de torch / CUDA / cuDNN → PyTorch y el backend de la GPU no coinciden

    • Revisar PyTorch: python -c "import torch; print(torch.__version__)"
    • Comprobar que el controlador de la GPU cumple los requisitos actuales del sistema
    • Un nodo puede exigir una versión de torch incompatible con la de ComfyUI
  3. Excepción dentro del custom node → versión del nodo o defecto de código

    • Buscar el mismo traceback en los issues de GitHub del nodo
    • Si una versión nueva introdujo la regresión, probar un commit que se sepa funcional

Dato variable: al empaquetar este artículo, ComfyUI recomienda Python 3.13 y ofrece 3.12 como alternativa cuando algunas dependencias de custom nodes fallan con 3.13. Los requisitos de PyTorch y CUDA cambian con rapidez; consulta los requisitos actuales del sistema.

3. Instalado en Manager, pero aún no disponible

El estado «instalado» no demuestra que el nodo cargue. Después de reiniciar puede seguir rojo o provocar un conflicto entre torch y torchvision.

Por qué un nodo instalado puede seguir sin estar disponible:

  • Un error de red interrumpió la descarga del repositorio o sus dependencias
  • Los requirements de Python no se instalaron en el entorno de ComfyUI
  • El nodo está desactivado o falla durante el import
  • Su versión no es compatible con la versión actual de ComfyUI

Por qué chocan las dependencias:

  • Varios custom nodes exigen versiones diferentes de torch, torchvision o numpy
  • Una versión fijada estrictamente en requirements.txt entra en conflicto con los paquetes existentes

Orden de resolución:

  1. Leer el último traceback completo y clasificarlo con la sección anterior
  2. Desactivar o eliminar el nodo sospechoso y volver a probar ComfyUI
  3. Buscar versiones estrictas como torch==2.4.1 en requirements.txt
  4. Si el conflicto continúa, abrir un issue con:
    • El traceback completo
    • El resultado de python main.py --disable-all-custom-nodes
    • Las versiones de Python, PyTorch y el controlador de la GPU

Dato variable: Manager existe en variantes nueva integrada y legacy. Sigue la documentación actual para los nombres de opciones y menús. Si la causa real es OOM o un pico de VRAM, continúa con Optimizar ComfyUI para 6 a 8 GB de VRAM.

4. Rutas de modelos y menús vacíos

ComfyUI no incluye los pesos de los modelos. Descarga por separado checkpoints, VAE, LoRA, ControlNet y upscalers, y colócalos en la subcarpeta correspondiente de ComfyUI/models/.

Orden de comprobación si falta el archivo:

  1. Carpeta correcta

    • Checkpoints en ComfyUI/models/checkpoints/
    • VAE en ComfyUI/models/vae/
    • LoRA, ControlNet y upscalers en sus carpetas por tipo
    • Si un custom node utiliza otra ruta, sigue su README
  2. Reinicio o actualización

    • Reiniciar ComfyUI o usar la actualización de definiciones disponible en la interfaz actual
  3. Integridad del archivo

    • Comparar su tamaño con la fuente de descarga
    • Volver a descargar o verificar un archivo incompleto
  4. Loader compatible

    • Elegir un loader y una plantilla de workflow diseñados para esa familia de modelos
    • FLUX, SD3.x y otras arquitecturas recientes pueden requerir text encoders, VAE y combinaciones de nodos específicos
    • Las rutas de un custom node pueden diferir de las indicaciones generales de ComfyUI/models/
  5. extra_model_paths.yaml

    • Portable y Manual pueden referenciar bibliotecas externas mediante extra_model_paths.yaml; reinicia después de guardar
    • Desktop tiene su propio archivo de configuración para modelos externos; usa la ruta oficial vigente

Para relacionar modelo y VAE, consulta Elegir un modelo de Stable Diffusion.

Diagnosticar un bloqueo de carga con —disable-all-custom-nodes

Cuando ComfyUI queda en loading, muestra una página en blanco o deja de representar la interfaz, a menudo hay una extensión frontend de un custom node implicada. --disable-all-custom-nodes permite saber rápidamente si los custom nodes son la causa.

1. Iniciar sin custom nodes

Comando:

python main.py --disable-all-custom-nodes

Windows Portable:

Copia run_nvidia_gpu.bat o run_cpu.bat, agrega --disable-all-custom-nodes al comando de inicio y guarda otro script de arranque seguro.

Interpretación:

  • El problema desaparece sin custom nodes → un custom node es responsable
    • Continúa con una búsqueda binaria
  • El problema persiste → los custom nodes no son la causa
    • Revisa el core de ComfyUI, los requisitos del sistema, el controlador de la GPU y Python/PyTorch
    • Revisa los archivos de modelo y sus rutas
    • Busca un pico de VRAM con Optimizar ComfyUI para 6 a 8 GB de VRAM

Dato variable: confirma las opciones de inicio con python main.py --help.

2. Aislar el nodo problemático mediante búsqueda binaria

Si el arranque seguro demuestra que un custom node es responsable, la búsqueda binaria reduce los candidatos sin adivinar.

Principio: mueve o activa la mitad de los custom nodes en cada prueba, observa el resultado y vuelve a dividir el grupo sospechoso.

Pasos:

  1. Hacer una copia de seguridad de ComfyUI/custom_nodes/
  2. Mover la mitad de las carpetas de nodos a un directorio temporal de prueba
  3. Iniciar ComfyUI y reproducir el problema
  4. Interpretar el resultado:
    • El problema desaparece → el nodo problemático está en la mitad movida
    • El problema continúa → está en la mitad que quedó activa
  5. Repetir hasta aislar un nodo o una interacción pequeña

Después de identificarlo:

  • Buscar el mismo traceback en los issues de GitHub
  • Revisar requirements.txt para detectar versiones fijadas estrictamente
  • Actualizar, sustituir, desactivar o eliminar el nodo
  • Si una versión nueva introdujo la regresión, probar el commit funcional anterior

Datos que conviene incluir en un issue:

  • Versión de ComfyUI
  • Error completo y pasos para reproducirlo
  • Sistema operativo
  • Resultado de la prueba --disable-all-custom-nodes
  • Versiones de Python, PyTorch, el controlador de la GPU y el hardware

Corregir salidas VAE grises, negras o incompatibles

Una salida gris, blanca, teñida o negra puede deberse a un VAE incompatible, una conexión de decodificación incorrecta, la precisión del VAE o la atención, o archivos específicos de un modelo reciente. Prueba en este orden.

1. Orden de comprobación del VAE

Pasos:

  1. Revisar la conexión del VAE

    • Conectar la salida VAE del checkpoint loader o de un VAE loader independiente al nodo de decodificación
    • Algunos checkpoints incluyen un VAE; otros modelos necesitan un archivo separado
  2. Relacionar VAE, modelo y workflow

    • SD1.5, SDXL, FLUX y SD3.x pueden necesitar combinaciones diferentes de VAE, text encoder y loader
    • Empezar por la plantilla de workflow oficial más pequeña o el ejemplo del README del modelo
  3. Revisar --fp16-vae

    • La documentación de Startup Flags indica que --fp16-vae puede producir imágenes negras
    • Quitarla o probar --fp32-vae / --bf16-vae si el hardware lo permite
  4. Probar opciones de precisión

    • --fp32-vae: ejecuta el VAE con precisión completa y suele consumir más VRAM
    • --bf16-vae: ejecuta el VAE en BF16, con hardware y backend compatibles
    • --cpu-vae: ejecuta el VAE en CPU y suele ser mucho más lento
    • --force-upcast-attention: comprueba si el upcast de atención corrige la imagen negra; no es un ajuste general de calidad
  5. Revisar por último VRAM, controladores y dependencias

    • Un pico de VRAM puede interrumpir la decodificación VAE
    • Revisar el controlador de la GPU según los requisitos actuales
    • Comprobar que PyTorch coincida con el backend de la GPU

Síntomas habituales:

SíntomaCausa posible
Gris, blanco o teñidoVAE incorrecto, ruta de decodificación errónea o incompatibilidad entre workflow y modelo
Completamente negro--fp16-vae, precisión de atención, pico de VRAM o combinación de modelos no válida
Error de cargaVAE dañado, ruta incorrecta o archivos incompletos

2. Riesgo de imagen negra con VAE fp16

Muchos tutoriales recomiendan --fp16-vae para reducir el uso de recursos. Sin embargo, la referencia oficial Startup Flags advierte que puede producir imágenes negras. Decide según el modelo, el hardware y los registros.

Opciones de precisión del VAE:

OpciónEfectoCuándo probarla
--fp16-vaeEjecuta el VAE en FP16 y suele reducir recursosPuede producir imágenes negras; úsala con precaución
--fp32-vaeEjecuta el VAE con precisión completaÚtil para diagnosticar imágenes negras, normalmente con más VRAM
--bf16-vaeEjecuta el VAE en BF16Requiere hardware y backend compatibles
--cpu-vaeEjecuta el VAE en CPUPrueba para VRAM limitada; suele ser más lento

Precisión de atención:

  • --force-upcast-attention: prueba si el upcast de atención corrige la imagen negra
  • --dont-upcast-attention: es incompatible con la opción anterior y está reservada para depuración

Orden práctico:

  • No copies «opciones de aceleración» sin leer el síntoma y la salida de consola
  • Para una imagen negra, elimina primero --fp16-vae; después prueba --fp32-vae o --force-upcast-attention según el entorno
  • Confirma los nombres y valores predeterminados con el python main.py --help vigente
  • El recorrido completo para OOM y poca VRAM está en Optimizar ComfyUI para 6 a 8 GB de VRAM

3. Distinguir una incompatibilidad entre VAE y modelo

Si cambiar el modelo o el VAE rompe un workflow que funcionaba, probablemente no coincidan el modelo, el VAE, el loader o la plantilla del workflow. Cada familia exige sus propios archivos y nodos.

Comprobación por familia:

FamiliaComprobación del VAEComprobación del loader/workflow
Checkpoint SD1.5Usar el VAE integrado o uno compatible con SD1.5Empezar por un workflow básico compatible con SD1.5
Checkpoint SDXLUsar el VAE integrado o uno compatible con SDXLUsar una plantilla de workflow y un loader compatibles con SDXL
FLUX / SD3.xPreparar el VAE y el text encoder según el READMESeguir la plantilla oficial o la documentación del proyecto

Diagnóstico:

  1. Revisar el README del modelo, la página del proyecto o la plantilla oficial
    • Confirmar el VAE integrado, los pesos adicionales y el loader requerido
  2. Revisar los archivos elegidos en cada loader
    • El VAE del menú debe coincidir con el modelo y el workflow
  3. Reproducir el problema con la plantilla oficial más pequeña
    • Retirar el procesamiento personalizado y volver a conectar los nodos uno a uno

Correspondencia de síntomas:

SíntomaCausa probable
Gris, blanco o teñidoVAE, modelo o ruta de decodificación incompatibles
Error de cargaVAE dañado, ruta incorrecta o archivos incompletos
El workflow mínimo funciona, el original fallaUn procesamiento o custom node modifica la decodificación

Para elegir con más detalle, consulta Elegir un modelo de Stable Diffusion.

Estrategia de actualización: stable, development, copia y reversión

Una actualización de ComfyUI puede romper un workflow que funcionaba el día anterior. Development contiene los últimos commits, pero también puede incluir problemas abiertos. Stable prioriza la estabilidad con cierto retraso. Registrar las versiones y conservar una ruta de vuelta es mejor que ejecutar otra actualización global después del primer fallo.

1. Hacer una copia antes de elegir stable o development

Lista previa a la actualización:

  1. Registrar el commit actual de ComfyUI

    • Git: git rev-parse HEAD
    • Portable o Desktop: registrar la versión y el canal de actualización
  2. Registrar Python y PyTorch

    • Python: python --version
    • PyTorch: python -c "import torch; print(torch.__version__)"
    • En NVIDIA, registrar el controlador con nvidia-smi
  3. Registrar las versiones de los custom nodes importantes

    • Exportar o guardar la lista de Manager
    • Registrar los commits de los nodos críticos para producción
  4. Hacer copia de los workflows y la configuración

    • Exportar los archivos JSON importantes a otro directorio
    • Guardar extra_model_paths.yaml, la configuración de modelos externos de Desktop y los datos importantes del usuario

Stable o Development:

Tipo de versiónCaracterísticasUso adecuado
Stable / ReleaseVersión estabilizada, quizá por detrás de algunas funcionesProducción y entornos duraderos
Development / LatestÚltimos commits y acceso anticipado a funcionesProbar nuevos modelos, funciones y compatibilidad
Commit fijadoEstado conocido sin correcciones posteriores automáticasReversión temporal, aislamiento de una regresión y reproducción

Estrategia por instalación:

InstalaciónEstrategia
DesktopCanal stable de forma predeterminada; elegir otro desde la interfaz de gestión vigente si hace falta
Portableupdate_comfyui_stable.bat sigue stable y update_comfyui.bat sigue development
Manual GitEjecutar git pull y actualizar requirements.txt dentro del entorno de ComfyUI; cambiar de commit para volver

Dato variable: confirma los nombres de los scripts y los ajustes de Desktop en la documentación de actualización vigente.

2. Revertir después de una actualización fallida

Primero identifica si cambió el core, un solo custom node o el entorno de Python.

Clasificar el cambio:

  1. Solo se actualizó el core de ComfyUI

    • Probar si el core inicia con --disable-all-custom-nodes
    • Comprobar si los custom nodes requieren una versión compatible
  2. Solo se actualizó un custom node

    • Restaurar su versión anterior
    • O desactivarlo y volver a probar ComfyUI
  3. Se actualizaron las dependencias

    • Volver a comprobar Python, PyTorch y los paquetes críticos
    • update_comfyui_and_python_dependencies.bat de Portable reinstala todas las dependencias; la documentación advierte que puede generar conflictos y romper nodos vinculados a versiones concretas

Reversión con Git:

# Mostrar commits recientes
git log --oneline

# Volver a un commit que se sabe funcional
git checkout <commit-hash>

# Actualizar dependencias solo en el entorno de ComfyUI correspondiente
pip install -r requirements.txt

Las rutas de reversión de Portable y Desktop pueden cambiar. Es preferible restaurar la copia previa y seguir la documentación vigente. Desinstalar de inmediato elimina versiones y ajustes útiles para diagnosticar.

Datos para un issue de custom node:

  • Error completo y pasos para reproducirlo
  • Versiones de ComfyUI, Python, PyTorch y el controlador de la GPU
  • Resultado de la prueba --disable-all-custom-nodes
  • Versiones del core o del nodo antes y después de la actualización

Próximos pasos

Cuando el entorno vuelva a ser estable, continúa con el tema de ComfyUI que corresponda:

  1. Reproducir un workflow compartido

  2. Reducir el uso de VRAM

  3. Upscaling e inpainting

  4. Crear videos

  5. Automatizar con la API

  6. Elegir modelos y VAE

Solucionar problemas de ComfyUI con cambios mínimos

Parte de los registros y síntomas para aislar problemas de nodos, dependencias, modelos, VRAM y versiones.

  1. 1

    Step 1: Conservar el estado inicial

    Exporta el workflow y registra Show report, el final de la consola y las versiones de ComfyUI, Python, PyTorch y el controlador de la GPU.
  2. 2

    Step 2: Clasificar el síntoma

    Para un nodo rojo, comprueba el tipo; para Import failed, las dependencias; para una pantalla en blanco, los custom nodes; para una salida anómala, el VAE; para OOM, el pico de VRAM.
  3. 3

    Step 3: Aislar los custom nodes

    Inicia con --disable-all-custom-nodes. Si el problema desaparece, reactiva la mitad de los nodos en cada prueba hasta encontrar al responsable.
  4. 4

    Step 4: Revisar el entorno

    Confirma que las dependencias están instaladas en el Python propio de ComfyUI y revisa requirements.txt, PyTorch y el backend de la GPU.
  5. 5

    Step 5: Comprobar modelos y precisión

    Haz coincidir archivos de modelo, loader, VAE y plantilla del workflow; para una imagen negra, prueba las opciones de precisión del VAE y la atención.
  6. 6

    Step 6: Revertir o reconstruir

    Si una actualización rompe el entorno, restaura la versión sospechosa del core o del nodo. Crea un entorno limpio solo cuando las dependencias se hayan sobrescrito sin una ruta clara de vuelta.

FAQ

¿Cómo se corrigen los nodos rojos en ComfyUI?
Comprueba si falta el tipo de nodo, cambió de nombre o dejó de cargar. Busca su nombre en Manager, Registry o el README del workflow. Si solo falta un modelo en el loader, revisa ComfyUI/models y el loader en lugar de instalar más nodos.
¿Qué significa Import failed en ComfyUI?
Python no pudo cargar un custom node. Las causas habituales son dependencias instaladas fuera del Python de ComfyUI, un wheel específico de la plataforma que falta o versiones de paquetes incompatibles entre varios nodos.
¿Qué hago si ComfyUI queda en loading o muestra una página en blanco?
Ejecuta python main.py --disable-all-custom-nodes. Si se abre la interfaz, aísla el custom node mediante búsqueda binaria. Si no, revisa el core, el sistema, el controlador de la GPU y el entorno de Python o PyTorch.
¿ComfyUI Manager puede corregir todos los nodos ausentes?
No. Manager instala, elimina, desactiva y activa custom nodes, pero los errores de red, conflictos de Python, nodos renombrados, modelos ausentes y problemas de ejecución requieren diagnósticos separados.
¿Cómo se corrige una salida VAE gris o negra en ComfyUI?
Haz coincidir primero el archivo VAE, el loader, la arquitectura del modelo y el workflow. Para una imagen negra, revisa --fp16-vae y prueba, según el hardware, --fp32-vae, --cpu-vae o el upcast de atención.
¿Qué hago si una actualización de ComfyUI rompe un workflow?
Detén las actualizaciones globales, registra las versiones del core, los custom nodes, Python y PyTorch, y prueba sin custom nodes. Luego actualiza, desactiva o restaura el nodo o el commit del core más sospechoso.

15 min de lectura · Publicado el: 28 ago 2026 · Actualizado el: 28 ago 2026

Comentarios

Inicia sesión con GitHub para dejar un comentario

Easton BlogEaston Blog