Bij de meeste productie-LLM-applicaties vormt de systeemprompt, contextdocumentatie of gespreksgeschiedenis het grootste deel van de input-tekst bij elke aanroep. Als uw systeemprompt duizend tokens heeft en u tienduizend verzoeken per dag verwerkt, betaalt u voor tien miljoen tokens — waarvan het merendeel elke keer dezelfde tekst is. Prompt caching lost dit probleem op op infrastructuurniveau: de provider slaat de KV-representatie van herhalende prefixen op en berekent die bij een volgende aanroep niet opnieuw.
Dit artikel legt uit hoe prompt caching onder de motorkap werkt, onder welke omstandigheden het de kosten én de latentie aanzienlijk verlaagt, wat u concreet moet cachen en wanneer caching juist niet helpt — of zelfs extra kosten toevoegt. Dit hangt ook samen met het ontwerp van prompts die goed gecached worden, een onderwerp dat veel teams over het hoofd zien.
Hoe prompt caching werkt
Wanneer u een request naar de LLM API stuurt, berekent het model voor elke input-token de zogenaamde KV-cache (key-value vectoren) — de basis van het self-attention-mechanisme waarmee het model verbanden tussen tokens evalueert. Diese berekening is niet gratis: het is GPU-werk dat direct van invloed is op de prijs én op de time to first token (TTFT).
Prompt caching (ook wel context caching of prefix caching genoemd) houdt het volgende in: als het begin van de prompt — het prefix — identiek is in meerdere aanroepen, berekent de provider de KV-representatie ervan één keer, slaat die op de server op en laadt die bij volgende requests gewoon in, in plaats van de berekening te herhalen. Voor de aanroepende kant is dit volledig transparant — de antwoorden zijn even correct, maar goedkoper en sneller.
Wat dit in cijfers betekent:
- Bij Anthropic: cache read = 10 % van de gewone input-tokenprijs (90 % besparing); cache write = 125–200 % van de gewone input-tokenprijs (lichte meerprijs bij de eerste schrijfoperatie)
- Bij OpenAI: automatisch, cache read = 50 % van de gewone input-tokenprijs; geen expliciete code van de aanroepende kant nodig
- Reële besparing in productie: doorgaans 50–70 % op de totale input-tokenkosten bij workloads met lange, herhalende prefixen
De economie ziet er dus als volgt uit: voor de eerste aanroep betaalt u iets meer voor de cache write, maar elke volgende lezing van hetzelfde prefix is aanzienlijk goedkoper. Het break-evenpunt ligt bij de tweede lezing; bij duizenden aanroepen per dag is de besparing substantieel.
TTL en prefix-consistentie
Een gecached prefix heeft geen onbeperkte geldigheid. Anthropic biedt een TTL (time-to-live) van 5 minuten of 1 uur — na afloop wordt de cache ongeldig en wordt het prefix bij de volgende aanroep opnieuw berekend (opnieuw een cache write). OpenAI beheert de TTL automatisch, zonder expliciet in te stellen waarde.
Hieruit vloeien twee praktische gevolgen voort. Ten eerste: als uw workload requests met hetzelfde prefix in korte tijd binnenkrijgt (binnen seconden of minuten), werkt caching goed. Als requests over de hele dag zijn gespreid met tussenpozen van een uur en u een TTL van 5 minuten gebruikt, zal de cache regelmatig ongeldig worden. Ten tweede: het prefix moet byte-voor-byte identiek zijn. Zelfs een kleine wijziging (een extra spatie, een anders opgemaakt datumveld in de systeemprompt) maakt de volledige gecachede representatie ongeldig en activeert een nieuwe cache write.
Wat het zinvol is te cachen
Niet elke tekst in de prompt is de moeite van caching waard. De keuze volgt een eenvoudige logica: cachen loont voor wat lang, statisch en herhaaldelijk gebruikt is.
Systeemprompt. De meest voor de hand liggende kandidaat. Als u 500–2000 tokens aan systeeminstructies heeft (rol, context, gedragsregels, few-shot voorbeelden), veranderen die in de meeste applicaties nooit of zelden. Sla ze op als een vast prefix aan het begin van de prompt — caching dekt ze automatisch.
Gedeelde documenten en normen. Als elk request dezelfde technische handleiding, ISO-norm, bedrijfsvoorschriften of juridisch document als referentiecontext bevat, is dit een ideale kandidaat. Wij hebben implementaties gezien waarbij een 300 pagina's tellende technische documentatie bij elke aanroep in een klantenservicechatbot werd ingevoegd — caching verlaagde de kosten daar met meer dan 80 %.
Lange gespreksgeschiedenis. Bij multi-turn chats stuurt de applicatie bij elk nieuw request de volledige voorafgaande geschiedenis mee. Het oudere deel van de geschiedenis verandert niet — het is een groeiend, stabiel prefix. Caching werkt hier goed, mits de applicatie de conversatie consistent opmaakt en berichten niet herordent.
Few-shot voorbeelden. Als u in uw systeemprompt enkele lange invoer–uitvoer-voorbeelden gebruikt (zogenaamde few-shot prompting), zijn ook die statisch en herbruikbaar. Neem ze op in het gecachede prefix.
Wat daarentegen niet de moeite waard is om te cachen:
- Korte of eenmalige prompts — u betaalt extra voor de cache write, maar haalt nooit rendement
- Prompts waarbij elk request al vanaf het begin verschilt (bijvoorbeeld bij het genereren van variabele rapporten zonder gemeenschappelijk prefix)
- Systemen met inconsistente opmaak — een willekeurige wijziging in de volgorde van parameters in de systeemprompt volstaat om de cache ongeldig te maken
Prompts ontwerpen voor caching
Een van de meest voorkomende omissies die we tegenkomen bij de beoordeling van bestaande applicaties: teams schakelen caching in, maar de promptstructuur is niet ontworpen om er effectief gebruik van te maken.
De basisregel: statisch vóór dynamisch. Caching dekt het prefix — het begin van de prompt. Daarom moet alles wat per request wijzigt (de concrete vraag van de gebruiker, variabele parameters, de huidige datum) aan het einde van de prompt staan. Als u een dynamisch element in het midden van een statische context plaatst, verandert het prefix bij elke aanroep en werkt caching niet.
Voorbeeld van verkeerde volgorde:
Systeemprompt (statisch)
↓
Huidige datum en gebruikersnaam (dynamisch — wijzigt bij elk request)
↓
Technische handleiding (statisch, 800 tokens)
↓
Vraag van de gebruiker (dynamisch)In dit voorbeeld maakt het dynamische element in het midden de caching voor de volledige technische handleiding eronder ongeldig.
Juiste volgorde:
Systeemprompt (statisch)
↓
Technische handleiding (statisch, 800 tokens)
↓
Huidige datum en gebruikersnaam (dynamisch)
↓
Vraag van de gebruiker (dynamisch)Het statische blok is nu een aaneengesloten prefix — de provider cachet het en de dynamische elementen beïnvloeden het niet.
Stabiele opmaak. Als uw systeemprompt code genereert, vermijd dan het invoegen van variabele waarden (timestamp, versie) direct in het statische deel. Gebruik in plaats van Huidige systeemversie: 2.4.1 (uitgerold 2026-03-20) de vorm Huidige systeemversie: {version} en voeg de waarde pas toe in het dynamische deel, of beter nog in het user message.
Op on-prem (vLLM, SGLang) gelden dezelfde principes. Zowel vLLM als SGLang implementeren prefix caching op hun eigen manier — SGLang via RadixAttention (LRU-boom van KV-caches), vLLM via PagedAttention met prefix-aware blokkenbeheer. Beide frameworks herkennen automatisch herhalende prefixen en herhalen de berekening ervan niet. De details verschillen, maar het ontwerpprincipe — statisch vóór dynamisch — geldt gelijkelijk. Meer over de keuze van een serving-framework vindt u in vLLM vs SGLang vs Ollama.
Wanneer caching duidelijk helpt — en wanneer niet
Een eenvoudige test: bereken welk percentage van de input-tokens een herhalend statisch prefix vormt. Ligt dat boven de 50 %, dan is caching waarschijnlijk een zinvolle investering. Als elk request uniek is, helpt caching niet.
Scenario's met hoge besparing:
- RAG met lange context. Applicaties die bij elke aanroep dezelfde gedeelde documentatie als context invoegen (bedrijfsvoorschriften, handleidingen, normen). De gecachede context wordt geladen voor 10 % van de prijs.
- Klantenservice met lange systeemprompts. Een typische productie-klantenservicechatbot heeft een systeemprompt van 500–1500 tokens die het product, de regels, de toon en voorbeelden beschrijft. Bij duizenden aanroepen per dag is de besparing substantieel.
- Multi-turn agents met accumulerende geschiedenis. Conversatiesessies waarbij de geschiedenis in de context wordt geschreven. Het oudere deel van de geschiedenis wordt een stabiel prefix — caching groeit hier organisch mee naarmate het gesprek langer wordt. Dit hangt rechtstreeks samen met hoe u de kosten van een AI-agent in productie beheert.
- Batchverwerking van documenten met gemeenschappelijke instructies. Als u duizenden facturen, serviceverslagen of bestellingen verwerkt met dezelfde extractie-instructies, worden die instructies gecached en betaalt u alleen voor de documenten zelf.
Scenario's met lage of geen besparing:
- Generatieve one-shot taken. Schrijf een annotatie bij deze video, vertaal deze tekst, genereer een rapport — elk request is ook in het systeemgedeelte uniek. U betaalt extra voor de cache write, maar haalt daar nooit rendement uit.
- Workloads met een laag volume. Als een applicatie honderd aanroepen per dag doet, zijn de absolute besparingen klein. De implementatie-overhead (refactoring van prompts, monitoring van de hit rate) verdient zich mogelijk niet terug.
- Korte systeemprompts. Als uw systeemprompt 50 tokens heeft, wordt de minimumlengte voor caching (Anthropic vereist een prefix van minimaal 1024 tokens) al niet gehaald.
De effectiviteit van caching meten
Uitrollen zonder meting is navigeren op de tast. Drie metrics om bij te houden:
Cache hit rate. Het aandeel requests waarbij het prefix uit de cache werd geladen, ten opzichte van het totaal. Bij Anthropic geeft de API in het antwoord cache_read_input_tokens en cache_creation_input_tokens terug. OpenAI geeft cached_tokens terug in het usage-object. Doel: bij correct gestructureerde prompts zou de hit rate bij een stabiele workload 80–95 % moeten zijn.
Gemiddelde input-tokens per request. Als caching werkt, dalen de effectieve kosten van de input-tokens — cache-read-tokens worden goedkoper in rekening gebracht. Volg het voortschrijdend gemiddelde van de input-kosten per request in de tijd.
TTFT (Time to First Token). Het gecachede prefix elimineert de herberekening, wat de TTFT verkort. Als u een bimodale latentieverdeling ziet (sommige requests sneller, andere trager), is dat waarschijnlijk het gevolg van het verschil tussen cache hit en cache miss.
Neem deze metrics op in uw observability-pipeline — bijvoorbeeld via gestructureerde logs of monitoring in agent observability en tracing.
Vergelijking van cloudproviders
De aanpakken verschillen ook in implementatiedetails, wat van invloed is op hoe u caching ontwerpt.
Anthropic (Claude): Expliciet — in het request moet u de blokken die u wilt cachen markeren met de cache_control-parameter. Dit geeft u controle over wat er precies gecached wordt. TTL van 5 minuten of 1 uur (naar keuze). Minimum voor caching: 1024 tokens. Cache write kost 125–200 % van de gewone input-tokenprijs; cache read kost 10 %.
OpenAI (GPT): Impliciet — automatisch, zonder code. De provider herkent zelf herhalende prefixen en cachet die. Cache read = 50 % van de input-tokenprijs. Eenvoudiger te activeren, minder controle over wat er gecached wordt.
Google (Gemini): Expliciete context caching via de API, vergelijkbaar met Anthropic. Langere TTL — uren tot dagen. Geschikt voor zeer stabiele, lange contexten (volledige handleidingen, codebases).
On-prem (vLLM, SGLang): Prefix caching is ingebouwd en draait automatisch bij herhalende prefixen. U betaalt geen extra voor writes — de compute-kosten zijn voor u, maar bij herhaalde prefixen bespaart het serving-framework GPU-tijd, wat de throughput verhoogt en de latentie verlaagt. Dit voordeel is doorslaggevend bij een privé-implementatie met eigen hardware.
Veelgestelde vragen
Is prompt caching veilig — blijven mijn gegevens op de servers van de provider?
Ja, de gecachede KV-representatie blijft op de servers van de provider gedurende het TTL-venster. Voor de meeste bedrijven is dat geen probleem — API-aanroepen gaan sowieso daar naartoe. Voor organisaties met strikte eisen aan data residency (ziekenhuizen, banken, gereguleerde sectoren) is on-prem serving met vLLM of SGLang een betere keuze, waarbij de cache volledig onder uw controle blijft. Meer hierover in on-prem LLM voor gereguleerde sectoren.
Kan caching de kwaliteit van de antwoorden negatief beïnvloeden?
Nee — caching beïnvloedt alleen hoe snel de KV-vectoren voor het prefix in het geheugen komen, niet welke waarden ze hebben. Het model ontvangt een identieke context, ongeacht of het prefix opnieuw is berekend of uit de cache is geladen. De antwoorden zijn gelijk.
Loont caching voor een kleine applicatie met een paar honderd aanroepen per dag?
Dat hangt af van de lengte van de systeemprompt en de modelprijs. Voor een systeemprompt van 1000 tokens en 500 aanroepen per dag met een frontier-model zijn de maandelijkse besparingen in de orde van enkele euro's — aan de grens van of het de moeite waard is de code te refactoren. Bij 50.000 aanroepen per dag en een prompt van 2000 tokens bedragen de besparingen honderden euro's per maand of meer — daar is het rendement ondubbelzinnig.
Wat als mijn systeemprompt elk uur bijgewerkt moet worden (bijvoorbeeld met de actuele tijd of de voorraadstatus)?
Dit is een klassieke valkuil. Als de dynamische waarde binnen het gecachede blok staat, maakt elke wijziging de cache ongeldig. De oplossing: haal de dynamische waarde uit het gecachede prefix en zet die in het user message of in een niet-gecached blok aan het einde van de prompt. De gecachede systeemprompt verandert niet; de dynamische waarde gaat er naast.
Werkt prompt caching ook met gestructureerde uitvoer (JSON mode)?
Ja. Caching is onafhankelijk van het uitvoerformaat. Het gecachede prefix kan een combinatie zijn van systeeminstructies en een JSON-schema, mits dat statisch is — het model genereert op basis daarvan en de cache hit rate verandert niet. Meer over gestructureerde uitvoer in structured outputs en JSON mode.
Conclusie
Prompt caching is geen revolutie — het is een infrastructuuroptimalisatie die stil en betrouwbaar werkt, zolang u de applicatie zo ontwerpt dat ze er gebruik van maakt. Drie zaken zijn cruciaal: het statische prefix in uw prompts identificeren, het consequent aan het begin plaatsen en de hit rate meten. Bij workloads met duizenden aanroepen per dag en lange, gedeelde contexten kan deze aanpassing de LLM API-factuur met tientallen procenten verlagen, zonder enige ingreep in de applicatielogica.
*Bij MP Industrial Solutions stuiten we bij de beoordeling van de LLM-applicaties van klanten regelmatig op promptstructuren waarbij caching niet wordt benut — of waarbij een dynamisch element midden in een statische context het volledige effect tenietdoet. Als u wilt dat wij naar uw applicatie kijken en concrete besparingen identificeren, plannen we graag een consultatie.*