Hur fungerar en LLM-gateway? En praktisk guide för utvecklingsteam

En LLM-gateway ligger mellan dina applikationer och de modelleverantörer du ansluter via den, och ger dig ett enda ställe där du hanterar autentiseringsuppgifter och följer upp användningen.

”Just nu är det ett enda sk*tkaos”, skrev en ingenjör på Reddit i r/LLMDevs i september 2026.

”Alla har sin egen uppsättning nycklar för Claude, OpenAI, AWS Bedrock och alla andra inferensleverantörer vi använder.”

BigGos bevakning av llm-proxy-tk, en lättviktig FastAPI-gateway, liknar upplägget vid att göra LLM:er till ”kranvatten för företag”, med gatewayen som byggnadens huvudventil.

Men innan du sätter så stor tilltro till rörsystemet ska vi titta på vad det är du installerar.

Vad är en LLM-gateway?

En LLM-gateway är en omvänd proxy för modellanrop. Dina applikationer skickar förfrågningar till den i stället för direkt till OpenAI, Anthropic, Google eller vilka LLM-leverantörer du nu använder. Gatewayen vidarebefordrar förfrågningarna och tillämpar dina regler på vägen.

Varje LLM-leverantör har ett eget API, med en egen struktur för förfrågningar, en egen autentisering och ett eget sätt att returnera fel. Var och en har dessutom separata hastighetsbegränsningar och egna sätt att fallera. Om det inte finns något gemensamt lager framför dem måste varje applikation som anropar en leverantör sköta allt själv – och gör det på lite olika sätt.

Liknelsen med kranvatten räcker bara en bit, men den räcker så här långt: leverantörerna kopplas in en gång, i gatewayen. Därefter får varje applikation en egen anslutning med egen mätare, så att du kan se vem som använder vad och stänga av en enskild ledning utan att röra de andra.

LLM-, AI-, MCP- och API-gatewayer: Vad är skillnaden?

Hur fungerar en LLM-gateway?

Följ en förfrågan från din applikation till modellen och tillbaka.

1. Förfrågan når gatewayen: Din applikation skickar en helt vanlig chattförfrågan, ofta i ett OpenAI-kompatibelt format, till gatewayens slutpunkt. Ur applikationens perspektiv är det den här adressen den anropar för att nå modellen.
2. Gatewayen kontrollerar vem som frågar och vad de får göra: Innan förfrågan vidarebefordras validerar den autentiseringsuppgifterna. Ofta är det en virtuell nyckel som har utfärdats till ett team eller en produkt. Om du har kopplat in skyddsräcken för indata kan prompter också genomsökas efter känsliga uppgifter eller försök att åsidosätta modellens instruktioner.
3. Gatewayen kontrollerar om den redan har svaret: Om cachelagring är aktiverad kan en kvalificerad matchande förfrågan besvaras med ett sparat svar utan ytterligare ett leverantörsanrop. Vissa gatewayer erbjuder också semantisk cachelagring, som letar efter förfrågningar som bedöms vara tillräckligt lika snarare än identiska. Det kan passa för trafik av FAQ-typ.
4. Gatewayen väljer vart förfrågan ska skickas: Förfrågan kan ange en specifik modell eller ett alias. Gatewayen slår upp motsvarande rutt i din konfiguration. Du kan också konfigurera en reservrutt. Om leverantör A inte svarar i tid kan gatewayen prova leverantör B.
5. Gatewayen förbereder anropet och returnerar svaret: En gateway omvandlar din förfrågan till den valda leverantörens format och autentiserar det utgående anropet. Så snart svaret har tagits emot omvandlas det till det format som din applikation kräver.
6. Gatewayen registrerar vad som hände: När loggning är aktiverad registrerar gatewayen uppgifter som vem som gjorde anropet, vilken modell som hanterade det, antal tokens, latens och kostnad. Det här är loggen som Reddit-ingenjören från inledningen saknade.

4 saker du behöver veta innan du tar en gateway i produktion

Allt i avsnittet ovan är möjligt eftersom gatewayen ser varje förfrågan som dirigeras genom den. Det är säljargumentet. Men det är också en beskrivning av den attackyta och det leverantörsberoende du måste planera för.

Gatewayen är nu den mest värdefulla komponenten i din AI-stack

Gatewayen centraliserar åtkomsten. Därmed placerar den också en stor mängd autentiseringsuppgifter inom räckhåll för en enda tjänst. Microsofts säkerhetsteam listar vad en LiteLLM-driftsättning kan innehålla eller hämta: leverantörernas API-nycklar, en egen huvudnyckel, poster för virtuella nycklar, anslutningssträngar till databaser, routningsinställningar och policyer för klientorganisationer.

