Prijsmodellen per token uitgelegd: input, output en cached
Het afrekenen van API-toegang tot grote taalmodellen (LLM's) gebeurt vrijwel zonder uitzondering op basis van verwerkte eenheden: tokens. Hoewel dit eenvoudiger lijkt dan het huren van vaste infrastructuur, ontstaat er in de praktijk vaak verwarring over de opbouw van de factuur. De kosten per aanroep worden namelijk niet bepaald door één vast tarief, maar door een combinatie van verschillende factoren: invoertokens, uitvoertokens, gecachte status en aanvullende verwerkingsvormen.
Om grip te houden op de uitgaven bij softwareontwikkeling en integraties, is een diepgaand begrip van deze prijsstructuren noodzakelijk. In dit artikel behandelen we hoe tokenprijzen zijn opgebouwd, waarom invoer en uitvoer anders gewaardeerd worden, hoe context caching werkt en welke verborgen variabelen de totale rekening beïnvloeden.
De basis: gescheiden tarieven voor invoer en uitvoer
Aanbieders van AI-modellen hanteren afzonderlijke tarieven voor het verwerken van de vraag (input of prompt) en het genereren van het antwoord (output of completion). In vrijwel alle gevallen ligt het tarief voor uitvoer aanzienlijk hoger dan dat voor invoer.
Dit prijsverschil is een rechtstreeks gevolg van de onderliggende hardware-architectuur en verwerkingstechniek van transformermodellen:
- Invoerverwerking (Parallel): Wanneer een prompt naar het model wordt gestuurd, kan de grafische kaart (GPU) alle invoertokens tegelijkertijd verwerken. Deze bewerking maakt optimaal gebruik van de parallelle rekenkracht van de hardware. De verwerkingstijd per token is daardoor laag, wat zich vertaalt in een lager tarief.
- Uitvoergeneratie (Autoregressief): Het genereren van een antwoord gebeurt stapsgewijs. Het model berekent één token, voegt dit toe aan de context, en berekent vervolgens het volgende token. Dit sequentiële proces vereist dat de gehele modelmatrix bij elke stap opnieuw door het geheugen van de GPU moet worden gehaald. Dit veroorzaakt een bottleneck in geheugenbandbreedte en vergt meer rekenkracht per gegenereerd token, wat het hogere uitvoertarief verklaart.
Kernregel: Een korter antwoord genereren bespaart direct meer geld dan het inkorten van de vraag met een vergelijkbaar aantal tokens.
Gecachte invoer: hoe context caching kosten verlaagt
Bij veel toepassingen, zoals het stellen van vragen over een vaste documentenset of het gebruik van uitgebreide systeemprompts, wordt een groot deel van de invoertekst bij opeenvolgende verzoeken herhaald. Om te voorkomen dat het model deze constante tekst bij elke API-aanroep opnieuw moet verwerken, bieden leveranciers context caching aan.
Wat wordt er goedkoper?
Wanneer een gedeelte van de invoer succesvol uit de cache wordt ingelezen (een cache hit), hoeft de server de rekenintensieve voorverwerking niet te herhalen. Leveranciers berekenen hiervoor een gereduceerd invoertarief. Dit kortingspercentage voor gecachte invoertokens ligt in de praktijk aanzienlijk lager dan het standaard invoertarief.
Voorwaarden voor context caching
Caching werkt niet automatisch op willekeurige teksten. Er geldt een aantal strikte voorwaarden:
- Stabiele prefix: De gecachte tekst moet exact aan het begin van de prompt staan. Zodra er één karakter aan het begin verandert, vervalt het nut van de cache voor de rest van de tekst.
- Minimumlengte: Caching vereist een minimale omvang van de invoertekst. Voor zeer korte prompts weegt de administratieve overhead van de cache niet op tegen de winst.
- Houdbaarheidsduur (TTL): Caches blijven gedurende een beperkte tijd in het geheugen van de server bewaard. Wordt een cache gedurende een bepaalde periode niet aangesproken, dan wordt deze gewist.
Waarom caching zelf ook kosten met zich meebrengt
Het aanhouden van context in het snelle geheugen (VRAM) van een GPU-cluster is kostbaar. Daarom rekenen sommige platformen een aanvullend tarief voor het opslaan van de cache per uur of per minuut dat deze actief blijft. Bij toepassingen met weinig frequente verzoeken kan het opslaan van een cache duurder uitvallen dan het simpelweg opnieuw verwerken van de standaard invoertokens.
Overige posten op de API-rekening
Naast de standaard invoer- en uitvoertokens kunnen er aanvullende verwerkingsvormen op de factuur verschijnen die het kostenplaatje beïnvloeden.
| Post | Omschrijving | Invloed op de kosten |
|---|---|---|
| Redeneertokens | Interne tussenstappen bij gespecialiseerde modellen. | Worden gefactureerd als uitvoertokens, wat de totale prijs per verzoek verhoogt. |
| Tool-calls & functieaanroepen | Geparseerde JSON-structuren voor externe koppelingen. | Tellen mee als invoer- en uitvoertokens, inclusief het meesturen van schema's. |
| Embeddings | Vectorrepresentaties van tekst voor zoeksystemen. | Vast tarief per verwerkt invoertoken. |
| Multimodale invoer | Afbeeldingen, documenten of audio. | Worden omgererekend naar een equivalent aantal teksttokens op basis van resolutie of duur. |
Met name bij het gebruik van redeneermodellen is waakzaamheid geboden. Deze modellen genereren voor de gebruiker onzichtbare 'gedachtengangen' om tot een nauwkeurig antwoord te komen. Al deze interne tokens vallen onder het duurdere uitvoertarief, waardoor de uiteindelijke prijs voor een enkele aanroep flink kan oplopen, zelfs als het uiteindelijke antwoord heel kort is.
Van tokens naar totale kosten per verzoek en per gebruiker
De basisformule voor het berekenen van de kosten van één API-verzoek luidt als volgt:
Kosten = (Ongecachte invoertokens * Tarief_Invoer)
+ (Gecachte invoertokens * Tarief_Cached_Invoer)
+ (Uitvoertokens * Tarief_Uitvoer)
+ Eventuele opslagkosten_cacheIn de praktijk vallen de daadwerkelijke maandfacturen vaak hoger uit dan een initiële schatting op basis van deze formule. Dit komt doordat schattingen voorbijgaan aan een reeks structurele factoren:
- Systeemprompts bij elk verzoek: Een instructie, regelset of roldefinitie moet bij ieder afzonderlijk verzoek worden meegestuurd als de API staatloos is.
- Meegroeiende gespreksgeschiedenis: Bij een chattoepassing wordt met elke opeenvolgende vraag het volledige voorgaande gesprek opnieuw ingestuurd. Het tiende bericht in een sessie kost daardoor een meervoud van het eerste bericht. Om de impact van deze groei te begrijpen, is inzicht in het context window essentieel.
- Hertries en foutafhandeling: Automatische herpogingen bij netwerkfouten, ongeldige JSON-uitvoer of onbevredigende antwoorden genereren extra tokenverbruik zonder dat dit direct zichtbaar is in de uiteindelijke gebruikerservaring.
Waarom een lagere tokenprijs niet altijd goedkoper is
Het is een veelgemaakte denkfout om te veronderstellen dat een model met een lager tarief per miljoen tokens automatisch leidt tot een lagere totale rekening. De totale uitgaven worden bepaald door de vermenigvuldiging van de prijs per token en het aantal gebruikte tokens.
Verschillende kenmerken van een model beïnvloeden de hoeveelheid tokens die nodig is om een specifieke taak te volbrengen:
Verbositeit
Het ene model is van nature beknopt, terwijl het andere model uitgebreide, amicale of gedetailleerde antwoorden formuleert. Een model dat dubbel zoveel woorden gebruikt om hetzelfde antwoord te geven, halveert het prijsvoordeel van een lagere tokenprijs.
Aantal benodigde pogingen
Minder krachtige modellen vereisen vaak complexere, langere prompts met meerdere voorbeelden (few-shot prompting) om tot het gewenste resultaat te komen. Als een compacter model drie pogingen nodig heeft om een correct geformatteerde JSON-structuur op te leveren, is de uiteindelijke verwerking duurder dan één geslaagde aanroep bij een geavanceerder model.
Eerlijk vergelijken: tokenizers en evaluaties
Bij het maken van een vergelijking tussen modelaanbieders is het noodzakelijk om op te passen met directe vergelijkingen op basis van louter de tokenprijzen. Een cruciale factor hierin is de tokenizer die door het model wordt gebruikt.
Een tokenizer zet ruwe tekst om in numerieke tokens. Verschillende modelfamilies maken gebruik van verschillende tokenizers met uiteenlopende vocabulairegroottes. Zo kan dezelfde Nederlandse alinea bij het ene model worden opgesplitst in 100 tokens, terwijl een ander model dezelfde tekst opbreekt in 130 tokens. Een prijsvergelijking per token is pas zuiver wanneer er gemeten wordt op basis van dezelfde invoertekst en dezelfde gewenste output.
Voor een realistisch beeld is het verstandig om het selectieproces te baseren op een gestructureerde aanpak. Het doornemen van de gids voor een geschikt model kiezen helpt bij het afwegen van functionaliteit tegen de uiteindelijke operationele uitgaven. Daarnaast geeft het analyseren van de verhouding tussen kwaliteit versus kosten inzicht in welke prestaties haalbaar zijn binnen een gesteld budget.
Stuurmechanismen voor kostenbeheersing
Ontwikkelaars en systeemarchitecten hebben verschillende knoppen om aan te draaien om het tokenverbruik binnen de perken te houden:
- Promptlengte optimaliseren: Verwijder overbodige opmaak, instructies en redundante voorbeelden uit de systeemprompt.
- Contextvenster-beleid instellen: Snijd oude berichten uit een gespreksgeschiedenis weg (truncation) of vat voorgaande berichten samen zodra een bepaalde drempel wordt bereikt.
- Uitvoerlimieten afdwingen: Stel de parameter
max_tokensin om te voorkomen dat een model bij een ontsporing eindeloze tekst blijft genereren. - Modelrouting: Gebruik lichte, goedkopere modellen voor eenvoudige taken (zoals classificatie of samenvatten) en zet zwaardere modellen alleen in voor complexe redeneerstappen. Voor de concrete uitvoering van de kostencontrole in productie kan gekeken worden naar de opties voor kosten monitoren via API-gateways.
