LiteLLM selbst hosten: Architektur- und Security-Guide für Production 2026

LiteLLM kann jeder Anwendung einen OpenAI-kompatiblen Endpoint geben, während das Gateway Provider-Zugangsdaten, Virtual Keys, Budgets, Routing und Observability übernimmt. Die offizielle Dokumentation beschreibt den Proxy als zentralen Service für Plattformteams, getrennt vom Python-SDK in einer einzelnen Anwendung. Genau um diesen Proxy als Infrastruktur geht es hier.

Die unterversorgte Frage lautet nicht mehr: „Kann ich den Container starten?“ Sie lautet: „Kann mein Team das Gateway patchen, skalieren und wiederherstellen, das jetzt alle Modell-Zugangsdaten hält?“ Eine Demo braucht einen Prozess. Production braucht einen Owner, eine private Datenschicht, eine Release-Policy und den Nachweis, dass ein Fehler nicht jedes KI-Feature gleichzeitig stoppt.

Was bedeutet es wirklich, LiteLLM selbst zu hosten?

LiteLLM selbst zu hosten bedeutet, dass Du das Gateway in Deiner eigenen Infrastruktur betreibst. Requests erreichen weiterhin OpenAI, Anthropic, Bedrock oder einen anderen konfigurierten Provider, außer Du leitest sie an einen lokalen Inference-Server wie vLLM oder Ollama. Du kontrollierst Proxy, Keys, Logs und Routing-Policy, nicht automatisch die Modellausführung.

Damit trennt sich dieser Artikel von zwei benachbarten Entscheidungen. Unser Vergleich von LLM-Gateways hilft Dir bei der Wahl zwischen LiteLLM, OpenRouter, Portkey oder einem Routing-Framework. Unser Kosten-Guide für selbst gehostete LLMs in der EU behandelt Modellgewichte und GPU-Inferenz. Hier ist das Produkt die Gateway-Control-Plane zwischen Deinen Anwendungen und beliebigen gehosteten oder lokalen Modellen.

Wann lohnt sich Self-Hosting mit LiteLLM?

LiteLLM gibt für sein Open-Source-Gateway keine Lizenzgebühr an und listet dort Virtual Keys, Budgets, Rate-Limits, Fallbacks, Logging und Prometheus-Metriken. Enterprise ergänzt Governance und Support, etwa SSO, SCIM und Audit-Logs. Prüfe die aktuelle Trennung vor der Beschaffung auf der LiteLLM-Preisseite.

Welche Architektur braucht ein produktives LiteLLM-Deployment?

Der aktuelle LiteLLM-Guide für Production-Deployments beschreibt stateless Services hinter einem Load Balancer, PostgreSQL für Keys, Teams, Spend-Logs und Konfiguration sowie Redis für gemeinsame Rate-Limits, Routing-State und Caching. Er empfiehlt mindestens zwei Replikas und einen eigenen Migrations-Job. Das ist die glaubwürdige Production-Basis, nicht eine öffentlich erreichbare Ein-Container-Compose-Datei.

Starte mit dem monolithischen Image, solange die getrennte Skalierung von Gateway, Backend und UI keinen gemessenen Engpass löst. Eine kleinere Architektur lässt sich leichter patchen und wiederherstellen. Komponenten helfen bei hohem Traffic oder strikter administrativer Trennung, erhöhen aber die Release-Koordination.

Wie deployst Du LiteLLM sicher?

1. Definiere den Gateway-Vertrag. Liste erlaubte Modell-Aliase, Provider und regionale Fallback-Reihenfolge, Budgets je Workload, erlaubte Endpunkte, Retention-Regeln und den Owner jedes Alerts. Ein gemeinsamer Endpoint ohne Policy zentralisiert nur das Risiko.
2. Beweise den Pfad in Staging. Starte einen gepinnten Container an einem privaten Endpoint, mounte eine versionierte config.yaml, injiziere Provider-Zugangsdaten über die Umgebung und sende einen Request mit dem normalen OpenAI-Client. Exponiere in Production weder main-latest noch Detailed-Debug-Logging.
3. Füge Postgres vor Team-Keys hinzu. Nutze eine private gemanagte Datenbank, verschlüsselte Verbindungen, automatische Backups und einen eigenen Migrations-Job. Halte Schemaänderungen aus Serving-Replikas heraus, damit ein Autoscaling-Event nicht mit einer Migration konkurriert.
4. Füge Redis vor der zweiten Replika hinzu. LiteLLMs Production-Checkliste empfiehlt Redis 7 oder neuer, sobald mehr als ein Proxy läuft. Ohne Shared State erzwingen Replikas Limits getrennt und Cache-Hits bleiben lokal. Skaliere in Kubernetes mit einem Worker pro Pod und CPU, nicht mit dauerhaft belegtem Prozessspeicher.
5. Vergib je Workload einen eigenen Virtual Key. Die Dokumentation zu Virtual Keys verlangt Postgres und unterstützt Modellzugriff, Budgets und Spend-Zuordnung. Setze Modell- und Routen-Allow-Lists ausdrücklich. Gib keiner Anwendung den Master Key und verlasse Dich nicht darauf, dass eine leere Liste keinen Zugriff bedeutet.
6. Setze das Gateway in ein privates Netz. Exponiere über TLS nur Request-Routen, die Clients brauchen. Lege Admin UI und Management-APIs hinter identitätsbasierten Zugriff oder einen eigenen administrativen Pfad. Begrenze Egress auf erlaubte Provider und Observability-Ziele.
7. Mache Updates reversibel. Teste Image, Konfiguration und Migrationen gegen eine Kopie des Production-Schemas, deploye einen Canary und spiele repräsentative Requests ab. Halte das vorige Image und ein kompatibles Datenbank-Backup für den Rollback bereit.
8. Übe Fehlerfälle. Deaktiviere nacheinander einen Provider, eine Gateway-Replika, Redis und Postgres. Prüfe erwarteten Fallback, Readiness, Alert, Recovery-Ziel und Client-Fehler. Ein nie getesteter Fallback ist Dokumentation, keine Resilienz.