I oktober 2026 offentliggjorde Check Point Research två allvarliga sårbarheter i LiteLLM:

• CVE-2026-35029 gjorde det möjligt för autentiserade användare, även de med enbart läsbehörighet, att nå administrativa funktioner och ta över instansen.
• CVE-2026-59823 gjorde det möjligt för användare att omdirigera förfrågningar till en server de kontrollerade och fånga upp leverantörsnycklar.

Båda åtgärdades i version 1.83.9. En applikation som använder gatewayen ska inte kunna ändra dess inställningar.

Dina skyddsräcken behöver en policy för när de fallerar

En granskning från Pillar Security den 4 oktober 2026 dokumenterar integrationer av skyddsräcken från tredje part i stora gatewayer, däribland LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management och Apigee. (Pillar säljer skyddsräcken, så ha det i åtanke när du läser deras rekommendationer.)

En hook är en punkt i förfrågningsflödet, vanligtvis innan prompten skickas till modellen eller efter att svaret har kommit tillbaka, där gatewayen kan lämna över innehållet till en extern skanner för bedömning. En blockerande kontroll väntar på bedömningen innan trafiken får fortsätta. Portkeys dokumentation kallar dessa before_request_hooks och after_request_hooks; TrueFoundry kör fyra och lägger till kontroller före och efter MCP-verktygsanrop.

Nu finns det två saker att kontrollera:

• Vad händer om själva skannern fallerar? Om du blockerar förfrågan stoppar du okontrollerad trafik, men du riskerar att avbryta din applikation. Släpper du igenom den kan applikationen fortsätta utan kontrollen. Felloggen visar i efterhand att kontrollen saknades, vilket är användbart, men inte detsamma som att faktiskt ha kört den.
• Kan du byta ut skannern? Om en annan leverantör inte stöds kan du behöva uppdatera din applikation eller använda en annan proxy för att ansluta.

TrueFoundrys MCP-hookar utökar gatewayens räckvidd från modellförfrågningar till verktygsanrop. Men den kan bara inspektera trafik som passerar genom den. En kodagent som kör ett kommando på en utvecklares dator kan befinna sig utanför det synfältet.

Numbat, Perplexitys verktyg med öppen källkod, arbetar på just den sidan. Numbat ansluter till agenter som stöds via lokala hookar och kan inspektera planerade åtgärder, som skalkommandon eller filskrivningar, innan de körs. Blockeringsfunktionen är valfri och avstängd som standard. Gatewayen ser modelltrafiken som dirigeras genom den. Numbat ger dessutom insyn i vad agenten gör med svaret.

Du behöver veta var gatewayens kontroll tar slut

Forkast News identifierar tre utvecklingslinjer som närmar sig gatewayen från olika håll:

• LLM-fokuserade gatewayer: LiteLLM och Portkey började med modellanrop: översättning mellan leverantörer, routning av förfrågningar och spårning av tokens. Nu lägger de till kontroller för verktygsanrop.
• Plattformar för API-hantering: Kong, Googles Apigee och Azure API Management började med autentisering, behörigheter och trafikhantering och lade sedan till stöd för modeller och AI-specifika regler.
• Agentnativ infrastruktur: agentgateway är till exempel byggt kring agenter som kommunicerar med modeller, verktyg och andra agenter, bland annat via MCP och A2A.

Den avgörande frågan är vad du dirigerar:

• Bara modellanrop? En gateway som är byggd främst för LLM:er är en bra utgångspunkt.
• Modellanrop i ett företag som redan är fullt av API-regler? Börja med plattformen du redan har.
• Agenter som anropar verktyg som anropar modeller? Kontrollera att även de anslutningarna täcks.

Du inför en gemensam felpunkt

Säg att din supportchattbot använder OpenAI och ditt researchverktyg använder Anthropic – och att båda ansluter via samma gateway. Om den gatewayen slutar fungera förlorar båda verktygen åtkomsten till sina modeller, även om OpenAI och Anthropic fungerar som vanligt.

Det här har faktiskt hänt. Felfrekvensen för Cloudflares AI Gateway nådde som mest 97 % under avbrottet den 12 juni 2025. Gatewayen var beroende av Cloudflares lagringstjänst Workers KV för sina inställningar, och den tjänsten fallerade.

Om du kör gatewayen själv bör du ha ytterligare en instans igång som kan ta över om en fallerar. Om någon annan står för driften av din gateway bör du fråga hur de håller den igång vid fel och vad som händer med dina förfrågningar under återställningen.

De viktigaste funktionerna att leta efter i en LLM-gateway

