Risolvere gli errori di ComfyUI: nodi rossi, VAE e versioni

Apri un workflow condiviso e trovi una fila di unknown nodes rossi. Esegui Install Missing Custom Nodes in Manager, riavvii ComfyUI, ma restano rossi. Manager non è uno strumento di riparazione universale: gestisce il codice dei nodi, ma non garantisce la corretta installazione di tutte le dipendenze e non installa i file dei modelli.

I nodi rossi sono solo uno dei punti di partenza per risolvere i problemi di ComfyUI. L’applicazione può restare su loading, l’interfaccia può diventare bianca, un workflow prima funzionante può rompersi dopo un aggiornamento, l’output VAE può diventare grigio o nero oppure un modello copiato può non comparire nel menu a discesa. Questi sintomi rimandano spesso a conflitti tra custom node, versioni delle dipendenze, percorsi dei modelli, opzioni di precisione o picchi di VRAM.

Il percorso più breve parte dal sintomo: identifica il livello più probabile, quindi esegui il test minimo che permetta di confermare o escludere l’ipotesi.

Tabella rapida per sintomo

La tabella copre sei punti di ingresso comuni. Trova il sintomo nella prima colonna, restringi la causa con la seconda e parti dalla terza.

Sintomo	Causa più probabile	Prima azione
Nodi rossi / unknown nodes	Custom node assente, nodo rinominato o import fallito	Cercare il nome in Manager o Registry e controllare Import failed nella console
Blocco su loading / pagina bianca / blank screen	Conflitto con un’estensione frontend di un custom node	Provare python main.py --disable-all-custom-nodes
Prompt execution failed dopo Queue	Errore di custom node, problema del modello o VRAM insufficiente	Aprire Show report e identificare il componente che ha generato l’errore
Output VAE grigio, bianco, alterato o nero	VAE incompatibile o precisione errata	Controllare la connessione del VAE loader, i file associati e --fp16-vae
Workflow rotto dopo l’aggiornamento	Incompatibilità tra core e custom node o conflitto di dipendenze	Identificare che cosa è stato aggiornato ed esaminare gli script di update
Modello copiato assente dal menu	Percorso errato o definizioni dei nodi non aggiornate	Controllare la sottocartella in ComfyUI/models/, poi riavviare o aggiornare

Non eliminare subito l’installazione. Salva workflow, log, elenco dei nodi e versioni prima di modificare l’ambiente.

Nodo rosso: custom node o modello?

Un unknown node rosso significa in genere che ComfyUI non trova quel tipo di nodo. Il custom node può mancare, essere stato rinominato o disattivato, oppure fallire durante l’import delle dipendenze. Un modello assente tende invece a sparire dal menu del loader o a produrre un errore del modello durante l’esecuzione. Separa queste due classi di guasto.

1. Che cosa corregge Install Missing in Manager

Install Missing Custom Nodes di ComfyUI-Manager risolve soprattutto l’assenza del codice di un nodo. Manager installa i nodi tramite Registry o un repository sorgente, ma gli elementi seguenti possono richiedere un intervento separato:

• Le dipendenze Python del nodo, come torch, numpy o xformers in requirements.txt
• I file dei modelli: checkpoint, VAE, LoRA e ControlNet
• I percorsi dei modelli specifici del custom node, indicati nel README

Comfy Desktop include Manager e lo abilita per impostazione predefinita. Nelle installazioni Portable e Manual attuali, il nuovo Manager è integrato nel core di ComfyUI, ma occorre installare manager_requirements.txt e avviare con --enable-manager. Se un nodo non compare in Manager, potrebbe non essere registrato oppure un problema di rete potrebbe limitare l’elenco ai dati locali o in cache. Verifica il repository originale prima di installare un pacchetto dal nome simile.

Segui questo ordine: cercare Import failed nella console → cercare il nodo in Manager o Registry → verificare il percorso del modello. Il processo completo di importazione è descritto in Riutilizzare un workflow di ComfyUI.

2. Leggere correttamente Import failed

Quando la console mostra Import failed, la fine del traceback contiene in genere il modulo assente o la versione in conflitto. La classe dell’errore determina il passo successivo:

Albero decisionale:

