Come i modelli MoE si distribuiscono diversamente: guida al self-hosting
Qwen3.5-9B occupa 5,3 GB di VRAM. Il suo fratello MoE, Qwen3.5-35B-A3B, ne richiede 18,5 — eppure attiva solo 3 miliardi di parametri per token. Come si spiega?
I modelli Mixture-of-Experts confondono chi li deve deployare perché il conteggio dei “parametri attivi” è fuorviante per la pianificazione hardware. Leggi “3B attivi” e pensi che basti una GPU da 8 GB. Poi il modello non si carica nemmeno.
Questa guida spiega la matematica della VRAM, analizza ogni modello MoE che puoi ospitare in autonomia oggi e mostra come farli girare su hardware accessibile. Useremo la famiglia Qwen 3.5 come esempio ricorrente perché offre il confronto più limpido disponibile: stessa generazione, stessi dati di addestramento, stesse capacità — cambia solo l’architettura.
TL;DR: I modelli Mixture-of-Experts come DeepSeek V3.1 (685B totali, 37B attivi) e Qwen3.5-35B-A3B (36B totali, 3B attivi) instradano ogni token attraverso una frazione dei loro expert — ma i pesi di ogni expert devono restare in memoria. Qwen3.5-9B (denso) occupa 5,29 GB a Q4_K_M; il suo fratello MoE ne richiede 18,49 GB alla stessa quantizzazione pur attivando meno parametri (Unsloth GGUF, 2026). Sotto Q4_K_M, la qualità del routing degrada — quindi non scendere oltre.
Cosa significa “Mixture of Experts” per il deployment?
Dall’inizio del 2025, quasi tutti i principali modelli AI di frontiera usano architetture MoE (NVIDIA Blog, 2025). In un modello denso ogni parametro partecipa a ogni token. In un modello MoE una rete di routing seleziona un sottoinsieme di “expert” per token — ma tutti gli expert devono essere caricati in memoria. Questo singolo fatto spiega quasi ogni sorpresa di deployment che incontrerai.
Pensala così. Un modello denso è un unico chef che usa ogni ingrediente della cucina per ogni piatto. Un modello MoE è un ristorante con 256 chef, ciascuno specializzato, ma devi comunque affittare l’intero edificio anche se solo 8 chef cucinano in un dato momento.
Qwen 3.5: il confronto perfetto
La famiglia Qwen 3.5 ci offre il confronto più pulito possibile. Entrambe le varianti condividono gli stessi dati di addestramento, le stesse capacità (codice, multilingua, ragionamento, chiamate a strumenti, visione) e la stessa finestra di contesto da 262K. L’unica differenza è l’architettura:
- Qwen3.5-9B — denso, 9,65 miliardi di parametri. Ogni parametro si attiva su ogni token.
- Qwen3.5-35B-A3B — MoE, 35,95 miliardi di parametri totali, 256 expert, 8 attivi + 1 condiviso per token. Circa 3 miliardi di parametri si attivano per token.
Stessa famiglia. Stessa generazione. Profili di deployment radicalmente diversi. Ecco cosa fa l’architettura MoE alla tua infrastruttura.
Nota il pattern. Man mano che i modelli MoE crescono, il divario tra parametri totali e attivi si allarga drasticamente. Kimi K2.5 ha oltre mille miliardi di parametri ma ne attiva solo 32 miliardi per token — il 3,1% del totale. Alla tua GPU non interessa quel rapporto. Deve contenerli tutti.
Requisiti VRAM — Perché i modelli MoE richiedono più di quanto ti aspetti
Qwen3.5-35B-A3B necessita 3,5× più VRAM rispetto a Qwen3.5-9B a Q4_K_M pur attivando meno parametri per token (Unsloth GGUF, Unsloth GGUF, 2026). Il motivo è semplice: la VRAM per i pesi del modello scala con i parametri totali, non con quelli attivi. Solo la KV cache scala con i parametri attivi.
La formula
Per qualsiasi modello GGUF quantizzato, la VRAM si suddivide in due parti:
- Pesi del modello = parametri_totali × bit_per_peso / 8. Tutti gli expert inclusi.
- KV cache = proporzionale a parametri_attivi × lunghezza_contesto × dimensione_batch.
In un modello denso, parametri totali = parametri attivi, quindi la distinzione non conta. Nei modelli MoE, conta enormemente. Ecco come appare con numeri reali dai nostri dati:
| Modello | Architettura | Parametri totali | Parametri attivi | Dimensione Q4_K_M |
|---|---|---|---|---|
| Qwen3.5-9B | Denso | 9,65B | 9,65B | 5,29 GB |
| Qwen3.5-35B-A3B | MoE (256 expert) | 35,95B | ~3B | 18,49 GB |
| DeepSeek V3.1 | MoE (256 expert) | 684,53B | ~37B | 377,56 GB |
La nostra scoperta: Quando abbiamo costruito le pagine di deploy di Prositronic, i modelli MoE hanno richiesto calcoli di VRAM e avvisi completamente diversi. Un modello con 3B parametri attivi potrebbe suggerire che giri su un Raspberry Pi — finché non ti rendi conto che tutti i 36 miliardi di pesi devono stare in memoria. Abbiamo dovuto aggiungere un avviso
MOE_EXPERT_CPU_OFFLOADdedicato a ogni pagina di deploy MoE.
La fascia verde nella barra MoE è rivelatrice. Se potessi caricare solo i 3B di parametri attivi, ti servirebbero circa 1,6 GB. Invece ne servono 18,49 GB perché tutti i 256 expert — 35,95 miliardi di parametri — devono essere residenti affinché il router possa selezionare tra di essi.
Per i modelli MoE più grandi, le configurazioni multi-GPU diventano inevitabili. DeepSeek V3.1 a Q4_K_M pesa 377,56 GB. Kimi K2.5 supera i 500 GB. Nessuna singola GPU consumer si avvicina. Significa che non puoi eseguirli affatto? Non proprio — è qui che entra in gioco l’expert offloading (lo vedremo in una sezione successiva).
I tuoi modelli MoE — Un confronto per il deployment
Le configurazioni con singolo expert attivo offrono un throughput dal 50 all’80% più alto rispetto alle configurazioni con 8 expert attivi (Chitty-Venkata et al., 2025). Sei famiglie di modelli MoE sono disponibili oggi per il deployment self-hosted, con dimensioni che vanno da 36B a oltre mille miliardi di parametri totali. Ecco come si confrontano:
| Modello | Totali | Attivi | Expert (usati/totali) | Dim. Q4 | VRAM min. |
|---|---|---|---|---|---|
| Qwen3.5-35B-A3B | 35,95B | ~3B | 8+1 / 256 | 18,49 GB | 24 GB |
| Qwen3-235B-A22B | 235B | ~22B | 8 / 64 | ~130 GB | Multi-GPU |
| DeepSeek V3.1 | 684,53B | ~37B | 8+1 / 256 | 377,56 GB | Multi-GPU |
| Kimi K2.5 | 1.016B | ~32B | 8 / 384 | ~550 GB | Multi-GPU |
| Llama 4 Scout | ~109B | ~17B | 1 / 16 | ~60 GB | 2× 48 GB |
| Llama 4 Maverick | ~400B | ~17B | 1 / 128 | ~220 GB | Multi-GPU |
Routing a grana fine vs a grana grossa
Nota la divisione architetturale. DeepSeek V3.1 e Qwen3.5-35B-A3B usano 256 expert piccoli (routing a grana fine) — ogni expert è uno specialista di nicchia. Llama 4 Scout usa solo 16 expert grandi (routing a grana grossa) — ogni expert è un generalista che gestisce una gamma più ampia di token. Cosa significa per te?
I modelli a grana fine possono essere più precisi nell’allocazione del calcolo. Ma richiedono più gestione della memoria e il loro routing è più sensibile alla quantizzazione. I modelli a grana grossa sono più semplici da deployare ma meno flessibili. Llama 4 Scout attiva solo 1 expert per token (non 8), il che rende il pattern di accesso alla memoria più prevedibile ma limita la specializzazione.
Impatto della quantizzazione sui modelli MoE
FP8 raggiunge un throughput dal 25 al 30% superiore rispetto a FP16 ai batch size più elevati su GPU H100 (Chitty-Venkata et al., 2025). Ma non lasciarti tentare dalla quantizzazione estrema. I modelli MoE sono più sensibili alla quantizzazione aggressiva rispetto ai modelli densi perché i pesi del router devono mantenere alta precisione per selezionare correttamente gli expert.
Il router è il cervello di un modello MoE. Esamina ogni token e decide quali expert dovrebbero elaborarlo. Quando quantizzi un modello denso a Q2, ogni parametro degrada uniformemente. Quando quantizzi un modello MoE a Q2, il router inizia a scegliere gli expert sbagliati. Il risultato non è un declino graduale della qualità — è un crollo improvviso.
I modelli MoE all’avanguardia soffrono di una perdita di accuratezza non trascurabile con la quantizzazione estrema sotto i 4 bit; i ricercatori hanno sviluppato metodi come MiLo (Mixture of Low-rank compensators) per recuperare l’accuratezza, ma questi aggiungono complessità (Huang et al., 2025). Per il deployment pratico, la nostra raccomandazione è semplice: non scendere sotto Q4_K_M.
MXFP4: l’eccezione
C’è un’eccezione. Qwen3.5-35B-A3B offre una quantizzazione MXFP4_MOE a 20,11 GB che applica la quantizzazione MX a 4 bit specificamente ai livelli expert mantenendo i livelli di attenzione e routing a precisione più alta. Questo approccio selettivo preserva la qualità del routing comprimendo comunque la maggior parte del modello. Se il tuo hardware supporta MXFP4 (NVIDIA Blackwell e successivi), è una valida alternativa a Q4_K_M.
Quantizzazione dinamica: un approccio più intelligente
La strategia di quantizzazione dinamica di Unsloth comprime selettivamente i livelli expert MoE a bit-width inferiori mantenendo i livelli di attenzione e routing a precisione più alta. Ecco perché si vede il prefisso “UD” in molti nomi di file di quantizzazione — sta per “Unsloth Dynamic”. L’approccio sfrutta il fatto che gli expert contribuiscono in modo disuguale alla qualità del modello: gli expert condivisi e i livelli di routing sono obiettivi ad alto valore per la preservazione, mentre gli expert attivati raramente tollerano più compressione.
Strategie di expert offloading
DeepSeek V3.1 nella quantizzazione TQ1_0 gira su una singola GPU da 24 GB con MoE offloading più 96–128 GB di RAM di sistema, raggiungendo circa 1–2 token al secondo (benchmark della community, 2025). L’expert offloading è la tecnica chiave per eseguire grandi modelli MoE su hardware limitato. Conserva i pesi degli expert inattivi nella RAM di sistema o su NVMe e li carica sulla GPU su richiesta.
CPU offloading con llama.cpp
L’approccio più pratico per configurazioni a singola GPU. In llama.cpp puoi scaricare tutti i livelli expert MoE sulla CPU mantenendo i livelli di attenzione e routing sulla GPU:
llama-server \
--model Qwen3.5-35B-A3B-UD-Q4_K_M.gguf \
-ot ".ffn_.*_exps.=CPU" \
--n-gpu-layers 999 \
--ctx-size 8192 \
--jinjaIl flag -ot ".ffn_.*_exps.=CPU" dice a llama.cpp di posizionare tutti
i livelli feed-forward degli expert sulla CPU mantenendo tutto il resto sulla GPU.
È più efficace dell’uso del solo --n-gpu-layers, che
scarica interi blocchi transformer anziché dividere specificamente i livelli expert.
Multi-GPU: tensor parallelism vince
Tensor parallelism ottiene guadagni di prestazioni di 2×+ passando da 1 a 4 GPU su H100, superando sia pipeline parallelism che expert parallelism (Chitty-Venkata et al., 2025). Se hai più GPU connesse via NVLink, tensor parallelism (TP) divide ogni livello tra le GPU. Expert parallelism (EP) assegna expert diversi a GPU diverse. TP vince perché la larghezza di banda NVLink è abbastanza alta da rendere efficiente la divisione dei livelli, mentre EP soffre dell’overhead di bilanciamento del carico — alcuni expert ricevono più traffico di altri.
Speculative decoding nasconde la latenza dell’offloading
Una tecnica recente chiamata SpecMoEOff combina speculative decoding con expert offloading, ottenendo un miglioramento del throughput di decodifica fino a 2,5× generando token di bozza mentre i pesi degli expert vengono trasferiti dalla RAM alla GPU. È ancora sperimentale ma indica un futuro in cui anche modelli MoE da mille miliardi di parametri girano su hardware da workstation.
Caratteristiche prestazionali — Cosa aspettarsi
La latenza inter-token varia di quasi il 100% tra i migliori e i peggiori modelli MoE in termini di prestazioni (Chitty-Venkata et al., 2025). I modelli densi hanno una latenza per token prevedibile perché ogni token segue lo stesso percorso di calcolo. I modelli MoE no — le decisioni di routing creano varianza. Se la tua applicazione richiede tempi di risposta costanti, questo conta.
Picchi di latenza da expert “freddi”
Quando un token viene instradato verso un expert usato raramente, e i pesi di quell’expert sono stati espulsi dalla cache GPU (o non sono mai stati caricati in una configurazione con offloading), si verifica un picco di latenza. La GPU si blocca in attesa che i pesi dell’expert arrivino dalla RAM. Questi picchi sono imprevedibili — dipendono dal contenuto del prompt e da quali expert vengono attivati.
Il throughput varia in base al prompt
Alcuni prompt colpiscono ripetutamente lo stesso piccolo insieme di expert. Altri distribuiscono il carico su molti expert. Questo rende il throughput MoE fondamentalmente meno prevedibile di quello dei modelli densi. Le sequenze più corte (128 token) raggiungono un throughput fino al 30% superiore rispetto alle sequenze da 2048 token nei modelli MoE (Chitty-Venkata et al., 2025).
Anche il batching è meno efficiente. In un modello denso, ogni token nel batch segue lo stesso percorso di calcolo. In un modello MoE, token diversi nello stesso batch vengono instradati a expert diversi, creando pattern di accesso alla memoria che le GPU gestiscono meno efficientemente.
Quando il denso vince
Confronta tutto questo con Qwen3.5-9B. È denso. Ogni token segue lo stesso percorso di calcolo. La latenza è prevedibile. Il throughput è costante. Non ci sono picchi da expert freddi. Nessun overhead di routing. Non eguaglierà Qwen3.5-35B-A3B nei benchmark, ma per applicazioni sensibili alla latenza — chat in tempo reale, assistenti di codifica interattivi, interfacce vocali — quella prevedibilità può contare più della capacità grezza. Puoi deployare e confrontare entrambi su Prositronic usando il nostro verificatore di compatibilità hardware.
Domande frequenti
Perché il mio modello MoE richiede così tanta VRAM se solo pochi expert sono attivi?
Tutti i pesi degli expert devono risiedere in memoria per il routing istantaneo. Qwen3.5-35B-A3B carica 35,95 miliardi di parametri ma ne attiva circa 3 miliardi per token. Il router deve poter selezionare qualsiasi expert in qualsiasi momento, quindi ogni expert resta caricato anche se la maggior parte resta inattiva in ogni singolo forward pass.
Posso eseguire DeepSeek V3 su una singola GPU?
Sì, con l’expert offloading. La quantizzazione TQ1_0 entra su una singola GPU da 24 GB con 96–128 GB di RAM di sistema, ma aspettati circa 1–2 token al secondo (benchmark della community, 2025). Per velocità utilizzabili ti serviranno almeno due GPU da 48 GB o quattro GPU da 24 GB con la quantizzazione Q4_K_M e tensor parallelism.
Qual è la quantizzazione minima che dovrei usare per i modelli MoE?
Q4_K_M. Sotto questa soglia, il degrado dei pesi del router causa la selezione errata degli expert, riducendo la qualità dell’output in modo più marcato rispetto alla quantizzazione equivalente sui modelli densi. I modelli MoE soffrono di una perdita di accuratezza non trascurabile con la quantizzazione estrema sotto i 4 bit (Huang et al., 2025).
Un modello MoE è sempre migliore di un modello denso con dimensione attiva simile?
Non per le applicazioni sensibili alla latenza. Qwen3.5-9B (denso) offre una latenza per token prevedibile senza overhead di routing. Qwen3.5-35B-A3B (MoE) ottiene punteggi più alti nei benchmark ma ha latenza variabile a causa del routing degli expert. Scegli il denso quando hai bisogno di tempi di risposta costanti; scegli MoE quando ti serve la massima capacità per euro di calcolo.
Qual è la differenza tra MoE a grana fine e a grana grossa?
DeepSeek V3 e Qwen3.5-35B-A3B usano 256 expert piccoli (grana fine). Llama 4 Scout usa 16 expert più grandi (grana grossa). Il routing a grana fine consente una specializzazione più precisa ma richiede più gestione della memoria. I modelli a grana grossa sono più semplici da deployare ma meno flessibili nell’allocazione del calcolo.
Prossimi passi
Ecco cosa portarsi a casa:
- MoE ≠ meno VRAM. Tutti i pesi degli expert devono essere caricati indipendentemente da quanti sono attivi per token.
- Non scendere sotto Q4_K_M per i modelli MoE. La qualità del router degrada bruscamente sotto la quantizzazione a 4 bit.
- L’expert offloading è essenziale per le configurazioni a singola GPU. Usa
-ot ".ffn_.*_exps.=CPU"in llama.cpp. - I modelli densi vincono sulla prevedibilità della latenza. Scegli in base alla tolleranza della tua applicazione alla varianza.
- Tensor parallelism batte expert parallelism per i deployment multi-GPU, specialmente con NVLink.
Deploya sia Qwen3.5-9B che Qwen3.5-35B-A3B su Prositronic per vedere le differenze in prima persona. Inizia dalla pagina di deploy di Qwen3.5-9B e dalla pagina di deploy di Qwen3.5-35B-A3B, poi controlla la pagina di compatibilità hardware per trovare la GPU giusta per il tuo carico di lavoro.