Ottimizzare ComfyUI con poca VRAM: SDXL, FLUX e video su GPU da 6–8 GB

Il terminale mostra torch.cuda.OutOfMemoryError: CUDA out of memory. Nella console di ComfyUI compare regular VAE encoding, retrying with tiled VAE encoding, ma l’immagine da 1024×1024 non viene comunque completata. Una RTX 3060 da 8 GB riesce a generare un’immagine SDXL singola, ma attivando insieme Hires Fix, FaceDetailer e ControlNet l’uso supera subito 12 GB. A 768×768 e senza ControlNet il workflow parte, ma il risultato non ha la qualità desiderata.

Con 6–8 GB di VRAM, una normale GPU consumer oppure un ambiente Apple Silicon o AMD, l’obiettivo è eseguire nel modo più stabile possibile SDXL, FLUX e workflow video leggeri in ComfyUI, sapendo quali interventi sacrificano velocità, qualità o compatibilità.

---

Prima individua la fascia di VRAM della GPU

Il budget di VRAM non si decide a intuito. La fascia della GPU determina i workflow realistici e la prima strategia da provare.

Fascia VRAM, workflow possibili e punto di partenza

VRAM	Workflow possibili	Limiti e rischi	Punto di partenza consigliato
6 GB	SDXL a bassa risoluzione (512–768) FLUX fortemente quantizzato (Q2_K/Q3_K_S + GGUF + —lowvram/—novram) Video: 8 frame 480p come caso limite	Risoluzione limitata I nodi aggiuntivi causano facilmente OOM Offload su RAM lento	Quantizzazione spinta come Q3_K_S Risoluzione 512–768 ControlNet e rami di post-elaborazione disattivati Non più di 8 frame video
8 GB	Un’immagine SDXL 1024×1024 FLUX fp8/GGUF Q4_K_S senza stabilità garantita 8 frame 480p agevoli, 24 frame 720p al limite	ControlNet e Hires Fix insieme possono causare OOM T5 deve essere fp8/GGUF Non oltre 1024×1024 FLUX.1 GGUF Q5_K_S al limite	Prima FLUX.2 Klein 4B GGUF T5 fp8/GGUF Tiled VAE batch size=1
12 GB	SDXL + ControlNet + upscale semplice FLUX Q5_K_S/Q6_K agevole 24 frame 720p agevoli, 60 frame 1080p al limite	Più ControlNet richiedono attenzione Va calcolato frame×risoluzione Picco di post-elaborazione ancora limitato	FLUX Q5_K_S/Q6_K T5 fp8 facoltativo Tiled VAE facoltativo Provare batch size 2–3
16 GB+	FLUX full fp16 o Q8_0 quasi lossless Più spazio per ControlNet/LoRA 60 frame 1080p	File FLUX full di circa 23 GB Frame×risoluzione resta importante Esiste ancora il picco di post-elaborazione	FLUX Q8_0 o fp16 T5 fp16 Tiled VAE facoltativo Provare batch size 4–8

Principali cause dei picchi, dalla più pesante

1. Pesi del modello: checkpoint SDXL circa 6,5 GB, FLUX fp16 circa 23 GB
2. Encoder T5: fp16 circa 9 GB, oltre una GPU da 8 GB; fp8 circa 4–5 GB; GGUF Q3/Q4/Q5
3. Risoluzione latent: un latent 2048×2048 può avvicinarsi a 8 GB
4. VAE encode/decode: casi con picchi di circa 8 GB a 2048×2048
5. Batch size: l’inferenza simultanea crea il picco maggiore
6. ControlNet/Detailer: casi di circa 2–3 GB ciascuno
7. Frame video: frame×risoluzione×VideoVAE
8. Cache/anteprima: circa 0,5–1 GB

Il consumo reale dipende da risoluzione, precisione, versione del modello, batch, nodi di post-elaborazione, frame, PyTorch/driver e implementazione dei custom node. Può variare di 1–2 GB. Usa la tabella come budget iniziale, poi misura il workflow effettivo.

---

Flag di avvio di ComfyUI per poca VRAM

ComfyUI offre diversi flag per controllare VRAM e memoria di sistema. Cambiano tra le versioni: le indicazioni seguenti si riferiscono circa a ComfyUI v0.18.0+ di marzo 2026. Dai sempre priorità a python main.py --help e alla documentazione ufficiale corrente.

Flag, funzione, GPU e impatto sulla velocità