1. ModuleNotFoundError: No module named 'xxx' → pacchetto Python assente

   • Non installarlo nel Python di sistema, ma nell’ambiente Python di ComfyUI
   • Portable: python_embeded\python.exe -m pip install -r custom_nodes\xxx\requirements.txt
   • Desktop e Manual usano percorsi diversi; individua l’eseguibile Python realmente usato da ComfyUI

2. Errori torch / CUDA / cuDNN → PyTorch e backend GPU non corrispondono

   • Verificare PyTorch: python -c "import torch; print(torch.__version__)"
   • Controllare che il driver GPU rispetti i requisiti di sistema attuali
   • Un nodo può richiedere una versione di torch incompatibile con quella di ComfyUI

3. Eccezione nel custom node → versione del nodo o difetto del codice

   • Cercare lo stesso traceback nelle issue GitHub del nodo
   • Se una nuova versione ha introdotto la regressione, provare un commit noto come funzionante

Informazione variabile: al momento del packaging, ComfyUI consiglia Python 3.13 e propone 3.12 come alternativa quando alcune dipendenze dei custom node falliscono con 3.13. I requisiti di PyTorch e CUDA cambiano rapidamente; consulta i requisiti di sistema attuali.

3. Installato in Manager, ma ancora non disponibile

Lo stato “installato” non dimostra che il nodo venga caricato. Dopo il riavvio può restare rosso o generare un conflitto tra torch e torchvision.

Perché un nodo installato può restare indisponibile:

• Un errore di rete ha interrotto il download del repository o delle dipendenze
• I requirements Python non sono stati installati nell’ambiente di ComfyUI
• Il nodo è disattivato o fallisce durante l’import
• La sua versione non è compatibile con la versione attuale di ComfyUI

Perché le dipendenze entrano in conflitto:

• Più custom node richiedono versioni diverse di torch, torchvision o numpy
• Una versione fissata rigidamente in requirements.txt entra in conflitto con i pacchetti esistenti

Ordine di risoluzione:

1. Leggere l’ultimo traceback completo e classificarlo con la sezione precedente
2. Disattivare o rimuovere il nodo sospetto, quindi provare di nuovo ComfyUI
3. Cercare in requirements.txt versioni rigide come torch==2.4.1
4. Se il conflitto continua, aprire una issue con:
   • Il traceback completo
   • Il risultato di python main.py --disable-all-custom-nodes
   • Le versioni di Python, PyTorch e driver GPU

Informazione variabile: Manager coesiste in forma nuova integrata e legacy. Segui la documentazione attuale per etichette e menu. Se la causa reale è OOM o un picco di VRAM, continua con Ottimizzare ComfyUI per 6-8 GB di VRAM.

4. Percorsi dei modelli e menu vuoti

ComfyUI non include i pesi dei modelli. Scarica separatamente checkpoint, VAE, LoRA, ControlNet e upscaler, quindi inseriscili nella sottocartella corrispondente di ComfyUI/models/.

Ordine di verifica se il file non compare:

1. Cartella corretta

   • Checkpoint in ComfyUI/models/checkpoints/
   • VAE in ComfyUI/models/vae/
   • LoRA, ControlNet e upscaler nelle rispettive cartelle per tipo
   • Se un custom node usa un altro percorso, segui il suo README

2. Riavvio o aggiornamento

   • Riavviare ComfyUI o usare l’aggiornamento delle definizioni supportato dall’interfaccia attuale

3. Integrità del file

   • Confrontare la dimensione con la fonte del download
   • Scaricare di nuovo o verificare un file incompleto

4. Loader compatibile

   • Scegliere un loader e un template di workflow progettati per quella famiglia di modelli
   • FLUX, SD3.x e altre architetture recenti possono richiedere text encoder, VAE e combinazioni di nodi specifici
   • I percorsi di un custom node possono differire dalle indicazioni generali di ComfyUI/models/

5. extra_model_paths.yaml

   • Portable e Manual possono fare riferimento a librerie esterne con extra_model_paths.yaml; riavvia dopo il salvataggio
   • Desktop ha un proprio file di configurazione per i modelli esterni; usa il percorso ufficiale attuale

