Wat kost een token? Rekenen aan contextlengte, invoer en uitvoer

Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini) · Laatst bijgewerkt: 7 augustus 2026

Wat je hiervoor moet weten: Dit artikel bouwt voort op basiskennis van taalmodellen binnen het onderwijscurriculum. Raadpleeg Tokenisatie uitgelegd om te begrijpen hoe tekst precies wordt opgedeeld in rekenbare subwoorde-eenheden. Dit artikel legt uit welke algoritmes teksten opsplitsen, wat essentieel is voor het inschatten van tokenaantallen. Bekijk Parameters en gewichten voor inzicht in de interne rekenstructuur van grote taalmodellen. Deze pagina biedt achtergrondinformatie over de wijze waarop modelgrootte en geheugenbeslag samenhangen. Sla de AI-begrippenlijst open indien specifieke vaktermen verheldering behoeven. Dit overzicht helpt lezers om definities van vakjargon snel op te zoeken.

Artikel gecontroleerd op 2026-08-07.

1. Inleiding: De noodzaak van een heldere token-economie

In het voorgestelde leerpad voor ontwikkelaars vormt deze handleiding module 1 (Fundamenten, oriëntatie). Wie begint met het bouwen van applicaties bovenop Large Language Models (LLM's) via API-interfaces, merkt snel dat de financiële structuur fundamenteel verschilt van traditionele software. In klassieke cloud-architecturen worden kosten doorgaans berekend per CPU-uur, per gigabyte geheugengebruik of per uitgaande netwerktransactie. Bij taalmodellen vormt het token daarentegen de primaire verrekeneenheid. Hoewel het begrip token in inleidende documentatie regelmatig wordt aangestipt, blijven de exacte financiële consequenties voor productieomgevingen vaak onderbelicht.

De vraag "wat kost een token?" kan niet met één vast getal worden beantwoord. De kosten van een API-call hangen af van de verhouding tussen de ingestuurde tekst en de gegenereerde respons, de totale omvang van de context, en het eventuele gebruik van herhalingsmechanismen zoals caching. Wie zonder rekenmodel een applicatie in productie neemt, kan geconfronteerd worden met maandfacturen die factoren hoger liggen dan de initiële inschattingen. Om verrassingen te voorkomen, ontleedt dit artikel de token-economie tot op de eurocent aan de hand van wiskundige formules en praktijkgerichte rekenvoorbeelden.

Het doel van deze module is het verschaffen van een mechanisch inzicht in de kostenstructuur. Het artikel onthoudt zich van adviezen voor of tegen het gebruik van lange contextvensters of specifieke commerciële aanbieders. In plaats daarvan biedt het de rekenkundige onderbouwing en objectieve beslisregels waarmee bouwwerkzaamheden budgettair voorspelbaar kunnen worden ingeregeld.

2. Waar de rekening uit bestaat: Input- versus outputtokens

Wanneer een verzoek naar een LLM-API wordt verstuurd, splitst de provider de facturatie op in twee hoofdcategorieën: inputtokens en outputtokens. De totale kosten van een enkele API-call worden gedefinieerd door de som van beide variabelen, vermenigvuldigd met hun respectievelijke tarieven.

Inputtokens omvatten alle informatie die de client naar het model verzendt. Dit bestaat uit de systeem-prompt (instructies voor de rol en het gedrag van het model), de contextuele informatie (zoals opgehaalde documenten, database-resultaten of code-bestanden) en de volledige eerdere gespreksgeschiedenis. Outputtokens zijn de tokens die het model tijdens de inferentie-fase genereert en terugstuurt naar de client.

Lees Prijsmodellen per token uitgelegd op hub.llmnet.nl voor een gedetailleerd overzicht van commerciële contractvormen bij API-leveranciers. Die pagina vergelijkt pay-as-you-go tarieven met gereserveerde capaciteit en volumekortingen.

Bij vrijwel elke commerciële API-aanbieder ligt het tarief voor outputtokens aanzienlijk hoger dan dat voor inputtokens. Een gemiddelde verhouding is dat outputtokens drie tot vier keer zo duur zijn per eenheid. Dit prijsverschil is niet willekeurig, maar vloeit rechtstreeks voort uit de hardwarematige verwerking op de grafische processoren (GPU's) van de provider:

• Prompt Prefill Phase (Input): De inputtokens worden door het model in één grote parallelle matrixvermenigvuldiging verwerkt. Omdat alle invoertokens tegelijkertijd bekend zijn, kan de rekenkracht van de GPU (de Tensor Cores) optimaal worden benut. Deze fase is voornamelijk rekengebonden (compute-bound) en verloopt zeer efficiënt.
• Autoregressive Generation Phase (Output): Het model moet outputtokens één voor één genereren. Elk nieuw gegenereerd token dient als invoer voor de volgende stap. Hierdoor moet het model bij elk afzonderlijk token alle miljarden parameters opnieuw uit het VRAM-geheugen van de GPU naar de rekenkernen laden. Deze fase is strikt geheugenbandbreedte-gebonden (memory-bandwidth bound), waardoor de hardwarematige bezetting per token veel minder efficiënt is.

Zie Context engineering uitgelegd voor technieken om de inhoud van de context window efficiënt in te richten. Op die pagina leert u hoe u overbodige opmaak en geschiedenis verwijdert zonder informatieverlies.

3. De invloed van contextlengte op het prijsverloop

Een veelvoorkomende misvatting bij het bouwen van LLM-applicaties is het idee dat men alleen betaalt voor de 'nieuwe' tekst die in een chatgesprek wordt getypt. De API-interfaces van moderne taalmodellen zijn echter staatloos (stateless). Het model onthoudt geen eerdere interacties tussen opeenvolgende HTTP-verzoeken.

Dit betekent dat bij elke interactie in een doorlopend gesprek de volledige historie opnieuw moet worden meegeleverd. Bij een chattoepassing waarbij de gebruiker tien opeenvolgende vragen stelt, verzendt de client bij de tiende vraag niet alleen die tiende vraag, maar ook het systeem-prompt, vraag 1 tot en met 9, en antwoord 1 tot en met 9. Het aantal inputtokens groeit daardoor cumulatief bij elke interactie.

Daarnaast speelt de schaalbaarheid van de 'attention'-matrix in de transformer-architectuur een rol. De rekenkundige complexiteit van de standaard self-attention operatie schaalt kwadratisch met de lengte van de context. Hoewel moderne varianten zoals FlashAttention deze rekenkracht op hardwareniveau optimaliseren, blijft het geheugenbeslag van de sleutel- en waardeparen (de KV-cache) lineair meegroeien met elke extra token in de context. Wanneer het contextvenster groeit van 2.000 naar 100.000 tokens, stijgt de hoeveelheid data die per verzoek in het GPU-geheugen gefixeerd moet blijven met een factor vijftig.

Wanneer een ontwikkelaar een document van 100.000 tokens in het contextvenster plaatst om daar vijf opeenvolgende vragen over te stellen, betaalt de ontwikkelaar de inputkosten voor die 100.000 tokens niet één keer, maar vijf keer. Zonder aanvullende optimalisaties leidt dit tot een steile, cumulatieve kostenstijging.

4. Drie uitgewerkte rekenvoorbeelden met concrete euro-bedragen

Om de financiële mechanica inzichtelijk te maken, volgen hieronder drie uitgewerkte scenario's. Belangrijke waarschuwing: alle genoemde euro-bedragen en tarieven in deze voorbeelden zijn fictieve aannames binnen een rekenmodel met peildatum 2026-08-07. Deze bedragen dienen uitsluitend om de berekeningswijze te illustreren en vertegenwoordigen geen werkelijke marktprijzen of gegarandeerde offertes.

Aannames voor de rekenmodellen (Peildatum 2026-08-07)

Voor de onderstaande berekeningen hanteren we de volgende fictieve basistarieven voor een hypothetisch geavanceerd taalmodel:

• Ongecachete inputtokens: €0,0025 per 1.000 tokens (€2,50 per 1.000.000 tokens).
• Gecachete inputtokens: €0,0005 per 1.000 tokens (€0,50 per 1.000.000 tokens).
• Outputtokens: €0,0100 per 1.000 tokens (€10,00 per 1.000.000 tokens).

Scenario A: Een korte chat-call (Lichte interactie)

In dit scenario stelt een gebruiker een eenvoudige vraag aan een klantenservicebot. De context bestaat uit een korte systeem-prompt en de gebruikersvraag. Er vindt geen caching plaats.

• Input: 1.800 tokens (systeem-prompt) + 200 tokens (vraag) = 2.000 inputtokens.
• Output: 200 tokens (antwoord).
• Inputkosten: (2.000 / 1.000) * €0,0025 = €0,0050.
• Outputkosten: (200 / 1.000) * €0,0100 = €0,0020.
• Totaal per call: €0,0070.

Scenario B: Nederlandse casus - RAG op een juridische kennisbank (30k context)

Een Nederlandse gemeente gebruikt een Retrieval-Augmented Generation (RAG) systeem om beleidsstukken te doorzoeken. Bij elke vraag van een ambtenaar haalt het systeem 30.000 tokens aan relevante Nederlandse wet- en regelgeving op en voegt deze toe aan het prompt. Het model genereert een samenvattend antwoord van 500 tokens.

Variant B1 (Ongecachet): Elk verzoek bevat unieke beleidsstukken of het systeem maakt geen gebruik van context caching.

• Input: 30.000 tokens.
• Output: 500 tokens.
• Inputkosten: (30.000 / 1.000) * €0,0025 = €0,0750.
• Outputkosten: (500 / 1.000) * €0,0100 = €0,0050.
• Totaal per call (ongecachet): €0,0800.

Variant B2 (Gecachet): De 30.000 tokens aan beleidsteksten vormen een vaste statische basis die door meerdere ambtenaren gedurende de dag herhaaldelijk wordt geraadpleegd. De provider herkent het statische gedeelte en rekent daar het voordeligere cache-tarief voor.

• Input gecachet: 29.000 tokens a €0,0005 per 1k = €0,0145.
• Input nieuw (ongecachet): 1.000 tokens a €0,0025 per 1k = €0,0025.
• Output: 500 tokens a €0,0100 per 1k = €0,0050.
• Totaal per call (gecachet): €0,0220. (Een reductie van 72,5% op de totale call-kosten).

Scenario C: Documentverwerking (100k context)

Een financieel analist voert een compleet jaarverslag van 100.000 tokens in en vraagt het model om een gestructureerde risicoanalyse van 2.000 tokens te genereren. Dit is een eenmalige, zware verwerkings-call zonder caching.

• Input: 100.000 tokens.
• Output: 2.000 tokens.
• Inputkosten: (100.000 / 1.000) * €0,0025 = €0,2500.
• Outputkosten: (2.000 / 1.000) * €0,0100 = €0,0200.
• Totaal per call: €0,2700.

Vergelijkend overzicht rekenvoorbeelden (Aannames per 2026-08-07)

Onderstaande tabel vat de rekenresultaten samen en laat de financiële impact zien bij een schaal van 1.000 verzoeken per dag.

5. Wanneer caching werkt (en wat de beperkingen zijn)

Om de verwerkingskosten van herhaalde grote contexten te drukken, bieden diverse API-providers mechanismen voor context caching. De technische basis hiervan is het hergebruiken van de reeds berekende KV-cache op de GPU-servers van de provider, zodat het model de prompt prefill-fase voor bekende tekstsegmenten niet opnieuw hoeft uit te voeren.

Bestudeer KV-caching opbouw voor de diepere technische werking van de Key-Value cache in de transformer-architectuur. Dit artikel legt uit hoe activatiewaarden in het GPU-geheugen worden vastgehouden tijdens inferentie.

Raadpleeg Context caching uitgelegd op hub.llmnet.nl om te beoordelen welke API-providers automatische of handmatige caching ondersteunen en wat de financiële drempelwaarden zijn. Op dat platform vindt u marktbrede vergelijkingen van cache-integraties.

De mechanica van prijsereductie bij caching

Wanneer een client een verzoek instuurt waarvan de eerste $N$ tokens identiek zijn aan een eerder ingestuurd verzoek, kan de provider de KV-cache van het geheugenadres aflezen. Dit levert twee voordelen op: de latentie (tijd tot de eerste gegenereerde token) daalt drastisch, en de provider rekent een gereduceerd tarief voor de gecachete inputtokens (in het rekenvoorbeeld een korting van 80%).

Zwakke punten en beperkingen van context caching

Context caching is geen universele oplossing en kent duidelijke operationele nadelen:

• Strikte prefix-afhankelijkheid: Caching werkt bij de meeste providers uitsluitend vanaf het allereerste token van het verzoek. Als u een variabele waarde (zoals een uniek gebruikers-ID of een wisselende tijdstempel) bovenaan uw prompt plaatst, vervalt de cache-overeenkomst voor de gehele daaropvolgende tekst van 100.000 tokens. Dynamic content moet daarom altijd achteraan de prompt worden toegevoegd.
• Minimale volumegrenzen: Veel API-providers hanteren een minimale drempelwaarde voordat caching geactiveerd wordt (bijvoorbeeld minimaal 1.024 of 32.768 tokens). Voor korte prompts biedt caching daarom geen enkel financieel voordeel.
• Houdbaarheid en Cache Expiration (TTL): De opgeslagen KV-cache blijft slechts een beperkte tijd (Time-To-Live) op het GPU-geheugen bewaard (vaak variërend van 5 minuten tot enkele uren). Als er gedurende die periode geen nieuwe verzoeken met dezelfde prefix binnenkomen, wordt de cache gewist. Bij lage verwerkingsvolumes betaalt de ontwikkelaar soms zelfs extra 'opslagkosten' per uur om de cache actief te houden, wat bij sporadisch gebruik duurder kan uitvallen dan ongecachete verzoeken.
• Geen korting op outputtokens: Caching heeft uitsluitend betrekking op de inputfase. De verwerking van de outputtokens blijft tegen het volledige, hoge tarief gefactureerd worden.

6. De verborgen kosten in productieomgevingen

Ontwikkelaars die een budget opstellen op basis van ideale testscenario's, komen in productieomgevingen regelmatig voor onvoorziene kosten te staan. Deze verborgen kosten ontstaan door operationele randverschijnselen die het aantal verwerkte tokens ongemerkt vermenigvuldigen.

1. Onvoorspelbare outputlengtes

Hoewel een ontwikkelaar de lengte van de input vrij nauwkeurig kan controleren, is de lengte van de gegenereerde output inherent stochastisch. Wanneer een model getriggerd wordt om in een 'loop' te raken, uitgebreide JSON-structuren te genereren, of lange beredeneringen (chain-of-thought) uit te schrijven, schieten de duurste tokens (de outputtokens) omhoog. Zonder een strikte instelling van de parameter max_tokens kan een enkel ontspoord verzoek het honderdvoudige van de gebudgetteerde outputkosten verbruiken.

2. Agentic loops, tools en automatische retries

In moderne AI-architecturen worden modellen ingezet als 'agents' die zelfstandig functies en tools aanroepen. Wanneer een model een foutief geformatteerde functie-aanroep genereert, stopt de applicatie niet. De foutmelding wordt teruggevoerd in de context, waarna het model een nieuwe poging doet. Een enkele gebruikersvraag kan hierdoor achter de schermen resulteren in vier of vijf opeenvolgende API-calls. Inclusief de telkens meegestuurde context vermenigvuldigt het input-tokenvolume zich exponentieel.

3. Rate limits en de financiële impact van herhaalde verzoeken

Wanneer een productie-applicatie tegen de limieten van een API-provider aanloopt (Rate Limits uitgedrukt in Requests Per Minute of Tokens Per Minute), vallen verzoeken uit met HTTP-statuscode 429. Wanneer de client-toepassing niet correct is geconfigureerd met een 'exponential backoff'-strategie, worden afgebroken of mislukte verzoeken opnieuw ingestuurd. Voor verzoeken die halverwege de verwerking zijn geannuleerd, berekenen sommige providers alsnog de reeds verwerkte inputtokens, wat leidt tot directe kapitaalvernietiging.

Ga naar Rate limits en kosten op api.llmnet.nl om te zien hoe verwerkingslimieten uw operationele uitgaven indirect beïnvloeden. Dit overzicht helpt ontwikkelaars bij het ontwerpen van foutbestendige retry-mechanismen.

Bezoek Kosten monitoren op api.llmnet.nl voor praktische handleidingen over het instellen van budgetnotificaties en automatische uitvalschakelaars. Deze bron toont hoe u onverwachte kostenoverschrijdingen in productiesystemen voorkomt.

7. Meten in plaats van aannemen: Verbruik per call analyseren

Om grip te houden op de token-economie mogen ontwikkelaars niet vertrouwen op schattingen op basis van woordaantallen. De verhouding tussen het aantal woorden in een tekst en het aantal gegenereerde tokens varieert sterk per taal en per type invoer. Nederlandse teksten verbruiken gemiddeld 15% tot 40% meer tokens dan Engelse teksten voor exact dezelfde inhoud, omdat tokenizer-vocabulaires primair op Engelstalige corpora zijn getraind.

Het uitlezen van API-metadata

Vrijwel elke API-provider levert bij een succesvolle respons een JSON-payload mee met de exacte telemetrie van het verzoek. In plaats van zelf het aantal tokens te schatten, dient een productiesysteem deze waarden direct uit te lezen en op te slaan in de eigen logbestanden.

Een standaard respons-meta-object ziet er conceptueel als volgt uit:

• prompt_tokens: Het exacte aantal verwerkte inputtokens.
• completion_tokens: Het exacte aantal gegenereerde outputtokens.
• cached_tokens: (Indien van toepassing) Het deel van de prompt_tokens dat uit de cache is opgehaald.
• total_tokens: De som van de invoer en uitvoer.

Bekijk Token usage normalisatie bij providers op api.llmnet.nl om te begrijpen hoe respons-metadata tussen verschillende API's kan worden omgevormd tot één standaardformaat. Die pagina bevat voorbeelden voor het combineren van telemetrie uit diverse API-responses.

Prijs per token versus kosten per taak

Een cruciale stap in de kostenanalyse is de verschuiving van de metriek "prijs per token" naar "kosten per afgeronde taak". Een goedkoper model per token is niet per definitie goedkoper per taak. Als een kleiner, goedkoper model 1.500 outputtokens en drie herhaalpogingen nodig heeft om een gestructureerd JSON-bestand correct op te leveren, terwijl een duurder, groter model dezelfde taak foutloos uitvoert in 200 outputtokens, is het duurdere model per saldo goedkoper voor de totale bedrijfsvoering.

Raadpleeg Kosten per taak op benchmark.llmnet.nl om de daadwerkelijke kosten van uiteenlopende modelgroottes per specifieke bedrijfstaak te vergelijken. Deze benchmark meet hoeveel geld een afgeronde taak kost in plaats van losse tokens.

8. Lokaal draaien versus API-gebruik: De fysieke rekenbalans

Wanneer de geschatte API-kosten voor een project toenemen, overwegen organisaties regelmatig om over te stappen op het lokaal hosten van open-weight modellen (zoals Llama- of Mistral-varianten) op eigen hardware of via dedicated cloud-instanties (bijvoorbeeld met vLLM of Ollama). Binnen de token-economie betekent dit een overstap van een variabel operationeel kostenmodel (OpEx) naar een vast investerings- en infrastructuurmodel (CapEx / vaste OpEx).

De vergelijking van kostenstructuren

Bij het gebruik van een commerciële API betaalt u uitsluitend voor de daadwerkelijk verwerkte tokens. Als een systeem ’s nachts niet wordt gebruikt, bedragen de API-kosten nul euro. Bij het lokaal of dedicated hosten van een model op een GPU-server (zoals een Nvidia H100 of A10G instantie) betaalt u een vast tarief per uur, ongeacht of de GPU 100% belast is of volledig stilstaat.

De kostprijs per token van een lokale GPU-opstelling laat zich berekenen door de totale operationele kosten van de server te delen door de totale token-throughput over een gegeven periode:

• Hardware-afschrijving of serverhuur: Het vaste bedrag per maand voor de dedicated hardware.
• Energieverbruik: Het daadwerkelijke stroomverbruik van de GPU's, CPU's en koelsystemen onder belasting, vermenigvuldigd met de lokale kWh-prijs.
• Beheersoverheid: De loonkosten van de ontwikkelaars of system administrators die verantwoordelijk zijn voor de opschaling, beveiliging en het onderhoud van de inferentie-cluster.

Lees Stroomverbruik bij lokale AI op gids.llmnet.nl voor de fysieke berekening van kWh-verbruik, hardware-afschrijving en koeling bij eigen servers. Die gids biedt de nodige parameters om de TCO van lokale hardware af te wegen tegen cloud-API's.

Wanneer is lokaal financieel voordeliger?

Een lokale opstelling is rekenkundig pas voordeliger wanneer de bezettingsgraad van de GPU continu hoog is (bijvoorbeeld bij constante batch-verwerking van miljoenen documenten) en wanneer de contextlengtes binnen het beschikbare VRAM-geheugen van de eigen videokaarten passen. Bij wisselvallige belasting of extreem grote contextvensters blijven API-providers financieel efficiënter vanwege hun schaalvoordelen en het dynamisch delen van GPU-capaciteit over duizenden klanten.

9. Beslisregels en zwakke punten van dit artikel

Synthese: Beslisregels voor de bouwer

Om de token-economie beheersbaar te houden binnen software-architecturen, kunnen de volgende rekenkundige beslisregels worden gehanteerd:

1. Scheid statische en dynamische context: Plaats vaste instructies, documenten en sjablonen aan de voorkant van de prompt en dynamische variabelen aan de achterkant, zodat u optimaal gebruikmaakt van automatische context caching.
2. Beperk de outputlengte expliciet: Stel altijd een harde bovengrens in op de gewenste respons-tokens via de API-parameters om ontsporingen in kosten te voorkomen.
3. Kies het model op basis van taakcomplexiteit: Gebruik lichte, goedkope modellen voor classificatie, extractie en eenvoudige tekstbewerking. Bewaar de zwaardere, duurdere modellen voor ingewikkelde redeneerstappen en eindsyntheses.
4. Snoei de gespreksgeschiedenis: Implementeer een 'sliding window' of vat eerdere gespreksrondes samen in plaats van de volledige chat-historie onbeperkt door te sturen bij elke nieuwe vraag.
5. Monitor op taakniveau: Log de exacte waarden uit de API-metadata en bereken de kosten per succesvol afgeronde bedrijfstransactie, niet per losse call.

Zwakke punten en beperkingen van dit artikel

In overeenstemming met de redactierichtlijnen wijzen we de lezer op de inherente beperkingen en zwakke punten van de analyses in dit artikel:

• Prijsvolatiliteit in de markt: Prijzen van AI-providers veranderen frequent. De in dit artikel gehanteerde tarieven en rekenvoorbeelden zijn expliciet gebaseerd op fictieve aannames met peildatum 2026-08-07. Ze kunnen niet worden gebruikt als garantie voor actuele commerciële tarieven.
• Taal-specifieke afwijkingen: De exacte kosten per pagina tekst verschillen per taal. Omdat tokenizers efficiënter zijn in het verwerken van Engels dan van Nederlands, zijn alle aannames over token-aantallen afhankelijk van de gebruikte taal en de specifieke tokenizer van het gekozen model.
• Vereenvoudiging van hardware-architectuur: In de praktijk hanteren providers aanvullende optimalisaties (zoals Quantization, Speculative Decoding en PagedAttention) die de interne kostprijs beïnvloeden. Dit artikel behandelt de API-kosten vanuit de externe gebruiker en negeert de interne margeopbouw van de leveranciers.
• Geen rekening gehouden met netwerk-egress en latency-kosten: De rekenmodellen focussen uitsluitend op token-tarieven. Eventuele kosten voor netwerkverbindingen, data-overdracht tussen regio's of vertragingsschade voor de bedrijfsvoering zijn niet in de formules opgenomen.

Artikel gecontroleerd op 2026-08-07.

Hierna verder met: Nu u de basis van de token-economie beheerst, kunt u een niveau dieper duiken in de praktische optimalisatie van contexten en geheugenstructuren. Lees Context engineering uitgelegd om te leren hoe u prompts opbouwt voor minimale token-belasting, of bestudeer KV-caching opbouw voor een diepgaande technische analyse van geheugen-optimalisatie op GPU-niveau.