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

Deze studie onthult dat voor Mixture-of-Experts-talenmodellen de optimale sparsiteit voor redeneertaken niet alleen wordt bepaald door het totale aantal parameters, maar door een combinatie van actieve FLOPs en het aantal tokens per parameter, waarbij redeneren baat heeft bij een optimale verhouding in plaats van maximale parametergrootte.

De kern

Stel je voor dat je een gigantisch team van experts bouwt om een heel slimme robot te maken. Deze robot moet twee dingen kunnen: feiten onthouden (zoals hoofdsteden of historische data) en redeneren (zoals wiskundeproblemen oplossen of code schrijven).

In de wereld van kunstmatige intelligentie (AI) gebruiken we vaak een architectuur die MoE (Mixture of Experts) heet. Dit werkt als een groot kantoor met duizenden specialisten. Maar omdat het te duur en te traag is om alle specialisten tegelijk te laten werken, kiezen we er voor elke vraag slechts een paar uit. Dit heet sparsiteit (of 'verspreiding'): hoe minder experts je per vraag inschakelt, hoe 'spijker' het systeem is.

De onderzoekers van dit paper (uit ICLR 2026) hebben een groot experiment gedaan om te ontdekken: Hoeveel experts moeten we eigenlijk inschakelen om de slimste robot te krijgen?

Hier is wat ze hebben ontdekt, vertaald naar alledaagse taal:

1. Het Grote Misverstand: "Meer is altijd beter"

Vroeger dachten mensen: "Als ik mijn robot meer 'hersencellen' (parameters) geef, wordt hij automatisch slimmer."

• Voor het onthouden van feiten: Dit klopt. Als je een robot meer experts geeft (zelfs als ze maar zelden werken), onthoudt hij meer feiten. Het is alsof je een bibliotheek uitbreidt met meer boeken; hoe meer boeken, hoe meer je kunt opzoeken.
• Voor het redeneren: Hier gaat het mis. De onderzoekers ontdekten dat als je te veel experts toevoegt zonder de hoeveelheid 'werk' (rekenkracht) per expert te verhogen, de robot op redeneertaken juist dommer wordt. Het is alsof je een team van 1000 ingenieurs hebt, maar ze moeten allemaal samenwerken aan één klein probleem. Ze gaan elkaar in de weg zitten, communiceren slecht en raken in de war.

2. De Twee Regels voor Slimme Robots

De paper introduceert twee simpele regels om de perfecte balans te vinden:

Regel A: De "Actieve Werkkracht" (Active FLOPs)

Stel je voor dat je een groepje experts hebt.

• Scenario 1: Je hebt 100 experts, maar je laat er maar 2 werken.
• Scenario 2: Je hebt 20 experts, en je laat er 10 werken.
  Zelfs als beide scenario's evenveel tijd en geld kosten om te trainen, wint Scenario 2.
  De les: Het is belangrijker dat de experts die echt aan het werk zijn (de actieve experts) goed worden ingezet, dan dat je een enorme berg experts hebt die zelden iets doen. Voor redeneren heb je een grotere "actieve werkkracht" nodig.

Regel B: De "Lesuur-per-Expert" (Tokens per Parameter)

Dit gaat over hoeveel informatie elke expert krijgt om te leren.

• Feiten onthouden: Je wilt dat elke expert veel boeken leest. Je hebt dus veel experts nodig die elk een klein beetje informatie krijgen. Dit is "parameter-hongerig".
• Redeneren: Je wilt dat elke expert veel oefent. Als je te veel experts hebt voor de hoeveelheid trainingstijd, krijgt elke expert te weinig oefenmateriaal. Ze worden dan "ondervoed".
  De les: Voor redeneren is er een "gouden middenweg". Je hebt ongeveer 20 woorden (tokens) per expert nodig. Als je meer experts toevoegt zonder meer tekst te geven, worden de experts te hongerig en leren ze niet goed redeneren.

3. De "Nabootsing" (Post-Training) Lost het Niet Op

Je zou denken: "Oké, als de robot tijdens het leren (pre-training) verkeerd is ingesteld, kunnen we hem later niet gewoon bijleren met speciale technieken (zoals Reinforcement Learning of GRPO)?"
Het antwoord is nee.
Het is alsof je een student hebt die tijdens zijn schooltijd (pre-training) verkeerde methoden heeft geleerd. Je kunt hem later wel extra huiswerk geven of een coach aanstellen (post-training), maar als de basisstructuur van zijn denken (de sparsiteit) niet klopt, blijft hij vastlopen bij moeilijke problemen. De fout zit in de architectuur, niet in de motivatie.

