💬 NLP

GEM: GPU-Variability-Aware Expert to GPU Mapping for MoE Systems

GEM is een framework dat de inferentielatentie van Mixture-of-Experts (MoE)-modellen optimaliseert door experts op basis van hardwarevariatie en tokenbeladingspatronen op GPUs af te beelden, waardoor straggler-effecten worden verminderd en de end-to-end-prestaties met tot 16,5% worden verbeterd.

Oorspronkelijke auteurs: Sourish Wawdhane, Avinash Kumar, Poulami Das

Gepubliceerd 2026-05-20

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Sourish Wawdhane, Avinash Kumar, Poulami Das

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 een keuken van een high-end restaurant runt (het GPU-cluster) waar je een team van gespecialiseerde chefs (de Experts) hebt dat een enorme bestelling van gerechten voor veel klanten tegelijk bereidt.

In een modern "Mixture-of-Experts" (MoE) AI-model heeft de keuken niet één grote chef die alles doet. In plaats daarvan heeft het veel kleinere, gespecialiseerde chefs. Voor elk enkel woord dat de AI genereert (een "token"), beslist een manager (de Router) welke twee chefs nodig zijn om dat specifieke woord te bereiden.

Het probleem: De "Langzaamste Chef"-regel

In deze keuken geldt een strenge regel: Het hele team moet wachten op de langzaamste persoon om klaar te zijn voordat ze naar de volgende stap kunnen gaan.

Als je 8 chefs hebt, en 7 van hen hun taken in 10 seconden afronden, maar één chef 12 seconden nodig heeft omdat deze langzamer is of te veel werk heeft, zit de hele keuken vast te wachten op die extra 2 seconden. In de wereld van AI wordt deze wachttijd een "straggler" (vertrager) genoemd, en het doodt de snelheid van het hele systeem.

Het artikel identificeert twee hoofdredenen waarom een chef een straggler wordt:

Slechte Toewijzing: De manager gaf per ongeluk de drukste, populairste recepten aan slechts één chef, terwijl anderen inactief zaten.
Hardware-Variabiliteit: Zelfs als het werk perfect is verdeeld, zijn sommige chefs van nature langzamer dan anderen vanwege hun specifieke hardware (zoals een oudere oven of een vermoeide arm). Het artikel vond dat in een groep identiek ogende GPU's, de snelste bijna 28% sneller kan zijn dan de langzaamste.

De oude manier: "Gelijke Werklast, Gelijke Tijd"

Vorige oplossingen probeerden dit op te lossen door elke chef exact hetzelfde aantal gerechten te geven om te bereiden. Ze dachten: "Als iedereen evenveel werk heeft, zullen iedereen op hetzelfde moment klaar zijn."

Maar dit faalt omdat:

Verschillende Snelheden: Een snelle chef kan 14% meer gerechten bereiden in dezelfde tijd als een langzame chef. Als je ze exact dezelfde stapel werk geeft, is de snelle chef vroeg klaar en moet wachten, terwijl de langzame chef nog steeds worstelt.
Verborgen Patronen: Sommige chefs zijn bijna de hele tijd druk (Consistente Experts), terwijl anderen alleen samen druk zijn in korte, intense piekmomenten (Temporale Experts). Oude methoden misten deze "piekerende" patronen. Als twee chefs die altijd op precies hetzelfde moment druk worden, aan dezelfde trage machine worden toegewezen, komt de hele keuken tot stilstand.

De nieuwe oplossing: GEM (GPU-variabiliteitsbewuste Expert Mapping)

De auteurs stellen GEM voor, een slim systeem dat fungeert als een geniale keukenmanager die precies weet hoe snel elke chef is en hoe de bestellingen binnenkomen.

GEM gebruikt twee slimme trucs:

1. De "Proportionele Last"-strategie
In plaats van iedereen hetzelfde aantal gerechten te geven, geeft GEM de snelle chefs meer gerechten en de langzame chefs minder gerechten.

Analogie: Stel je een race voor. Als een renner 14% sneller is, geef je hen niet dezelfde afstand als de langzamere renner. Je geeft hen een langere baan zodat ze beide op precies hetzelfde moment de finishlijn kruisen.
GEM berekent precies hoeveel extra werk de snelle GPU's aankan zodat iedereen de laag op hetzelfde moment afrondt.

2. De "Patroon-Detective"-strategie
GEM observeert de keuken even kort (slechts 16 stappen) om twee dingen te leren:

Wie is altijd druk? (De Consistente Experts).
Wie wordt samen druk? (De Temporale Experts).
Analogie: Als Chef A en Chef B altijd tegelijk een enorme instroom van bestellingen krijgen, zorgt GEM ervoor dat ze niet aan dezelfde trage oven worden toegewezen. Het spreidt ze uit over verschillende stations zodat ze elkaar niet blokkeren.

Hoe GEM werkt (Het 4-stapsproces)

