MoE: l'idea di attivare solo gli esperti che servono

Negli articoli scorsi abbiamo parlato di DeepSeek V4-Pro (1,6T totali, 49B attivi) e di Qwen3.6-27B, un dense da 27B che ha tenuto testa a un MoE da 397B della generazione precedente. Numeri che a prima vista sembrano scritti in due lingue diverse: cosa vuol dire che un modello ha 1600 miliardi di parametri ma ne usa solo 49? Dove finiscono gli altri 1551? E perché un dense da 27B può battere un MoE quindici volte più grande?

Sotto questi numeri c'è un'idea sola, vecchia di 35 anni, tornata centrale: Mixture of Experts (MoE). L'idea di non far parlare tutto il modello per ogni token, ma solo la parte che serve.

Questo articolo è il manuale di sopravvivenza per leggere quei numeri senza perdersi.

Il numero ingannatore

"DeepSeek V4-Pro: 1,6 trilioni di parametri." Suona mostruoso. È mostruoso. Ma per generare il prossimo token, il modello ne usa 49 miliardi. Gli altri 1551 miliardi, in quell'istante, dormono.

Non è un trucco contabile per gonfiare i comunicati stampa. È un'architettura che spacchetta il modello in tanti "specialisti", e per ogni token in input decide quali far lavorare. Il rapporto fra parametri totali e parametri attivi — total/active — è il KPI che descrive quanto un modello è "sparso". DeepSeek V4-Pro sta a circa 33×. Il suo predecessore V3 (671B/37B) era a 18×. Mixtral 8x7B sta a 3,6×. Qwen3-30B-A3B sta a 10×. Più alto il rapporto, più aggressiva la sparsità.

Da qui in poi, ogni volta che leggi un annuncio di un nuovo modello, prima di tutto cerca quel rapporto.

L'idea base: il consulto medico

Quando hai un problema specifico non chiami in sala riunioni tutti i medici dell'ospedale. C'è un medico di base che decide se serve l'ortopedico o l'otorino. Se serve l'otorino, l'ortopedico resta a casa.

MoE è esattamente questo. Per ogni token, una piccola rete chiamata router (o gating network) decide a quali "specialisti" mandare il token. Gli altri non vengono interrogati e quindi non consumano FLOPs. È efficienza calcolata: paghi l'aritmetica solo per la frazione di modello che ha qualcosa di utile da dire.

L'idea non è nata con ChatGPT. Ha 35 anni. "Adaptive Mixture of Local Experts" — Jacobs, Jordan, Nowlan, Hinton — è un paper del 1991. Per trent'anni è rimasta in soffitta perché non serviva: i modelli erano abbastanza piccoli da poter essere "densi" senza problemi. È tornata utile quando il puro brute-force dello scaling ha cominciato a costare troppo.

Il momento accademico moderno è il 2017: Shazeer e altri (con Hinton e Dean) pubblicano Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer a ICLR. Scalano un modello a 137 miliardi di parametri inserendo layer MoE fra LSTM, e introducono il Noisy Top-k Gating, più o meno quello che usiamo ancora oggi.

Come funziona, senza formule pesanti

Dentro un transformer, ogni layer ha due blocchi principali: l'attention e l'FFN (feed-forward network). In un modello dense, l'FFN è uno solo. In un modello MoE, l'FFN viene replicato N volte — 8, 16, 64, 128, 256 copie — e ogni copia si chiama expert.

Davanti agli expert c'è il router: una rete lineare piccolissima che, dato l'embedding del token, sputa fuori un punteggio per ogni expert. Prendi i top-k punteggi (di solito k=1 o k=2; DeepSeek V3 spinge fino a k=8) e mandi il token solo a quegli expert. L'output finale è la somma pesata dei loro output.

In una riga, l'idea è:

y = somma su i scelti di [ peso_router_i * Expert_i(x) ]

Niente di mistico. La parte interessante è che il router è addestrato insieme al resto: impara da solo quali expert "specializzare" su cosa. Non glielo dici tu — emerge dal training.

Una nota importante: gli expert non sono "l'expert di matematica" o "l'expert di codice Python" come spesso si racconta nelle slide. La specializzazione è molto più astratta e spesso illeggibile a occhio umano. Lavorano su pattern statistici, non su categorie umane.

Active vs Total: il KPI nuovo

Per un modello dense la domanda "quanto è grande?" ha una risposta sola. Per un MoE ne ha due, e contano entrambe.

Total params: quanto pesa su disco e quanto VRAM serve per caricarlo.
Active params: quanti parametri fanno FLOPs per ogni token generato.

