Guida completa al riuso dei workflow ComfyUI: checklist da importazione a riproduzione

Dopo aver importato il workflow ComfyUI di qualcun altro, potresti trovarti davanti a una schermata piena di nodi rossi e a una lista di modelli vuota. La prima volta che mi è successo, ci ho messo mezz’ora a capire che il problema rientrava in tre categorie: nodi mancanti, percorsi dei modelli sbagliati e dipendenze Python non installate. Questa guida non spiega come installare ComfyUI. Si concentra su una domanda precisa: quando ricevi un workflow JSON o un PNG, come completi ciò che manca, lo depuri passo dopo passo e riproduci qualcosa di vicino all’immagine di esempio? Il punto centrale è una checklist riutilizzabile, dall’import all’archiviazione.

Perché il workflow di un’altra persona non parte

Un workflow ComfyUI è, in sostanza, un grafo di nodi collegati. JSON o metadata PNG registra tipi di nodi, valori dei parametri e connessioni, ma non contiene file dei modelli, plugin di custom node o dipendenze Python. Quando importi un workflow condiviso, ciò che manca nel tuo ambiente locale emerge subito.

Un nodo rosso significa che ComfyUI non trova il tipo di nodo corrispondente. Alcuni sono nodi integrati, cioè core node, e non dovrebbero mancare. Altri sono estensioni di terze parti, cioè custom node, che magari non hai installato. Dopo aver completato i nodi, il menu di Load Checkpoint o Load LoRA può restare vuoto: il file del modello non è nella directory predefinita, oppure la configurazione del percorso è errata. Anche dopo questo passaggio, alcuni custom node possono segnalare pacchetti Python mancanti, come insightface o onnxruntime.

Questi tre tipi di problemi si sommano. Un workflow può richiedere tre custom node, due modelli checkpoint e un pacchetto Python nello stesso momento. Senza un ordine di diagnosi, è facile bloccarsi su un passaggio e installare un mucchio di cose inutili. La checklist più sotto separa i problemi e li affronta per priorità.

Due fonti di workflow: JSON vs metadata PNG

Quando qualcuno condivide un workflow, di solito usa uno di due supporti: un file JSON autonomo oppure un’immagine PNG con metadata. Il JSON è il formato nativo esportato da ComfyUI e conserva le informazioni sui nodi. La metadata PNG è una forma incorporata: alcune immagini generate includono i dati del workflow nel file, ma solo se chi le ha create li ha conservati.

Trascinare un file JSON

Quando ricevi un file JSON, trascinalo direttamente nell’interfaccia di ComfyUI. L’interfaccia carica il grafo dei nodi e mostra tutte le connessioni. È il modo più affidabile: il JSON non dipende dalla compressione dell’immagine e conserva integre le informazioni sui nodi.

Se il JSON è stato esportato da ComfyUI, il layout importato dovrebbe coincidere con quello dell’autore. Se appare disordinato, potrebbe dipendere da una differenza di versione di ComfyUI al momento dell’export, oppure da un JSON modificato a mano.

Condizioni per caricare metadata PNG

Alcune immagini PNG generate con IA incorporano metadata del workflow. Puoi caricarle trascinando l’immagine in ComfyUI oppure scegliendo “Load” nel menu e selezionando il PNG.

La condizione è semplice: l’immagine deve ancora contenere la metadata. Molte piattaforme social e molti host di immagini comprimono i file o rimuovono la metadata durante l’upload, facendo sparire i dati del workflow. Se l’immagine arriva da un post social, è molto probabile che la metadata sia già stata rimossa e che trascinarla in ComfyUI produca solo una tela vuota.

Preferisci i file JSON. La metadata PNG è utile quando l’autore conserva il proprio storico di generazione, ma non è un formato affidabile per condividere tra piattaforme.

Confronto tra JSON e metadata PNG

Prima di importare un workflow, controlla la fonte. Una lista dei nodi, una lista dei modelli o un README sono più sicuri di un JSON o di un PNG da soli.

Nodi rossi: distinguere Core Node e Custom Node

Dopo l’import possono comparire nodi rossi con titoli come “Missing” o “Unknown node type”. Non installare pacchetti a caso. Prima identifica il tipo di nodo, poi decidi dove cercare.

Differenza tra Core Node e Custom Node

Un core node è un nodo integrato in ComfyUI. Arriva con il programma principale e non dovrebbe mancare. Esempi comuni: Load Checkpoint, KSampler, VAE Decode, Save Image. Se questi nodi sono rossi, l’installazione di ComfyUI potrebbe essere incompleta o troppo vecchia.

Railway - Piattaforma di deploy moderna, senza operazioni complesse, online in pochi minuti

Inizia ora →Pubbl.

