# KV-cache kwantisatie in llama.cpp en vLLM [Naar de inhoud](#lm-inhoud)Netwerk/NL[EN](/en/)[Hubhub.llmnet.nlModellen vergelijken op taak, taal, kosten en licentie.](https://hub.llmnet.nl/)[Communitycommunity.llmnet.nlPrompttechnieken, patronen en systeemprompts.](https://community.llmnet.nl/)[APIapi.llmnet.nlLLM's robuust in software: rate limits, routing, structured output.](https://api.llmnet.nl/)[Consultancyconsultancy.llmnet.nlAI invoeren in een organisatie, van pilot tot productie.](https://consultancy.llmnet.nl/)[Nieuwsnieuws.llmnet.nlOntwikkelingen in AI, geduid voor Nederland.](https://nieuws.llmnet.nl/)[Benchmarkbenchmark.llmnet.nlZelf meten wat AI-kwaliteit is, voor jouw taken.](https://benchmark.llmnet.nl/)[Vacaturesvacatures.llmnet.nlAI-rollen, salarissen en carrièrepaden in Nederland.](https://vacatures.llmnet.nl/)[Lerenleren.llmnet.nlAI-concepten in gewoon Nederlands, van beginner tot bouwer.](https://leren.llmnet.nl/)[Gidsgids.llmnet.nlAI privé draaien op eigen Mac, pc, NAS of thuisserver.](https://gids.llmnet.nl/)[Directorydirectory.llmnet.nlHet AI-ecosysteem in kaart: tools, modellen, bedrijven.](https://directory.llmnet.nl/)[Radarradar.llmnet.nlSignalen uit X, onderzoek en communities voor indie developers.](https://radar.llmnet.nl/)[Appsapps.llmnet.nlReviews van AI-apps en open-source repo's, met tips voor wie zelf bouwt.](https://apps.llmnet.nl/)[llmnet.nl — hoofdsite](https://llmnet.nl/)[](https://x.com/intent/post?url=https%3A%2F%2Fgids.llmnet.nl%2Fkv-cache-kwantisatie-instellen-in-llama-cpp-en-vllm&text=KV-cache%20kwantisatie%20in%20llama.cpp%20en%20vLLM)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fgids.llmnet.nl%2Fkv-cache-kwantisatie-instellen-in-llama-cpp-en-vllm)[](https://www.reddit.com/submit?url=https%3A%2F%2Fgids.llmnet.nl%2Fkv-cache-kwantisatie-instellen-in-llama-cpp-en-vllm&title=KV-cache%20kwantisatie%20in%20llama.cpp%20en%20vLLM)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fgids.llmnet.nl%2Fkv-cache-kwantisatie-instellen-in-llama-cpp-en-vllm&text=KV-cache%20kwantisatie%20in%20llama.cpp%20en%20vLLM)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fgids.llmnet.nl%2Fkv-cache-kwantisatie-instellen-in-llama-cpp-en-vllm)[](https://www.reddit.com/submit?url=https%3A%2F%2Fgids.llmnet.nl%2Fkv-cache-kwantisatie-instellen-in-llama-cpp-en-vllm&title=KV-cache%20kwantisatie%20in%20llama.cpp%20en%20vLLM)[](#) # KV-cache kwantisatie instellen in llama.cpp en vLLM Plaats in de route: Stap 2 (Hardware, prestaties & energie) binnen het traject kiezen → installeren → gebruiken → koppelen → beheren/serveren. Wie vooraf wil nagaan of de aanwezige videokaart toereikend is voor het draaien van moderne modellen, raadpleegt eerst het overzicht over [welke hardware nodig is om LLM's lokaal te draaien](https://gids.llmnet.nl/hardware-voor-lokale-llm). Toepassingsgebied & hardware-indicatie: Deze handleiding richt zich op systemen met dedicated GPU's (zoals Nvidia GeForce, RTX of datacenter-accelerators) en moderne multi-core processoren waarbij het beschikbare videogeheugen een beperkende factor vormt voor lange contextreeksen. Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini) Wanneer we lokale taalmodellen inzetten voor het verwerken van lange documenten, diepe codeeropdrachten of intensieve meerstapsgesprekken, lopen we vrijwel direct tegen een fysieke geheugenbarrière aan. Waar het statische gewicht van het model permanent in het grafisch geheugen (VRAM) rust, groeit de Key-Value (KV) cache dynamisch met elk aangeboden en gegenereerd token mee. Bij contextvensters van 32k, 64k of zelfs 128k tokens overstijgt het geheugenbeslag van deze cache dikwijls de totale omvang van het basismodel zelf. Wie de contextruimte wil maximaliseren zonder direct te investeren in extra videokaarten, komt uit bij het comprimeren van deze tijdelijke aandachtsvectoren via kwantisatie. In dit artikel doorlopen we de exacte runtime-flags en configuratieparameters voor KV-cache kwantisatie in zowel llama.cpp als vLLM. We behandelen de werking van FP8, INT8 en INT4 precisie, analyseren de afwegingen tussen geheugenwinst en rekenkundige degradatie, en lichten de invloed op taalvaardigheid toe. Om de theoretische fundamenten van gewichtscompressie en bitreductie te begrijpen, verwijst [het overzichtsartikel over kwantisatie](https://gids.llmnet.nl/kwantisatie-uitgelegd) naar de achterliggende principes van afronding, schaalfactoren en matrixtransformaties. ## Waarom de KV-cache lineair groeit met de contextlengte Bij autoregressieve transformers moet het model bij elke gegenereerde stap terugkijken naar alle voorgaande tokens in de actieve reeks. Om te voorkomen dat eerdere matrixvermenigvuldigingen voor sleutel- en waardeparen (Keys en Values) bij elk nieuw token opnieuw berekend moeten worden, slaat de inferentiemotor deze tussenresultaten per aandachtslaag op in het VRAM. Voor een diepgaand inzicht in hoe deze mechanismen wiskundig functioneren, legt [de uitleg over KV-caching in transformer-architecturen](https://leren.llmnet.nl/kv-caching-opbouw) exact uit hoe sleutels en waarden per aandachtslaag worden gestructureerd en bewaard. De standaardprecisie voor deze cache is van oudsher 16-bits drijvende-kommagetallen (FP16 of BF16), wat neerkomt op 2 bytes per element. De theoretische formule voor het geheugenbeslag per token luidt als volgt: Geheugen per token (bytes) = 2 * n_layers * n_kv_heads * head_dim * bytes_per_element Als illustratief rekenvoorbeeld nemen we een model met 32 lagen, 8 KV-heads (via Grouped-Query Attention) en een head-dimensie van 128 (zoals gebruikelijk bij moderne 8B-architecturen). In FP16 kost elk token in de cache: 2 * 32 * 8 * 128 * 2 = 131.072 bytes, oftewel exact 128 KB. Bij een context van 4.096 tokens vraagt dit circa 512 MB VRAM. Zodra we de context echter opschroeven naar 128.000 tokens, slokt de KV-cache in zijn eentje maar liefst 16 GB VRAM op. Tel daar de circa 5 tot 6 GB VRAM bij op voor een 4-bits gekwantiseerd 8B-basismodel, en een consumentenkaart van 24 GB zit nagenoeg vol voor slechts één enkele actieve sessie. Modelarchitectuur (Illustratief) | Contextlengte | FP16 Cache (2 bytes) | FP8 / Q8_0 Cache (1 byte) | Q4_0 Cache (~0,55 byte) | 8B Model (32 lagen, 8 KV-heads) | 32.768 tokens | 4,00 GB | 2,00 GB | 1,12 GB | 8B Model (32 lagen, 8 KV-heads) | 131.072 tokens | 16,00 GB | 8,00 GB | 4,50 GB | 14B Model (48 lagen, 8 KV-heads) | 32.768 tokens | 6,00 GB | 3,00 GB | 1,70 GB | 14B Model (48 lagen, 8 KV-heads) | 131.072 tokens | 24,00 GB | 12,00 GB | 6,80 GB | Om te berekenen hoe deze parameters uitvallen voor specifieke modelconfiguraties en hardware, biedt de [VRAM-rekenhulp voor lokale modellen](https://gids.llmnet.nl/vram-rekenhulp-hoeveel-geheugen-heeft-welk-model-nodig) een systematische methode om geheugenlimieten vooraf in te schatten. Daarnaast kan men via de [interactieve KV-cache calculator](https://leren.llmnet.nl/tool-kv-cache-calculator) dynamisch variëren met contextlengtes, batchgroottes en precisieniveaus om de exacte allocaties door te rekenen. ## Kwantisatietypen voor de KV-cache: FP8, INT8 en INT4 Het comprimeren van de KV-cache verschilt fundamenteel van het kwantiseren van modelgewichten. Modelgewichten zijn statisch en kunnen vooraf via kalibratiedatasets zorgvuldig worden geoptimaliseerd (zoals bij AWQ, GPTQ of GGUF k-quants). De KV-cache daarentegen ontstaat dynamisch tijdens het genereren van tekst. Kwantisatie moet daarom 'on-the-fly' plaatsvinden tijdens de inferentie, met minimale rekenkundige vertraging. In de praktijk onderscheiden we drie gangbare formaten voor cache-compressie: - FP8 (E4M3 en E5M2): Maakt gebruik van 8-bits floating-point getallen. Het E4M3-formaat (1 tekenbit, 4 exponentbits, 3 mantissabits) biedt een uitstekend dynamisch bereik voor activatievectoren en benadert de kwaliteit van FP16 zeer dicht. Het halveert het geheugengebruik direct naar 1 byte per element en wordt hardwarematig versneld op moderne GPU-architecturen. - INT8 (Q8_0 in llama.cpp): Kwantiseert getallen uniform naar 8-bits gehele getallen met een schaalfactor per blok (vaak per 32 waarden). Dit formaat is universeel inzetbaar op vrijwel alle compute-hardware en vertoont een uiterst gering verlies aan numerieke precisie. - INT4 (Q4_0 in llama.cpp): Reduceert de vectoren tot 4-bits integers (ongeveer 0,55 byte per element inclusief schaalfactoren). Dit levert een geheugenbesparing op van circa 70% ten opzichte van FP16, maar kan bij taken die extreme contextprecisie vereisen over grote afstanden tot lichte kwaliteitsdegradatie leiden. ## KV-cache kwantisatie instellen in llama.cpp Binnen het ecosysteem van llama.cpp (en afgeleide wrappers) sturen twee specifieke parameters het formaat van de cache aan: --cache-type-k (voor de Keys) en --cache-type-v (voor de Values). Standaard alloceert llama.cpp f16 voor beide buffers. De Key-vectoren bepalen de aandachtsverdeling via het inproduct met de Query-vector, terwijl de Value-vectoren de eigenlijke inhoudelijke representaties dragen. Omdat Key-vectoren gevoeliger zijn voor kwantisatieruis dan Value-vectoren, kan men kiezen voor een asymmetrische configuratie (bijvoorbeeld Q8_0 voor K en Q4_0 voor V) wanneer maximale geheugenbesparing noodzakelijk is. Onderstaand voorbeeld toont het opstartcommando voor llama-server met een symmetrische Q8_0 cache en een context van 65.536 tokens: llama-server \ -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \ -c 65536 \ -ngl 99 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --host 0.0.0.0 \ --port 8080 Wanneer men de maximale contextcapaciteit wil benutten op een videokaart met beperkt VRAM (zoals 16 GB), kan een 4-bits configuratie voor zowel Keys als Values worden geconfigureerd: llama-server \ -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \ -c 65536 \ -ngl 99 \ --cache-type-k q4_0 \ --cache-type-v q4_0 \ --host 0.0.0.0 \ --port 8080 Voor aanvullende richtlijnen rondom het verdelen van buffers en het voorkomen van geheugenfragmentatie beschrijft de handleiding over [het contextvenster lokaal optimaliseren](https://gids.llmnet.nl/context-window-optimaliseren-lokaal) hoe contextlengtes en bufferruimtes evenwichtig worden ingesteld. ## Configuratie in vLLM voor hoge doorvoer en FP8-cache Waar llama.cpp hoofdzakelijk geoptimaliseerd is voor lokaal enkelvoudig gebruik, richt vLLM zich op servers met hoge verwerkingscapaciteit en meerdere gelijktijdige verzoeken. vLLM maakt gebruik van PagedAttention, waarbij het KV-geheugen wordt ingedeeld in virtuele geheugenpagina's om interne en externe fragmentatie tegen te gaan. vLLM ondersteunt FP8 KV-cache kwantisatie via runtime-argumenten. Op architecturen met native FP8 Tensor Cores (zoals moderne datacenter- en consumentenchips) levert dit directe hardwareversnelling op. Op oudere generaties kan de engine terugvallen op softwarematige conversie, wat de geheugenbesparing behoudt maar extra instructiecycli vereist. Om een vLLM server op te starten met een FP8-gekwantiseerde cache, activeert men de vlag --kv-cache-dtype fp8: python3 -m vllm.entrypoints.openai.api_server \ --model meta-llama/Meta-Llama-3.1-8B-Instruct \ --kv-cache-dtype fp8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.95 \ --port 8000 Voor diepgaande instructies over multi-GPU opstellingen, scheduling en serveroptimalisatie raadpleegt men de uitgebreide handleiding over [het configureren van een vLLM server op Linux](https://gids.llmnet.nl/vllm-server-configureren). Wie twijfelt over de juiste engine voor een specifieke serveropstelling, vindt in [de vergelijking van vLLM en Ollama voor productieomgevingen](https://radar.llmnet.nl/review-vllm-versus-ollama-voor-productie-op-eigen-servers) een systematische evaluatie van geheugenbeheer en doorvoersnelheden onder gelijktijdige belasting. Binnen vLLM halveert FP8 niet alleen het geheugenbeslag per token, maar vergroot het ook de effectieve capaciteit van de PagedAttention-pool. Hierdoor kan het systeem substantieel meer gelijktijdige sessies (concurrency) in het videogeheugen vasthouden voordat requests naar het tragere systeem-RAM moeten worden uitgewisseld. ## Invloed op taalconsistentie en kwaliteitsafwegingen Een belangrijk aspect bij cache-compressie is het potentiële effect op de semantische consistentie over lange tekstreeksen. In tegenstelling tot modelgewichten, waarbij kwantisatieruis globaal verdeeld is, beïnvloedt ruis in de KV-cache direct de aandachtsverdeling tussen verafgelegen tokens. In academische literatuur en algemene benchmarks vertonen 8-bits varianten (FP8 en INT8) doorgaans een verwaarloosbare afwijking in perplexiteit ten opzichte van FP16. Bij 4-bits kwantisatie (zoals Q4_0) kunnen er bij zeer lange sequenties (boven 32k tokens) subtiele afwijkingen optreden bij taken die strikte syntaxis vereisen, zoals formele logica of het ophalen van exacte feiten uit grote tekstdocumenten. Bij het formuleren van complexe Nederlandse instructies — waar tangconstructies en langere afhankelijkheden tussen werkwoorden en onderwerpen voorkomen — blijft 8-bits kwantisatie robuust functioneren. Om te controleren of de responsen van het model natuurlijk en syntactisch correct blijven, biedt het artikel over [het optimaliseren van AI-prestaties in het Nederlands](https://gids.llmnet.nl/beter-nederlands) nuttige technieken voor consistente outputkwaliteit. ## Impact op doorvoersnelheid: Latentie en prefill Het comprimeren van de KV-cache heeft invloed op twee fasen van het inferentieproces: de prefill-fase (verwerking van de initiële prompt) en de decode-fase (generatie van nieuwe tokens). Tijdens de prefill-fase moeten de berekende activatievectoren worden omgezet naar het lagere precisieformaat voordat ze worden opgeslagen. Dit vraagt een kleine hoeveelheid extra rekenkracht. Tijdens de daaropvolgende decode-fase vormt de geheugenbandbreedte tussen de GPU-kernen en het VRAM vrijwel altijd de primaire bottleneck. Omdat er bij 8-bits en 4-bits formaten aanzienlijk minder data per token over de geheugenbus getransporteerd hoeft te worden, kan de generatiesnelheid bij omvangrijke contexten juist toenemen. De werkelijke winst in tokens per seconde hangt sterk af van de verhouding tussen de contextlengte en de rekenkracht van de GPU: bij korte prompts (onder 2.048 tokens) is het effect op de snelheid minimaal, terwijl bij lange documenten de reductie in geheugenverkeer een duidelijke versnelling kan opleveren. ## Foutopsporing en Out-of-Memory situaties voorkomen Zelfs met een gecomprimeerde cache kunnen er runtime-onderbrekingen optreden wanneer de contextruimte onverwacht volloopt. Een veelvoorkomende oorzaak in llama.cpp is het toewijzen van een contextgrootte die weliswaar binnen de theoretische VRAM-ruimte past, maar geen rekening houdt met tijdelijke CUDA compute-buffers die nodig zijn tijdens piekbelasting. Wanneer een proces onverwacht stopt door geheugengebrek, kan dit vaak worden herleid tot een overschatting van de beschikbare vrije VRAM-ruimte of een te hoog aantal gelijktijdige slots. Mocht de inferentiemotor vastlopen of weigeren te starten, dan biedt de storingshandleiding over [het oplossen van out-of-memory meldingen en trage inferentie](https://gids.llmnet.nl/als-het-niet-werkt-out-of-memory-trage-tokens-en-een-gpu-die-niet-meed) concrete stappen om geheugenconflicten stapsgewijs te lokaliseren. ## Privacy en lokale gegevensverwerking Het kwantiseren van de KV-cache is een zuiver wiskundige geheugenoptimalisatie die zich volledig afspeelt binnen het lokale werkgeheugen en VRAM van het eigen systeem. Er worden tijdens dit proces geen tussenliggende activatielagen, embeddings of promptgegevens naar externe servers verzonden. Alle contextinformatie blijft strikt gebonden aan de lokale machine. Voor organisaties die lokale taalmodellen inzetten om te voldoen aan strikte privacyrichtlijnen, beschrijft het overzicht over [privacyvriendelijk werken met lokale AI](https://gids.llmnet.nl/privacyvriendelijk-ai) hoe gegevensstromen geïsoleerd en conform regelgeving kunnen worden beheerd. ## Praktische richtlijnen voor configuratie Bij het inrichten van een lokale inferentie-omgeving kan men de volgende richtlijnen hanteren: - Moderne GPU's met hardwarematige FP8-ondersteuning: Gebruik bij voorkeur FP8 in vLLM (--kv-cache-dtype fp8) of Q8_0 in llama.cpp (--cache-type-k q8_0 --cache-type-v q8_0). Dit halveert het geheugenbeslag van de cache met behoud van numerieke stabiliteit. - Systemen met oudere GPU-architecturen of CPU-inferentie: Kies voor q8_0 in llama.cpp voor een evenwichtige balans tussen geheugenwinst en compatibiliteit. Vermijd FP8 in vLLM indien de GPU geen native ondersteuning biedt en rekensnelheid leidend is. - Maximale contextcapaciteit op krap bemeten hardware: Pas een 4-bits configuratie toe (zoals --cache-type-k q4_0 --cache-type-v q4_0 in llama.cpp) wanneer lange documenten absoluut binnen één enkele grafische kaart moeten passen, en controleer steekproefsgewijs of de output consistent blijft bij grootschalige prompts.