4. De Conclusie: Het is een Balansoefening

De onderzoekers zeggen dat we de oude regels moeten herschrijven:

• Wil je een feitenmachine? Maak je systeem zo verspreid (spars) mogelijk met heel veel experts.
• Wil je een redeneermachine? Zorg dan dat je niet te verspreid bent. Houd de experts dichterbij elkaar (minder sparsiteit) en zorg dat ze genoeg oefenmateriaal krijgen.

Kort samengevat in een metafoor:
Stel je voor dat je een orkest dirigeert.

• Voor het onthouden van muziekstukken (feiten), wil je een enorm orkest met honderden muzikanten, maar je speelt maar een paar noten tegelijk. Hoe meer muzikanten, hoe meer repertoire je hebt.
• Voor het improviseren en componeren (redeneren), wil je een kleinere, hechte groep muzikanten die intensief samenwerkt. Als je te veel muzikanten toevoegt zonder meer tijd te geven om samen te repeteren, ontstaat er chaos en klinkt het niet goed.

De kunst is dus niet om zo groot mogelijk te zijn, maar om de juiste verhouding te vinden tussen het aantal experts en hoeveel werk ze per seconde doen.

Technische samenvatting

Probleemstelling

De evolutie van Large Language Models (LLM) wordt momenteel gedreven door empirische schaalwetten die trainingverlies koppelen aan modelgrootte, datasetgrootte en computebudget. Hoewel deze wetten goed werken voor dichte (dense) Transformers, introduceren Mixture-of-Experts (MoE)-modellen een nieuwe dimensie: sparsiteit.
Bestaande schaalwetten gaan vaak uit van een lineaire relatie waarbij meer parameters altijd leiden tot betere prestaties. Echter, MoE-modellen (zoals Gemini, DeepSeek-V3, Qwen) routingen tokens door een subset van experts, waardoor ze een hoge capaciteit hebben bij een vast computebudget.
Het centrale probleem dat dit paper adresseert, is dat de optimale sparsiteit voor MoE-modellen niet eenduidig is. Bestaande aannames suggereren dat hogere sparsiteit (meer experts, minder actieve parameters per token) altijd gunstig is voor schaalbaarheid. Dit paper onderzoekt of dit geldt voor zowel memorisatie (feitenkennis) als redenering (wiskunde, code), en of er een fundamenteel verschil bestaat in hoe deze vaardigheden schalen met architecturale hyperparameters.

Methodologie

De auteurs hebben een uitgebreide empirische studie uitgevoerd met de volgende opzet:

1. Architectuur: Ze gebruikten een Mixtral-achtige architectuur (Transformer met RMSNorm, SwiGLU, en rotary positional embeddings). De feed-forward lagen zijn vervangen door MoE-lagen met dropless token-choice top-k routing.
2. Experimentele Variatie: Ze trainden families van MoE-modellen met gecontroleerde variaties in:
   • Modelbreedte ($d$): 512, 1024, 2048.
   • Aantal experts per laag ($E$): 8 tot 256.
   • Top-k routing: 2, 4, 8, 16 experts per token.
   • Computebudget: Alle experimenten werden uitgevoerd onder een vast computebudget (IsoFLOP), waarbij het totale aantal tokens tijdens training constant werd gehouden (125 miljard tokens).
3. Evalueringsbenchmarks:
   • Memorisatie: TriviaQA (vragen over feiten) en HellaSwag (common sense).
   • Redenering: GSM8K en GSM-Plus (wiskundige redenering).
   • Code: HumanEval en MBPP (codegeneratie).
4. Post-training en Test-time Compute (TTC): Om te controleren of de gevonden trends specifiek zijn voor de pre-training fase, werden er experimenten uitgevoerd met:
   • GRPO (Group Relative Policy Optimization): Een RL-post-training methode.
   • Test-time Compute: Self-consistency decoding (meerdere samples en majority voting) zonder model-update.
5. Analyse: De auteurs ontkoppelden het pre-training verlies van downstream takenverlies en nauwkeurigheid. Ze introduceerden twee kritieke metrieken:
   • Active FLOPs: Het aantal berekeningen dat daadwerkelijk wordt uitgevoerd per token.
   • Total Tokens per Parameter (TPP): De verhouding tussen trainingsdata en het totale aantal parameters.

