Immagini in locale: ComfyUI 0.40 e comfy_attention - nuovo per tutti i modelli

Generare immagini in locale non è più una novità. Lo è invece un aspetto meno visibile: il motore che guida i modelli. ComfyUI 0.40, uscita il 13 ottobre, tocca proprio quello — e lo fa in un modo che riguarda tutti i modelli, non solo uno specifico.

Il punto di partenza è semplice: la qualità dei modelli open (SDXL, FLUX, Qwen-Image) non è più il collo di bottiglia. Lo è l'infrastruttura che li fa girare: come gestiscono la VRAM, quale kernel di attenzione usano, come escono i risultati. ComfyUI 0.40 risponde a tutte e tre.

comfy_attention: un motore di attenzione per tutti i modelli

Fino a ora, il supporto di ComfyUI al nuovo contenitore di attenzione (AttentionTensorContainer) era limitato a una parte dei modelli. Nella 0.40 viene esteso a tutti i modelli (release 0.40.0).

Cosa cambia in pratica:

• Configurazione per modello — i file di modello possono dichiarare quale kernel di attenzione usare: la nuova configurazione comfy_attention può selezionare il kernel "kitchen sol attention", in più rispetto a flash attention e SDPA.
• Sovrascrittura con i LoRA — un LoRA può sostituire la configurazione di attenzione per layer del modello di base: si addestra una personalizzazione che cambia anche il comportamento di esecuzione, non solo il risultato estetico.

Perché conta: il kernel di attenzione è uno dei pochi punti in cui la stessa GPU produce velocità molto diverse a seconda di come è scritta la matematica. Avere la scelta — per modello, e modificabile con un LoRA — significa ottimizzare lo stesso workflow su un laptop AMD e su una workstation NVIDIA senza toccare il resto della pipeline.

Una nota onesta: la release non pubblica benchmark ufficiali su comfy_attention. Il vantaggio è nell'unificazione e nella configurabilità, non in un numero che ComfyUI abbia misurato e pubblicato.

L'API di asset, in locale

La 0.40 implementa in locale l'API di esportazione degli asset (CORE-454): i risultati del workflow escono come asset gestiti dal sistema, che nella versione arriva attivo di default — si disattiva con --disable-assets.

In pratica: se colleghi ComfyUI a uno strumento esterno (un'interfaccia, uno script, un servizio che consuma i tuoi output), il formato di scambio diventa standard e locale. Nessuna immagine passa da un servizio esterno per essere "registrata" o servita. Per chi monta una piccola linea di produzione grafica sul proprio hardware — catalogo, varianti, asset per il sito — è il pezzo che mancava per automatizzare l'ultimo miglio.

Uscite 3D standard

Tutti i nodi 3D esportano ora il modello come elemento di output 3D standard (PR 16200), e arrivano due nuovi nodi per le telecamere: CreateCameraInfo e CameraAngle.

Il 3D in locale è ancora una nicchia — i modelli 3D open restano lontani dalla qualità fotografica dei DiT — ma la standardizzazione dell'output significa che i workflow 3D si compongono con gli stessi connettori di quelli 2D. Chi sperimenta con render di prodotto o prototipazione ha meno attrito per collegare un generatore 3D a un'immagine.

VRAM reale: la tabella che conta

ComfyUI 0.40 include anche miglioramenti di prestazioni per la bassa VRAM sui LLM Qwen 3.5 (PR 16820) e un caricatore nativo di stack di LoRA (CORE-186). Ma la domanda resta sempre la stessa: quanti GB servono davvero?

Questa è la tabella di riferimento che abbiamo usato negli articoli sui modelli di immagini, valida ancora oggi:

Modello	Parametri	Risoluzione nativa	VRAM consigliata	Architettura
SD 1.5	~0,9B	512px	6-8GB	U-Net
SDXL 1.0	2,6B	1024px	12GB	U-Net
FLUX.1 [schnell]	12B	1024px	16GB	DiT
FLUX.1 [dev]	12B	1024px	16-24GB	DiT
Qwen-Image 2.1	7B	2048px	16GB	DiT

Con Qwen-Image 2.1 il dettaglio vale: in bfloat16 il modello occupa circa 14GB di VRAM. Con 16GB (RTX 4060 Ti 16GB, RTX 5080) gira, con offload verso la CPU se la scena è a 2K; con 24GB (RTX 4090, 3090) è comfort senza offload; sotto i 16GB si riduce l'output a 1024×1024 o si usa l'offload CPU. Come spiegato in Qwen-Image 2.1: generare e modificare immagini in locale, il ragionamento completo — e la scelta in base al budget — è nella guida Modelli di immagini in locale: da SDXL a Qwen-Image.

E i limiti?

• Nessun numero ufficiale — ComfyUI non ha pubblicato speedup per comfy_attention; aspettati miglioramenti, non un moltiplicatore garantito.
• L'API asset è giovane — attiva di default, ma l'ecosistema di strumenti esterni che la consumano sta ancora nascendo.
• Il 3D è sperimentale — output standardizzati, sì; qualità paragonabile alla fotografia, no.

Mentre scrivo: la 0.43 è già uscita

La 0.40 è del 13 ottobre; a oggi è già disponibile la 0.43.0, con il supporto per MOSS-Image (rope scaling, LoRA di color-depth e editing), i nodi per FLUX 3 Max e FLUX 3 Video in 2K/4K, il supporto a Fibo 2.0 e la prima parte dei KV cache a VRAM dinamica (release 0.43.0). Il ritmo di ComfyUI è una release maggiore al mese: un workflow che oggi sfrutta comfy_attention tra un mese potrà contare anche sui nuovi nodi senza rifare l'infrastruttura.

Fonti

• ComfyUI v0.40.0 — release notes
• ComfyUI v0.43.0 — release notes
• Modelli di immagini in locale: da SDXL a Qwen-Image

In sintesi

ComfyUI 0.40 porta comfy_attention a tutti i modelli, con kernel selezionabili per modello e sovrascrivibili via LoRA; attiva di default il sistema di asset con API locale; standardizza l'output 3D dei nodi. La VRAM resta la variabile che decide cosa gira: la tabella sopra è il riferimento. Se il tuo setup ha 16GB, FLUX quantizzato e Qwen-Image 2.1 sono il punto di partenza; se hai 24GB, i DiT a piena qualità senza offload. Per rendere il tutto più efficiente sul tuo hardware, la quantizzazione resta la leva più diretta.

Articolo generato con IA