MOSS-Image: il ripack ComfyUI di OpenMOSS-Team, workflow e requisiti reali

MOSS-Image è un modello open di generazione di immagini da 5 miliardi di parametri, e la notizia non è il modello: è che il giorno stesso del lancio (16 ottobre 2026) era già dentro ComfyUI, con i file già tagliati nel formato giusto e quattro workflow pronti da caricare. È la differenza tra comprare un'auto usata da rimettere a posto e riceverne una che parte alla consegna: qui i pesi, l'encoder e i file di configurazione stanno dove ComfyUI se li aspetta, e l'unica decisione vera è quanto spazio ha la tua GPU.

Cos'è MOSS-Image

MOSS-Image è un DiT (Diffusion Transformer) da 5B di parametri pubblicato da OpenMOSS-Team con licenza Apache 2.0, pesi e codice inclusi. L'architettura completa che gira sul tuo hardware è formata da tre pezzi:

• Il DiT base da 5B — il generatore vero e proprio, nei checkpoint MOSS-Image-Base (il punto di partenza, quello su cui far fine-tune) e MOSS-Image-SFT (raffinato su dati curati: testi meglio raggruppati e layout più pulito).
• L'encoder di testo Qwen3.5 da 9B — legge il prompt, fino a 4.000 token, e manda la rappresentazione al DiT.
• La VAE di FLUX.2 — comprime e decomprime l'immagine; nel ripack ci sono la versione completa e una "small".

Tre caratteristiche lo distinguono dai modelli di immagini che già conosci. Il controllo del layout: nel prompt puoi includere una struttura JSON con bounding box e dire al modello dove mettere ogni elemento. Il rendering del testo: i testi nell'immagine sono uno dei punti di forza dichiarati. E gli stili: anime e fotorealistico entrambi coperti, senza LoRA di terze parti. I settaggi di default sono quelli riportati nel repository ufficiale: sampler Euler di flow matching, 50 step, CFG 3, shift 5.

Il ripack ComfyUI: come si installa

Il giorno del rilascio, Comfy-Org ha integrato MOSS-Image in modo nativo (PR #17095, 16 ottobre 2026) — niente plugin, niente workflow di terze parti. Il ripack ufficiale su Hugging Face contiene esattamente i file che servono, divisi per cartella:

• diffusion_models/ — il DiT in bf16 (Base e SFT) e in int8_convrot
• text_encoders/ — Qwen3.5 9B in bf16, int8 e w4a8_gptq
• loras/ — color_depth_control e edit_rank_64_bf16
• vae/ — flux2-vae e flux2-vae_small

Ogni file si mette nella cartella che gli compete dentro la tua installazione ComfyUI: è tutto, non c'è altro da scaricare. Il ripack include quattro workflow pronti (text-to-image, text-to-image da Base, e due layout-guided), e il mese scorso ha registrato 3,7 milioni di download — il segnale più onesto che il flusso funzioni.

Il setup Python, se lavori dal repository invece che da ComfyUI, richiede Python 3.10+, PyTorch 2.9+, diffusers ≥ 0.38 e transformers ≥ 5.3, come indicato nella model card di MOSS-Image-Base.

VRAM reale: la tabella che conta

I 28 GB di pesi in bf16 non sono un numero da prendere alla lettera: sono la somma di due componenti molto diverse. Il conto:

Pezzo	Parametri	Peso in bf16
DiT	5B	5 × 2 byte = 10 GB
Encoder Qwen3.5	9B	9 × 2 byte = 18 GB
Totale pesi	14B	28 GB

L'encoder pesa il 64% del modello. È questo il motivo per cui la versione bf16 completa non sta su una GPU da 24GB: anche togliendo tutto il resto, l'encoder da solo occupa 18GB. La via d'uscita sono le varianti quantizzate che stanno già nel ripack.

Combinazione (file del ripack)	Pesi	VRAM realistica*	Dove sta
DiT bf16 + encoder bf16	~28 GB	~31 GB	RTX 5090 32GB (stretto), Mac Studio 512GB
DiT int8 + encoder bf16	~23 GB	~26 GB	RTX 5090 32GB, Mac Studio 64GB
DiT w4a8 + encoder w4a8	~8 GB	~11 GB	RTX 4070 Ti Super 16GB, RTX 3060 12GB (stretto)

*Pesi + ~3GB di runtime (attivazioni, VAE, workspace del sampler) a 1024px con 50 step. I pesi sono calcolati sui parametri effettivi (1 byte/parametro per int8, ~0,56 per w4a8); il runtime è una stima dal comportamento tipico dei DiT in inferenza.

Due conseguenze pratiche. Se hai 24GB, la riga intermedia è il punto d'ingresso su una 32GB e non passa su una 24GB: con 24GB parti dalla riga w4a8 (~11GB), che lascia margine per risoluzione e step extra. Se hai un Mac con memoria unificata, il modello ci sta intero nella RAM condivisa e la regola è la stessa: pesi + margine.

E i limiti?

• I pesi quantizzati non hanno benchmark ufficiali. La tabella sopra è il conto sui byte, non una misura della qualità: w4a8 sull'encoder è la quantizzazione più aggressiva, e il testo renderizzato — il punto di forza dichiarato del modello — è proprio quello che soffre di più la compressione. Verifica sul tuo caso d'uso.
• Base vs SFT non è "base = peggio". SFT è raffinato su dati curati e dà layout e testi più puliti; Base è il checkpoint su cui far girare i tuoi LoRA. Se fai editing personalizzato, parti da Base.
• La VAE è in float32 nella distribuzione Base: è piccola in assoluto, ma non si quantizza insieme agli altri due pesi.
• Prompt lunghi non significano risoluzione alta. I 4.000 token di prompt sono capacità di contesto, non pixel: le dimensioni di output devono comunque essere multipli di 16.

Vedi anche

• Modelli di immagini in locale: da SDXL a Qwen-Image — il quadro generale dei generatori che girano sul tuo hardware
• ComfyUI 0.40 e comfy_attention — il motore che fa girare questo workflow
• Quantizzazione: ottenere di più dallo stesso hardware — come leggere i formati int8 e w4a8 della tabella sopra

Fonti

• OpenMOSS/MOSS-Image — repository GitHub
• Comfy-Org/MOSS-Image — ripack ComfyUI (Hugging Face)
• OpenMOSS-Team/MOSS-Image-Base — model card (Hugging Face)

In sintesi

MOSS-Image porta il formato "DiT 5B + encoder Qwen3.5 9B" in licenza Apache 2.0, e il ripack ComfyUI lo rende installabile in dieci minuti: file nelle cartelle giuste, quattro workflow inclusi. Il costo vero è la VRAM: 28GB di pesi in bf16, con l'encoder che da solo ne pesa 18, e la via d'uscita sotto i 24GB è la coppia w4a8 che scende a ~11GB realistici. Se la tua GPU è da 16GB o più, hai un workflow di immagini locale che gestisce layout, testo e prompt lunghi — senza abbonamenti.

Articolo generato con IA