Optimal Sparsity of Mixture-of-Experts Language Models for Reasoning Tasks

Each language version is independently generated for its own context, not a direct translation.

Immagina di dover costruire un'orchestra gigante per suonare musica complessa. Fino a poco tempo fa, la regola d'oro era: "Più musicisti hai, meglio suona". Se volevi un suono migliore, aggiungevi semplicemente più violini, più trombe e più percussioni.

Questo è quello che è successo con i modelli di intelligenza artificiale (LLM): più parametri (musici) avevi, più intelligente sembrava il modello.

Ma questo studio, pubblicato alla conferenza ICLR 2026, ci dice che la storia è un po' più complicata, specialmente quando si tratta di Mixture-of-Experts (MoE).

Ecco cosa hanno scoperto, spiegato in modo semplice:

1. L'Orchestra a "Esperti" (Cosa sono gli MoE)

Invece di far suonare tutti i musicisti per ogni nota, i modelli MoE usano un "direttore d'orchestra" intelligente. Per ogni frase che il modello deve scrivere, il direttore sceglie solo un piccolo gruppo di musicisti (gli "esperti") per suonare quella specifica parte.

Modello Denso: Tutti i musicisti suonano sempre.
Modello MoE: Solo 2 o 4 musicisti su un totale di 100 suonano per ogni nota. Questo fa risparmiare energia (calcolo) e permette di avere un'orchestra enorme senza spendere una fortuna.

2. Il Problema: "Memoria" vs "Ragionamento"

Gli autori hanno scoperto che questa scelta di quanti musicisti far suonare (la "sparsità") ha effetti diversi su due tipi di compiti:

La Memoria (Imparare fatti): Se vuoi che l'orchestra ricordi a memoria le date della storia, i nomi dei presidenti o le ricette, più musicisti ci sono in totale (anche se pochi suonano alla volta), meglio è. È come avere un archivio infinito. Più esperti hai nel tuo gruppo, più cose riesci a memorizzare.
Il Ragionamento (Risolvere problemi di matematica o logica): Qui la storia cambia. Se chiedi all'orchestra di comporre una sinfonia nuova o risolvere un enigma complesso, avere troppi musicisti in totale ma farne suonare troppo pochi alla volta è un disastro.
- L'analogia: Immagina di avere 100 chef in una cucina (il modello). Se per ogni piatto ne scegli solo 2 (sparsità alta), quei 2 chef sono sovraccarichi e non hanno abbastanza ingredienti (dati) per imparare a cucinare bene piatti complessi. Se invece ne scegli 10 o 20 (sparsità bassa, modello più "denso"), hanno più risorse per ragionare insieme e creare qualcosa di intelligente.

3. La Scoperta Principale: Non conta solo il "Prezzo", conta chi "Suona"

Il paper rivela due regole d'oro che cambiano il modo di progettare queste intelligenze:

I FLOPs Attivi (Chi suona davvero): Due modelli possono avere lo stesso "prezzo" di addestramento e lo stesso errore sulla carta. Ma se uno fa suonare più musicisti contemporaneamente (più top-k), ragionerà meglio. È come dire: non importa quanto è grande il teatro, importa quanti musicisti stanno suonando attualmente per risolvere il problema.
Il Rapporto "Ingredienti per Chef" (TPP): Per il ragionamento, serve un equilibrio perfetto. Se hai troppi chef (parametri) e pochi ingredienti (dati di addestramento), i chef non imparano nulla. Se hai pochi chef e tantissimi ingredienti, sono felici ma non abbastanza potenti. Il punto ideale per il ragionamento matematico è circa 20 ingredienti per ogni chef.

4. L'Inganno della "Post-Produzione"

C'è un altro trucco che le aziende usano: dopo aver addestrato il modello, gli danno "pillole di rinforzo" (come il GRPO) o gli fanno pensare più a lungo prima di rispondere (calcolo al momento dell'uso).

