Prompt caching is een optimalisatietechniek waarbij de verwerkte representatie van een promptprefix — zoals een systeemprompt, kennisbank of set few-shot voorbeelden — wordt opgeslagen op de servers van de LLM-provider en hergebruikt bij opvolgende verzoeken, waardoor zowel kosten als latentie drastisch dalen. Het eerste verzoek dat de cache aanmaakt betaalt een kleine schrijfpremie (doorgaans 1,25× de normale tokenkosten), maar alle volgende verzoeken die dezelfde prefix delen lezen uit de cache tegen een korting van 90% (0,1× de normale kosten). Voor AI-applicaties met hoog volume waarbij dezelfde systeemprompt en context bij elk verzoek worden meegestuurd, kan prompt caching de API-kosten met meer dan 80% per jaar verlagen en tegelijkertijd de responslatentie met een factor drie verminderen, aangezien de gecachete tokens niet opnieuw hoeven te worden verwerkt.
Waarom het belangrijk is
Prompt caching is mogelijk de optimalisatie met de hoogste ROI die beschikbaar is voor productie-LLM-applicaties. Stel je een klantenservicechatbot voor die een systeemprompt van 8.000 tokens, een kennisbank van 10.000 tokens en slechts 500 tokens unieke gebruikersinvoer meestuurt bij elk verzoek. Zonder caching worden de volledige 18.500 tokens elke keer verwerkt. Met caching worden de 18.000 stabiele tokens eenmaal verwerkt en vervolgens uit de cache gelezen tegen 10% van de kosten bij elk volgend verzoek. Bij 1.000 verzoeken per dag vertaalt dit zich naar jaarlijkse besparingen van meer dan €20.000 — door een implementatie van twee uur die simpelweg caching-headers toevoegt aan API-aanroepen. Het break-evenpunt ligt bij slechts 1,4 verzoeken met dezelfde prefix, wat betekent dat caching zich vrijwel onmiddellijk terugverdient. Voor elke applicatie die meer dan een handvol verzoeken per dag doet met een stabiele systeemprompt, is het niet gebruiken van prompt caching geld laten liggen.
Hoe het werkt
Wanneer een LLM-provider een verzoek ontvangt met caching ingeschakeld, berekent en slaat deze de interne key-value (KV) representaties op van de cachebare prefix — de computationeel dure tussenresultaten die de transformer produceert bij het verwerken van die tokens. Bij volgende verzoeken met dezelfde prefix detecteert de provider de cachehit, slaat de dure berekening voor het gecachete deel over, en verwerkt alleen de nieuwe, niet-gecachete tokens. De cache verloopt doorgaans na 5 minuten inactiviteit, wat betekent dat perioden met weinig verkeer een "cold start" cachewritekost met zich meebrengen wanneer het verkeer hervat. Implementatie is eenvoudig: je markeert stabiele promptsecties (systeemprompt, kennisbank, voorbeelden) met een cache control-header, en de API regelt de rest. Meerlaagse cachingstrategieën scheiden content op updatefrequentie — volledig statische richtlijnen in één gecachet blok, semi-statische productcatalogi in een ander, en dynamische per-gebruiker context volledig buiten de cache.
Voorbeeld
Een SaaS-platform draait een AI-documentanalysetool die door klanten geüploade contracten verwerkt. Elk verzoek bevat: een systeemprompt van 6.000 tokens met analyse-instructies, een juridische referentiebibliotheek van 12.000 tokens, en het variabele klantdocument (gemiddeld 3.000 tokens). Zonder caching is hun maandelijkse API-rekening bij 5.000 analyses per dag €32.000. Ze implementeren tweelaags prompt caching: de systeemprompt en juridische bibliotheek (18.000 tokens) worden als cachebaar gemarkeerd. Het eerste verzoek elke ochtend betaalt 1,25× voor de cachewrite. De overige 4.999 verzoeken lezen die 18.000 tokens tegen 0,1× kosten, en betalen alleen de volledige prijs voor de 3.000 variabele documenttokens. De maandelijkse kosten dalen naar €7.200 — een reductie van 77%. Ze voegen elke 4 minuten tijdens kantooruren een keep-alive ping toe om cacheverlopen tijdens korte verkeerspauzes te voorkomen, wat €80 per maand extra kost maar de sporadische cold-start latentiepieken elimineert die hun gebruikers hadden opgemerkt.