Hvordan fungerer en LLM-gateway? En praktisk veiledning for utviklingsteam

En LLM-gateway ligger mellom applikasjonene dine og modelleverandørene du kobler til gjennom den, og gir deg ett sted å administrere legitimasjon og spore bruken.

«Akkurat nå er det et s**tshow», skrev en ingeniør på Reddit i r/LLMDevs i september 2026.

«Alle har sitt eget sett med nøkler til Claude, OpenAI, AWS Bedrock og alle de andre inferensleverandørene vi bruker.»

BigGos omtale av llm-proxy-tk, en lettvekts FastAPI-gateway, sammenligner oppsettet med å gjøre LLM-er til «bedriftens springvann», med gatewayen som byggets hovedkran.

Men før du setter så stor lit til rørsystemet, la oss se nærmere på hva det er du faktisk installerer.

Hva er en LLM-gateway?

En LLM-gateway er en omvendt proxy for modellkall. Applikasjonene dine sender forespørsler til den i stedet for direkte til OpenAI, Anthropic, Google eller hvilke LLM-leverandører du nå bruker. Gatewayen videresender forespørslene og bruker reglene dine underveis.

Hver LLM-leverandør har sitt eget API, med egen forespørselsstruktur, egen autentisering og sin egen måte å returnere feil på. Hver av dem har også egne hastighetsgrenser og feilmoduser. Uten et felles lag foran dem må hver applikasjon som kaller en leverandør, gjøre alt selv – og gjøre det litt annerledes.

Springvannsanalogien holder bare et stykke på vei, men den holder så langt: Leverandørene kobles til én gang, i gatewayen. Deretter får hver applikasjon sin egen tilkobling med måler, slik at du kan se hvem som bruker hva, og stenge en enkelt ledning uten å røre de andre.

LLM-, AI-, MCP- og API-gatewayer: Hva er forskjellen?

Hvordan fungerer en LLM-gateway?

Følg én forespørsel fra applikasjonen din til modellen og tilbake.

1. Forespørselen kommer til gatewayen: Applikasjonen din sender en helt vanlig chatforespørsel, ofte i et OpenAI-kompatibelt format, til gatewayens endepunkt. Sett fra applikasjonens side er dette adressen den kaller for å nå modellen.
2. Gatewayen sjekker hvem som spør, og hva de har lov til: Før forespørselen videresendes, validerer gatewayen legitimasjonen. Ofte er det en virtuell nøkkel utstedt til et team eller et produkt. Hvis du har koblet inn guardrails for inndata, kan prompter også skannes for sensitive data eller forsøk på å overstyre modellens instruksjoner.
3. Gatewayen sjekker om den allerede har svaret: Hvis hurtigbufring er aktivert, kan en kvalifisert, samsvarende forespørsel besvares fra et lagret svar uten et nytt leverandørkall. Noen gatewayer tilbyr også semantisk hurtigbufring, som ser etter forespørsler som vurderes som tilstrekkelig like, i stedet for identiske. Det kan passe for FAQ-lignende trafikk.
4. Gatewayen velger hvor forespørselen skal: Forespørselen kan angi en bestemt modell eller et alias. Gatewayen slår opp den tilsvarende ruten i konfigurasjonen din. Du kan også konfigurere en reserverute. Hvis leverandør A får tidsavbrudd, kan gatewayen prøve leverandør B.
5. Gatewayen klargjør kallet og returnerer svaret: Gatewayen konverterer forespørselen din til den valgte leverandørens format og autentiserer det utgående kallet. Så snart svaret er mottatt, konverteres det til formatet applikasjonen din krever.
6. Gatewayen registrerer hva som skjedde: Når logging er aktivert, registrerer gatewayen detaljer som hvem som gjorde kallet, hvilken modell som håndterte det, antall tokens, ventetid og kostnad. Dette er loggen Reddit-ingeniøren fra innledningen ikke hadde.

4 ting du må vite før du tar i bruk en gateway i produksjon

Alt i avsnittet ovenfor er mulig fordi gatewayen ser hver forespørsel som rutes gjennom den. Det er salgsargumentet. Men det er også en beskrivelse av angrepsflaten og leverandøravhengigheten du må planlegge for.

Gatewayen er nå den mest verdifulle boksen i AI-stakken din

Gatewayen sentraliserer tilgang. Dermed gir den også én enkelt tjeneste tilgang til mye legitimasjon. Microsofts sikkerhetsteam lister opp hva en LiteLLM-installasjon kan inneholde eller hente: leverandørenes API-nøkler, sin egen hovednøkkel, oppføringer for virtuelle nøkler, tilkoblingsstrenger for databaser, rutingsinnstillinger og leietakerpolicyer.

