# ComfyUI finisce la memoria su Windows: VRAM, RAM o disco?

Quando ComfyUI segnala `CUDA out of memory` su Windows, indaga prima la memoria della GPU e il workflow che ha fallito. Eliminare le immagini generate libera spazio su disco, ma non aumenta la VRAM dedicata. Un messaggio generico di memoria esaurita può riguardare anche la RAM di sistema, quindi conserva il testo esatto dell'errore invece di trattare ogni errore come lo stesso problema.

## Conserva il workflow che fallisce e individua la fase

Salva il workflow e annota modello, risoluzione, dimensione del batch e nodo in cui l'esecuzione si interrompe. Usa il report dell'errore e il log del terminale per distinguere il caricamento di un modello, il campionamento, la decodifica di un'immagine e l'esecuzione di un nodo personalizzato. La fase conta perché ognuna può richiedere una quantità diversa di memoria.

La [guida alla risoluzione dei problemi](https://docs.comfy.org/troubleshooting/overview) di ComfyUI consiglia di controllare il report, ridurre la dimensione dell'immagine o del batch ed escludere problemi dei nodi personalizzati. Trattale come confronti controllati. Non aggiornare tutti i nodi, sostituire Python e cambiare il modello nello stesso momento, perché una riesecuzione riuscita non rivelerebbe più quale modifica è stata determinante.

## Leggi separatamente la memoria della GPU e la memoria di sistema

Apri **Gestione attività › Prestazioni** e controlla la memoria dedicata della GPU insieme alla pagina Memoria mentre riproduci l'errore. Su un PC con più GPU assicurati di guardare quella effettivamente usata dal workflow.

| Risorsa | Cosa cambia quando manca |
| --- | --- |
| Memoria GPU dedicata | Se modello e tensori intermedi stanno nella GPU |
| RAM di sistema e commit | Se Windows e il lavoro lato CPU hanno spazio |
| Spazio su disco | Se modelli, output e file di paging possono crescere |

La memoria GPU condivisa non è VRAM fisica aggiuntiva sulla scheda grafica. Un grande SSD libero non significa che un grande modello starà su quella scheda. La [spiegazione della Gestione attività per la GPU](https://devblogs.microsoft.com/directx/gpus-in-the-task-manager/) di Microsoft descrive le diverse voci.

## Abbina il primo esperimento al nodo che ha fallito

Un rapporto di esaurimento memoria di solito contiene informazioni più utili del solo nodo rosso. Conserva il primo errore di allocazione e il nodo che lo ha generato; le eccezioni successive possono essere conseguenze di quel primo errore. Salva una copia del workflow prima di modificarne il grafo.

| Fase del fallimento | Primo confronto controllato | Cosa può stabilire il risultato |
| --- | --- | --- |
| Caricamento di un checkpoint o di un text encoder | Un modello più piccolo compatibile con la stessa attività minima | Se la richiesta di caricamento è l'ostacolo |
| Campionamento | Prima batch uno, poi dimensioni immagine supportate più basse in un'esecuzione separata | Se il carico intermedio rientra a una dimensione inferiore |
| Decodifica VAE dopo il campionamento | Una decodifica VAE tiled compatibile | Se la decodifica era il picco che ha fallito |
| Upscaling o elaborazione video | Un input più piccolo o meno frame, se supportato | Se la dimensione dell'input di quella fase determina il fallimento |
| Un nodo personalizzato | L'equivalente integrato più piccolo supportato | Se il fallimento è specifico di quel percorso del nodo |

Questi sono esperimenti, non garanzie. Un checkpoint più piccolo può cambiare la famiglia di modelli, i nodi richiesti o la qualità dell'output, quindi usa un workflow che lo supporti. Se il primo errore riguarda il caricamento dei pesi, ridurre la qualità JPEG finale non cambierà la quantità di memoria richiesta dal modello.

Tieni un registro semplice di modello, seed, risoluzione, batch, nodo modificato e risultato. Mantieni lo stesso seed quando il workflow lo supporta, così i confronti visivi sono più facili, riconoscendo comunque che cambiare precisione o nodi può comunque cambiare l'immagine. Una volta che una configurazione ridotta arriva a termine, ripristina un requisito alla volta finché la fase limitante non diventa chiara.

## Riduci una richiesta alla volta

Parti da una dimensione del batch pari a uno e da una risoluzione supportata più piccola. Se il workflow arriva così alla fine, aumenta solo una dimensione e ripeti. Raddoppiare sia la larghezza sia l'altezza dell'immagine produce quattro volte i pixel, ma non implica esattamente quattro volte la VRAM totale, perché modelli e nodi diversi hanno costi propri.

Se l'errore avviene in decodifica invece che in campionamento, prova un nodo di decodifica VAE a riquadri compatibile quando il workflow lo supporta. Controlla l'output per giunzioni o altre differenze. Se un singolo modello non riesce a caricarsi, dimensioni di output più piccole da sole potrebbero non risolvere il problema. Prova un modello o una precisione supportati da quel workflow e da quell'hardware.

Salva e chiudi altri lavori pesanti per la GPU prima di un'altra esecuzione. Se la memoria resta occupata dopo un job fallito, riavvia ComfyUI normalmente dopo aver salvato il workflow. Un riavvio può liberare un carico abbandonato, ma non rende affidabile un workflow troppo grande.

## Cambia la decodifica VAE senza ricostruire l'intero workflow

La [documentazione di ComfyUI VAE Decode Tiled](https://docs.comfy.org/built-in-nodes/VAEDecodeTiled) descrive la decodifica di campioni latenti in tile più piccoli. In una copia salvata di un workflow immagine compatibile, collega gli stessi campioni latenti e lo stesso VAE al nodo di decodifica tiled, quindi collega il suo output immagine al nodo di salvataggio o anteprima esistente. Conserva il workflow originale, così la modifica è reversibile.

Parti dai valori predefiniti disponibili del nodo invece di copiare diversi valori di tile e overlap da un altro modello. Se serve un tile più piccolo, cambia solo quel valore e controlla sia l'uso di memoria sia l'immagine risultante. Pezzi più piccoli possono ridurre il working set ma aggiungono overhead di elaborazione; esamina gradienti uniformi, bordi e dettagli fini prima di accettare il risultato.

Il tiling in decodifica non riduce la memoria necessaria prima per caricare il modello o eseguire il sampler. Se l'esecuzione non arriva mai alla decodifica, riporta l'indagine alla fase che fallisce. Un VAE video o un modello specializzato può richiedere un proprio nodo compatibile, quindi non sostituire un decoder immagine solo perché il suo nome contiene “tiled”.

## Usa il percorso di ottimizzazione adatto alla tua installazione

La guida ufficiale documenta `--lowvram` per le installazioni manuali. Per un'installazione manuale avviata dal proprio ambiente, la forma è:

```
python main.py --lowvram
```

Non è un comando universale da incollare in ComfyUI Desktop, in un pacchetto portabile o in un launcher di terze parti. Usa le impostazioni di avvio supportate da quell'installazione e mantieni gli argomenti esistenti. Spostare il lavoro fuori dalla memoria GPU può scambiare velocità e RAM di sistema con una minore richiesta di VRAM.

Per gli errori che coinvolgono nodi personalizzati, confronta con un workflow integrato e segui la [risoluzione dei problemi dei nodi personalizzati](https://docs.comfy.org/troubleshooting/custom-node-issues) di ComfyUI. Conserva il workflow originale e annota quali nodi sono stati disattivati. Un nodo personalizzato mancante cambia il workflow, quindi confronta il più piccolo compito equivalente che riesci a riprodurre.

## Ripristina le impostazioni di avvio dopo il confronto

Conserva una copia del launcher o un appunto dei suoi argomenti prima di provare un'opzione di memoria. Un ambiente Python manuale, il pacchetto portable per Windows e l'app Desktop non partono necessariamente allo stesso modo. Aggiungi un'opzione solo tramite il meccanismo che avvia effettivamente questa installazione; creare un secondo ambiente Python può introdurre un problema diverso.

Il [riferimento ai flag di avvio](https://docs.comfy.org/development/comfyui-server/startup-flags) di ComfyUI descrive diversi controlli indipendenti di memoria e cache. Non sono una raccolta di opzioni da abilitare tutte insieme. Per esempio, ridurre la cache dei risultati può abbassare la memoria trattenuta ma causare l'esecuzione ripetuta di più nodi. L'offload su CPU può richiedere RAM di sistema aggiuntiva e rallentare il workflow.

Dopo un'esecuzione riuscita, verifica che l'output sia completo e utilizzabile, poi ripeti l'attività normale. Se la modifica consente solo un piccolo test ma il workflow richiesto fallisce ancora, registra quel limite. Rimuovi un argomento di test inutile dal launcher originale e torna all'ultima configurazione funzionante prima di un altro esperimento.

Se il collo di bottiglia è l'impegno di memoria del sistema, controlla Memoria di Windows insieme alla memoria GPU e mantieni una configurazione del file di paging funzionante. Aumentare la capacità del disco, aumentare il limite del file di paging e ridurre la domanda di VRAM dedicata sono interventi diversi; nessuno deve essere presentato come rimedio universale per gli altri.

## Tieni la pulizia dell'output come attività separata

Immagini e video generati possono occupare molto spazio su disco. Esaminali per progetto e conserva il workflow e le risorse necessarie a riprodurre i risultati di valore. Fai un backup di tutto ciò che intendi conservare prima di eliminare l'unica copia.

Se l'errore è una carenza di commit di Windows, la [guida alla memoria di Windows](/it/windows/blog/windows-high-memory-usage) spiega in cosa si differenzia dalla VRAM. Non eliminare il file di paging per far sembrare il disco più pulito. Quando segnali un errore persistente, includi l'errore esatto, GPU e driver, tipo di installazione e il più piccolo workflow che fallisce, rimuovendo prompt e percorsi privati.


Canonical: https://mole.fit/it/windows/blog/comfyui-out-of-memory-windows