Du kommer att ge gatewayen tillgång till allas autentiseringsuppgifter, så du bör ställa höga krav på vad den ger i gengäld.

• Ett API framför flera leverantörer: Din kod talar ett format, ofta ett OpenAI-kompatibelt, och gatewayen översätter. LLM-leverantörerna möter dig på halva vägen. Perplexitys Agent API stöder till exempel gränssnittet för OpenAI:s Responses API, så att team kan återanvända befintliga OpenAI-klientbibliotek.
• Virtuella nycklar med kopplade regler: Varje team eller produkt får en egen nyckel, med regler för tillåtna modeller, gränser för förfrågningar och utgifter.
• Routning och reservalternativ: Gatewayen skickar förfrågningar till modeller utifrån dina inställningar, som kan prioritera kostnad, hastighet eller en viss leverantör. Om ett anrop misslyckas kan den prova en annan. Med Perplexitys Agent API kan du ange upp till fem modeller, även från olika leverantörer, i den ordning du föredrar.
• Cachelagring: Ett sparat svar kan bespara dig ytterligare ett leverantörsanrop. Vissa gatewayer matchar identiska förfrågningar, medan andra även kan matcha förfrågningar med liknande innebörd. Kontrollera om cachelagrade svar kan hållas åtskilda per användare eller team, och om du kan stänga av cachelagring för personanpassade eller tidskänsliga svar.
• Strömning och enhetliga fel: Svaren levereras medan de genereras, och leverantörsfel översätts till ett format som din applikation kan hantera. Kontrollera vad som händer när du lägger till AI-skyddsräcken.
• Loggning och kostnadsfördelning: Gatewayen registrerar vem som gjorde ett anrop, vilken modell som hanterade det, hur många tokens det använde, hur lång tid det tog och dess uppskattade kostnad. Kontrollera om loggarna innehåller prompter och svar och hur länge de sparas.
• Hookar för skyddsräcken: Det här är punkter i förfrågningsflödet där gatewayen kan skicka innehåll till en extern skanner för bedömning. De sitter ofta före en modellförfrågan eller efter dess svar. Kontrollera om förfrågningar stoppas eller fortsätter när skannern fallerar, och om du kan ansluta en annan skanner.
• Ett administratörsgränssnitt som du kan låsa: Gatewayen hanterar åtkomsten till leverantörernas autentiseringsuppgifter och de regler som alla använder. Kontrollera att du kan begränsa administratörsåtkomsten separat från applikationstrafiken och att användare med enbart läsbehörighet inte kan ändra inställningar. Huvudventilen behöver ett lås.

Vilka verktyg kan du använda för att bygga din LLM-gateway?

På marknaden överlappar funktionslistorna i hög grad. I en Reddit-tråd om intern modellåtkomst frågade trådskaparen: vilken gateway kräver inte en dedikerad ingenjör?

Det är enligt oss rätt fråga, och den har fyra svar, beroende på hur mycket av arbetet du är beredd att ta ansvar för.

Skriv den själv

En minimal gateway hanterar en kort lista med uppgifter: ta emot förfrågningar, kontrollera anroparens nyckel, lägga till leverantörens autentiseringsuppgift, vidarebefordra anropet och logga resultatet. Men stöd för olika leverantörsformat innebär mer arbete. Detsamma gäller att hålla det hela igång.

Om du redan kör Envoy kan du med dess filter för extern bearbetning ansluta en tjänst som inspekterar och ändrar förfrågningar och svar. Du måste fortfarande bygga och driva den tjänsten själv.

I en tråd på r/LLMDevs om huruvida en gateway sänker kostnaderna berättade u/QuanTradin att loggning av tokens och en flagga för cacheträffar vid varje anrop hjälpte dem att hitta två jobb som betalade fullt pris för identiska prompter.

”...att åtgärda det var värt mer än något routningslager hade varit.”

Det är en rapporterad erfarenhet, och ett bra ställe att börja på. Ta reda på vad du betalar för innan du bygger avancerade sätt att dirigera det.

Kör en gateway med öppen källkod i egen regi

LiteLLM är ett vanligt val här: OpenAI-kompatibelt, med stöd för ett brett utbud av leverantörer och en stor community. Bifrost är ett alternativ som är byggt för låg overhead per förfrågan. Helicone är värt en titt om observerbarhet står överst på din funktionslista.

LiteLLM har, som alla produkter, begränsningar för vissa team. I en tråd på r/aiagents om alternativ till att bygga en egen berättade u/Own_Bar_920 att LiteLLM klarade routningen bra men inte räckte till för dem när det gällde versionshantering av prompter mellan team och kontinuerliga utvärderingar vid modellbyten, vilket fick dem att gå över till ett separat verktyg.

