SSD Nodes Learn 8GB di RAM — $66/anno
Guide Matt ConnorDi Matt Connor · Aggiornato 2026-08-02

Requisiti hardware per Stable Diffusion: guida pratica

Scopri l'hardware necessario per eseguire Stable Diffusion in locale. Analizziamo le prestazioni reali tra CPU e GPU, i limiti di SDXL e lo spazio disco per i modelli.

Cosa richiede realmente un generatore di immagini AI self-hosted

Un generatore di immagini AI self-hosted è composto da una web app e un file modello. L'applicazione è ComfyUI e viene eseguita su qualsiasi sistema Linux. Il modello è ciò che determina i requisiti hardware. Un checkpoint di classe SDXL è un singolo file da 6.94 GB e deve risiedere nella memoria della GPU. Questo singolo fatto definisce l'intero budget, quindi leggi la scala gerarchica dell'hardware qui sotto prima di noleggiare qualsiasi risorsa.

Il riassunto onesto: un VPS basato solo su CPU può installare ed eseguire il software, ed è in grado di generare immagini a 512x512 con un modello più datato Stable Diffusion 1.5 in uno o due minuti per immagine. Lo stesso sistema che esegue SDXL a 1024x1024 impiega dai dieci ai venti minuti per immagine. Non si tratta di una configurazione guasta. È aritmetica, e questa guida la spiega.

Perché la dimensione del modello determina la macchina

La generazione di immagini esegue un ciclo di denoising. Un rendering a 30 step passa l'intero modello sull'immagine 30 volte e ogni passaggio legge ogni peso. SDXL a mezza precisione occupa circa 6.9 GB di pesi, quindi un rendering a 30 step sposta circa 200 GB attraverso la memoria prima che l'immagine sia visibile.

Una GPU con 24 GB di memoria video (VRAM, la memoria saldata accanto al chip grafico) legge a centinaia di gigabyte al secondo e contiene tutti i 6.9 GB contemporaneamente. Una VPS con CPU legge la RAM di sistema a decine di gigabyte al secondo e non dispone di hardware a matrice per le convoluzioni, quindi lo stesso ciclo viene eseguito da uno a due ordini di grandezza più lentamente. Questa è la stessa argomentazione sulla larghezza di banda della memoria che regola i modelli di testo, e vale la pena leggerla insieme a quando una VPS con GPU vale effettivamente la spesa.

La generazione di immagini differisce dalla generazione di testo per un aspetto rilevante. Un modello di chat trasmette i token, quindi una macchina lenta sembra comunque utilizzabile perché le parole appaiono mentre le leggi. Un'immagine appare solo quando l'ultimo step è terminato. Lento significa fissare una barra di avanzamento.

La scala dell'hardware, con numeri reali

Il blocco sottostante contiene valori tipici per un'immagine SDXL a 1024x1024, 30 step, campionatore Euler, aggiornati a luglio 2026. Considerali come ordini di grandezza. Il campionatore, il numero di step e la risoluzione possono modificarli.

ChartOne SDXL image, 1024x1024, 30 steps (typical, July 2026)
The data behind this chart
[
  {
    "label": "8 vCPU VPS, no GPU",
    "seconds_per_image": 780
  },
  {
    "label": "8GB VRAM GPU",
    "seconds_per_image": 32
  },
  {
    "label": "12GB VRAM GPU",
    "seconds_per_image": 18
  },
  {
    "label": "24GB VRAM GPU",
    "seconds_per_image": 9
  }
]

La riga della CPU indica 780 secondi, circa tredici minuti. La scheda da 24 GB impiega 9 secondi. Questo è il divario che stai colmando con l'acquisto.

Interpreta la scala in questo modo. Sotto gli 8 GB di VRAM, SDXL funziona comunque, poiché ComfyUI sposta automaticamente i layer nella RAM di sistema e può gestire una scheda con appena 1 GB. Lo spostamento (offloading) richiede tempo a ogni step, quindi una scheda da 6 GB si avvicina più a un minuto per immagine che a trenta secondi. A 8 GB il modello base viene caricato interamente e il rendering è fluido. A 12 GB puoi mantenere uno o due ControlNet insieme al checkpoint senza ricorrere all'offloading. A 24 GB puoi eseguire SDXL, il refiner e l'upscaling in un unico workflow, e puoi iniziare ad addestrare adattatori LoRA, operazione che richiede molta più memoria rispetto alla generazione.

Cosa può e cosa non può fare una CPU VPS

Può fare più di quanto ci si aspetti e meno di quanto suggerito dal marketing. È necessario definire chiaramente il limite.

Una CPU VPS può installare ComfyUI, ospitare l'interfaccia web, gestire la libreria dei modelli, gestire la coda ed eseguire la generazione di immagini senza alcuna GPU. Con Stable Diffusion 1.5 a 512x512 e 20 step, si prevedono circa da 60 a 150 secondi per immagine su 8 vCPU moderne con 16 GB di RAM. Per un lavoro in batch eseguito durante la notte, o per un endpoint di immagini a basso volume dietro una coda, questo è assolutamente accettabile.

