Was ist ein AI Gateway?
Ein AI Gateway ist ein gemeinsamer Zugangspunkt zwischen Ihren Anwendungen und den KI-Modellen, die sie nutzen — OpenAI, Anthropic, Mistral oder Modelle, die Sie selbst betreiben. Statt dass jede Anwendung eigene Schlüssel hält und eigene Entscheidungen trifft, läuft jede Anfrage durch eine Stelle, an der Zugriff, Kosten, Datenregeln und der Nachweis, was passiert ist, einmal für alle geregelt werden.
Dieselben drei Anwendungen, zweimal
Ohne Gateway
- Jede Anwendung hält ihre eigenen Anbieter-Schlüssel — und jede ist eine Stelle, an der ein Schlüssel abfließen kann.
- Jedes Team baut eigene Wiederholungen, Limits und Protokollierung, jedes ein wenig anders.
- Die Kosten kommen als eine Rechnung pro Anbieter, ohne eine Zeile für das Team oder die Funktion, die sie verursacht hat.
- Einen Anbieter hinzuzufügen oder zu wechseln heißt, Code in jeder Anwendung zu ändern.
Mit Gateway
- Die Anbieter-Schlüssel liegen an einer Stelle. Anwendungen bekommen eigene Gateway-Keys, die sich widerrufen lassen, ohne den Anbieter anzufassen.
- Wiederholungen, Failover und Caching passieren einmal, auf dieselbe Weise, für jede Anwendung.
- Jede Anfrage wird in dem Moment, in dem sie passiert, einem Team, einer Anwendung und einem Nutzer zugeordnet.
- Modelle werden in der Konfiguration hinzugefügt oder getauscht. Der Anwendungscode bleibt gleich.
Fünf Dinge passieren mit jeder Anfrage
Die Details unterscheiden sich von Produkt zu Produkt, die Form ist dieselbe: erst die Prüfungen, in der Mitte der Modellaufruf, am Ende der Nachweis. Eine Anfrage, die eine Prüfung nicht besteht, stoppt, bevor jemand dafür bezahlt.
- Prüfen, wer fragt. Die Anwendung legt ihren eigenen Gateway-Key vor, oder das Firmen-Login eines Nutzers. Unbekannte Aufrufer werden abgewiesen. ✗ abgewiesen
- Limits prüfen. Liegt dieses Team innerhalb seines Budgets und seines Ratenlimits? Falls nicht, endet die Anfrage hier — bevor der Anbieter kontaktiert wird. ✗ Budget überschritten
- Regeln anwenden. Organisationsweite Regeln laufen über den Prompt — zum Beispiel personenbezogene Daten maskieren oder verhindern, dass sie zu einem externen Anbieter gelangen. ✗ blockiert · ◑ maskiert
- Ein Modell wählen und aufrufen. Das Gateway entscheidet, welcher Anbieter und welches Modell die Anfrage bedient, und wechselt zum nächsten, wenn ein Anbieter langsam ist oder ausfällt.
- Festhalten, was passiert ist. Wer gefragt hat, welches Modell geantwortet hat, was es gekostet hat und welche Regeln galten — für jede Anfrage aufgeschrieben, nicht nachträglich rekonstruiert.
Das ist die vereinfachte Fassung. Der vollständige Anfrageweg von Wäg hat neun Stufen, darunter Caching und Werkzeug-Policy für Werkzeugaufrufe von Agenten: den Anfrageweg Stufe für Stufe ansehen.
Es beginnt meistens mit einem davon
Niemand kauft ein Gateway, nur weil es die Kategorie gibt. Man kauft es, weil etwas von dieser Liste passiert ist.
| Was Ihnen auffällt | Was ein Gateway dagegen tut | Mehr dazu |
|---|---|---|
| Die KI-Rechnung hat sich verdoppelt, und niemand kann sagen, welches Team dahintersteckt. | Ordnet die Kosten jeder Anfrage einem Team, einer Anwendung und einem Nutzer zu und stoppt die Ausgaben an einem Limit, das Sie setzen. | Kosten und Budgets |
| Anbieter-Schlüssel stehen in einem Dutzend Konfigurationsdateien und CI-Secrets. | Hält die Anbieter-Schlüssel an einer Stelle. Anwendungen bekommen Gateway-Keys, die Sie eingrenzen, rotieren und widerrufen können. | Sicherheit |
| Ein Ausfall bei einem Anbieter hat eine Funktion für Kunden mit heruntergerissen. | Wiederholt Anfragen und wechselt automatisch zu einem anderen Anbieter oder Modell. | Routing und Failover |
| Jemand hat gefragt, ob Kundendaten an ein externes Modell gehen, und niemand wusste es. | Wendet Datenregeln auf jeden Prompt an — maskieren, schwärzen oder blockieren —, bevor er das Haus verlässt. | Policy und Guardrails |
| Jedes Team hat sich sein eigenes Modell gewählt, und die meisten nehmen standardmäßig das teuerste. | Leitet jede Anfrage an das günstigste Modell, das sie bewältigen kann — nach Policy statt nach Gewohnheit. | Intelligentes Routing |
| Ein Prüfer, ein Kunde oder der EU AI Act fragt, was Ihre KI-Systeme tatsächlich getan haben. | Führt ein Protokoll jeder Anfrage: wer gefragt hat, welches Modell geantwortet hat, was es gekostet hat, welche Regeln galten. | EU AI Act und Protokollierung |
| Agenten rufen inzwischen Werkzeuge und interne Systeme mit echten Zugangsdaten auf. | Führt Werkzeugaufrufe von Agenten durch dieselbe Identität, Policy und denselben Nachweis wie Modellaufrufe. Nicht jedes Gateway kann das — fragen Sie nach. | Agenten-Governance |
Meistens eine Zeile
Die meisten Gateways sprechen die OpenAI-API, die nahezu jedes KI-SDK und jedes Framework bereits unterstützt. Ein Gateway einzuführen heißt, die Adresse zu ändern, an die Ihre Anwendung Anfragen schickt, und den Schlüssel, mit dem sie das tut.
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 und Verarbeitung der Antworten bleiben, wie sie sind. Ein gutes Gateway übersetzt auch für Anbieter mit anderer API, etwa Anthropic oder Gemini, sodass die Anwendung nie wissen muss, welcher Anbieter geantwortet hat.
Die Entscheidung, von der viele nicht wissen, dass sie sie treffen
Ein Gateway sieht jeden Prompt und jede Antwort, die hindurchgehen. Die erste Frage ist deshalb nicht, welche Funktionen es hat, sondern auf wessen Infrastruktur es läuft.
| Frage | Gehostet — ein Anbieter betreibt es | Selbst betrieben — Sie betreiben es |
|---|---|---|
| Wohin Prompts und Antworten gehen | Auf dem Weg zum Modellanbieter durch das Netz und die Systeme des Gateway-Anbieters | Nirgendwohin Neues — sie bleiben in Ihrer Infrastruktur, bis sie den von Ihnen gewählten Anbieter erreichen |
| Wer Ihre Anbieter-Schlüssel hält | Der Anbieter | Sie |
| Zeit bis zur ersten Anfrage | Minuten — anmelden und die Basis-URL ändern | Länger — Sie müssen es erst bereitstellen |
| Wer es am Laufen hält | Der Anbieter | Ihr Team, meist das Platform-Team |
| Die richtige Wahl, wenn | Tempo am wichtigsten ist und die Daten nicht sensibel sind | Datenschutz, Regulierung oder Beschaffungsvorgaben einen Dritten im Anfrageweg ausschließen |
Nicht immer
Sie eine Anwendung, einen Anbieter und ein Team haben und niemand außerhalb der Technik nach KI-Kosten oder Daten fragt. Den Anbieter direkt aufzurufen ist einfacher, und einfach ist ein Vorteil. Kommen Sie wieder, wenn sich das ändert.
Schauen Sie sich um, sobald eines davon passiert:
- Ein zweites Team oder ein zweiter Anbieter kommt dazu.
- Jemand fragt, was KI pro Team oder pro Produkt kostet, und die Antwort dauert eine Woche.
- Datenschutz oder Sicherheit fragen, wohin Prompts gehen.
- Ein Ausfall bei einem Anbieter wird zu Ihrem Ausfall.
- Agenten beginnen, mit echten Zugangsdaten auf Ihren Systemen zu handeln.
Wenn ein Gateway nicht reicht
Ein Gateway steuert die Anwendungen, die sich entscheiden, darauf zu zeigen. Sobald KI zur gemeinsamen Infrastruktur wird — viele Teams, Agenten mit echter Befugnis, Prüfer, die Fragen stellen —, wandelt sich die Frage von „wie werden Anfragen weitergeleitet“ zu „wer entscheidet für die ganze Organisation, was eine Anfrage sein darf“. Das ist die Grenze zwischen einem AI Gateway und einer AI Control Plane.
Ein AI Gateway, das Sie selbst betreiben
Wäg ist ein Open-Source-AI-Gateway, das vollständig in Ihrer eigenen Infrastruktur läuft: keine gehostete Version, kein Anbieter im Anfrageweg, kein Phone-Home. Es spricht die OpenAI-API, verbindet sich mit 25+ OpenAI-kompatiblen Anbietern sowie nativ mit Anthropic und Gemini und ergänzt die Control-Plane-Schicht — Identität, hierarchische Budgets, Policy, Agenten-Governance und Audit — im selben Anfrageweg. Apache-2.0, in Rust geschrieben.
Sie betreiben bereits LiteLLM oder ein anderes Gateway? Wäg importiert die LiteLLM-Konfiguration, und die Migrationsanleitung beschreibt, wie Sie beide parallel laufen lassen, bevor Sie umstellen.
Was Leute zuerst fragen
Ist ein AI Gateway dasselbe wie ein LLM-Proxy?
Im Wesentlichen ja. LLM-Proxy, AI-Proxy, LLM-Gateway und AI Gateway beschreiben alle einen Endpunkt vor mehreren Modellanbietern. Gateway meint meist mehr als Weiterleiten — Schlüssel, Limits, Regeln und einen Nachweis —, aber die Begriffe werden nicht einheitlich verwendet. Prüfen Sie also, was ein Produkt tatsächlich durchsetzt, nicht, wie es heißt.
Worin unterscheidet es sich von einem API-Gateway?
Ein API-Gateway verwaltet Anfragen: Routing, Authentifizierung und Ratenlimits pro Aufruf. Ein AI Gateway versteht zusätzlich, was in einer Modellanfrage steckt — Tokens, den Preis je Modell, gestreamte Antworten, Prompts, die personenbezogene Daten enthalten können, und Anbieter, die füreinander einspringen können. Manche API-Gateways bringen inzwischen KI-Funktionen mit; die nützliche Frage ist, ob sie Tokens und Kosten zählen oder nur Anfragen.
Muss ich meinen Anwendungscode ändern?
Meist nur die Basis-URL und den Schlüssel, vorausgesetzt das Gateway spricht die OpenAI-API und Ihre Anwendung nutzt ein OpenAI-kompatibles SDK oder Framework — was die meisten tun.
Macht es Anfragen langsamer?
Es fügt einen Netzwerksprung hinzu und kostet damit etwas Zeit. Ein gut gebautes Gateway fügt Millisekunden hinzu, bei Modellantworten, die hunderte Millisekunden bis mehrere Sekunden dauern, und ein Cache-Treffer kann eine Anfrage deutlich schneller machen als den Anbieter direkt aufzurufen. Fragen Sie jeden Anbieter nach dem Overhead, gemessen mit eingeschalteter Protokollierung und Budgets, nicht ohne.
Ist es nicht ein Single Point of Failure?
Nur wenn es als einzelne Instanz läuft. Produktive Gateways laufen als mehrere zustandslose Instanzen hinter einem Load Balancer, und Failover zwischen Anbietern verhindert in der Regel mehr Ausfälle, als das Gateway verursacht.
Sieht der Gateway-Anbieter meine Prompts?
Bei einem gehosteten Gateway ja: Prompts und Antworten laufen durch die Systeme des Anbieters. Bei einem selbst betriebenen Gateway steht der Anbieter gar nicht im Anfrageweg — die Software läuft in Ihrer Infrastruktur und spricht nur mit den Anbietern, die Sie konfigurieren.
Kann es zu Modellen routen, die wir selbst betreiben?
Ja, wenn diese Modelle eine OpenAI-kompatible API anbieten, wie vLLM, Ollama und die meisten Inferenz-Server es tun. Das Gateway behandelt sie wie jeden anderen Anbieter, sodass lokale und Cloud-Modelle hinter demselben Endpunkt und denselben Regeln stehen. Für Modelle auf den eigenen Rechnern der Mitarbeitenden oder in mobilen Apps zeichnet Wäg Edge die lokalen Aufrufe auf und meldet sie an das Gateway.
Ein Endpunkt. Jedes Modell. Volle Kontrolle.
Betreiben Sie es in Ihrer eigenen Infrastruktur
Alles, was Sie brauchen, um eine Control Plane produktiv zu betreiben, steht unter Apache-2.0 und bleibt es auch — Routing, HA, Caching, Failover, Budgets, Policy, MCP, Jobs und Observability. Self-hosted, ohne Account, ohne Phone-Home.
$ docker run -p 4000:4000 <registry>/waeg-gateway:<version>Kein funktionierender Pull: Die Images sind noch nicht öffentlich. Designpartner erhalten die Registry-Details vertraulich.
In 5 Minuten deployenAls Design-Partner mitgestalten
Wäg ist noch nicht öffentlich verfügbar. Wir arbeiten mit einer kleinen Gruppe von Teams, die Multi-Provider-KI produktiv betreiben und Governance und Souveränität ernst nehmen, um die Control Plane an echten Workloads zu härten.
- Jede Enterprise-Funktion enthalten, ohne Lizenzkosten
- Migration gemeinsam mit uns — auch von LiteLLM
- Direkter Draht zu den Engineers und realer Einfluss darauf, was als Nächstes kommt