Hvordan fungerer en LLM-gateway? En praktisk guide til udviklingsteams

En LLM-gateway sidder mellem dine applikationer og de modeludbydere, du forbinder via den, så du har ét sted at administrere legitimationsoplysninger og spore forbrug.

”Lige nu er det et s**t show,” lød det fra en ingeniør, der skrev på Reddit i r/LLMDevs i september 2026.

”Alle har deres egne nøgler til Claude, OpenAI, AWS Bedrock og alle de andre inferensudbydere, vi bruger.”

BigGos dækning af llm-proxy-tk, en letvægtsgateway bygget på FastAPI, sammenligner opsætningen med at gøre LLM'er til ”virksomhedens postevand” med gatewayen som bygningens hovedhane.

Men før du sætter så stor lid til rørføringen, så lad os se nærmere på, hvad det er, du installerer.

Hvad er en LLM-gateway?

En LLM-gateway er en reverse proxy til modelkald. Dine applikationer sender anmodninger til den i stedet for direkte til OpenAI, Anthropic, Google eller de LLM-udbydere, du nu bruger. Gatewayen videresender anmodningerne og anvender dine regler undervejs.

Hver LLM-udbyder har sit eget API med sin egen anmodningsstruktur, sin egen godkendelse og sin egen måde at returnere fejl på. Hver udbyder har også sine egne hastighedsbegrænsninger og fejltilstande. Hvis der ikke er et fælles lag foran dem, klarer hver applikation, der kalder en udbyder, det hele selv – hver på sin lidt anderledes måde.

Sammenligningen med postevand holder kun et stykke vej, men den holder så langt: Udbyderne kobles kun på én gang, nemlig i gatewayen. Derefter får hver applikation sin egen forbindelse med måler, så du kan se, hvem der bruger hvad, og lukke for en enkelt ledning uden at røre de andre.

LLM-, AI-, MCP- og API-gateways: Hvad er forskellen?

Hvordan fungerer en LLM-gateway?

Følg en enkelt anmodning fra din applikation til modellen og tilbage igen.

1. Anmodningen ankommer til gatewayen: Din applikation sender en chatanmodning, der ser helt almindelig ud, ofte i et OpenAI-kompatibelt format, til gatewayens endpoint. Set fra applikationens side er det den adresse, den kalder for at nå modellen.
2. Gatewayen tjekker, hvem der spørger, og hvad de har lov til: Før anmodningen videresendes, validerer den legitimationsoplysningerne. Ofte er det en virtuel nøgle, der er udstedt til et team eller et produkt. Hvis du har koblet input-guardrails på, kan prompts også scannes for følsomme data eller forsøg på at tilsidesætte modellens instruktioner.
3. Gatewayen tjekker, om den allerede har svaret: Hvis caching er aktiveret, kan en matchende anmodning, der opfylder betingelserne, besvares ud fra et gemt svar uden endnu et kald til udbyderen. Nogle gateways tilbyder også semantisk caching, som leder efter anmodninger, der vurderes at være tilstrækkeligt ens frem for identiske. Det kan passe godt til FAQ-agtig trafik.
4. Gatewayen vælger, hvor anmodningen skal hen: Anmodningen kan angive en bestemt model eller et alias. Gatewayen slår den tilsvarende rute op i din konfiguration. Du kan også konfigurere en reserverute. Hvis udbyder A får timeout, kan gatewayen prøve udbyder B.
5. Gatewayen forbereder kaldet og returnerer svaret: En gateway konverterer din anmodning til den valgte udbyders format og godkender det udgående kald. Så snart svaret er modtaget, konverteres det til det format, din applikation kræver.
6. Gatewayen registrerer, hvad der skete: Når logning er aktiveret, registrerer gatewayen blandt andet, hvem der foretog kaldet, hvilken model der besvarede det, antal tokens, latenstid og omkostninger. Det er netop den log, Reddit-ingeniøren fra indledningen ikke havde.

De 4 ting, du skal vide, før du sætter en gateway i produktion

Alt i afsnittet ovenfor er muligt, fordi gatewayen ser hver eneste anmodning, der sendes gennem den. Det er salgsargumentet. Men det er også en beskrivelse af den angrebsflade og den leverandørafhængighed, du skal planlægge efter.

Gatewayen er nu den mest værdifulde boks i din AI-stak

Gatewayen centraliserer adgangen. Og derfor placerer den også mange legitimationsoplysninger inden for rækkevidde af én enkelt tjeneste. Microsofts sikkerhedsteam oplister, hvad en LiteLLM-udrulning kan indeholde eller hente: udbydernes API-nøgler, dens egen hovednøgle, poster for virtuelle nøgler, forbindelsesstrenge til databaser, routingindstillinger og lejerpolitikker.

