Wanneer je team elk verzoek naar GPT-5 of Claude 4.7 Opus stuurt, betaal je vrijwel zeker te veel. Bij een gemiddelde productie-workload lopen de onnodige kosten op tot wel 40 procent, en in sommige gevallen zelfs aanzienlijk meer.
De uitgaven van bedrijven aan (LLM’s) sprongen van $3,5 miljard eind 2024 naar $8,4 miljard medio 2025, en de meeste teams die deze rekeningen krijgen, hebben geen controle-laag tussen hun applicatie en de model-providers. Elk verzoek krijgt de “top model”-behandeling, of het nu nodig is of niet. Elke storing legt de productie plat. Elke dubbele vraag verbruikt een nieuwe set tokens.
Een AI-gateway biedt de oplossing. Hoewel de besparingen per workload verschillen, ligt het gemiddelde tussen de 30 en 50 procent. Inmiddels is de gateway dan ook standaard infrastructuur voor elke serieuze productie-deployment. In dit artikel leggen we uit hoe zo’n gateway werkt, waar de winst vandaan komt en hoeveel jij specifiek kunt besparen.
Wat een AI gateway eigenlijk is
Een AI gateway is een controle-laag die zich bevindt tussen jouw applicatie code en de LLM-providers. In plaats van dat jouw app direct OpenAI aanroept, roept het de gateway aan, die vervolgens beslist waar het verzoek naartoe moet gaan.
Dat klinkt misschien als een eenvoudige tussenstap, maar dat is het niet. Omdat de gateway elk verzoek centraal verwerkt, kan het acties uitvoeren die voor een losse applicatie onmogelijk zijn.
- Elk verzoek naar het goedkoopste model dat de taak aankan,
- Antwoorden cachen op vragen die al eerder zijn gesteld,
- Terugvallen op een tweede provider wanneer de eerste offline is,
- Budgetten per team en per project afdwingen,
- Loggen en meten wat er feitelijk wordt uitgegeven, door wie, waaraan.
Deze manier van denken is niet nieuw. Iedereen die werkt met een API-gateway zoals Kong of een edge-laag als Cloudflare zal het patroon herkennen. Het grote verschil is dat LLM-workloads zulke specifieke kenmerken hebben qua kosten en latentie, dat een control-laag hier nóg crucialer is dan bij een normale REST API. Ter illustratie: één verkeerd gerouteerde aanroep naar Claude Opus kan meer kosten dan tienduizend Redis-lookups.
Waar de 40% feitelijk vandaan komt
De besparing van 40% is een realistisch doel, mits je drie onafhankelijke technieken met elkaar combineert. Geen van deze methoden kan die winst in zijn eentje realiseren. Het is daarom essentieel om elke techniek op zijn eigen kracht te beoordelen. Baseer je daarbij op gepubliceerde benchmarks in plaats van blind te varen op marketing claims.
1. Model-routing op basis van complexiteit
Dit is de grootste individuele hefboom, en het is degene die de meeste teams laten liggen.
Niet elk verzoek heeft een frontier-model nodig. Een classificatietaak, een korte extractie, een opmaakklus, een simpel FAQ-antwoord; deze kunnen worden afgehandeld door een kleiner en goedkoper model zonder meetbaar kwaliteitsverlies. Onderzoek van SciForce toonde aan dat hybride routing-systemen, die basis verzoeken via lichtere modellen sturen en frontier-modellen reserveren voor complex redeneren, reducties van 37 tot 46 procent in het totale LLM-gebruik behalen, terwijl ze 32 tot 38 procent snellere reacties leveren op eenvoudige queries.
De gateway maakt dit in de praktijk heel eenvoudig. Je stelt de routingregels één keer in via de configuratie, terwijl je applicatiecode ongewijzigd blijft. Je stuurt elk verzoek simpelweg naar de gateway. Deze bepaalt vervolgens razendsnel de beste route: van Haiku of Sonnet tot Opus, of van GPT-5 Nano tot het zware werk. Voor privacygevoelige data kan de gateway zelfs direct schakelen naar een lokale Qwen3-instance op je eigen hardware.
Een belangrijke nuance: routing is slechts zo goed als de achterliggende logica. Een gateway die simpelweg routeert op basis van tekstlengte of trefwoorden, stuurt vroeg of laat een complexe redeneertaak naar een te klein model, met inconsistente of foutieve resultaten tot gevolg.. Goede implementaties gebruiken daarom een evaluatie-stap, een lichtgewicht classifier-model of specifieke regels per endpoint. Het grote voordeel is dat de gateway je een centrale plek biedt voor die intelligentie. Zonder gateway zit je vast aan de keuzes die een developer maanden geleden toevallig in de SDK heeft vastgelegd.
2. Semantic caching
Een groot deel van het dataverkeer binnen AI-producten bestaat uit vragen die inhoudelijk op hetzelfde neerkomen. Een klantenservice-bot die de vraag “Hoe reset ik mijn wachtwoord?” beantwoordt, verwerkt bijna identieke intenties, of de gebruiker nu “hulp bij wachtwoordherstel”, “ik ben mijn inloggegevens vergeten” of “kan niet in mijn account komen” typt. Elke variatie triggert een nieuwe API-call bij een naïeve infrastructuur. Elke call verbruikt tokens.
Semantic caching lost dit op door de betekenis van binnenkomende verzoeken te vergelijken met eerder gecachte verzoeken met behulp van vector embeddings en cosinus gelijkenis. Wanneer een match een configureerbare drempel overschrijdt (meestal 0,90 tot 0,95), wordt het gecachte antwoord direct geretourneerd. Geen LLM-call nodig. Cache-hits komen terug in minder dan 5 milliseconden in plaats van de 2 tot 5 seconden voor een volledige inferentie.
De cijfers variëren hier enorm per use case, en de marketing is vaak oneerlijk over het realistische plafond. Gepubliceerde productie-hit rates liggen tussen de 20 en 45 procent, niet de 90-plus die je soms gequoteerd ziet. Classificatie taken cachen goed, in de range van 40 tot 60 procent. Open chatgesprekken cachen slecht: 10 tot 20 procent. RAG-toepassingen landen meestal rond de 20 procent. Maar zelfs een hitrate van 20 procent op een maandelijkse rekening van €5.000 bespaart €1.000 per maand, terwijl de cache-infrastructuur zelf minder dan 5 procent van de besparingen kost.
De beste implementaties maken gebruik van twee lagen. Eerst een exacte match hash-controle (sub-milliseconde, nul risico op verkeerde antwoorden), en daarna pas een vector-overeenkomst-zoekopdracht als de exacte controle mislukt. Dit houdt het snelle pad snel en betaalt de kosten voor de embedding alleen wanneer het echt kan helpen.
Een valkuil die genoemd moet worden: context-lekkage. Als gebruiker A een vraag stelt die privégegevens (PII) bevat en gebruiker B stelt iets wat semantisch vergelijkbaar is, zal een naïeve cache het antwoord van A aan B tonen. Elke productie-gateway die gevoelige data verwerkt, heeft namespace-scheiding per gebruiker of tenant nodig. Dit is niet optioneel.
3. Fallbacks, load balancing, en provider arbitrage
De derde besturingshefboom is minder voor de hand liggend, maar reëel. Wanneer je via een gateway routeert, ben je niet langer gebonden aan de prijzen of beschikbaarheid van één provider. Als OpenAI een regionale storing heeft om 2 uur ‘s nachts (wat veel teams over kwam in 2024 en opnieuw in 2025), routeert je gateway automatisch naar Anthropic, Bedrock of Vertex, en je gebruikers merken er niets van.
Maar fallback is ook een kosten hefboom. Hetzelfde Llama-model kan beschikbaar zijn bij vijf verschillende providers tegen wild uiteenlopende prijzen. Een gateway met multi-provider ondersteuning kan routeren naar het goedkoopste gezonde endpoint dat aan je kwaliteits- en latentie-eisen voldoet, en kan verkeer dynamisch verschuiven bij prijswijzigingen. Voor modellen die door meerdere infrastructuur providers worden gehost, zijn prijsverschillen van 2x of meer gebruikelijk.
Bij elkaar opgeteld, en dan eerlijk gerekend: hybride routing op een gemengde workload vermindert het gebruik met ruwweg 40 procent. Semantic caching op wat overblijft voegt nog eens 20 tot 25 procent reductie toe op dat restant (niet op het oorspronkelijke totaal). Provider arbitrage op wat er dan nog over is, draagt nog eens zo’n 10 procent bij. Samengesteld is dat 0,60×0,78×0,90, wat neerkomt op ongeveer 42 procent korting op de oorspronkelijke rekening. Dat is waar het getal uit de kop vandaan komt.
Het plafond van 50 procent dat soms in materiaal van leveranciers wordt genoemd, is haalbaar, maar alleen voor workloads die ongewoon goed cachen (support-bots, FAQ, classificatie-zware pipelines) of die bijzonder sterke routing-kansen hebben (veel eenvoudige verzoeken die momenteel naar frontier-modellen gaan). De vloer van 30 procent is wat je bereikt bij workloads die worden gedomineerd door een unieke long-form generatie, waar semantic caching bijna niets bijdraagt en je besparingen bijna volledig uit routing voortkomen.
Wat een AI gateway je biedt naast besparingen
Het kostenverhaal is de makkelijke verkoop, maar het operationele verhaal is de reden waarom gateways onmisbaar worden.
- Je krijgt observabiliteit. Zonder gateway weet niemand precies wie wat uitgeeft aan welk model. Met een gateway krijg je spend-attributie per team, per project en per developer in real-time.
- Je krijgt budget-handhaving. Harde limieten per team per maand. Zachte waarschuwingen bij 80 procent. De mogelijkheid om een op hol geslagen agent-loop stop te zetten voordat deze in één weekend het kwartaal budget opbrandt.
- Je krijgt provider-onafhankelijkheid. Je applicatiecode is niet langer getrouwd met de SDK van OpenAI of het berichtformaat van Anthropic. De gateway stelt één OpenAI-compatibele API beschikbaar, en je wisselt van provider achter de schermen zonder de applicatiecode aan te raken.
- Je krijgt een plek om governance af te dwingen. Regels voor preventie van dataverlies, PII-redactie, audit-logs voor compliance (SOC 2, GDPR, AI Act), prompt-filtering. Alles gecentraliseerd. Eén plek om een beleid bij te werken in plaats van twintig.
- En je krijgt fallback-betrouwbaarheid. Het soort betrouwbaarheid dat betekent dat je door de volgende provider-storing heen slaapt in plaats van uit bed gebeld te worden.
Het huidige gateway-landschap
De markt is in 2026 genoeg geconsolideerd dat de keuze minder afhangt van functies en meer van waar je al opereert en op welke schaal je werkt.
LiteLLM blijft de standaard open-source optie. Gebaseerd op Python, zelf te hosten ondersteunt meer dan 100 providers via een OpenAI-compatibele API en heeft een grote developer-community. Het is het juiste startpunt als je klein bent, veel met Python werkt en maximale flexibiliteit wilt. De nadelen: de Python-runtime voegt meetbare latentie per verzoek toe in vergelijking met gecompileerde alternatieven, en het project had begin 2026 een incident met de beveiliging van de toeleveringsketen waardoor sommige enterprise-teams nerveus werden over het PyPI-distributiemodel.
Cloudflare AI Gateway is de optie zonder installatie als je al op Cloudflare draait. Het leeft op het edge-netwerk, de gratis versie dekt analytics en basis-caching, en er is geen infrastructuur om te beheren. De beperking is dat het alleen exact-match caching doet, geen semantische, waardoor de besparingen op caching lager zijn dan wat een volwaardige semantic cache oplevert.
Vercel AI Gateway is de natuurlijke keuze voor Next.js-teams die al op Vercel deployen. Nauwe integratie met de Vercel AI SDK en frontend-vriendelijk. Teams die geavanceerde kostenbeheersing of semantic caching nodig hebben, groeien hier snel uit.
Kong AI Gateway is logisch als je Kong al gebruikt voor je reguliere API gateway. Het breidt je bestaande governance- en rate limiting-beleid uit naar LLM-verkeer via AI-specifieke plugins. Semantic caching en rate limiting op basis van tokens vallen onder de enterprise-laag.
Portkey is het product om naar te kijken als kostenoptimalisatie je belangrijkste drijfveer is. Sterke semantic caching, goede multi-provider routing en in de praktijk geteste observabiliteit.
Bifrost (open source, geschreven in Go door Maxim AI) richt zich op de enterprise-kant met hoge doorvoer. 11 microseconden gateway-overhead per verzoek bij 5.000 verzoeken per seconde op een enkele instantie, dual-layer caching en hiërarchische budgetten. De moeite waard als je op serieuze schaal werkt of evalueert voor enterprise governance.
OpenRouter zit dichter bij een marktplaats voor modellen dan een gateway, met meer dan 300 modellen van ruim 60 providers onder één API. Uitstekend voor prototyping en voor teams die brede toegang tot modellen willen zonder infrastructuur te draaien. Governance en zelf-hosting zijn beperkt.
Er zijn er nog meer (Helicone, Inworld Router, TrueFoundry, ngrok AI Gateway, Hyperion), elk met hun eigen invalshoek. Het overkoepelende punt is dat er geen universele winnaar is. Kies degene die past bij hoe je momenteel al deployt.
Hoe je bepaalt of je er een nodig hebt
Een simpele test. Als meer dan één van de volgende punten waar is, heb je een gateway nodig:
- Je maandelijkse LLM-uitgaven zijn boven de €500 en stijgen.
- Je draait in productie en een LLM-storing heeft echte zakelijke gevolgen.
- Je gebruikt meer dan één model-provider, of verwacht dit binnen twaalf maanden te doen.
- Je hebt meer dan één team of project dat de LLM-infrastructuur deelt.
- Je hebt audit-logs, PII-afhandeling of compliance-rapportage nodig.
Als geen van deze punten van toepassing is, heb je waarschijnlijk nog geen gateway nodig. Een enkele SDK-aanroep naar OpenAI of Anthropic is prima voor prototyping. Het moment dat je naar productie gaat met echte gebruikers en echte facturatie, verandert de rekensom snel. Als je niet zeker weet waar jouw workload op deze lijst staat, is een korte AI Feasibility Assessment een verstandige manier om een concreet antwoord te krijgen voordat je je vastlegt op infrastructuur.
Het pragmatische startpunt
Voor de meeste teams ziet het logische pad er als volgt uit. Begin met een managed gateway (Cloudflare als je daar al zit, Vercel als je op Next.js zit, anders Portkey of Bifrost Cloud) om routing, caching en observability binnen een week live te hebben. Instrumenteer je verkeer. Kijk naar wat je werkelijke cache-hitrate is, hoe de verdeling van de complexiteit van verzoeken eruit ziet en waar je uitgaven geconcentreerd zijn.
Dan, en pas dan, begin je met tunen. Stel routing-regels in voor de categorieën verzoeken die duidelijk geen frontier-model nodig hebben. Schakel semantic caching in voor de endpoints waar de intentie repetitief is (support, FAQ, classificatie). Voeg budget-waarborgen toe per team. Meet de situatie voor en na. Teams die hands-on ondersteuning willen bij dit tuning-proces in hun eigen omgeving, kunnen externe hulp inschakelen via AI Consultancy, wat het soort werk is dat zichzelf meestal binnen de eerste facturatiecyclus terugbetaalt.
Als je besparingen in de eerste maand de 25 procent aantikt, ben je op de goede weg. Als ze in de derde maand de 40 procent bereiken, heb je het werk goed gedaan. Als je boven de 50 procent uitkomt, leent jouw workload zich goed voor caching en mag je jezelf gelukkig prijzen. Als je na zes maanden serieuze inspanning onder de 20 procent blijft, behoort jouw workload waarschijnlijk tot de minderheid die niet veel profiteert van caching (bijvoorbeeld veel unieke long-form generatie), en zullen je besparingen in plaats daarvan bijna volledig voortkomen uit routing en provider-arbitrage.
Het getal in de kop is een doel, geen garantie. Het infrastructuur patroon is waar het om gaat. Zodra de gateway er staat, wordt elke toekomstige optimalisatie goedkoper om te implementeren, wordt elke nieuwe provider plug-and-play en wordt elke storing een non-event. Dat is de werkelijke waarde. Die 40 procent is slechts wat je als eerste op de factuur ziet.
Veelgestelde vragen (FAQ)
Is een AI gateway hetzelfde als een API gateway zoals Kong of AWS API Gateway?
Nee. Een traditionele API gateway verzorgt de routing, authenticatie en rate limiting voor REST-endpoints. Een AI gateway doet dat ook, maar voegt daar de onderdelen aan toe die specifiek van belang zijn voor LLM verkeer: semantic caching, model-aware routing, budgetten op basis van tokens, multi-provider fallback en observability per prompt. Kong heeft AI-specifieke plugins toegevoegd om dit gat te dichten, maar de meeste gespecialiseerde AI gateways behandelen LLM-verkeer als een “first-class” workload in plaats van als een extraatje.
Zal het routeren van verzoeken naar kleinere modellen de kwaliteit schaden?
Alleen als de routing logica onzorgvuldig is. Een gateway die blind routeert op basis van stringlengte zal uiteindelijk een complexe redeneertaak naar een model met 3 miljard parameters sturen en onzin produceren. Een correct geconfigureerde gateway maakt gebruik van expliciete regels per endpoint (dit endpoint gaat altijd naar Haiku, dat endpoint altijd naar Opus) of een lichtgewicht classifier om te beslissen. De afweging wat betreft kwaliteit is beheersbaar, maar gaat niet vanzelf. Zorg dat je een evaluatie plant voor en na de implementatie.
Hoe lang duurt het om een gateway in productie te implementeren?
Voor een managed optie zoals Cloudflare AI Gateway, Vercel of Portkey kun je binnen een dag live zijn. Je wijst je base URL en API-key aan en je routeert direct via de gateway. Voor een self-hosted optie zoals LiteLLM of Bifrost moet je rekenen op een week om de infrastructuur, observability en de eerste routing-regels op te zetten. Het realiseren van daadwerkelijke besparingen via de gateway duurt langer; reken op één tot drie maanden voor het finetunen van routing-regels en caching-drempels op basis van het werkelijke verkeer.
Hoe zit het met de dataprivacy en de EU AI Act?
Een gateway is hier juist nuttig. Omdat al het LLM-verkeer door één controlepunt stroomt, heb je één centrale plek om PII-redactie, audit-logging en regels voor data-residentie af te dwingen. Voor workloads die de EU-infrastructuur niet mogen verlaten, kun je de gateway koppelen aan een self-hosted model (bijvoorbeeld Qwen of Llama die op lokale hardware draait) en privacygevoelig verkeer daarheen routeren, terwijl je niet privacy-gevoelig verkeer naar frontier-providers stuurt. De gateway maakt die splitsing praktisch toepasbaar.
Heb ik een gateway nodig als ik slechts één provider gebruik?
Als je er zeker van bent dat je nooit een tweede provider zult gebruiken, is de businesscase voor kostenbesparing minder sterk. Je profiteert nog steeds van semantic caching, budgetbeheer en observability, wat zeker waarde heeft. Maar als je grootste zorg het vermijden van een lock-in en de betrouwbaarheid van de fallback is, levert een gateway die waarde pas echt wanneer je daadwerkelijk ondersteuning voor meerdere providers hebt geconfigureerd.
Wat kost een gateway?
Managed gateways brengen doorgaans ofwel een percentage van jouw LLM-uitgaven in rekening (1 tot 5 procent is gebruikelijk), of een vast maandelijks bedrag op basis van het verzoek volume. Self-hosted opties zoals LiteLLM en Bifrost zijn gratis te gebruiken, maar daarvoor betaal je in infrastructuur en tijd voor ops. Voor de meeste teams liggen de kosten van de gateway ruim onder de 10 procent van de besparingen die het oplevert. Is dat niet het geval, dan heb je de verkeerde gateway gekozen.
