ComfyUI GGUF: esegui grandi modelli di diffusione su GPU con poca VRAM

GGUF è un formato binario sviluppato dal progetto llama.cpp per memorizzare pesi di reti neurali quantizzati. Originariamente concepito per i modelli linguistici di grandi dimensioni (LLM), è stato adattato anche per gli UNet dei modelli di diffusione; il nodo personalizzato ComfyUI-GGUF nodo personalizzato di city96 integra tale supporto in ComfyUI. Il risultato pratico: FLUX.1-dev, che richiede circa 24 GB di VRAM in precisione completa BF16, diventa eseguibile su una GPU da 6–8 GB con quantizzazione Q4 — mantenendo una qualità dell’immagine spesso indistinguibile da quella del modello a piena precisione all’occhio umano.

Perché GGUF è importante per la generazione di immagini

I checkpoint standard della diffusione vengono distribuiti come .safetensors file in FP16 o BF16. Per modelli di generazioni precedenti (SD1.5, circa 2 GB; SDXL, circa 7 GB), ciò è gestibile su hardware di fascia media. Per FLUX.1 e SD3, i file in precisione completa occupano rispettivamente 24 GB e 16 GB: una dimensione superiore al limite di VRAM disponibile su qualsiasi GPU consumer singola.

La quantizzazione GGUF mappa ciascun peso su una rappresentazione intera più piccola. Un peso Q8_0 utilizza 8 bit invece di 16, riducendo approssimativamente a metà le dimensioni del modello con una perdita di qualità trascurabile. Le varianti Q4 usano 4 bit per peso, portando le dimensioni a circa un quarto di quelle in fp16. I risparmi diventano particolarmente significativi nei modelli con miliardi di parametri. Usa il Calcolatore VRAM per stimare quanta memoria GPU sarà necessaria per un determinato livello di quantizzazione prima ancora di scaricare qualsiasi file.

FLUX.1 include inoltre un grande encoder testuale T5-XXL (circa 9,3 GB in fp16). Combinare un UNet in formato GGUF con un encoder T5-XXL anch’esso in formato GGUF permette di far rientrare l’intera pipeline FLUX.1 su schede grafiche che altrimenti non riuscirebbero affatto ad eseguirla. Entrambi i componenti possono essere caricati indipendentemente nel formato GGUF.

Installazione del nodo personalizzato ComfyUI-GGUF

Tramite ComfyUI Manager (consigliato)

1. Apri ComfyUI e clicca su Manager nella barra laterale.
2. Vai a Installa nodi personalizzati.
3. Cerca nodo personalizzato ComfyUI-GGUF.
4. Fai clic Installa accanto alla voce di city96, quindi riavvia ComfyUI.

Installazione manuale

Clona il repository nella tua cartella custom_nodes e installa la dipendenza Python richiesta:

cd ComfyUI/custom_nodes
git clone https://github.com/city96/ComfyUI-GGUF

Linux / macOS (venv):

source ComfyUI/venv/bin/activate
pip install -r ComfyUI/custom_nodes/ComfyUI-GGUF/requirements.txt

Windows (ComfyUI portatile):

ComfyUIpython_embedspython.exe -m pip install -r ComfyUIcustom_nodesComfyUI-GGUFrequirements.txt

Windows (venv):

ComfyUIvenvScriptsactivate.bat
pip install -r ComfyUIcustom_nodesComfyUI-GGUFrequirements.txt

La dipendenza principale è il pacchetto Python gguf . Riavvia ComfyUI dopo l’installazione.

Recupero dei file dei modelli GGUF

city96 pubblica su Hugging Face versioni GGUF di FLUX.1-dev e FLUX.1-schnell con l’username city96. Cerca su Hugging Face city96 FLUX.1-dev-gguf per trovare il repository corrispondente. Ogni repository contiene più .gguf file, uno per ogni livello di quantizzazione. Scarica un solo file, corrispondente al livello di quantizzazione desiderato: non hai bisogno di tutti i file presenti.

Sono inoltre disponibili su Hugging Face versioni GGUF dell’encoder testuale T5-XXL (cerca t5-v1_1-xxl-encoder-gguf). L’encoder CLIP-L è sufficientemente piccolo (~240 MB) da rendere raramente conveniente la sua quantizzazione.

Membri della community pubblicano anche varianti GGUF di modelli FLUX finetunati su CivitAI. La stessa struttura di nodi e directory si applica indipendentemente dalla fonte da cui scarichi i file.

Dove posizionare i file dei modelli

Il VAE per FLUX non viene quantizzato e rimane nella sua posizione standard. Solo l’UNet e l’encoder testuale traggono vantaggio dal caricamento in formato GGUF.

Utilizzo dei nodi loader GGUF

Dopo aver installato ComfyUI-GGUF e riavviato, nuovi nodi compaiono nel browser dei nodi. Questi sostituiscono le controparti standard nei tuoi flussi di lavoro: non puoi caricare un .gguf file con il normale nodo UNETLoader.

Per un flusso di lavoro FLUX standard: sostituisci UNETLoader per UnetLoaderGGUF, e sostituisci DualCLIPLoader per DualCLIPLoaderGGUF se utilizzi anche un T5-XXL in formato GGUF. Collega le uscite agli stessi nodi downstream di prima — le forme dei tensori sono compatibili.

Scelta del livello di quantizzazione

La tabella seguente mostra valori approssimativi relativi soltanto ai pesi UNet di FLUX.1. Il tuo budget totale di VRAM deve coprire anche il VAE (~350 MB), gli encoder testuali (240 MB per CLIP-L, più la quantità che assegni al T5-XXL) e i tensori intermedi generati durante l’inferenza. Usa il Riferimento sui requisiti di VRAM insieme a questa tabella e consulta la guida alle GPU se devi decidere quale scheda acquistare.