Kijken en Leren: GEM observeert de AI voor een klein moment om te zien welke experts worden gebruikt en wanneer.
Testen van de Hardware: Het voert een snelle test uit om precies te zien hoe snel elke specifieke GPU is onder verschillende belastingen. Het doet dit slim door alleen te testen op specifieke "mijlpalen" (zoals het controleren van de snelheid van een auto elke 32 mijl in plaats van elke mijl) om tijd te besparen.
De Zoektocht: Het voert een simulatie uit om de perfecte rangschikking van chefs naar ovens te vinden. Het probeert chefs te verwisselen totdat het een opstelling vindt waarbij de "langzaamste" chef zo snel mogelijk klaar is.
Implementeren: Het vergrendelt deze nieuwe rangschikking. De AI begint te draaien, en omdat het werk is gebalanceerd voor de werkelijke snelheid van de machines, draait het hele systeem soepeler.

De resultaten

Toen de auteurs dit testten op vijf verschillende krachtige AI-modellen:

Snelheidswinst: De AI voltooide taken gemiddeld 7,9% sneller.
Beste Geval: In sommige situaties was het 16,5% sneller.
Soepelere Ervaring: De "tail latency" (de worst-case vertragingen die gebruikers het gevoel geven dat de AI stottert) verbeterde zelfs meer, met tot 16,9%.

Kortom, GEM voorkomt dat de AI wacht op het langzaamste deel van het systeem door de snelle delen meer werk te geven en de langzame delen minder, terwijl het ervoor zorgt dat geen twee "drukke" experts vastzitten op dezelfde trage machine. Het verandert hardware-verschillen van een zwakte in een hulpmiddel voor betere prestaties.

Technische Samenvatting: GEM – Expert-naar-GPU-toewijzing met bewustzijn van GPU-variabiliteit voor Mixture-of-Experts-modellen

1. Probleemstelling

Mixture-of-Experts (MoE)-modellen verbeteren de inferentie-efficiëntie door slechts een subset van "expert"-subnetwerken per token te activeren. Hun prestaties in real-world serving-omgevingen worden echter ernstig geblokkeerd door straggler-GPU's. Bij lock-step-uitvoering moet een batch wachten tot de langzaamste GPU een laag heeft verwerkt voordat het kan doorgaan.

Het artikel identificeert twee primaire oorzaken voor stragglers die bestaande oplossingen niet gelijktijdig aanpakken:

Expert-ongelijkheid: Bepaalde experts worden onevenredig vaker gebruikt dan anderen. Als deze "zwaar gebruikte" experts op één GPU zijn ondergebracht, wordt die GPU een knelpunt.
Hardware-variabiliteit: Moderne GPU's vertonen inherente prestatievariabiliteit door procesvariaties, omgevingsfactoren en energiebeheer. Zelfs met perfect gebalanceerde tokenlasten zal een fysiek langzamere GPU fungeren als straggler.

Vorig werk probeert dit op te lossen door ofwel kunstmatige uniformiteit in expertgebruik in te voeren (wat de modelnauwkeurigheid verslechtert) of door experts dynamisch te herverdelen (wat geheugenoverhead met zich meebrengt). Cruciaal is dat deze benaderingen onwetend zijn van hardware-variabiliteit, waardoor zwaar gebruikte experts vaak op de langzaamste beschikbare GPU's worden geplaatst, waardoor het straggler-probleem in stand blijft.

2. Methodologie: GEM-framework

De auteurs stellen GEM (GPU-variability-aware Expert Mapping) voor, een framework dat experts toewijst aan GPU's door expliciet rekening te houden met zowel taakspecifieke tokenlasten als hardware-prestatiekenmerken. GEM werkt via een vierstaps-pijplijn:

Stap 1: Expert-gebruikstrace

GEM vangt de tokenrouteringspatronen van een specifieke taak tijdens online inferentie op. Het telt het aantal tokens dat naar elke expert wordt gerouteerd om een gebruikstrace op te bouwen.

Inzicht: Het artikel onderscheidt tussen consistente experts (die frequent worden gebruikt in de meeste tijdstappen) en temporele experts (die zelden worden gebruikt, maar zwaar in specifieke, gecorreleerde uitbarstingen).
Optimalisatie: Experimenten tonen aan dat een trace-lengte van 16 tijdstappen voldoende is om zowel consistente als temporele patronen vast te leggen zonder de implementatie te vertragen.

Stap 2: Profileren van prestatievariabiliteit

GEM profileert de latentie van MoE-lagen op verschillende GPU's als functie van de tokenlast.

Uitdaging: Gedetailleerde profilering (bij elke tokenaantal) is te traag (uren), terwijl grove steekproeven de "trapsgewijze" aard van MoE-latentie missen (waarbij de latentie springt bij specifieke batchgroottes).
Oplossing: GEM steekt tokenaantallen alleen op tegelgrenzen (veelvouden van 32 of 64 tokens, waar latentiesprongen optreden). Dit reduceert de profileringsduur van uren naar minuten (bijvoorbeeld 3 minuten voor Llama-4-Scout) terwijl de nauwkeurigheid behouden blijft.

Stap 3: Variabiliteitsbewuste expert-toewijzing

GEM gebruikt een iteratieve heuristische zoektocht om de optimale expert-naar-GPU-toewijzing te vinden.

