22 maart 2026
Bij hoge inferentieconcurrency, waarbij tientallen of honderden verzoeken tegelijk een LLM aansturen, is geheugenbandbreedte de meest kritieke hardwarebottleneck. De GPU moet bij elk verzoek enorme hoeveelheden modelgewichten uit het geheugen laden, en die bandbreedte raakt bij hoge concurrency razendsnel verzadigd. CPU-prestaties en PCIe-doorvoer spelen ook een rol, maar het geheugen is doorgaans de eerste en hardste begrenzing. Begrijpen welke bottleneck op welk moment domineert, helpt je de juiste hardware te kiezen voor jouw specifieke werklast.
Een hardwarebottleneck bij AI-inferentie is een component in je systeem die de verwerkingscapaciteit begrenst, waardoor andere componenten daarop moeten wachten. Bij LLM-inferentieserverhardware gaat het om de schakel die als eerste zijn maximale capaciteit bereikt: dat kan het GPU-geheugen zijn, de geheugenbandbreedte, de CPU, de PCIe-verbinding of de netwerkinterface.
Bottlenecks ontstaan niet altijd op dezelfde plek. Een systeem dat prima werkt bij vijf gelijktijdige verzoeken, kan volledig vastlopen bij vijftig. De reden is dat elke extra aanvraag extra druk legt op gedeelde resources. Omdat grote taalmodellen zo geheugenintensief zijn, verschuift de begrenzing bij hogere concurrency vrijwel altijd richting geheugen en bandbreedte, niet richting rekenkracht. Dat maakt het analyseren van bottlenecks bij inferentie fundamenteel anders dan bij training.
Geheugenbandbreedte wordt zo snel de beperkende factor omdat een LLM bij elke inferentiestap de volledige modelgewichten door het geheugen moet transporteren. Hoe meer gelijktijdige verzoeken er binnenkomen, hoe vaker die gewichten geladen moeten worden. De rekenkracht van de GPU staat daarbij te wachten: niet op berekeningen, maar op data uit het geheugen.
Dit fenomeen heet memory-bound inferentie. Grote modellen, zeker modellen met meerdere miljarden parameters, passen nauwelijks in het GPU-geheugen. Elke token die gegenereerd wordt, vereist een volledige doorloop van de gewichten. Bij lage concurrency valt dit mee, maar zodra tientallen verzoeken tegelijk draaien, raakt de geheugenbus snel verzadigd. De GPU rekent dan sneller dan het geheugen data kan aanleveren, wat leidt tot wachttijden en lagere doorvoer.
Technieken zoals KV-cache helpen om herberekening te vermijden, maar die cache vergt zelf ook geheugenruimte. Bij hoge concurrency groeit de KV-cache snel, wat de druk op beschikbaar GPU-geheugen verder vergroot. Meer geheugen per GPU en hogere bandbreedte zijn daarom de meest directe oplossingen.
Hoge concurrency verhoogt de GPU-belasting op twee manieren: het verhoogt het aantal parallelle berekeningen én de druk op het geheugen. Bij lage concurrency draait de GPU vaak niet op volle capaciteit. Bij hoge concurrency raken zowel de rekenkern als de geheugenbus dichter bij hun limiet, maar in de meeste LLM-inferentiescenario’s bereikt het geheugen zijn grens eerder dan de rekenkern.
GPU-utilization is daarbij een veelgebruikte maar misleidende maatstaf. Een GPU kan op papier tachtig procent bezetting tonen, terwijl hij in werkelijkheid grotendeels wacht op data uit het geheugen. Dit onderscheid tussen compute-bound en memory-bound gedrag is relevant voor het interpreteren van monitoringdata. Gebruik je profileringstools zoals Nsight of vendorspecifieke dashboards, kijk dan niet alleen naar GPU-gebruik, maar ook naar geheugenbandbreedte-utilization en geheugenlatentie.
Bij batch-inferentie, waarbij meerdere verzoeken gebundeld worden verwerkt, verschuift de balans iets richting compute. Maar bij realtime inferentie met wisselende aanvraagtijden, typisch voor productiesystemen, blijft geheugenbandbreedte de dominante bottleneck.
Een latentiebottleneck vertraagt individuele verzoeken: de tijd tussen het insturen van een prompt en het ontvangen van het eerste token stijgt. Een doorvoerbottleneck beperkt het totale aantal verzoeken dat het systeem per seconde kan verwerken. Beide bottlenecks hebben een andere oorzaak en vragen om een andere aanpak.
Latentiebottlenecks ontstaan vaak door geheugenlatentie, trage PCIe-overdracht of CPU-overhead bij het voorbereiden van batches. Bij interactieve toepassingen, zoals een chatinterface, is lage latentie de prioriteit. Gebruikers merken direct wanneer het eerste token te lang op zich laat wachten. Een snellere geheugenbus of een GPU met hogere bandbreedte per core helpt hier.
Doorvoerbottlenecks spelen een grotere rol bij batchverwerking of API-diensten die veel gelijktijdige gebruikers bedienen. Hier telt het totale aantal tokens per seconde over alle verzoeken heen. Meer GPU-geheugen maakt grotere batches mogelijk, wat de doorvoer verhoogt. Meerdere GPU’s of multinode-opstellingen zijn bij zeer hoge concurrency de logische vervolgstap.
Het is mogelijk om tegelijk een latentieprobleem en een doorvoerprobleem te hebben, maar de oplossing voor het een kan het ander verergeren. Grotere batches verhogen de doorvoer, maar verhogen ook de latentie per verzoek. Dit spanningsveld maakt het analyseren van de juiste bottleneck zo relevant.
De CPU speelt bij LLM-inferentie een ondersteunende, maar niet te onderschatten rol. De CPU verwerkt inkomende verzoeken, beheert de wachtrij, voert tokenisatie uit en coördineert de communicatie tussen systeem en GPU. Bij hoge concurrency kan de CPU een bottleneck worden als hij deze taken niet snel genoeg afhandelt.
CPU-bottlenecks bij inferentie manifesteren zich anders dan GPU-bottlenecks. Je ziet ze terug als hoge CPU-utilization gecombineerd met lage GPU-bezetting: de GPU staat te wachten op werk dat de CPU nog niet heeft klaargezet. Dit gebeurt vaker bij systemen met een relatief zwakke processor ten opzichte van de GPU-capaciteit, of bij inferentieframeworks die veel preprocessing op de CPU uitvoeren.
Een moderne server-CPU met voldoende cores en hoge singlethreadprestaties vermindert dit risico. Voor zware inferentieworkloads kies je bij voorkeur een platform waarbij CPU en GPU goed op elkaar zijn afgestemd, zodat geen van beide structureel op de ander hoeft te wachten.
Je bepaalt de meest kritieke bottleneck door je systeem te profileren onder realistische belasting. Meet tegelijk de GPU-utilization, geheugenbandbreedte-utilization, CPU-gebruik, PCIe-doorvoer en wachtrijdiepte. De component die als eerste zijn maximum bereikt terwijl andere componenten nog ruimte hebben, is de bottleneck.
Volg daarvoor een praktische aanpak:
De combinatie van hoge geheugenbandbreedte-utilization en stijgende latentie bij toenemende concurrency wijst op een memory-bound systeem. Hoog CPU-gebruik bij lage GPU-bezetting wijst op een CPU-bottleneck. Door beide scenario’s te kunnen onderscheiden, richt je optimalisaties en hardware-investeringen op de juiste plek.
De meest effectieve hardwarekeuzes voor hoge inferentieconcurrency richten zich op GPU-geheugen, geheugenbandbreedte en CPU-GPU-balans. GPU’s met meer HBM-geheugen en hogere geheugenbandbreedte verwerken grotere KV-caches en meer gelijktijdige verzoeken zonder te verzadigen. Multi-GPU-configuraties schalen de doorvoer verder op.
Concreet betekent dit dat je bij de keuze van LLM-inferentieserverhardware let op:
Platforms die al deze componenten goed op elkaar afstemmen, geven je de meeste ruimte om te schalen zonder steeds tegen dezelfde begrenzingen aan te lopen. Bij ons, NCS International, configureren we Supermicro-servers specifiek voor dit soort zware inferentieworkloads: van de GPU-selectie tot de CPU-configuratie en het geheugenontwerp. Supermicro ondersteunt als eerste nieuwe Nvidia-GPU-generaties, wat betekent dat je bij hoge inferentieconcurrency kunt beschikken over de nieuwste hardware, ruim voordat andere merken die mogelijkheid bieden. Bekijk onze serveroplossingen voor AI-inferentie en ontdek welke configuratie past bij jouw werklast en schaalbehoefte.
Een snelle manier is het vergelijken van GPU-utilization met geheugenbandbreedte-utilization via nvidia-smi. Als de GPU-utilization hoog lijkt maar de doorvoer tegenvalt, en de geheugenbandbreedte-utilization dicht bij 100% zit, ben je vrijwel zeker memory-bound. Gratis tools zoals nvidia-smi dmon of de open-source tool nvtop geven al genoeg inzicht om een eerste diagnose te stellen zonder licentiekosten.
Een veelgemaakte fout is focussen op het aantal TFLOPS van een GPU terwijl geheugenbandbreedte en VRAM-capaciteit de echte bottlenecks zijn bij hoge concurrency. Een andere valkuil is onderschatten hoeveel geheugen de KV-cache inneemt bij langere contexten en meer gelijktijdige gebruikers. Zorg er ook voor dat de CPU en PCIe-verbinding niet worden vergeten: een trage CPU of smalle PCIe-verbinding kan een krachtige GPU volledig fnuiken.
Ja, kwantisatie vermindert zowel het geheugengebruik als de benodigde bandbreedte significant, omdat de modelgewichten kleiner worden opgeslagen en sneller geladen kunnen worden. INT8-kwantisatie halveert ruwweg het geheugengebruik ten opzichte van FP16, en INT4 reduceert dit nog verder. Het nadeel is een mogelijke kwaliteitsafname in de modeloutput, dus het is verstandig om de nauwkeurigheid van je model te benchmarken na kwantisatie voordat je dit in productie uitrolt.
Dit hangt af van het modelformaat en de gewenste latentie, maar een vuistregel is dat een multi-GPU-configuratie relevant wordt zodra een enkele GPU structureel boven de 80-90% geheugenbandbreedte-utilization zit bij je gemiddelde concurrency. Voor modellen van 70 miljard parameters of groter is een multi-GPU-setup bij meer dan tien tot twintig gelijktijdige verzoeken vaak al noodzakelijk. Profileer je systeem onder piekbelasting om het omslagpunt voor jouw specifieke workload te bepalen.
Langere prompts vergroten de KV-cache per verzoek aanzienlijk, omdat voor elke token in de context key- en value-vectoren worden opgeslagen. Bij een context van 32.000 tokens kan de KV-cache per verzoek al meerdere gigabytes beslaan, wat bij hoge concurrency de beschikbare VRAM razendsnel uitput. Als jouw toepassing werkt met lange documenten of uitgebreide gespreksgeschiedenissen, is GPU-geheugengrootte nog kritischer dan bij korte prompts.
De sleutel is het opzetten van een gelaagde schalingsstrategie: begin met verticaal schalen door GPU's met meer HBM-geheugen en hogere bandbreedte te kiezen, en ga daarna horizontaal schalen met meerdere GPU's per node of meerdere nodes. Gebruik een inferentie-framework zoals vLLM of TensorRT-LLM dat efficiënt omgaat met KV-cache-beheer en dynamisch batchen ondersteunt. Door van tevoren je verwachte piekbelasting en modelgrootte te kennen, kun je hardware kiezen die ruimte laat voor groei in plaats van meteen tegen de grenzen aan te lopen.
Absoluut. Frameworks zoals vLLM, TensorRT-LLM en Triton Inference Server benutten hardwaremogelijkheden zoals paged attention, continue batching en geoptimaliseerde CUDA-kernels die de effectieve geheugenbandbreedte en GPU-bezetting aanzienlijk verbeteren. Een krachtige GPU presteert aanzienlijk slechter onder een ongeoptimaliseerd framework dan onder een framework dat specifiek is afgestemd op die hardware. Kies hardware en software altijd als een gecombineerd systeem en valideer de combinatie met een benchmark op jouw eigen workload.
Den Sliem 89
7141 JG Groenlo
The Netherlands
+31 544 470 000
info@ncs.nl