Flag	Funzione	GPU	Impatto sulla velocità	Quando usarlo
--lowvram	Divide il modello e trasferisce i segmenti dalla RAM	4–8 GB	20–40% più lento	Nessun effetto con Dynamic VRAM attivo Prova manuale dopo —normalvram
--novram	Mantiene i pesi in CPU/RAM e sposta sulla GPU solo il calcolo attivo	Meno di 4 GB	50–70% più lento	Ultima risorsa Molto lento, ma può partire
--normalvram	Forza la modalità standard e disattiva Dynamic VRAM	12 GB+	Nessun impatto previsto	Per provare manualmente —lowvram OOM da frammentazione
--reserve-vram N	Riserva N GB di VRAM al sistema operativo	Tutte le fasce	Nessun impatto previsto	Evita instabilità del sistema Di solito 2–4 GB
--async-offload	Esegue l’offload dei pesi in modo asincrono	Tutte le fasce	Esempio: 5–10% più veloce	Riduce l’attesa CPU–GPU con RAM sufficiente, in genere 32 GB+
--fp8_e4m3fn-unet	Forza UNet in fp8	8–12 GB	In genere neutro	FLUX può ignorarlo Controlla il compute dtype
--fp8_e4m3fn-text-enc	Usa fp8 per il text encoder	8 GB	In genere neutro	Porta T5 da circa 9 GB a 4–5 GB FLUX con poca VRAM
--fp8_e5m2fn-text-enc	Usa un altro formato fp8 per il text encoder	8 GB	In genere neutro	Alternativa a fp8_e4m3fn
--preview-method none	Disattiva la generazione dell’anteprima	Tutte le fasce	Leggermente più veloce	Risparmia circa 0,5–1 GB Prima prova per un OOM
--cache-none	Disattiva la cache	RAM limitata	Più lento	Risparmia RAM ma aumenta i ricalcoli
--cache-lru 10	Conserva 10 risultati in una cache LRU	RAM sufficiente	Più veloce	Compromesso per la cache Provare 10–20
--cache-classic	Usa la vecchia cache aggressiva	RAM sufficiente	Più veloce	Può occupare più RAM
--force-fp16	Forza fp16 globalmente	Tutte le fasce	In genere neutro	Può risparmiare 2–3 GB
--use-pytorch-cross-attention	Forza SDP attention di PyTorch	Tutte le fasce	Esempio: 5–20% più veloce	ComfyUI sceglie spesso xformers/SDP automaticamente Forzare solo in test specifici
--use-flash-attention	Forza Flash Attention	Tutte le fasce	Esempio: 5–20% più veloce	Richiede flash-attention Incompatibile con alcune versioni CUDA
--fast	Modalità veloce sperimentale	Tutte le fasce	Incerto	Esperimento avanzato Può alterare qualità o stabilità Non è un’impostazione base per 8 GB

Esempi di comando

# Configurazione di base per 8 GB di VRAM
python main.py --lowvram --force-fp16 --fp8_e4m3fn-text-enc --preview-method none

# Configurazione limite per 6 GB di VRAM
python main.py --novram --force-fp16 --fp8_e4m3fn-text-enc --preview-method none --reserve-vram 2

# Configurazione più veloce con RAM sufficiente
python main.py --async-offload --cache-lru 10 --use-pytorch-cross-attention

Informazioni soggette a cambiamento: i flag possono cambiare. Verifica python main.py --help e la documentazione corrente. FLUX può ignorare --fp8_e4m3fn-unet per il proprio compute dtype interno; quando serve, imposta weight_dtype nel nodo.

---

Perché —lowvram non evita sempre l’OOM

Intorno a ComfyUI v0.18.0+ di marzo 2026, Dynamic VRAM è attivo per impostazione predefinita. Gestisce già l’offload in modo adattivo, quindi con Dynamic VRAM attivo --lowvram viene ignorato.

Quando provare manualmente --lowvram

• Dopo aver disattivato Dynamic VRAM con --normalvram
• Se un workflow presenta OOM da frammentazione, provando --disable-dynamic-vram

Alternative

• Usa il comportamento predefinito di Dynamic VRAM
• Tieni --novram come ultima risorsa, accettando una perdita di velocità del 50–70%
• Riserva margine al sistema con --reserve-vram 2-4

Vantaggio di Dynamic VRAM: valuta la memoria necessaria e scarica automaticamente in RAM quando la VRAM non basta.

Rischio di Dynamic VRAM: in alcuni workflow può restare un OOM da frammentazione; in quel caso prova --disable-dynamic-vram.

---

