🤖 machine learning

WiSP: A Working-Set View of Mixture-of-Experts Serving on Extremely Low-Resource Hardware

Dit artikel introduceert WiSP, een routing-bewust working-set beheersysteem voor Mixture-of-Experts-modellen op hardware met beperkte middelen dat expertgewichten dynamisch paginaat en de VRAM-allocatie tussen experts en de KV-cache optimaliseert om de decode-doorvoersnelheid aanzienlijk te verbeteren zonder de onderliggende serving engine aan te passen.

Oorspronkelijke auteurs: Jiamu Zhang, Liang Wu, Mayank Darbari, Liangjie Hong

Gepubliceerd 2026-06-23

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Jiamu Zhang, Liang Wu, Mayank Darbari, Liangjie Hong

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

Het Grote Probleem: De AI die "Te Groot is om te Passen"

Stel je voor dat je een enorme bibliotheek aan boeken hebt (het AI-model) die honderden miljarden pagina's bevat. Je wilt een specifiek verhaal lezen op een kleine, draagbare e-reader (een standaard grafische kaart, of GPU).

Het probleem is dat de e-reader niet genoeg geheugen heeft om de hele bibliotheek tegelijk te bevatten. Echter, voor elke specifieke zin die je leest, heb je slechts een paar specifieke pagina's uit een paar specifieke boeken nodig. De rest van de bibliotheek ligt ongebruikt te wachten.

Huidige oplossingen proberen dit op te lossen door de hele bibliotheek in een magazijn te bewaren (het hoofdgeheugen van de computer) en telkens naar het magazijn te rennen om de pagina's te pakken die je nodig hebt, elke keer als je een bladzijde omslaat. Dit is traag omdat de reis naar het magazijn (datatransfer) lang duurt.

De WiSP-oplossing: De "Slimme Bibliothecaris"

De auteurs hebben een systeem ontwikkeld genaamd WiSP (Working-Set Paging). In plaats van voor elke pagina naar het magazijn te rennen, fungeert WiSP als een slimme bibliothecaris die observeert wat je aan het lezen bent en een kleine, zorgvuldig samengestelde stapel boeken die waarschijnlijk nodig zullen zijn, direct op je bureau houdt (het GPU-geheugen).

Zo werkt het in drie eenvoudige delen:

1. De "Slimme Stapel" (Expert Paging)

In AI-modellen die "Mixture-of-Experts" (MoE) worden genoemd, heeft het model veel verschillende "experts" (gespecialiseerde sub-modellen), maar gebruikt het er slechts een paar voor elk woord dat het genereert.

De Oude Manier: Het systeem pakt alle experts voor een laag, zelfs als het er slechts twee gebruikt. Dit verspilt ruimte en tijd.
De WiSP-Manier: WiSP houdt alleen de specifieke experts die je daadwerkelijk gebruikt op je bureau. Als je een nieuwe expert nodig hebt, wisselt het er snel één uit de stapel en haalt de nieuwe op uit het magazijn.
Het Resultaat: Omdat het alleen de piepkleine stukjes verplaatst die je daadwerkelijk nodig hebt, is het veel sneller. Het paper vond dat dit de AI op kleine computers tot wel 2 keer sneller maakt dan de oude methode.

2. Het "Gedeelde Bureau" (Memory Allocation)

Je bureau (GPU-geheugen) is erg klein. Je hebt twee zaken die om ruimte vechten:

De Expert-stapel: De boeken die je op dit moment nodig hebt om te lezen.
De Context-notities (KV Cache): De aantekeningen die je tot nu toe over het verhaal hebt gemaakt, zodat je niet vergeet wat er is gebeid.

Als je je bureau vult met te veel boeken, heb je geen ruimte meer voor je aantekeningen. Als je het bureau vult met te veel aantekeningen, kun je de boeken die je nodig hebt niet pakken.

De WiSP-oplossing (MV-WSA): Dit is een slimme regel die beslist hoe de ruimte op je bureau verdeeld moet worden. Het vraagt zichzelf constant af: "Is het nuttiger om meer boeken op het bureau te hebben, of meer aantekeningen?"
Het past deze verdeling dynamisch aan. Als je een lang verhaal schrijft, geeft het je meer ruimte voor aantekeningen. Als je snel van onderwerp wisselt, geeft het je meer ruimte voor boeken. Dit zorgt ervoor dat je nooit voor een van beide tekortkomt.

3. De "Glazen Bol"-mythe (Waarom Voorspellen Niet Hielp)

De onderzoekers vroegen zich af: "Wat als we een glazen bol (AI-voorspelling) gebruiken om te raden welk boek je er als volgende bij nodig hebt, en het alvast pakken voordat je erom vraagt?"

