Kosten per route versus de maandfactuur: meet waar het geld naartoe gaat

Een maandfactuur voor AI vertelt je hoeveel je hebt uitgegeven; meten per route vertelt je welk werk dat geld uitgaf. Eén route kan twee keer zo duur worden terwijl een daling elders het totaal vlak houdt. En stijgt de rekening wel, dan weet je nog steeds niet wat er gebeurde: meer aanvragen, meer tokens per aanvraag, vaker een retry of een ander model op de route?

Hoofdstuk 9 van Het model-portfolio bouwt dat onderscheid op rond kostenattributie: meet eerst de routingregel die het geld uitgaf en koppel die daarna aan de feature en het team dat ervoor verantwoordelijk is. Zo wordt een vage opdracht om te bezuinigen een review van één benoemde route. De meter wijst aan waar je moet zoeken; logs en tests moeten de oorzaak daarna vaststellen.

Hoe houd je LLM-kosten per feature bij in plaats van op één maandfactuur?

Geef elke modelaanroep een routelabel, een featurelabel en een eigenaar. Leg verbruik en doorlooptijd vast, reken de kosten uit en tel ze over een vaste periode op per route. Tel daarna de kosten van alle routes van een feature op voor het featuretotaal.

Een route is hier een benoemde routingregel of een taaktype, zoals kennis.antwoord. Een feature, in het boek een productoppervlak, is wat dat werk bedient, bijvoorbeeld een interne kennisassistent. Eén feature kan meerdere routes gebruiken. Bedient een route meerdere features, geef dan bij elke aanroep het featurelabel mee, zodat je de kosten zuiver kunt verdelen.

Je kijkt steeds naar dezelfde kosten, op een hoger niveau opgeteld: poging → route → feature → budgeteigenaar. Tel het subtotaal van een route dus niet nog eens op bij dat van de feature, want dan tel je hetzelfde geld dubbel. ‘Kosten per route’ is hier het totaal van een route over een gekozen periode; ‘kosten per aanvraag’ is een aparte deling.

Houd de routenaam gelijk als het model eronder wisselt, en leg het model in een apart veld vast. Anders wordt elke maandvergelijking een zoektocht naar werk dat onderweg van naam veranderde. In Wat is modelroutering? lees je wat zo’n beleid per route vastlegt; hier gaat het om het meten van de gevolgen.

Leg in je bestaande logs deze groepen velden vast:

Onderdeel	Wat je vastlegt	Wat je ermee controleert
Attributie	Route, feature, budgeteigenaar	Welk werk de kosten veroorzaakte
Identiteit	Oorspronkelijk aanvraag-ID, poging-ID, tijdstempel	Welke aanroepen bij dezelfde aanvraag horen
Toewijzing	Werkelijk model, aanbieder en serviceniveau	Of de toewijzing is veranderd
Verbruik	Input, output en relevante factuurcategorieën	Welke verbruikspost is gegroeid
Doorlooptijd	Totale tijd van begin tot eind; tijd tot eerste token bij streaming	Of gebruikers langer wachten
Uitvoering	Resultaat, aantal retry’s en escalatievlag	Of extra pogingen de uitgaven verklaren

Een overzicht per model kan deze toewijzing niet maken zodra meerdere features hetzelfde model delen. Een spreadsheet op basis van gelabelde logexports kan dat wel. Begin bij de labels en bij het besluit dat je ermee wilt nemen.

Hoe bereken je de kosten per route en per aanvraag?

Deel per gefactureerde verbruikscategorie het aantal door de rekeneenheid van het tarief en vermenigvuldig met het geldende tarief. Tel de categorieën één keer op. Bewaar het tarief en de ingangsdatum bij de berekening, zodat je kunt zien of je verbruik veranderde of de prijs.

Maak factuurregels die elkaar niet overlappen, volgens de definities van je aanbieder. Een totaal en de uitsplitsing ervan zijn geen losse bedragen om bij elkaar op te tellen. Kijk eerst hoe je aanbieder input uit de cache en redeneertokens meetelt voordat je er een prijs aan hangt; Zo lees je een AI-rekening legt die soorten tokens uit.