Tre percorsi per FLUX su 8 GB: fp8, GGUF e Klein 4B

FLUX è un modello da 12 miliardi di parametri e il file originale pesa circa 23 GB. Su 8 GB esistono tre percorsi con costi diversi.

Confronto dei percorsi di quantizzazione FLUX

Percorso	Dimensione file	VRAM	Qualità rispetto a fp16	GPU	Velocità	Compatibilità	Uso
FLUX full (fp16)	~23 GB	~20 GB+	100%	24 GB+	Più veloce	Ufficiale	Uso professionale VRAM sufficiente
FLUX fp8 checkpoint	~12 GB	~11 GB	~95–98%	12 GB agevoli/16 GB+	Abbastanza veloce	Quantizzazione ufficiale	12 GB+ Un solo file
FLUX GGUF Q8_0	~12,7 GB	~11 GB	~99%	12 GB+/16 GB+	Lento con offload	Nodo city96, WIP	12 GB+ Quasi lossless
FLUX GGUF Q5_K_S	~8,5 GB	~7,5 GB	~94–96%	8 GB al limite/12 GB agevoli	Lento	Nodo city96, WIP	8 GB Equilibrio qualità
FLUX GGUF Q4_K_S	~6,8 GB	~6,5 GB	~88–90%	8 GB/6 GB al limite	Più lento	Nodo city96, WIP	6–8 GB Priorità all’esecuzione
FLUX.2 Klein 4B GGUF Q4_K_M	~2,6 GB	~2,6 GB	Qualità propria del modello 4B	8 GB agevoli	4 steps, veloce	Apache 2.0, nodo city96	Per 8 GB Inferenza in 4 steps Veloce

Encoder T5

Versione T5	Dimensione file	VRAM	GPU
T5 fp16	~9 GB	~9 GB	24 GB+, oltre 8 GB
T5 fp8_e4m3fn	~4–5 GB	~4–5 GB	Possibile su 8 GB
T5 GGUF Q3/Q4/Q5	~2–4 GB	~2–4 GB	Configurazione limite per 6–8 GB

Installazione

Per fp8, scarica il file safetensors, caricalo con Load Diffusion Model e imposta weight_dtype su fp8_e4m3fn nel nodo.

Per GGUF, installa il custom node ComfyUI-GGUF di city96, carica il modello con Unet Loader (GGUF) e metti il file in models/unet/.

Rischio dei nodi esterni: il nodo GGUF è indicato come WIP e il supporto LoRA è experimental. Cambia spesso e non è un percorso ufficiale integrato.

Osservazione qualitativa di Apatero: Q5_K_S resta vicino a fp16; le differenze emergono soprattutto nel testo renderizzato e nei pattern fini. Q4_K_S perde più dettaglio.

Osservazioni di velocità di Local AI Master

• FLUX.1-dev Q4_K_S + —lowvram, 1024×1024, 20 steps, RTX 3060 Ti 8 GB: circa 90–150 secondi
• FLUX.2 Klein 4B Q4_K_M, 1024×1024, 4 steps, 8 GB: circa 15–30 secondi

Benchmark soggetti a cambiamento: hardware, versioni e workflow modificano molto i risultati. Considerali soltanto intervalli di riferimento.

---

Ridurre gli OOM di VAE Encode e Decode con Tiled VAE

A 2048×2048 o nei video, VAE Encode/Decode può esaurire la VRAM. Tiled VAE divide l’immagine in aree più piccole e riduce il picco.

Nodi

VAEDecodeTiled decodifica il latent in tile. VAEEncodeTiled codifica l’immagine in latent nello stesso modo.

Parametri

Parametro	Funzione	Valore iniziale	Uso
tile_size	Dimensione di un tile	512 con poca VRAM 1024 con margine	Più piccolo consuma meno VRAM ma rallenta 512 consigliato per 8 GB
overlap	Sovrapposizione tra tile	64	Evita le giunzioni Regolabile tra 32 e 128
fast mode	Modalità veloce	true	Consigliata
temporal_size	Blocco temporale, solo VideoVAE	8 con poca VRAM 16 con margine	Elabora i frame in gruppi Serve soltanto per VideoVAE
temporal_overlap	Sovrapposizione temporale, solo VideoVAE	2–4	Overlap tra gruppi di frame

Confronto dei picchi, dati SynpixCloud

Risoluzione	Picco VAE standard	Picco Tiled 512	Picco Tiled 1024
1024×1024	~2 GB	~0,5 GB	~1 GB
2048×2048	~8 GB	~1 GB	~2,5 GB