La brutta notizia: Questi trucchi aiutano un po', ma non possono riparare un modello mal costruito. Se hai scelto la configurazione sbagliata degli esperti durante l'addestramento (troppi esperti totali, troppo pochi attivi), nessun trucco post-addestramento ti farà diventare un genio della matematica. È come dare un libro di ricette a un cuoco che non ha mai imparato a tagliare le verdure: non diventerà uno chef stellato.

In Sintesi: Cosa dobbiamo fare?

Prima si pensava che per avere un'IA intelligente bastasse renderla più grande e più economica (più sparsa).
Questo studio ci dice che per il ragionamento, la "parsimonia" eccessiva è nemica.

Se vuoi un'IA che ricordi tutto (come un'enciclopedia vivente): Rendila enorme e molto sparsa (molti esperti, pochi attivi).
Se vuoi un'IA che ragioni (come un matematico o un programmatore): Devi bilanciare le cose. Non esagerare con il numero totale di esperti, e assicurati che ne lavorino abbastanza contemporaneamente. A volte, un modello un po' più "denso" (meno sparsità) è molto più intelligente di uno super-sparso, anche se costa di più da addestrare.

È un invito a smettere di guardare solo la grandezza del modello e iniziare a guardare come lavora il modello: chi sta pensando davvero al momento giusto?

Each language version is independently generated for its own context, not a direct translation.

1. Il Problema

Le leggi di scaling empiriche hanno guidato l'evoluzione dei Large Language Models (LLM), ma i loro coefficienti cambiano quando l'architettura o la pipeline dei dati vengono modificate. I modelli Mixture-of-Experts (MoE) sono diventati lo standard per il scaling economico (es. Gemini, DeepSeek, Qwen), introducendo una nuova dimensione di sparsità che i modelli densi non considerano.

Il problema centrale affrontato dagli autori è la mancanza di comprensione su come la sparsità degli MoE influenzi due regimi di capacità distinti:

Abilità di memorizzazione (es. TriviaQA, HellaSwag).
Abilità di ragionamento (es. GSM8K, GSM-Plus, codifica).

Esiste un compromesso (trade-off) ottimale tra il numero totale di parametri, i parametri attivi (FLOPs) e la quantità di dati di addestramento per parametro (TPP - Tokens Per Parameter) che massimizzi le prestazioni, specialmente per compiti complessi di ragionamento? Inoltre, tecniche di post-training (come il Reinforcement Learning) o l'aumento del calcolo al momento del test (Test-Time Compute - TTC) possono mitigare le carenze introdotte da una sparsità subottimale?

2. Metodologia

Gli autori hanno condotto un'indagine empirica su larga scala utilizzando architetture basate su Mixtral (Transformer con strati MoE).

Setup Sperimentale:
- Architettura: 16 layer, con dimensioni nascoste ( $d$ ) variabili (512, 1024, 2048).
- Variabili Architetturali: Hanno variato sistematicamente il numero di esperti per layer ( $E \in \{8, \dots, 256\}$ ) e il numero di esperti selezionati per token ( $k \in \{2, 4, 8, 16\}$ ).
- Budget Computazionale: Gli esperimenti sono stati condotti sotto vincoli di budget computazionale fissi (IsoFLOP), variando la sparsità (rapporto tra parametri totali e attivi) mantenendo costanti i FLOPs di addestramento per token.
- Dataset: Un corpus di pre-addestramento bilanciato di 125 miliardi di token, composto da testo web, letteratura STEM, matematica e codice.
- Valutazione: Hanno misurato la perdita di pre-addestramento, la perdita sui task downstream e l'accuratezza su benchmark specifici:
  - Memorizzazione: TriviaQA, HellaSwag.
  - Ragionamento Matematico: GSM8K, GSM-Plus.
  - Codifica: HumanEval, MBPP.
- Analisi Post-Training: Hanno applicato GRPO (Group Relative Policy Optimization, una variante RL) e tecniche di Test-Time Compute (Self-Consistency) per verificare se potevano recuperare le prestazioni perse nei modelli più sparsi.

3. Contributi Chiave e Risultati

