AI GATEWAY · FORKLARET

Hvad er en AI gateway?

En AI gateway er ét fælles indgangspunkt mellem jeres applikationer og de AI-modeller, de bruger — OpenAI, Anthropic, Mistral eller modeller, I selv driver. I stedet for at hver applikation har sine egne nøgler og træffer sine egne beslutninger, går hver forespørgsel gennem ét sted, hvor adgang, omkostninger, dataregler og registreringen af, hvad der skete, håndteres én gang for alle.

FØR OG EFTER

De samme tre applikationer, to gange

Uden en gateway

  • Hver applikation har sine egne udbydernøgler — og hver af dem er et sted, hvor en nøgle kan lække.
  • Hvert team bygger sine egne gentagelsesforsøg, grænser og logning, hver gang en smule forskelligt.
  • Forbruget kommer som én faktura pr. udbyder, uden en linje for det team eller den funktion, der forårsagede det.
  • At tilføje eller skifte udbyder betyder kodeændringer i hver eneste applikation.

Med en gateway

  • Udbydernøglerne ligger ét sted. Applikationerne får deres egne gateway-nøgler, som kan inddrages uden at røre udbyderen.
  • Gentagelsesforsøg, failover og caching sker én gang, på samme måde, for alle applikationer.
  • Hver forespørgsel henføres til et team, en applikation og en bruger, mens den sker.
  • Modeller tilføjes eller skiftes i konfigurationen. Applikationskoden ændres ikke.
HVAD DEN GØR

Fem ting sker med hver forespørgsel

Detaljerne varierer mellem produkter, men formen er den samme: først kontrollerne, så modelkaldet i midten og til sidst registreringen. En forespørgsel, der falder på en kontrol, stopper, før nogen bliver opkrævet for den.

  1. Tjek, hvem der spørger. Applikationen viser sin egen gateway-nøgle eller en brugers virksomhedslogin. Ukendte afsendere afvises. ✗ afvist
  2. Tjek grænserne. Er holdet inden for sit budget og sin rate limit? Hvis ikke, stopper forespørgslen her — før udbyderen overhovedet kontaktes. ✗ over budget
  3. Anvend reglerne. Regler for hele organisationen kører på prompten — for eksempel at maskere personoplysninger eller forhindre, at de forlader huset til en ekstern udbyder. ✗ blokeret · ◑ maskeret
  4. Vælg en model og kald den. Gatewayen vælger, hvilken udbyder og model der betjener forespørgslen, og går videre til den næste, hvis en udbyder er langsom eller nede.
  5. Registrér, hvad der skete. Hvem der spurgte, hvilken model der svarede, hvad det kostede, og hvilke regler der blev anvendt — skrevet ned for hver forespørgsel, ikke rekonstrueret bagefter.

Dette er den forenklede version. Wägs fulde forespørgselsvej har ni trin, blandt andet caching og værktøjspolitik på agenters værktøjskald: se forespørgselsvejen, trin for trin.

HVORFOR TEAMS INDFØRER EN

Det starter som regel med en af disse

Ingen køber en gateway, fordi kategorien findes. De køber en, fordi noget på denne liste er sket.

Det, I opdagerDet, en gateway gør ved detLæs mere
AI-regningen blev fordoblet, og ingen kan sige, hvilket team der forårsagede det.Henfører omkostningen ved hver forespørgsel til et team, en applikation og en bruger og stopper forbruget ved en grænse, I selv sætter.Omkostninger og budgetter
Udbydernøgler er indsat i et dusin konfigurationsfiler og CI-secrets.Opbevarer udbydernøgler ét sted. Applikationerne får gateway-nøgler, som I kan afgrænse, rotere og inddrage.Sikkerhedsniveau
Et udbyderudfald tog en kundevendt funktion med sig.Forsøger igen og skifter automatisk over til en anden udbyder eller model.Routing og failover
Nogen spurgte, om kundedata sendes til en ekstern model, og ingen vidste det.Anvender dataregler på hver prompt — maskér, redigér eller blokér — før den forlader huset.Policy og guardrails
Hvert team valgte sin egen model, og de fleste vælger som standard den dyreste.Router hver forespørgsel til den billigste model, der kan klare den, efter policy frem for efter vane.Intelligent routing
En revisor, en kunde eller EU's AI-forordning spørger, hvad jeres AI-systemer faktisk har gjort.Fører en registrering af hver forespørgsel: hvem der spurgte, hvilken model der svarede, hvad det kostede, og hvilke regler der blev anvendt.AI-forordningen og logning
Agenter kalder nu værktøjer og interne systemer med rigtige credentials.Sender agenters værktøjskald gennem samme identitet, policy og registrering som modelkald. Ikke alle gateways gør det — spørg.Agentstyring
HVAD ÆNDRES I JERES KODE