Una CPU VPS non può offrire un flusso di lavoro interattivo. L'iterazione dei prompt richiede venti rendering in un'ora, ma a tredici minuti ciascuno se ne ottengono quattro. Inoltre, non può eseguire l'addestramento. Il fine-tuning di LoRA su CPU si misura in giorni, non in ore, quindi va considerato non disponibile.

La regola della memoria per il solo utilizzo della CPU è diversa da quella per la GPU. I pesi vengono caricati nella RAM di sistema, quindi è necessaria la dimensione del modello più lo spazio di lavoro: circa 16 GB di RAM per SDXL e circa 8 GB per SD 1.5. Un'istanza da 4 GB avvierà ComfyUI per poi essere terminata dall'out-of-memory killer durante il primo rendering; ciò si manifesta con la scomparsa del processo con Killed in dmesg e l'assenza di un traceback Python.

Installazione di ComfyUI su una macchina con GPU

Questi sono i comandi upstream. Iniziare da un'installazione pulita di Ubuntu 24.04 con il driver NVIDIA già presente. Verificare prima il driver, poiché ogni errore successivo appare identico senza questo controllo.

nvidia-smi

Questo deve stampare una tabella con la scheda e una versione di CUDA. command not found, o NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver, significa che il driver manca o che il modulo del kernel non è stato caricato dopo un aggiornamento. Risolvere il problema prima di continuare, poiché ComfyUI passerà silenziosamente alla CPU e si finirà per incolpare il software.

sudo apt update
sudo apt install -y git python3-venv python3-pip wget
git clone https://github.com/comfyanonymous/ComfyUI.git
cd ComfyUI
python3 -m venv venv
. venv/bin/activate
pip install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cu130
pip install -r requirements.txt

L'ambiente virtuale non è un consiglio facoltativo. PyTorch scarica un ampio albero di dipendenze e installarlo a livello di sistema su una macchina che esegue altro è il modo in cui si danneggiano le altre applicazioni. Verificare che PyTorch possa vedere la scheda prima di procedere.

python -c "import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))"

True più il nome della scheda significa che lo stack funziona. False significa che il wheel installato non corrisponde al driver, solitamente perché era già presente nella cache un wheel di torch solo per CPU. Reinstallare con l'index URL indicato sopra.

Ottenere un modello e pianificare lo spazio su disco

ComfyUI viene distribuito senza pesi. I checkpoint vanno inseriti in models/checkpoints, i file VAE in models/vae e gli adattatori LoRA in models/loras.

cd ~/ComfyUI/models/checkpoints
wget https://huggingface.co/stabilityai/stable-diffusion-xl-base-1.0/resolve/main/sd_xl_base_1.0.safetensors

Preferire sempre .safetensors rispetto a .ckpt. Un file .ckpt è un oggetto Python serializzato (pickled) e il suo caricamento esegue codice proveniente dall'autore del file. Il formato safetensors contiene solo tensori, pertanto un file malevolo non può eseguire alcun codice.

Lo spazio di archiviazione è il costo che spesso viene trascurato. Un singolo checkpoint base SDXL occupa 6.94 GB. Il refiner ne occupa altri 6 GB. Un singolo modello ControlNet varia da 1.4 a 2.5 GB, un upscaler da 60 a 350 MB e un LoRA da 20 a 400 MB. Chiunque si appassioni a questo strumento scarica un secondo e un terzo modello base entro una settimana. Prevedere 100 GB di spazio su disco per un'installazione operativa e monitorare anche la directory degli output: i file PNG 1024x1024 pesano da 1 a 2 MB ciascuno e un batch non presidiato riempie rapidamente un disco di piccole dimensioni. Collocare models/ e output/ su un volume espandibile ed eseguire il backup dei file JSON dei workflow con strumenti come backup incrementali cifrati verso object storage. I pesi sono scaricabili nuovamente. I workflow ottimizzati, invece, no.

Eseguire e raggiungere il servizio in sicurezza

cd ~/ComfyUI
. venv/bin/activate
python main.py --listen 127.0.0.1 --port 8188

ComfyUI è in ascolto sulla porta 8188. Su una macchina dotata solo di CPU, aggiungere --cpu, che forza l'utilizzo del percorso CPU invece di restituire errore per l'assenza di un dispositivo CUDA.

Effettuare il bind su 127.0.0.1, non su 0.0.0.0. ComfyUI non dispone di una schermata di login né di account utente. Chiunque raggiunga la porta può accodare processi, leggere ogni immagine generata e installare nodi personalizzati, il che equivale all'esecuzione di codice arbitrario sul server. Accedere invece tramite un tunnel SSH dal proprio portatile.

ssh -N -L 8188:127.0.0.1:8188 you@your-server

Aprire quindi http://127.0.0.1:8188 in locale. Se è necessario un accesso multi-utente reale, posizionare un reverse proxy con autenticazione davanti al servizio e mantenere l'applicazione in ascolto su localhost. Lo stesso principio si applica a qualsiasi servizio self-hosted privo di autenticazione, ed è lo standard in implementazioni Docker Compose su VPS.

