Hoe werkt een LLM-gateway? Een praktische gids voor engineeringteams

Een LLM-gateway zit tussen je applicaties en de modelproviders die je erop aansluit, zodat je op één plek je toegangsgegevens beheert en het gebruik bijhoudt.

“Op dit moment is het één grote s**tshow”, schreef een engineer in september 2026 op Reddit in r/LLMDevs.

“Iedereen heeft zijn eigen set sleutels voor Claude, OpenAI, AWS Bedrock en alle andere inferentieproviders die we gebruiken.”

De berichtgeving van BigGo over llm-proxy-tk, een lichtgewicht FastAPI-gateway, vergelijkt de opzet met het veranderen van LLM’s in “kraanwater voor bedrijven”, met de gateway als hoofdkraan van het gebouw.

Maar voordat je zoveel vertrouwen in het leidingwerk stelt, kijken we eerst wat je eigenlijk installeert.

Wat is een LLM-gateway?

Een LLM-gateway is een reverse proxy voor modelaanroepen. Je applicaties sturen verzoeken naar de gateway in plaats van rechtstreeks naar OpenAI, Anthropic, Google of welke LLM-providers je ook gebruikt. De gateway stuurt die verzoeken door en past onderweg je regels toe.

Elke LLM-provider heeft een eigen API, met een eigen verzoekstructuur, een eigen authenticatie en een eigen manier om fouten terug te geven. Elke provider heeft ook eigen snelheidslimieten en eigen manieren waarop het mis kan gaan. Als er geen gedeelde laag vóór die providers zit, doet elke applicatie die een provider aanroept alles zelf, en telkens net iets anders.

De vergelijking met kraanwater gaat maar tot op zekere hoogte op, maar wel tot hier: providers worden één keer aangesloten, op de gateway. Vanaf dat moment krijgt elke applicatie een eigen aansluiting met meter, zodat je kunt zien wie wat gebruikt en elke afzonderlijke leiding kunt afsluiten zonder aan de andere te komen.

LLM-, AI-, MCP- en API-gateways: wat is het verschil?

Hoe werkt een LLM-gateway?

Volg één verzoek van je applicatie naar het model en weer terug.

1. Het verzoek komt aan bij de gateway: Je applicatie stuurt een normaal ogend chatverzoek, vaak in een OpenAI-compatibel formaat, naar het endpoint van de gateway. Vanuit de applicatie gezien is dit het adres dat ze aanroept om het model te bereiken.
2. De gateway controleert wie de vraag stelt en wat diegene mag doen: Voordat de gateway het verzoek doorstuurt, valideert hij de toegangsgegevens. Vaak is dat een virtuele sleutel die aan een team of product is uitgegeven. Als je invoerguardrails hebt ingebouwd, kunnen prompts ook worden gescand op gevoelige gegevens of op pogingen om de instructies van het model te omzeilen.
3. De gateway controleert of hij het antwoord al heeft: Als caching is ingeschakeld, kan een geschikt, overeenkomend verzoek worden beantwoord met een opgeslagen antwoord, zonder nieuwe aanroep naar de provider. Sommige gateways bieden ook semantische caching, waarbij wordt gezocht naar verzoeken die voldoende vergelijkbaar worden geacht in plaats van identiek. Dat kan goed werken voor verkeer in FAQ-stijl.
4. De gateway kiest waar het verzoek naartoe gaat: Het verzoek kan een specifiek model of een alias noemen. De gateway zoekt de bijbehorende route op in je configuratie. Je kunt ook een back-uproute instellen. Als provider A een time-out geeft, kan de gateway provider B proberen.
5. De gateway bereidt de aanroep voor en stuurt het antwoord terug: Een gateway zet je verzoek om naar het formaat van de gekozen provider en authenticeert de uitgaande aanroep. Zodra het antwoord binnen is, wordt het omgezet naar het formaat dat je applicatie nodig heeft.
6. De gateway legt vast wat er is gebeurd: Als logging is ingeschakeld, legt de gateway gegevens vast zoals wie de aanroep deed, welk model hem afhandelde, het aantal tokens, de latentie en de kosten. Dit is het logboek dat de Reddit-engineer uit de inleiding niet had.