Scorefunctie: In plaats van tokenaantallen te balanceren, minimaliseert GEM de som van straggler-latenties over alle tijdstappen. De score $S(M)$ wordt berekend als:
$S(M) = \sum_{t \in T} \max_{g} (C_g(n_g(M, t)))$
Waar $C_g$ de latentiekost is voor GPU $g$ gegeven het tokenaantal $n_g$ , afgeleid van de variabiliteitsprofielen.
Toegepaste kerninzichten:
1. Niet-uniforme lastbalancering: Snellere GPU's krijgen proportioneel meer tokens toegewezen dan langzamere GPU's, zodat alle GPU's ongeveer tegelijkertijd klaar zijn met het verwerken van een laag.
2. Correlatiebehandeling: GEM detecteert gecorreleerde temporele experts (experts die gelijktijdig in uitbarstingen worden gebruikt) en zorgt ervoor dat ze op verschillende GPU's worden geplaatst. Bovendien vermijdt het het plaatsen van deze hoog-belaste experts op de langzaamste GPU's.
Zoekalgoritme: Het systeem start met meerdere initiële toewijzingen (door ruis toe te voegen aan gebruiksmetrieken om diversiteit te garanderen) en wisselt iteratief expertparen om de totale straggler-latentiescore te verlagen tot convergentie.

Stap 4: Implementatie

Zodra de optimale toewijzing is bepaald, laadt GEM de expertgewichten op hun toegewezen GPU's bij het laden van het model. De MoE-router blijft tokens zoals gewoonlijk distribueren, maar de fysieke locatie van de experts is nu geoptimaliseerd voor de specifieke hardware-cluster.

3. Belangrijkste bijdragen

Identificatie van dubbele knelpunten: Het artikel benadrukt dat stragglers voortkomen uit de combinatie van niet-uniform expertgebruik en inherente GPU-hardwarevariabiliteit, een probleem dat door eerdere statische of dynamische balanceringsmethoden wordt over het hoofd gezien.
GEM-framework: Het eerste framework dat hardware-variabiliteitsbewuste expert-toewijzing uitvoert voor MoE-modellen.
Nieuwe toewijzingsstrategie:
- Latentie-gebaseerde balancering: Weg van gelijke tokenverdeling naar proportionele tokenverdeling op basis van GPU-snelheid.
- Detectie van temporele experts: Het identificeren en scheiden van gecorreleerde temporele experts om gelijktijdige lastpieken op enkele GPU's te voorkomen.
Efficiënte profilering: Een steekproefstrategie op tegelgrenzen die hardwarevariabiliteitsprofielen in minuten in plaats van uren vastlegt.

4. Experimentele resultaten

De auteurs evalueerden GEM op vijf state-of-the-art MoE-modellen (Mixtral-8x7B, Mixtral-8x22B, Llama-4-Scout, Hunyuan-A13B, Qwen3-30B-A3B) met behulp van ShareGPT- en CodeContests-datasets. Ze emuleerden drie niveaus van GPU-variabiliteit (Laag, Gemiddeld, Hoog) op een 4-GPU-node.

End-to-end latentie: GEM verbeterde de latentie gemiddeld met 7,9% en tot 16,5% ten opzichte van de baseline (standaard lineaire toewijzing van vLLM).
- Opstellingen met hoge variabiliteit zagen de grootste winsten (tot 16,5%).
- Zelfs in opstellingen met lage variabiliteit bood GEM verbeteringen (tot 4,5%) door te optimaliseren voor gecorreleerde temporele experts.
Tail-latentie (p90 TPOT): GEM verlaagde de 90e-percentiel tijd-per-output-token gemiddeld met 9,1% (tot 16,9%), wat de waargenomen responsiviteit aanzienlijk verbetert.
Profileringsoverhead: Het proces van variabiliteitsprofilering en toewijzing duurt in totaal minder dan 4 minuten, wat verwaarloosbaar is in vergelijking met de uren of dagen inferentie die in productie worden verleend.

5. Betekenis en claims

Het artikel beweert dat GEM het eerste hardware-variabiliteitsbewuste expert-toewijzingsframework is voor MoE-inferentie. De betekenis ligt in het transformeren van hardware-variabiliteit van een nadeel naar een toewijzingsbeperking die kan worden benut om de prestaties te verbeteren.

De auteurs benadrukken dat:

Het simpelweg balanceren van tokenaantallen onvoldoende is omdat het hardware-heterogeniteit negeert.
Het negeren van temporele experts (die vaak gecorreleerd zijn) leidt tot suboptimale toewijzingen, zelfs als de gemiddelde lasten gebalanceerd zijn.
Naarmate de systeemgroottes toenemen (bijvoorbeeld van 4 naar 64 GPU's), de kloof tussen de snelste en langzaamste GPU's monotoon groter wordt, waardoor variabiliteitsbewuste toewijzing steeds kritischer wordt voor grootschalige implementaties.

Het werk toont aan dat door de plaatsing van experts af te stemmen op zowel de statistische aard van tokenroutering als de fysieke realiteit van GPU-prestaties, aanzienlijke latentieverminderingen kunnen worden bereikt zonder modellen opnieuw te trainen of aanzienlijke geheugenoverhead te incasseren.