Per abbinare modello e VAE, consulta Scegliere un modello Stable Diffusion.

Diagnosticare un blocco del caricamento con —disable-all-custom-nodes

Quando ComfyUI resta su loading, mostra una pagina bianca o non esegue più il rendering dell’interfaccia, spesso è coinvolta un’estensione frontend di un custom node. --disable-all-custom-nodes permette di capire rapidamente se la causa sono i custom node.

1. Avviare senza custom node

Comando:

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

Windows Portable:

Copia run_nvidia_gpu.bat o run_cpu.bat, aggiungi --disable-all-custom-nodes al comando di avvio e salva uno script separato per l’avvio sicuro.

Interpretazione:

• Il problema scompare senza custom node → un custom node è responsabile
  • Continua con una ricerca binaria
• Il problema persiste → i custom node non sono la causa
  • Controlla core ComfyUI, requisiti di sistema, driver GPU e Python/PyTorch
  • Controlla i file dei modelli e i relativi percorsi
  • Cerca un picco di VRAM con Ottimizzare ComfyUI per 6-8 GB di VRAM

Informazione variabile: conferma le opzioni di avvio con python main.py --help.

2. Isolare il nodo problematico con la ricerca binaria

Se l’avvio sicuro dimostra che un custom node è responsabile, la ricerca binaria riduce i candidati senza procedere per tentativi casuali.

Principio: sposta o attiva metà dei custom node a ogni prova, osserva il risultato e dividi di nuovo il gruppo sospetto.

Passaggi:

1. Eseguire il backup di ComfyUI/custom_nodes/
2. Spostare metà delle cartelle dei nodi in una directory temporanea di test
3. Avviare ComfyUI e riprodurre il problema
4. Interpretare il risultato:
   • Il problema scompare → il nodo problematico si trova nella metà spostata
   • Il problema resta → si trova nella metà mantenuta
5. Ripetere finché non si isola un nodo o una piccola interazione

Dopo l’identificazione:

• Cercare lo stesso traceback nelle issue GitHub
• Esaminare requirements.txt alla ricerca di versioni fissate rigidamente
• Aggiornare, sostituire, disattivare o rimuovere il nodo
• Se una nuova versione ha introdotto la regressione, provare il commit funzionante precedente

Informazioni da includere in una issue:

• Versione di ComfyUI
• Errore completo e passaggi per riprodurlo
• Sistema operativo
• Risultato del test --disable-all-custom-nodes
• Versioni di Python, PyTorch, driver GPU e hardware

Correggere output VAE grigi, neri o incompatibili

Un output grigio, bianco, alterato o nero può dipendere da un VAE incompatibile, un collegamento di decodifica errato, la precisione del VAE o dell’attenzione oppure file specifici di un modello recente. Procedi in questo ordine.

1. Ordine di verifica del VAE

Passaggi:

1. Controllare il collegamento VAE

   • Collegare l’uscita VAE del checkpoint loader o di un VAE loader separato al nodo di decodifica
   • Alcuni checkpoint includono un VAE; altri modelli richiedono un file separato

2. Abbinare VAE, modello e workflow

   • SD1.5, SDXL, FLUX e SD3.x possono richiedere combinazioni diverse di VAE, text encoder e loader
   • Partire dal template di workflow ufficiale più piccolo o dall’esempio nel README del modello

3. Controllare --fp16-vae

   • La documentazione Startup Flags indica che --fp16-vae può produrre immagini nere
   • Rimuoverlo o provare --fp32-vae / --bf16-vae se l’hardware lo consente

4. Provare le opzioni di precisione

   • --fp32-vae: esegue il VAE a precisione completa e in genere usa più VRAM
   • --bf16-vae: esegue il VAE in BF16 con hardware e backend compatibili
   • --cpu-vae: esegue il VAE sulla CPU e in genere è molto più lento
   • --force-upcast-attention: verifica se l’upcast dell’attenzione corregge l’immagine nera; non è un’impostazione generale di qualità

5. Controllare infine VRAM, driver e dipendenze

   • Un picco di VRAM può interrompere la decodifica VAE
   • Controllare il driver GPU secondo i requisiti attuali
   • Verificare che PyTorch corrisponda al backend GPU

