Generatore AI self-hosted: hardware e costi reali

Cosa serve davvero a un generatore di immagini AI self-hosted

Un generatore di immagini AI self-hosted è composto da un'applicazione web e da un file di modello. L'applicazione è ComfyUI e può essere eseguita su qualsiasi server Linux. Il modello determina l'hardware necessario. Un checkpoint della classe SDXL è un singolo file da 6.94 GB e deve essere caricato nella memoria della GPU. Questo dato determina l'intero budget, quindi consulta la panoramica dell'hardware riportata di seguito prima di noleggiare un server.

In sintesi: un VPS con sola CPU può installare ed esporre il software e generare immagini a 512x512 usando un modello Stable Diffusion 1.5 meno recente, in uno o due minuti per immagine. Lo stesso server, eseguendo SDXL a 1024x1024, impiega da dieci a venti minuti per immagine. Non è un'installazione malfunzionante. È una conseguenza dei calcoli, spiegata in questa guida.

Perché le dimensioni del modello determinano la macchina

La generazione di immagini esegue un ciclo di denoising. Un rendering in 30 passaggi esegue il denoiser, la UNet di SDXL, sull’immagine 30 volte e ogni passaggio legge tutti i pesi della UNet. I due encoder testuali vengono eseguiti una volta prima del ciclo e la VAE decodifica una volta al termine, quindi non rientrano nel costo di ogni passaggio. La UNet di SDXL in half precision occupa 5.14 GB di pesi. In questa semplificazione, un rendering in 30 passaggi trasferisce quindi circa 154 GB di pesi attraverso la memoria prima di produrre un’immagine, oltre ai tensori intermedi.

Una GPU con 24 GB di memoria video (VRAM, la memoria saldata accanto al chip grafico) legge a centinaia di gigabyte al secondo e mantiene tutti i 6.9 GB disponibili contemporaneamente. Una CPU VPS legge la RAM di sistema a decine di gigabyte al secondo e non dispone di hardware matriciale per le convoluzioni. Per questo lo stesso ciclo richiede da uno a due ordini di grandezza in più. È lo stesso argomento basato sulla larghezza di banda della memoria che determina le prestazioni dei modelli testuali. Conviene leggerlo insieme a quando una VPS con GPU vale davvero il costo.

La generazione di immagini differisce dalla generazione di testo per un aspetto importante. Un modello conversazionale trasmette i token in streaming, quindi anche una macchina lenta resta utilizzabile perché le parole compaiono mentre si legge. Un’immagine compare soltanto quando termina l’ultimo passaggio. Se è lenta, si resta a guardare una barra di avanzamento.

La scala hardware, con numeri reali

Il blocco seguente riporta valori tipici per una singola immagine SDXL a 1024x1024, 30 step, con sampler Euler, aggiornati a luglio 2026. Considerali come ordini di grandezza. Il sampler, il numero di step e la risoluzione possono modificarli.

