KV Cache

Wat is een KV Cache?

De KV-cache is het geheugen waar een transformer-taalmodel de attention-keys en -values opslaat die het al berekend heeft voor eerdere tokens. Door ze te hergebruiken genereert het model elk nieuw token zonder de hele input opnieuw te verwerken, wat token-voor-token-generatie snel maakt en lange contexten duur in geheugen.

De belangrijkste punten

• Zonder KV-cache zou elk gegenereerd token attention over de hele sequentie opnieuw moeten berekenen; met cache wordt elke stap alleen het nieuwste token verwerkt.
• KV-cachegrootte groeit lineair met contextlengte, en bij lange contexten kan het wedijveren met of het geheugen gebruikt door de modelgewichten zelf overtreffen.
• Prompt caching, de API-functie die herhaalde promptprefixen verdisconteert, is KV-cache-hergebruik over verzoeken heen, en het is de belangrijkste kostenhendel voor agentworkloads.
• Cache-vriendelijk promptontwerp, stabiele prefixen met variabele content aan het einde, verlaagt direct zowel latentie als uitgave.

Hoe het werkt

Het attention-mechanisme van een transformer laat elk token terugkijken naar elk eerder token. Om dat te doen berekent het model een key- en value-vector voor elk token op elke laag. Tijdens generatie veranderen deze niet zodra berekend: token 500 geeft aandacht aan dezelfde keys en values voor tokens 1 tot en met 499 die berekend werden toen die tokens verwerkt werden. Ze cachen is dus pure winst. De generatielus splitst zich in twee fasen: prefill, waar het model de hele prompt parallel opneemt en de cache vult, en decode, waar het één token tegelijk afgeeft, waarbij elke stap keys en values alleen voor het nieuwste token berekent en al het andere uit de cache leest. Prefill is compute-gebonden en bepaalt time to first token; decode is geheugenbandbreedte-gebonden en bepaalt tokens per seconde.

De kosten van deze snelheid zijn geheugen. Cachegrootte schaalt met lagen, attention-heads, head-dimensie, en bovenal sequentielengte, dus kan een sessie met een zeer lang contextvenster tientallen gigabytes cache per verzoek eisen. Veel van moderne inferentie-engineering is KV-cachebeheer: grouped-query-attention en multi-head-latent-attention verkleinen wat opgeslagen moet worden, paged attention wijst cache toe in blokken zodat servers geen gereserveerd geheugen verspillen, cachekwantisering slaat keys en values op met lagere precisie, en uitzettingsschema's laten oude items vallen wanneer geheugen opraakt. De verspilling die bestreden wordt is substantieel: het vLLM-team mat dat pre-PagedAttention-servingsystemen 60-80% van het KV-cachegeheugen verloren aan fragmentatie en overreservering, wat hun paged-ontwerp verlaagt tot bijna nul [1]. De PagedAttention-paper van UC Berkeley meldt 2-4x hogere servingdoorvoer dan eerdere state-of-the-art-systemen zoals FasterTransformer en Orca bij dezelfde latentie [2]. Over verzoeken heen hergebruiken aanbieders gecachete prefixen, verkocht aan developers als prompt caching met grote input-tokenkortingen voor het hergebruikte deel.

Voorbeeld

Een agentplatformteam merkt dat de rekening van hun coding-agent gedomineerd wordt door inputtokens: elke beurt verstuurt hetzelfde prefix van 30.000 tokens systeemprompt, tooldefinities, en repoconventies opnieuw, gevolgd door het groeiende gesprek. Omdat het prefix byte-identiek is over beurten heen, bedient de cache van de aanbieder het tegen een fractie van de normale inputprijs, maar alleen als het identiek blijft. Een engineer voegt dan een huidige tijdstempel toe nabij de top van de systeemprompt, en cache-hitratios storten in, wat de effectieve inputkosten van de ene op de andere nacht verdrievoudigt, want elk verzoek heeft nu een ander prefix vanaf het eerste afwijkende token. De fix is ordening: statische instructies en tools eerst, alles dynamisch laatst. Latentie verbetert samen met kosten, want gecachete prefixen slaan het grootste deel van prefill over.

Veelvoorkomende misvattingen

De veelgemaakte verwarring is de KV-cache behandelen als een antwoordcache, alsof het model antwoorden op herhaalde vragen memoiseert. Het cachet interne attention-status, geen outputs. Een cache-hit op je promptprefix betekent niet dat je dezelfde completion krijgt, en het vereist niet dezelfde vraag, alleen dezelfde leidende bytes. Dit misverstand leidt tot echte fouten in beide richtingen: teams verwachten identieke antwoorden van gecachete prompts en zijn verrast door variatie, of ze wuiven prompt caching weg als irrelevant omdat hun vragen verschillen, en missen dat hun enorme gedeelde systeemprompt precies is wat de cache te gelde maakt.

FAQ

Waarom gebruikt de KV-cache zoveel geheugen? Omdat hij key- en value-vectoren opslaat voor elk token op elke laag. De kosten per token liggen vast door architectuur, dus groeit geheugen lineair met contextlengte, en het parallel bedienen van veel long-context-gebruikers vermenigvuldigt dat. Dit, meer dan modelgewichten, is wat gelijktijdige long-context-sessies op een GPU beperkt. Het is ook waarom cachebeheer servingprestaties domineert: in vLLM's benchmarks van 2023 op LLaMA-modellen leverde paged cachebeheer tot 24x hogere doorvoer dan Hugging Face Transformers [3].

Is prompt caching hetzelfde als de KV-cache? Prompt caching is het commerciële oppervlak van KV-cache-hergebruik: de aanbieder houdt de berekende cache voor een promptprefix vast en rekent een verlaagd tarief wanneer een later verzoek het exact hergebruikt. Het onderliggende mechanisme is dezelfde cache die generatie binnen één verzoek versnelt.

Hoe maak ik mijn agent cache-vriendelijk? Houd het promptprefix stabiel en byte-identiek over beurten heen: systeemprompt en tooldefinities eerst, dynamische content zoals opgehaalde context en gebruikersberichten laatst, en injecteer nooit tijdstempels of willekeurige ID's vroeg in de prompt. Toevoegen aan het einde van een gesprek bewaart het gecachete prefix; het begin bewerken maakt het ongeldig.

Bronnen

1. vLLM-project (officiële blog). "Bestaande LLM-servingsystemen verspillen 60-80% van het KV-cachegeheugen; PagedAttention verlaagt verspilling tot bijna nul." https://vllm.ai/blog/2023-06-20-vllm. Geraadpleegd augustus 2026.
2. UC Berkeley (arXiv, SOSP 2023). "PagedAttention verbetert LLM-servingdoorvoer 2-4x ten opzichte van FasterTransformer en Orca bij dezelfde latentie." https://arxiv.org/abs/2309.06180. Geraadpleegd augustus 2026.
3. vLLM-project (officiële blog). "vLLM leverde tot 24x hogere doorvoer dan Hugging Face Transformers op LLaMA-modellen." https://vllm.ai/blog/2023-06-20-vllm. Geraadpleegd augustus 2026.