Quando usare Tiled VAE

• Risoluzione oltre 1024×1024
• GPU da 8–12 GB
• Workflow video con VideoVAE
• OOM nei nodi di post-elaborazione come Hires Fix, Upscale o FaceDetailer

Nota sulla documentazione del nodo: la pagina è indicata come generata dall’AI; fai riferimento all’interfaccia della versione ComfyUI installata.

---

Checklist OOM ordinata per causa del picco

Quando compare CUDA out of memory, controlla le cause dal picco maggiore al minore, applicando un’azione concreta per ogni voce.

Causa, riduzione e priorità

Causa del picco	Esempio di VRAM	Azione di riduzione	Priorità
Pesi del modello	SDXL ~6,5 GB FLUX fp16 ~23 GB	Passa a fp8/GGUF Usa —lowvram/—novram	P0
Encoder T5	fp16 ~9 GB	Passa a T5 fp8/GGUF, compreso city96 T5 GGUF	P0 per FLUX
Risoluzione latent	2048×2048 ~8 GB	Riduci a 1024×1024 o 512×512	P1
VAE encode/decode	Picco ~8 GB a 2048×2048	Tiled VAE, tile_size=512, overlap=64	P1
batch size	batch size=4 a 1024×1024, picco ~8–12 GB	Riduci batch size a 1 Usa una coda con batch count	P2
ControlNet/Detailer	~2–3 GB ciascuno	Disattiva il ramo ControlNet Oppure usa una configurazione ControlNet a poca VRAM	P2
Frame video	frame×risoluzione×VideoVAE	Temporal chunking Meno frame Tiled VAE temporale	P2 per video
Cache/anteprima	~0,5–1 GB	—preview-method none —cache-none	P3

Azioni in ordine di priorità

1. Riduci la risoluzione: da 2048 a 1024, poi a 512
2. Disattiva l’anteprima: --preview-method none
3. Passa a un modello fp8/GGUF: FLUX Q4_K_S, Q5_K_S o Klein 4B
4. Passa a T5 fp8/GGUF: necessario per FLUX con poca VRAM
5. Usa Tiled VAE: tile_size=512, overlap=64
6. Riduci batch size: batch size=1 e coda con batch count
7. Disattiva ControlNet e post-elaborazione: FaceDetailer, Hires Fix, Upscale
8. Per i video: meno frame e temporal chunking

---

Checklist per la lentezza: distinguere due casi

Se la generazione è lenta, separa «lento ma funzionante», costo inevitabile dell’offload con poca VRAM, da «più lento del dovuto», dove puoi intervenire.

Tipo di collo di bottiglia, diagnosi e intervento

Collo di bottiglia	Segnale	Diagnosi	Intervento
Lento ma funzionante, costo dell’offload
—lowvram/—novram	20–70% più lento	Controlla i flag di avvio	Accetta la lentezza Oppure usa più VRAM
Offload GGUF in RAM	Utilizzo GPU basso	Percentuale GPU nel task manager	La banda della RAM limita la velocità Passa a fp8/fp16 se la VRAM basta
Workflow video con molti frame	VAE Decode lento	Calcola frame×risoluzione	Riduci i frame Usa Temporal Tiling
Modalità CPU con —cpu	Estremamente lento	Controlla i flag di avvio	Solo come ultima risorsa Usa o aggiorna la GPU
Più lento del dovuto, regolabile
Troppi sampler steps	FLUX dev oltre 20 steps	Controlla il nodo KSampler	Per FLUX dev bastano 20 steps schnell/Klein 4B ne richiedono 4
Attention non regolata	Uso VRAM alto	Controlla i flag di avvio	Abilita xformers Oppure SDP attention
VAE Decode lento	tile_size di Tiled VAE troppo piccolo	Controlla VAEDecodeTiled	Da 512 a 1024 Circa 1 GB in più, 10–30% più veloce
Offload CPU non regolato	Attese CPU–GPU	Controlla i flag di avvio	Abilita —async-offload Assicurati di avere almeno 32 GB di RAM
Cache su disco/RAM inadeguata	Il modello viene ricaricato	Controlla i flag di avvio	—cache-lru 10 Memorizza 10 risultati
Altri processi usano la GPU	Utilizzo GPU disponibile basso	Percentuale GPU nel task manager	Chiudi browser, giochi o editor video

Interventi in ordine di priorità