Un custom node è un’estensione di terze parti da installare separatamente. Esempi comuni: IP-Adapter Apply, ControlNet Apply, FaceDetailer. La maggior parte dei nodi rossi nasce da custom node mancanti.

Il modo pratico per distinguerli è guardare il nome. Se include prefissi noti di estensioni, come IPAdapter, ControlNet o Impact, quasi sicuramente è un custom node. Se non sei sicuro, fai clic destro nell’interfaccia ComfyUI e cerca il nome in “Add Node”. Un core node compare nella lista predefinita; un custom node assente no.

Come trovare un Custom Node

Una volta confermato che si tratta di un custom node, hai tre percorsi di ricerca.

ComfyUI Registry: è la piattaforma di registro consigliata dal progetto. Vai su registry.comfy.org e cerca per nome del nodo o dell’estensione. Registry di solito mostra origine, metodo di installazione e dipendenze. Alcuni nodi supportano l’installazione con un clic, se la tua versione di ComfyUI lo permette.

ComfyUI Manager: è uno strumento di terze parti per gestire estensioni. Se lo hai installato, apri ComfyUI, vai in “Manager” -> “Install Custom Nodes” e cerca il nome del nodo. Manager elenca le estensioni corrispondenti e mostra lo stato di installazione. Non è una funzione core di ComfyUI; la sua stabilità dipende dalla manutenzione della community.

Ricerca su GitHub: se Registry e Manager non trovano nulla, cerca il nome del nodo su GitHub. Molti autori documentano i nomi dei nodi nel README. Quando trovi il repository, clonalo nella directory custom_nodes seguendo le istruzioni del README.

Problemi di dipendenze Python

Alcuni custom node richiedono pacchetti Python aggiuntivi. Per esempio, IP-Adapter può richiedere insightface, e alcune estensioni ControlNet possono richiedere onnxruntime.

Il metodo è entrare nella directory del custom node e leggere il README o requirements.txt. Dalla radice di ComfyUI, esegui:

pip install -r custom_nodes/directory-del-nodo/requirements.txt

Alcuni README indicano direttamente pip install nome-pacchetto. Segui le istruzioni del progetto.

Confermare prima quali nodi mancano davvero

Un workflow può riferirsi a molti custom node, ma potresti dover installare solo quelli che appaiono rossi dopo l’import. La lista dei nodi rossi è l’inventario reale delle mancanze. Non installare tutti i pacchetti popolari alla cieca: ogni pacchetto aumenta il tempo di avvio e il rischio di conflitti.

Modello non trovato? Controlla directory e libreria esterna

Dopo aver completato i nodi, i menu di Load Checkpoint, Load LoRA e Load VAE possono restare vuoti. I modelli referenziati nel workflow non viaggiano con il JSON; devi inserirli manualmente nella directory models di ComfyUI.

Struttura della directory models di ComfyUI

All’avvio, ComfyUI scansiona le sottocartelle dentro models e carica i modelli per tipo. Le directory più comuni sono:

Se il nodo Load Checkpoint del workflow specifica sdxl_base.safetensors, devi mettere quel modello in models/checkpoints/sdxl_base.safetensors. Il menu del nodo mostrerà automaticamente i modelli in quella cartella.

A cosa serve extra_model_paths.yaml

Se la tua libreria di modelli sta altrove, per esempio su un NAS condiviso o in una cartella centralizzata, non devi copiare ogni volta tutto in models. Puoi usare extra_model_paths.yaml per puntare a percorsi esterni.

Il file si trova nella radice di ComfyUI e usa YAML. Esempio:

my_custom_config:
  base_path: /path/to/external
  checkpoints: models/checkpoints
  loras: models/loras
  vae: models/vae
  controlnet: models/controlnet

All’avvio, ComfyUI scansiona i percorsi configurati e li combina con la directory models predefinita. Il formato può cambiare tra versioni; controlla la documentazione ufficiale o i messaggi di avvio se qualcosa non torna.

Confermare la versione del modello

Il workflow può indicare solo sdxl_base, ma nella pratica possono esistere più versioni: ufficiale, fine-tune della community, fp16, pruned. Versioni diverse possono produrre output molto diversi.

Quando ricevi un workflow, chiedi prima fonte e versione del modello. Se non c’è una nota, cerca il nome nella libreria corrispondente, come Civitai o Hugging Face, e controlla se l’autore ha indicato una versione pubblica. Scegli la versione segnalata dall’autore, non un file qualsiasi con lo stesso nome.

Questa guida non fornisce link diretti al download. Le licenze dei modelli sono troppo variabili. Qui è meglio registrare nomi e fonti, poi verificare l’autorizzazione per conto tuo.

Perché il risultato non coincide con l’immagine di esempio

Hai completato nodi e modelli, il workflow gira, ma l’output è molto diverso dall’immagine di esempio. Non significa per forza che hai sbagliato qualcosa. La differenza può dipendere da parametri, versione del modello o backend di esecuzione.

