Perplexity publicerar en förklaring av AI-gateways funktion och begränsningar

Perplexity publicerade den 20 oktober 2026 en guide som förklarar hur AI-gateways dirigerar, mäter och styr trafiken mellan applikationer och stora språkmodeller, och när en organisation behöver en sådan. Inlägget, med titeln ”Vad är en AI-gateway? En guide till dirigering, kostnadskontroll och styrning av trafik från LLM:er och agenter”, var det senaste inlägget på företagets blogg.

Definition och hantering av förfrågningar

Guiden definierar en AI-gateway som ett centralt proxylager mellan en organisations applikationer eller AI-agenter å ena sidan och de stora språkmodeller och verktyg som de använder å andra sidan. Dirigering, kostnadskontroll, säkerhetskontroller och användningsövervakning hanteras på samma ställe. Eftersom varje leverantör (guiden nämner OpenAI, Anthropic, Google, modeller med öppen källkod och egenhostade slutpunkter) tillhandahåller egna SDK:er, API-nycklar och format för anrop tar gatewayen emot en standardiserad förfrågan och översätter den till formatet för den aktuella leverantören. Modeller kan läggas till, bytas ut eller tas ur bruk genom gatewayens konfiguration i stället för genom ändringar i applikationskoden.

Enligt guiden passerar varje förfrågan som skickas till gatewayens bas-URL genom samma fyra steg: gatewayen autentiserar och godkänner den som anropar med hjälp av en nyckel och en roll; tillämpar policyer som tokenbegränsningar, budgetar och skyddsräcken, däribland maskering av personligt identifierande information (PII); dirigerar förfrågan till en modell eller leverantör utifrån kostnad, svarstid eller tillgänglighet, växlar över till en reservlösning och översätter förfrågan till mål­leverantörens format; samt loggar modellen, antalet token, svarstiden och resultatet för kostnadsuppföljning och felsökning.

Funktioner och angivna begränsningar

Guiden beskriver sex funktionsområden. Dirigering och redundans väljer modell utifrån kostnad, svarstid eller kapacitet och omdirigerar automatiskt förfrågningar när en leverantör ligger nere eller har begränsat antalet anrop. Tokenbaserade anropsbegränsningar och budgetar sätter ett tak för användningen per team, projekt eller användare och avvisar förfrågningar när en tilldelad gräns har nåtts. Semantisk cachelagring matchar nya instruktioner med sparade svar utifrån betydelsen och returnerar det lagrade svaret utan att anropa en modell när instruktionerna är tillräckligt lika. Skyddsräcken granskar varje instruktion och varje svar, tar bort personuppgifter eller känsliga uppgifter innan de når en leverantör, minskar risken för promptinjektion och filtrerar bort oönskat innehåll. Observerbarhet registrerar vilken modell som kördes, tokenanvändning, svarstid och fel, medan styrningsfunktioner ger åtkomst till modeller utifrån användarroller och sparar en granskningslogg över varje anrop.

När det gäller begränsningar uppger guiden att en gateway ökar svarstiden, men beskriver fördröjningen som relativt liten för LLM-trafik. Den hänvisar till ett oberoende riktmärke från juni 2026, genomfört av Broadcoms VMware Cloud Foundation-team, där en finjusterad Envoy AI Gateway lade till cirka 2 millisekunder per förfrågan vid upp till 224 samtidiga användare, med dirigering och anropsbegränsning men utan innehållsgranskning. I samma riktmärke, enligt guiden, anges att skyddsräcken och semantisk cachelagring kan lägga till tiotals till hundratals millisekunder. Guiden uppger också att gateways inte avgör vad man ska fråga en modell, kommer ihåg konversationer, kör en agents stegvisa logik eller bedömer svarens kvalitet. Den varnar dessutom för att kostnadsstyrd dirigering kan försämra kvaliteten när en billigare modell ger ett sämre svar.

Gatewaytyper och agenttrafik