Som regel én linje

De fleste gateways taler OpenAI-API'et, som næsten alle AI-SDK'er og frameworks allerede understøtter. At tage en i brug betyder at ændre den adresse, jeres applikation sender forespørgsler til, og den nøgle, den sender med.

  client = OpenAI(
-     base_url="https://api.openai.com/v1",
-     api_key=os.environ["OPENAI_API_KEY"],
+     base_url="https://ai-gateway.internal/v1",
+     api_key=os.environ["GATEWAY_KEY"],
  )

Prompts, SDK og håndtering af svar forbliver, som de er. En god gateway oversætter også for udbydere med et andet API, såsom Anthropic eller Gemini, så applikationen aldrig behøver vide, hvilken udbyder der svarede.

HOSTET ELLER SELVHOSTET

Det valg, de fleste ikke ved, at de træffer

En gateway ser hver prompt og hvert svar, der passerer gennem den. Så det første spørgsmål er ikke, hvilke funktioner den har, men hvis infrastruktur den kører på.

SpørgsmålHostet — en leverandør driver denSelvhostet — I driver den
Hvor prompts og svar tager henGennem leverandørens netværk og systemer på vej til udbyderenIngen nye steder — de bliver i jeres infrastruktur, indtil de når den udbyder, I valgte
Hvem der har jeres udbydernøglerLeverandørenI
Tid til den første forespørgselMinutter — opret en konto og skift base-URL'enLængere — I skal først deploye den
Hvem holder den kørendeLeverandørenJeres team, som regel platformsteamet
Det rigtige valg, nårHastighed betyder mest, og dataene ikke er følsommeDatabeskyttelse, regulering eller indkøbsregler udelukker en tredjepart i forespørgselsvejen
HAR I BRUG FOR EN

Ikke altid

Sandsynligvis ikke endnu, hvis…

I har én applikation, én udbyder og ét team, og ingen uden for udviklingen spørger til AI-forbrug eller data. Så er det enklere at kalde udbyderen direkte, og enkelhed er en fordel. Vend tilbage, når det ændrer sig.

Begynd at se jer om, når en af disse ting sker:

  • Et andet team eller en anden udbyder kommer til.
  • Nogen spørger, hvad AI koster pr. team eller pr. produkt, og svaret tager en uge.
  • Databeskyttelse eller sikkerhed spørger, hvor prompts tager hen.
  • Et udfald hos én udbyder bliver til jeres udfald.
  • Agenter begynder at handle i jeres systemer med rigtige credentials.
UDOVER GATEWAYEN

Når en gateway ikke er nok

En gateway styrer de applikationer, der vælger at pege på den. Når AI bliver fælles infrastruktur — mange teams, agenter med reel beføjelse, revisorer der stiller spørgsmål — ændrer spørgsmålet sig fra, hvordan forespørgsler videresendes, til hvem der afgør, hvad en forespørgsel må, for hele organisationen. Det er skellet mellem en AI gateway og en AI control plane.

HVOR WÄG PASSER IND

En AI gateway, I selv driver

Wäg er en open source AI gateway, der kører helt i jeres egen infrastruktur: ingen hostet version, ingen leverandør i forespørgselsvejen, ingen phone-home. Den taler OpenAI-API'et, forbinder til 25+ OpenAI-kompatible udbydere samt native Anthropic og Gemini og tilføjer control plane-laget — identitet, hierarkiske budgetter, policy, agentstyring og audit — i den samme forespørgselsvej. Apache-2.0, skrevet i Rust.