Mantenere il processo attivo con systemd

Una coda di rendering che si interrompe alla chiusura della sessione SSH non è un servizio. Crea /etc/systemd/system/comfyui.service.

[Unit]
Description=ComfyUI
After=network-online.target

[Service]
User=comfy
WorkingDirectory=/home/comfy/ComfyUI
ExecStart=/home/comfy/ComfyUI/venv/bin/python main.py --listen 127.0.0.1 --port 8188
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable --now comfyui
systemctl status comfyui

active (running) e una riga di log che riporta To see the GUI go to: http://127.0.0.1:8188 indicano che il servizio è attivo. Nota che ExecStart richiama direttamente l'interprete all'interno dell'ambiente virtuale, poiché systemd non esegue il profilo della shell e activate non avviene mai.

La raccomandazione pragmatica in base al budget

Se vuoi provare la generazione di immagini e il costo è più importante della velocità, prendi un VPS CPU con 16 GB di RAM, esegui SD 1.5 a 512x512 e accetta un tempo di un minuto o due per immagine. Questo è il punto di ingresso onesto e costa una frazione di qualsiasi soluzione dotata di GPU. È anche il posto giusto dove ospitare la libreria dei modelli e i flussi di lavoro mentre decidi.

Se iteri sui prompt quotidianamente, noleggia a ore una GPU con almeno 12 GB di VRAM da un cloud GPU e spegnila quando hai finito. La generazione di immagini è un lavoro a picchi e una GPU inattiva fatturata mensilmente è il modo più comune in cui le persone spendono troppo in questo ambito. Mantieni i checkpoint su uno storage a blocchi economico e montali.

Se offri servizi ad altri o addestri adattatori LoRA, ti servono 24 GB di VRAM e una macchina che tieni sempre attiva. A quel punto la stessa macchina solitamente si ripaga eseguendo anche un modello linguistico locale, che è la configurazione descritta in self-hosting di un LLM con Ollama.

Qualunque livello tu scelga, misura la tua macchina prima di credere a qualsiasi dato pubblicato. Metti in coda lo stesso prompt cinque volte e leggi i secondi per iterazione che ComfyUI stampa nella sua console. Quel numero è la tua reale posizione sulla scala.

FAQ

Posso eseguire Stable Diffusion senza una GPU?

Sì. ComfyUI funziona con python main.py --cpu e genera immagini reali senza una scheda grafica dedicata. Prevedi circa da 60 a 150 secondi per immagine per Stable Diffusion 1.5 a 512x512, e da dieci a venti minuti per SDXL a 1024x1024, su 8 vCPU moderne. Questa configurazione è adatta per elaborazioni batch notturne ed endpoint a basso volume. Non è adatta per l'iterazione dei prompt, mentre l'addestramento è del tutto fuori portata.

Quanta VRAM serve per SDXL?

8 GB permettono di eseguire SDXL comodamente a 1024x1024. Al di sotto di questa soglia, ComfyUI sposta automaticamente i layer nella RAM di sistema e continua a funzionare fino a circa 1 GB di VRAM, ma ogni operazione di spostamento comporta un aumento dei tempi di elaborazione. 12 GB consentono di mantenere un ControlNet insieme al checkpoint, mentre 24 GB coprono il modello base, il refiner e l'upscaling in un unico workflow, rappresentando il limite pratico per l'addestramento di adattatori LoRA.

Quanto spazio su disco richiedono i modelli?

Il solo checkpoint base di SDXL occupa 6,94 GB, a cui si aggiungono circa 6 GB per il refiner. I modelli ControlNet pesano da 1,4 a 2,5 GB ciascuno, gli adattatori LoRA da 20 a 400 MB e gli upscaler fino a 350 MB. Prevedi 100 GB per un'installazione operativa con alcuni modelli base e monitora separatamente la directory di output, dato che i file PNG a 1024x1024 occupano da 1 a 2 MB ciascuno.

È sicuro esporre ComfyUI su internet?

No. ComfyUI non dispone di alcun tipo di autenticazione e il suo sistema di custom-node installa ed esegue codice Python dall'interfaccia; pertanto, una porta aperta espone il server all'esecuzione remota di codice. Esegui il bind su 127.0.0.1, accedi tramite un tunnel SSH con ssh -N -L 8188:127.0.0.1:8188 you@your-server e utilizza un reverse proxy con autenticazione se l'accesso è richiesto da più persone.

Perché il mio rendering viene terminato senza messaggi di errore?

Se il processo scompare con Killed in dmesg senza alcun traceback Python, si tratta dell'out-of-memory killer di Linux e non di un bug di ComfyUI. Su una macchina basata solo su CPU, i pesi risiedono nella RAM di sistema; pertanto, SDXL richiede circa 16 GB e SD 1.5 circa 8 GB, oltre allo spazio di lavoro. Aumenta la RAM, aggiungi swap o passa a un modello più piccolo e a una risoluzione inferiore.

#stable-diffusion#comfyui#ai#images#self-hosting#gpu