De 4 dingen die je moet weten voordat je een gateway in productie neemt

Alles in het vorige deel is mogelijk omdat de gateway elk verzoek ziet dat erdoorheen loopt. Dat is het verkooppraatje. Maar het is ook een beschrijving van het aanvalsoppervlak en de afhankelijkheid van een leverancier waar je rekening mee moet houden.

De gateway is nu het waardevolste onderdeel van je AI-stack

De gateway centraliseert de toegang. En daarmee brengt hij ook veel toegangsgegevens binnen bereik van één service. Het beveiligingsteam van Microsoft somt op wat een LiteLLM-implementatie kan bevatten of ophalen: API-sleutels van providers, een eigen hoofdsleutel, records van virtuele sleutels, verbindingsstrings voor databases, routeringsinstellingen en tenantbeleid.

In oktober 2026 maakte Check Point Research twee kwetsbaarheden met een hoog risico bekend in LiteLLM:

• Via CVE-2026-35029 konden geauthenticeerde gebruikers, ook gebruikers met alleen-lezenrechten, bij beheerfuncties komen en de instantie overnemen.
• Via CVE-2026-59823 konden gebruikers verzoeken omleiden naar een server die ze zelf beheerden en zo de sleutels van providers onderscheppen.

Beide zijn verholpen in versie 1.83.9. Een applicatie die de gateway gebruikt, zou de instellingen ervan niet moeten kunnen wijzigen.

Je guardrails hebben een beleid nodig voor als ze falen

Een review van Pillar Security van 4 oktober 2026 documenteert integraties van externe guardrails bij grote gateways, waaronder LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management en Apigee. (Pillar verkoopt zelf guardrails, dus houd daar rekening mee bij het lezen van de aanbevelingen.)

Een hook is een punt in het verzoekpad, meestal voordat de prompt naar het model gaat of nadat het antwoord terugkomt, waar de gateway de inhoud aan een externe scanner kan voorleggen voor een oordeel. Een blokkerende controle wacht op dat oordeel voordat het verkeer verder mag. De documentatie van Portkey noemt deze before_request_hooks en after_request_hooks; TrueFoundry gebruikt er vier, met extra controles vóór en na MCP-toolaanroepen.

Er zijn twee dingen om te controleren:

• Wat gebeurt er als de scanner zelf faalt? Als je het verzoek blokkeert, houd je ongecontroleerd verkeer tegen, maar kan je applicatie onderbroken worden. Laat je het door, dan kan je applicatie verder zonder die controle. Het foutenlogboek laat je achteraf zien dat de controle ontbrak. Dat is nuttig, maar niet hetzelfde als de controle daadwerkelijk uitvoeren.
• Kun je de scanner vervangen? Als een andere provider niet wordt ondersteund, moet je misschien je applicatie aanpassen of een extra proxy gebruiken om verbinding te maken.

De MCP-hooks van TrueFoundry breiden het bereik van de gateway uit van modelverzoeken naar toolaanroepen. Maar de gateway kan alleen verkeer inspecteren dat erdoorheen loopt. Een coding-agent die een opdracht uitvoert op de computer van een ontwikkelaar, kan buiten dat zicht vallen.

Numbat, de open-source tool van Perplexity, werkt aan die kant. Numbat maakt via lokale hooks verbinding met ondersteunde agents en kan geplande acties, zoals shellopdrachten of het schrijven van bestanden, inspecteren voordat ze worden uitgevoerd. De blokkeerfunctie is optioneel en staat standaard uit. De gateway ziet het modelverkeer dat via hem wordt gerouteerd. Numbat geeft daarnaast inzicht in wat de agent met het antwoord doet.

Je moet weten waar de controle van de gateway ophoudt