De Verrassing: Ze ontdekten dat in deze specifieke setting (het lezen van één zin tegelijk), voorspellen het niet sneller maakt.
Waarom? De "weg" (de datacontact) tussen het magazijn en het bureau is te smal. Zelfs als je perfect voorspelt, kan de vrachtwagen maar een beperkte hoeveelheid tegelijk vervoeren. De flessenhals is niet het raden van het juiste boek; het is de snelheid van de vrachtwagen.
De Werkelijke Waarde: De "glazen bol" is nog steeds nuttig, maar niet voor de snelheid. Het helpt de bibliothecaris om precies te weten hoe groot de stapel voor jou specifiek moet zijn. Hierdoor kan het systeem de stapel verkleinen tot de perfecte grootte, waardoor er meer bureauplek vrijkomt voor je aantekeningen.

De Kern van het Verhaal

Het paper betoogt dat het draaien van grote AI-modellen op kleine computers een geheugenbeheerprobleem is, en niet alleen een rekenprobleem.

WiSP is een hulpmiddel dat fungeert als een slimme bibliothecaris, die alleen de noodzakelijke boeken op het bureau houdt en ze efficiënt verwisselt.
Het verandert het AI-model zelf niet; het beheert alleen het geheugen beter.
Het maakt de AI aanzienlijk sneller op kleine apparaten door te voorkomen dat er tijd wordt verspild aan het verplaatsen van onnodige gegevens.
Het leert ons dat in dit specifieke scenario het efficiënt beheren van je werkruimte belangrijker is dan het proberen te voorspellen van de toekomst.

Het systeem werkt zo goed dat het zelfs enorme AI-modellen kan draaien op een enkele computerkaart die ze voorheen helemaal niet aan kon, zonder de kwaliteit van de antwoorden van de AI te veranderen.

Technische Samenvatting: WiSP – Een Working-Set Perspectief op Mixture-of-Experts Serving op Extreem Laag-Resource Hardware

Probleemstelling
Moderne Mixture-of-Experts (MoE) modellen, zoals Qwen3-30B-A3B en Mixtral-8×7B, plaatsen het merendeel van hun parameters in de expert-lagen, terwijl slechts een klein fractie van deze experts actief is voor elk gegeven token. Op consumenten-GPU's met beperkt VRAM passen deze modellen vaak niet volledig in het geheugen. De standaardoplossing, statische laag-niveau CPU-offloading (bijv. --cpu-offload-gb in vLLM), houdt het geheugengebruik laag maar transporteert alle experts in een laag bij elke forward pass over de PCIe-bus. Deze aanpak slaagt er niet in om de sparsity van MoE-modellen te benutten, wat hun efficiëntievoordelen effectief tenietdoet.

De auteurs kaderen het serving van MoE met lage resources als een working-set managementprobleem. In dit regime is het GPU-geheugen de beperkte snelle opslag en het host-geheugen de back-end opslag. Twee verschillende stromen van geheugenvraag concurreren om hetzelfde VRAM-budget:

Expert Weights: Een routing-afhankelijke stroom waarbij slechts een subset van experts nodig is per token.
KV Cache: Een token-afhankelijke stroom die vereist is voor autoregressieve generatie.

Bestaande systemen behandelen deze vaak als afzonderlijke problemen of richten zich op high-batch datacenter-instellingen waar berekening kan overlappen met datatransport. In scenario's met lage concurrency voor interactieve serving (bijv. lokale programmeerassistenten) is de berekening per stap minimaal, waardoor de PCIe-bandbreedte de primaire bottleneck wordt in plaats van de rekenkracht of voorspellingsnauwkeurigheid.

Methodologie: WiSP (Working-Set Paging)
Het paper introduceert WiSP, een systeem dat de aanwezige expert-set behandelt als een cache over het routinggedrag van het model, die gezamenlijk met de KV-cache wordt beheerd. WiSP bestaat uit twee hoofdonderdelen:

Routing-Aware Expert Pager:
- Mechanisme: WiSP sluit aan bij een ongewijzigde serving engine (bijv. vLLM) door gebruik te maken van een bestaande expert-map indirectie-hook (π). In plaats van volledige lagen te laden, onderhoudt het een kleine GPU scratch-ruimte die alleen de "working set" van experts bevat die waarschijnlijk hergebruikt zullen worden.
- Werking: Bij elke stap haalt de pager alleen de ontbrekende gerouteerde experts uit het host-geheugen (H2D) en verwijdert de least-recently-used (LRU) experts om ruimte te maken.
- Garanties: Omdat de onderliggende kernels en weights onveranderd blijven (alleen de mapping wordt omgeleid), produceert WiSP byte-identieke outputs aan de baseline engine. Het vereist geen nieuwe kernels, kwantisatieveranderingen of modelretraining.
MV-WSA (Marginal-Value Working-Set Allocation):
- Het Allocatieprobleem: Omdat expert weights en de KV-cache hetzelfde VRAM-budget delen, vermindert het vergroten van de aanwezige expert-set de KV-capaciteit, en vice versa.
- Strategie: MV-WSA bepaalt de optimale splitsing ( $f$ ) tussen het expert-budget en het KV-budget. Het streeft ernaar om de marginale latentie-voordeel per byte over beide pools gelijk te trekken.
- Admission Floor: Cruciaal is dat de allocator een minimale KV-cache grootte ( $\kappa_{min}$ ) afdwingt die vereist is om de huidige concurrency toe te laten. Als de onbeperkte optimale splitsing de KV-cache zou uithongeren, klemt het systeem de splitsing om te garanderen dat de scheduler kan initialiseren en draaien.
- Implementatiemodi:
  - Offline Configurator: Analyseert een representatieve trace om bij de start een vaste splitsing in te stellen.
  - Online Controller: Wijzigt de grootte van beide pools dynamisch tijdens het serveren op "drained barriers" (punten waar geen actieve verzoeken meer geheugenblokken vasthouden), waarbij bytes fysiek tussen de expert scratch en de KV-pool worden verplaatst zonder het totale budget te overschrijden.