Kører I allerede LiteLLM eller en anden gateway? Wäg importerer LiteLLM-konfiguration, og migrationsguiden gennemgår, hvordan I kører begge side om side, før I skifter.

SPØRGSMÅL

Det, folk spørger om først

Er en AI gateway det samme som en LLM-proxy?

For det meste. LLM-proxy, AI-proxy, LLM gateway og AI gateway beskriver alle ét endpoint foran flere modeludbydere. Gateway antyder som regel mere end videresendelse — nøgler, grænser, regler og en registrering — men begreberne bruges ikke ensartet, så undersøg, hvad et produkt rent faktisk håndhæver, frem for hvad det kaldes.

Hvordan adskiller den sig fra en API-gateway?

En API-gateway styrer forespørgsler: routing, autentificering og rate limits pr. kald. En AI gateway forstår også, hvad der er inde i en modelforespørgsel — tokens, prisen pr. model, streamede svar, prompts der kan indeholde personoplysninger, og udbydere der kan træde i stedet for hinanden. Nogle API-gateways tilføjer nu AI-funktioner; det brugbare spørgsmål er, om de tæller tokens og omkostninger eller kun forespørgsler.

Skal jeg ændre min applikationskode?

Som regel kun base-URL'en og nøglen, forudsat at gatewayen taler OpenAI-API'et, og at jeres applikation bruger en OpenAI-kompatibel SDK eller et framework — hvilket de fleste gør.

Gør den forespørgsler langsommere?

Den tilføjer et netværkshop og dermed lidt tid. En veludviklet gateway lægger millisekunder til, mens modelsvar tager flere hundrede millisekunder op til flere sekunder, og et cache-hit kan gøre en forespørgsel meget hurtigere end at kalde udbyderen overhovedet. Bed enhver leverandør om overhead målt med logning og budgetter slået til, ikke fra.

Er den ikke et single point of failure?

Kun hvis den kører som en enkelt instans. Gateways i produktion kører som flere tilstandsløse instanser bag en load balancer, og failover mellem udbydere fjerner typisk flere udfald, end gatewayen selv tilføjer.

Kan gateway-leverandøren se mine prompts?

Med en hostet gateway, ja: prompts og svar passerer gennem leverandørens systemer. Med en selvhostet gateway er leverandøren slet ikke i forespørgselsvejen — softwaren kører i jeres infrastruktur og taler kun med de udbydere, I konfigurerer.

Kan den route til modeller, vi selv hoster?

Ja, hvis modellerne udstiller et OpenAI-kompatibelt API, som vLLM, Ollama og de fleste inferensservere gør. Gatewayen behandler dem som enhver anden udbyder, så modeller on-premises og i skyen står bag det samme endpoint og de samme regler. For modeller på medarbejdernes egne computere eller inde i mobilapps registrerer Wäg Edge de lokale kald og rapporterer dem til gatewayen.

Ét endpoint. Alle modeller. Fuld kontrol.

Start med open source

Kør det i jeres egen infrastruktur

Alt, hvad I skal bruge for at drive en control plane i produktion, er Apache-2.0 og bliver ved med at være det — routing, HA, caching, failover, budgetter, policy, MCP, jobs og observability. Self-hosted, ingen konto, ingen phone-home.

$ docker run -p 4000:4000 <registry>/waeg-gateway:<version>

Endnu ikke et pull, der virker: images er ikke offentlige endnu. Designpartnere får registry-oplysningerne direkte.

Deploy på 5 minutter
Designpartnerskab

Vær med til at forme det som designpartner

Wäg er endnu ikke offentligt tilgængelig. Vi arbejder sammen med en lille gruppe teams, der kører multi-provider AI i produktion og tager governance og suverænitet alvorligt, for at hærde vores control plane på reelle workloads.

  • Alle Enterprise-funktioner inkluderet, uden licensomkostning
  • Praktisk migrering — vi gør det sammen med jer, også fra LiteLLM
  • Direkte adgang til de engineers, der bygger det, og reel indflydelse på, hvad der kommer næst
Ansøg om at deltage