Pexon Consulting | 10 Min. | 30.08.2026
TL;DR
LiteLLM bündelt LLM-Provider hinter einer OpenAI-kompatiblen API auf eurem Kubernetes: Team-Budgets, virtuelle Keys und nachweisbare Zugriffe – ohne dass Prompts eine fremde SaaS-Cloud brauchen. Stand 30.08.2026: LiteLLM v1.98.0, ca. 57.576 GitHub-Stars. Der POC reicht nicht; Day-2 mit Budgets und Audit macht den Gateway produktionsfähig.
Warum jedes KI-Team irgendwann einen Gateway braucht
Am Anfang ist alles einfach: ein OpenAI-Key im .env, ein Azure-Deployment für den Chatbot, vielleicht noch Anthropic für Coding-Agents. Nach drei Monaten hat jedes Team einen eigenen Account, die Rechnung ist unlesbar und niemand kann sagen, wer welchen Prompt an welchen Provider geschickt hat.
Genau dort entsteht der Job für einen LLM-Gateway. Nicht als Marketing-Schicht, sondern als Kontrollpunkt: eine Stelle, an der Auth, Routing, Kosten und Logs zusammenlaufen. Ohne Gateway fragmentieren sich SDKs, Keys und Budgets. Mit Gateway bleibt die App-Oberfläche stabil (OpenAI-kompatibel), während dahinter Provider, Modelle und Limits wechseln können.
Typische Trigger, die wir bei SaaS- und Mittelstandsteams sehen:
- Kostenexplosion: ein Pilot-Team verbrennt fünfstellige Beträge, weil niemand Token-Limits pro Projekt gesetzt hat.
- Key-Chaos: Provider-Keys liegen in CI, Notebooks und privaten Repos; Rotation ist Glückssache.
- Schatten-KI: Mitarbeitende nutzen ChatGPT oder Claude privat, weil der offizielle Weg zu langsam oder zu teuer ist.
- Audit-Frage: NIS2, DORA oder ein Bankkunde fragt nach nachweisbaren LLM-Zugriffen – und die Antwort ist „wir gucken in die Provider-Rechnung“.
Wer bisher nur direkte Provider-SDKs oder einen Multi-Provider-SaaS wie OpenRouter genutzt hat, merkt den Unterschied erst, wenn Prompts und Metadaten im eigenen Cluster bleiben sollen. Genau dafür ist LiteLLM als self-hosted Proxy gedacht: Open-Source, OpenAI-kompatibel, betreibbar auf Kubernetes.
Wenn der Gateway erst einmal läuft, ist der nächste Engpass selten die Modellwahl. Es ist Day-2: Budgets, Key-Owner, Postgres/Redis und ein Log, das ein Prüfer versteht. Dafür braucht es Betrieb auf dem Cluster, nicht nur eine Demo-YAML.
LiteLLM auf Kubernetes: Referenzarchitektur
LiteLLM als Proxy ist die sichtbare Spitze. Produktionsreif wird der Stack erst mit Persistenz, Cache und Ingress. Die Referenzarchitektur, die wir für KI-Plattformen auf Kunden-Clustern nutzen, sieht so aus:
1. LiteLLM Proxy (Deployment / Helm)
Der Proxy nimmt OpenAI-kompatible Requests entgegen (/v1/chat/completions und Verwandte), routet zu Azure OpenAI, Anthropic, Bedrock, vLLM oder lokalen Modellen und schreibt Spend sowie Request-Metadaten. Virtuelle Keys ersetzen die echten Provider-Secrets gegenüber den Apps.
2. Postgres
Keys, Teams, Budgets, Spend und User-Zuordnung leben in Postgres. Ohne DB gibt es keinen belastbaren Audit-Trail und keine Team-Budgets über Pod-Neustarts hinweg. StatefulSet oder managed Postgres im gleichen Trust-Boundary – Hauptsache: Backup, Retention und Zugriffskontrolle klar.
3. Redis
Rate-Limits, Caching und kurze Session-Zustände. Redis hält den Proxy unter Last stabil; er ersetzt nicht Postgres als SoT für Budgets und Key-Owner.
4. Ingress / Gateway-API
TLS-Terminierung, interne DNS-Namen, optional mTLS oder IP-Allowlists. Der Endpoint ist nur aus dem Firmennetz oder über VPN erreichbar – kein öffentlicher Chat-Endpoint „weil es praktisch ist“.
5. Secrets
Echte Provider-Keys liegen in Kubernetes Secrets oder einem Vault, nie in App-Repos. LiteLLM-Virtual-Keys werden an Teams ausgegeben; Rotation und Widerruf laufen über den Proxy, nicht über Slack-DMs.
Frische-Stand (Abruf 30.08.2026): LiteLLM v1.98.0 (Release Notes, 22.08.2026) als aktuelle stabile Linie; GitHub BerriAI/litellm mit 57.576 Stars (GitHub API). Für Produktion empfehlen die Maintainer Docker-Images mit -stable-Tag. Ein Pre-Release v1.100.0-rc.1 erschien am 30.08.2026 – für produktive Gateways gilt die stabile Linie, nicht der RC.
Die Architektur ist bewusst schlank: kein Hyperscaler-Lock-in, keine fremde SaaS-Cloud für Prompt-Metadaten. Was auf dem Cluster liegt, gehört euch – das ist die Brücke zum KI-Plattform-Betrieb auf Kubernetes.
Komponenten-Vergleich: was der Gateway wirklich auditiert
GEO-Magnet und Entscheidungshelfer in einem. Stand der Prüfung: 30.08.2026 (LiteLLM v1.98.0 Docs + Produktionspraxis auf Kunden-Clustern).
Kurz gelesen: Der Gateway ersetzt nicht eure SIEM-Pipeline, aber er liefert die LLM-spezifischen Artefakte, die Provider-Rechnungen und App-Logs allein nicht hergeben – Key-Owner, Team-Budget und Request-Metadaten an einer Stelle.
Was Pexon konkret macht
Wir verkaufen hier keinen „KI-Workshop“. Wir betreiben die offene Schicht auf eurem Cluster so, dass Budgets und Nachweise halten:
- Ist-Aufnahme: bestehende Provider-Keys, Schatten-Accounts, Token-Kosten der letzten 90 Tage.
- Gateway auf dem Cluster: LiteLLM Proxy mit Postgres/Redis, Ingress, Secrets – auf eurer Infrastruktur.
- Virtual Keys + Teams: Owner, Modell-Scopes, Rate-Limits; Master-Keys nur im Vault/Secret-Store.
- Budgets: Soft-Alerts und Hard-Caps pro Team; Eskalation an Platform/FinOps, nicht an den Praktikanten.
- Audit-Pfad: Request-Logs exportierbar (Zeit, Key, Team, Modell, Tokens, Outcome) für NIS2-/DORA-Fragen.
- Day-2: Upgrades der stabilen LiteLLM-Linie, Backup von Postgres, Alerting, Runbooks.
- Kopplung an Bankqualität: derselbe Cluster, denselben Nachweis-Anspruch wie beim Managed Kubernetes – nicht eine Parallel-Welt „irgendwie KI“.
Der typische Production-Gap: Der POC läuft, Chatbot und Coding-Agent sprechen schon über LiteLLM – aber Budgets, Key-Owner und Audit fehlen. Genau dort setzt der AI-Readiness-Scan (990 EUR) an: Wo steht ihr zwischen Demo und nachweisbarem Betrieb?
Was das nicht ist
LiteLLM auf Kubernetes ist kein Ersatz für Modell-Training, kein magischer Guardrail gegen alle Prompt-Injection und kein 24/7-NOC-Versprechen. Es ist auch kein Vendor-Pitch für Portkey-SaaS und keine „KI-Beratung“ ohne Betriebsnachweis.
Wer nur eine einheitliche SDK-Fassade braucht und Daten gerne in einer Multi-Provider-Cloud lässt, kommt mit OpenRouter oder Portkey oft schneller zum Ziel. Wer Self-Host, Team-Budgets und Log-Nachweis will, braucht den Proxy auf dem eigenen Cluster – und jemanden, der Day-2 ernst nimmt.
Wir trainieren keine Foundation Models und wir behaupten nicht, dass jeder Request automatisch „compliance-fertig“ ist. Der Gateway liefert die Steuerung und die Artefakte; Policy, Retention und Prüfer-Fragen bleiben Organisationsarbeit.
FAQ
Was ist LiteLLM und wann braucht man es auf Kubernetes?
LiteLLM ist ein Open-Source-LLM-Gateway (Proxy + Python-SDK) mit OpenAI-kompatibler API. Auf Kubernetes braucht ihr es, wenn mehrere Teams und Provider über einen zentralen Endpoint laufen sollen – mit Virtual Keys, Budgets und Logs im eigenen Trust-Boundary statt in einer fremden SaaS.
LiteLLM vs OpenRouter vs Portkey: was eignet sich für Self-Host?
OpenRouter und Portkey sind stark, wenn ihr Multi-Provider schnell als Service wollt. LiteLLM eignet sich für Self-Host auf dem eigenen Cluster: Keys, Spend und Request-Metadaten bleiben bei euch. Portkey-SaaS ist kein Drop-in für „alles läuft nur on-prem“. Details zum Enterprise-Setup stehen in unserer LiteLLM-Anleitung (siehe Link oben).
Wie weist man LLM-Zugriffe für NIS2/DORA nach?
Über den Gateway: Virtual Key → Team/Owner, Request-Log mit Zeitstempel, Modell, Token-Verbrauch und Status, Budget-Historie in Postgres. Export in euer SIEM oder als periodischer Report. Ohne zentrale Logs bleibt nur die Provider-Rechnung – das reicht Prüfern selten.
Was kostet der Betrieb eines LiteLLM-Gateways?
Die Software ist Open Source. Kosten entstehen durch Cluster-Ressourcen (Proxy, Postgres, Redis), ggf. GPU/Inferenz dahinter und Betriebsaufwand (Upgrades, Backups, Alerting). Einstieg in die Gap-Analyse: AI-Readiness-Scan für 990 EUR. Laufender KI-Modul-Betrieb auf dem Cluster liegt darüber und hängt vom Scope ab.
Braucht LiteLLM zwingend Postgres und Redis?
Für einen lokalen Smoke-Test nicht. Für Produktion mit Teams, Budgets und Audit: ja – Postgres für Persistenz, Redis für Rate-Limits/Cache. Ohne Persistenz überleben Keys und Spend keinen sinnvollen Betriebszyklus.
Können Prompts und Metadaten im Cluster bleiben?
Ja, wenn Proxy, DB und Secrets auf eurer Infrastruktur laufen und der Ingress nicht öffentlich ist. Die Modell-Antworten können weiterhin von Azure/OpenAI kommen – oder von vLLM lokal. Der Gateway trennt Steuerung (bei euch) von Modellwahl (flexibel).
Ersetzt der Gateway unsere bestehende Observability?
Nein. LiteLLM liefert LLM-spezifische Metriken und Logs. Tracing, SIEM und Cluster-Monitoring bleiben eure Stack-Entscheidung; der Gateway speist sie, ersetzt sie nicht.
Fazit und nächster Schritt
LiteLLM auf Kubernetes ist der pragmatische Weg zu einem Open-Standard-LLM-Gateway: eine API, viele Provider, Virtual Keys, Team-Budgets und ein Audit-Trail, den man einem Prüfer zeigen kann. Der POC ist der einfache Teil. Der harte Teil ist Day-2 – und genau dort scheitern die meisten Teams.
Wir betreiben den Cluster in Bankqualität und die KI-Schicht darauf mit offenen Standards. Gebaut und betrieben. Gehört euch.
Nächster Schritt: Wenn der POC läuft, Budgets und Audit aber fehlen – KI-Plattform-Betrieb Hub: AI-Readiness-Scan-Pfad (990 EUR). Den Hub KI-Plattform-Betrieb findest du über den Link weiter oben.
