🤖 machine learning

Compute-Optimal Is Not Cluster-Optimal: Systems-Aware Scaling for Sparse Mixture-of-Experts

Dit artikel introduceert MOSAIC, een systeembewust co-design framework dat aantoont dat optimale sparsiteit voor sparse Mixture-of-Experts modellen pas ontstaat wanneer de modelarchitectuur gezamenlijk met hardwarebeperkingen wordt geoptimaliseerd, in plaats van enkel door traditionele compute-optimale schaalwetten.

Oorspronkelijke auteurs: Soumajyoti Sarkar, Yuxin Tang, Sheng Zha

Gepubliceerd 2026-08-12

📖 7 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Soumajyoti Sarkar, Yuxin Tang, Sheng Zha

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je probeert de ultieme, meest krachtige robothersenen te bouwen. In de wereld van kunstmatige intelligentie is dit "brein" een enorm computerprogramma genaamd een Large Language Model (LLM). Om deze hersenen slimmer te maken, hebben wetenschappers een eenvoudige regel ontdekt: als je ze meer data voert en groter maakt, worden ze beter in het begrijpen van de wereld. Deze regel wordt een "scaling law" genoemd. Lange tijd was het recept voor het bouwen van deze hersenen verdeeld in twee aparte stappen. Eerst zou een wiskundige de perfecte grootte van het brein bepalen op basis van de beschikbare hoeveelheid rekenkracht (genaamd "compute"). Daarna zou een andere ingenieur proberen dat brein op een specifieke set computerchips te persen om het zo snel mogelijk te laten draaien.

Denk aan het plannen van een roadtrip. De eerste stap is beslissen hoe ver je wilt rijden op basis van je benzinebudget. De tweede stap is het kiezen van een auto. Maar wat als de auto die je hebt gekozen zo zwaar en lomp is dat hij benzine verbruikt in een verschrokkend tempo, waardoor je eigenlijk niet zo ver kunt rijden als je van plan was? Dat is het probleem waar dit artikel zich mee bezighoudt. Het betoogt dat je niet eerst een hersengrootte kunt kiezen en je daarna pas zorgen kunt maken over de auto. Je moet het brein en de auto samen ontwerpen, want de vorm van het brein bepaalt hoe efficiënt de auto rijdt. Als je de motor van de auto negeert, eindig je misschien met een "perfect" brein dat te zwaar is om te bewegen, waardoor je stil blijft staan bij de startlijn.

Het Probleem: Het "Perfecte" Brein Dat Niet Past

Het artikel introduceert een nieuwe manier van denken genaamd MOSAIC (Model Optimization via Systems-Aware TraIning Co-design). De auteurs, werkzaam bij Amazon AGI Foundations, merkten op dat de oude manier van werken geld liet liggen. Traditioneel zouden onderzoekers een "Compute-Optimal" model berekenen. Dit is de modelgrootte die de beste resultaten oplevert voor een vaste hoeveelheid rekenkracht, uitgaande van het scenario dat elke bit aan kracht perfect wordt gebruikt.

De auteurs ontdekten echter een verborgen valstrik. Ze richtten zich op een specifiek type AI-architectuur genaamd Mixture-of-Experts (MoE). Stel je een enorme bibliotheek voor waar, in plaats van één grote bibliothecaris die elk boek leest, duizenden kleine, gespecialiseerde experts aanwezig zijn. Wanneer er een vraag binnenkomt, stuurt een slimme router de vraag naar slechts een paar van deze experts (bijvoorbeeld 2 van de 100) om het antwoord te geven. Dit maakt het model erg snel en efficiënt, omdat het niet de hele bibliotheek hoeft te wekken voor elke vraag.

De oude wiskunde suggereerde dat om de beste resultaten te krijgen, je de bibliotheek zo groot mogelijk moest maken en zo min mogelijk experts moest wekken. Met andere woorden: het "perfecte" model zou extreem ijl (sparse) moeten zijn (voornamelijk leeg). Het model zou volgens de wiskunde de hoogste mate van ijleheid hebben die op de rand van het mogelijke ligt.

De Twist: De Automotor Doe Heeft Er Toe Doen

Hier verandert het verhaal. De auteurs realiseerden zich dat hoewel de wiskunde zegt "maak het super ijl", de fysieke realiteit van de computerchips zegt "op geen enkele manier".

