Wat een prompt kost: tokens, caching en de rekening

In het laboratorium van prompt engineering sturen developers moeiteloos duizenden woorden aan instructies naar grootschalige taalmodellen. Systeemprompts met uitgebreide persona-definities, tientallen few-shot voorbeelden en complete JSON-schema's vliegen over de API-lijnen. Zolang een applicatie in de ontwikkelfase zit met tientallen testverzoeken per dag, valt het financiële effect nauwelijks op. Zodra een AI-applicatie echter naar productie schaalt en tienduizenden gebruikers verwerkt, verandert de prompt van een onschuldig stukje broncode in de grootste variabele kostenpost op de infrastructuurrekening.

Het bepalen van de werkelijke prijs van een prompt vereist een grondig inzicht in de onderliggende token-economie, de asymmetrische prijsstelling van AI-providers en de technische werking van GPU-geheugencaching. Een prompt is namelijk geen statische reeks karakters; het is een dynamische instructieset die bij elke aanroep door de inference-engine moet worden verwerkt. In dit handboek ontleden we hoe tokens worden berekend, waarom de opbouw van je systeemprompt rechtstreeks bepaalt of je in aanmerking komt voor honderden euro's aan cachingkortingen, en hoe je je prompts strak hydrateert zonder dat de redeneerkwaliteit instort.

Hoe tokens worden geteld: De verwerker onder de motorkap

Om te begrijpen waar de rekening vandaan komt, moeten we kijken naar hoe een Large Language Model (LLM) tekst leest. Een LLM verwerkt geen rauwe ASCII- of UTF-8-karakters en leest evenmin hele woorden. In plaats daarvan knipt een subword tokenizer (zoals BPE of WordPiece) de invoertekst op in nummers die corresponderen met een vaste vocabulairetabel. Eén token staat gemiddeld gelijk aan ongeveer 0,75 Engelse woorden of ongeveer 4 karakters.

Voor Nederlandstalige ontwikkelaars zit hier een directe financiële adder onder het gras. De meeste populaire tokenizers van OpenAI, Anthropic en Meta zijn hoofdzakelijk getraind op Engelstalige corpora. Nederlandse woorden worden door deze algoritmes veel vaker opgesplitst in meerdere losse subword-fragments. Waar het Engelse woord sustainability vaak als één of twee tokens telt, kan de Nederlandse vertaling duurzaamheid worden opgebroken in drie tot vier tokens. Dit betekent dat een Nederlandstalige systeemprompt van nature tot 30 procent duurder kan uitvallen in verwerking dan een inhoudelijk identieke Engelse prompt.

Om vooraf in te schatten hoeveel tokens een specifieke instructieset inneemt, kun je de prompt-tokenteller gebruiken om je teksten snel te analyseren. Met deze tool krijg je direct inzicht in de verhouding tussen karakters en token-aantallen voor verschillende tokenizers, waardoor je onverwachte kostenstijgingen al tijdens de ontwerpfase opmerkt.

De anatomie van API-kosten: Input vs. Output pricing

API-providers hanteren vrijwel zonder uitzondering een tweeledige tariefstructuur: kosten per miljoen input-tokens en kosten per miljoen output-tokens. Output-tokens zijn structureel 3 tot 5 keer zo duur als input-tokens. Dit prijsverschil wordt veroorzaakt door de hardwarematige realiteit van autoregressieve generatie.

Bij het verwerken van de input (de prompt) kan de GPU alle tokens parallel verwerken in één enkele forward pass over de Transformer-lagen. Dit is een prefill-fase die extreem efficiënt gebruikmaakt van de massale parallelle rekenkracht van moderne AI-accelerators. Bij de generatie-fase (de output) moet het model echter token voor token opeenvolgend berekenen. Elke nieuw gegenereerde token vereist een volledige doorloop van het gehele netwerk, waarbij alle weights opnieuw uit het HBM-geheugen geladen moeten worden.

Op de infrastructurele laag kun je het verbruik bewaken volgens de richtlijnen voor rate limits, tokens en kosten beheren. Deze gids biedt concrete handvatten voor het instellen van budgetgrenzen en rate-limiting op API-niveau, wat voorkomt dat ontspoorde output-loops je budget uitputten.

Prompt-caching en Prefix Caching ontleed

De belangrijkste innovatie in token-economie van de afgelopen jaren is prompt-caching (ook wel prefix caching genoemd). Omdat de prefill-fase van een lange prompt veel GPU-rekenkracht vraagt, bewaren providers de tussentijdse berekeningen van het Transformer-netwerk — de zogenaamde Key-Value (KV) cache — in het VRAM van de servercluster.

