Ein lauffähiges Gateway in unter fünf Minuten
Ein Container, ein Anbieter, eine Anfrage. Kein Account, keine Anmeldung, kein Phone-Home. Wenn Sie Docker haben, sind Sie damit fertig, bevor Ihr Kaffee kommt.
Das Gateway starten
Der Embedded-Modus braucht nichts Externes: Der Zustand liegt im Speicher, nichts übersteht also einen Neustart, und es muss noch kein Postgres oder Redis stehen. Die Konsole läuft auf demselben Port, ausgeliefert von derselben Rust-Binary.
$ docker run -p 4000:4000 <registry>/waeg-gateway:<version>Kein funktionierender Pull: Die Images sind noch nicht öffentlich. Designpartner erhalten die Registry-Details vertraulich.
Registry und Version sind Platzhalter — Designpartner erhalten sie vertraulich. Konsole unter http://localhost:4000/ui/: Melden Sie sich mit dem vorangelegten Admin-Konto an und ändern Sie dessen Passwort.
Einen Anbieter hinzufügen
Geben Sie ihm ein Upstream und einen Alias und starten Sie dann neu, mit der Datei eingebunden wie im Kommentar gezeigt. Aliase sind das, worauf Ihr Anwendungscode verweist — Sie können sie später umbiegen, ohne die Anwendung anzufassen.
# waeg.yaml
providers:
openai:
provider: openai
api_key_env: OPENAI_API_KEY # or api_key_ref: a vault reference
models:
- name: chat # what your code sends as "model"
deployments:
- provider: openai
model_id: gpt-4o
# Restart with it mounted:
# docker run -p 4000:4000 -e OPENAI_API_KEY \
# -v "$PWD/waeg.yaml:/etc/waeg/waeg.yaml" \
# <registry>/waeg-gateway:<version> serve --config /etc/waeg/waeg.yamlIhr SDK darauf richten
Wäg bedient die OpenAI-kompatible Oberfläche, es ändert sich also nur die Base-URL. Ihr SDK, die Anfrageformate, das Streaming-Verhalten und Tool-Calling bleiben unverändert.
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:4000/v1", # the only change
api_key="<your-waeg-virtual-key>", # created in the console
)
resp = client.chat.completions.create(
model="chat",
messages=[{"role": "user", "content": "Hello"}],
)Prüfen Sie die Antwort-Header. Das ist das erste sichtbare Zeichen dafür, dass etwas entschieden wurde, statt nur weitergeleitet:
| Header | Was er Ihnen sagt |
|---|---|
x-waeg-routed-model | Welches Deployment die Anfrage tatsächlich bedient hat. |
x-waeg-route-reason | Warum der Router es gewählt hat — bei intelligentem Routing und Sitzungsaffinität. |
x-waeg-cache | Bei einem Cache-Treffer: welche der vier Stufen geantwortet hat. |
In der Konsole ansehen
Öffnen Sie die Konsole, und die Anfrage ist bereits da: Traffic, Latenz, Tokens, die Routing-Entscheidung und etwaige Policy-Bewertungen. Kosten erscheinen, sobald das mitgelieferte Preispaket unter Usage & cost → Pricing geladen ist. Sonst wurde nichts konfiguriert — das ist es, was der Durchlauf durch den Anfrageweg erzeugt.
Wie es von hier aus weitergeht
Von LiteLLM migrieren
Bestehende Config mit einem Befehl importieren, beides parallel betreiben und umstellen, wenn die Zahlen übereinstimmen.
Für den Ernstfall deployen
Der Wäg-Operator betreibt das Gateway aus einer einzigen Custom Resource — Skalierung, Rollouts, Prüfung seiner Abhängigkeiten —, und ein Helm-Chart gibt es auch. Postgres, OpenFGA, Redis und einen Object Store bringen Sie mit.
Governance ergänzen
Hierarchische Budgets, die Policy-Kette, Agenten- und MCP-Steuerung, Audit-Nachweise.
Wäg befindet sich in der Private Preview, die Image-Adresse oben ist also ein Platzhalter. Designpartner erhalten die gebauten, signierten Images und die Registry-Details vertraulich, mit persönlichem Onboarding.