[
  {
    "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, cioè circa tredici minuti. La scheda da 24 GB impiega 9 secondi. È questa la differenza prestazionale che stai acquistando.

Interpreta la scala nel modo seguente. Con meno di 8 GB di VRAM, SDXL continua a funzionare, perché ComfyUI gestisce insieme VRAM e RAM di sistema e scarica automaticamente i pesi del modello. A ottobre 2026, il README del progetto indica come requisiti minimi 4 GB di VRAM e 8 GB di RAM di sistema, usando il caricamento asincrono dei pesi. Lo scaricamento dei pesi aggiunge tempo a ogni step, quindi una scheda da 6 GB impiega più probabilmente circa un minuto per immagine che trenta secondi. Con 8 GB il modello base entra in memoria e il rendering procede senza particolari limitazioni. Con 12 GB puoi mantenere in memoria un ControlNet o due ControlNet insieme al checkpoint, senza scaricare i pesi. Con 24 GB puoi eseguire SDXL, il refiner e l'upscaling nello stesso workflow, oltre ad addestrare adattatori LoRA con memoria disponibile. L'addestramento richiede meno memoria: la guida all'addestramento di SDXL per il trainer kohya-ss sd-scripts indica che l'addestramento LoRA può essere eseguito con 8 GB di memoria GPU, mentre sono consigliati 10 GB. Per ottenere questo risultato, la guida indica di addestrare soltanto la U-Net, attivare il gradient checkpointing, memorizzare nella cache gli output del text encoder e i latent, usare un optimizer a 8 bit o Adafactor e ridurre il parametro LoRA dim a un valore compreso tra 4 e 8 su una scheda da 8 GB. La guida LoRA per la GUI kohya_ss, che integra questi script, è più prudente: indica di usare una GPU con almeno 12 GB di memoria per l'addestramento LoRA.

Cosa può e non può fare una CPU VPS

Può fare più di quanto molti si aspettino e meno di quanto lasci intendere il marketing. È importante definire con precisione questo limite.

Una CPU VPS può installare ComfyUI, pubblicare l'interfaccia web, contenere la libreria dei modelli, gestire la coda e generare immagini senza alcuna GPU. Con Stable Diffusion 1.5 a 512x512 e 20 passaggi, su 8 vCPU moderne con 16 GB di RAM una singola immagine richiede in genere da 60 a 150 secondi. Per un processo batch eseguito durante la notte o per un endpoint di generazione a basso volume protetto da una coda, le prestazioni sono adeguate.

Una CPU VPS non consente un flusso di lavoro interattivo. Iterare sui prompt significa eseguire 20 render in un'ora; se ciascuno richiede tredici minuti, se ne ottengono soltanto quattro. Inoltre, non consente di eseguire il training. Il fine-tuning LoRA su CPU richiede giorni, non ore, quindi va considerato non disponibile.

La regola relativa alla memoria per l'esecuzione solo su CPU è diversa da quella per la GPU. I pesi vengono caricati nella RAM di sistema, quindi servono le dimensioni del modello e spazio di lavoro aggiuntivo: circa 16 GB di RAM per SDXL e circa 8 GB per SD 1.5. Una macchina con 4 GB avvierà ComfyUI, ma il processo verrà terminato dall'oom killer durante il primo render. Il processo scomparirà con Killed in dmesg, senza alcun traceback Python.

Installare ComfyUI su una macchina con GPU

Questi sono i comandi del progetto upstream. Partire da un'installazione pulita di Ubuntu 24.04 con il driver NVIDIA già installato. Verificare prima il driver, perché senza questo controllo tutti gli errori successivi hanno lo stesso aspetto.

nvidia-smi

Deve essere visualizzata 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 indicano che il driver manca oppure che il modulo del kernel non è stato caricato dopo un aggiornamento. Risolvere il problema prima di continuare, perché ComfyUI passerà silenziosamente alla CPU e si potrebbe attribuire la causa al 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 è facoltativo. PyTorch installa un albero di dipendenze ampio e installarlo a livello di sistema su un server che esegue anche altri servizi può compromettere gli altri componenti. Verificare che PyTorch rilevi la scheda prima di procedere.

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

True insieme al nome della scheda indica che lo stack funziona. False indica che il wheel installato non è compatibile con il driver, in genere perché era già presente nella cache un wheel di torch per la sola CPU. Reinstallare usando l'index URL sopra.

Scarica un modello e pianifica lo spazio su disco

ComfyUI non include alcun file di pesi. I checkpoint vanno 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

Preferisci sempre .safetensors a .ckpt. Un file .ckpt è un oggetto Python serializzato con pickle e il suo caricamento esegue codice proveniente da chi lo ha creato. Il formato safetensors contiene soltanto tensori, quindi un file ostile non può eseguire codice.

Lo spazio di archiviazione è un costo che spesso viene dimenticato. Un checkpoint base SDXL occupa 6.94 GB. Il refiner richiede altri 6 GB. Un modello SDXL ControlNet occupa da 320 MB per il modello Canny piccolo a 2.5 GB per quello completo in precisione dimezzata. Un upscaler è più piccolo: il modello standard Real-ESRGAN x4plus occupa 67 MB, il modello anime 17.9 MB e il modello anime video 2.5 MB. Una LoRA occupa da alcune decine di megabyte fino a 787 MB per gli adattatori Hyper-SDXL di ByteDance. Chi usa questo sistema scarica spesso un secondo e un terzo modello base entro una settimana. Prevedi 100 GB di spazio su disco per un'installazione operativa e controlla anche la directory degli output: i file PNG 1024x1024 occupano da 1 a 2 MB ciascuno e un batch lasciato in esecuzione riempie silenziosamente un disco di piccole dimensioni. Posiziona models/ e output/ su un volume che puoi espandere e configura il backup dei file JSON dei workflow con una soluzione come backup incrementali crittografati su object storage. I pesi possono essere scaricati di nuovo. I workflow che hai ottimizzato, invece, no.

Eseguilo e accedi in modo sicuro

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

ComfyUI è in ascolto sulla porta 8188. Su un host con la sola CPU, aggiungi --cpu: forza l'uso della CPU invece di terminare a causa dell'assenza di un dispositivo CUDA.

Fai il bind su 127.0.0.1, non su 0.0.0.0. ComfyUI ora supporta gli account, ma nessuno di questi protegge il server. Il login disponibile in Settings, nella sezione User, autentica il tuo account Comfy e funziona anche con un'installazione locale: la documentazione di Comfy indica l'accesso tramite email, Google, GitHub e API key. La documentazione descrive questo account come il tuo accesso ai partner node e agli abbonamenti Comfy Cloud, ma non lo presenta come un sistema per proteggere con password il tuo server. Il flag --multi-user abilita soltanto lo storage per utente: a ottobre 2026, il server ricava il nome utente da un'intestazione della richiesta comfy-user e non verifica alcuna password. Chiunque raggiunga la porta può accodare job, leggere tutte le immagini che hai generato e, se hai avviato il server con --enable-manager, installare custom node, eseguendo codice arbitrario sul server. Accedi invece tramite un tunnel SSH dal laptop.

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

Quindi apri http://127.0.0.1:8188 localmente. Se ti serve un accesso realmente multiutente, configura un reverse proxy con autenticazione davanti al servizio e mantieni l'applicazione in ascolto su localhost. Lo stesso principio vale per qualsiasi servizio self-hosted privo di autenticazione ed è il modello standard nelle implementazioni Docker Compose su un VPS.

Esegui il servizio in modo persistente con systemd

Una coda di rendering che si arresta quando chiudi la sessione SSH non è un servizio. Eseguila con un utente comfy senza accesso interattivo, non con il tuo account: i nodi personalizzati sono codice e non devono essere eseguiti con accesso alla tua directory home. Crea l'utente e sposta l'installazione nella sua home:

sudo useradd --system --create-home --home-dir /home/comfy --shell /usr/sbin/nologin comfy
sudo mv ~/ComfyUI /home/comfy/
sudo chown -R comfy:comfy /home/comfy/ComfyUI

L'ambiente virtuale continua a funzionare dopo lo spostamento perché l'unità richiama direttamente il relativo python. Scrivi quindi /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 con To see the GUI go to: http://127.0.0.1:8188 indicano che il servizio è attivo. Nota che ExecStart indica direttamente l'interprete all'interno dell'ambiente virtuale, perché systemd non esegue il profilo della shell e activate non viene mai eseguito.

La raccomandazione pragmatica in base al budget

Se vuoi provare la generazione di immagini e il costo è più importante della velocità, scegli un VPS con CPU e 16 GB di RAM, esegui SD 1.5 a 512x512 e accetta tempi di uno o due minuti per immagine. Questo è il punto di ingresso realistico e costa una frazione rispetto a qualsiasi soluzione con una GPU. È anche il luogo adatto per ospitare la libreria dei modelli e i workflow mentre valuti quale configurazione adottare.

Se modifichi i prompt ogni giorno, noleggia a ore, tramite un GPU cloud, una GPU con almeno 12 GB di VRAM e arrestala quando hai finito. La generazione di immagini è un'attività discontinua e una GPU inattiva con fatturazione mensile è il modo più comune per spendere troppo in questo contesto. Conserva i checkpoint su uno storage a blocchi economico e montali.

Se offri il servizio ad altre persone o addestri regolarmente adattatori LoRA, prevedi 24 GB di VRAM e una macchina sempre disponibile. La guida SDXL di sd-scripts indica che l'addestramento LoRA è possibile con 8 GB, con 10 GB consigliati, usando le relative impostazioni per ridurre il consumo di memoria; la guida LoRA della GUI kohya_ss richiede almeno 12 GB. Il valore di 24 GB indicato nella guida di sd-scripts si riferisce al fine-tuning completo di SDXL con batch size 1. Una scheda da 24 GB è quindi sufficiente per il lavoro con LoRA e consente ancora di eseguire il fine-tuning. A quel punto, la stessa macchina di solito giustifica il proprio costo eseguendo anche un language model locale. Questa è la configurazione descritta in self-hosting di un LLM con Ollama.

Qualunque livello tu scelga, misura la tua macchina prima di considerare attendibili i valori pubblicati. Inserisci lo stesso prompt in coda cinque volte e leggi i secondi per iterazione che ComfyUI visualizza nella console. Questo è il tuo reale posizionamento nella scala delle prestazioni.

FAQ

Posso eseguire Stable Diffusion senza una GPU?

Sì. ComfyUI funziona con python main.py --cpu e genera immagini reali anche senza una scheda grafica. Con Stable Diffusion 1.5 a 512x512, su 8 vCPU moderne, occorrono indicativamente da 60 a 150 secondi per immagine; con SDXL a 1024x1024 occorrono da dieci a venti minuti. È sufficiente per elaborazioni notturne e endpoint a basso volume. Non è adatto all'iterazione dei prompt e rende completamente impraticabile l'addestramento.

Quanta VRAM serve per SDXL?

8 GB consentono di eseguire SDXL senza problemi a 1024x1024. Al di sotto di questa quantità, ComfyUI trasferisce automaticamente i pesi del modello nella RAM di sistema e continua a funzionare. A ottobre 2026, il README indica come requisito minimo 4 GB di VRAM più 8 GB di RAM di sistema; ogni passaggio trasferito in memoria di sistema aumenta però i tempi di esecuzione. 12 GB consentono di mantenere un ControlNet insieme al checkpoint, mentre 24 GB sono sufficienti per usare base, refiner e upscaling nello stesso workflow. La guida di kohya-ss sd-scripts indica che l'addestramento LoRA di SDXL può essere eseguito con 8 GB, con 10 GB consigliati, se si usano le impostazioni per il risparmio di memoria; la guida LoRA della GUI di kohya_ss richiede invece almeno 12 GB. Il fine-tuning completo di SDXL richiede 24 GB con batch size 1.

Quanto spazio su disco richiedono i modelli?

Il checkpoint base di SDXL occupa da solo 6.94 GB e il refiner aggiunge circa 6 GB. I modelli ControlNet per SDXL occupano da 320 MB a 2.5 GB ciascuno in half precision, gli adapter LoRA da alcune decine di megabyte a 787 MB e gli upscaler Real-ESRGAN da 2.5 MB a 67 MB. Prevedi 100 GB per un'installazione operativa con alcuni modelli base e monitora separatamente la directory di output, perché i file PNG a 1024x1024 occupano da 1 a 2 MB ciascuno.

È sicuro esporre ComfyUI su Internet?

No. Il login dell'account Comfy nelle impostazioni di ComfyUI funziona da un'installazione locale, ma consente di accedere ai nodi partner e agli abbonamenti cloud di Comfy; nessuna documentazione di Comfy lo presenta come una protezione per il server. Il flag --multi-user separa soltanto lo storage dei singoli utenti e non verifica alcuna password. Con ComfyUI-Manager abilitato, l'interfaccia installa nodi personalizzati, cioè codice Python eseguito sul server; una porta esposta equivale quindi all'esecuzione di codice da remoto. Associalo a 127.0.0.1, raggiungilo tramite un tunnel SSH con ssh -N -L 8188:127.0.0.1:8188 you@your-server e configura davanti a esso un reverse proxy con autenticazione se devono accedervi più persone.

Perché il rendering è stato terminato senza mostrare messaggi di errore?

La scomparsa del processo con Killed in dmesg, senza traceback Python, indica l'intervento dell'out-of-memory killer di Linux, non un bug di ComfyUI. Su una macchina che usa soltanto la CPU, i pesi risiedono nella RAM di sistema; SDXL richiede quindi circa 16 GB e SD 1.5 circa 8 GB, oltre alla memoria di lavoro. Aumenta la RAM, aggiungi swap oppure usa un modello più piccolo e una risoluzione inferiore.