Guiden jämför AI-gateways med traditionella API-gateways utifrån flera aspekter: mätning av tokenanvändning jämfört med gränser för antal förfrågningar, semantisk cachelagring jämfört med cachelagring med exakt matchning, granskning av instruktioner för att hitta känsliga uppgifter och dolda instruktioner jämfört med autentisering med nyckel samt dirigering till modeller utifrån kostnad, svarstid eller kapacitet jämfört med dirigering till backendtjänster. Den skiljer också mellan två snävare begrepp: en LLM-gateway hanterar själva modell-anropet, medan en MCP-gateway styr vilka verktyg och datakällor en agent kan nå via Model Context Protocol. LiteLLM, Portkey, Azure API Management och Envoy AI Gateway har numera stöd för MCP-styrning, påpekar guiden, vilket innebär att begreppen beskriver överlappande kontrollager.

För agenter, som enligt guiden arbetar i loopar med modell-anrop och verktygsanvändning tills en uppgift är slutförd, styr och övervakar gatewayen all trafik som agenten initierar, godkänner vilka verktyg och datakällor agenten får åtkomst till och registrerar alla modell- och verktygsanrop i en granskningslogg.

Uppgifter om införande och vägledning för driftsättning

För att uppskatta efterfrågan hänvisar guiden till uppgifter från tredje part. I Cisco AI Readiness Index 2025 uppgav 83 % av 8 039 tillfrågade högre chefer vid företag med fler än 500 anställda att de planerar att utveckla eller driftsätta AI-agenter. Gartner räknar med att uppgiftsspecifika agenter kommer att finnas i 40 % av företagsapplikationerna i slutet av 2026, jämfört med under 5 % 2025. När det gäller kostnader hänvisar guiden till undersökningen DoiT/Sapio 2026, där 79 % av de deltagande ekonomicheferna uppgav att de hade överskridit sin AI-budget under det senaste året. Den hänvisar också till en undersökning från Dataiku och Harris Poll 2026, där 93 % av CIO:er på storföretag uppgav att olika modeller presterar bättre för olika användningsområden, 81 % av företagen räknar med att använda två eller fler modellleverantörer och 55 % har bytt LLM-leverantör minst en gång.

Oberoende övervakning som guiden hänvisar till uppskattade ledande LLM-leverantörers drifttid till omkring 99,85–99,9 % i maj 2026, en nivå som guiden räknar om till ungefär 9–13 timmars avbrott per år. I en undersökning från Cockroach Labs 2026, med 1 125 ledande infrastrukturbeslutsfattare, uppskattade två tredjedelar att en timmes avbrott i AI-tjänster skulle kosta deras organisation mer än 100 000 dollar. Guiden hänvisar också till OWASP:s ranking från 2025, där promptinjektion rankas som den största säkerhetsrisken för LLM:er, och till ett resultat från Zscaler ThreatLabz som visar att mängden företagsdata som skickas till AI-applikationer ökade med 93 % på ett år och att ChatGPT ensamt utlöste 410 miljoner överträdelser av regler för att förebygga dataförlust.

Guiden listar tecken på att en organisation behöver en gateway: leverantörsnycklar som är hårdkodade i flera kodbaser, modellfakturor som ekonomiavdelningen inte kan hänföra till någon användning, fel på grund av hastighetsbegränsningar eller driftstopp kopplade till beroendet av en enda leverantör, oinspekterade promptar med känsliga uppgifter, konkurrerande leverantörsintegrationer mellan olika team, MCP-verktygsintegrationer och avsaknad av en överblick över säkerhet och regelefterlevnad. Enligt guiden behövs ingen gateway för en enstaka prototyp, ett sidoprojekt med liten trafik eller anrop till en enda modellslutpunkt med minimala säkerhetskrav. Bland de självhostade alternativen finns LiteLLM, Portkey och Apache APISIX i ett privat moln, Kubernetes eller en lokal infrastruktur. Bland de hanterade alternativen finns Cloudflare AI Gateway, Azure API Management och Amazon Bedrock AgentCore Gateway. Guiden beskriver valet utifrån kontroll över data och integritet, den operativa bördan – inklusive tillståndslager som PostgreSQL, Redis eller etcd – driftsättningshastighet och integrationer. I FAQ:n står det att ”gateway för generativ AI” och ”AI-gateway” är utbytbara begrepp och att det inte finns någon entydigt bästa AI-gateway med öppen källkod.