Lo studio rivela due principi fondamentali che ridefiniscono lo scaling ottimale per i modelli MoE:

A. Il Ruolo dei FLOPs Attivi (Active FLOPs)

Risultato: Modelli con la stessa perdita di addestramento ma un numero maggiore di parametri attivi (ottenuti aumentando $k$ ) ottengono un'accuratezza di ragionamento superiore.
Implicazione: La qualità del ragionamento non è determinata solo dalla perdita di pre-addestramento, ma dal numero di FLOPs attivi sia in fase di training che di inferenza. A parità di loss, un routing con $k$ più alto (più esperti attivi) supera sempre configurazioni con $k$ più basso.

B. Il Rapporto Token-Per-Parametro (TPP) e la Non-Monotonicità

Memorizzazione: Le task di memorizzazione migliorano monotonamente all'aumentare del numero totale di parametri (e quindi della sparsità), poiché sono "affamate di parametri" (parameter-hungry).
Ragionamento: Le task di ragionamento mostrano un comportamento non monotono (a forma di U invertita).
- L'accuratezza raggiunge un picco quando il rapporto TPP è circa 20.
- Se il TPP è troppo basso (troppi parametri rispetto ai dati), il modello diventa "affamato di dati" (data-starved) e le capacità di ragionamento crollano, anche se la perdita di training diminuisce.
- Se il TPP è troppo alto (pochi parametri), il modello è sottodimensionato.
Conclusione: Per il ragionamento, esiste un punto ottimale di densità. Aumentare eccessivamente la sparsità (aggiungendo molti esperti ma mantenendo fissi i token) danneggia il ragionamento perché ogni esperto riceve meno dati di addestramento.

C. Inefficacia del Post-Training e del Test-Time Compute

Gli autori hanno dimostrato che né il Reinforcement Learning (GRPO) né l'aumento del Test-Time Compute (TTC) riescono a eliminare il divario di prestazioni causato da una sparsità subottimale durante il pre-addestramento.
Anche se queste tecniche migliorano le prestazioni assolute, il trade-off fondamentale tra sparsità e ragionamento rimane invariato. Questo sottolinea che la scelta della sparsità ottimale deve avvenire durante il pre-addestramento.

D. Generalizzazione ai Task di Codifica

Gli stessi trend osservati per la matematica si applicano alla generazione di codice (HumanEval, MBPP). A budget computazionali elevati, configurazioni più dense (meno sparse) tendono a superare quelle molto sparse per il ragionamento procedurale.

4. Significato e Implicazioni

Questo lavoro offre una revisione critica delle leggi di scaling attuali per i modelli MoE:

Ridefinizione dello Scaling Ottimale: Non esiste una sparsità "migliore" universale. La sparsità ottimale dipende dal task:
- Per la memorizzazione, sparsità elevate (più esperti, meno attivi) sono vantaggiose.
- Per il ragionamento, è necessario un bilanciamento attento tra FLOPs attivi e TPP. In regimi ad alto calcolo, configurazioni più dense possono essere preferibili per preservare le capacità di ragionamento.
Critica all'approccio "Loss-Centric": Ridurre la perdita di training non garantisce un miglioramento delle capacità di ragionamento. Due modelli con la stessa loss possono avere prestazioni di ragionamento drasticamente diverse a causa della loro architettura di routing e del rapporto dati/parametri.
Guida per la Progettazione: Per costruire modelli di ragionamento efficienti sotto un budget fisso, non basta aumentare il numero totale di parametri. È cruciale ottimizzare il numero di esperti attivi ( $k$ ) e garantire che il rapporto TPP rimanga vicino al valore ottimale (circa 20) per evitare che gli esperti siano sottodimensionati rispetto ai dati disponibili.

In sintesi, il paper dimostra che la sparsità degli MoE non è un semplice knob per risparmiare calcolo, ma un fattore architetturale critico che deve essere sintonizzato specificamente per le capacità di ragionamento, distinguendosi nettamente dalle esigenze di memorizzazione.