--- title: "LiteLLM selbst hosten: Production-Guide 2026" canonical: https://wavect.io/de/blog/self-host-litellm-production-2026/ language: de description: "LiteLLM 2026 sicher selbst hosten: Docker oder Kubernetes, Postgres, Redis, Virtual Keys, Monitoring, Patching, Rollout-Kosten und Alternativen." image: "https://wavect.io/img/blog/headers/header_self-host-litellm-production-2026.png" --- [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 14 Min Lesezeit · 13. August 2026 [**Weiter**](/de/blog/linux-for-ai-agents/) # LiteLLM selbst hosten: Architektur- und Security-Guide für Production 2026 TL;DR LiteLLM selbst zu hosten heißt, das KI-Gateway zu betreiben, nicht automatisch die Modelle dahinter. Ein produktives Setup braucht mindestens zwei exakt gepinnte Gateway-Replikas hinter TLS, privates gemanagtes Postgres, Redis für gemeinsame Rate-Limits und Routing-State, begrenzte Virtual Keys, Secret Storage, Health-Probes, Metriken, Backups und einen getesteten Upgrade-Pfad. LiteLLM OSS kostet keine Lizenz, Infrastruktur und Rufbereitschaft bleiben aber echte Kosten. Der PyPI-Angriff und mehrere Proxy-Schwachstellen von 2026 machen exakte Versions-Pins, Image-Signaturprüfung, Netzwerkbegrenzung und schnelles Patching zu Go-live-Anforderungen. Starte mit einem Staging-Container und baue den resilienten Stack erst, wenn Kontrolle, Compliance oder Provider-Portabilität den Betriebsaufwand rechtfertigen. 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](https://docs.litellm.ai/) 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](/de/blog/llm-gateway-router-comparison-2026/) hilft Dir bei der Wahl zwischen LiteLLM, OpenRouter, Portkey oder einem Routing-Framework. Unser [Kosten-Guide für selbst gehostete LLMs in der EU](/de/blog/self-hosting-llms-eu-cost/) 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](https://www.litellm.ai/pricing). | Situation | Sinnvoller Default | Warum | | --- | --- | --- | | Ein Prototyp, ein Provider, kein Plattform-Owner | Provider direkt aufrufen | Ein Gateway wird zur weiteren Production-Abhängigkeit, bevor es ein echtes Problem löst. | | Mehrere Produkte oder Teams teilen Provider-Accounts | Self-Hosting kann sich lohnen | Begrenzte Keys, zentrale Budgets und eine Provider-Abstraktion schaffen einen klaren Kontrollpunkt. | | Delivery-Speed ist wichtiger als Infrastrukturkontrolle | Managed Gateway nutzen | Du kaufst Betrieb, Updates und Support, statt sie selbst zu bauen. | | Private Netze, EU-Deployment oder eigene Controls sind Pflicht | Self-Hosting evaluieren | Du wählst Netzwerk, Region, Logs, Retention und Deployment-Kadenz. | | Du brauchst zusätzlich lokale Modell-Inferenz | Gateway und Inferenz getrennt betreiben | LiteLLM routet Requests. vLLM, Ollama oder ein anderer Server führt das Modell aus. | ## Welche Architektur braucht ein produktives LiteLLM-Deployment? Der aktuelle [LiteLLM-Guide für Production-Deployments](https://docs.litellm.ai/docs/proxy/deploy) 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. | Schicht | Verantwortung in Production | Fehlerfrage | | --- | --- | --- | | TLS-Ingress oder Load Balancer | TLS terminieren, Routen begrenzen, Missbrauch drosseln und Replikas sauber drainen | Kann ein fehlerhafter Client Management-Endpunkte erreichen oder den Service auslasten? | | Mindestens zwei LiteLLM-Replikas | Traffic aus einer exakt gepinnten, signierten Image-Version bedienen | Unterbricht ein Rollout oder ein abgestürzter Pod laufende Streams? | | Managed PostgreSQL | Keys, Teams, Spend und Konfiguration mit Backups speichern | Kannst Du wiederherstellen, bevor das Gateway zum unternehmensweiten Ausfall wird? | | Managed Redis | Rate-Limits, Cache und Router-State zwischen Replikas teilen | Bleiben Limits korrekt, wenn Traffic auf verschiedenen Pods landet? | | Secret Store | Provider-Zugangsdaten, Master Key und permanenten Salt Key speichern | Kann eine Anwendung die Provider-Zugangsdaten einer anderen lesen? | | Metriken, Logs und Traces | Verfügbarkeit, Latenz, Spend, Fehler und Sättigung messen, ohne Prompts zu leaken | Erkennt der On-call, ob LiteLLM, Datenbank oder Provider ausgefallen ist? | 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](https://docs.litellm.ai/docs/proxy/prod) 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](https://docs.litellm.ai/docs/proxy/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](https://github.com/BerriAI/litellm/issues/24518) 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](https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc) betraf 1.81.16 bis 1.83.6. Eine [Command-Injection in MCP-Test-Endpunkten](https://github.com/BerriAI/litellm/security/advisories/GHSA-v4p8-mg3p-g94g) betraf 1.74.2 bis 1.83.6. Eine spätere [Rechteausweitung über Virtual Keys](https://github.com/advisories/GHSA-qrc4-49gv-mv9m) 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](https://github.com/BerriAI/litellm/releases) 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](https://docs.litellm.ai/docs/proxy/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](/de/blog/pii-redaction-before-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](https://docs.litellm.ai/docs/proxy/health). - **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. | Deployment-Level | Typischer Engineering-Aufwand | Enthalten | | --- | --- | --- | | Privates Staging-Gateway | 1 bis 3 Engineering-Tage | Gepinnter Container, zwei Provider, Config, ein Virtual Key, Basis-Logs und Smoke-Tests | | Single-Region-Production-Basis | 1 bis 3 Engineering-Wochen | Replikas, TLS, Managed Postgres und Redis, Secret Store, Budgets, Metriken, Backups, Canary-Rollout und Runbook | | Regulierte oder Multi-Team-Plattform | 4 bis 10 Engineering-Wochen | Identity-Integration, Tenant-Policy, Audit-Evidenz, Datenschutz, Disaster Recovery, Lasttests und Support-Übergabe | | Laufender Betrieb | Benannte monatliche Kapazität plus On-call | Patches, Provider-Änderungen, Cost-Map-Prüfung, Incident Response, Access Reviews und Restore-Übungen | 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](/de/blog/reduce-llm-token-costs-2026/). ## Häufige Fragen ### Ist LiteLLM beim Self-Hosting kostenlos? Das Open-Source-Gateway hat keine Lizenzgebühr. Du bezahlst trotzdem Compute, PostgreSQL, Redis, Traffic, Observability, Backups, Modell-Provider und die Menschen, die das System patchen und betreiben. Enterprise-Governance und Support werden getrennt bepreist. ### Bleiben Prompts beim selbst gehosteten LiteLLM auf meinen Servern? Der Prompt läuft durch Dein Gateway, verlässt es für einen gehosteten Provider aber weiterhin, außer das gewählte Modell läuft in Deiner Infrastruktur. Prüfe den ganzen Pfad inklusive Logs, Callbacks, Provider-Retention und Backups. ### Kann LiteLLM ohne Kubernetes in Docker laufen? Ja. Docker eignet sich für Entwicklung, Staging und bestimmte VM-Deployments. Production braucht trotzdem mehrere Prozesse oder Replikas, TLS, Postgres, Redis, Health-Checks, Backups, Monitoring und einen sicheren Release-Prozess. Kubernetes ist ein Weg zu diesen Controls, nicht das Ziel selbst. ### Braucht LiteLLM Postgres und Redis? Postgres ist für Proxy-Authentifizierung, Virtual Keys und Spend-Tracking nötig. Redis wird erforderlich, wenn mehrere Proxy-Instanzen Rate-Limits, Routing-State und Cache teilen müssen. Ein minimales stateless Experiment kann ohne die volle Datenschicht laufen, ist aber kein Multi-Team-Production-Design. ### Welche LiteLLM-Version sollte ich deployen? Nutze den aktuell unterstützten Stable Release, pinne Image-Tag oder Digest exakt, prüfe die Signatur und teste vor der Promotion. Nutze keine beweglichen Tags und behandle eine alte Mindest-Fix-Version nicht als aktuelle Empfehlung. ### Wann sollte ich eine Managed-Alternative wählen? Wähle Managed, wenn kein Team Gateway-Patches, Recovery und On-call besitzt oder Time-to-Market wichtiger als private Infrastrukturkontrolle ist. Prüfe Self-Hosting erneut, wenn Compliance, Netzwerk, Provider-Portabilität oder Scale einen konkreten Business Case schaffen. ## Fazit Selbst gehostetes LiteLLM ist ein kleiner Service mit großem Blast Radius. Der Container ist leicht. Production ist die Disziplin darum herum: privates Netz, exakt gepinnte signierte Releases, begrenzte Keys, Postgres, Redis, Metriken, Backups, Fehlerübungen und ein Owner, der schnell patchen kann. Nutze LiteLLM, wenn ein kontrolliertes Gateway mehrere Produkte und Provider vereinfacht. Behandle Modell-Inferenz als eigene Architekturentscheidung. Wenn Dein Team das Gateway nicht durch einen Incident und Restore tragen kann, kaufe den Betrieb als Managed Service. Wenn es das kann, starte mit einem engen Staging-Vertrag, beweise Resilienz und erweitere nur aus Evidenz. ## Das könnte dich auch interessieren.. [**LLM-Gateways im Vergleich 2026** Wähle zwischen LiteLLM, OpenRouter, Portkey und RouteLLM, bevor Du Dich auf ein Betriebsmodell festlegst.](/de/blog/llm-gateway-router-comparison-2026/) [**Security-Fragebogen für EU-KI-Anbieter** Mach aus Aussagen zu Security, Datenschutz, Retention und Incident Response überprüfbare Evidenzfragen.](/de/blog/ai-vendor-security-questionnaire-eu/) Modelle und Infrastruktur ## In diesem Cluster weiterlesen Modellauswahl, Inferenzkosten, lokaler Betrieb, Kompression und Serving-Architektur. [Mit dem Grundlagenartikel starten**LLMs in der EU selbst hosten: Wann sich Open Weights wirklich rechnen**](/de/blog/self-hosting-llms-eu-cost/) - [KI-fähiges Unternehmenswiki: Architektur und Aufbau](/de/blog/ai-ready-company-wiki/) - [Versieht Claude Texte mit Wasserzeichen? API-Antwort 2026](/de/blog/claude-text-watermark-api-2026/) - [OpenKB Review: Knowledge Compiler vs. RAG](/de/blog/openkb-review-vs-rag/) - [Unsloth Desktop im Test: Private lokale KI-Workstation?](/de/blog/unsloth-desktop-local-ai-workstation-review/) - [NeMo Switchyard 0.2: Agenten-Routing ohne Training?](/de/blog/nemo-switchyard-model-router/) Postfach, ohne Lärm ## Folge der Arbeit, die für dich zählt Du bekommst eine kurze E-Mail, wenn wir etwas Neues veröffentlichen. Folge dem ganzen Blog oder nur den Themen, die dich interessieren. [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 14 Min Lesezeit · 13. August 2026 [**Weiter**](/de/blog/linux-for-ai-agents/) Neue Beiträge per E-Mail × × Neue Beiträge per E-Mail Eine kurze E-Mail, wenn wir etwas veröffentlichen. Kostenlos, ohne Tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/self-host-litellm-production-2026/#webpage", "@type": "WebPage", "dateModified": "2026-08-13", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-13", "url": "https://wavect.io/de/blog/self-host-litellm-production-2026/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "LiteLLM selbst zu hosten heißt, das KI-Gateway zu betreiben, nicht automatisch die Modelle dahinter. Ein produktives Setup braucht mindestens zwei exakt gepinnte Gateway-Replikas hinter TLS, privates gemanagtes Postgres, Redis für gemeinsame Rate-Limits und Routing-State, begrenzte Virtual Keys, Secret Storage, Health-Probes, Metriken, Backups und einen getesteten Upgrade-Pfad. LiteLLM OSS kostet keine Lizenz, Infrastruktur und Rufbereitschaft bleiben aber echte Kosten. Der PyPI-Angriff und mehrere Proxy-Schwachstellen von 2026 machen exakte Versions-Pins, Image-Signaturprüfung, Netzwerkbegrenzung und schnelles Patching zu Go-live-Anforderungen. Starte mit einem Staging-Container und baue den resilienten Stack erst, wenn Kontrolle, Compliance oder Provider-Portabilität den Betriebsaufwand rechtfertigen.", "articleBody": " Blog-Übersicht/AI und Agents/Modelle und Infrastruktur LiteLLM selbst hosten: Architektur- und Security-Guide für Production 2026 TL;DR LiteLLM selbst zu hosten heißt, das KI-Gateway zu betreiben, nicht automatisch die Modelle dahinter. Ein produktives Setup braucht mindestens zwei exakt gepinnte Gateway-Replikas hinter TLS, privates gemanagtes Postgres, Redis für gemeinsame Rate-Limits und Routing-State, begrenzte Virtual Keys, Secret Storage, Health-Probes, Metriken, Backups und einen getesteten Upgrade-Pfad. LiteLLM OSS kostet keine Lizenz, Infrastruktur und Rufbereitschaft bleiben aber echte Kosten. Der PyPI-Angriff und mehrere Proxy-Schwachstellen von 2026 machen exakte Versions-Pins, Image-Signaturprüfung, Netzwerkbegrenzung und schnelles Patching zu Go-live-Anforderungen. Starte mit einem Staging-Container und baue den resilienten Stack erst, wenn Kontrolle, Compliance oder Provider-Portabilität den Betriebsaufwand rechtfertigen. 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. SituationSinnvoller DefaultWarum Ein Prototyp, ein Provider, kein Plattform-OwnerProvider direkt aufrufenEin Gateway wird zur weiteren Production-Abhängigkeit, bevor es ein echtes Problem löst. Mehrere Produkte oder Teams teilen Provider-AccountsSelf-Hosting kann sich lohnenBegrenzte Keys, zentrale Budgets und eine Provider-Abstraktion schaffen einen klaren Kontrollpunkt. Delivery-Speed ist wichtiger als InfrastrukturkontrolleManaged Gateway nutzenDu kaufst Betrieb, Updates und Support, statt sie selbst zu bauen. Private Netze, EU-Deployment oder eigene Controls sind PflichtSelf-Hosting evaluierenDu wählst Netzwerk, Region, Logs, Retention und Deployment-Kadenz. Du brauchst zusätzlich lokale Modell-InferenzGateway und Inferenz getrennt betreibenLiteLLM routet Requests. vLLM, Ollama oder ein anderer Server führt das Modell aus. 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. SchichtVerantwortung in ProductionFehlerfrage TLS-Ingress oder Load BalancerTLS terminieren, Routen begrenzen, Missbrauch drosseln und Replikas sauber drainenKann ein fehlerhafter Client Management-Endpunkte erreichen oder den Service auslasten? Mindestens zwei LiteLLM-ReplikasTraffic aus einer exakt gepinnten, signierten Image-Version bedienenUnterbricht ein Rollout oder ein abgestürzter Pod laufende Streams? Managed PostgreSQLKeys, Teams, Spend und Konfiguration mit Backups speichernKannst Du wiederherstellen, bevor das Gateway zum unternehmensweiten Ausfall wird? Managed RedisRate-Limits, Cache und Router-State zwischen Replikas teilenBleiben Limits korrekt, wenn Traffic auf verschiedenen Pods landet? Secret StoreProvider-Zugangsdaten, Master Key und permanenten", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "offizielle Dokumentation", "url": "https://docs.litellm.ai/" }, { "@type": "WebPage", "name": "LiteLLM-Preisseite", "url": "https://www.litellm.ai/pricing" }, { "@type": "WebPage", "name": "LiteLLM-Guide für Production-Deployments", "url": "https://docs.litellm.ai/docs/proxy/deploy" }, { "@type": "WebPage", "name": "Production-Checkliste", "url": "https://docs.litellm.ai/docs/proxy/prod" }, { "@type": "WebPage", "name": "Dokumentation zu Virtual Keys", "url": "https://docs.litellm.ai/docs/proxy/virtual_keys" }, { "@type": "WebPage", "name": "Incident-Timeline des Projekts", "url": "https://github.com/BerriAI/litellm/issues/24518" }, { "@type": "WebPage", "name": "SQL-Injection in der API-Key-Prüfung", "url": "https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc" }, { "@type": "WebPage", "name": "Command-Injection in MCP-Test-Endpunkten", "url": "https://github.com/BerriAI/litellm/security/advisories/GHSA-v4p8-mg3p-g94g" }, { "@type": "WebPage", "name": "Rechteausweitung über Virtual Keys", "url": "https://github.com/advisories/GHSA-qrc4-49gv-mv9m" }, { "@type": "WebPage", "name": "LiteLLM-Release-Seite", "url": "https://github.com/BerriAI/litellm/releases" }, { "@type": "WebPage", "name": "Security Best Practices", "url": "https://docs.litellm.ai/docs/proxy/security_best_practices" }, { "@type": "WebPage", "name": "Health-Check-Vertrag", "url": "https://docs.litellm.ai/docs/proxy/health" } ], "dateModified": "2026-08-13", "datePublished": "2026-08-13", "description": "LiteLLM selbst zu hosten heißt, das KI-Gateway zu betreiben, nicht automatisch die Modelle dahinter. Ein produktives Setup braucht mindestens zwei exakt gepinnte Gateway-Replikas hinter TLS, privates gemanagtes Postgres, Redis für gemeinsame Rate-Limits und Routing-State, begrenzte Virtual Keys, Secret Storage, Health-Probes, Metriken, Backups und einen getesteten Upgrade-Pfad. LiteLLM OSS kostet keine Lizenz, Infrastruktur und Rufbereitschaft bleiben aber echte Kosten. Der PyPI-Angriff und mehrere Proxy-Schwachstellen von 2026 machen exakte Versions-Pins, Image-Signaturprüfung, Netzwerkbegrenzung und schnelles Patching zu Go-live-Anforderungen. Starte mit einem Staging-Container und baue den resilienten Stack erst, wenn Kontrolle, Compliance oder Provider-Portabilität den Betriebsaufwand rechtfertigen.", "headline": "LiteLLM selbst hosten: Production-Guide 2026", "image": "https://wavect.io/img/blog/headers/header_self-host-litellm-production-2026.svg", "inLanguage": "de", "keywords": "LiteLLM, KI-Infrastruktur, LLM-Gateway, Self-Hosting", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/self-host-litellm-production-2026/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/self-host-litellm-production-2026/", "wordCount": 2114 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/ai-agents/", "name": "AI und Agents", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/models-infrastructure/", "name": "Modelle und Infrastruktur", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/self-host-litellm-production-2026/", "name": "LiteLLM selbst hosten: Production-Guide 2026 | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Das Open-Source-Gateway hat keine Lizenzgebühr. Du bezahlst trotzdem Compute, PostgreSQL, Redis, Traffic, Observability, Backups, Modell-Provider und die Menschen, die das System patchen und betreiben. Enterprise-Governance und Support werden getrennt bepreist." }, "name": "Ist LiteLLM beim Self-Hosting kostenlos?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Der Prompt läuft durch Dein Gateway, verlässt es für einen gehosteten Provider aber weiterhin, außer das gewählte Modell läuft in Deiner Infrastruktur. Prüfe den ganzen Pfad inklusive Logs, Callbacks, Provider-Retention und Backups." }, "name": "Bleiben Prompts beim selbst gehosteten LiteLLM auf meinen Servern?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Ja. Docker eignet sich für Entwicklung, Staging und bestimmte VM-Deployments. Production braucht trotzdem mehrere Prozesse oder Replikas, TLS, Postgres, Redis, Health-Checks, Backups, Monitoring und einen sicheren Release-Prozess. Kubernetes ist ein Weg zu diesen Controls, nicht das Ziel selbst." }, "name": "Kann LiteLLM ohne Kubernetes in Docker laufen?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Postgres ist für Proxy-Authentifizierung, Virtual Keys und Spend-Tracking nötig. Redis wird erforderlich, wenn mehrere Proxy-Instanzen Rate-Limits, Routing-State und Cache teilen müssen. Ein minimales stateless Experiment kann ohne die volle Datenschicht laufen, ist aber kein Multi-Team-Production-Design." }, "name": "Braucht LiteLLM Postgres und Redis?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nutze den aktuell unterstützten Stable Release, pinne Image-Tag oder Digest exakt, prüfe die Signatur und teste vor der Promotion. Nutze keine beweglichen Tags und behandle eine alte Mindest-Fix-Version nicht als aktuelle Empfehlung." }, "name": "Welche LiteLLM-Version sollte ich deployen?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Wähle Managed, wenn kein Team Gateway-Patches, Recovery und On-call besitzt oder Time-to-Market wichtiger als private Infrastrukturkontrolle ist. Prüfe Self-Hosting erneut, wenn Compliance, Netzwerk, Provider-Portabilität oder Scale einen konkreten Business Case schaffen." }, "name": "Wann sollte ich eine Managed-Alternative wählen?" } ] } ```