Det går utöver grundläggande routning i en gateway, och det är just poängen: om routning är huvudbehovet höll LiteLLM måttet för dem.

Du får en färdig funktionslista, där vissa funktioner beror på utgåvan, och behåller gatewayen inom ditt nätverk. Du ansvarar också för säkerhetsuppdateringar, vilket Check Point-avslöjandena ovan gjorde konkret, och för gatewayens tillgänglighet, vilket avsnittet om en gemensam felpunkt visade.

Men budgetera för att någon ska ha ansvaret för den. En farhåga i en tråd på r/LLMDevs om gatewayer för intern åtkomst gällde underhållet. u/Informal-Writer9685 ville ha något som ”inte kräver en dedikerad ingenjör för underhållet” och frågade om LiteLLM:s rapporterade instabilitet vid uppgraderingar var ett verkligt problem i deras skala eller något som bara spelade roll i produktion.

Använd en hanterad gateway

Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter och Portkeys hostade gateway driver tjänsten åt dig. För en kompatibel applikation kan det räcka med en ändrad URL och en API-nyckel för att få igenom den första förfrågan.

Avvägningen här är att varje prompt nu passerar genom en tredje part innan den når leverantören. Det är ytterligare ett personuppgiftsbiträde i din efterlevnadsdokumentation, och ett avbrott i själva gatewayen är leverantörens incident – inte din att åtgärda.

Den 17 och 19 februari 2026 drabbades OpenRouter till exempel av avbrott som varade i 38 respektive 35 minuter efter att ett cacheberoende hade fallerat. Vissa kunder fick felmeddelandet ”User not found” och lade tid på att felsöka helt giltiga API-nycklar. Felet låg i gatewayens infrastruktur.

Men till OpenRouters heder ska sägas att de publicerade en detaljerad incidentanalys och lade till skydd som hindrar ett cachefel från att överbelasta databasen. En hanterad gateway som OpenRouter kan förenkla åtkomsten, men som u/QuanTradin påpekar på r/LLMDevs minskar utgifterna inte automatiskt bara för att fakturorna samlas på ett ställe.

Bygg ut den API-gateway du redan har

Om Kong, Apigee eller Azure API Management redan står framför dina tjänster har var och en AI-specifika funktioner: Kong AI Gateway, Apigees policyer för AI-gateway och AI-gatewayen i Azure API Management. Du kan bygga vidare på den autentisering, de nätverksregler och de driftrutiner du redan har och lägga till modellkontroller via plugin-program eller policyer.

Det här kan vara vägen med minst organisatoriskt motstånd i ett stort företag. AI-funktionerna är yngre än de fristående gatewayernas. Se till att testa tokenbaserad hastighetsbegränsning och strömning genom hela den uppsättning plugin-program eller policyer du planerar att använda.

Installera för all del huvudventilen – den allsmäktiga gatewayen. Ingenjören från inledningen har ändå en poäng. Ett företags tillgång till modeller bör inte bero på vem som råkar ha rätt nyckel i en byrålåda.

En gateway löser det genom att samla nycklarna under central kontroll, vilket gör det desto mer riskabelt att lämna lådan öppen. Du måste veta vems låda det är.

Vanliga frågor om LLM-gatewayer

Är LLM-gatewayen gratis?

Om du menar kategorin finns det LLM-gatewayer med gratisversioner.

LLM-gatewayer finns i allt från gratis programvara med öppen källkod till betalplaner från cirka 50 USD per månad, med anpassad prissättning för företagsdistributioner. Vissa tar i stället ut en procentsats – OpenRouters Standard-plan lägger till exempel på 5,5 % vid köp av krediter.

Vilken LLM-gateway är bäst?

Vilket arbete är du beredd att ta ansvar för?

• Titta på Bifrost eller Helicone om du vill drifta gatewayen själv och ha kontroll över konfigurationen.
• Ett hanterat alternativ som OpenRouter eller Vercel AI Gateway passar team som vill att någon annan driftar tjänsten.
• Om du redan använder Kong eller Azure API Management bör du först se över vilka AI-funktioner de har.

Testa alternativen på din kortlista med dina egna anrop, och kontrollera även vad som händer när en leverantör får avbrott.

Har AWS en LLM-gateway?

Ja. Amazon Bedrock AgentCore Gateway stöder modellanrop via det som AWS kallar ”inference targets”. Med dem kan applikationer använda en enda slutpunkt för att nå leverantörer som Amazon Bedrock, OpenAI och Anthropic, medan gatewayen hanterar leverantörernas autentiseringsuppgifter och routning.