Tel elke gefactureerde poging op die aan de route is toegewezen en voeg tijdgebonden routekosten toe, zoals cache-opslag per uur. Ook een mislukte poging waarvoor je betaalt, hoort in het totaal. Ontbreekt een verbruiksveld, dan is dat verbruik onbekend, niet nul.

Houd de noemer expliciet:

Kosten per route-aanvraag = alle toegewezen routekosten ÷ oorspronkelijke aanvragen op die route.

Gefactureerde retry’s en escalaties tellen mee in de kosten; de oorspronkelijke aanvraag telt één keer in de noemer. Pogingen volg je apart. Voor de kosten per afgeronde taak van een feature tel je alle kosten op die via de routes van die feature zijn toegewezen, en deel je door het aantal afgeronde taken in dezelfde periode. Zet bij elk getal door welke eenheid je deelt: een aanvraag, een poging en een afgeronde taak zijn verschillende maten.

Sluit de toegewezen totalen aan op de factuur van je aanbieder, over dezelfde periode en op dezelfde grondslag. Zet toeslagen, tegoeden en onverklaarde verschillen op aparte regels. Missen oudere logregels een featurelabel, markeer een verdeling achteraf dan als schatting en laat het niet-toegewezen deel apart staan. Een exact maandtotaal maakt een geschatte verdeelsleutel niet exact.

Wat kan een vlakke maandfactuur verbergen? Een hypothetisch voorbeeld

Neem een klein softwareproduct met drie routes. Alle cijfers hieronder zijn verzonnen. Elke aanvraag doet één geslaagde, gefactureerde modelaanroep; er zijn geen retry’s, geen caching, geen verborgen redeneertokens en geen andere kosten. Elke route bedient één feature.

Route	Aanvragen vorige maand	Kosten vorige maand	Aanvragen deze maand	Kosten deze maand
support.chat	40.000	€ 800	40.000	€ 800
kennis.antwoord	10.000	€ 600	10.000	€ 1.200
catalogus.verrijk	20.000	€ 1.600	20.000	€ 1.000
Totaal	70.000	€ 3.000	70.000	€ 3.000

Factuur en totaal aantal aanvragen zijn gelijk gebleven. Toch zijn de kosten per aanvraag op kennis.antwoord verdubbeld, van € 0,06 naar € 0,12. De besparing van € 600 op catalogus.verrijk valt precies weg tegen de stijging van € 600 op kennis.antwoord.

Reken de kennisroute door met verzonnen tarieven van € 2 per miljoen inputtokens en € 6 per miljoen outputtokens, in beide maanden gelijk. Vorige maand gebruikte elke aanvraag 24.000 inputtokens en 2.000 outputtokens:

24.000 ÷ 1.000.000 × € 2 + 2.000 ÷ 1.000.000 × € 6 = € 0,06.

Nu stuurt elke aanvraag 54.000 inputtokens mee, terwijl de output op 2.000 blijft:

54.000 ÷ 1.000.000 × € 2 + 2.000 ÷ 1.000.000 × € 6 = € 0,12.

Bij 10.000 aanvragen is dat € 600 en € 1.200. Omdat het volume gelijk bleef, valt meer verkeer in dit voorbeeld af als verklaring. De uitsplitsing per categorie wijst naar de input.

Stel dat je in de logs een contextblok van 30.000 tokens vindt dat een promptwijziging heeft toegevoegd. Hoofdstuk 9 opent met een samengestelde casus van hetzelfde type: een herstructurering van de prompt voegde bij elke aanvraag op een interne kennisroute een volledige documentsamenvatting toe, en wekenlang merkte niemand het, omdat de antwoorden er voor gebruikers hetzelfde uitzagen. Toets of het blok nodig is voor goede antwoorden voordat je het weghaalt. De rekensom laat zien wat het kost, niet wat het waard is.

Was het aantal aanvragen verdubbeld bij gelijke kosten per aanvraag, dan zou je eerst uitzoeken waar het extra verkeer vandaan kwam. Sleutelen aan het model lost dan het verkeerde probleem op.

Welke signalen horen naast de kosten?