Vultr - Cloud server NVMe ad alte prestazioni, 32 location globali, deploy Docker con un clic

Vedi prezzi →Pubbl.

Tabella di impatto dei parametri

Questa tabella riassume quanto incidono i parametri più comuni. I parametri ad alto impatto vanno allineati con precisione; quelli a impatto minore possono essere regolati con più margine.

La versione del modello è il fattore più importante

Anche se scarichi un modello con lo stesso nome, una versione diversa può far deragliare completamente il risultato. Per esempio, sdxl_base può indicare il modello ufficiale, una variante fp16 della community o un fine-tune anime. Se l’autore usa l’originale e tu scarichi una variante anime, lo stile finale cambia del tutto.

Dopo aver ricevuto il workflow, conferma prima fonte e versione del modello. Se l’autore non le indica, guarda la pagina del modello e cerca le note di versione. Se non sei sicuro, chiedi all’autore invece di tirare a indovinare.

L’obiettivo è avvicinarsi a stile e composizione, non clonare l’immagine

Riprodurre un’immagine in modo identico richiede stessa versione del modello, seed allineato, tutti i parametri allineati e stesso ambiente di esecuzione. È difficile soddisfare tutte queste condizioni, soprattutto quando mancano seed e versione esatta del modello.

L’obiettivo pratico è avvicinarsi allo stile e alla composizione dell’immagine di esempio. Se soggetto, tonalità e struttura compositiva sono simili, la riproduzione è riuscita. Differenze sottili, come volto e texture, sono normali.

Checklist di troubleshooting per riusare workflow ComfyUI

La checklist seguente copre l’intero processo, dall’import all’archiviazione. Salvala e usala punto per punto ogni volta che riusi un workflow esterno.

Passo 1: confermare la fonte

Quando ricevi il workflow, controlla prima formato e informazioni di supporto.

• Verifica se è un file JSON o un’immagine PNG. Preferisci JSON; la metadata PNG può essere rimossa dalle piattaforme.
• Controlla se ci sono note associate: lista dei nodi, lista dei modelli, README o commento dell’autore.
• Se hai solo un PNG, prova a caricare la metadata. Se fallisce, la metadata è andata persa; chiedi il JSON all’autore o lascia perdere.
• Se la fonte non è chiara o una condivisione della community ha più di 12 mesi, trattala come meno affidabile.

Passo 2: completare i nodi

Dopo l’import, controlla i nodi rossi.

• Elenca tutti i nomi dei nodi rossi e conferma se sono core node o custom node.
• Core node mancante: controlla se l’installazione di ComfyUI è completa o se la versione è troppo vecchia.
• Custom node mancante:
  • Cerca il nome del nodo o del pacchetto in ComfyUI Registry.
  • Se hai Manager installato, cerca in “Install Custom Nodes”.
  • Se non trovi nulla, cerca il nome del nodo su GitHub e installa seguendo il README.
• Riavvia ComfyUI dopo aver installato il custom node.
• Verifica se i nodi rossi sono spariti. Se restano rossi, potrebbe mancare una dipendenza Python; entra nella directory del custom node, guarda requirements.txt ed esegui pip install -r requirements.txt.

Installa prima i nodi realmente mancanti. Non installare tutti i pacchetti popolari.

Passo 3: mappare i modelli

Dopo aver completato i nodi, controlla i nodi dei modelli.

• Elenca tutti i riferimenti ai modelli nel workflow: checkpoint, LoRA, VAE, ControlNet, IP-Adapter e così via.
• Controlla il tipo di ogni modello per sapere in quale sottocartella di models/ deve andare.
• Verifica se hai già un modello locale con lo stesso nome. Se sì, conferma che la versione coincida.
• Se non lo hai, cerca il nome in una libreria come Civitai o Hugging Face e verifica fonte e versione.
• Dopo il download, mettilo nella directory corretta oppure configura un percorso esterno con extra_model_paths.yaml.
• Riavvia ComfyUI e controlla che il modello appaia nel menu del nodo.

La versione del modello è il fattore che incide di più sulla riproduzione. Confermala prima di cambiare altri parametri.

Passo 4: bloccare i parametri

Con i modelli al loro posto, controlla i parametri del workflow.

• Verifica se il seed è fisso. Se non lo è, non puoi riprodurre la stessa immagine; puoi solo avvicinare lo stile.
• Controlla sampler, steps, CFG Scale e dimensione immagine.
• Verifica se è caricato un VAE e quali pesi hanno i LoRA.
• Confronta immagine di esempio e parametri, cercando differenze evidenti.
• Se l’autore ha indicato modifiche ai parametri, applicale.

I parametri possono essere stati ritoccati dall’autore. Se immagine di esempio e JSON non coincidono perfettamente, serve un allineamento manuale.