I oktober 2026 offentliggjorde Check Point Research to høyrisikosårbarheter i LiteLLM:

• CVE-2026-35029 lot autentiserte brukere, inkludert brukere med kun lesetilgang, nå administrative funksjoner og ta over instansen.
• CVE-2026-59823 lot brukere omdirigere forespørsler til en server de kontrollerte, og fange opp leverandørnøkler.

Begge ble rettet i versjon 1.83.9. En applikasjon som bruker gatewayen, skal ikke kunne endre gatewayens innstillinger.

Guardrailene dine trenger en policy for feilsituasjoner

En gjennomgang fra Pillar Security datert 4. oktober 2026 dokumenterer tredjeparts guardrail-integrasjoner på tvers av ledende gatewayer, inkludert LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management og Apigee. (Pillar selger guardrails, så ha det i bakhodet når du leser anbefalingene deres.)

En krok (hook) er et punkt i forespørselsbanen, vanligvis før prompten sendes til modellen eller etter at svaret kommer tilbake, der gatewayen kan overlate innholdet til en ekstern skanner for en vurdering. En blokkerende sjekk venter på vurderingen før trafikken får fortsette. Portkeys dokumentasjon kaller disse before_request_hooks og after_request_hooks; TrueFoundry kjører fire, med ekstra sjekker før og etter MCP-verktøykall.

Det er to ting du bør sjekke:

• Hva skjer hvis selve skanneren svikter? Blokkerer du forespørselen, stopper du ukontrollert trafikk, men kan avbryte applikasjonen din. Slipper du den gjennom, kan applikasjonen fortsette uten den sjekken. Feilloggen viser deg i etterkant at sjekken manglet, noe som er nyttig, men ikke det samme som å ha kjørt den.
• Kan du bytte ut skanneren? Hvis en annen leverandør ikke støttes, kan du bli nødt til å oppdatere applikasjonen din eller bruke en annen proxy for å koble til.

TrueFoundrys MCP-kroker utvider gatewayens rekkevidde fra modellforespørsler til verktøykall. Men den kan bare inspisere trafikk som går gjennom den. En kodeagent som kjører en kommando på en utviklers maskin, kan ligge utenfor dette synsfeltet.

Perplexitys Numbat, som er åpen kildekode, dekker nettopp den siden. Numbat kobler seg til støttede agenter via lokale kroker og kan inspisere planlagte handlinger, som skallkommandoer eller filskrivinger, før de kjøres. Blokkeringsfunksjonen er valgfri og er slått av som standard. Gatewayen ser modelltrafikken som rutes gjennom den. Numbat gir i tillegg innsyn i hva agenten gjør med svaret.

Du må vite hvor gatewayens kontroll slutter

Forkast News identifiserer tre utviklingslinjer som nærmer seg gatewayen fra hver sin kant:

• LLM-fokuserte gatewayer: LiteLLM og Portkey startet med modellkall: oversetting mellom leverandører, ruting av forespørsler og sporing av tokens. Nå legger de til kontroller for verktøykall.
• API-administrasjonsplattformer: Kong, Googles Apigee og Azure API Management startet med autentisering, tillatelser og trafikkstyring, og la deretter til støtte for modeller og AI-spesifikke regler.
• Agentnativ infrastruktur: agentgateway ble for eksempel bygget rundt agenter som kommuniserer med modeller, verktøy og andre agenter, blant annet via MCP og A2A.

Det avgjørende spørsmålet er hva du ruter:

• Bare modellkall? En LLM-orientert gateway er et godt utgangspunkt.
• Modellkall i en virksomhet som allerede er full av API-regler? Start med plattformen du har.
• Agenter som kaller verktøy som kaller modeller? Sjekk at også disse tilkoblingene er dekket.

Du innfører et felles feilpunkt

La oss si at kundestøtte-chatboten din bruker OpenAI og forskningsverktøyet ditt bruker Anthropic – begge kobler seg til via samme gateway. Men hvis gatewayen slutter å fungere, mister begge verktøyene tilgangen til modellene sine, selv om OpenAI og Anthropic fungerer normalt.

Dette har faktisk skjedd. Cloudflares AI Gateway hadde en feilrate på opptil 97 % under driftsavbruddet 12. juni 2025. Gatewayen var avhengig av Cloudflares lagringstjeneste Workers KV for innstillinger, og den tjenesten sviktet.

Hvis du drifter gatewayen selv, bør du ha en ekstra kopi i drift som kan ta over hvis én svikter. Hvis noen andre hoster gatewayen din, bør du spørre hvordan de holder den i gang ved feil, og hva som skjer med forespørslene dine under gjenopprettingen.

Nøkkelfunksjonene du bør se etter i LLM-gatewayer

