Een AI gateway is een proxylaag die tussen je applicatie en een of meer LLM-provider-API's zit. Het centraliseert zaken die anders verspreid zouden zijn over elke service die een model aanroept: authenticatie, rate limiting, kostenallocatie, logging en failover.
Waarom er een aparte laag bestaat
Een LLM-API rechtstreeks aanroepen werkt prima voor één service in ontwikkeling. Zodra meerdere services, teams of omgevingen betrokken zijn, herhaalt dezelfde boilerplate zich: API-sleutelbeheer, retry-logica, timeout-afhandeling, uitgavenregistratie. Een AI gateway verplaatst dat allemaal naar één plek, op dezelfde manier als een gewone API gateway authenticatie en routing centraliseert voor microservices.
Het verschil is dat LLM-verkeer kenmerken heeft die gewoon HTTP-verkeer niet heeft. Verzoeken zijn duur, traag en variabel in tokenaantal. Antwoorden moeten mogelijk op semantisch niveau gecached worden (een opgeslagen antwoord teruggeven voor een query die dicht genoeg bij een eerdere ligt, niet alleen identiek). De gateway kan ook contentfiltering toepassen voordat een prompt het model bereikt en voordat een antwoord de gebruiker bereikt.
Wat een AI gateway doorgaans doet
- Provider-routing. Verzoeken sturen naar OpenAI, Anthropic, een zelf-gehost model of anderen op basis van regels: kosten, latentie, beschikbaarheid of vereiste modelcapaciteit.
- Fallback en retry. Als een provider een fout geeft of een latentiedrempel overschrijdt, probeert de gateway het opnieuw met een andere provider, zonder dat de aanroepende service dat merkt.
- Rate limiting en quota's. Uitgaven- of verzoeklimieten afdwingen per team, per product of per omgeving.
- Observability. Gecentraliseerde logs van elk verzoek, tokenaantal, latentie en kosten. Dit is moeilijk te reconstrueren als elke service afzonderlijk logt.
- Caching. Exacte-match-caching is eenvoudig. Sommige gateways ondersteunen ook semantische caching via vectorsimilariteit, wat overbodige aanroepen vermindert voor queries die functioneel hetzelfde zijn.
- Prompt- en antwoordfiltering. Gevoelige inhoud verwijderen of markeren, guardrails toepassen of persoonsgegevens redigeren voordat data je infrastructuur verlaat.
Hoe het verschilt van een gewone API gateway
Een standaard API gateway routeert HTTP-verkeer, dwingt authenticatie af en handelt rate limits af. Een AI gateway doet dat ook, maar voegt tokenbewuste kostencontroles, modelspecifieke retry-strategieën en vaak semantische caching toe. De twee sluiten elkaar niet uit: veel teams draaien een API gateway voor een AI gateway, of gebruiken één product dat beide afhandelt.
Waar het past in een productiesysteem
Voor een klein project met één model en één aanroepende service voegt een gateway operationele overhead toe zonder veel winst. De afweging verandert wanneer:
- Meerdere services of teams modeltoegang delen
- Je auditbaarheid nodig hebt voor compliance of kostenallocatie
- Je van provider wilt wisselen zonder applicatiecode aan te raken
- Je werkt met een context window dat groot genoeg is dat overbodige aanroepen materiële kosten met zich meebrengen
Voor systemen die gebruikmaken van RAG-pipelines zit een gateway vaak naast de retrievallaag, waarbij de gateway de daadwerkelijke modelaanroepen afhandelt terwijl de retrievallogica afzonderlijk werkt.
Implementatieopties
Gateways kunnen zelf-gehost worden (er zijn open-source opties beschikbaar) of als managed service draaien. Zelf-hosten geeft meer controle over waar data naartoe gaat, wat belangrijk is als je compliancebeleid vereist dat prompts binnen een bepaalde jurisdictie blijven. Managed services verminderen de operationele last, maar introduceren een derde partij in het datapad.
Voor teams met EU-dataresidenievereisten is de hostinglocatie van de gateway geen detail. Als prompts persoonsgegevens bevatten, is de gateway een gegevensverwerker en moet die ook als zodanig worden behandeld.
Waar we op testen
Engineers die met AI gateways werken, moeten meer begrijpen dan alleen configuratie. De vetting van Miyagami omvat Orchestration, not prompting: of een kandidaat kan redeneren over de plek van een gateway in een multi-service architectuur, waarvoor die wel en niet verantwoordelijk zou moeten zijn, en hoe je voorkomt dat je logica te sterk centraliseert die eigenlijk in de applicatie thuishoort. We beoordelen ook oordeelsvermogen bij onvolledige specs, omdat gateway-configuratiebeslissingen, zoals wanneer te cachen, wanneer te failoveren en wat te loggen, vaak trade-offs inhouden die de initiële briefing niet oplost.
Korte antwoorden
Heb ik een AI gateway nodig als ik maar één LLM-provider gebruik?
Niet per se. Met één provider en één service zijn directe API-aanroepen eenvoudiger. Een gateway wordt de moeite waard wanneer je gecentraliseerde logging, kostencontroles over teams heen of de mogelijkheid nodig hebt om van provider te wisselen zonder applicatiecode te wijzigen.
Kan een AI gateway mijn LLM-kosten verlagen?
Dat kan. Het cachen van herhaalde of nagenoeg identieke queries voorkomt overbodige modelaanroepen. Rate limits en quota's voorkomen ongecontroleerde uitgaven. Routing naar goedkopere modellen voor eenvoudigere verzoeken verlaagt ook de kosten, maar die routinglogica moet wel expliciet worden gedefinieerd.
Is een AI gateway hetzelfde als een MCP-server?
Nee. Een AI gateway zit tussen je applicatie en model-API's en handelt routing en observability af. Een MCP-server stelt tools en context beschikbaar aan een agent tijdens runtime. Ze richten zich op verschillende lagen en kunnen naast elkaar bestaan in hetzelfde systeem.
