Inferentiekost

Wat is inferentiekost?

Inferentiekost is wat je betaalt om een model te laten draaien, elke keer opnieuw. Het staat los van wat het model gekost heeft om te trainen, en het staat los van wat jouw project gekost heeft om te bouwen. Het is de lijn die nooit stopt.

Net dat verrast mensen die uit de klassieke software komen. Een rapport dat je één keer bouwt, draait jaren aan de kostprijs van de server eronder. Een AI-functie die je één keer bouwt, heeft een kost per gebruik, voor altijd. De vraag of iets de moeite is om te automatiseren, verandert daardoor van vorm. Het gaat niet meer enkel over de bouwinspanning, het gaat over de kost per keer tegenover de waarde van die keer.

De eenheid is de token. Je prompt wordt geteld in inputtokens, het antwoord in outputtokens, en je factuur is de som van die twee aan verschillende tarieven.

Waar de factuur vandaan komt

Output kost een veelvoud van input. Bij zowat alle aanbieders liggen outputtokens op een veelvoud van inputtokens, vaak rond vijf keer. Dat heeft een rechtstreeks gevolg voor je ontwerp: een systeem dat veel leest en kort antwoordt is goedkoop, en een systeem dat weinig leest en lang schrijft is dat niet. Zoek je besparingen, kijk dan eerst naar de lengte van je antwoorden en pas daarna naar de lengte van je prompts.

Nadenken wordt aangerekend als output. Redeneermodellen maken interne redeneertokens aan voor ze antwoorden. Je krijgt ze nooit te zien, en je betaalt ze aan het outputtarief. Een model dat een tijdje nadenkt en dan drie zinnen geeft, kan je meer kosten dan een model dat drie pagina's schrijft.

Tools voegen inputtokens toe bij elke aanroep. Elke tooldefinitie die je meegeeft, met haar naam, beschrijving en schema, gaat telkens mee in de prompt. Een agent met twintig tools eraan betaalt bij elke beurt voor twintig toolbeschrijvingen, of hij ze nu gebruikt of niet.

Context stapelt op in een gesprek. Bij elke beurt gaat de geschiedenis opnieuw mee. Een gesprek van twintig beurten is geen twintig kleine aanvragen, het is een aanvraag die elke beurt groeit.

De knoppen die echt helpen

Prompt caching. Als een groot stuk van je prompt altijd hetzelfde is, denk aan een lange systeemprompt, een beleidsdocument of een schema, dan kan je de aanbieder dat laten bewaren. Uit die cache lezen kost een fractie van de gewone inputprijs, doorgaans rond een tiende. Naar de cache schrijven kost iets meer dan gewone input, wat betekent dat caching zichzelf al na heel weinig hergebruik terugbetaalt. Bij een supportassistent die bij elke aanvraag dezelfde instructies meestuurt, is dit meestal de grootste besparing die er te rapen valt.

Batchverwerking. Moet het werk niet nu meteen gebeuren, dan bieden aanbieders batchverwerking aan tegen ongeveer de helft van de prijs, op input én output. Tickets van gisteren 's nachts classificeren, een tabel verrijken, in bulk beschrijvingen genereren: allemaal goede kandidaten.

Naar een kleiner model routeren. Niet elke stap heeft je duurste model nodig. Classificeren, gegevens uit tekst plukken en doorverwijzen lukt meestal prima op een klein model tegen een fractie van de prijs, en dan hou je het dure model voor de stap waar echt oordeel bij komt kijken. Hier zit vaak de helft van je factuur.

Gestructureerde output. Een model dat JSON teruggeeft, schrijft geen inleiding en geen slotalinea. Minder outputtokens aan het dure tarief, en makkelijker verwerken achteraf.

Kortere antwoorden vragen. Het model zeggen hoe lang het antwoord mag zijn, is een kostenmaatregel en niet enkel een stijlvoorkeur.

Waarom agents de vorm van je budget veranderen

De cijfers die hier tellen komen van Anthropic, die het op hun eigen werklast gemeten hebben. Eén agent verbruikt ongeveer vier keer zoveel tokens als een gewoon chatgesprek, want hij lust, roept tools aan en leest resultaten terug. Een multi-agentsysteem verbruikt ongeveer vijftien keer zoveel tokens als een chatgesprek.

Lees dat als een grootteorde op hun opdracht en niet als een tarief voor die van jou. Wat overal klopt, is de vorm. Een chatbericht is één aanvraag. Een agent is een onbekend aantal aanvragen, waarvan het model tijdens het draaien beslist hoeveel het er worden en niet jij.

Daar hangt één praktisch gevolg aan dat je best regelt voor je live gaat. Een workflow met drie vaste modelaanroepen heeft een factuur die je kan voorspellen. Een agent die zelf bepaalt hoeveel aanroepen hij doet niet, tot je een harde grens zet op het aantal rondes en op het tokenbudget. Die grens is geen luxe. Ze is het verschil tussen een kost die je kan verdedigen en een verrassing.

Waar moet je op letten bij inferentiekost

De pilootfase voorspelt de productiefactuur nooit. Vijf collega's die een tool uittesten, leveren een afrondingsfout op. Vijfhonderd collega's die ze dagelijks gebruiken niet. Reken dus op volume voor je je vastlegt, en niet erna.

De kost per juist antwoord is het cijfer dat telt. Een goedkoper model dat vaker de mist ingaat, kost je herwerk, en herwerk is duurder dan tokens. Vergelijk op kost per bruikbaar resultaat en niet op prijs per miljoen tokens.

Standaard is niemand eigenaar van de factuur. Als meerdere toepassingen dezelfde modelimplementatie aanroepen, komt de factuur binnen als één getal. Een LLM-gateway ervoor zetten, met tokenmetingen per afnemer, is wat daar een getal per team van maakt.

Nieuwe pogingen zijn onzichtbare uitgaven. Een agent die faalt en het opnieuw probeert, betaalt twee keer. Bestaat je foutafhandeling uit een simpele herhaallus, dan betaal je elke mislukking aan de volle prijs.

Caching verandert wat een aanpassing je kost. Zodra je op prompt caching steunt, maakt een wijziging aan je systeemprompt de cache ongeldig. Dat is op zich prima, maar het betekent wel dat een onschuldig ogende herformulering je factuur voor een dag kan verschuiven.