I oktober 2026 offentliggjorde Check Point Research to højrisikosårbarheder i LiteLLM:

• CVE-2026-35029 gav godkendte brugere, også brugere med skrivebeskyttet adgang, mulighed for at nå administrative funktioner og overtage instansen.
• CVE-2026-59823 gav brugere mulighed for at omdirigere anmodninger til en server, de selv kontrollerede, og opsnappe udbydernøgler.

Begge blev rettet i version 1.83.9. En applikation, der bruger gatewayen, bør ikke kunne ændre dens indstillinger.

Dine guardrails har brug for en fejlpolitik

En gennemgang fra Pillar Security den 4. oktober 2026 dokumenterer tredjepartsintegrationer af guardrails på tværs af de store gateways, herunder LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management og Apigee. (Pillar sælger selv guardrails, så husk det, når du læser deres anbefalinger.)

En hook er et punkt i anmodningsforløbet, typisk før prompten sendes til modellen eller efter svaret kommer tilbage, hvor gatewayen kan give indholdet videre til en ekstern scanner og få en vurdering. Et blokerende tjek venter på den vurdering, før trafikken får lov at fortsætte. Portkeys dokumentation kalder dem before_request_hooks og after_request_hooks; TrueFoundry kører fire og tilføjer tjek før og efter MCP-værktøjskald.

Der er så to ting, du skal tjekke:

• Hvad sker der, hvis selve scanneren fejler? Hvis du blokerer en anmodning, stopper du ukontrolleret trafik, men risikerer at afbryde din applikation. Lader du den gå igennem, kan din applikation fortsætte uden det tjek. Fejlloggen viser dig bagefter, at tjekket manglede, hvilket er nyttigt, men ikke det samme som at have kørt det.
• Kan du udskifte scanneren? Hvis en anden udbyder ikke understøttes, kan du blive nødt til at opdatere din applikation eller bruge en anden proxy for at oprette forbindelse.

TrueFoundrys MCP-hooks udvider gatewayens rækkevidde fra modelanmodninger til værktøjskald. Men den kan kun inspicere trafik, der går gennem den. En kodningsagent, der kører en kommando på en udviklers maskine, kan ligge uden for det synsfelt.

Perplexitys open source-værktøj Numbat arbejder på den side. Numbat forbinder til understøttede agenter via lokale hooks og kan inspicere planlagte handlinger, såsom shell-kommandoer eller filskrivninger, før de udføres. Blokeringsfunktionen er valgfri og er som standard slået fra. Gatewayen ser den modeltrafik, der sendes gennem den. Numbat giver indsigt i, hvad agenten gør med svaret.

Du skal vide, hvor gatewayens kontrol slutter

Forkast News identificerer tre udviklingslinjer, der nærmer sig gatewayen fra forskellige retninger:

• LLM-fokuserede gateways: LiteLLM og Portkey startede med modelkald: oversættelse mellem udbydere, routing af anmodninger og sporing af tokens. Nu tilføjer de kontroller for værktøjskald.
• API-administrationsplatforme: Kong, Googles Apigee og Azure API Management startede med godkendelse, tilladelser og trafikstyring og tilføjede derefter understøttelse af modeller og AI-specifikke regler.
• Agent-native infrastruktur: agentgateway blev for eksempel bygget op omkring agenter, der kommunikerer med modeller, værktøjer og andre agenter, blandt andet via MCP og A2A.

Det afgørende spørgsmål er, hvad du router:

• Kun modelkald? En gateway, der er bygget til LLM'er fra starten, er et godt udgangspunkt.
• Modelkald i en virksomhed, der allerede er fuld af API-regler? Start med den platform, du har.
• Agenter, der kalder værktøjer, der kalder modeller? Tjek, at de forbindelser også er dækket.

Du introducerer et fælles fejlpunkt

Lad os sige, at din supportchatbot bruger OpenAI, og at dit researchværktøj bruger Anthropic – begge forbinder via den samme gateway. Men hvis gatewayen holder op med at virke, mister begge værktøjer adgangen til deres modeller, selvom OpenAI og Anthropic kører helt normalt.

Det er rent faktisk sket. Cloudflares AI Gateway toppede med en fejlrate på 97 % under nedbruddet den 12. juni 2025. Gatewayen var afhængig af Cloudflares lagringstjeneste Workers KV til sine indstillinger, og den tjeneste fejlede.

Hvis du selv driver gatewayen, så hold en ekstra kopi kørende, der kan tage over, hvis den ene fejler. Hvis en anden hoster din gateway, så spørg, hvordan de holder den kørende under fejl, og hvad der sker med dine anmodninger under gendannelsen.