Punti di partenza pratici: Q5_K_S o Q4_K_S per schede da 8–12 GB (miglior rapporto qualità/VRAM). Q3_K_S o Q2_K per schede da 6 GB, se utilizzi anche un T5-XXL quantizzato. Q8_0 per schede da 16 GB, quando desideri la massima fedeltà pur mantenendo l’intero modello nella VRAM.

I checkpoint standard dei modelli di diffusione sono distribuiti come

A livello Q8_0, le differenze rispetto a BF16 sono virtualmente impercettibili in confronti affiancati. A livello Q4_K_S, possono emergere degradazioni molto sottili nei dettagli fini e nella resa del testo, ma i risultati rimangono di qualità produttiva per la maggior parte degli utilizzi. Q2_K introduce una leggera sfocatura e occasionali artefatti, soprattutto sui volti e sui dettagli fini: è da considerarsi un’ultima risorsa per hardware fortemente limitato in memoria.

La velocità di generazione con GGUF può essere comparabile o addirittura superiore a quella ottenuta caricando un modello BF16 con offloading sulla CPU, poiché i pesi quantizzati riducono la pressione sulla larghezza di banda della memoria. Tuttavia, se la tua GPU riesce a contenere l’intero modello BF16 nella VRAM senza ricorrere all’offloading, tale configurazione sarà generalmente più veloce dell’inferenza GGUF. Il vantaggio prestazionale di GGUF è più evidente quando l’alternativa prevede lo scambio continuo di layer tra VRAM e RAM di sistema.

Su Apple Silicon (macOS), il backend MPS supporta l’inferenza GGUF tramite ComfyUI-GGUF, ma le caratteristiche prestazionali differiscono da quelle di CUDA NVIDIA. I risultati sono funzionali, ma la velocità di generazione potrebbe essere inferiore rispetto a una GPU NVIDIA equivalente. L’architettura di memoria unificata di Apple Silicon comporta un limite pratico di VRAM più alto rispetto a GPU discrete con capacità nominale identica, quindi potresti riuscire a eseguire livelli di quantizzazione superiori a quelli indicati nella tabella.

Su GPU AMD (Linux, ROCm), l’inferenza GGUF funziona tramite il backend ROCm di PyTorch. Installa prima la versione di PyTorch compatibile con ROCm per ComfyUI, quindi procedi con l’installazione di ComfyUI-GGUF. Prestazioni e compatibilità variano in base alla generazione della GPU; le schede RDNA 3 (serie RX 7000) godono del supporto più affidabile.

Domande frequenti

Posso caricare un file .gguf con il nodo standard UNETLoader?

No. Il nodo standard UNETLoader accetta soltanto file .safetensors . Devi installare il nodo personalizzato ComfyUI-GGUF e utilizzare UnetLoaderGGUF per caricare i modelli .gguf di diffusione.

Devo quantizzare io stesso i miei modelli, oppure posso scaricare file già quantizzati?

Per FLUX.1-dev e FLUX.1-schnell, city96 fornisce su Hugging Face file GGUF pre-quantizzati per tutti i principali livelli di quantizzazione. Scarica il file .gguf specifico corrispondente al livello desiderato: non è necessario eseguire alcuno strumento di quantizzazione autonomamente.

GGUF funziona anche con modelli SD1.5 e SDXL?

Tecnicamente sì, ma il vantaggio è modesto. SD1.5 occupa circa 2 GB e SDXL circa 7 GB in fp16 — entrambi rientrano comodamente nella VRAM delle GPU consumer di fascia media. La quantizzazione GGUF risulta particolarmente utile per modelli molto grandi (FLUX.1, SD3), i cui pesi in precisione piena superano la capacità di VRAM della maggior parte delle schede.

Un T5-XXL in formato GGUF è sensibilmente peggiore della versione fp16 completa?

A livello Q8_0 o Q5_K_S, la capacità di interpretare i prompt e la qualità della codifica testuale sono sostanzialmente identiche a quelle della versione fp16. Livelli di quantizzazione inferiori (Q2_K, Q3_K_S) possono talvolta produrre un leggero peggioramento nell’aderenza ai prompt complessi, ma tale effetto è molto più sottile rispetto all’impatto sulla qualità dell’UNet allo stesso livello di quantizzazione.

Il mio flusso di lavoro è stato creato per un modello FLUX in precisione piena. Devo ricostruirlo completamente?

No. Sostituisci semplicemente UNETLoader con UnetLoaderGGUF e (opzionalmente) DualCLIPLoader con DualCLIPLoaderGGUF. Tutte le connessioni downstream — KSampler, decodifica VAE, condizionamento — rimangono invariate. Le uscite di questi nodi sono compatibili dal punto di vista tensoriale con il resto di un flusso di lavoro FLUX standard.

Perché ComfyUI esaurisce comunque la VRAM anche con un modello quantizzato?

L’UNet GGUF rappresenta soltanto una parte dell’uso complessivo di VRAM. Una pipeline FLUX completa carica anche CLIP-L (~240 MB), T5-XXL (fino a ~9,3 GB in fp16) e il VAE (~350 MB), oltre ai buffer di lavoro durante la generazione. Se continui a esaurire la VRAM, carica anche il T5-XXL in formato GGUF tramite DualCLIPLoaderGGUFe considera l’attivazione della funzione integrata di tiling del VAE in ComfyUI per la fase di decodifica.