Il costo computazionale di un MoE per token è all'incirca quello di un dense con i suoi parametri attivi. Un modello con 671B totali / 37B attivi costa, in compute per token, come un dense da 37B. La memoria però la paghi tutta — perché devi tenere tutti gli expert pronti, non sai in anticipo a quale toccherà.

Da qui la regola:

Active per il compute, total per la memoria.

Tienila a mente: la maggior parte dei malintesi sui MoE nasce da chi confonde i due piani.

Il momento Mixtral

Per due anni MoE è stato un giocattolo da paper. Switch Transformer di Google (2021) aveva spinto fino a 1,6T parametri con 2048 experts e top-1 routing, ma era roba interna, niente pesi pubblici. GShard scalava transformer MoE oltre 600B. Bei numeri, poco effetto pratico sulla community.

Poi, dicembre 2023. Mistral droppa un torrent magnet su Twitter senza preavviso. Dentro c'è Mixtral 8x7B: 46,7B parametri totali, 12,9B attivi per token, 8 experts per layer con top-2 routing.

I numeri operativi:

Inferenza ~6× più veloce di Llama 2 70B, batte o pareggia su quasi tutti i benchmark.
MT-Bench Instruct 8,3, paragonabile a GPT-3,5 dell'epoca.
Pesi aperti, licenza permissiva.

Una nota sul naming: "8x7B" non significa 56B. Attention ed embedding sono condivisi fra tutti gli expert, quindi i parametri totali reali sono 46,7B. È marketing, non aritmetica.

Da quel momento "dense vs sparse" smette di essere una domanda accademica.

Le innovazioni DeepSeek

Mixtral era 2023. La generazione successiva di MoE arriva dalla Cina, con DeepSeek che a gennaio 2024 pubblica il paper DeepSeekMoE introducendo due idee che ormai sono standard de facto.

Fine-grained experts. Invece di pochi expert grandi (8 da 7B come Mixtral), tanti expert piccoli ottenuti splittando l'intermediate dimension dell'FFN. Più expert significano più combinazioni possibili — quando ne attivi 8 su 256 hai una varietà combinatoria che con 2 su 8 non puoi nemmeno avvicinare. Più specializzazione, meno ridondanza.

Shared experts. Uno o pochi expert sempre attivi per ogni token. L'idea: c'è del "common knowledge" che serve sempre — grammatica, struttura sintattica, embedding di base. Metterlo in un expert dedicato libera gli altri dal dover replicare quella conoscenza.

DeepSeek V3 (dicembre 2024) applica il tutto: 671B totali, 37B attivi, 256 routed experts + 1 shared, top-8 routing. Trainato su 14,8T token in 2,788 milioni di H800 GPU-hours. A 2$/GPU-h fa circa 5,576 milioni di dollari di compute pretraining. È il numero che ha fatto il giro del mondo perché stimato 20× sotto i costi presunti dei modelli frontier dell'epoca. Va detto: è il costo del training run finale, non di tutta la R&D dell'azienda — Stratechery e Interconnects su questo sono stati onesti. V4-Pro (2026) ha portato la stessa famiglia architetturale a 1,6T totali e 49B attivi, spingendo ulteriormente la sparsità.

C'è una terza innovazione DeepSeek che merita un capitolo: auxiliary-loss-free load balancing (paper di agosto 2024). Risolve un problema che vediamo subito.

Il problema del routing collapse

Lasciato libero, il router fa una cosa stupida: trova due o tre expert "preferiti" e ci manda tutto. Gli altri diventano dead weight, mai aggiornati, mai utili. Si chiama routing collapse ed è il fallimento più comune nel training MoE.

La soluzione classica è una load balancing loss: una loss ausiliaria che penalizza distribuzioni squilibrate. Spinge il router a usare gli expert in modo uniforme. Funziona, ma introduce un'interferenza con la loss principale — stai chiedendo al modello due cose contemporaneamente, e a volte entrano in conflitto.

L'idea DeepSeek auxiliary-loss-free è semplice: niente loss ausiliaria, ma un bias dinamico sul logit di ogni expert. Se un expert è sotto-utilizzato, il suo bias sale; se è sovra-utilizzato, scende. Il routing si bilancia da solo senza inquinare il gradiente del task principale. Più stabile, meno tuning.

Studi recenti mostrano anche che il collasso non è uniforme nei layer: tipicamente early e late layer collassano peggio dei middle layer. Pattern utile da conoscere se mai dovrai debuggare un training MoE.

Il paradosso della VRAM

Qui arriviamo al punto dolente che spesso si glissa nei comunicati.