Hoofdstuk 9 bundelt de operationele metingen in vijf signalen: tokenvolume, kosten, latentiepercentielen, het aantal routingbeslissingen en het escalatiepercentage. Houd ze bij elkaar. Kosten laten zien waar het geld zit; de andere vier helpen verklaren wat er verschoof.

Geef elke route één rij op het dashboard: de kosten van de afgelopen zeven dagen tegen het weekbudget, de p95-latentie tegen de SLO, het escalatiepercentage waar dat van toepassing is en de volumetrend. Zet erbij hoe lang een overschrijding al duurt, wie de eigenaar is en wanneer de volgende review is.

De p95-latentie is de doorlooptijd waarbinnen ongeveer 95% van de gemeten aanvragen klaar is. Meet de hele route, van binnenkomst tot afgeleverd antwoord. Houd p50 en p99 achter de hand voor diagnose en leg bij gestreamde antwoorden de tijd tot het eerste token apart vast. Kies een meetvenster en een minimale steekproef die passen bij het verkeer op de route.

Terug naar het hypothetische product. Stel dat support.chat nog steeds € 800 kost, maar dat de p95 oploopt van 0,8 naar 1,4 seconden bij een SLO van één seconde. De kostenregel is onveranderd; de latentieregel vraagt aandacht. Wie alleen naar kosten kijkt, mist die achteruitgang.

Escaleert een route aanvragen naar een ander model, leg dan vast welk deel escaleert en wat beide stappen kosten. Een stijging wijst op veranderde input, kwaliteit of escalatiecriteria, zonder te zeggen welke van de drie.

Wanneer moet een route-alert tot een review leiden?

Leid het budget af uit het verwachte verkeer en het beoogde verbruik, inclusief geplande retry’s en escalaties. Maak van wat de route nu kost niet ongemerkt de norm, want dan budgetteer je bestaande verspilling mee. Tel de routebudgetten over dezelfde periode op en controleer of ze binnen het totale modelbudget van het product passen.

Hoofdstuk 9 gebruikt 75% van het weekbudget van een route als illustratieve vroege waarschuwing: laag genoeg om nog in te grijpen voordat het budget op is. Stel dat de hypothetische route kennis.antwoord per week 2.500 aanvragen verwerkt tegen de beoogde € 0,06 per stuk. Het budget is dan € 150 en de waarschuwing ligt op € 112,50.

Leg eerst de klok vast. Tel je vanaf het begin van de budgetweek, dan passeert een route die gelijkmatig volgens plan uitgeeft € 112,50 op dag zes. Gebeurt dat al halverwege de week, dan geeft de route veel sneller uit dan gepland: dat is het signaal. Op een voortschrijdend totaal over zeven dagen, de weergave in het dashboard van het hoofdstuk, staat een route volgens plan elke dag rond € 150, en dan gaat een waarschuwing op 75% nooit meer uit. Zet de waarschuwing daarom op de budgetweek. Ze vraagt iemand om naar de route te kijken; ze bewijst geen verspilling.

Als eerste vuistregel voor een review noemt het hoofdstuk een budgetoverschrijding die langer dan 72 uur aanhoudt. Die klok start pas als de uitgaven boven het budget zelf komen, niet bij de waarschuwing op 75%. Pas het venster aan op het volume, de latentieklasse en het risico van de route. Een duidelijke ontsporing pak je meteen aan.

Latentie heeft een eigen waarschuwing: het hoofdstuk begint bij 80% van de p95-SLO en stelt die drempel bij na valse alarmen en gemiste incidenten. Een overschrijding van de SLO zelf die gedurende het hele venster van de route aanhoudt, van uren bij real-time routes tot zeven dagen bij batch, leidt tot een review. Dat geldt ook voor een escalatiepercentage dat zeven dagen of langer boven 150% van de basislijn ligt, en voor elke nieuwe route of elk nieuw model zonder budget en SLO. Die horen vast te staan vóór er productieverkeer komt, of uiterlijk binnen 24 uur als de route ongemerkt langs de poort glipte.

