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.<\/p>\n\n\n\n
- \n
- Elk verzoek naar het goedkoopste model dat de taak aankan,<\/li>\n\n\n\n
- Antwoorden cachen op vragen die al eerder zijn gesteld,<\/li>\n\n\n\n
- Terugvallen op een tweede provider wanneer de eerste offline is,<\/li>\n\n\n\n
- Budgetten per team en per project afdwingen,<\/li>\n\n\n\n
- Loggen en meten wat er feitelijk wordt uitgegeven, door wie, waaraan.<\/li>\n<\/ul>\n\n\n\n
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\u00f3g crucialer is dan bij een normale REST API. Ter illustratie: \u00e9\u00e9n verkeerd gerouteerde aanroep naar Claude Opus kan meer kosten dan tienduizend Redis-lookups.<\/p>\n\n\n\n
![\"Ai](\"https:\/\/datanorth.ai\/wp-content\/uploads\/2026\/05\/image-1.png\")
<\/figure>\n\n\n\nWaar de 40% feitelijk vandaan komt<\/h2>\n\n\n\n
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. <\/p>\n\n\n\n
1. Model-routing op basis van complexiteit<\/h3>\n\n\n\n
Dit is de grootste individuele hefboom, en het is degene die de meeste teams laten liggen.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
De gateway maakt dit in de praktijk heel eenvoudig. Je stelt de routingregels \u00e9\u00e9n 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
2. Semantic caching<\/h3>\n\n\n\n
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\u00efeve infrastructuur. Elke call verbruikt tokens.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
De cijfers vari\u00ebren 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 \u20ac5.000 bespaart \u20ac1.000 per maand, terwijl de cache-infrastructuur zelf minder dan 5 procent van de besparingen kost.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Een valkuil die genoemd moet worden: context-lekkage. Als gebruiker A een vraag stelt die priv\u00e9gegevens (PII) bevat en gebruiker B stelt iets wat semantisch vergelijkbaar is, zal een na\u00efeve 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.<\/p>\n\n\n\n
3. Fallbacks, load balancing, en provider arbitrage<\/h3>\n\n\n\n
De derde besturingshefboom is minder voor de hand liggend, maar re\u00ebel. Wanneer je via een gateway routeert, ben je niet langer gebonden aan de prijzen of beschikbaarheid van \u00e9\u00e9n 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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\u00d70,78\u00d70,90, wat neerkomt op ongeveer 42 procent korting op de oorspronkelijke rekening. Dat is waar het getal uit de kop vandaan komt.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Wat een AI gateway je biedt naast besparingen<\/h2>\n\n\n\n
Het kostenverhaal is de makkelijke verkoop, maar het operationele verhaal is de reden waarom gateways onmisbaar worden.<\/p>\n\n\n\n
- \n
- Je krijgt observabiliteit.<\/strong> 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.<\/li>\n\n\n\n
- 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 \u00e9\u00e9n weekend het kwartaal budget opbrandt.<\/li>\n\n\n\n
- Je krijgt provider-onafhankelijkheid.<\/strong> Je applicatiecode is niet langer getrouwd met de SDK van OpenAI of het berichtformaat van Anthropic. De gateway stelt \u00e9\u00e9n OpenAI-compatibele API beschikbaar, en je wisselt van provider achter de schermen zonder de applicatiecode aan te raken.<\/li>\n\n\n\n
- Je krijgt een plek om governance af te dwingen.<\/strong> Regels voor preventie van dataverlies, PII-redactie, audit-logs voor compliance (SOC 2, GDPR, AI Act), prompt-filtering. Alles gecentraliseerd. E\u00e9n plek om een beleid bij te werken in plaats van twintig.<\/li>\n\n\n\n
- 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.<\/li>\n<\/ul>\n\n\n\n
Het huidige gateway-landschap<\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
LiteLLM<\/strong> <\/a>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.<\/p>\n\n\n\n
Cloudflare <\/strong><\/a>A<\/a><\/strong>I Gateway<\/strong><\/a> 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.<\/p>\n\n\n\n
Vercel AI Gateway<\/strong><\/a> 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.<\/p>\n\n\n\n
Kong AI Gateway<\/strong> <\/a>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.<\/p>\n\n\n\n
Portkey<\/strong><\/a> 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.<\/p>\n\n\n\n
Bifrost<\/strong> <\/a>(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\u00ebrarchische budgetten. De moeite waard als je op serieuze schaal werkt of evalueert voor enterprise governance.<\/p>\n\n\n\n
OpenRouter<\/strong><\/a> zit dichter bij een marktplaats voor modellen dan een gateway, met meer dan 300 modellen van ruim 60 providers onder \u00e9\u00e9n API. Uitstekend voor prototyping en voor teams die brede toegang tot modellen willen zonder infrastructuur te draaien. Governance en zelf-hosting zijn beperkt.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Hoe je bepaalt of je er een nodig hebt<\/h2>\n\n\n\n
Een simpele test. Als meer dan \u00e9\u00e9n van de volgende punten waar is, heb je een gateway nodig:<\/p>\n\n\n\n
- \n
- Je maandelijkse LLM-uitgaven zijn boven de \u20ac500 en stijgen.<\/li>\n\n\n\n
- Je draait in productie en een LLM-storing heeft echte zakelijke gevolgen.<\/li>\n\n\n\n
- Je gebruikt meer dan \u00e9\u00e9n model-provider, of verwacht dit binnen twaalf maanden te doen.<\/li>\n\n\n\n
- Je hebt meer dan \u00e9\u00e9n team of project dat de LLM-infrastructuur deelt.<\/li>\n\n\n\n
- Je hebt audit-logs, PII-afhandeling of compliance-rapportage nodig.<\/li>\n<\/ul>\n\n\n\n
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 <\/a>een verstandige manier om een concreet antwoord te krijgen voordat je je vastlegt op infrastructuur.<\/p>\n\n\n\n
Het pragmatische startpunt<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
- Je krijgt observabiliteit.<\/strong> 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.<\/li>\n\n\n\n