LLM-kostenoptimalisatie: de engineeringgids
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.
Het kostenprobleem
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.
Waarom kosten uit de hand lopen
- •Inflatie van het contextvenster: de gespreksgeschiedenis groeit met elke beurt, en u betaalt elke keer voor de volledige context
- •Herhaallussen: time-outherhalingen, validatieherhalingen en parseerherhalingen kunnen uw werkelijke aanroepvolume met 2 tot 5x vergroten
- •Te veel prompten: teams voegen voor elk randgeval instructies toe, waardoor systeemprompts opzwellen tot meer dan 3.000 tokens
- •Verkeerd model voor de taak: GPT-4o gebruiken voor taken die GPT-4o mini net zo goed aankan
De optimalisatie-mindset
- •Eerst meten: u kunt niet optimaliseren wat u niet meet -- instrumenteer elke LLM-aanroep
- •Modellen juist dimensioneren: 80% van de LLM-taken heeft niet het duurste model nodig
- •Agressief cachen: veel vragen zijn semantisch identiek aan eerdere
- •Batchen waar mogelijk: asynchrone batch-API's zijn bij de meeste aanbieders 50% goedkoper
Het verhaal van $200/dag naar $2.000/dag
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%.
Anatomie van de kosten
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.
Invoertokens (60-80%)
Systeemprompts, gespreksgeschiedenis, opgehaalde context (RAG), few-shotvoorbeelden. Hier gaat het meeste geld naartoe, en hier liggen de grootste besparingen.
Uitvoertokens (15-30%)
Gegenereerde antwoorden. Uitvoertokens kosten per token 2 tot 4x meer dan invoertokens, maar het volume is doorgaans lager. Uitgebreide antwoorden zijn de belangrijkste kostendrijver.
Overhead (5-15%)
Embeddinggeneratie, fine-tuningrekenkracht, vectoropslag, logging en bewakingsinfrastructuur. Klein per eenheid, maar telt op bij schaal.
Modelprijsvergelijking (per 1M tokens)
| 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.
Belangrijk inzicht: de 17x-kloof
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
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%.
Complexiteitsclassificator
Een klein model of heuristiek classificeert de complexiteit van de vraag en stuurt deze vervolgens naar de juiste modellaag.
Taakgebaseerde router
Routeren op taaktype: classificatie, extractie, samenvatting, generatie, redeneren. Elke taak wordt gekoppeld aan een optimaal model.
Cascadepatroon
Begin met het goedkoopste model. Als de betrouwbaarheid laag is of het antwoord de validatie niet doorstaat, escaleer dan naar een groter model.
Kwaliteitspoort
Een klein verificatiemodel controleert of de uitvoer van het goedkope model aan de kwaliteitsdrempels voldoet voordat deze wordt teruggegeven.
Implementatiepatroon: cascaderouter
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.
Besparingen in de praktijk: modelrouting
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.
Semantische caching
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.
Vergelijking van cachingstrategieën
| 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) |
Implementatie: Redis + embeddings
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).
Optimalisatie van de hitratio
- •Normaliseer vragen (kleine letters, interpunctie verwijderen) vóór de embedding
- •Cache op het niveau van de semantische intentie, niet op het ruwe tekstniveau
- •Scheid caches per systeemprompt om kruisbesmetting te voorkomen
- •Bewaak en stem de gelijkenisdrempel af (begin bij 0,95, pas aan op basis van het percentage valse positieven)
Tools & bibliotheken
- •GPTCache: open-source bibliotheek voor semantische caching met meerdere backends
- •Redis + RediSearch: productieklare vectorzoekfunctie met TTL-ondersteuning
- •Anthropic / OpenAI prompt-caching: ingebouwde prefixcaching, geen implementatie-inspanning
- •LiteLLM: proxy met ingebouwde cachingondersteuning over aanbieders heen
Promptoptimalisatie
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.
Compressie van de systeemprompt
Verwijder overbodige instructies, gebruik afkortingen, consolideer regels. Een systeemprompt van 2000 tokens comprimeert vaak tot 800 tokens zonder enig kwaliteitsverlies.
Migratie van few-shot naar zero-shot
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.
Afdwingen van gestructureerde uitvoer
Gebruik de JSON-modus of function calling om uitgebreide proza te elimineren. 'Leg je redenering uit' voegt meer dan 200 tokens per antwoord toe.
Snoeien van het contextvenster
Neem alleen relevante gespreksgeschiedenis op. Vat oude beurten samen. Verwijder systeemberichten die het model al via fine-tuning heeft geleerd.
Beheersing van de antwoordlengte
Stel max_tokens passend in. Gebruik 'Wees beknopt' of 'Antwoord in minder dan 100 woorden' in de prompt. Stopsequenties voor vroegtijdige beëindiging.
Voor / na: compressie van de systeemprompt
Voor (1.847 tokens)
Na (612 tokens)
Hetzelfde gedrag, 67% minder invoertokens. Bij 50K verzoeken/dag met GPT-4o bespaart dit ~$190/dag ($5.700/maand) alleen al op de systeemprompttokens.
Batchverwerking
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.
Wanneer batch gebruiken
- •Contentgeneratie (blogposts, productbeschrijvingen, e-mails)
- •Pijplijnen voor dataclassificatie en -labeling
- •Bijwerken van documentsamenvattingen
- •Evaluatie- en testsuites
- •Embeddinggeneratie voor grote corpora
Wanneer batch NIET gebruiken
- •Interactieve chatbots (gebruikers verwachten een antwoord in <3s)
- •Realtime contentmoderatie
- •Streamingantwoorden in de interface
- •Taken waarbij de uitvoer afhangt van het vorige resultaat (chains)
- •Alles met een SLA onder 24 uur (batch kan tot 24u duren)
Wachtrijgebaseerde architectuur
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.
Economie van fine-tuning
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.
Break-evenanalyse
| 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 |
Fine-tune wanneer...
- •U een goed gedefinieerde, enge taak hebt (classificatie, extractie, opmaak)
- •U meer dan 10K aanroepen/dag voor die taak doet
- •U meer dan 500 hoogwaardige trainingsvoorbeelden hebt
- •U lange systeemprompts of few-shotvoorbeelden moet elimineren
Fine-tune NIET wanneer...
- •Uw taak brede algemene kennis vereist (gebruik in plaats daarvan RAG)
- •de eisen vaak veranderen (hertrainen is duur)
- •U minder dan 200 trainingsvoorbeelden hebt
- •Prompt-engineering met een kleiner model acceptabele kwaliteit bereikt
Open-source modellen self-hosten
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.
Totale eigendomskosten (maandelijks)
| 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.
Serving-stack
- •vLLM: beste doorvoer, PagedAttention, continue batching
- •TGI (HuggingFace): productieklaar, Docker-native, ingebouwde quantization
- •Ollama: eenvoudige lokale ontwikkeling, niet voor productieschaal
- •TensorRT-LLM: NVIDIA-geoptimaliseerd, hoogste prestaties op NVIDIA-GPU's
GPU-huuropties
- •RunPod: $1,64/uur voor A100 80GB, goed om te experimenteren
- •Lambda Labs: $1,99/uur voor A100, gereserveerde instances beschikbaar
- •AWS/GCP/Azure: hogere kosten, enterprise-SLA's, geïntegreerd ecosysteem
- •Together AI / Fireworks: serverless inferentie, betalen per token op open modellen
Beslissingskader voor self-hosting
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.
Bewaking & waarschuwingen
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.
Belangrijke te volgen metrieken
| 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 |
Observability-tools
- •Helicone: proxygebaseerd, kostenvolgen zonder code, logging per verzoek
- •LangSmith: volledige tracing, evaluatie, promptversiebeheer (LangChain-ecosysteem)
- •Langfuse: open-source alternatief, zelf te hosten, kostentoewijzing
- •OpenLLMetry: OpenTelemetry-gebaseerd, integreert in uw bestaande observability-stack
Waarschuwingsregels
- •Dagelijkse uitgaven > 2x gemiddeld: vang op hol geslagen lussen of misbruik vroeg op
- •Gemiddeld aantal tokens/verzoek > 150% van de baseline: detecteer opgezwollen prompts
- •Cache-hitratio < 20%: problemen met cache-invalidatie of nieuwe vraagpatronen
- •Foutpercentage > 5%: herhalingen vermenigvuldigen stilletjes uw kosten
Kostentoewijzing per functie
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.
Het optimalisatie-playbook
Probeer niet alles tegelijk te implementeren. Volg deze prioriteitsvolgorde op basis van de inspanning-impactverhouding. Elke stap bouwt voort op de vorige.
Stapsgewijze optimalisatievolgorde
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.
Prioriteitsmatrix
| 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 |
Voorbeeld van cumulatieve besparingen
Startbasis: $10.000/maand aan LLM-API's.
Klaar om uw LLM-kosten te verlagen?
Of u nu $500 of $50.000/maand aan LLM-API's uitgeeft, er zijn concrete engineeringstappen om dat met 60-90% te verlagen. Ik help teams hun LLM-uitgaven te auditeren, routing en caching te implementeren en kostenbewaking op te zetten die regressie voorkomt.