Forkast News onderscheidt drie stromingen die de gateway vanuit verschillende richtingen benaderen:

• LLM-gerichte gateways: LiteLLM en Portkey begonnen met modelaanroepen: vertalen tussen providers, verzoeken routeren en tokens bijhouden. Nu voegen ze controles voor toolaanroepen toe.
• API-managementplatforms: Kong, Apigee van Google en Azure API Management begonnen met authenticatie, machtigingen en verkeersbeheer, en voegden later ondersteuning toe voor modellen en AI-specifieke regels.
• Agent-native infrastructuur: agentgateway is bijvoorbeeld gebouwd rond agents die communiceren met modellen, tools en andere agents, onder meer via MCP en A2A.

De bepalende vraag is wat je routeert:

• Alleen modelaanroepen? Een gateway die primair op LLM’s is gericht, is een goed vertrekpunt.
• Modelaanroepen binnen een organisatie die al vol API-regels zit? Begin met het platform dat je al hebt.
• Agents die tools aanroepen die modellen aanroepen? Controleer of die verbindingen ook worden gedekt.

Je introduceert een gedeeld single point of failure

Stel dat je supportchatbot OpenAI gebruikt en je onderzoekstool Anthropic, en dat beide via dezelfde gateway verbinding maken. Als die gateway uitvalt, verliezen beide tools de toegang tot hun modellen, ook als OpenAI en Anthropic gewoon normaal werken.

Dit is echt gebeurd. Bij Cloudflare piekte het foutpercentage van AI Gateway op 97% tijdens de storing van 12 juni 2025. De gateway was voor zijn instellingen afhankelijk van de opslagdienst Workers KV van Cloudflare, en juist die dienst viel uit.

Als je de gateway zelf draait, houd dan een tweede exemplaar actief dat het kan overnemen als er een uitvalt. Als iemand anders je gateway host, vraag dan hoe ze hem draaiende houden bij storingen en wat er tijdens het herstel met je verzoeken gebeurt.

De belangrijkste functies om op te letten bij LLM-gateways

Je geeft de gateway toegang tot ieders toegangsgegevens, dus je mag er in ruil daarvoor gerust veel van verwachten.

• Eén API vóór meerdere providers: Je code spreekt één formaat, vaak een OpenAI-compatibel formaat, en de gateway vertaalt. LLM-providers komen je daarin tegemoet. Zo ondersteunt de Agent API van Perplexity de Responses API-interface van OpenAI, zodat teams bestaande OpenAI-clientbibliotheken kunnen hergebruiken.
• Virtuele sleutels met gekoppelde regels: Elk team of product krijgt een eigen sleutel, met regels voor toegestane modellen, verzoeklimieten en uitgaven.
• Routering en fallback: De gateway stuurt verzoeken naar modellen op basis van je instellingen, waarbij de nadruk kan liggen op kosten, snelheid of een bepaalde provider. Als een aanroep mislukt, kan hij een ander model proberen. Met de Agent API van Perplexity kun je tot vijf modellen opgeven in je voorkeursvolgorde, ook modellen van verschillende providers.
• Caching: Een opgeslagen antwoord kan je een nieuwe aanroep naar de provider besparen. Sommige gateways herkennen identieke verzoeken; andere kunnen ook verzoeken met een vergelijkbare betekenis herkennen. Controleer of gecachete antwoorden per gebruiker of team gescheiden kunnen worden en of je caching kunt uitschakelen voor gepersonaliseerde of tijdgevoelige antwoorden.
• Streaming en consistente foutmeldingen: Antwoorden komen binnen terwijl ze worden gegenereerd, en fouten van providers worden vertaald naar een formaat dat je applicatie kan verwerken. Controleer wat er gebeurt als je AI-guardrails toevoegt.
• Logging en kostentoewijzing: De gateway legt vast wie een aanroep deed, welk model hem afhandelde, hoeveel tokens er werden gebruikt, hoe lang het duurde en wat de geschatte kosten waren. Controleer of logs prompts en antwoorden bevatten en hoe lang ze worden bewaard.
• Guardrail-hooks: Dit zijn punten in het verzoekpad waar de gateway inhoud naar een externe scanner kan sturen voor een oordeel. Ze zitten meestal vóór een modelverzoek of na het antwoord daarop. Controleer of verzoeken stoppen of doorgaan als de scanner faalt, en of je een andere scanner kunt aansluiten.
• Een beheerinterface die je kunt afschermen: De gateway bepaalt wie bij de toegangsgegevens van providers kan en beheert de regels die iedereen gebruikt. Controleer of je beheerderstoegang los van het applicatieverkeer kunt beperken en of gebruikers met alleen-lezenrechten geen instellingen kunnen wijzigen. De hoofdkraan heeft een slot nodig.