Wanneer een vervolgaanroep exact dezelfde begintekst (prefix) bevat, hoeft het model die tokens niet opnieuw door alle lagen te rekenen. De provider leest de KV-cache direct uit het geheugen. Dit levert niet alleen een gigantische latentiewinst op (vaak tot 80 procent snellere Time-To-First-Token), maar vertaalt zich bij aanbieders zoals Anthropic, OpenAI en Google ook in een directe korting van 50 tot 90 procent op de prijs van die specifieke input-tokens.

Voor een diepgaande analyse van de server-side werking van KV-caches verwijzen we naar het overzicht over context caching bij LLM-API's uitgelegd. Daar lees je exact hoe providers Key-Value-paartjes in het geheugen van hun GPU-clusters vasthouden en welke minimale drempels er gelden om caching te activeren.

Architectuur voor maximale cache hits: De vaste prefix

Veel ontwikkelaars maken onbewust de fout om dynamische variabelen bovenin hun prompt te plaatsen, zoals de huidige datum, het unieke gebruikers-ID of de vraag van de gebruiker. Hierdoor verandert de invoer vanaf token 1, waardoor er nooit een cache-hit optreedt.

Om optimaal te profiteren van caching moet je je prompts opbouwen als een gelaagde piramide. De meest statische, zware onderdelen horen helemaal bovenaan te staan, terwijl de dynamische, snel veranderende gegevens naar de bodem verhuizen.

De optimale volgorde voor prompt-opbouw

1. Statische Systeemprompt (Bovenaan): De algemene rolbeschrijving, gedragsregels en vaste opmaakinstructies. Dit blok verandert zelden of nooit.
2. Vaste Documenten / Kennisbasis: Grote naslagwerken, API-documentatie of polisvoorwaarden die door meerdere verzoeken heen identiek blijven.
3. Few-Shot Voorbeelden: Vaste paren van vraag en antwoord die het gewenste formaat demonstreren.
4. Historische Dialoog context: Eerdere berichten in een multi-turn gesprek (indien van toepassing).
5. Dynamische User Input & Variabelen (Onderaan): De specifieke vraag van de gebruiker, inclusief tijdelijke variabelen zoals de datum of het gebruikersprofiel.

Door je instructies op te knippen in vaste blokken, helpt de aanpak voor prompts opbouwen uit herbruikbare onderdelen om je prefix voorspelbaar te houden. Deze modulaire structuur zorgt ervoor dat een groot deel van de prompt ongewijzigd blijft, wat cruciaal is voor effectieve caching.

// VOORBEELD: Slechte promptstructuur (Cache miss bij elke aanroep)
{
  "system": "Datum: 2026-08-07. Gebruiker: ID-8942.", // Dynamisch bovenaan = BREEKT CACHE
  "prompt": "[Lange statische systeemprompt van 3000 tokens...]"
}

// VOORBEELD: Optimale promptstructuur (High Cache Hit Ratio)
{
  "system": "[Lange statische systeemprompt van 3000 tokens...]", // Vaste prefix = CACHE HIT
  "user_context": "Datum: 2026-08-07. Gebruiker: ID-8942.",      // Dynamisch onderaan
  "user_query": "Wat zijn de voorwaarden voor retourneren?"
}

Token-besparing zonder kwaliteitsverlies: De grens opzoeken

Naast caching is het simpelweg inkorten van de totale promptomvang de meest directe manier om kosten te drukken. Het roekeloos wegsnijden van instructies brengt echter grote risico's met zich mee. Zodra een prompt te spaarzaam wordt opgesteld, verliest het model essentiële context, met stijlbreuken, formaatfouten of hallucinaties tot gevolg.

Bij het reduceren van token-aantallen moet je altijd oog houden voor de prestaties, zoals besproken in het artikel over promptlengte versus antwoordkwaliteit in de praktijk. Dit artikel laat zien op welk punt het wegsnijden van context de nauwkeurigheid van de output begint aan te tasten.

Bewezen technieken voor token-pruning

• Verwijder beleefdheidsvormen en opvulling: Zinnen als "Neem aangesloten tekst aandachtig door en probeer zo nauwkeurig mogelijk het volgende antwoord te formuleren" kunnen zonder enig kwaliteitsverlies worden teruggebracht tot "Analyseer de tekst en beantwoord de vraag."
• Gebruik compacte datastructuren: In plaats van uitgebreide JSON-objecten met lange sleutelnamen in je few-shot voorbeelden, kun je vaak volstaan met een strakke CSV-notatie of YAML, wat tot 40 procent op syntaxis-tokens bespaart.
• Snoei in de Few-Shot voorbeelden: Test of drie uitstekende, gevarieerde voorbeelden niet exact hetzelfde resultaat opleveren als tien overlappende voorbeelden.
• Dwing beknopte output af: Omdat output-tokens het duurst zijn, kun je in de systeemprompt expliciet eisen: "Antwoord in maximaal 2 zinnen" of "Geef uitsluitend de JSON-array terug zonder inleidende tekst".

