# Hoe Mixture of Experts LLM-productiekosten verlaagt [Naar de inhoud](#lm-inhoud)Netwerk/NL[EN](/en/)[Hubhub.llmnet.nlModellen vergelijken op taak, taal, kosten en licentie.](https://hub.llmnet.nl/)[Communitycommunity.llmnet.nlPrompttechnieken, patronen en systeemprompts.](https://community.llmnet.nl/)[APIapi.llmnet.nlLLM's robuust in software: rate limits, routing, structured output.](https://api.llmnet.nl/)[Consultancyconsultancy.llmnet.nlAI invoeren in een organisatie, van pilot tot productie.](https://consultancy.llmnet.nl/)[Nieuwsnieuws.llmnet.nlOntwikkelingen in AI, geduid voor Nederland.](https://nieuws.llmnet.nl/)[Benchmarkbenchmark.llmnet.nlZelf meten wat AI-kwaliteit is, voor jouw taken.](https://benchmark.llmnet.nl/)[Vacaturesvacatures.llmnet.nlAI-rollen, salarissen en carrièrepaden in Nederland.](https://vacatures.llmnet.nl/)[Lerenleren.llmnet.nlAI-concepten in gewoon Nederlands, van beginner tot bouwer.](https://leren.llmnet.nl/)[Gidsgids.llmnet.nlAI privé draaien op eigen Mac, pc, NAS of thuisserver.](https://gids.llmnet.nl/)[Directorydirectory.llmnet.nlHet AI-ecosysteem in kaart: tools, modellen, bedrijven.](https://directory.llmnet.nl/)[Radarradar.llmnet.nlSignalen uit X, onderzoek en communities voor indie developers.](https://radar.llmnet.nl/)[llmnet.nl — hoofdsite](https://llmnet.nl/)[](https://x.com/intent/post?url=https%3A%2F%2Fnieuws.llmnet.nl%2Fhoe-mixture-of-experts-de-rekenkosten-van-llm-productie-verlaagt&text=Hoe%20Mixture%20of%20Experts%20LLM-productiekosten%20verlaagt)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fnieuws.llmnet.nl%2Fhoe-mixture-of-experts-de-rekenkosten-van-llm-productie-verlaagt)[](https://www.reddit.com/submit?url=https%3A%2F%2Fnieuws.llmnet.nl%2Fhoe-mixture-of-experts-de-rekenkosten-van-llm-productie-verlaagt&title=Hoe%20Mixture%20of%20Experts%20LLM-productiekosten%20verlaagt)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fnieuws.llmnet.nl%2Fhoe-mixture-of-experts-de-rekenkosten-van-llm-productie-verlaagt&text=Hoe%20Mixture%20of%20Experts%20LLM-productiekosten%20verlaagt)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fnieuws.llmnet.nl%2Fhoe-mixture-of-experts-de-rekenkosten-van-llm-productie-verlaagt)[](https://www.reddit.com/submit?url=https%3A%2F%2Fnieuws.llmnet.nl%2Fhoe-mixture-of-experts-de-rekenkosten-van-llm-productie-verlaagt&title=Hoe%20Mixture%20of%20Experts%20LLM-productiekosten%20verlaagt)[](#) # Hoe Mixture of Experts de rekenkosten van LLM-productie verlaagt Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini) In het canonieke overzicht over modelarchitecturen zagen we in [de opkomst van kleine taalmodellen](https://nieuws.llmnet.nl/kleine-taalmodellen) hoe compactere parametersets de operationele kosten drukken door gerichte taakspecialisatie. Waar compacte dichte modellen (dense models) simpelweg minder parameters bevatten over de gehele linie, pakt de zogeheten Mixture of Experts-architectuur (MoE) het fundamentele schalingsprobleem via een andere as aan: conditionele activatie. In plaats van elk gewicht in het netwerk te raadplegen voor elk token dat wordt gegenereerd, activeert een spaarse MoE-laag slechts een klein deel van de totale parameters per rekenstap. De verschuiving naar MoE is in productiesystemen de dominante strategie geworden om grootschalige redeneercapaciteit betaalbaar te houden. De belofte klinkt aantrekkelijk: de prestaties en kennisopslag van een netwerk met honderden miljarden parameters, gekoppeld aan de rekenlatentie en FLOPS-behoefte van een veel kleiner model. Toch brengt deze conditionele rekenmethode een specifiek technisch evenwicht met zich mee. De besparing op Floating Point Operations per Second (FLOPS) verschuift de knelpunten namelijk rechtstreeks naar geheugenbandbreedte, VRAM-capaciteit en netwerkcommunicatie tussen chips. ## Het structurele verschil tussen dichte modellen en spaarse architecturen Klassieke transformer-modellen zijn 'dense' (dicht). Wanneer een dichte transformer een token verwerkt, passeert dat token alle parameters in de self-attention-lagen en in de feed-forward netwerken (FFN). Als een model 70 miljard parameters heeft, worden al die 70 miljard gewichten voor elk afzonderlijk gegenereerd token ingeladen en vermenigvuldigd. Deze lineaire koppeling tussen de totale modelgrootte en de rekenkracht per token vormt een economische barrière bij grootschalige uitrol. Een sparse Mixture of Experts-architectuur vervangt de klassieke FFN-lagen door een set van meerdere onafhankelijke 'experts' (meestal 8, 16 of meer parallelle FFN-blokken), vergezeld door een lichtgewicht routeringslaag, ook wel het gating-netwerk genoemd. De self-attention-lagen blijven veelal gedeeld over het hele netwerk om contextuele relaties tussen tokens vast te leggen, maar de daadwerkelijke transformatie en kennistoepassing in de FFN-laag wordt dynamisch toegewezen. Door per token slechts de top-1, top-2 of top-4 experts in te schakelen, ontkoppelt het model de totale parameteromvang (de modelcapaciteit) van de actieve parameteromvang (de rekenlast). Het onderscheid tussen totale en actieve parameters is essentieel bij het budgetteren van inferentie. Een MoE-model met in totaal 8x7B parameters (ongeveer 47 miljard parameters in totaal door gedeelde lagen) kan bijvoorbeeld geconfigureerd zijn met top-2 routering. Tijdens het genereren van een token rekent het systeem slechts met ongeveer 13 miljard actieve parameters. De lezer kan in het leertraject over [wat een token kost en rekenen aan contextlengte](https://leren.llmnet.nl/wat-kost-een-token-rekenen-aan-contextlengte-invoer-en-uitvoer) bestuderen hoe deze parameterfractie rechtstreeks doorwerkt in de theoretische kostprijs per duizend tokens. ## De wiskunde van het gating-netwerk en routeringsmechanismen De kern van een werkende MoE-architectuur is de router of gate. Deze component bepaalt voor elk token naar welke experts de representatievectoren worden doorgestuurd. Wiskundig gezien berekent het gating-netwerk een genormaliseerde kansverdeling over alle beschikbare experts via een softmax-functie over een lineaire projectie: # Conceptuele Top-k Routering in PyTorch-stijl import torch import torch.nn as nn import torch.nn.functional as F class SparseMoERouter(nn.Module): def __init__(self, d_model: int, num_experts: int, top_k: int = 2): super().__init__() self.gate = nn.Linear(d_model, num_experts, bias=False) self.top_k = top_k def forward(self, x: torch.Tensor): # x shape: [batch_size * seq_len, d_model] logits = self.gate(x) weights, indices = torch.topk(logits, self.top_k, dim=-1) routing_weights = F.softmax(weights, dim=-1) return routing_weights, indices Hoewel de wiskunde eenvoudig oogt, schuilt de complexiteit in het trainen van deze router. Zonder correcties treedt er snel expert-instorting (expert collapse) op: het netwerk leert om enkele favoriete experts voor vrijwel alle tokens te selecteren, waardoor de overige experts ongetraind blijven en het systeem feitelijk degradeert tot een kleiner dicht model. Om dit te voorkomen, introduceren ontwikkelaars hulpverliezen (auxiliary loss functies) tijdens het trainen die een gelijkmatige spreiding van tokens over alle experts afdwingen. Moderne architecturen verfijnen dit principe via fijnmazige routering (fine-grained experts). In plaats van 8 grote experts kiest men bijvoorbeeld voor 64 of 128 micro-experts, waarbij er naast dynamisch gekozen experts ook vaste, gedeelde experts zijn die altijd vuren. Deze gedeelde experts vangen domein-onafhankelijke grammatica en algemene taalpatronen op, zodat de gespecialiseerde micro-experts zich puur kunnen richten op specifieke kennisdomeinen of syntactische structuren. ## Waarom FLOPs dalen maar VRAM-eisen gelijk blijven De rekenkundige efficiëntie van MoE leidt in de praktijk regelmatig tot verwarring bij engineers die servers inrichten. De vermindering van rekenkracht (FLOPS) vertaalt zich niet automatisch in lagere hardware-eisen per servernode. Om een model te kunnen draaien, moeten namelijk alle parameters – zowel de actieve als de inactieve experts – in het snelle GPU-werkgeheugen (VRAM) geladen zijn. Modeltype & Configuratie | Totale Parameters | Actieve Parameters / Token | Minimaal VRAM (FP16/BF16) | Minimaal VRAM (INT4 Kwantisatie) | Dense Medium (70B) | 70 miljard | 70 miljard | ca. 140 GB | ca. 40 GB | Sparse MoE (8x7B, Top-2) | ca. 47 miljard | ca. 13 miljard | ca. 95 GB | ca. 28 GB | Sparse MoE (8x22B, Top-2) | ca. 141 miljard | ca. 39 miljard | ca. 285 GB | ca. 80 GB | Groot Dense Model (405B) | 405 miljard | 405 miljard | ca. 810 GB | ca. 230 GB | De tabel toont de duidelijke scheidslijn: een 8x7B MoE-model heeft tijdens runtime evenveel geheugenruimte nodig als een dichte variant van 47 miljard parameters, maar het vereist per token slechts de rekenkracht van een 13B model. De winst zit hem in de doorvoersnelheid en energie-efficiëntie per compute-cluster. In het achtergrondartikel over [de hardware-race rond AI-chips en rekenkracht](https://nieuws.llmnet.nl/chips-en-hardware-race) wordt geanalyseerd hoe geheugenbandbreedte (HBM) daardoor een belangrijkere beperkende factor is geworden dan pure tensor-rekenkernen. ## De impact op inferentie-infrastructuur en batch-verwerking Bij inferentie op productieschaal draait alles om twee kernstatistieken: Time To First Token (TTFT) en inter-token latentie (throughput in tokens per seconde). MoE-modellen leveren bij kleine batchgroottes een drastische versnelling op ten opzichte van dichte modellen met een vergelijkbare kenniskwaliteit, omdat de processor per token veel minder matrixvermenigvuldigingen hoeft uit te voeren. Zodra de batchgrootte toeneemt bij drukbezochte API-eindpunten, ontstaat er echter een specifiek schaalprobleem: token-fragmentatie. Wanneer een server 64 verzoeken tegelijkertijd verwerkt, kiezen de tokens binnen die batch verschillende routes. Waar bij een batchgrootte van 1 slechts twee experts actief zijn, worden bij een batch van 64 vrijwel alle experts in het geheugen aangesproken. De rekenbesparing per token blijft bestaan, maar de voordelen van geheugencaching en aaneengesloten data-overdracht nemen af. Om deze reden vereist MoE-inferentie gespecialiseerde serving engines zoals vLLM, TensorRT-LLM of SGLang met aangepaste CUDA-kernels voor sparse matrix operations (zoals segmented GEMM). Deze softwarelagen groeperen binnenkomende tokens dynamisch per expert voordat de berekening wordt gestart. Zonder deze optimalisaties leidt de overhead van verspreide geheugentoegang ertoe dat de theoretische rekenwinst op papier verdampt in de praktijk van de serverarchitectuur. ## Geheugenbandbreedte versus rekenkracht: het geheugengebonden regime De generatiefase van een LLM (het token-voor-token uitsturen) is fundamenteel memory-bandwidth bound (geheugengebonden). Voor elk individueel token moeten de modelgewichten van het DRAM/HBM-geheugen naar de rekenkernen worden gekopieerd. Bij een dicht model van 70B moet bij batchgrootte 1 telkens 140 GB aan data over de geheugenbus reizen om één enkel token te produceren. Bij een MoE-model verwerkt de GPU alleen de gewichten van de geactiveerde experts en de vaste lagen. Voor een 8x7B model met top-2 routering hoeft de geheugencontroller per token slechts ongeveer 26 GB aan gewichten over te dragen in plaats van 95 GB. Dit verklaart direct waarom MoE-modellen zulke hoge generatiesnelheden halen op afzonderlijke streams: de wachttijd op geheugentransport neemt met een factor drie tot vier af. In productiescenario's waar de rekencapaciteit verder geoptimaliseerd moet worden, combineert men MoE-architecturen vaak met applicatielagen voor opslag en hergebruik. In het document over [het effectief toepassen van LLM-caching](https://api.llmnet.nl/caching-llm-antwoorden) wordt uitgelegd hoe semantische en prompt-caching de routeringsoverhead volledig omzeilen voor herhaalde verzoeken, wat de uiteindelijke infrastructuurkosten nog verder verlaagt. ## Distributie over meerdere GPU's: Expert Parallelism Wanneer een MoE-model te groot is voor één enkele grafische kaart, introduceert men naast Tensor Parallelism (TP) en Pipeline Parallelism (PP) een specifieke parallelisatietechniek: Expert Parallelism (EP). Hierbij worden verschillende experts verdeeld over verschillende fysieke GPU's binnen of tussen servers. [Token Invoer] ---> [Gedeelde Self-Attention op alle GPU's] | v [Routeringslaag (Top-2 Selectie)] / \ (Token A naar Expert 1) (Token B naar Expert 7) | | v v [GPU 0: Expert 1..2] [GPU 3: Expert 7..8] \ / ---> [All-to-All Communicatie] Expert Parallelism introduceert echter een zware afhankelijkheid van netwerkbandbreedte. Tussen de attention-laag en de experts moeten tokens via zogeheten All-to-All collectieve operaties worden uitgewisseld tussen de verschillende GPU's. Als de interconnects (zoals NVLink binnen een node, of InfiniBand/RoCE tussen nodes) niet snel genoeg zijn, blokkeren de GPU-rekenkernen in afwachting van netwerkpakketten. Waar een dense model vooral rekent en af en toe tensor-synchronisaties uitvoert, vereist een gedistribueerd MoE-systeem een datacenternetwerk met extreem lage latentie en hoge doorvoer. ## De trade-offs: complexiteit, load balancing en fijnmazig afstemmen Ondanks de grote efficiëntievoordelen kent de inzet van Mixture of Experts in een productieomgeving significante nadelen die zorgvuldig moeten worden afgewogen: - Instabiliteit tijdens fine-tuning: Het trainen of finetunen van MoE-modellen met LoRA of full-parameter fine-tuning is aanmerkelijk complexer dan bij dichte netwerken. De routeringsbeslissingen kunnen verschuiven door taakspecifieke data, waardoor bepaalde experts overbelast raken en het model zijn generalisatievermogen verliest. - Onvoorspelbaar geheugengebruik bij piekbelasting: Als een plotselinge stroom van gebruikersvragen toevallig tokens genereert die allemaal naar dezelfde specifieke expert worden gerouteerd (load imbalance), ontstaat er een hotspot op de GPU die die specifieke expert host. De verwerkingsrij op die GPU loopt vol, terwijl andere GPU's in het cluster nietsdoend wachten. - Kwantisatie-uitdagingen: Het kwantiseren van MoE-modellen (bijvoorbeeld naar INT4 of FP4) vereist specialistische kalibratie. Omdat verschillende experts verschillende activatiedynamieken en uitschieters (outliers) vertonen, leidt uniforme kwantisatie vaak tot groter kwaliteitsverlies dan bij homogene dichte netwerken. - Vaste geheugenvoetafdruk: Organisaties die lokaal draaien hebben nog steeds dure servers nodig met voldoende totale VRAM-capaciteit om het volledige model in te laden, zelfs als de gemiddelde GPU-belasting laag blijft. De adoptie van deze techniek staat niet op zichzelf; in het bredere ecosysteem zien we dat de ontwikkelingen in [open-source LLM-trends](https://nieuws.llmnet.nl/open-source-llm-trends) ervoor zorgen dat steeds meer open gewichten beschikbaar komen als MoE. Hierdoor wordt hoogwaardige redeneercapaciteit bereikbaar voor organisaties met een beperkt rekenbudget, mits hun hardwarearchitectuur is ingericht op de bijbehorende geheugeneisen. ## Kostenanalyse in de praktijk: wanneer kies je voor MoE? De keuze tussen een dense architectuur en een sparse MoE-model hangt in de praktijk af van de operationele context waarin het model wordt ingezet: Kies voor een dense model wanneer de toepassing lokaal draait op edge-apparaten of werkstations met strikt beperkt VRAM (zoals laptops of embedded systems), wanneer batchgroottes constant zeer groot zijn en geheugenbandbreedte maximaal wordt benut, of wanneer continue fine-tuning op kleine domeindatasets een vaste vereiste is binnen het ontwikkelteam. Kies voor een Mixture of Experts-architectuur wanneer het systeem via een API of centrale serveromgeving opereert met variabele werklasten, wanneer lage latentie per gebruiker essentieel is zonder concessies te doen aan brede achtergrondkennis en redeneervaardigheden, en wanneer de infrastructuur beschikt over voldoende geheugenruimte (eventueel ondersteund door snelle interconnects tussen kaarten). De economische realiteit van AI-infrastructuur dwingt engineeringteams om scherp te sturen op de kosten per gegenereerd antwoord. Mixture of Experts lost de inherente spanning tussen modelcapaciteit en rekenbudget niet op door magie, maar door een doordachte herverdeling van computetaken over tijd en hardware. Daarmee heeft het een vaste plaats veroverd als hoeksteen van moderne, kostenefficiënte LLM-productiesystemen.