Von LiteLLM zu Wäg in einem Nachmittag, nicht einem Quartal
LiteLLM bringt Teams schnell zu Multi-Provider — deshalb läuft es in so vielen Produktivsystemen. Was es nicht mitbringt, ist eine Governance-Schicht: hierarchische Budgets, die Ausgaben stoppen, bevor der Anbieter aufgerufen wird, Policy-Durchsetzung im Anfrageweg, Werkzeugaufrufe, die auf einen benannten Freigeber warten, und ein Audit-Nachweis, den Sie einem Compliance-Team geben können. Wäg tritt an die Stelle des LiteLLM-Proxys und ergänzt diese Schicht. Ihr SDK, Ihre Modell-Aliase und Ihr Anwendungscode bleiben. Sie ändern eine Base-URL.
Was sich ändert
- Die Base-URL, auf die Ihre Clients zeigen
- Wo die Konfiguration liegt
- Der Proxy-Prozess, den Sie betreiben
Was nicht
- Ihr SDK — openai, langchain, llamaindex, das LiteLLM-SDK als Client, alles OpenAI-Kompatible
- Die Modell-Aliase, auf die Ihr Code verweist
- Anfrage- und Antwortformate
- Streaming-Verhalten, Tool-Calling, Vision
- Ihre Anbieterkonten und API-Schlüssel
Vier Schritte, keiner davon eine Neuentwicklung
1 · Konfiguration importieren
Liest Ihre LiteLLM-config.yaml — auf der Kommandozeile oder eingefügt unter Platform → System → Import in der Konsole — und erzeugt Wäg-Konfiguration: Modelle und Aliase, Referenzen auf Anbieter-Zugangsdaten, Routing-Strategie, Fallbacks, Redis, Projekte als Anwendungen mit Budgets, virtuelle Keys, MCP-Server und A2A-Agenten.
$ waeg import litellm --from config.yaml -o waeg.yaml$ waeg config validate --config waeg.yamlZu prüfen ist der Import-Bericht. Jeder Schlüssel landet in einer von vier Listen — mapped, skipped, needs_human und notes —, und die Kommandozeile gibt die Anzahl mit Beispielen aus:
mapped
model_list (12 rows) → 6 aliases: gpt-4o, claude, fast, cheap, embed, vision
model_list[3].litellm_params.rpm: 600 → relative deployment weight
litellm_settings.fallbacks → alias fallbacks
litellm_settings.num_retries: 3 → routing.max_retries: 3
router_settings.routing_strategy → routing.strategy: weighted (see notes)
projects[0] (max_budget, budget_duration) → application app_ll_search + application budget
skipped
litellm_settings.success_callback → re-create under Observability
needs_human
general_settings.master_key: os.environ/LITELLM_MASTER_KEY → set WAEG_MASTER_KEY
litellm_settings.cache_params → re-create under Caching
notes
routing_strategy "latency-based-routing-v2" is not known → weightedBeispielhafte Ausgabe. Sie zeigt, dass der Bericht ein echtes Artefakt ist: Nichts scheitert stillschweigend, alles ohne Wäg-Entsprechung wird zur Prüfung aufgeführt statt angenähert, und Secrets werden nie zurückgegeben.
2 · Eine Base-URL umstellen
Wäg bedient die OpenAI-kompatible Oberfläche — /v1/chat/completions, /v1/responses (zustandslos), /v1/embeddings, /v1/images/*, /v1/audio/*, /v1/videos, /v1/rerank, /v1/ocr, /v1/moderations, /v1/files, /v1/batches, /v1/realtime, /v1/models — dazu /v1/messages von Anthropic, /v1beta von Gemini sowie /v1/mcp und /v1/a2a für Agenten. LiteLLM-Clients wie Cline und Roo funktionieren weiter: GET /model/info antwortet mit oder ohne /v1, x-litellm-api-key wird auf Pass-Through- und MCP-Routen akzeptiert, und x-litellm-session-id fasst Aufrufe zu Konversationen zusammen. Streaming ist echtes SSE.
client = OpenAI(
- base_url="http://litellm:4000/v1",
+ base_url="https://waeg.internal/v1",
api_key=os.environ["GATEWAY_KEY"],
)Zu prüfen: GET /v1/models liefert Ihre Aliase, danach je eine Streaming- und eine Tool-Calling-Anfrage pro Alias.
3 · Parallel verifizieren
Betreiben Sie beides. Leiten Sie einen Anteil des Traffics an Wäg oder spiegeln Sie Produktions-Traffic dorthin und vergleichen Sie. Weil Replicas zustandslos sind und ihre Zähler über Redis und ihre Konfiguration über Postgres teilen, können Sie den Canary hoch- und runterskalieren, ohne Budgetzustand zu verlieren.
- Routing-Entscheidungen — x-waeg-routed-model auf jeder Antwort, x-waeg-route-reason bei intelligentem Routing
- Cache-Verhalten — x-waeg-cache und ob die Trefferquoten Ihren Erwartungen entsprechen
- Token-Zahlen und Kostenzuordnung gegen Ihre Anbieterrechnung
- p50/p95/p99-Latenz, Fehler- und Fallback-Raten
- Kompatibilitätssignale — Anfrage- und Antwortfelder, auf die Ihre Clients angewiesen sind und die das Gateway weitergereicht oder verworfen hat, gezählt aus Ihrem eigenen Traffic
4 · Umstellen
Stellen Sie die Base-URL für einen Service um, dann für die übrigen. Lassen Sie das LiteLLM-Deployment laufen, bis Sie zufrieden sind — ein Rollback ist dieselbe einzeilige Änderung in umgekehrter Richtung.
Eine sinnvolle Reihenfolge: zuerst interne Werkzeuge, dann Batch- und Offline-Workloads, dann ein Produktivservice, dann alles.
Stellen Sie die Base-URL zurück. Das ist der gesamte Vorgang — Wäg hält keinen Zustand, von dem Ihre Anwendungen abhängen, und Ihre Anbieterkonten, Schlüssel und Modell-Aliase bleiben unberührt. Lassen Sie beide Deployments während des Übergangs laufen. Es gibt bewusst keinen Lock-in-Schritt in dieser Migration.
Konfigurationsfeld für Konfigurationsfeld
| LiteLLM | Wäg | Anmerkungen |
|---|---|---|
model_list[].model_name | Modell-Alias | Wird wörtlich übernommen — Ihr Code läuft weiter |
litellm_params.model | Deployment: provider + model_id | Mehrere Zeilen mit demselben model_name werden zu gewichteten Deployments eines Alias |
api_key: os.environ/X | api_key_env: X | Zur Laufzeit aus der Umgebung gelesen; wechseln Sie später zu einer Vault-Referenz, wenn Sie möchten |
litellm_params.api_base | Anbieter-base_url | Ein anderer Host oder eine andere Region wird ein weiterer Anbieter |
router_settings.routing_strategy | routing.strategy | simple-shuffle und usage-based → weighted, least-busy und latency-based → latency, cost-based → cost; alles andere → weighted, mit Hinweis. Wäg ergänzt intelligent |
litellm_settings.fallbacks | Alias-Fallbacks | Bei der Strategie intelligent stärker-zuerst geordnet |
litellm_settings.num_retries | routing.max_retries | Plus ein Circuit Breaker je Deployment |
general_settings.master_key | master_key | Eine os.environ-Referenz wird zur Prüfung aufgeführt: Setzen Sie WAEG_MASTER_KEY. Plus virtuelle Keys mit Budgets und Modell-Whitelists |
projects[]: max_budget / budget_duration | Anwendung + Budget | Wäg ist hierarchisch: Org → Team → Nutzer → Anwendung → Modell → Key |
rpm auf einem Deployment | Deployment-Gewicht | Ein relatives Gewicht, kein Ratenlimit. rpm_limit und tpm_limit eines Projekts gehen in die Budget-Policy seiner Anwendung; TPM pro Deployment hat keine Entsprechung |
cache_params | nach dem Import neu anlegen | Unter Caching: exakte, kanonische, Near-Dup- und semantische Stufen mit Schutz vor Falschtreffern |
guardrails | nach dem Import neu anlegen | Dieselben Anbieter gibt es als Katalogeinträge, in einer geordneten Kette: vor, während und nach dem Aufruf |
success_callback / failure_callback | nach dem Import neu anlegen | Unter Observability: OTLP-, Langfuse- und HTTP-Callbacks, dazu Prometheus-Metriken |
custom Python callbacks | — keine Entsprechung | Wäg ist kein Python-Prozess. Nutzen Sie stattdessen eine HTTP-Webhook-Policy-Engine |
keys[] mit einer project_id | virtuelle Keys | An die Anwendung des Projekts gebunden, sodass das Budget eines Coding-Agenten an seinem Key hängt |
mcp_servers | Plattform-MCP-Server | Bearer- und API-Key-Auth werden zu statischen Zugangsdaten; Nutzer-OAuth und Token Exchange brauchen Enterprise. Importierte Werkzeuge werden gepinnt |
agents[] | Plattform-A2A-Agenten | Aktualisieren Sie nach dem Import jede Agent Card; das Gateway ruft sie ab und prüft sie |
import litellm (in-process) | ein Client des Gateways | Das SDK funktioniert weiter, wenn es auf Wäg zeigt; sein In-Process-Routing und seine Callbacks nicht |
Auch das, was LiteLLM kann und Wäg nicht
Prüfen Sie das gegen Ihr Setup, bevor Sie beginnen. Wenn eines der ersten beiden Punkte für Sie tragend ist, ist die Migration ein echtes Projekt statt eines Nachmittags — und das sollten Sie jetzt wissen, nicht auf halbem Weg.
Kein In-Process-Routing
LiteLLM lässt sich als Python-Bibliothek importieren. Zeigt das SDK auf Wäg, funktioniert es weiter als Client, aber sein In-Process-Routing und seine Callbacks werden nicht übernommen — das Routing geschieht stattdessen im Gateway.
Keine eigenen Python-Callbacks
LiteLLM erlaubt beliebigen Python-Code im Anfrage-Lebenszyklus. Der Erweiterungspunkt von Wäg ist eine HTTP-Webhook-Policy-Engine — sauberer zu betreiben und abzusichern, unmittelbar aber weniger flexibel. Aus umfangreicher Callback-Logik wird ein kleiner Service.
Weniger exotische Anbieter, dafür originalgetreuer
Die Anbieterabdeckung von LiteLLM ist breiter. Wäg hat rund ein Dutzend native Anbietertypen plus jeden OpenAI-kompatiblen Server, mit nativen Anthropic- und Gemini-Adaptern, die Tool-, Vision- und strukturierte Ausgaben originalgetreu erhalten, statt alles auf ein Format zu vereinheitlichen. Prüfen Sie vorher Ihre Liste.
Andere Routing-Philosophie
Wäg bewertet Anfragen strukturell — Tools, Vision, Kontextlänge, Reasoning-Signale — leitet daraus harte Fähigkeitsuntergrenzen ab und wählt dann das günstigste Modell, das sie erfüllt. Deterministisch und über Header erklärbar. Kein ML-Router im heißen Pfad.
Andere Cache-Philosophie
Vier Stufen — exakt, kanonisch, Near-Dup, semantisch — mit Schutz vor Falschtreffern. „Hauptstadt von Frankreich“ und „Hauptstadt von Spanien“ sind ein Miss. Zahlen, Verneinungen und geänderte Entitäten brechen einen Treffer.
Governance ist hierarchisch, nicht flach
Das ist der eigentliche Grund zu migrieren. LiteLLMs Budgets gelten pro Key. Die von Wäg staffeln sich über Org → Team → Nutzer → Anwendung → Modell → Key mit Fair-Share-Obergrenzen, sodass das Modell zur tatsächlichen Struktur von Organisationen passt.
Was Sie gewonnen haben
Budgets, die Ausgaben vorher stoppen
Gestaffelte Limits über Org → Team → Nutzer → Anwendung → Modell → Key. Jede Anfrage wird gegen jeden zutreffenden Zähler geprüft; die erste Überschreitung lehnt den Aufruf ab, bevor Anbieterkosten entstehen. Mit WAEG_CLUSTER=1 schließen sie auch dann, wenn Redis nicht erreichbar ist.
Policy im Anfrageweg
Eine geordnete Scanner-Kette vor dem Aufruf, mitten im Stream auf einem gleitenden Fenster und nach dem Aufruf. PII, Prompt Injection, Moderation oder Ihr eigener Webhook. Blockieren, maskieren oder schwärzen — pro Regel.
Gesteuerte Agenten-Schleifen
Entfernte MCP-Server erhalten Zugangsdaten pro Server — statischer Schlüssel, weitergereichtes Nutzer-Token oder OAuth Client Credentials, mit Enterprise auch die eigene OAuth-Verbindung des Nutzers oder Token Exchange — plus Werkzeug-Whitelists und Pinning. Werkzeugaufrufe können auf einen benannten Freigeber warten, mit Enterprise in Slack oder Teams, und jeder Schritt wird budgetiert und protokolliert.
Ein Audit-Nachweis
Jede Anfrage, Routing-Entscheidung, Policy-Bewertung und Kosten in Anfrage-Logs, OTLP-Traces und Prometheus-Metriken — und, einmal eingeschaltet, ein signierter, hash-verketteter Nachweis-Ledger, den jeder mit waeg ledger verify offline prüfen kann. Enterprise ergänzt Nachweis-Pakete, die dem AI Act und DORA zugeordnet sind, mit markierten Lücken, sowie die Kennzeichnung von KI-Inhalten.
Eine Binary
Rust, distroless, ohne Root. Keine Shell, kein Interpreter und kein Paketmanager im Gateway-Image, signierte Releases mit SBOM und keine Node-Laufzeit im Gateway — der optionale Konsolen-Assistent läuft als eigener Service.
Ein Operator für den Betrieb
Ein eigener Kubernetes-Operator deklariert das Gateway — Topologie, Speicher, OpenFGA, Skalierung per HPA oder KEDA — und gleicht Anbieter, Modelle, Budgets, Keys und Guardrails als Ressourcen ab. Fehlkonfigurationen erscheinen als Conditions mit Begründung, nicht als Pod, der eine Stunde später scheitert.
Sehen, wo das Gateway endet und die Control Plane beginnt · Zu den Benchmarks
Häufige Fragen
Muss ich meinen Anwendungscode ändern?
Nein. Sie ändern die Base-URL, die Ihr OpenAI-kompatibler Client ohnehin verwendet.
Lässt sich meine LiteLLM-Config übernehmen?
Weitgehend, über waeg import litellm oder Platform → System → Import in der Konsole. Sie erhalten einen Bericht darüber, was übernommen wurde, was übersprungen wurde und was eine menschliche Prüfung braucht, und nichts scheitert stillschweigend.
Kann ich beides parallel betreiben?
Ja, und das ist der empfohlene Weg. Spiegeln oder teilen Sie den Traffic und vergleichen Sie Routing-Entscheidungen, Kosten und Latenz vor der Umstellung.
Ist Wäg ein Fork von LiteLLM?
Nein. Es ist eine unabhängige Implementierung in Rust, gebaut um ein Inference-Request-Modell statt um Provider-SDK-Dispatch. Die Kompatibilität ist Absicht; die Herkunft ist eine andere.
Wird Streaming unterstützt?
Ja — echte Server-Sent Events, nicht gepuffert und nachträglich zerteilt.
Tool-Calling und Vision?
Ja, über OpenAI-, Anthropic- und Gemini-Anfrageformate. Native Adapter erhalten anbieterspezifisches Verhalten, statt es auf einen kleinsten gemeinsamen Nenner zu reduzieren.
Was ist mit den nativen APIs von Anthropic und Gemini?
Sie werden als erstklassige Anfrageformate unterstützt, nicht nur als Übersetzung des OpenAI-Formats.
Brauche ich Redis?
Für mehr als eine Replica ja — es hält Budgets und Ratenlimits über Replicas hinweg konsistent, neben Postgres und OpenFGA, die Produktion ohnehin braucht. Der Embedded-Modus braucht nichts Externes, ist aber Single-Node und hält seinen Zustand im Speicher.
Läuft es auf Kubernetes?
Ja, auf zwei Wegen. Ein eigener Operator deklariert das Gateway und seinen Katalog als Ressourcen — zustandslose Replicas, Skalierung per HPA oder KEDA, gemeinsame Budgetzähler, Health- und Readiness-Probes —, und ein Helm-Chart steht bereit, wenn Sie es lieber selbst betreiben.
Ist es wirklich Apache-2.0?
Ja. Der Produktionspfad des Gateways steht unter Apache-2.0: Routing, HA, Caching, Failover, Budgets, Guardrails, MCP, Jobs, Observability und der Nachweis-Ledger. Enterprise ergänzt Identität (SSO, SCIM, IdP-Tokens), Audit- und Nachweis-Pakete, Agenten-Zahlungen, Freigaben in Slack und Teams, Pass-Through-Guardrails und Support.
Telefoniert es nach Hause?
Nein. Keine Telemetrie und keine Analytik, und die Lizenz ist ein signiertes Offline-Token ohne Lizenzserver. Es läuft vollständig air-gapped: Beobachten Sie seine ausgehenden Verbindungen, und Sie sehen nur die Anbieter, die Sie konfiguriert haben.
Was, wenn wir Hilfe bei der Migration brauchen?
Designpartner erhalten praktische Migrationsunterstützung, auch von LiteLLM — wir machen es gemeinsam mit Ihnen, statt Ihnen eine Anleitung zu geben.
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