Rekenvoorbeelden en scenario-analyses uit de praktijk

Om de financiële impact van token-structuur en caching tastbaar te maken, analyseren we drie veelvoorkomende productiescenario's. We rekenen hier met een fictieve maar representatieve prijsstelling van € 2,50 per 1M input-tokens, € 0,25 per 1M cached input-tokens en € 10,00 per 1M output-tokens.

Scenario 1: Klantenservice RAG-Bot

Een organisatie verwerkt 50.000 klantvragen per dag. Elk verzoek bevat een statische systeemprompt plus relevante kennisbankartikelen van in totaal 4.000 tokens. De gebruiker stelt een vraag van 100 tokens en de bot geeft een antwoord van gemiddeld 200 tokens.

• Zonder Caching:
  • Input: 50.000 x 4.100 tokens = 205M tokens = € 512,50 per dag.
  • Output: 50.000 x 200 tokens = 10M tokens = € 100,00 per dag.
  • Totaal per maand (30 dagen): € 18.375,-
• Met Geoptimaliseerde Prefix Caching (90% Cache Hit Rate op de 4.000 statische tokens):
  • Uncached Input: 50.000 x (100 user + 400 static miss tokens) = 25M tokens = € 62,50 per dag.
  • Cached Input: 50.000 x 3.600 cached tokens = 180M tokens = € 45,00 per dag.
  • Output: 10M tokens = € 100,00 per dag.
  • Totaal per maand (30 dagen): € 6.225,- (Een besparing van 66%)

Scenario 2: Automated Code Review Assistant

Voor specifieke toepassingen waarin veel vaste context wordt meegegeven, verwijzen we naar de gids voor prompts schrijven voor codegeneratie. In die gids ontdek je hoe je omvangrijke codebases efficiënt binnen het contextvenster structureert.

Wanneer een ontwikkelaar een pull request van 500 regels code laat reviewen, wordt een systeemprompt van 2.000 tokens (met daarin alle bedrijfscoderichtlijnen) gecombineerd met 8.000 tokens aan code-context. Als de ontwikkelaar de bedrijfscoderichtlijnen bovenaan de prompt plaatst, kan die 2.000-token prefix over honderden reviews per dag heen gecached worden, wat een continue reductie op de basiskosten oplevert.

Valkuilen en de keerzijde van token-optimalisatie

Hoewel kostenbesparing aantrekkelijk is, kleven er serieuze risico's aan agressieve token-optimalisatie en blind vertrouwen op caching.

1. Cache Invalidation Triggers

Aanbieder-specifieke drempels kunnen je caching-strategie ongemerkt omzeep helpen. Veel API's vereisen dat een prefix minimaal 1.024 tokens lang is voordat het überhaupt in aanmerking komt voor caching. Als je systeemprompt 800 tokens telt, betaal je elke keer de volle mep, tenzij je de prompt bewust uitbreidt met gestructureerde documentatie of voorbeelden om de drempel te halen.

2. Cache Eviction bij lage frequentie

Een KV-cache op de GPU-clusters van een provider blijft niet oneindig bewaard. Als er gedurende 5 tot 10 minuten geen nieuwe verzoeken met dezelfde prefix binnenkomen, wordt de cache automatisch gewist (eviction) om ruimte te maken voor andere gebruikers. Caching levert dus pas echt winst op bij verzoeken met een constante, hoge frequentie.

3. Over-optimization en verlies van nuances

Wanneer je een systeemprompt te ver terugsnoeit om tokens te besparen, verdwijnen vaak de subtiele randvoorwaarden ("edge case handling"). Het resultaat is dat het model vaker fouten maakt, wat leidt tot vervolgaanroepen, retries of handmatige correcties door ontwikkelaars. Een mislukte aanroep die opnieuw moet worden uitgevoerd kost dubbel zoveel tokens als een iets langere, maar in één keer geslaagde prompt.

Conclusie & Checklist voor kostenefficiënt promptontwerp

Een professionele prompt engineer kijkt niet alleen naar hoe goed een model een taak uitvoert, maar ook naar wat die verwerking kost op schaal. Door prompts op te bouwen met een strikt scheidingsvlak tussen statische prefixes en dynamische variabelen, transformeer je dure API-aanroepen in efficiënte, ge-cachete operaties.

Met deze principes geborgd in je software-architectuur blijft je AI-applicatie niet alleen schaalbaar en snel, maar blijft ook de maandelijkse API-rekening volledig onder controle.