Mixture of Experts: il modello che non si accende tutto

Mixtral 8x7B ha circa 47 miliardi di parametri. Eppure, quando genera un token, ne usa più o meno 13. Gli altri restano fermi, caricati in memoria ma spenti, come le luci delle stanze in cui non stiamo entrando. Non è un difetto: è l’idea centrale di un’architettura che oggi sta dietro buona parte dei modelli linguistici più grandi in circolazione, la Mixture of Experts.

L’intuizione è quasi banale, una volta detta ad alta voce: perché un modello dovrebbe usare tutti i suoi parametri per ogni parola? Tradurre una frase in francese, completare una funzione Python e continuare una poesia sono compiti diversi. Forse conviene avere pezzi di rete specializzati, e accendere di volta in volta solo quelli che servono.

Un condominio di specialisti

Immaginate uno studio professionale con otto consulenti: un fiscalista, un avvocato, un notaio, un ingegnere e così via. Quando arriva un cliente, non convocate tutti e otto in riunione: la segreteria ascolta il problema e lo indirizza ai due più adatti. Il cliente paga il tempo di due persone, ma lo studio nel suo complesso copre otto competenze.

Un modello Mixture of Experts funziona così. Dentro il transformer, alcuni strati feed-forward — quelli che normalmente sarebbero un unico blocco denso — vengono sostituiti da un gruppo di blocchi paralleli, gli esperti. Davanti a loro c’è un componente piccolo e cruciale, il router (o gating network): per ogni token in ingresso, il router calcola un punteggio per ciascun esperto e attiva solo i migliori, tipicamente due. L’output finale è la media pesata delle risposte degli esperti scelti.

La distinzione da tenere a mente è quella tra parametri totali e parametri attivi. I primi determinano quanta memoria serve per tenere il modello caricato; i secondi, quanto calcolo serve per ogni token. Un MoE compra capacità (parametri totali) senza pagare l’intero conto in calcolo (parametri attivi). DeepSeek-V3, per fare un esempio concreto, dichiara 671 miliardi di parametri totali ma ne attiva circa 37 per token: meno del 6%.

Per ogni token, il router assegna un punteggio a tutti gli esperti e attiva solo i due migliori. L’output è la somma pesata delle loro risposte: la maggior parte del modello resta spenta.

Il router: piccolo, decisivo, fragile

Il router è tecnicamente poca cosa — spesso una singola proiezione lineare seguita da una softmax — ma è il punto dove l’architettura può fallire. Il rischio classico si chiama collasso del routing: durante l’addestramento, un paio di esperti iniziano per caso a ricevere più token, quindi imparano di più, quindi il router li preferisce ancora di più. Il circolo vizioso lascia gli altri esperti sottoallenati e inutili: avete pagato otto consulenti e ne lavorano due.

La contromisura standard è una penalità di load balancing aggiunta alla funzione di perdita: il modello viene punito se la distribuzione dei token tra gli esperti si sbilancia troppo. È un compromesso dichiarato — si sacrifica un po’ di libertà del router per tenere in vita tutta la squadra — e la letteratura recente esplora varianti che riducono questo costo, per esempio strategie di bilanciamento senza termine ausiliario nella loss.

Un MoE compra capacità senza pagare l’intero conto in calcolo: il prezzo vero lo paga in memoria, e in complessità di addestramento.

Cosa imparano davvero gli esperti

Il nome inganna. Verrebbe da immaginare l’esperto di matematica, quello di diritto, quello di poesia. Le analisi sui modelli reali mostrano una specializzazione molto più prosaica: gli esperti tendono a dividersi il lavoro per proprietà superficiali dei token — punteggiatura, numeri, frammenti di codice, certe famiglie di parole — più che per dominio semantico. E la scelta avviene token per token, non frase per frase: nella stessa frase, parole diverse possono passare da esperti diversi.

Per tornare all’analogia dello studio professionale: non è che il cliente «pratica fiscale» vada dal fiscalista. È che ogni singola pagina della pratica viene smistata a chi tratta meglio quel tipo di pagina. Meno intuitivo, ma è ciò che l’ottimizzazione ha trovato conveniente.

Il conto da pagare: la memoria

Se i MoE fossero gratis, tutti i modelli sarebbero MoE. Il costo principale è la memoria: i parametri non attivi non fanno calcolo, ma devono comunque stare da qualche parte, pronti a essere chiamati. Un modello da centinaia di miliardi di parametri totali richiede la VRAM di un modello da centinaia di miliardi di parametri, anche se per ogni token ne «consuma» una frazione. È il motivo per cui i MoE brillano nei datacenter — dove la memoria si distribuisce su molte GPU e il risparmio di calcolo si traduce in throughput e bollette più basse — e restano scomodi sul portatile di casa.

C’è poi un costo di sistema: con gli esperti sparsi su macchine diverse, i token devono essere fisicamente spostati verso l’esperto giusto e poi riportati indietro. Questa comunicazione va orchestrata bene, altrimenti il tempo guadagnato col calcolo sparso si perde in rete.

Perché ne sentirete parlare sempre di più

La traiettoria del settore è leggibile: Mixtral ha reso popolare l’approccio nell’open source nel 2023, DeepSeek-V3 e la generazione successiva di modelli aperti lo hanno spinto a scale molto maggiori, e diversi laboratori dichiarano apertamente architetture sparse per i loro modelli di punta. La ragione è economica prima che scientifica: a parità di budget di calcolo per token, un MoE offre più capacità, e a parità di qualità costa meno per ogni risposta generata.

Per chi legge, la conseguenza pratica è imparare a leggere le schede tecniche. Quando un modello dichiara «671 miliardi di parametri», la domanda giusta è: totali o attivi? Il primo numero dice quanto è capiente, il secondo quanto costa farlo girare — e i confronti tra modelli densi e sparsi fatti solo sui parametri totali sono, semplicemente, confronti sbagliati. La prossima volta che due modelli vi sembrano incomparabili sulla carta, controllate se uno dei due, semplicemente, non si accende tutto.