De vigtigste funktioner, du skal kigge efter i LLM-gateways

Du giver gatewayen adgang til alles legitimationsoplysninger, så du bør stille store krav til, hvad den giver til gengæld.

• Ét API foran flere udbydere: Din kode taler ét format, ofte et OpenAI-kompatibelt, og gatewayen oversætter. LLM-udbyderne møder den på halvvejen. Perplexitys Agent API understøtter for eksempel OpenAIs Responses API-grænseflade, så teams kan genbruge eksisterende OpenAI-klientbiblioteker.
• Virtuelle nøgler med tilknyttede regler: Hvert team eller produkt får sin egen nøgle med regler for tilladte modeller, anmodningsgrænser og forbrug.
• Routing og fallback: Gatewayen sender anmodninger til modeller ud fra dine indstillinger, som kan prioritere pris, hastighed eller en bestemt udbyder. Hvis et kald fejler, kan den prøve et andet. Med Perplexitys Agent API kan du angive op til fem modeller, også fra forskellige udbydere, i den rækkefølge, du foretrækker.
• Caching: Et gemt svar kan spare dig for endnu et kald til udbyderen. Nogle gateways matcher identiske anmodninger; andre kan også matche anmodninger med lignende betydning. Tjek, om cachelagrede svar kan adskilles efter bruger eller team, og om du kan slå caching fra for personlige eller tidsfølsomme svar.
• Streaming og ensartede fejl: Svarene ankommer, efterhånden som de genereres, og udbyderfejl oversættes til et format, din applikation kan håndtere. Tjek, hvad der sker, når du tilføjer AI-guardrails.
• Logning og omkostningsfordeling: Gatewayen registrerer, hvem der foretog et kald, hvilken model der besvarede det, hvor mange tokens der blev brugt, hvor lang tid det tog, og de anslåede omkostninger. Tjek, om logfilerne indeholder prompts og svar, og hvor længe de opbevares.
• Guardrail-hooks: Det er punkter i anmodningsforløbet, hvor gatewayen kan sende indhold til en ekstern scanner for at få en vurdering. De sidder typisk før en modelanmodning eller efter dens svar. Tjek, om anmodninger stoppes eller fortsætter, når scanneren fejler, og om du kan tilslutte en anden scanner.
• En administrationsgrænseflade, du kan låse ned: Gatewayen styrer adgangen til udbydernes legitimationsoplysninger og de regler, alle bruger. Tjek, at du kan begrænse administratoradgang separat fra applikationstrafik, og at brugere med skrivebeskyttet adgang ikke kan ændre indstillinger. Hovedhanen skal have en lås.

Hvilke værktøjer kan du bruge til at bygge din LLM-gateway?

Funktionslisterne overlapper på tværs af markedet. I en Reddit-tråd om intern adgang til modeller spurgte trådstarteren: Hvilken gateway kræver ikke en dedikeret ingeniør?

Efter vores mening er det det rigtige spørgsmål, og der er fire svar på det, afhængigt af hvor meget af arbejdet du er villig til selv at stå for.

Skriv den selv

En minimal gateway klarer en kort liste af opgaver – modtage anmodninger, tjekke kalderens nøgle, tilføje udbyderens legitimationsoplysninger, videresende kaldet og logge resultatet. Men understøttelse af forskellige udbyderformater giver ekstra arbejde. Det samme gør det at holde det hele kørende.

Hvis du allerede kører Envoy, kan du med dets external processing-filter tilslutte en tjeneste, der inspicerer og ændrer anmodninger og svar. Du skal dog stadig selv bygge og drive den tjeneste.

I en r/LLMDevs-tråd om, hvorvidt en gateway sænker omkostningerne, fortalte u/QuanTradin, at det at logge tokens og et cache-hit-flag ved hvert kald hjalp dem med at finde to job, der betalte fuld pris for identiske prompts.

”...det var mere værd at rette det, end noget routinglag ville have været.”

Det er én brugers beretning, men et godt sted at starte. Find ud af, hvad du betaler for, før du bygger avancerede måder at route det på.

Selvhost en open source-gateway

LiteLLM er et populært valg her: Den er OpenAI-kompatibel, understøtter en lang række udbydere og har et stort fællesskab. Bifrost er et alternativ, bygget til lavt overhead pr. anmodning. Helicone er værd at kigge på, hvis observerbarhed står øverst på din funktionsliste.

Som ethvert produkt har LiteLLM sine begrænsninger for nogle teams. I en r/aiagents-tråd om alternativer til at bygge selv fortalte u/Own_Bar_920, at LiteLLM klarede routing fint, men kom til kort for dem med hensyn til promptversionering på tværs af teams og løbende evalueringer ved skift af modeller, hvilket fik dem til at tage et separat værktøj i brug.

