API-kosten per eindgebruiker toerekenen in een SaaS-product
Bij het bouwen van een Software-as-a-Service (SaaS) product dat gebruikmaakt van Large Language Models (LLM's), loop je al snel aan tegen een fundamenteel probleem: de enorme variatie in verbruik tussen eindgebruikers. Waar traditionele SaaS-infrastructuren relatief voorspelbare kosten per gebruiker met zich meebrengen, is dat bij LLM-integraties anders. Eén gebruiker die dagelijks complexe documenten samenvat of intensief met een chatbot communiceert, kan meer API-kosten veroorzaken dan honderd passieve gebruikers bij elkaar.
Als SaaS-aanbieder wil je voorkomen dat een kleine groep intensieve gebruikers jouw winstmarges volledig wegvaagt. Het simpelweg hanteren van een gemiddelde abonnementsprijs leidt onvermijdelijk tot kruissubsidie, waarbij de inactieve abonnees betalen voor de actieve grootverbruikers, of erger nog: tot direct verliesgevende klanten. Dit artikel behandelt de strategieën, patronen en technische implementatiedetails om LLM-kosten op een eerlijke en betrouwbare manier toe te rekenen aan individuele eindgebruikers.
Wat reken je toe? Variabel vs. Vast
Voordat je begint met het toewijzen van kosten, is het cruciaal om een duidelijk onderscheid te maken tussen de variabele LLM-kosten en de vaste platformkosten. Niet alle infrastructurele kosten lenen zich voor directe allocatie per gebruiker.
| Kostentype | Onderdelen | Toerekeningsmethode |
|---|---|---|
| Variabele LLM-kosten | Inputtokens, outputtokens, modelkeuze, fine-tuning hosting | Direct toerekenen op basis van exact gemeten API-verbruik per tenant of gebruiker. |
| Vaste platformkosten | Server hosting, databases, authenticatie, support, licenties | Afschrijven als algemene overhead, verdeeld over alle actieve accounts via de basisabonnementen. |
De variabele kosten worden direct beïnvloed door het gedrag van de eindgebruiker. Het aantal tokens dat door de API stroomt, de specifieke modelkeuze (bijvoorbeeld een complex redeneermodel versus een lichter en goedkoper model) en eventuele aanvullende functionaliteiten zoals vector search bepalen de uiteindelijke factuur van de LLM-provider. Deze variabele kosten wil je direct kunnen herleiden naar de verantwoordelijke gebruiker.
De drie basispatronen voor toerekening
Er zijn drie beproefde patronen om deze variabele kosten door te berekenen of te alloceren binnen je SaaS-prijzen. De keuze voor een patroon hangt nauw samen met de positionering van het product en de tolerantie van de doelgroep voor onvoorspelbare facturen.
A. Per-token doorbelasting (Pay-as-you-go)
In dit model fungeert de SaaS-applicatie als een transparante doorgeefluik. De gebruiker betaalt een lage vaste basisprijs en rekent daarnaast exact af voor het aantal verbruikte tokens. Dit patroon sluit nauw aan bij de pricing van de onderliggende API-providers.
- Voordelen: Geen enkel risico op verliesgevende gebruikers; maximale transparantie; schaalt direct mee met de activiteit.
- Nadelen: Gebruikers ervaren factuurangst en kunnen hun gebruik gaan beperken om kosten te sparen; complexere administratie en facturatie achteraf.
- Wanneer toepassen: B2B-producten gericht op ontwikkelaars of power-users die gewend zijn aan verbruiksafhankelijke kosten. Zie voor een diepere uitleg over token-facturatie de pagina over prijsmodellen per token uitgelegd.
B. Tiered abonnementen met verbruiksplafonds (Fair-use)
Dit is het meest gangbare model voor algemene SaaS-applicaties. Gebruikers kiezen een abonnement (bijvoorbeeld Basic, Pro of Enterprise) met een vast maandbedrag. Aan elk abonnement is een maximumaantal tokens of een bepaald budget gekoppeld.
- Voordelen: Voorspelbare kosten voor zowel de klant als de SaaS-aanbieder; makkelijk te begrijpen en te verkopen.
- Nadelen: Vereist strikte handhaving en weigering van requests zodra de limiet is bereikt; risico op ontevreden klanten als de limiet onduidelijk is gecommuniceerd.
- Wanneer toepassen: Generieke SaaS-toepassingen (zoals CRM's of schrijfhulpen) waar AI een ondersteunende feature is.
C. Credits en feature-gebaseerde afschrijving
Bij dit patroon vertaal je de technische complexiteit van tokens naar een begrijpelijke eenheid binnen de applicatie: credits. Het genereren van een afbeelding kost bijvoorbeeld 50 credits, het samenvatten van een e-mail 2 credits en een chatgesprek 1 credit per interactie.
- Voordelen: De gebruiker hoeft niet te begrijpen wat een token is; je kunt de creditwaarde eenvoudig aanpassen als de API-kosten van providers dalen of stijgen; stimuleert het gebruik van efficiëntere functionaliteiten.
- Nadelen: Het bepalen van de juiste credit-waardering per feature vereist nauwkeurige interne berekeningen om marges te waarborgen.
- Wanneer toepassen: Applicaties die verschillende typen media (tekst, beeld, audio) en meerdere typen modellen combineren.
Hoe meet je verbruik betrouwbaar per eindgebruiker?
Een betrouwbare toerekening valt of staat met de meetinfrastructuur (metering). Fouten in de meting leiden direct tot foutieve facturen of onjuist afgedwongen limieten.
1. Metering in de gateway-laag, niet in de client
Het meten van tokenverbruik mag nooit plaatsvinden in de client-side code of rechtstreeks in de applicatielogica van individuele microservices. Dit introduceert beveiligingsrisico's en inconsistenties. Richt in plaats daarvan een centrale API-gateway of proxy in die tussen de applicatie en de LLM-providers staat.
Deze gateway vangt elke request en response op, leest de metadata uit de response headers (waar providers het exacte aantal verbruikte tokens rapporteren) en schrijft deze gegevens asynchroon weg naar een datastore. Voor een effectieve verwerking is het essentieel dat elke request direct gekoppeld is aan een unieke tenant-identiteit. Meer details over het inrichten van zo'n architectuur vind je op de pagina over multi-tenant LLM-apps.
2. Attributie en normalisatie over providers heen
SaaS-producten maken vaak gebruik van verschillende providers (zoals OpenAI, Anthropic en open-source modellen gehost op AWS of Hugging Face). Elke provider hanteert zijn eigen tokenizer en geeft het verbruik op een andere manier door.
Je meetinfrastructuur moet deze gegevens normaliseren naar een gestandaardiseerd formaat. Dit betekent dat je per transactie ten minste de volgende gegevens moet opslaan:
{
"timestamp": "2026-08-06T14:32:01Z",
"tenant_id": "tenant-9832",
"user_id": "usr-5501",
"provider": "anthropic",
"model": "claude-3-5-sonnet",
"input_tokens": 1024,
"output_tokens": 256,
"cost_usd": 0.003840
}Door de kosten direct in USD (of EUR) op te slaan op basis van de op dat moment geldende tarieven van de provider, voorkom je dat je achteraf historische tokenaantallen moet omrekenen wanneer een provider zijn tarieven wijzigt.
Afwegingen en operationele complexiteit
Het bouwen van een sluitend costs-allocation systeem dwingt je tot het maken van een aantal operationele keuzes waarbij nauwkeurigheid en prestaties tegen elkaar moeten worden afgewogen.
Nauwkeurigheid versus latentie
Het inline meten en valideren van limieten kan extra latentie (network hops) introduceren bij elke API-call. Als de gateway bij elk request synchroon in een relationele database moet controleren of een gebruiker nog voldoende budget heeft, vertraagt dit de user experience.
De oplossing is het gebruik van een snelle in-memory cache (zoals Redis) voor het valideren van actuele limieten, gecombineerd met een asynchrone message queue (bijvoorbeeld RabbitMQ of Kafka) die de daadwerkelijke verbruiksgegevens verwerkt en wegschrijft naar de primaire database. Hierbij accepteer je een kleine vertraging (vaak enkele seconden of minuten) in de nauwkeurigheid van het getoonde verbruik in ruil voor een optimale responstijd van de applicatie.
Wie betaalt de inefficiënte calls van de gebruiker?
Eindgebruikers schrijven niet altijd efficiënte prompts. Ze sturen soms enorme lappen tekst mee die niet relevant zijn, of ze herhalen prompts waardoor onnodig veel inputtokens worden verbruikt. Hoewel dit technisch gezien de verantwoordelijkheid van de gebruiker is, kan het doorberekenen hiervan leiden tot supportvragen en ontevredenheid.
Het is daarom verstandig om in de applicatielaag mechanismen in te bouwen die dit gedrag inperken. Denk aan het limiteren van de maximale invoerlengte in de UI en het toepassen van slimme rate limiting om misbruik te voorkomen. Dit sluit nauw aan bij de bredere beveiligings- en kostenbeheersingsmaatregelen die worden besproken op de pagina over rate limits en kosten.
Praktische uitwerking van de metering-data
Wanneer de data betrouwbaar binnenstroomt via de gateway, moet deze worden verwerkt voor rapportage en facturatie. Dit vereist een doordachte datastructuur en bewaartermijn.
Aggregatie en opslag
Het bewaren van elke individuele API-call op rij-niveau (raw logs) is waardevol voor debugging en audits, maar wordt bij hoge volumes snel onbetaalbaar en traag voor rapportagedoeleinden. Aggregeer daarom de data op vaste intervallen:
- Raw logs: Bewaar deze maximaal 14 tot 30 dagen in een goedkope object storage (zoals AWS S3 of Google Cloud Storage) voor eventuele disputen.
- Uur- en dagaggregaten: Sla geaggregeerde totalen per gebruiker/tenant op in een time-series database of een geoptimaliseerde relationele tabel voor de weergave in dashboards en wekelijkse rapportages.
- Maandtotalen: Gebruik deze voor de definitieve facturatie en bewaar deze conform de wettelijke fiscale bewaartermijnen.
UI-communicatie en waarschuwingen
Transparantie in de applicatie voorkomt dat gebruikers verrast worden door hun verbruik. Zorg voor een overzichtelijk dashboard in de instellingen van de SaaS-applicatie waar de gebruiker (of de administrator van de tenant) het actuele verbruik kan inzien.
Stuur proactief notificaties (bijvoorbeeld via e-mail of in-app alerts) wanneer een gebruiker 80% en 100% van zijn maandelijkse budget of credit-tegoed heeft bereikt. Dit geeft hen de tijd om hun gebruik aan te passen of hun abonnement te upgraden voordat hun toegang daadwerkelijk wordt geblokkeerd.
Grensgevallen en uitzonderingen
In de praktijk verloopt kostenallocatie zelden vlekkeloos. Er zijn verschillende scenario's die vragen om een pragmatische aanpak.
Gedeelde API-keys
Als jouw SaaS-product een API aanbiedt aan eindgebruikers, kunnen zij die API-key delen binnen hun eigen organisatie of integreren in scripts die onverwacht veel verkeer genereren. In dergelijke gevallen is het essentieel dat de kostenallocatie gekoppeld is aan de API-key zelf, zodat de tenant exact kan zien welke sleutel verantwoordelijk is voor welk deel van de factuur.
Interne en demo-gebruikers
Ontwikkelaars, supportmedewerkers en potentiële klanten in een demo-omgeving genereren ook LLM-kosten. Deze kosten mogen de statistieken van de betalende gebruikers niet vervuilen. Label deze accounts in de database als `internal` of `demo` en zorg ervoor dat de gateway deze data filtert voordat de rapportages voor bedrijfsvoering en marge-analyses worden gegenereerd. Dit is met name belangrijk bij het uitvoeren van een nauwkeurige rendementsanalyse; zie hiervoor de richtlijnen over het berekenen van de AI ROI berekenen.
Caching en kostenverdeling
Het implementeren van een semantische cache of het gebruikmaken van provider-side caching (zoals prompt caching) verlaagt de kosten van herhaalde queries aanzienlijk. Dit roept de vraag op: wie profiteert van deze korting?
Als Gebruiker A een vraag stelt en Gebruiker B stelt vijf minuten later exact dezelfde vraag waardoor de response uit de cache komt, is de verdeling van de korting complex. De meest pragmatische oplossing is om de kostenbesparing door caching te gebruiken als marge-optimalisatie voor het platform zelf, of om een vast, gemiddeld gereduceerd tarief te rekenen voor cache-hits, ongeacht wie de cache initieel heeft gevuld.
Compliance, privacy en transparantie
Het bijhouden van gedetailleerde verbruiksgegevens per eindgebruiker raakt direct aan de privacywetgeving (AVG/GDPR). Token-tracking betekent vaak ook dat je metadata opslaat over wat er naar de LLM is gestuurd.
Zorg ervoor dat in de algemene voorwaarden en de privacyverklaring van de SaaS-applicatie expliciet is opgenomen dat het verbruik wordt gemeten voor facturatie- en beveiligingsdoeleinden. Indien er sprake is van audits of wettelijke verplichtingen om data te bewaren, moet de metering-infrastructuur dit ondersteunen zonder de privacy van de eindgebruiker te schenden. Raadpleeg voor de inrichting van een dergelijk audittrail de richtlijnen over audit-logging en compliance.
Naast de toerekening aan individuele gebruikers, is het minstens zo belangrijk om de totale platformkosten en budgetten scherp in de gaten te houden. Dit voorkomt dat cumulatieve lekken of onverwachte pieken de gezonde marge van je SaaS-onderneming alsnog bedreigen. Voor een compleet beeld van hoe je deze overkoepelende infrastructuurkosten monitort en beheert, kun je terecht op de pagina over kosten monitoren.
