23 april 2026
KV-cache-geheugen bepaalt in grote mate hoe snel en efficiënt een taalmodel reageert tijdens inferentie. Zonder een goed werkende KV-cache moet een GPU bij elke nieuwe token alle voorgaande berekeningen opnieuw uitvoeren, wat de latentie flink verhoogt. De KV-cache slaat tussenresultaten op, zodat dat niet nodig is. Hoe groter het model en hoe langer de context, hoe meer GPU-geheugen de KV-cache vraagt. Dit artikel legt uit wat de KV-cache precies is, waarom die zo belangrijk is voor LLM-inferentie en welke hardwarekeuzes er echt toe doen.
KV-cache staat voor key-valuecache en is een geheugenstructuur die tijdens LLM-inferentie de berekende sleutel- en waardevectoren uit het attentionmechanisme van een transformermodel opslaat. In plaats van deze vectoren bij elke nieuwe token opnieuw te berekenen, haalt de GPU ze op uit de cache. Dit versnelt het genereren van tekst aanzienlijk, vooral bij lange gesprekken of documenten.
Elke keer dat een taalmodel een token genereert, kijkt het attentionmechanisme terug naar alle eerdere tokens in de context. Die terugblik vereist de sleutel- en waardevectoren van al die eerdere tokens. Zonder cache betekent dat steeds meer rekenwerk naarmate de context langer wordt. Met een KV-cache sla je die vectoren eenmalig op en gebruik je ze herhaaldelijk, wat de verwerkingstijd per token drastisch verlaagt.
De KV-cache heeft directe invloed op twee van de belangrijkste prestatie-indicatoren bij LLM-inferentie: time to first token (TTFT) en tokens per seconde (TPS). Zonder cache schaalt de rekentijd kwadratisch met de contextlengte. Met een volledige KV-cache blijft de rekentijd per token nagenoeg constant, ongeacht hoe lang de context al is.
Dit is vooral relevant bij toepassingen met lange contexten, zoals het samenvatten van documenten, meertalige assistenten of chatbots die lange gesprekken bijhouden. In die gevallen kan het verschil tussen een systeem met en zonder effectieve KV-cache oplopen tot een factor tien in latentie. Voor productieomgevingen waar meerdere gebruikers tegelijkertijd verzoeken sturen, is een goed gecachte inferentiestack het verschil tussen een responsieve service en een die vastloopt.
Het geheugengebruik van een KV-cache hangt af van vier factoren: het aantal attentionlagen in het model, het aantal attentionheads, de dimensie per head en de contextlengte. Voor grote modellen met lange contexten kan de KV-cache al snel tientallen gigabytes aan GPU-geheugen innemen, soms meer dan de modelgewichten zelf.
Een praktisch voorbeeld: een model met 32 lagen, 32 heads en een head-dimensie van 128, dat een context van 8.000 tokens verwerkt in float16-precisie, heeft al gauw 4 tot 8 GB aan KV-cache nodig per verzoek. Bij meerdere gelijktijdige gebruikers vermenigvuldigt dat zich direct. Dit maakt geheugenplanning voor LLM-inferentieserverhardware een serieuze uitdaging die je vooraf goed moet doorrekenen.
Modelgewichten zijn statisch: ze worden eenmalig geladen bij het opstarten van het model en blijven ongewijzigd tijdens inferentie. De KV-cache is dynamisch: hij groeit mee met elke gegenereerde token en varieert per gebruiker en per sessie. Beide concurreren om hetzelfde GPU-geheugen, maar ze gedragen zich fundamenteel anders.
Modelgewichten voor een model van 70 miljard parameters in float16 nemen al gauw 140 GB aan VRAM in beslag. Dat is een vaste, voorspelbare last. De KV-cache daarentegen is variabel en afhankelijk van het aantal actieve verzoeken en de lengte van de context. In de praktijk betekent dit dat je bij het kiezen van GPU-hardware niet alleen naar de modelgrootte kijkt, maar ook naar hoeveel ruimte er overblijft voor de KV-cache bij de verwachte belasting.
Er zijn meerdere technieken die het geheugengebruik van de KV-cache actief terugbrengen zonder grote concessies aan kwaliteit. De bekendste zijn kwantisatie van de cache, grouped query attention (GQA) en paged attention, zoals geïmplementeerd in frameworks als vLLM.
Welke techniek het beste werkt, hangt af van je model, je framework en je latentievereisten. In de meeste productieomgevingen combineer je meerdere van deze technieken.
Voor LLM-inferentie met grote KV-caches zijn drie GPU-specificaties het meest bepalend: de totale VRAM-capaciteit, de geheugenbandbreedte en de ondersteuning voor hogere precisieniveaus zoals float16 en bfloat16.
VRAM-capaciteit bepaalt hoeveel modelgewichten én KV-cache je tegelijkertijd kunt laden. Geheugenbandbreedte bepaalt hoe snel je die cache kunt uitlezen tijdens het genereren van tokens. Een GPU met veel VRAM maar lage bandbreedte wordt een knelpunt bij hoge doorvoer. Nvidia H100- en H200-GPU’s combineren grote VRAM-capaciteit met HBM3-geheugen en zeer hoge bandbreedte, wat ze populair maakt voor veeleisende LLM-inferentieserverhardware. De nieuwere B300-generatie zet die lijn voort met nog meer capaciteit en bandbreedte per GPU.
Daarnaast speelt NVLink een rol bij multi-GPU-set-ups: het maakt het mogelijk om de KV-cache over meerdere GPU’s te verdelen zonder de bandbreedte te verliezen die je bij PCIe-verbindingen wel kwijtraakt.
De juiste GPU-server voor LLM-inferentie met grote KV-caches kies je op basis van vier criteria: de totale VRAM die je nodig hebt voor modelgewichten plus KV-cache bij piekbelasting, de geheugenbandbreedte, de schaalbaarheid via NVLink of multi-GPU-configuraties en de ondersteuning voor de nieuwste Nvidia-GPU-generaties.
Begin met het doorrekenen van je geheugenbudget. Bepaal de modelgrootte in geheugen, schat het verwachte aantal gelijktijdige verzoeken en de gemiddelde contextlengte, en bereken de KV-cache per verzoek. Dat totaal vertelt je hoeveel VRAM je minimaal nodig hebt. Voeg daar een buffer bovenop voor het framework, activaties en overhead.
Vervolgens kijk je naar schaalbaarheid. Heb je vandaag een model van 7 miljard parameters, maar wil je over zes maanden naar 70 miljard? Dan kies je een serverplatform dat meerdere GPU’s ondersteunt en eenvoudig uitbreidbaar is. Bedenk ook of je inferentie op één locatie uitvoert of verdeeld over meerdere nodes.
Bij ons, NCS International, helpen we je precies dit soort afwegingen te maken. Als de grootste en oudste Supermicro-distributeur van Nederland leveren wij GPU-servers die volledig zijn afgestemd op jouw workload, van de juiste GPU-configuratie tot de bijpassende opslag- en netwerkarchitectuur. Supermicro ondersteunt nieuwe Nvidia-GPU-generaties eerder dan merken als HP en Dell, wat betekent dat je bij ons als eerste toegang hebt tot de nieuwste hardware voor LLM-inferentie. Bekijk onze serveroplossingen voor AI-inferentie en GPU-workloads en ontdek welke configuratie het beste past bij jouw situatie.
Een veelvoorkomend signaal is dat de latentie sterk oploopt naarmate gesprekken langer worden, terwijl de GPU-rekenbelasting (compute utilization) relatief laag blijft. Dit wijst erop dat de bottleneck niet in de rekenkracht zit, maar in de geheugenbandbreedte of VRAM-capaciteit. Tools zoals Nvidia Nsight Systems of de ingebouwde monitoring van frameworks als vLLM kunnen je helpen om geheugengebruik en bandbreedte per verzoek inzichtelijk te maken.
Als de beschikbare VRAM voor de KV-cache is uitgeput, heeft het systeem verschillende opties: het verzoek weigeren, oudere cache-items verwijderen (eviction), of de cache gedeeltelijk naar CPU-geheugen of opslag offloaden. Dit laatste verhoogt de latentie aanzienlijk, omdat CPU-naar-GPU-datatransfer veel trager is dan directe VRAM-toegang. Het is daarom belangrijk om bij het dimensioneren van je server altijd een realistische piekbelasting te hanteren en niet alleen het gemiddelde gebruik.
In de meeste productieomgevingen is int8-kwantisatie van de KV-cache veilig en leidt het tot verwaarloosbare kwaliteitsvermindering, zeker bij grotere modellen. Int4-kwantisatie is agressiever en kan bij bepaalde taken of modellen merkbare degradatie veroorzaken, met name bij complexe redeneeruitgaven. Het advies is om kwantisatie altijd te valideren met een representatieve benchmark op jouw specifieke use case voordat je het volledig in productie uitrolt.
Ja, dit is mogelijk via een techniek die prefix caching (of prompt caching) wordt genoemd. Als meerdere verzoeken dezelfde systeemprompt of gedeelde context hebben, kan de KV-cache voor dat gedeelte eenmalig worden berekend en hergebruikt worden voor alle verzoeken. Frameworks zoals vLLM en SGLang ondersteunen dit natively en het kan de effectieve cache-efficiëntie bij veel gelijktijdige gebruikers sterk verbeteren, met name in applicaties met een vaste systeemprompt.
Bij een enkelvoudige GPU is de KV-cache volledig lokaal in de VRAM van die GPU, wat de laagste latentie geeft. Bij multi-GPU-inferentie via tensor parallelism wordt de KV-cache verdeeld over meerdere GPU's, wat de totale capaciteit vergroot maar ook communicatie-overhead introduceert. NVLink minimaliseert die overhead aanzienlijk ten opzichte van PCIe, waardoor multi-GPU-setups met NVLink in de praktijk goed schalen voor grote modellen met hoge KV-cache-eisen.
De meest voorkomende fout is het dimensioneren op basis van alleen de modelgewichten, zonder rekening te houden met de KV-cache bij piekbelasting. Teams laden een model van 70 miljard parameters op een server met 140 GB VRAM, zien dat het model past, en ontdekken vervolgens dat er bij tien gelijktijdige gebruikers met lange contexten nauwelijks ruimte overblijft voor de cache. De oplossing is altijd vooraf een volledig geheugenbudget te berekenen: modelgewichten + KV-cache per verzoek × verwacht aantal gelijktijdige verzoeken + framework-overhead.
De keuze van framework heeft grote invloed op hoe efficiënt de KV-cache wordt beheerd. vLLM staat bekend om zijn paged attention-implementatie die fragmentatie minimaliseert en hoge throughput mogelijk maakt. TensorRT-LLM van Nvidia is sterk geoptimaliseerd voor Nvidia-hardware en biedt geavanceerde kwantisatie-opties voor de cache. Text Generation Inference (TGI) van Hugging Face is gebruiksvriendelijker maar biedt minder fijnmazige controle. Voor veeleisende productieomgevingen met hoge gelijktijdigheid en lange contexten is vLLM of TensorRT-LLM doorgaans de betere keuze.
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.
