AI Gateway vs. AI Control Plane
Begreberne bruges i flæng, og det er et problem, når man specificerer infrastruktur. Skellet er ikke marketing — det handler om, hvor beslutningerne træffes, og hvad de gælder for.
Den ene router requests. Den anden afgør, hvad en request må være.
En AI Gateway
Sætter ét endpoint foran flere providers. Den router, holder nøgler, gentager, cacher og failer over. Den løser et konnektivitets- og robusthedsproblem, og den løser det for enhver, der peger på den.
En AI Control Plane
Afgør, hvad en request må være, før den bliver til én: hvem der spørger, hvor meget de må bruge, hvilke data der må forlade huset, hvilken model der må betjene den, og hvilken registrering den efterlader. Den løser et governance-problem for organisationen — uanset om den enkelte applikation deltog eller ej.
Enhver control plane indeholder en gateway. Ikke enhver gateway bliver en control plane — det kræver, at identitet, budgetter, politik og audit er førsteklasses i request-stien frem for skruet på ved siden af.
Hvor grænsen faktisk går
| Akse | Gateway | Control plane |
|---|---|---|
| Genstand for styring | En request og en rute | En inference-request med sin omkostning, politik og identitet |
| Omfang | De services, der peger på den | Enhver AI-workload i organisationen |
| En agents beføjelse | En nøgle, der virker, indtil nogen roterer den | En identitet med en ejer, en kørselsgrænse, en værktøjspolitik og en navngiven godkender |
| Håndhævelse | Vejledende, eller grænser pr. nøgle | I request-stien, før provideren kontaktes |
| Registrering der produceres | Trafiklogs | Beslutninger — model, årsag, afgørelse, omkostning, aktør |
| Drevet af | Ét team | Organisationen, som fælles infrastruktur |
Sådan afgør I, hvilken I har
Nyttigt ved vurdering af enhver leverandør i denne kategori, os inklusive.
- Opt-in-testen. Hvis et team starter en service i morgen uden at fortælle jer det, er den så styret? En gateway styrer det, der peger på den. En control plane styrer det, organisationen har besluttet skal igennem den — og gør det til en undtagelse, I kan opdage, hvis noget ikke går igennem.
- Håndhævelsestesten. Når et budget overskrides, stopper der så noget, eller bliver et dashboard bare rødt? Vejledende grænser er rapportering. En control plane afviser kaldet, før provideren kontaktes.
- Registreringstesten. Kan I seks måneder senere rekonstruere, hvilken model der betjente en request, hvorfor, hvilke politikafgørelser der gjaldt, hvad den kostede, og på hvis vegne? En gateway logger trafik. En control plane producerer beslutninger.
De samme tre hændelser, to gange
| Hændelse | Med en gateway | Med en control plane |
|---|---|---|
| Et teams forbrug fordobles natten over | I opdager det via provider-fakturaen eller via et dashboard, ingen holdt øje med. Attribuering er en dataøvelse. | Soft-budget-webhooken udløste ved tærsklen; den hårde grænse afviste overforbruget, før det blev brugt, og kun mod det teams tæller. |
| En ny regel for datahåndtering udstedes | Den bliver til en sag for hvert team, der kalder en model, og et code review-problem for altid derefter. | Én politikændring træder i kraft for enhver workload bag endpointet på én gang, inklusive dem, ingen har registreret. |
| En agent kalder et ikke-godkendt tool | Tool-kaldet passerede aldrig gennem gatewayen, så der findes ingen registrering af, at det skete. | Værktøjer, der nås via gatewayens MCP-endpoint, står på en allow-list, så kaldet blev afvist og logget. En server, klienten selv kører, dukker op i agentoversigten. |
Ofte ikke
AI er én funktion i én service, med én provider og ét team. En gateway er den rigtige størrelse til det, og at overkøbe infrastruktur er sin egen fejltilstand. Intet nedenfor gælder jer endnu, og at tage en control plane i brug for tidligt køber mest af alt driftsflade, I ikke har brug for.
I har sandsynligvis brug for en, så snart et af disse punkter er sandt:
- Mere end en håndfuld teams kalder modeller.
- Forbruget skal attribueres til omkostningssteder, ikke bare have et loft.
- Regler for datahåndtering skal holde på tværs af applikationer, ikke pr. repository.
- Agenter kalder eksterne tools med rigtige credentials.
- I skal kunne dokumentere kontrol med AI-brugen over for nogen uden for engineering.
- Gatewayen blev bærende — enhver produktsti afhænger nu af den.
En control plane, I selv driver
Wäg er en open source AI Control Plane, der kører i jeres egen infrastruktur. Den indeholder gatewayen — OpenAI-kompatibel, multi-provider, caching, failover — og tilføjer identitet, hierarkiske budgetter, politik, agent-governance og audit i den samme request-sti. Den importerer LiteLLM-konfiguration, så hvis I allerede kører en gateway, koster det én base-URL at prøve den.
Ét endpoint. Alle modeller. Fuld kontrol.
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 minutterVæ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