Belangrijkste Bijdragen en Resultaten

1. Het "Inverse-U" Effect op Redenering

In tegenstelling tot memorisatie-taken, vertonen redeningstaken (wiskunde, code) een niet-monotoon gedrag:

• Memorisatie: Prestaties verbeteren monotoon naarmate het totale aantal parameters toeneemt (hogere sparsiteit is beter).
• Redenering: Er is een omgekeerde U-vormige relatie. Als het totale aantal parameters te hoog wordt (en dus de sparsiteit te hoog is) bij een vast computebudget, verslechtert de prestatie op redeningstaken, zelfs als het pre-training verlies daalt.
• Conclusie: Voor redenering is er een optimale sparsiteit. Te veel experts leiden tot "data-honger" per expert; elke expert krijgt te weinig data om complexe patronen te leren.

2. De Rol van Active FLOPs

Een cruciale bevinding is dat training loss alleen niet voorspellend is voor redeneringsprestaties.

• Twee modellen met hetzelfde training verlies kunnen zeer verschillende redeneringsnauwkeurigheid hebben.
• Modellen met een groter aantal actieve FLOPs (d.w.z. een hoger $k$ in top-k routing) presteren consistent beter op redeningstaken, zelfs bij identiek training verlies.
• Dit impliceert dat de capaciteit om te redeneren direct gekoppeld is aan de hoeveelheid compute die tijdens inferentie en training per token wordt verbruikt, niet alleen aan de totale modelgrootte.

3. Total Tokens per Parameter (TPP) en Data-Honger

De auteurs bevestigen en verfijnen het Chinchilla-scaling concept:

• Memorisatie: Is "parameter-hongerig". Het profiteert van een lage TPP (veel parameters, relatief minder data per parameter).
• Redenering: Is "data-hongerig". Prestaties pieken rond een TPP van ongeveer 20. Als de TPP te laag is (te veel parameters voor de hoeveelheid data), daalt de redeneringsnauwkeurigheid drastisch.
• Dit verklaart waarom extreem sparsere modellen (veel experts) falen op redeningstaken: de data wordt te versnipperd over te veel experts.

4. Robuustheid tegen Post-training en TTC

De auteurs onderzochten of geavanceerde technieken de negatieve effecten van suboptimale sparsiteit konden herstellen:

• GRPO (RL): Verbeterde de absolute prestaties, maar elimineerde niet de trend dat sparsere modellen slechter presteren op redeningstaken bij hoge parameteraantallen.
• Test-time Compute (Self-Consistency): Verbeterde ook de prestaties, maar de onderliggende degradatie door overmatige sparsiteit bleef bestaan.
• Conclusie: De optimale architectuur moet tijdens pre-training worden vastgesteld. Post-training kan de schade van een verkeerde sparsiteit niet volledig herstellen.

Significantie en Implicaties

Dit paper biedt een fundamentele correctie op de huidige schaalwetten voor LLMs:

1. Herdefinitie van Compute-Optimaliteit: De klassieke visie dat "meer parameters = beter" is onvolledig voor MoE-modellen. Voor redeningstaken moet de optimalisatie een balans vinden tussen:
   • Active FLOPs: Voldoende compute per token voor complexe redenering.
   • TPP: Voldoende data per parameter om overfitting op sub-taken te voorkomen.
2. Architecturale Richting: Voor modellen die gericht zijn op redenering (wiskunde, code, logica) moeten ontwikkelaars voorzichtig zijn met het verhogen van het aantal experts. In hoge computeregimes kunnen dichtere configuraties (minder experts, hogere $k$) beter presteren dan extreem sparsere configuraties.
3. Praktische Toepassing: Het paper biedt een blauwdruk voor het plannen van MoE-training. Het suggereert dat voor redeningstaken een TPP van ~20 en een zorgvuldige afweging van top-k routing essentieel zijn, en dat het blindelings vergroten van het model (meer experts) zonder extra data of compute per token contraproductief kan zijn.

Samenvattend stelt het paper dat de "optimale sparsiteit" geen universele constante is, maar een dynamische variabele die afhankelijk is van de taak (memorisatie vs. redenering) en de verhouding tussen beschikbare data en het aantal actieve parameters.