15 mei 2026
Het optimaliseren van throughput op een LLM-inferenceserver met meerdere GPU’s doe je door batchgrootte, geheugenbandbreedte en softwarestack slim op elkaar af te stemmen. De grootste winst haal je uit het maximaal benutten van het GPU-geheugen via efficiënte batching, het kiezen van een geoptimaliseerde inference-engine zoals vLLM of TensorRT-LLM, en het verminderen van communicatie-overhead tussen GPU’s. Zorg er daarnaast voor dat je hardware de geheugenbandbreedte levert die jouw modelgrootte vereist. Hieronder vind je per onderwerp een concreet antwoord.
Throughput bij LLM-inferentie is het aantal tokens dat een server per seconde genereert over alle actieve verzoeken heen. Hoe hoger de throughput, hoe meer gebruikers of processen je tegelijkertijd kunt bedienen met dezelfde hardware. Dit maakt throughput tot de belangrijkste maatstaf voor de kostenefficiëntie van een inference-omgeving.
Latency en throughput zijn twee verschillende dingen. Latency meet hoe snel een enkel verzoek een antwoord krijgt. Throughput meet hoeveel werk de server in totaal verzet. In productieomgevingen met veel gelijktijdige gebruikers, zoals een interne AI-assistent of een API-dienst, is throughput de bepalende factor voor schaalbaarheid. Een lage throughput betekent dat je meer hardware nodig hebt voor hetzelfde aantal gebruikers, wat de operationele kosten sterk opdrijft.
Op een multi-GPU-inferenceserver verdeel je het model over meerdere GPU’s via tensor parallelism of pipeline parallelism. Bij tensor parallelism splits je individuele lagen van het model op over GPU’s, zodat elke GPU een deel van de berekening uitvoert. Bij pipeline parallelism wijs je verschillende lagen toe aan verschillende GPU’s, die het werk sequentieel doorgeven.
Tensor parallelism is de meest gebruikte aanpak voor grote taalmodellen omdat het de latency per verzoek laag houdt. De GPU’s communiceren tijdens elke forward pass via high-speed interconnects zoals NVLink of InfiniBand. Hoe sneller die verbinding, hoe minder overhead de communicatie veroorzaakt. Bij modellen die niet op één GPU passen, is multi-GPU-inferentie geen keuze maar een noodzaak.
De drie grootste knelpunten voor GPU-throughput bij LLM-inferentie zijn geheugenbandbreedte, communicatie-overhead tussen GPU’s en inefficiënte benutting van de KV-cache. Elk van deze factoren kan de prestaties sterk beperken, ook als de rekenkracht van de GPU’s op papier ruim voldoende lijkt.
LLM-inferentie is memory-bound, niet compute-bound. De GPU besteedt meer tijd aan het laden van modelgewichten uit het geheugen dan aan het uitvoeren van berekeningen. Een GPU met hoge rekenkracht maar beperkte geheugenbandbreedte presteert daardoor slechter dan je op basis van TFLOPS zou verwachten.
De KV-cache slaat tussenliggende berekeningen op voor elke token in een context. Naarmate contextlengtes groeien, groeit ook de KV-cache snel in omvang. Als de cache niet efficiënt wordt beheerd, verspil je GPU-geheugen dat je anders voor grotere batches had kunnen gebruiken. Communicatie tussen GPU’s via PCIe is bovendien aanzienlijk langzamer dan via NVLink, wat bij grote modellen een merkbaar effect heeft op de totale throughput.
De optimale batchgrootte voor maximale throughput is de grootste batch waarbij de GPU-geheugenbenutting net onder de limiet blijft, zonder dat de KV-cache overloopt. Grotere batches verhogen de throughput omdat de GPU meer verzoeken parallel verwerkt, maar te grote batches leiden tot geheugenfouten of sterk verhoogde latency per verzoek.
Moderne inference-engines zoals vLLM gebruiken continuous batching, waarbij nieuwe verzoeken worden toegevoegd aan een lopende batch zodra er ruimte vrijkomt. Dit is efficiënter dan statische batching, waarbij je wacht tot een volledige batch klaar is. Met continuous batching benut je het GPU-geheugen dynamisch en vermijd je onnodige wachttijd. Begin met een conservatieve batchgrootte en verhoog die stapsgewijs terwijl je GPU-geheugengebruik en throughput monitort via tools als nvidia-smi of de ingebouwde metrics van je inference-engine.
Voor multi-GPU LLM-inferentie leveren vLLM, TensorRT-LLM en DeepSpeed-MII doorgaans de beste prestaties. vLLM is populair vanwege PagedAttention, een techniek die het KV-cachegeheugen efficiënter beheert. TensorRT-LLM van NVIDIA biedt de sterkste optimalisatie specifiek voor NVIDIA-GPU’s en ondersteunt geavanceerde kwantisatietechnieken. DeepSpeed-MII is sterk bij zeer grote modellen met pipeline parallelism.
Gebruik vLLM als je snel wilt starten met een open-sourceoplossing die breed wordt ondersteund en regelmatig wordt bijgewerkt. Kies TensorRT-LLM als je maximale prestaties wilt op NVIDIA-hardware en bereid bent te investeren in een iets complexere opzet. Voor modellen van 70B parameters en groter, verspreid over meerdere nodes, is DeepSpeed-MII een sterke optie.
Vergeet ook de CUDA-versie en drivercompatibiliteit niet. Een mismatch tussen driver, CUDA-toolkit en inference-framework is een veelvoorkomende oorzaak van prestatieproblemen die niets met de hardware te maken hebben.
GPU-geheugenbandbreedte bepaalt direct hoe snel modelgewichten vanuit VRAM naar de rekenkern worden geladen. Omdat LLM-inferentie memory-bound is, geldt: hogere bandbreedte leidt rechtstreeks tot een hogere token-generatiesnelheid. Een GPU met HBM-geheugen, zoals de H100 of H200, presteert bij inferentie daardoor aanzienlijk beter dan een GPU met GDDR-geheugen bij vergelijkbare rekenkracht.
Bij grotere modellen wordt dit effect sterker. Een model van 70B parameters heeft per forward pass enorme hoeveelheden data uit het geheugen nodig. Als de bandbreedte beperkt is, wacht de GPU constant op data en benut hij zijn rekencapaciteit maar gedeeltelijk. Kwantisatie, waarbij je modelgewichten van FP16 naar INT8 of INT4 verkleint, vermindert de hoeveelheid data die geladen moet worden en verhoogt daarmee de effectieve throughput zonder extra hardware.
De meest geschikte hardware voor een multi-GPU LLM-inferenceserver combineert GPU’s met hoge geheugenbandbreedte en grote VRAM-capaciteit, snelle GPU-interconnects zoals NVLink, en voldoende CPU- en systeemgeheugen om batches efficiënt voor te bereiden. NVIDIA H100- en H200-GPU’s zijn momenteel de referentie voor productie-inferentie, mede door hun HBM3-geheugen en NVLink 4.0-ondersteuning.
De keuze voor het juiste platform hangt af van modelgrootte, het aantal gelijktijdige gebruikers en je schaalbaarheidsambities. Voor kleinere modellen tot 13B parameters volstaan GPU’s met 24 of 48 GB VRAM per kaart. Voor modellen van 70B en groter heb je meerdere GPU’s met 80 GB of meer nodig, of pas je kwantisatie toe om binnen de geheugenlimiet te blijven.
Bij het samenstellen van een multi-GPU-inferenceserver speelt ook de serverarchitectuur een grote rol. Een platform dat meerdere GPU’s via NVLink verbindt en voldoende PCIe-bandbreedte biedt voor storage en netwerk, maakt het verschil tussen een systeem dat zijn GPU’s volledig benut en een systeem dat constant op data wacht.
Wij bij NCS International leveren Supermicro-servers die speciaal zijn ontworpen voor veeleisende GPU-werklasten, waaronder LLM-inferentie. Supermicro ondersteunt nieuwe NVIDIA-GPU-generaties als een van de eersten wereldwijd, wat betekent dat je bij ons toegang hebt tot de nieuwste hardware voordat andere merken die mogelijkheid bieden. We configureren elk systeem volledig op maat, van het aantal GPU’s en de interconnecttopologie tot opslag en koeling. Bekijk onze serveroplossingen voor AI en inferentie voor een overzicht van wat wij voor jouw infrastructuur kunnen betekenen.
Monitor tijdens een inferentie-run de GPU-bezetting via nvidia-smi of tools zoals Nsight Systems. Als de GPU-bezetting (GPU utilization) hoog is maar de throughput tegenvalt, is geheugenbandbreedte vrijwel zeker de beperkende factor. Een lage GPU-bezetting in combinatie met lage throughput wijst eerder op inefficiënte batching of communicatie-overhead tussen GPU's. Door beide metrics gelijktijdig te bekijken krijg je snel een duidelijk beeld van waar de echte knelpunten zitten.
Een veelgemaakte fout is het negeren van CUDA- en drivercompatibiliteit tussen het inference-framework en de geïnstalleerde GPU-drivers, wat tot onverklaarbare prestatieproblemen leidt. Een tweede veelvoorkomende fout is het kiezen van PCIe-verbindingen tussen GPU's in plaats van NVLink, waardoor communicatie-overhead de winst van extra GPU's grotendeels tenietdoet. Tot slot onderschatten veel teams de impact van de KV-cache: zonder goed geheugenbeheer (zoals PagedAttention in vLLM) verspil je kostbare VRAM die je voor grotere batches had kunnen inzetten.
Kwantisatie van FP16 naar INT8 of INT4 verhoogt de throughput aanzienlijk doordat er minder data uit het geheugen geladen hoeft te worden, en het stelt je in staat grotere modellen binnen je VRAM-limiet te draaien. Het nadeel is een potentiële afname van modelkwaliteit, die per model en per kwantisatiemethode sterk verschilt. Moderne technieken zoals GPTQ en AWQ minimaliseren dit kwaliteitsverlies, maar het is verstandig om de uitvoerkwaliteit van je gekwantiseerde model altijd te evalueren op jouw specifieke use case voordat je het in productie neemt.
De meest praktische aanpak is horizontale schaling: voeg extra inferentieservers toe achter een load balancer die inkomende verzoeken verdeelt over meerdere instanties. Dit is eenvoudiger te beheren dan het uitbreiden van één enkele server en biedt ook redundantie bij hardware-uitval. Voor modellen die al over meerdere GPU's verdeeld zijn, kun je ook kijken naar het verhogen van het aantal parallelle instanties per server via meerdere tensor-parallelism-groepen, mits je VRAM dit toelaat.
Absoluut. De modelgrootte in parameters bepaalt direct hoeveel VRAM je nodig hebt, en de architectuur van het model (bijvoorbeeld het aantal attention heads en de context window) beïnvloedt hoe snel de KV-cache groeit. Een model van 7B parameters in FP16 past op een enkele GPU met 24 GB VRAM, terwijl een model van 70B parameters minimaal vier GPU's van 80 GB vereist zonder kwantisatie. Het is daarom verstandig om je hardwareconfiguratie altijd te baseren op het specifieke model dat je wilt draaien, inclusief de verwachte gemiddelde en maximale contextlengte.
Open-source modellen zoals LLaMA 3 en Mistral draaien uitstekend op multi-GPU-servers en profiteren volop van tensor parallelism en continuous batching in engines als vLLM. Voor de grotere varianten, zoals LLaMA 3 70B of 405B, is een multi-GPU-setup zelfs noodzakelijk. vLLM heeft native ondersteuning voor de meeste populaire open-source architecturen en is daarmee een logische keuze als startpunt voor productie-inferentie met deze modellen.
Als je huidige GPU's al memory-bound zijn en de communicatie-overhead tussen GPU's beperkt is, levert een upgrade naar GPU's met hogere geheugenbandbreedte (zoals van A100 naar H100) meer throughput per GPU dan het toevoegen van extra kaarten. Als je model al efficiënt gebruik maakt van de beschikbare bandbreedte maar je wilt meer gelijktijdige gebruikers bedienen, is horizontale schaling met meer GPU's of servers de betere keuze. Een goede manier om dit te bepalen is het meten van de Memory Bandwidth Utilization (MBU) van je huidige setup: zit je boven de 70-80%, dan is sneller geheugen de prioriteit.
Den Sliem 89
7141 JG Groenlo
The Netherlands
+31 544 470 000
info@ncs.nl
GPU-servers verwerken duizenden berekeningen parallel — ontdek wanneer ze onmisbaar zijn voor jouw organisatie.
Wat is een AI-server en wanneer heb je er een nodig? Ontdek de techniek, hardware en toepassingen.
