AI-gateway vs AI control plane
Begreppen används omväxlande, vilket är ett problem när ni specificerar infrastruktur. Skillnaden är inte marknadsföring — den handlar om var beslut fattas och vad de gäller.
Den ena routar requests. Den andra avgör vad en request får vara.
En AI-gateway
Sätter en endpoint framför flera leverantörer. Den routar, håller nycklar, gör omförsök, cachar och gör failover. Den löser ett problem med anslutning och motståndskraft, och den löser det för den som pekar på den.
En AI control plane
Avgör vad en request får vara innan den blir en: vem som frågar, vad de får spendera, vilka data som får lämna, vilken modell som får betjäna den, och vilket spår requesten lämnar efter sig. Den löser ett styrningsproblem, för organisationen, oavsett om varje applikation deltog eller inte.
Varje control plane innehåller en gateway. Varje gateway blir inte en control plane — det kräver att identitet, budgetar, policy och revision är förstklassiga i requestvägen snarare än fastskruvade vid sidan av den.
Var gränsen faktiskt går
| Axel | Gateway | Control plane |
|---|---|---|
| Enhet i fokus | En request och en rutt | En inferensrequest, med sin kostnad, policy och identitet |
| Omfattning | De tjänster som pekar på den | Varje AI-arbetslast i organisationen |
| En agents befogenhet | En nyckel som fungerar tills någon roterar den | En identitet med en ägare, en körningsgräns, en verktygspolicy och en namngiven godkännare |
| Tillämpning | Rådgivande, eller gränser per nyckel | I requestvägen, innan leverantören kontaktas |
| Underlag som skapas | Trafikloggar | Beslut — modell, orsak, utfall, kostnad, aktör |
| Drivs av | Ett team | Organisationen, som gemensam infrastruktur |
Så avgör ni vilken ni har
Användbart när ni utvärderar vilken leverantör som helst i den här kategorin, inklusive oss.
- Anslutningstestet. Om ett team startar en tjänst i morgon utan att berätta det för er — styrs den då? En gateway styr det som pekar på den. En control plane styr det som organisationen har beslutat måste gå genom den — och gör allt som inte gör det till ett undantag ni kan upptäcka.
- Tillämpningstestet. När en budget överskrids — stoppas något, eller blir en dashboard röd? Rådgivande gränser är rapportering. En control plane avvisar anropet innan leverantören kontaktas.
- Dokumentationstestet. Kan ni sex månader senare rekonstruera vilken modell som betjänade en request, varför, vilka policyutfall som gällde, vad den kostade och för vems räkning? En gateway loggar trafik. En control plane producerar beslut.
Samma tre händelser, två gånger
| Händelse | Med en gateway | Med en control plane |
|---|---|---|
| Ett teams kostnader fördubblas över en natt | Ni får veta det av leverantörsfakturan, eller av en dashboard som ingen tittade på. Att fördela kostnaden blir en dataövning. | Webhooken för mjuk budget utlöstes vid tröskeln; den hårda gränsen nekade överskridandet innan det spenderades, och bara mot det teamets räknare. |
| En ny regel för datahantering utfärdas | Det blir ett ärende för varje team som anropar en modell, och ett kodgranskningsproblem för all framtid. | En policyändring får effekt för varje arbetslast bakom endpointen samtidigt, även de som ingen registrerade. |
| En agent anropar ett osanktionerat verktyg | Verktygsanropet gick aldrig genom gatewayen, så det finns ingen dokumentation på att det skedde. | Verktyg som nås via gatewayens MCP-endpoint står på en tillåtlista, så anropet nekades och loggades. En server som klienten själv kör syns i agentinventariet. |
Ofta inte
AI är en funktion i en tjänst, med en leverantör och ett team. En gateway är rätt storlek för det, och att köpa för mycket infrastruktur är ett eget felläge. Inget nedan gäller er ännu, och att införa en control plane tidigt ger mest driftsyta ni inte behöver.
Ni behöver troligen en så snart något av det här stämmer:
- Fler än en handfull team anropar modeller.
- Kostnader måste fördelas på kostnadsställen, inte bara begränsas.
- Regler för datahantering måste hålla över applikationer, inte per repository.
- Agenter anropar externa verktyg med skarpa credentials.
- Ni måste kunna visa kontroll över AI-användningen för någon utanför utvecklingsorganisationen.
- Gatewayen blev bärande — varje produktväg är nu beroende av den.
En control plane som ni driftar
Wäg är en AI control plane i open source som körs i er egen infrastruktur. Den innehåller gatewayen — OpenAI-kompatibel, flera leverantörer, cache, failover — och lägger till identitet, hierarkiska budgetar, policy, agentstyrning och revision i samma requestväg. Den importerar LiteLLM-konfiguration, så om ni redan kör en gateway kostar det en bas-URL att prova.
En endpoint. Alla modeller. Full kontroll.
Kör den i er egen infrastruktur
Allt ni behöver för att köra en control plane i produktion är Apache-2.0 och förblir det — routing, HA, cache, failover, budgetar, policy, MCP, jobb och observability. Self-hosted, inget konto, ingen phone-home.
$ docker run -p 4000:4000 <registry>/waeg-gateway:<version>Ingen fungerande pull: avbilderna är inte publika än. Designpartner får registeruppgifterna privat.
Driftsätt på 5 minuterForma den som design partner
Wäg är ännu inte publikt släppt. Vi arbetar med en liten grupp team som kör AI från flera leverantörer i produktion och tar styrning och suveränitet på allvar, för att härda control plane:n mot verkliga arbetslaster.
- Alla Enterprise-funktioner ingår, utan licenskostnad
- Praktisk migrering — vi gör den tillsammans med er, även från LiteLLM
- En direktlinje till ingenjörerna som bygger den, och verkligt inflytande över vad som kommer härnäst