1. Abilita xformers o SDP attention: pip install xformers, rilevato automaticamente da ComfyUI, oppure --use-pytorch-cross-attention; può risparmiare 20–30% di VRAM e accelerare del 5–20%
2. Usa un modello FLUX da 4 steps: schnell o Klein 4B invece di dev a 20 steps
3. Regola tile_size di Tiled VAE: da 512 a 1024, con circa 1 GB di picco in più ma 10–30% di velocità in più
4. Abilita async offload: --async-offload quando la RAM è sufficiente
5. Chiudi gli altri processi GPU: browser, giochi ed editor video

Dati SynpixCloud: xformers/SDP attention risparmia il 20–30% di VRAM e accelera del 5–20%.

Dati Local AI Master: FLUX.2 Klein 4B Q4_K_M, 4 steps, 1024×1024, 8 GB di VRAM, 15–30 secondi.

Dati soggetti a cambiamento: hardware, versioni e workflow modificano i risultati. Considerali soltanto intervalli di riferimento.

---

Perché un file GGUF più piccolo può essere più lento

Dopo la quantizzazione GGUF il file è più piccolo, circa 6,8 GB per Q4_K_S contro 23 GB per FLUX fp16, ma la generazione può rallentare:

• GGUF scarica i pesi del modello nella RAM di sistema invece di mantenerli in VRAM, riducendo l’utilizzo della GPU
• Durante l’inferenza i pesi devono passare dalla RAM alla VRAM, quindi ogni esecuzione comporta trasferimenti RAM→VRAM
• La banda della RAM è molto inferiore a quella della VRAM: circa 25–50 GB/s per DDR4/DDR5 contro 500–1000 GB/s per GDDR6X

Quando usare GGUF

• La VRAM non basta, per esempio per FLUX su 6–8 GB, e anche fp8 supera il limite
• Accetti una velocità inferiore pur di rendere eseguibile il workflow

Quando non usare GGUF

• Con almeno 12 GB di VRAM, fp8 o fp16 è più veloce
• Se la priorità è la velocità e non semplicemente riuscire a eseguire il modello

Osservazione di Apatero: Q8_0 con offload sulla CPU può richiedere 5–10 minuti per una generazione.

---

Budget VRAM per i video: frame×risoluzione×VideoVAE

Nei workflow video, frame×risoluzione×VideoVAE fa salire rapidamente il consumo. Qui consideriamo solo budget e riduzione dei picchi, senza entrare nei workflow Wan o AnimateDiff completi.

Principio di budget

Il picco dipende da frame×risoluzione×VideoVAE, perché ogni frame richiede VAE Encode/Decode.

Formula approssimativa: VRAM ≈ pesi del modello + T5 + frame×latent per frame + picco VideoVAE.

Esempi, da ComfyUI-Wan2.2-workflow e Local AI Master

Parametri video	Budget VRAM	GPU	Nota
8 frame 480p, 640×360	~6–8 GB	Possibile con 6 GB	Test RTX 3050 6 GB: un secondo di video in meno di 5 minuti
24 frame 720p, 1280×720	~12–16 GB	8 GB al limite/12 GB agevoli	Richiede Temporal Tiling
60 frame 1080p, 1920×1080	~20–24 GB+	16 GB+	Per GPU con molta VRAM

Strategie per ridurre il picco

Temporal Tiling divide i frame in piccoli gruppi, per esempio 8 per volta, elaborandone uno solo alla volta. I parametri sono temporal_size, numero di frame per gruppo, e temporal_overlap, sovrapposizione tra gruppi.

Tiled VAE per i frame video applica la decodifica a tile a ogni frame e riduce il picco della singola immagine.

Riduci prima i frame da 60 a 24, poi a 8, per verificare se il workflow è eseguibile.

Riduci la risoluzione da 1080p a 720p, poi a 480p.

Come modello, prova Wan 2.2 5B, adatto a 8 GB, oppure Wan 2.2 14B GGUF, eseguibile da 6 GB.

Dati soggetti a cambiamento: hardware, versioni e workflow modificano i risultati. Considerali soltanto intervalli di riferimento.

---

Generare più immagini senza OOM: batch size e batch count

batch size e batch count hanno effetti molto diversi sulla VRAM. Aumentare alla cieca batch size porta facilmente a un OOM.

Differenza tra batch size e batch count

batch size esegue più inferenze insieme e produce il picco maggiore, moltiplicando latent, VAE e modello. batch count crea invece una coda sequenziale: genera N gruppi, ciascuno con il proprio batch size, e limita il picco alle immagini elaborate in quel momento.