Was hat sich 2026 bei der LiteLLM-Security geändert?

Security muss die Architektur prägen, weil der Proxy Modell-Zugangsdaten, Datenbankzugriff und Request-Inhalte halten kann. Im März 2026 erschienen die bösartigen LiteLLM-Versionen 1.82.7 und 1.82.8 auf PyPI. Laut Incident-Timeline des Projekts konnten die betroffenen Pakete Umgebungs- und Cloud-Zugangsdaten stehlen, während Nutzer der Proxy-Docker-Images nicht betroffen waren. Teams mit diesen Paketen sollten der Incident-Anleitung folgen und exponierte Zugangsdaten rotieren.

Getrennte Proxy-Schwachstellen erhöhten die Anforderungen zusätzlich. Eine kritische SQL-Injection in der API-Key-Prüfung betraf 1.81.16 bis 1.83.6. Eine Command-Injection in MCP-Test-Endpunkten betraf 1.74.2 bis 1.83.6. Eine spätere Rechteausweitung über Virtual Keys wurde in 1.83.14 behoben. Diese alten Fix-Versionen sind historische Untergrenzen, keine empfohlenen Deployment-Ziele.

Die praktische Antwort ist klar: Nutze einen aktuell unterstützten Stable Release, kein Prerelease und keinen alten Mindest-Patch. Am 13. August 2026 markierte GitHub v1.96.2 als neuesten Release und veröffentlichte auf der LiteLLM-Release-Seite einen cosign-Befehl zur Prüfung. Prüfe die Seite am Deployment-Tag erneut, pinne Version oder Digest exakt, verifiziere die Signatur, scanne das Image und promote denselben Digest durch alle Umgebungen.

Was muss vor dem Go-live wahr sein?

• Least Privilege ist ausdrücklich. Jede Workload hat einen eigenen Virtual Key, benannten Owner, erlaubte Modelle, Routen, Budget und Ablaufdatum. Der Master Key erreicht nie eine Anwendung.
• Secrets sind wiederherstellbar und getrennt. Provider Keys und Master Key liegen im Secret Store der Plattform. Der permanente LITELLM_SALT_KEY wird getrennt gesichert, weil eine Änderung nach dem Speichern von Credentials diese unlesbar macht.
• Das Netz schlägt geschlossen fehl. Admin-Routen sind privat, TLS-Prüfung bleibt aktiv, Provider-Egress ist begrenzt und Datenbank sowie Redis haben keine öffentliche Adresse. Diese Controls folgen LiteLLMs Security Best Practices.
• Logs haben eine Daten-Policy. Entscheide, ob Prompts und Antworten geloggt werden dürfen, redigiere sensible Felder vor dem Export, setze Retention, begrenze Zugriff und teste Löschung. Unser Guide zur PII-Redaktion vor LLM-Prompts behandelt diese Grenze.
• Health-Checks meinen verschiedene Dinge. LiteLLM dokumentiert unauthentifizierte Liveness- und Readiness-Endpunkte ohne Modellaufruf. Der authentifizierte Modell-Health-Endpunkt sendet dagegen echte Provider-Requests. Verdrahte Orchestrator-Probes und tiefere synthetische Checks nach dem Health-Check-Vertrag.
• Spend wird abgeglichen. Vergleiche LiteLLM-Zuordnung mit Provider-Rechnungen und teste Streaming, Retries, Cache-Hits und Fallback. Eine Dashboard-Schätzung hilft, Finance braucht aber einen Abgleichspfad.
• Ein Owner kann schnell patchen. Abonniere Security Advisories, definiere ein Patch-SLA, pflege eine Staging-Smoke-Suite und dokumentiere Credential-Rotation nach einem vermuteten Angriff.

Wie viel Arbeit verlangt selbst gehostetes LiteLLM?

Es gibt keinen ehrlichen Universalpreis, weil das Gateway Deine Cloud, Verfügbarkeitsziele, Identity-Plattform und Compliance übernimmt. Die folgenden Werte sind Wavect-Planungsgrößen fürs Scoping, keine LiteLLM-Angebote oder Versprechen zu Cloud-Preisen.

Bei moderatem Traffic entscheidet selten die Infrastrukturrechnung. Ownership entscheidet. Wenn niemand Patch- und Recovery-Pflicht übernehmen kann, ist ein Managed Gateway günstiger, selbst wenn die Rechnung höher ist. Betreibt ein Plattformteam bereits Kubernetes, Postgres, Redis, Secrets und Observability, kann LiteLLM in bestehende Controls passen.

Solltest Du LiteLLM selbst hosten oder ein Managed Gateway kaufen?

Hoste LiteLLM selbst, wenn Kontrolle eine Anforderung und Betrieb eine vorhandene Fähigkeit ist. Kaufe ein Managed Gateway, wenn Speed, Support und weniger Rufbereitschaft mehr wert sind als Infrastrukturkontrolle. Bleibe für einen engen Prototyp, der noch kein Gateway verdient, beim direkten Provider-Zugriff.

Ein brauchbarer Beschaffungstest kalkuliert ein Jahr, nicht einen Container. Nimm Design, Implementierung, Datenbank und Redis, Monitoring, Backups, Updates, Security Review, On-call und eine Provider-Migration auf. Vergleiche diese Summe mit der Managed-Option und den Kosten des Nichtstuns. Für die Optimierung nach dem Gateway hilft unser Playbook zur Reduktion von LLM-Token-Kosten.