Wanneer je een model hebt met duizenden kleine experts, moet de computer veel extra werk verrichten om simpelweg te beslissen welke experts wakker gemaakt moeten worden en om de informatie tussen hen door te sturen. Het is alsoals een groot kantoorgebouw hebben waar de manager de hele dag tussen de bureaus door rent om memo's te bezorgen, waardoor er heel weinig tijd overblijft voor het eigenlijke werk. Hoe ijler het model wordt, hoe meer tijd de computer verspilt aan deze "heen en weer ren"-taken (communicatiekosten) en hoe minder tijd er wordt besteed aan het eigenlijke denken (berekeningen).

Het artikel betoogt dat de oude "Compute-Optimal" wiskunde gebrekkig was omdat zij ervan uitging dat de computer 100% van zijn kracht aan het denkproces kon besteden. In werkelijkheid krijgt een super-ijl model misschien slechts 8% van de rekenkracht van de computer voor het eigenlijke denken, terwijl een iets dichter model er 15% kan krijgen.

De Oplossing: MOSAIC

Om dit op te lossen, bouwde het team MOSAIC. In plaats van te vragen: "Wat is het beste model voor een vaste hoeveelheid wiskunde?", vroegen zij: "Wat is het beste model dat we daadwerkelijk kunnen draaien op onze specifieke cluster van computers in een vaste hoeveelheid tijd?"

Ze combineerden twee zaken:

Een Scaling Law: Een voorspelling van hoe slim het model zal zijn op basis van zijn grootte en vorm.
Een Performance Model: Een simulator die voorspelt hoe snel het model daadwerkelijk zal draaien op echte hardware, rekening houdend met de kosten van het "heen en weer ren".

Toen ze MOSAIC draaiden, waren de resultaten verrassend. Het "perfecte" model was niet het model aan de uiterste rand van ijleheid. In plaats daarvan was het beste model een interne oplossing — een goed middenpad. Het was ijl genoeg om efficiënt te zijn, maar niet zo ijl dat de computer vastliep door de overhead van het beheren van al die kleine experts.

Wat Ze Vonden

Het team testte dit op echte hardware met behulp van NVIDIA B200 GPU's. Ze trainden modellen variërend van 700 miljoen tot 18 miljard actieve parameters (en tot wel 79 miljard totale parameters).

De Oude Manier: Als je simpelweg de oude wiskunde volgde, zou je een model kiezen met een ijleheid van ongeveer 0,985 (wat betekent dat 98,5% van de experts slaapt). Maar op hun specifieke cluster zou dit model zo traag zijn dat het een eeuwigheid zou duren om te trainen, en het zou in werkelijkheid minder slim zijn dan een iets dichter model.
De MOSAIC-Manier: Het systeem vond dat het ideale punt een ijleheid van ongeveer 0,96 was. Dit model was niet de "theoretische" beste, maar wel de praktische beste. Het draaide sneller, gebruikte de kracht van de computer efficiënter en behaalde een lagere foutmarge (wat betekent dat het slimmer was) dan de "theoretische" beste.

Sterker nog, ze toonden aan dat het model dat er op papier het beste uitzag (het model met de meeste "Model FLOPs"), in het echte leven juist het langzaamst was om te trainen. Het model dat won, was het model dat de balans vond tussen de wiskunde en de realiteit van de hardware.

Waarom Dit Belangrijk Is

Dit artikel suggereert dat we moeten stoppen met het behandelen van het ontwerp van AI-modellen en het ontwerp van de computers die ze draaien als twee aparte stappen. Je kunt niet zomaar een modelgrootte kiezen en hopen dat de computers het aankunnen. De vorm van het model verandert namelijk hoe de computer zich gedraagt.