Belangrijkste bevindingen over Prefetching
Een centrale empirische bevinding van het paper is dat routing-gebaseerde prefetching weinig tot geen voordeel biedt in single-stream, low-concurrency decode.

Bottleneck: De prestaties worden beperkt door de PCIe-bandbreedte, niet door de voorspellingsnauwkeurigheid. In batch-1 decode is de berekening per stap te klein om PCIe-transfers achter te kunnen, te verbergen.
Resultaat: Speculatieve prefetching verslechtert de prestaties vaak (vermindert de throughput met ~50% in tests) omdat het concurreert om bandbreedte en experts verwijdert die nodig zijn voor de directe volgende stap.
Herformulering: Het routing-signaal is waardevol, niet voor het verbergen van latentie, maar voor geheugenallocatie. Het helpt bij het identificeren van de minimale "veilige" aanwezige set-grootte, waardoor het systeem de expert-cache per gebruiker kan afstemmen en het vrijgekomen VRAM aan de KV-cache kan toewijzen.

Resultaten
De auteurs evalueren WiSP op diverse MoE-architecturen (LLM's, VLM's, Hybride SSM-MoE en Diffusiemodellen) met behulp van een NVIDIA H100 (waarbij sommige experimenten kleinere geheugenbudgetten simuleren).

Throughput Winsten: Onder gelijke VRAM-budgetten waarbij het model niet past, bereikt WiSP tot wel 1.95× decode throughput vergeleken met statische CPU-offloading. De winst is het grootst bij intermediaire geheugenbudgetten waar WiSP een aanzienlijk deel van de hergebruikte expert-set kan cachen, terwijl de baseline alles moet streamen.
KV Capaciteit: Door de expert-voetafdruk te verkleinen, vergroot WiSP direct de KV-cache capaciteit. Experimenten tonen aan dat het verkleinen van de expert-cap de maximale concurrency met meer dan 40% kan verhogen bij hetzelfde totale geheugenbudget.
Allocatie Prestaties:
- Offline: De MV-WSA configurator presteert goed op zowel prefill als decode, en blijft binnen enkele procenten van een per-workflow oracle in simulatie, terwijl vaste splitsingen (bijv. 50/50) ~20% slechter zijn.
- Online: De dynamische dual-resize controller verbetert de throughput met 1.20× ten opzichte van de beste statische offline split door zich aan te passen aan workload-verschuivingen (bijv. schakelen van lang-context beurten naar tool-call bursts).
Generaliteit: WiSP bedient succesvol modellen die niet op een enkele GPU passen (bijv. Jamba-v0.1, MiniMax-M2) en werkt over modaliteiten heen, inclusief Vision-Language Modellen (Kimi-VL) en Diffusiemodellen (DiT-MoE, LLaDA-MoE), waarbij byte-identieke outputs worden behouden.

Betekenis en Claims
Het paper claimt dat WiSP een verenigd framework biedt voor low-resource MoE serving door de aanwezigheid van experts en KV-caching te behandelen als één enkel working-set allocatieprobleem.

Verschuiving in Ontwerpparadigma: Het betoogt dat de focus voor low-concurrency serving moet verschuiven van "hoe prefetchen we experts sneller" naar "hoe alloceren we VRAM optimaal tussen experts en de KV-cache".
Praktische Impact: WiSP maakt het mogelijk om frontier-schaal MoE-modellen op consumentenhardware te bedienen zonder de correctheid van de output op te offeren of gespecialiseerde hardware (zoals Intel AMX) te vereisen.
Beperkingen: De auteurs merken expliciet op dat WiSP is ontworpen voor het regime waarin het model niet in het VRAM past; als het model wel past, blijft statische residency sneller omdat paging onnodige indirectie toevoegt. Daarnaast is aangetoond dat de prefetching-optimalisatie ineffectief is bij single-stream decode, hoewel het relevant kan zijn voor high-batch of multi-turn agent sessies waar compute overlap mogelijk is.

Het werk concludeert dat in de geheugen-gebonden, single-stream decode, het routing-signaal een geheugen-hefboom is (bepaalt de grootte van de working set) in plaats van een snelheid-hefboom (het verbergen van latentie), waardoor intelligente allocatie de primaire drijfveer voor prestaties is.