22 april 2026
Voor real-time inferentie van een taalmodel heb je minimaal 16 GB VRAM nodig voor kleinere modellen (7B parameters in INT4), maar in de praktijk is 24 tot 80 GB VRAM realistischer voor productieomgevingen. Hoe meer parameters een model heeft en hoe hoger de precisie, hoe meer VRAM je nodig hebt. Een 70B-model in FP16 vraagt al snel meer dan 140 GB VRAM, wat meerdere GPU’s vereist. De juiste hoeveelheid hangt af van de modelgrootte, kwantisatie en de gewenste doorvoersnelheid.
VRAM is het geheugen op een GPU dat tijdelijk data opslaat tijdens berekeningen. Voor taalmodellen betekent dit dat de gewichten van het model, de activaties tijdens inferentie en de KV-cache voor aandachtsmechanismen allemaal tegelijk in dit geheugen moeten passen. Als dat niet lukt, vertraagt het systeem drastisch of stopt het volledig.
Bij inferentie van grote taalmodellen zijn de geheugenbehoeften aanzienlijk groter dan bij traditionele machinelearningtaken. Een LLM werkt met miljarden parameters die elk een bepaalde hoeveelheid geheugen innemen, afhankelijk van de gehanteerde precisie. Daarnaast groeit de KV-cache mee met de lengte van de context, wat betekent dat langere gesprekken of documenten extra VRAM vragen. Onvoldoende VRAM leidt direct tot tragere responsen, wat bij real-time toepassingen onacceptabel is.
Het verschil met RAM in een gewone server is dat GPU-geheugen veel sneller is en direct toegankelijk is voor de rekenkern van de GPU. Zodra modelgewichten naar het CPU-RAM worden uitgewisseld, verlies je een groot deel van de prestatievoordelen van GPU-acceleratie. Voor productie-inferentie wil je daarom altijd het volledige model in VRAM houden.
De minimale VRAM-behoefte hangt direct af van het aantal parameters en de gebruikte precisie. Als vuistregel geldt: elk miljard parameters kost ongeveer 2 GB VRAM in FP16. Een model van 7B parameters heeft daarmee minimaal 14 GB VRAM nodig in FP16, en met kwantisatie naar INT4 kom je uit op ongeveer 4 tot 5 GB.
Hier is een praktisch overzicht van veelgebruikte modelgroottes:
Houd er rekening mee dat deze cijfers alleen de modelgewichten betreffen. In de praktijk komt daar nog de KV-cache bij, die afhankelijk is van de contextlengte en het aantal gelijktijdige verzoeken. Voor een productiesysteem met meerdere gebruikers reken je daarom altijd een buffer van 20 tot 30 procent boven op de theoretische minimumwaarde.
FP16, INT8 en INT4 zijn numerieke precisieniveaus voor het opslaan van modelgewichten. FP16 (16-bit floating point) biedt de hoogste nauwkeurigheid, maar vraagt het meeste geheugen. INT8 halveert het geheugengebruik ten opzichte van FP16 met minimaal kwaliteitsverlies. INT4 halveert het opnieuw, maar vraagt meer aandacht voor de impact op de modelkwaliteit.
FP16 is de standaardprecisie voor inferentie in productieomgevingen waar kwaliteit prioriteit heeft. Moderne GPU’s zoals de Nvidia H100 en H200 zijn specifiek geoptimaliseerd voor FP16-berekeningen via Tensor Cores. De output is nagenoeg identiek aan de originele modelkwaliteit, wat FP16 de voorkeur geeft voor kritische toepassingen zoals medische of juridische tekstgeneratie.
INT8-kwantisatie is inmiddels goed ingeburgerd en levert in de meeste gevallen vergelijkbare resultaten als FP16, met de helft van het geheugengebruik. Bibliotheken zoals bitsandbytes en GPTQ maken INT8-inferentie toegankelijk zonder complexe aanpassingen. INT4 gaat een stap verder en is interessant wanneer je een groot model op beperkte hardware wilt draaien, maar de kwaliteitsimpact varieert per model en taak. Voor eenvoudige taken is INT4 prima; voor complexe redeneervaardigheden merk je het verschil sneller.
De meest geschikte GPU’s voor real-time LLM-inferentie zijn de Nvidia H100, H200, A100 en, in de consumentenklasse, de RTX 4090 en RTX 6000 Ada. De keuze hangt af van de vereiste VRAM, doorvoersnelheid en het budget. Voor zakelijke productieomgevingen zijn de H-serie en A100 de standaard vanwege hun grote VRAM-capaciteit en hoge bandbreedte.
Naast VRAM is geheugenbandbreedte een bepalende factor. Hogere bandbreedte betekent dat gewichten sneller van het GPU-geheugen naar de rekenkern stromen, wat direct de tokens-per-seconde-snelheid bepaalt. De H100 en H200 blinken hier uit dankzij HBM-geheugen, dat aanzienlijk sneller is dan GDDR6.
Multi-GPU-inferentie is de juiste keuze wanneer een model niet in het VRAM van één enkele GPU past, of wanneer de doorvoersnelheid van één GPU onvoldoende is voor de vereiste belasting. Bij modellen groter dan 70B parameters in FP16 is multi-GPU-inferentie nagenoeg altijd noodzakelijk.
Er zijn twee hoofdstrategieën voor het verdelen van een model over meerdere GPU’s. Tensorparallelisme verdeelt individuele lagen horizontaal over GPU’s en vereist snelle interconnects zoals NVLink om communicatievertraging te minimaliseren. Pipelineparallelisme verdeelt het model verticaal in lagen per GPU, wat minder bandbreedte vraagt maar meer latentie introduceert. Voor real-time inferentie met lage latentie is tensorparallelisme met NVLink de voorkeursmethode.
Houd bij multi-GPU-setups rekening met de communicatieoverhead tussen GPU’s. Zonder NVLink of vergelijkbare hogesnelheidsinterconnects kan de verbinding tussen GPU’s een knelpunt worden dat de voordelen van extra GPU’s gedeeltelijk tenietdoet. Systemen met een NVLink Switch, zoals de DGX H100, zijn specifiek ontworpen om dit probleem te omzeilen.
De benodigde VRAM bereken je door drie componenten op te tellen: de geheugenvoetafdruk van de modelgewichten, de KV-cache voor de maximale contextlengte en een buffer voor activaties en overhead. Samen bepalen deze drie factoren het minimale VRAM-vereiste voor jouw specifieke situatie.
Stap voor stap ziet de berekening er zo uit:
Stel dat je een 13B-model wilt draaien in INT8 met een contextvenster van 4096 tokens en 8 gelijktijdige verzoeken. De gewichten kosten circa 13 GB, de KV-cache voegt afhankelijk van de architectuur 4 tot 8 GB toe, en de overhead brengt je op een totaal van 20 tot 25 GB. Een GPU met 24 GB VRAM zit dan aan zijn limiet; 48 GB geeft je comfortabele ruimte voor schaalbaarheid.
Voor LLM-inferentieserverhardware zijn Supermicro GPU-servers de meest gebruikte platforms in professionele omgevingen. Systemen als de Supermicro SYS-821GE-TNHR en de X13 GPU-serie bieden ondersteuning voor meerdere Nvidia H100- of H200-GPU’s, hoge geheugenbandbreedte en NVLink-connectiviteit voor multi-GPU-configuraties.
Bij de keuze van een serverplatform voor inferentie let je op de volgende punten:
Supermicro heeft als voordeel dat het nieuwe Nvidia GPU-generaties als eerste ondersteunt, ruim voordat andere fabrikanten hun platforms hebben aangepast. Dat is relevant als je wilt werken met de nieuwste hardware zodra die beschikbaar komt. Bij ons, NCS International, configureren we Supermicro-inferentieservers volledig op maat voor jouw workload, van de GPU-selectie tot de opslagarchitectuur en koeling. Als grootste en oudste Supermicro-distributeur in Nederland helpen we je de juiste hardware te kiezen voor jouw specifieke inferentie-use case, of het nu gaat om een single-GPU-systeem of een multi-rack inferentiecluster.
Ja, CPU-inferentie is technisch mogelijk via frameworks zoals llama.cpp, maar de snelheid is aanzienlijk lager dan bij GPU-inferentie. Voor real-time toepassingen met gebruikers die directe respons verwachten, is CPU-inferentie in de meeste gevallen onpraktisch. Het kan wel zinvol zijn voor kleinere modellen in kwantisatieformaten zoals INT4 op krachtige multi-core servers, bijvoorbeeld als tijdelijke oplossing of voor lage-doorvoer batchverwerking.
Als een model niet volledig in VRAM past, kun je gebruikmaken van technieken zoals offloading, waarbij een deel van de modellagen naar CPU-RAM of zelfs NVMe-opslag wordt verplaatst. Frameworks zoals DeepSpeed en llama.cpp ondersteunen dit. Het nadeel is een significante prestatievermindering door de tragere geheugenbandbreedte van RAM en NVMe ten opzichte van VRAM. Dit is acceptabel voor ontwikkeling of experimenten, maar niet voor productie-inferentie met lage latentie.
De contextlengte heeft een directe en niet-lineaire impact op de KV-cache, die meegroeit met elk extra token in de invoer en uitvoer. Bij lange documenten, uitgebreide gesprekken of RAG-toepassingen (Retrieval-Augmented Generation) kan de KV-cache snel een groot deel van de beschikbare VRAM opslokken. Als je regelmatig werkt met contextvensters van 32.000 tokens of meer, moet je dit zwaar meewegen in je VRAM-berekening — de KV-cache kan in zulke gevallen groter worden dan de modelgewichten zelf.
Voor productie-inferentie zijn vLLM, TensorRT-LLM van Nvidia en Triton Inference Server de meest gebruikte en betrouwbare opties. vLLM is populair vanwege zijn efficiënte PagedAttention-mechanisme, dat de KV-cache dynamisch beheert en de doorvoer significant verhoogt. TensorRT-LLM is geoptimaliseerd voor Nvidia-hardware en biedt de hoogste tokens-per-seconde-prestaties op H100- en H200-GPU's. De keuze hangt af van je prioriteiten: flexibiliteit, maximale prestaties of eenvoud van implementatie.
Bij LLM-inferentie is het systeem vrijwel altijd geheugenbandbreedte-gebonden (memory-bound) in plaats van compute-gebonden, zeker bij lage batchgroottes. Dit betekent dat de snelheid waarmee gewichten van het GPU-geheugen naar de rekenkern worden geladen de beperkende factor is, niet de rekenkracht zelf. Je kunt dit meten met tools zoals Nvidia Nsight Systems of nvidia-smi: als het GPU-gebruik laag is terwijl de geheugenbandbreedte verzadigd is, zit je in het memory-bound regime. Grotere batchgroottes helpen de GPU-benutting te verbeteren.
Een veelgemaakte fout is het onderschatten van de KV-cache en overhead, waardoor de server bij hogere belasting alsnog vastloopt of sterk vertraagt. Een andere valkuil is investeren in veel GPU's zonder te letten op de interconnectbandbreedte, waardoor multi-GPU-communicatie een knelpunt wordt. Tot slot zien we regelmatig dat teams kiezen voor maximale kwantisatie (INT4) zonder de kwaliteitsimpact te testen op hun specifieke taak, wat pas in productie zichtbaar wordt als een probleem.
Horizontale schaling — het toevoegen van extra inferentieservers achter een load balancer — is de meest flexibele aanpak voor groeiend gebruikersvolume. Hierbij draait elk knooppunt een volledige kopie van het model, wat eenvoudig te beheren is en geen NVLink vereist tussen servers. Voor modellen die al meerdere GPU's per instantie vereisen, combineer je verticale schaling (meer GPU's per server) met horizontale schaling (meer servers). Zorg dat je serverplatform voldoende GPU-slots heeft om mee te groeien zonder de hele infrastructuur te hoeven vervangen.
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.