Sintomi comuni:

Sintomo	Possibile causa
Grigio, bianco o alterato	VAE errato, percorso di decodifica sbagliato o incompatibilità tra workflow e modello
Completamente nero	--fp16-vae, precisione dell’attenzione, picco di VRAM o combinazione di modelli non valida
Errore di caricamento	VAE danneggiato, percorso errato o file incompleti

2. Rischio di immagini nere con VAE fp16

Molti tutorial consigliano --fp16-vae per ridurre l’uso delle risorse. Il riferimento ufficiale Startup Flags avverte però che può produrre immagini nere. Decidi in base al modello, all’hardware e ai log.

Opzioni di precisione del VAE:

Opzione	Effetto	Quando provarla
--fp16-vae	Esegue il VAE in FP16 e spesso riduce le risorse	Può produrre immagini nere; usare con cautela
--fp32-vae	Esegue il VAE a precisione completa	Utile per diagnosticare immagini nere, in genere con più VRAM
--bf16-vae	Esegue il VAE in BF16	Richiede hardware e backend compatibili
--cpu-vae	Esegue il VAE sulla CPU	Test per VRAM limitata, in genere più lento

Precisione dell’attenzione:

• --force-upcast-attention: verifica se l’upcast dell’attenzione corregge l’immagine nera
• --dont-upcast-attention: non è compatibile con l’opzione precedente ed è riservato al debug

Ordine pratico:

• Non copiare “opzioni di accelerazione” senza leggere il sintomo e l’output della console
• Per un’immagine nera, rimuovi prima --fp16-vae, poi prova --fp32-vae o --force-upcast-attention secondo l’ambiente
• Conferma nomi e valori predefiniti con il python main.py --help attuale
• Il percorso completo per OOM e poca VRAM è in Ottimizzare ComfyUI per 6-8 GB di VRAM

3. Distinguere un’incompatibilità tra VAE e modello

Se cambiare modello o VAE rompe un workflow che funzionava, probabilmente modello, VAE, loader o template del workflow non corrispondono. Ogni famiglia richiede file e nodi propri.

Controllo per famiglia:

Famiglia	Controllo VAE	Controllo loader/workflow
Checkpoint SD1.5	Usare il VAE integrato o un VAE compatibile con SD1.5	Partire da un workflow di base compatibile con SD1.5
Checkpoint SDXL	Usare il VAE integrato o un VAE compatibile con SDXL	Usare template di workflow e loader compatibili con SDXL
FLUX / SD3.x	Preparare VAE e text encoder secondo il README	Seguire il template ufficiale o la documentazione del progetto

Diagnosi:

1. Controllare il README del modello, la pagina del progetto o il template ufficiale
   • Confermare il VAE integrato, i pesi aggiuntivi e il loader richiesto
2. Controllare i file selezionati in ogni loader
   • Il VAE del menu deve corrispondere al modello e al workflow
3. Riprodurre il problema con il template ufficiale più piccolo
   • Rimuovere l’elaborazione personalizzata e ricollegare i nodi uno alla volta

Corrispondenza dei sintomi:

Sintomo	Causa probabile
Grigio, bianco o alterato	VAE, modello o percorso di decodifica incompatibile
Errore di caricamento	VAE danneggiato, percorso errato o file incompleti
Workflow minimo funzionante, originale in errore	Un’elaborazione o un custom node modifica la decodifica

Per le scelte dettagliate, consulta Scegliere un modello Stable Diffusion.

Strategia di aggiornamento: stable, development, backup e rollback

Un aggiornamento di ComfyUI può rompere un workflow che funzionava il giorno prima. Development contiene gli ultimi commit, ma può includere anche problemi ancora aperti. Stable privilegia la stabilità con un certo ritardo. Registrare le versioni e conservare una via di ritorno è meglio che eseguire un altro aggiornamento globale dopo il primo guasto.

1. Eseguire il backup prima di scegliere stable o development

Elenco prima dell’aggiornamento:

1. Annotare il commit ComfyUI attuale

   • Git: git rev-parse HEAD
   • Portable o Desktop: annotare versione e canale di aggiornamento