Passo 5: test minimo

Dopo aver controllato i parametri, fai prima una prova semplice.

• Esegui una volta con un prompt semplice, per esempio “a cat sitting on a chair”.
• Controlla che l’output sia normale: niente errori, niente immagine vuota, niente collasso evidente.
• Se compare un errore, leggi il log del terminale e individua il nodo o modello problematico.
• Se l’output è normale, regola prompt e parametri poco alla volta per avvicinarti all’esempio.
• Non partire con un prompt complesso. Un prompt complesso può nascondere problemi di nodi o modelli.

Passo 6: naming e archiviazione

Quando la riproduzione funziona, salva e organizza il workflow.

• Salva il workflow come nuovo file JSON.
• Formato consigliato: [tema]-[modello]-[data]-v1.json. Esempio: portrait-sdxl-base-20260623-v1.json.
• Registra le informazioni di versione del modello. Meglio usare un README.txt associato, non commenti dentro il JSON.
• Registra checkpoint e versione, nomi e pesi LoRA, VAE, parametri del sampler.
• Se in futuro lo condividi, aggiungi lista dei nodi, lista dei modelli, immagine di esempio e note sui parametri. Non condividere i file dei modelli.

Puoi copiare questa checklist in locale e spuntarla ogni volta che riusi un workflow.

Gestione dei workflow: convenzioni di nome e consigli di condivisione

Quando una riproduzione funziona, organizzare e archiviare evita di rifare lo stesso debug in futuro. Se condividi il workflow, informazioni complete riducono il tempo di troubleshooting di chi lo riceve.

🔥 Non sprecare mesi su prodotti senza domanda! Valida i punti di forza del tuo SaaS con Adsterra e un piccolo budget →

Testa ora →Pubbl.

Convenzione di nome

Nomi disordinati rendono difficile ritrovare il workflow giusto, soprattutto quando ne accumuli decine.

Formato consigliato: [tema]-[modello]-[data]-v1.json

Esempi:

• portrait-sdxl-base-20260623-v1.json: tema ritratto, modello SDXL Base, 23 giugno 2026, versione 1
• landscape-sd15-controlnet-20260620-v1.json: tema paesaggio, SD1.5 + ControlNet

Il tema può essere l’uso: portrait, landscape, anime, product, concept-art. Il modello è l’abbreviazione del checkpoint principale. La data usa il formato YYYYMMDD. v1, v2 distinguono le iterazioni.

Come registrare la versione dei modelli

Il JSON del workflow non registra la versione reale del file modello; registra solo il nome. Se nella libreria ci sono più versioni con lo stesso nome, la prossima volta potresti non sapere quale hai usato.

Due metodi:

Metodo 1: README.txt associato

Crea un README-[nome-file].txt nella stessa cartella e registra:

• nome del checkpoint e link di origine (non link diretto al download, solo URL della pagina del modello)
• nomi, pesi e fonti dei LoRA
• nome e fonte del VAE
• sampler, steps, CFG e dimensione
• altri parametri importanti

Usa README.txt come fonte principale per la versione dei modelli. È più compatibile e si condivide bene insieme a JSON e immagine di esempio.

Consigli per condividere un workflow

Quando condividi un workflow, informazioni complete aiutano chi lo riceve a partire velocemente.

Contenuti essenziali:

• File JSON: il workflow completo, l’elemento più importante.
• Lista dei nodi: tutti i custom node e la loro origine, per esempio link Registry o repository GitHub.
• Lista dei modelli: checkpoint, LoRA, VAE, ControlNet e altri modelli, con nomi e suggerimento di origine, senza link diretto al download.
• Immagine di esempio: un risultato generato, così l’altra persona sa quale obiettivo riprodurre.
• Note sui parametri: se i parametri del JSON non coincidono con l’immagine di esempio, indica quelli usati davvero.

Contenuti da non fornire:

• File dei modelli: le licenze sono complesse; non condividere direttamente i modelli.
• Link diretti al download: puoi indicare la pagina della libreria, ma i link diretti sono più rischiosi.
• Comandi di installazione dei pacchetti Python: se un custom node ha dipendenze speciali, indica il nome del pacchetto; lascia che chi riceve legga il README per il comando esatto.

Aggiungi un README breve con queste informazioni. Chi riceve potrà seguire la checklist punto per punto e arrivare al risultato molto più in fretta.

Prossime letture

Se non hai ancora installato ComfyUI, parti dalla guida completa introduttiva a ComfyUI per capire installazione, directory dei modelli e prima immagine. Per migliorare i prompt, leggi Prompt Engineering per casi business. Per workflow creativi assistiti dall’IA tra più media, vedi creazione cross-media. Per eseguire modelli linguistici in locale, continua con introduzione a Ollama.