Met welke tools kun je je LLM-gateway bouwen?

De functielijsten van aanbieders op de markt overlappen elkaar. In een Reddit-draad over interne toegang tot modellen stelde de auteur de vraag: voor welke gateway is geen aparte engineer nodig?

Dat is volgens ons de juiste vraag, en er zijn vier antwoorden op, afhankelijk van hoeveel van het werk je zelf voor je rekening wilt nemen.

Bouw hem zelf

Een minimale gateway heeft een kort takenlijstje: verzoeken aannemen, de sleutel van de aanroeper controleren, de toegangsgegevens van de provider toevoegen, de aanroep doorsturen en het resultaat loggen. Maar ondersteuning voor verschillende providerformaten brengt extra werk met zich mee. Net als het draaiende houden van het geheel.

Als je Envoy al gebruikt, kun je met het external-processing-filter een service koppelen die verzoeken en antwoorden inspecteert en aanpast. Die service moet je wel zelf bouwen en draaien.

In een r/LLMDevs-draad over de vraag of een gateway kosten bespaart vertelde u/QuanTradin dat het loggen van tokens en een cache-hit-vlag bij elke aanroep hielp om twee jobs te vinden die de volle prijs betaalden voor identieke prompts.

“...dat oplossen was meer waard dan welke routeringslaag ook zou zijn geweest.”

Dat is één gerapporteerde ervaring, en een goed beginpunt. Zoek uit waarvoor je betaalt voordat je uitgebreide manieren bouwt om het te routeren.

Host zelf een open-source gateway

LiteLLM is hier een veelgemaakte keuze: OpenAI-compatibel, met ondersteuning voor een breed scala aan providers en een grote community. Bifrost is een alternatief dat is gebouwd voor weinig overhead per verzoek. Helicone is het bekijken waard als observability bovenaan je functielijst staat.

Zoals elk product heeft LiteLLM voor sommige teams zijn beperkingen. In een r/aiagents-draad over alternatieven voor zelf bouwen zei u/Own_Bar_920 dat LiteLLM de routering prima afhandelde, maar voor hen tekortschoot bij promptversiebeheer over teams heen en bij continue evals tijdens het wisselen van modellen. Daardoor stapten ze over op een aparte tool.

Die behoeften gaan verder dan basale gatewayroutering, en daar gaat het juist om: als routering de belangrijkste behoefte is, hield LiteLLM bij hen prima stand.

Je krijgt een kant-en-klare functielijst, waarbij sommige functies afhangen van de editie, en je houdt de gateway binnen je eigen netwerk. Je bent ook zelf verantwoordelijk voor patches, wat de eerdere bekendmakingen van Check Point concreet maakten, en voor de beschikbaarheid van de gateway, wat het deel over het single point of failure duidelijk maakte.

Maar houd er in je planning rekening mee dat iemand ervoor moet opdraaien. Een van de zorgen in een r/LLMDevs-draad over gateways voor interne toegang was onderhoud. u/Informal-Writer9685 wilde iets “waarvoor geen aparte engineer nodig is om het te onderhouden” en vroeg of de gemelde instabiliteit van LiteLLM bij upgrades op hun schaal een echt probleem was of alleen in productie speelde.