2. Annotare Python e PyTorch

   • Python: python --version
   • PyTorch: python -c "import torch; print(torch.__version__)"
   • Su NVIDIA, annotare il driver con nvidia-smi

3. Annotare le versioni dei custom node importanti

   • Esportare o salvare l’elenco di Manager
   • Annotare i commit dei nodi critici per la produzione

4. Eseguire il backup di workflow e configurazione

   • Esportare i file JSON importanti in una directory separata
   • Salvare extra_model_paths.yaml, la configurazione Desktop dei modelli esterni e i dati utente importanti

Stable o Development:

Tipo di versione	Caratteristiche	Uso adatto
Stable / Release	Versione stabilizzata, talvolta indietro rispetto alle funzioni	Produzione e ambienti duraturi
Development / Latest	Commit più recenti e accesso anticipato alle funzioni	Test di nuovi modelli, funzioni e compatibilità
Commit fissato	Stato noto senza correzioni automatiche successive	Rollback temporaneo, isolamento di una regressione e riproduzione

Strategia per installazione:

Installazione	Strategia
Desktop	Canale stable predefinito; se necessario scegliere un altro canale dall’interfaccia di gestione attuale
Portable	update_comfyui_stable.bat segue stable, update_comfyui.bat segue development
Manual Git	Eseguire git pull, quindi aggiornare requirements.txt nell’ambiente ComfyUI; cambiare commit per tornare indietro

Informazione variabile: conferma i nomi degli script e le impostazioni Desktop nella documentazione di aggiornamento attuale.

2. Tornare indietro dopo un aggiornamento non riuscito

Identifica prima se è cambiato il core, un solo custom node o l’ambiente Python.

Classificare la modifica:

1. È stato aggiornato solo il core ComfyUI

   • Verificare se il core si avvia con --disable-all-custom-nodes
   • Controllare se i custom node richiedono una versione compatibile

2. È stato aggiornato un solo custom node

   • Ripristinare la versione precedente
   • Oppure disattivarlo e provare di nuovo ComfyUI

3. Sono state aggiornate le dipendenze

   • Ricontrollare Python, PyTorch e i pacchetti critici
   • update_comfyui_and_python_dependencies.bat di Portable reinstalla tutte le dipendenze; la documentazione avverte che può creare conflitti e rompere i nodi vincolati a versioni specifiche

Rollback con Git:

# Mostrare i commit recenti
git log --oneline

# Tornare a un commit noto come funzionante
git checkout <commit-hash>

# Aggiornare le dipendenze solo nell’ambiente ComfyUI corrispondente
pip install -r requirements.txt

I percorsi di rollback di Portable e Desktop possono cambiare. Preferisci ripristinare il backup precedente e seguire la documentazione attuale. Una disinstallazione immediata elimina versioni e impostazioni utili per la diagnosi.

Informazioni per una issue di custom node:

• Errore completo e passaggi per riprodurlo
• Versioni di ComfyUI, Python, PyTorch e driver GPU
• Risultato del test --disable-all-custom-nodes
• Versioni del core o del nodo prima e dopo l’aggiornamento

Passi successivi

Quando l’ambiente è stabile, continua con l’argomento ComfyUI pertinente:

1. Riprodurre un workflow condiviso

   • Importare il workflow, completare nodi e modelli e collegare i loader
   • Vedi Riutilizzare un workflow di ComfyUI

2. Ridurre l’uso della VRAM

   • Passare da OOM o picco di VRAM a --lowvram, VAE e quantizzazione
   • Vedi Ottimizzare ComfyUI per 6-8 GB di VRAM

3. Upscaling e inpainting

   • Ripristinare workflow con FaceDetailer, Impact Pack e altri nodi di post-elaborazione
   • Vedi Upscaling e inpainting in ComfyUI

4. Creare video

   • Risolvere workflow video, VAE video ed errori della fase finale
   • Vedi Creare video con ComfyUI

5. Automatizzare con l’API

   • Usare API format, /prompt, node_errors e gestione della coda
   • Vedi Automatizzare batch di immagini con l’API ComfyUI

6. Scegliere modelli e VAE

   • Confrontare checkpoint, VAE, LoRA e configurazioni dei loader
   • Vedi Scegliere un modello Stable Diffusion