De auteurs merken er voorzichtig bij op dat hun bevindingen specifiek zijn voor het type computerchips dat zij gebruikten (NVIDIA B200's) en de specifieke software die zij hebben gebouwd. Ze hebben geen universele wet gevonden die voor elke computer in het universum geldt. Echter, ze hebben bewezen dat voor de voorhoede van AI-training, het negeren van de "systemen" (de hardware en hoe deze data verplaatst) leidt tot suboptimale resultaten.

Door MOSAIC te gebruiken, hebben ze aangetoond dat het "beste" model geen vast punt op een grafiek is, maar een bewegend doelwit dat afhangt van je specifieke hardwarebudget. Het meest efficiënte model is het model dat als een handschoen om je cluster past, en niet het model dat er op een stuk papier het beste uitziet. Dit is een verschuiving van "Compute-Optimal" (wat de wiskunde zegt) naar "Cluster-Optimal" (wat de hardware daadwerkelijk kan leveren).

Kortom, als je de slimste AI mogelijk wilt bouwen, heb je niet alleen een groter brein nodig; je hebt een brein nodig dat past bij het lichaam waarin het leeft.

Technische Samenvatting: Compute-Optimaal is Niet Cluster-Optimaal

Probleemstelling
Huidige grootschalige pretraining-workflows scheiden conventioneel algoritmische schalingbeslissingen van de systeemimplementatie. Een "scaling law"-fase selecteert een modelarchitectuur en een databudget om de loss te minimaliseren onder een vaste compute-restrictie (FLOPs), gevolgd door een losgekoppelde "systems"-fase die de implementatie optimaliseert voor hardware-efficiëntie. De auteurs stellen dat deze scheiding gebrekkig is voor sparse Mixture-of-Experts (MoE) modellen. Terwijl traditionele scaling laws de $C_{model}$ (Model FLOPs) optimaliseren, negeren ze de systeem-efficiëntie van de voorgeschreven architectuur. Twee architecturen met identieke voorspelde loss en $C_{model}$ kunnen zeer verschillende trainings-throughput opleveren vanwege variaties in Model FLOPs Utilization (MFU), communicatiekosten en geheugenvoetafdrukken. Bijgevolg kan de "compute-optimale" configuratie die uit een FLOPs-budget wordt afgeleid, onhaalbaar of suboptimaal zijn op een specifieke hardware-cluster, omdat het geen rekening houdt met de "leverbare" compute die een cluster daadwerkelijk kan ondersteunen over een vaste trainingsperiode.

Methodologie: MOSAIC
De auteurs introduceren MOSAIC (Model Optimization via Systems-Aware Training Co-design), een framework dat de modelarchitectuur en de systems co-design formuleert als één enkel optimalisatieprobleem. MOSAIC selecteert gezamenlijk de modelarchitectuur, het training-tokenbudget en de gedistribueerde executie-layout (parallelisme-strategie) om de voorspelde loss te minimaliseren onder een hardware-beperkt budget.

Het framework integreert drie kerncomponenten:

Een vierdimensionale gezamenlijke Scaling Law: De auteurs passen een nieuwe scaling law toe voor sparse MoE-modellen die het totale aantal parameters ( $N_{tot}$ ), het aantal training-tokens ( $D$ ), de sparsity ( $S$ ) en een expert split factor ( $G$ ) bevat. $G$ wordt gedefinieerd als de ratio tussen de dense feed-forward breedte en de enkele expert-breedte ( $G = d_{ff}/d_{expert}$ ), wat de granulariteit van de experts vastlegt. De wet is geformuleerd als:
$L(N_{tot}, S, D, G) = \frac{a}{N_{tot}^\alpha} + \frac{b}{D^\beta} + \frac{c}{(1-S)^\lambda} + \frac{j}{(1-S)^\delta N_{tot}^\gamma G^\eta} + e$
Deze formulering maakt het mogelijk om de loss te voorspellen op basis van discrete geometrische keuzes in plaats van abstracte parameteraantallen.
Een Operator-Level Performance Model: Om de systeem-efficiëntie te schatten, hebben de auteurs een analytisch performance model ontwikkeld dat MFU en het geheugengebruik voorspelt voor een gegeven architectuur en parallelisme-layout. Dit model houdt rekening met:
- Compute-kosten (dense en grouped GEMMs, attention).
- Communicatie-overhead (all-to-all voor expert-parallelisme, pipeline bubbles, data-parallel collectieven).
- CPU dispatch latency (kritiek voor kleine micro-batches).
- Hardware-specifieke kalibratiefactoren voor inter-node stragglers en intra-node overlap.
  Het model is gevalideerd tegen training-runs tot 18 miljard actieve parameters, waarbij een Mean Absolute Percentage Error (MAPE) van minder dan 15% in MFU-voorspelling werd behaald.
Gezamenlijke Optimalisatie (MINLP): MOSAIC lost een mixed-integer nonlinear program (MINLP) op dat de voorspelde loss minimaliseert, onder de restrictie dat de vereiste Model FLOPs ( $C_{model}$ ) niet de Deliverable Model FLOPs ( $C_{deliverable}$ ) overschrijden.
$C_{deliverable} = C_{peak} \times \text{MFU}(Z, P_\ell, B) \times \eta_{good}$
Hierbij is $C_{peak}$ het ruwe hardware-plafond, en MFU is architectuur-afhankelijk. De optimalisatie doorzoekt een discrete grid van realiseerbare geometrieën ( $Z$ ) en executieplannen ( $P_\ell$ ) om de configuratie te vinden die de loss minimaliseert binnen de werkelijke capaciteiten van de cluster.

Kernbijdragen

Herformulering van het Compute-budget: Het paper toont aan dat voor sparse MoE-modellen het optimaliseren onder een vast $C_{model}$ -budget leidt tot een "boundary-seeking" gedrag, waarbij de optimale sparsity zich aan de uiterste grens van de data-support bevindt (d.w.z. het meest sparse model mogelijk). Dit komt omdat de scaling law een lagere loss voorspelt voor sparser modellen bij vaste FLOPs, waarbij de systeemkosten worden genegeerd.
Systems-Aware Co-Design: Door de scaling law te koppelen aan een performance model, verschuift MOSAIC het budget van $C_{model}$ naar $C_{deliverable}$ . Dit onthult dat de optimale sparsity een interieurpunt is dat wordt bepaald door de specifieke beperkingen van de cluster (geheugen, bandbreedte, parallelisme-overhead), in plaats van de grens.
Validatie van het Performance Model: De auteurs bieden een gevalideerd, operator-level performance model dat MFU nauwkeurig voorspelt en de optimale parallel-layout (Tensor, Expert, Pipeline, Data Parallelism) identificeert voor sparse MoEs, waarbij zij aantonen dat de "beste" layout sterk afhankelijk is van de specifieke geometrie en de grootte van de cluster.
Empirische Validatie: Het framework is getest op AWS p6-nodes (NVIDIA B200 GPU's) met runs tot 250B totale parameters. De resultaten bevestigden dat de configuratie die de rangorde op basis van Model FLOPs volgt, significant verschilt van de rangorde op basis van hardware-compute-efficiëntie (wandkloktijd).

Resultaten

Boundary vs. Interior Optima: Onder een vaste $C_{model}$ daalt de gefitte loss monotoon met toenemende sparsity, wat het optimum naar de grens ( $S_{max}$ ) duwt. Echter, onder een vast hardware-budget ( $C_{deliverable}$ ) vertoont de loss-curve een interieurminimum. De systeemkosten (communicatie, geheugen) van extreem sparse modellen wegen uiteindelijk zwaarder dan hun theoretische voordelen in loss.
Loss vs. Throughput Trade-off: In experimenten met een budget van 32 nodes over 20 dagen, bereikte de configuratie die de meeste Model FLOPs realiseerde (een dichtere, grovere expert-geometrie) niet de laagste loss. Omgekeerd, de loss-optimale configuratie (een sparser, fijnere expert-geometrie) behield een lagere MFU, maar bereikte een lagere uiteindelijke loss omdat dit de enige configuratie was die binnen de leverbare FLOPs-restrictie paste terwijl een gunstig loss-traject werd behouden.
Real-World Validatie: Gestage pretraining-runs op 8-node clusters valideerden het framework. De gemeten MFU-volgorde kwam overeen met de voorspelde volgorde. Bovendien, wanneer de loss wordt uitgezet tegen "peak-equivalent hardware compute" (rekening houdend met MFU), klapt de rangorde van configuraties om ten opzichte van de rangorde tegenover ruwe Model FLOPs, wat bevestigt dat het "compute-optimale" model niet het "cluster-optimale" model is.

Significantie
Het paper pleit voor een fundamentele verschuiving in hoe frontier taalmodellen worden getraind: van gedisconnecteerde fasen van "scaling law selectie" en "systems tuning" naar een verenigde architectuur-systems co-design. De auteurs beweren dat het vertrouwen op enkel Model FLOPs-budgetten onvoldoende is voor sparse MoE-modellen, omdat het de systeem-efficiëntie van de architectuur niet meerekent. Door MOSAIC te introduceren, tonen zij aan dat de optimale model-geometrie geen universele constante is, maar afhankelijk is van de specifieke hardware-cluster, het trainingsvenster en de parallelisme-restricties. Deze aanpak zorgt ervoor dat de gekozen architectuur niet alleen theoretisch loss-optimaal is, maar ook praktisch haalbaar en efficiënt op de doelhardware.

Meer zoals dit