Du skal gi gatewayen tilgang til alles legitimasjon, så du bør stille høye krav til hva den gir deg tilbake.

• Ett API foran flere leverandører: Koden din bruker ett format, ofte et OpenAI-kompatibelt, og gatewayen oversetter. LLM-leverandørene møter den på halvveien. Perplexitys Agent API støtter for eksempel grensesnittet til OpenAIs Responses API, slik at team kan gjenbruke eksisterende OpenAI-klientbiblioteker.
• Virtuelle nøkler med tilknyttede regler: Hvert team eller produkt får sin egen nøkkel, med regler for tillatte modeller, forespørselsgrenser og forbruk.
• Ruting og reserveløsning: Gatewayen sender forespørsler til modeller basert på innstillingene dine, som kan prioritere kostnad, hastighet eller en bestemt leverandør. Hvis et kall mislykkes, kan den prøve en annen. Med Perplexitys Agent API kan du angi opptil fem modeller, også fra ulike leverandører, i ønsket rekkefølge.
• Hurtigbufring: Et lagret svar kan spare deg for et nytt leverandørkall. Noen gatewayer matcher identiske forespørsler; andre kan også matche forespørsler med lignende betydning. Sjekk om bufrede svar kan holdes adskilt per bruker eller team, og om du kan slå av hurtigbufring for personlige eller tidssensitive svar.
• Strømming og konsistente feilmeldinger: Svarene kommer etter hvert som de genereres, og leverandørfeil oversettes til et format applikasjonen din kan håndtere. Sjekk hva som skjer når du legger til AI-guardrails.
• Logging og kostnadsfordeling: Gatewayen registrerer hvem som gjorde et kall, hvilken modell som håndterte det, hvor mange tokens det brukte, hvor lang tid det tok, og estimert kostnad. Sjekk om loggene inneholder prompter og svar, og hvor lenge de lagres.
• Guardrail-kroker: Dette er punkter i forespørselsbanen der gatewayen kan sende innhold til en ekstern skanner for en vurdering. De sitter vanligvis før en modellforespørsel eller etter svaret. Sjekk om forespørsler stopper eller fortsetter når skanneren svikter, og om du kan koble til en annen skanner.
• Et administrasjonsgrensesnitt du kan låse ned: Gatewayen styrer tilgangen til leverandørlegitimasjon og reglene alle bruker. Sjekk at du kan begrense administratortilgang separat fra applikasjonstrafikk, og at brukere med kun lesetilgang ikke kan endre innstillinger. Hovedkranen trenger en lås.

Hvilke verktøy kan du bruke til å bygge LLM-gatewayen din?

Funksjonslistene overlapper på tvers av markedet. I en Reddit-tråd om intern modelltilgang spurte trådstarteren: Hvilken gateway krever ikke en dedikert ingeniør?

Det er etter vår mening det riktige spørsmålet, og det har fire svar, avhengig av hvor mye av arbeidet du er villig til å ta ansvar for selv.

Skriv den selv

En minimal gateway håndterer en kort liste med oppgaver – ta imot forespørsler, sjekke avsenderens nøkkel, legge til leverandørlegitimasjonen, videresende kallet og logge resultatet. Men støtte for ulike leverandørformater gir mer arbeid. Det samme gjør det å holde det hele i drift.

Hvis du allerede kjører Envoy, lar Envoys filter for ekstern prosessering deg koble til en tjeneste som inspiserer og endrer forespørsler og svar. Du må fortsatt bygge og drifte den tjenesten selv.

I en r/LLMDevs-tråd om hvorvidt en gateway reduserer kostnader fortalte u/QuanTradin at logging av tokens og et cache-treff-flagg på hvert kall hjalp dem med å finne to jobber som betalte full pris for identiske prompter.

«...det var mer verdt å fikse det enn noe rutinglag ville ha vært.»

Det er en rapportert erfaring, og et godt sted å begynne. Finn ut hva du betaler for, før du bygger avanserte måter å rute det på.

Host en gateway med åpen kildekode selv

LiteLLM er et vanlig valg her: OpenAI-kompatibel, støtter et bredt utvalg av leverandører og har et stort fellesskap. Bifrost er et alternativ, bygget for lav overhead per forespørsel. Helicone er verdt en titt hvis observerbarhet står øverst på funksjonslisten din.

LiteLLM har, som ethvert produkt, begrensninger for enkelte team. I en r/aiagents-tråd om alternativer til å bygge selv fortalte u/Own_Bar_920 at LiteLLM håndterte ruting fint, men kom til kort for dem når det gjaldt promptversjonering på tvers av team og kontinuerlige evalueringer ved bytte av modeller, noe som fikk dem til å ta i bruk et eget verktøy.