Gebruik een beheerde gateway

Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter en de gehoste gateway van Portkey draaien de service voor je. Voor een compatibele applicatie kan het eerste verzoek er al doorheen komen met weinig meer dan een gewijzigde URL en een API-sleutel.

Het nadeel is dat elke prompt nu via een derde partij gaat voordat hij bij de provider aankomt. Dat is een extra gegevensverwerker voor je compliance-administratie, en een storing van de gateway zelf is een incident van een leverancier: het is niet aan jou om het op te lossen.

Zo kampte OpenRouter op 17 en 19 februari 2026 met storingen van respectievelijk 38 en 35 minuten, nadat een cachingafhankelijkheid uitviel. Sommige klanten kregen de foutmelding “User not found” en waren tijd kwijt aan het debuggen van volkomen geldige API-sleutels. De fout zat in de infrastructuur van de gateway.

Maar OpenRouter verdient lof: het bedrijf publiceerde een gedetailleerde postmortem en voegde beveiligingen toe om te voorkomen dat een cachestoring de database overbelast. Een beheerde gateway zoals OpenRouter kan de toegang vereenvoudigen, maar zoals u/QuanTradin op r/LLMDevs opmerkt, betekent het samenvoegen van de rekeningen niet automatisch dat de uitgaven dalen.

Breid de API-gateway uit die je al hebt

Als Kong, Apigee of Azure API Management al vóór je services staat, heeft elk daarvan AI-specifieke mogelijkheden: Kong AI Gateway, de AI-gatewaybeleidsregels van Apigee en de AI-gateway van Azure API Management. Je kunt voortbouwen op de authenticatie, netwerkregels en werkprocedures die je al hebt, en modelcontroles toevoegen via plug-ins of beleidsregels.

In een groot bedrijf kan dit de weg van de minste organisatorische weerstand zijn. De AI-functies zijn jonger dan die van de zelfstandige gateways. Test in elk geval tokengebaseerde snelheidsbeperking en streaming via de volledige set plug-ins of beleidsregels die je wilt gebruiken.

Installeer dus vooral die hoofdkraan: de almachtige gateway. Toch heeft de engineer uit de inleiding een punt. De toegang van een bedrijf tot modellen zou niet moeten afhangen van wie er toevallig de juiste sleutel in een la heeft liggen.

Een gateway lost dat op door die sleutels centraal te beheren, waardoor er des te meer op het spel staat als je de la open laat. Je moet weten wiens la het is.

Veelgestelde vragen over LLM-gateways

Is een LLM-gateway gratis?

Als je de categorie bedoelt: sommige LLM-gateways hebben een gratis versie.

LLM-gateways variëren van gratis opensourcesoftware tot betaalde abonnementen vanaf zo’n $ 50 per maand, met prijzen op maat voor enterprise-implementaties. Sommige rekenen in plaats daarvan een percentage; het Standard-abonnement van OpenRouter rekent bijvoorbeeld 5,5% extra bij de aankoop van credits.

Welke LLM-gateway is de beste?

Welk werk ben je bereid zelf op je te nemen?

• Bekijk Bifrost of Helicone als je zelf wilt hosten en de configuratie in eigen hand wilt houden.
• Een beheerde optie zoals OpenRouter of Vercel AI Gateway past bij teams die de service liever door iemand anders laten draaien.
• Gebruik je al Kong of Azure API Management? Bekijk dan eerst welke AI-mogelijkheden die bieden.

Test de opties op je shortlist met je eigen verzoeken, inclusief wat er gebeurt als een provider uitvalt.

Heeft AWS een LLM-gateway?

Ja. Amazon Bedrock AgentCore Gateway ondersteunt modelaanroepen via wat AWS „inference targets” noemt. Daarmee kunnen applicaties via één endpoint providers bereiken, waaronder Amazon Bedrock, OpenAI en Anthropic, terwijl de gateway de inloggegevens van de providers en de routering afhandelt.