Esempio di differenza nella VRAM

Configurazione	Risoluzione	Picco VRAM	Rischio OOM
batch size=4	1024×1024	~8–12 GB	Alto, per il picco simultaneo
batch count=4, batch size=1	1024×1024	~2–3 GB	Basso, picco controllato

Indicazioni

• Con 6–8 GB: batch size=1 e batch count=N in coda sequenziale
• Per batch via API: usa una strategia di coda ed evita richieste concorrenti che occupino insieme la VRAM

---

OOM improvvisi dopo un aggiornamento: controlla le versioni

Se un workflow che funzionava va improvvisamente in OOM o rallenta dopo un aggiornamento di PyTorch, driver o ComfyUI, il comportamento può essere cambiato con la versione.

Come le versioni influenzano la VRAM

Il comportamento CUDA di PyTorch cambia tra le versioni, per esempio per impostazioni predefinite TF32/FP16 o strategia dell’allocator CUDA. TF32 e FP16 non sono sempre automaticamente migliori: in alcuni casi cambiano precisione o consumo. Anche versioni di driver, ROCm e CUDA modificano le prestazioni GPU, come nel confronto tra AMD ROCm 7.2 e versioni precedenti.

Indicazioni

1. Salva l’ambiente prima dell’aggiornamento con conda o pip freeze
2. Prova l’aggiornamento in un ambiente di test prima di sostituire quello stabile
3. Registra le versioni stabili di PyTorch, CUDA e driver
4. Se compare un problema, torna a una versione specifica con pip install

---

Accelerazioni sperimentali e opzioni stabili

Prima di provare tecniche di accelerazione avanzate, separa gli esperimenti dalle opzioni stabili.

Esperimenti avanzati, non obbligatori per una GPU da 8 GB

Opzione	Stato	Rischio	Nota
--fast	Sperimentale	Può alterare qualità o stabilità	Segnalato experimental da ComfyUI
FlashAttention	Richiede il pacchetto flash-attention	Incompatibile con alcune versioni CUDA	Installazione complessa
Sage Attention	Modifica di terze parti	Sperimentale, può influire sulla precisione	Installazione complessa, legata a CUDA/PyTorch
TensorRT	Richiede TensorRT SDK	Conversione dei modelli complessa	Non adatto a chi inizia

Nota: sono esperimenti avanzati, non requisiti per una normale GPU da 8 GB.

Opzioni stabili

Opzione	Stato	Effetto	Nota
xformers	Stabile	Risparmia 20–30% di VRAM, accelera del 5–20%	pip install xformers Rilevamento automatico di ComfyUI
SDP attention, —use-pytorch-cross-attention	Stabile	Risparmia 20–30% di VRAM, accelera del 5–20%	La scelta migliore è spesso automatica

---

Conclusione

Fascia hardware: individua prima se la GPU ha 6, 8, 12 o almeno 16 GB. Ogni fascia permette workflow e strategie diversi.

Flag principali: Dynamic VRAM è attivo per impostazione predefinita da ComfyUI v0.18.0+ e --lowvram può non avere effetto. I flag cambiano: controlla sempre python main.py --help.

Percorsi di quantizzazione: su 8 GB, FLUX.2 Klein 4B GGUF offre inferenza in 4 steps intorno a 15–30 secondi, mentre FLUX.1 GGUF Q4_K_S può partire ma è lento. L’offload GGUF usa la RAM e dipende dalla sua banda.

Ordine di diagnosi: per gli OOM controlla pesi del modello, T5, risoluzione latent, VAE, batch, ControlNet, frame e cache. Per la lentezza separa il costo inevitabile dell’offload dalle impostazioni realmente regolabili.

Passi successivi

1. Individua la fascia della GPU: 6, 8, 12 o almeno 16 GB
2. Scegli la quantizzazione: su 8 GB, FLUX.2 Klein 4B o FLUX.1 GGUF Q4_K_S
3. Per un OOM segui la checklist nell’ordine indicato
4. Per la lentezza applica la checklist specifica
5. Nei workflow video usa Temporal Tiling

Se l’ambiente di base non funziona ancora, parti dalla guida introduttiva a ComfyUI. Se un workflow importato mostra nodi rossi, modelli mancanti o risultati non riproducibili, consulta la checklist per riutilizzare e diagnosticare i workflow ComfyUI. Se non hai ancora scelto tra SDXL, SD 3.5 e FLUX, leggi prima la guida alla scelta dei modelli Stable Diffusion.