Det rækker ud over basal gateway-routing, og det er netop pointen – når routing er hovedbehovet, holdt LiteLLM for dem.

Du får en færdig funktionsliste, hvor nogle funktioner afhænger af udgaven, og beholder gatewayen inden for dit eget netværk. Du står også selv for patching, hvilket Check Points offentliggørelser tidligere gjorde konkret, og for gatewayens tilgængelighed, hvilket afsnittet om det fælles fejlpunkt gjorde.

Men sæt ressourcer af til, at nogen har ansvaret for den. En af bekymringerne i en r/LLMDevs-tråd om gateways til intern adgang var vedligeholdelse. u/Informal-Writer9685 ønskede noget, der ”ikke kræver en dedikeret ingeniør at vedligeholde”, og spurgte, om den rapporterede ustabilitet ved opgraderinger af LiteLLM var et reelt problem i deres skala eller kun et problem i produktion.

Brug en administreret gateway

Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter og Portkeys hostede gateway driver tjenesten for dig. For en kompatibel applikation kræver det måske ikke meget mere end en ændret URL og en API-nøgle at få den første anmodning igennem.

Ulempen er, at hver prompt nu går gennem en tredjepart, før den når udbyderen. Det er endnu en databehandler i din compliance-dokumentation, og et nedbrud i selve gatewayen er en leverandørs hændelse – det er ikke dig, der kan løse det.

Den 17. og 19. februar 2026 havde OpenRouter for eksempel nedbrud på henholdsvis 38 og 35 minutter, efter at en caching-afhængighed fejlede. Nogle kunder fik fejlen ”User not found” og brugte tid på at fejlfinde helt gyldige API-nøgler. Fejlen lå i gatewayens infrastruktur.

Men det skal siges til OpenRouters ros, at de offentliggjorde en detaljeret postmortem og tilføjede beskyttelser, der skal forhindre en cachefejl i at overbelaste deres database. En administreret gateway som OpenRouter kan forenkle adgangen, men som u/QuanTradin påpeger på r/LLMDevs, sænker en samlet regning ikke automatisk forbruget.

Udvid den API-gateway, du allerede har

Hvis Kong, Apigee eller Azure API Management allerede står foran dine tjenester, har de hver især AI-specifikke funktioner: Kong AI Gateway, Apigees AI-gatewaypolitikker og Azure API Managements AI-gateway. Du kan bygge videre på den godkendelse, de netværksregler og de driftsprocedurer, du allerede har, og tilføje modelkontroller via plugins eller politikker.

I en stor virksomhed kan det være vejen med mindst organisatorisk modstand. AI-funktionerne er dog nyere end funktionerne i de selvstændige gateways. Sørg for at teste tokenbaseret hastighedsbegrænsning og streaming gennem hele det sæt af plugins eller politikker, du planlægger at bruge.

Så installér endelig hovedventilen – den almægtige gateway. Ingeniøren fra indledningen har dog en pointe. En virksomheds adgang til modeller bør ikke afhænge af, hvem der tilfældigvis har den rigtige nøgle liggende i en skuffe.

En gateway løser det ved at samle nøglerne under central kontrol, hvilket unægtelig gør det mere risikabelt at lade skuffen stå åben. Du er nødt til at vide, hvis skuffe det er.

Ofte stillede spørgsmål om LLM-gateways

Er LLM-gatewayen gratis?

Hvis du mener kategorien, findes der LLM-gateways med gratis versioner.

LLM-gateways spænder fra gratis open source-software til betalingsabonnementer fra omkring 50 dollar om måneden og individuelle priser for virksomhedsimplementeringer. Og nogle tager i stedet en procentdel; eksempelvis lægger OpenRouters Standard-abonnement 5,5 % oven i køb af kreditter.

Hvilken LLM-gateway er den bedste?

Hvilket arbejde er du villig til selv at påtage dig?

• Kig på Bifrost eller Helicone, hvis du vil selvhoste og selv styre konfigurationen.
• En administreret løsning som OpenRouter eller Vercel AI Gateway passer til teams, der hellere vil lade andre drive tjenesten.
• Hvis du allerede bruger Kong eller Azure API Management, bør du først undersøge deres AI-funktioner.

Test løsningerne på din shortliste med dine egne forespørgsler – herunder hvad der sker, når en udbyder fejler.

Har AWS en LLM-gateway?

Ja. Amazon Bedrock AgentCore Gateway understøtter modelkald via det, AWS kalder »inference targets«. De gør det muligt for applikationer at bruge ét endpoint til at nå udbydere som Amazon Bedrock, OpenAI og Anthropic, mens gatewayen håndterer udbydernes legitimationsoplysninger og routing.