Mixtral usa 12,9B parametri per token. Suona come "posso farlo girare su una GPU che regge un dense 13B". Sbagliato. Per fare lo switching veloce fra expert devi tenerli tutti in memoria. Mixtral richiede VRAM per ~46,7B totali — più o meno come un dense da 47B. In FP16 sono ~94 GB, due A100 80GB o equivalenti.

Il vantaggio MoE è sul compute, non sulla memoria. Su throughput in datacenter, dove il bottleneck sono i FLOPs/secondo, è enorme. Su single-machine consumer dove il bottleneck è la VRAM, devi tenerlo presente.

L'eccezione interessante è la quantizzazione. Qwen3-30B-A3B (30B totali, 3B attivi) in Q4_K_M occupa circa 17 GB di VRAM. Sta su una RTX 3080 16GB con un po' di offload, ci sta comodo su una 4090 24GB. E in inferenza si comporta come un dense da 3B in compute — cioè vola. È il punto sweet attuale per l'AI sovrana su hardware consumer.

Quando MoE conviene davvero

Riassumo dove l'architettura paga:

Pretraining a budget compute fisso. A parità di FLOPs, un MoE arriva a una loss più bassa di un dense equivalente. Switch Transformer riportava 4× speedup vs T5-XXL.
Throughput inference su server con VRAM abbondante. Il MoE serve più richieste al secondo a parità di GPU.
Quantizzato su consumer GPU, se il total entra in VRAM. Vedi Qwen3-30B-A3B.
Unified memory (Apple Silicon, Strix Halo): il bottleneck è la memory bandwidth, e attivare meno parametri per token significa muovere meno dati. Qui i MoE volano davvero.

Dove paga male:

Single-machine con poca VRAM. Non riduci il footprint memoria.
Fine-tuning single-task con dataset piccolo. I MoE soffrono overfitting in questo regime; brillano in instruction tuning multi-task.
Pipeline RL stile RLVR. Il gradiente attraversa solo gli expert attivati, in modo sparso e stocastico — e questo produce dinamiche di training instabili. È una delle ragioni per cui modelli dense come Qwen3.6-27B sono tornati competitivi.

Il panorama oggi

Tre numeri per fissare la mappa:

Modello	Total	Active	Experts	Top-k
Mixtral 8x7B (2023)	46,7B	12,9B	8	2
DeepSeek V3 (2024)	671B	37B	256 + 1 shared	8
Qwen3-235B-A22B (2025)	235B	22B	128	8
Qwen3-30B-A3B (2025)	30B	3B	128	8
Llama 4 Maverick (2025)	400B	17B	128 + 1 shared	1
DeepSeek V4-Pro (2026)	1,6T	49B	n.d.	n.d.

Sui modelli OpenAI un disclaimer doveroso: GPT-4 (2023) fu il primo grande caso sospettato di essere MoE, sulla base di leak SemiAnalysis e dichiarazioni di George Hotz (~1,76T totali, 8 o 16 expert, top-2). L'architettura non è mai stata confermata da OpenAI, e su GPT-5 e successivi (compresi GPT-5.3 e 5.4 usciti tra fine 2025 e inizio 2026) non c'è alcuna informazione pubblica sull'architettura interna. Quindi: storicamente GPT-4 è il primo "frontier MoE" sospettato, ma rumored resta rumored. Per il resto, la tendenza è chiara: MoE è lo standard frontier.

Cosa guardare ora

Se hai letto fin qui e vuoi portarti via una cosa sola, è la lente: rapporto active/total.

DeepSeek V4-Pro → 33× (sparsità estrema)
Llama 4 Maverick → 23,5× (molto aggressiva)
DeepSeek V3 → 18× (aggressiva)
Qwen3-235B-A22B → 10,7× (medio-aggressiva)
Mixtral 8x7B → 3,6× (sparsità moderata)
Qwen3.6-27B → 1× (dense, scelta opposta)

Quando esce un modello nuovo, prima di tutto guarda quel numero. Ti dice in che parte del trade-off l'azienda ha deciso di stare. Total alto = scommessa sulla quantità di conoscenza memorizzata. Active basso = scommessa sull'efficienza compute. Rapporto alto = sparsità aggressiva che richiede VRAM ma minimizza FLOPs/token.

Non c'è una scelta giusta. C'è una scelta giusta per il tuo carico: datacenter con tanti utenti? Sparsità aggressiva. Single-machine consumer? Dense piccolo o MoE quantizzato dove il total ti entra in VRAM. Pipeline RLVR? Dense, almeno per ora.

L'era in cui "più parametri totali = più intelligente" finiva in una riga di marketing è chiusa. Da qui in poi servono due numeri, sempre.

Per approfondire: