De meeste teams geven 3 tot 10 keer te veel uit aan LLM-inferentie. Deze gids behandelt de engineeringtechnieken die de kosten met 60-90% verlagen zonder in te leveren op de outputkwaliteit -- van modelrouting en semantische caching tot de economie van fine-tuning en de break-evenanalyse van self-hosting.
LLM-kosten hebben de vervelende gewoonte om exponentieel te groeien. Wat begint als een beheersbaar prototype van $200/dag wordt al snel een productienachtmerrie van $2.000/dag. De rekensom is simpel maar genadeloos: prijs per token x groeiend gebruik x inflatie van het contextvenster = exponentiële kostencurves.
Hier een reëel scenario dat we steeds opnieuw zien: een team bouwt een klantenservicechatbot. Tijdens de ontwikkeling testen ze met korte gesprekken en eenvoudige vragen. Kosten: $8/dag. Ze lanceren naar 500 gebruikers. Gesprekken worden langer, contextvensters lopen vol, herhaallogica treedt in werking bij time-outs, en de systeemprompt groeit met elke correctie van een randgeval. Binnen drie weken kost dezelfde chatbot $2.400/dag -- een toename van 300x die niemand had begroot.
Een B2B-SaaS-bedrijf lanceerde een AI-assistent die GPT-4o gebruikte voor alle vragen. Hun kostentraject:
Na het toepassen van de technieken in deze gids (routing + caching + promptcompressie) brachten ze de kosten bij 500 gebruikers terug naar $320/dag -- een verlaging van 87%.
Voordat u optimaliseert, moet u begrijpen waar het geld naartoe gaat. LLM-kosten vallen uiteen in verschillende afzonderlijke categorieën, en de verdeling varieert sterk per applicatietype.
Systeemprompts, gespreksgeschiedenis, opgehaalde context (RAG), few-shotvoorbeelden. Hier gaat het meeste geld naartoe, en hier liggen de grootste besparingen.
Gegenereerde antwoorden. Uitvoertokens kosten per token 2 tot 4x meer dan invoertokens, maar het volume is doorgaans lager. Uitgebreide antwoorden zijn de belangrijkste kostendrijver.
Embeddinggeneratie, fine-tuningrekenkracht, vectoropslag, logging en bewakingsinfrastructuur. Klein per eenheid, maar telt op bij schaal.
| Model | Aanbieder | Invoer | Uitvoer | Context | Opmerkingen |
|---|---|---|---|---|---|
| GPT-4o | OpenAI | $2.50 | $10.00 | 128K | Beste algemeen gebruik, multimodaal |
| GPT-4o mini | OpenAI | $0.15 | $0.60 | 128K | Ideaal voor eenvoudige taken, invoer 17x goedkoper dan 4o |
| Claude Sonnet 4.6 | Anthropic | $3.00 | $15.00 | 200K | Sterk redeneren, groot contextvenster |
| Claude Haiku 4.5 | Anthropic | $0.80 | $4.00 | 200K | Snel, kostenefficiënt voor classificatie |
| Mistral Large 3 | Mistral | $2.00 | $6.00 | 128K | Europese aanbieder, AVG-vriendelijk |
| Llama 4 Maverick (self-hosted) | Meta (open-source) | ~$0.30* | ~$0.30* | 1M | Alleen GPU-kosten, geen kosten per token |
* Self-hostingkosten zijn bij benadering, gebaseerd op huur van een A100-GPU tegen ~$2/uur die Llama 4 Maverick met vLLM bedient. De werkelijke kosten hangen af van doorvoer en benutting.
Invoertokens van GPT-4o kosten $2,50/1M. GPT-4o mini kost $0,15/1M. Dat is een prijsverschil van 17x. Voor classificatie, extractie en eenvoudige vraag-en-antwoord is het kwaliteitsverschil vaak verwaarloosbaar. Modelrouting buit deze kloof uit.
Modelrouting is de optimalisatie met de grootste impact. Het idee is simpel: stuur eenvoudige taken naar goedkope modellen en moeilijke taken naar dure modellen. De meeste productiebelastingen bestaan voor 70-80% uit eenvoudige taken die een klein model perfect aankan. Typische besparing: 60-80%.
Een klein model of heuristiek classificeert de complexiteit van de vraag en stuurt deze vervolgens naar de juiste modellaag.
Routeren op taaktype: classificatie, extractie, samenvatting, generatie, redeneren. Elke taak wordt gekoppeld aan een optimaal model.
Begin met het goedkoopste model. Als de betrouwbaarheid laag is of het antwoord de validatie niet doorstaat, escaleer dan naar een groter model.
Een klein verificatiemodel controleert of de uitvoer van het goedkope model aan de kwaliteitsdrempels voldoet voordat deze wordt teruggegeven.
Gebruik een lichtgewicht classificator (logistische regressie op embeddings, of een regelgebaseerd systeem) om de complexiteit van de vraag te scoren op een schaal van 0 tot 1. Kosten: ~0,01ms per vraag.
Een score < 0,3 gaat naar GPT-4o mini ($0,15/1M invoer). Een score 0,3-0,7 gaat naar Claude Haiku 4.5 ($0,80/1M). Een score > 0,7 gaat naar GPT-4o ($2,50/1M).
Als het goedkope model uitvoer met lage betrouwbaarheid teruggeeft of de validatie niet doorstaat, escaleer dan automatisch naar de volgende laag. Doorgaans escaleert slechts 5-10% van de vragen.
Een klantenserviceplatform dat 50.000 vragen/dag verwerkt, stapte over van GPT-4o voor alles naar een routing-opzet: 72% naar GPT-4o mini, 20% naar Claude Haiku 4.5, 8% naar GPT-4o. De maandelijkse kosten daalden van $38.000 naar $6.200 -- een verlaging van 84% zonder meetbare kwaliteitsachteruitgang in hun evaluatiesuite.
Als een gebruiker vraagt "Wat is uw retourbeleid?" en een ander "Hoe retourneer ik een artikel?", willen ze hetzelfde antwoord. Semantische caching detecteert deze vergelijkbare vragen en serveert gecachte antwoorden in plaats van overbodige API-aanroepen te doen. Voor applicaties met repetitieve vraagpatronen kan dit alleen al de kosten met 30-60% verlagen.
| Aanpak | Hitratio | Inspanning | Besparing | Beste voor |
|---|---|---|---|---|
| Exact-matchcache | 10-20% | Low | Low | Herhaalde identieke vragen (FAQ-bots, autoaanvulling) |
| Semantische cache (cosinus > 0,95) | 30-50% | Medium | High | Vergelijkbare vragen met hetzelfde antwoord (klantenservice) |
| Prompt-bewuste cache | 40-60% | High | Very High | Dezelfde systeemprompt + vergelijkbare gebruikersvragen |
| Prefixcaching (API-niveau) | Automatisch | None | Medium | Gedeelde systeemprompts over verzoeken heen (Anthropic, OpenAI) |
Genereer een embeddingvector voor de gebruikersvraag met een snel embeddingmodel (bijv. text-embedding-3-small tegen $0,02/1M tokens).
Gebruik Redis met de vectorzoekmodule (RediSearch) of een lichtgewicht vector-DB. Stel de drempel in op 0,95+ cosinusgelijkenis voor hoge precisie.
Bij een hit: geef het gecachte antwoord terug in <50ms. Bij een miss: roep de LLM aan, sla het resultaat op met embedding en TTL (bijv. 24 uur voor dynamische inhoud, 7 dagen voor statische).
Elk token in uw prompt kost geld. De meeste productieprompts bevatten 30-50% overbodige tokens -- uitgebreide instructies, onnodige voorbeelden en opmaak die het model niet nodig heeft. Promptoptimalisatie is het startpunt met de laagste inspanning en het hoogste rendement.
Verwijder overbodige instructies, gebruik afkortingen, consolideer regels. Een systeemprompt van 2000 tokens comprimeert vaak tot 800 tokens zonder enig kwaliteitsverlies.
Vervang uitgebreide few-shotvoorbeelden door beknopte instructies. Fine-tune een klein model op de voorbeelden in plaats van ze bij elke aanroep mee te sturen.
Gebruik de JSON-modus of function calling om uitgebreide proza te elimineren. 'Leg je redenering uit' voegt meer dan 200 tokens per antwoord toe.
Neem alleen relevante gespreksgeschiedenis op. Vat oude beurten samen. Verwijder systeemberichten die het model al via fine-tuning heeft geleerd.
Stel max_tokens passend in. Gebruik 'Wees beknopt' of 'Antwoord in minder dan 100 woorden' in de prompt. Stopsequenties voor vroegtijdige beëindiging.
Hetzelfde gedrag, 67% minder invoertokens. Bij 50K verzoeken/dag met GPT-4o bespaart dit ~$190/dag ($5.700/maand) alleen al op de systeemprompttokens.
Als uw werklast geen realtime antwoorden vereist, bieden batch-API's een onmiddellijke kostenverlaging van 50% zonder enige engineeringinspanning. De Batch API van OpenAI, de Message Batches van Anthropic en de meeste aanbieders bieden gereduceerde prijzen voor asynchrone verwerking.
Implementeer voor gemengde werklasten een wachtrij die realtime- en batch-geschikte verzoeken scheidt. Gebruik prioriteitswachtrijen om latentiegevoelig werk naar synchrone API's te routeren en al het overige naar batch-eindpunten.
Met fine-tuning kunt u een groot model + complexe prompt vervangen door een klein model waarin het gedrag is ingebakken. De economie is overtuigend: een fine-getuned GPT-4o mini kan op enge taken de kwaliteit van GPT-4o evenaren tegen 1/15 van de inferentiekosten. Maar fine-tuning heeft initiële kosten en is alleen de moeite waard bij voldoende schaal.
| Aanpak | Kosten/1K aanroepen | Kwaliteit | Latentie | Opzetkosten | Break-even |
|---|---|---|---|---|---|
| GPT-4o + gedetailleerde prompt | $25.00 | 95% | High | $0 | N/A |
| GPT-4o mini + few-shot | $1.50 | 88% | Low | $0 | N/A |
| GPT-4o mini fine-getuned | $0.90 | 93% | Low | $50-200 | ~300 |
| Llama 4 Scout fine-getuned (self-hosted) | $0.10 | 90% | Very Low | $500-2000 | ~2,000 |
Bij hoog volume kan het self-hosten van open-source modellen (Llama 4, Mistral Large 3, Qwen) de kosten per token met 80-95% verlagen. De afweging is operationele complexiteit: u hebt GPU-infrastructuur, model serving, bewaking en piketdienst nodig. Het break-evenpunt hangt af van uw volume.
| Optie | 100K req/mo | 1M req/mo | 10M req/mo | Voordelen | Nadelen |
|---|---|---|---|---|---|
| OpenAI API (GPT-4o) | $2,500 | $25,000 | $250,000 | Geen beheer, altijd het nieuwste model | Hoogste marginale kosten, leveranciersafhankelijkheid |
| GPU-huur (A100 80GB) | $2,000 | $2,000 | $6,000 | Vaste kosten bij schaal, data blijft lokaal | Beheerlast, capaciteitsplanning |
| Eigen hardware (H100) | $4,500* | $4,500* | $4,500* | Laagste langetermijnkosten, volledige controle | Hoge initiële investering ($30-40K), afschrijving |
* Kosten van eigen hardware afgeschreven over 36 maanden. Exclusief elektriciteit (~$200/maand voor een H100), rackruimte of beheerpersoneel.
Self-host wanneer u (a) een constant volume boven 1M tokens/dag, (b) een ML-ops-team of de bereidheid er een op te bouwen, (c) eisen aan datasoevereiniteit (AVG, HIPAA), of (d) API-uitgaven boven $5.000/maand hebt. Onder die drempels rechtvaardigt de operationele complexiteit de besparingen vrijwel nooit. Begin met serverless inferentie-aanbieders (Together AI, Fireworks) als tussenweg voordat u zich vastlegt op pure GPU-huur.
Kostenoptimalisatie is geen eenmalig project. Zonder continue bewaking kruipen de kosten weer omhoog door promptdrift, nieuwe functies en veranderende gebruikspatronen. U hebt realtime inzicht nodig in waar elke dollar naartoe gaat.
| Metriek | Beschrijving | Doel | Tool |
|---|---|---|---|
| Kosten per verzoek | Totale kosten (invoer- + uitvoertokens) per API-aanroep, uitgesplitst per functie | Track trend, < budget | Custom logging / Helicone |
| Kosten per gebruikerssessie | Geaggregeerde kosten over alle LLM-aanroepen in één gebruikersinteractie | < $0.05 for most apps | LangSmith / custom |
| Cache-hitratio | Percentage verzoeken bediend vanuit de semantische cache | > 30% | Redis metrics / custom |
| Tokenefficiëntie | Verhouding van nuttige uitvoertokens tot het totaal aan verbruikte tokens | > 60% | Custom analysis |
| Verdeling van modelrouting | Welk percentage van het verkeer naar elke modellaag gaat | < 20% to large model | Custom dashboard |
| Dagelijks uitgavenpercentage | Voortschrijdende dagkosten met anomaliedetectie voor pieken | < 2x daily average | Helicone / alerts |
Label elke LLM-aanroep met de functie die deze bedient (bijv. "chat", "search", "summarization", "classification"). Zo kunt u antwoorden op: "Welke functie kost het meest?" en "Zijn de kosten per gebruikersinteractie houdbaar?". Zonder dit optimaliseert u blind. Geef metadata door zoals {feature: "chat", user_tier: "free"} via de headers van uw LLM-proxy.
Probeer niet alles tegelijk te implementeren. Volg deze prioriteitsvolgorde op basis van de inspanning-impactverhouding. Elke stap bouwt voort op de vorige.
Voeg logging toe aan elke LLM-aanroep. Volg tokens in/uit, gebruikt model, functie, kosten, latentie. U kunt niet optimaliseren wat u niet meet.
Bekijk en comprimeer elke systeemprompt. Verwijder redundantie, kort instructies in, schrap onnodige few-shotvoorbeelden. Typische besparing: 20-40%.
Zet een basisrouter op. Begin met taakgebaseerde routing (eenvoudige regels), ga vervolgens over op een classificator. Routeer meer dan 70% van het verkeer naar het goedkoopste haalbare model.
Zet een semantische cache in voor eindpunten met veel verkeer. Begin met exact-match, voeg vervolgens embeddinggelijkenis toe. Streef naar meer dan 30% hitratio.
Identificeer werklasten die geen realtime antwoorden nodig hebben. Stap over op batch-eindpunten voor 50% besparing op die aanroepen.
Zet kostendashboards op met toewijzing per functie. Stel anomaliewaarschuwingen in. Maak van LLM-kosten een eersteklas operationele metriek.
Zodra u gegevens hebt over kosten en volumes per taak, evalueer dan of fine-tuning of self-hosting economisch zinvol is voor uw taken met het hoogste volume.
| Optimalisatie | Inspanning | Impact | Besparing | Wanneer doen |
|---|---|---|---|---|
| Promptcompressie | Low | Medium | 20-40% | Altijd eerst |
| Modelrouting | Medium | Very High | 60-80% | Bij meer dan $500/maand uitgaven |
| Semantische caching | Medium | High | 30-60% | Wanneer vragen repetitief zijn |
| Batchverwerking | Low | Medium | 50% op batch-geschikt | Wanneer latentie niet kritiek is |
| Fine-tuning | High | High | 70-90% | Bij meer dan 10K aanroepen/dag op één taak |
| Self-hosting | Very High | Very High | 80-95% | Bij meer dan $10K/maand of datasoevereiniteit |
Startbasis: $10.000/maand aan LLM-API's.