Det går utover grunnleggende gateway-ruting, og det er nettopp poenget – hvis ruting er hovedbehovet, holdt LiteLLM mål for dem.

Du får en ferdig funksjonsliste, der noen funksjoner avhenger av utgaven, og beholder gatewayen innenfor ditt eget nettverk. Du har også ansvaret for sikkerhetsoppdateringer, noe Check Point-avsløringene tidligere gjorde konkret, og for gatewayens tilgjengelighet, noe avsnittet om felles feilpunkt illustrerte.

Men sett av ressurser til at noen har ansvaret for den. En bekymring i en r/LLMDevs-tråd om gatewayer for intern tilgang var vedlikehold. u/Informal-Writer9685 ønsket noe som «ikke krever en dedikert ingeniør for å vedlikeholdes», og spurte om LiteLLMs rapporterte ustabilitet ved oppgraderinger var et reelt problem i deres skala eller bare et problem i produksjon.

Bruk en administrert gateway

Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter og Portkeys hostede gateway drifter tjenesten for deg. For en kompatibel applikasjon kan det å få den første forespørselen gjennom kreve lite mer enn en endret URL og en API-nøkkel.

Avveiningen er at hver prompt nå går via en tredjepart før den når leverandøren. Det er én databehandler til i samsvarsdokumentasjonen din, og nedetid i selve gatewayen er leverandørens hendelse – den er ikke din å fikse.

For eksempel hadde OpenRouter nedetid på henholdsvis 38 og 35 minutter 17. og 19. februar 2026, etter at en hurtigbufferavhengighet sviktet. Noen kunder fikk feilmeldingen «User not found» og brukte tid på å feilsøke helt gyldige API-nøkler. Feilen lå i gatewayens infrastruktur.

Men OpenRouter skal ha ros for å ha publisert en detaljert etteranalyse og lagt til beskyttelse som hindrer at en hurtigbufferfeil overbelaster databasen. En administrert gateway som OpenRouter kan forenkle tilgangen, men som u/QuanTradin påpeker på r/LLMDevs, betyr ikke en samlet faktura automatisk lavere forbruk.

Utvid API-gatewayen du allerede har

Hvis Kong, Apigee eller Azure API Management allerede står foran tjenestene dine, har hver av dem AI-spesifikke funksjoner: Kong AI Gateway, Apigees AI-gateway-policyer og Azure API Managements AI-gateway. Du kan bygge videre på autentiseringen, nettverksreglene og driftsrutinene du allerede har, og legge til modellkontroller via plugins eller policyer.

Dette kan være veien med minst organisatorisk motstand i en stor virksomhet. AI-funksjonene er nyere enn de frittstående gatewayenes. Sørg for å teste tokenbasert hastighetsbegrensning og strømming gjennom hele settet med plugins eller policyer du planlegger å bruke.

Så installer for all del hovedkranen – den allmektige gatewayen. Ingeniøren fra innledningen har likevel et poeng. Et selskaps tilgang til modeller bør ikke avhenge av hvem som tilfeldigvis har riktig nøkkel liggende i en skuff.

En gateway løser dette ved å samle nøklene under sentral kontroll, noe som gjør det desto mer risikabelt å la skuffen stå åpen. Du må vite hvem skuffen tilhører.

Vanlige spørsmål om LLM-gatewayer

Er LLM-gatewayen gratis?

Hvis du mener kategorien, finnes det LLM-gatewayer med gratisversjoner.

LLM-gatewayer spenner fra gratis programvare med åpen kildekode til betalte abonnementer fra rundt 50 dollar i måneden, med tilpassede priser for bedriftsinstallasjoner. Noen tar i stedet en prosentandel; OpenRouters Standard-abonnement legger for eksempel 5,5 % på kjøp av kreditter.

Hvilken LLM-gateway er best?

Hvilket arbeid er du villig til å ta ansvar for selv?

• Ta en titt på Bifrost eller Helicone hvis du vil drifte løsningen selv og ha kontroll over konfigurasjonen.
• Et administrert alternativ som OpenRouter eller Vercel AI Gateway passer for team som vil at noen andre skal drifte tjenesten.
• Hvis du allerede bruker Kong eller Azure API Management, bør du først sjekke hvilke AI-funksjoner de tilbyr.

Test kandidatene på kortlisten med dine egne forespørsler, inkludert hva som skjer når en leverandør svikter.

Har AWS en LLM-gateway?

Ja. Amazon Bedrock AgentCore Gateway støtter modellkall gjennom det AWS kaller «inference targets» (inferensmål). Disse lar applikasjoner bruke ett enkelt endepunkt for å nå leverandører som Amazon Bedrock, OpenAI og Anthropic, mens gatewayen håndterer leverandørlegitimasjon og ruting.