LLM-gateway

Wat is een LLM-gateway?

Een LLM-gateway staat tussen je toepassingen en de taalmodellen die ze aanroepen. In plaats van dat elke toepassing haar eigen sleutel bijhoudt en rechtstreeks een modelendpoint aanspreekt, roepen ze allemaal de gateway aan, en die beslist wat er daarna gebeurt.

Als dat bekend klinkt, dan klopt dat. Het is hetzelfde idee als een API gateway, toegepast op een ander soort backend. Wat het een eigen naam waard maakt, is dat je er andere dingen mee moet regelen. Bij een gewone API let je op het aantal aanvragen per seconde. Bij een taalmodel let je op tokens, want tokens zijn waarvoor je gefactureerd wordt en tokens zijn waarin je quota gemeten wordt.

Microsoft beschrijft zijn versie, de AI gateway in Azure API Management, als een uitbreiding van de bestaande API gateway en niet als een apart product. Die framing is nuttig: dit is geen nieuwe categorie infrastructuur, dit is je API-laag die een nieuw soort verkeer leert kennen.

Wat een gateway effectief doet

Tokenlimieten per afnemer. Dit is de reden waarom de meeste teams er een zetten. Je modelimplementatie heeft een quota uitgedrukt in tokens per minuut. Delen drie toepassingen die quota en gaat er één in een lus, dan vallen de twee andere stil. Met een gateway kan je een tokenlimiet of een tokenquota zetten per toepassing, per team of per abonnementssleutel, over een uur, een dag, een maand of een jaar. Hij kan de tokens in een prompt ook op voorhand inschatten, zodat een te grote aanvraag aan de gateway geweigerd wordt in plaats van quota op te eten aan de achterkant.

Belasting verdelen en stroomonderbreking. Je kan meerdere modelendpoints achter één gateway zetten en het verkeer erover verdelen, met round robin, met gewichten of met prioriteit. Prioriteit gebruik je als je gereserveerde capaciteit hebt die je eerst wil vullen, met betalen-per-gebruik erachter als overloop. Een stroomonderbreker stopt met verkeer sturen naar een backend die niet meer reageert, en komt terug zodra die hersteld is.

Semantische cache. Een gewone cache helpt enkel als twee aanvragen letterlijk identiek zijn, en dat gebeurt bij prompts zowat nooit. Een semantische cache vergelijkt de betekenis van de nieuwe prompt met prompts die hij al gezien heeft, en hergebruikt het antwoord als ze dicht genoeg bij elkaar liggen. Bij een supportassistent waar mensen hetzelfde op twintig manieren vragen, scheelt dat zowel in kosten als in wachttijd.

Aanmelden zonder overal sleutels. De gateway kan zich bij het model aanmelden met een managed identity, waardoor je toepassingen zelf nooit een modelsleutel in handen krijgen. Dat haalt een hele reeks problemen weg: sleutels in configuratiebestanden, sleutels in je broncode, sleutels die niemand nog durft te vervangen.

Controle op inhoud. Je kan prompts aan de gateway langs een inhoudscontrole sturen, en dan geldt die regel meteen voor al je toepassingen in plaats van dat ze in elk van hen apart gebouwd moet worden.

Eén plek waar alles gelogd staat. Prompts, antwoorden en tokenaantallen kan je centraal loggen, met eigen dimensies zoals de aanroepende toepassing of de gebruiker. Zo kan je eindelijk zeggen welk team verantwoordelijk is voor welk stuk van de factuur.

Waarom de tweede toepassing het kantelpunt is

Met één toepassing die één model aanroept, is een gateway overhead. Je zet een tokenlimiet op de implementatie zelf en daarmee is de kous af.

Zodra er een tweede toepassing bijkomt, duiken er meteen drie vragen op die je zonder gateway niet kan beantwoorden. Welke van de twee heeft vanochtend de quota opgesoupeerd. Welke van de twee draagt welk stuk van de factuur. En als je volgend kwartaal naar een ander model of een andere aanbieder moet, hoeveel codebases moet je dan aanpassen.

Die laatste vraag is het argument dat de meeste mensen overtuigt. Roepen je toepassingen de gateway aan in plaats van het model, dan is het model erachter vervangen een kwestie van configuratie. Microsoft is daar nog verder in gegaan met een unified model API die meerdere aanbieders achter één endpoint aanbiedt en de formaten vertaalt, zodat je modellen van verschillende leveranciers met één set regels kan beheren.

Gateways zijn intussen ook voorbij modellen gegroeid. Dezelfde laag staat nu voor MCP-servers en A2A-agent-API's, wat betekent dat de tools die je agents gebruiken en de agents zelf dezelfde behandeling krijgen als je modelverkeer: aanmelden, begrenzen, loggen en beleid op één plek.

Waar moet je op letten bij een LLM-gateway

Je hebt er een enkel faalpunt bij. Alles wat met AI te maken heeft, loopt nu door één component. Dat is precies wat je wou voor je governance, en het betekent dat de gateway dezelfde aandacht voor beschikbaarheid nodig heeft als de rest van je kritieke pad.

Een semantische cache kan het verkeerde antwoord geven. Twee prompts die qua betekenis dicht bij elkaar liggen, liggen niet altijd dicht genoeg. "Wat is de opzegtermijn bij een contract van onbepaalde duur" en "wat is de opzegtermijn bij een contract van bepaalde duur" liggen erg dicht bij elkaar en hebben een ander antwoord. Zet je drempel dus zorgvuldig en hou gepersonaliseerde antwoorden of antwoorden die van rechten afhangen volledig uit de cache.

Centraal loggen is centraal risico. Eén plek waar elke prompt en elk antwoord van het hele bedrijf staat, is een aantrekkelijk doelwit en een vraag rond gegevensbescherming. Beslis wat je bijhoudt en wie het mag lezen voor je het aanzet.

Een te strakke limiet is onzichtbaar. Botst een toepassing tegen haar tokenquota, dan zien gebruikers meestal een vage foutmelding en geen bericht dat het budget op is. Zorg dat die limiet ergens opduikt waar een mens naar kijkt.

Het is een controlepunt en geen beleid. Een gateway geeft je de mogelijkheid om limieten en regels af te dwingen. Welke limieten en welke regels blijft een beslissing die je bedrijf zelf moet nemen, en het component kopen neemt die beslissing niet voor je.