Geef elke alert een eigenaar en een vaste eerste stap: vergelijk volume, tokencategorieën, modeltoewijzing en retry’s met de vorige periode. Sluit de review af met wat er veranderde, waarom, en wanneer je opnieuw kijkt. Een alert meldt een toestand. Een bestedingsplafond afdwingen is een aparte maatregel; hoe je dat per taak inricht, lees je in Agent-runtimebudget: houd retry’s binnen hetzelfde plafond.

Welke vragen laat dit dashboard open?

De duurste route is een goed startpunt, maar niet automatisch de slechtste besteding. Misschien doet juist die route het waardevolste werk. Een goedkoper model, een kortere prompt of een andere escalatieregel heeft eerst een eigen kwaliteitstest nodig voordat je de wijziging accepteert.

Modelkosten laten bovendien veel van wat een feature kost buiten beeld, tenzij je het expliciet toevoegt: infrastructuur, betaalde tools en menselijke controle, bijvoorbeeld. Houd die afbakening zichtbaar. Noem je een totaal aan modelkosten ‘winstgevendheid’, dan claim je meer dan je hebt gemeten.

In het bewijsregister van het boek staat dit dashboard als ontwerp van de auteur zelf, zonder vrijgegeven claim dat het kosten bespaart. Beoordeel een eerste versie dus op de vraag of die toewijsbare kostenregels en bruikbare alerts oplevert; meet een eventuele besparing apart.

Probeer dit vandaag

Splits de modeluitgaven van vorige maand uit naar route of feature, desnoods grofweg. Zet de routes op volgorde en geef de duurste deze week de startdrempel uit het boek.

1. Maak je eerste attributietabel. Koppel de factuur- en verbruiksregels van vorige maand aan route- en featurelabels. Schrijf per route één rij met kosten, oorspronkelijke aanvragen, eigenaar en of het bedrag gemeten of geschat is. Zet kosten zonder onderbouwd label op een aparte regel voor niet-toegewezen verbruik en sluit het totaal op dezelfde grondslag aan op de factuur.
2. Zet de rijen op volgorde. Sorteer op totale kosten en reken daarna de kosten per aanvraag uit. Kies de duurste route. Heb je alleen totalen per feature, kies dan de duurste feature en bepaal welke routelabels daaronder nodig zijn.
3. Stel een beoogd weekbudget vast. Reken met het verwachte aantal aanvragen en het beoogde verbruik tegen de geldende tarieven, extra aanroepen inbegrepen. Leg het naast de werkelijke uitgaven. Controleer of de routebudgetten en het plafond van het product over dezelfde periode gaan.
4. Schrijf de waarschuwing op 75% uit. Noteer de klok (uitgaven sinds het begin van de budgetweek), het drempelbedrag, de eigenaar en de eerste onderzoeksstap. Voeg de p95-SLO en een reviewdatum toe. Ontbreken historische labels, begin ze dan nu te verzamelen en laat de verdeling over het verleden als schatting staan.
5. Test de grens offline. Neem de drempel van € 112,50 uit het voorbeeld en geef een testkopie van je regel achtereenvolgens een weekstand van € 112,49, € 112,50 en € 112,51 als invoer. Bij een regel die afgaat boven de drempel mag alleen het derde bedrag een waarschuwing geven. Controleer of de melding de juiste route, het juiste bedrag en de juiste eigenaar noemt. Noteer dit als test van de rekenregel, niet als bewijs dat productie gedekt is.
6. Volg één echte aanvraag. Loop via het aanvraag-ID alle gefactureerde pogingen na tot in het route- en featuretotaal. Controleer verbruik, tarieven en aantal retry’s tegen de bronregistraties. Elke kostenpost moet in elk overzicht precies één keer meetellen.

Lukt het niet om die aanvraag te volgen, noteer dan welk label of verbruiksveld ontbreekt en wijs iemand aan die het toevoegt. Sluiten de totalen niet aan, laat het verschil dan zichtbaar staan. Aan het eind heb je één route met een eigenaar en een eerlijk overzicht van wat de meter wel en nog niet laat zien.

Citeer deze pagina:Kosten per route versus de maandfactuur: meet waar het geld naartoe gaat.Len P. van der Hof. https://lenvanderhof.com/nl/blog/kosten-per-route-versus-de-maandfactuur/ · Gepubliceerd 7 november 2026.