LiteLLM Proxy: 1 API für 100+ LLMs (15-Minuten-Docker-Setup)

LiteLLM Proxy Setup: Schlüssel, Kosten und Rate Limits

Ihr Team teilt OpenAI-API-Schlüssel in Slack-DMs. Niemand weiß, wer letzten Dienstag 400 € ausgegeben hat. Es gibt kein Rate Limiting, keinen Fallback wenn ein Anbieter ausfällt, und ein Wechsel von GPT-4o zu Claude erfordert Codeänderungen an zwölf Stellen. Klingt bekannt? Ein selbst gehostetes LLM-Gateway behebt all das, und der LiteLLM-Proxy ist die beliebteste Open-Source-Option -- ein einzelner OpenAI-kompatibler Endpunkt, der Anfragen an 100+ LLM-Anbieter weiterleitet.

Diese Anleitung deckt das vollständige LiteLLM Proxy Setup ab: Docker Compose mit PostgreSQL, virtuelle Team-Schlüssel mit Budgets, Kostenverfolgung, Rate Limits und die Verbindung von KI-IDEs wie Claude Code und Cursor. Wenn Sie LLM-Gateway-Tools evaluieren, ist dies das praktische Tutorial von null bis zur Produktion.

Ein wichtiger Hinweis vorab: LiteLLMs SDK (die Python-Bibliothek) und der Proxy-Server sind verschiedene Dinge. Das SDK ist für einzelne Entwickler, die mehrere LLM-APIs aus Python aufrufen. Der Proxy ist für Teams -- er sitzt als Server zwischen Ihren Apps und LLM-Anbietern. Wenn Sie ein Solo-Entwickler sind, der ein Skript schreibt, reicht das SDK. Wenn Sie Schlüssel, Budgets und Zugriff für ein Team verwalten, benötigen Sie den Proxy. Das ist es, was wir hier einrichten.

LiteLLM Proxy auf einen Blick

So unterscheiden sich die Deployment-Methoden:

Für die meisten Teams ist Docker Compose mit PostgreSQL der goldene Mittelweg. Das werden wir aufbauen -- aber zuerst lassen wir einen Proxy in 60 Sekunden laufen.

Voraussetzungen und Umgebungseinrichtung

Bevor Sie beginnen, stellen Sie sicher, dass Sie Folgendes haben:

• Docker und Docker Compose installiert (Docker Desktop enthält beides)
• Mindestens einen LLM-API-Schlüssel (OpenAI, Anthropic oder eine lokale Ollama-Instanz)
• Grundlegende Terminal-/CLI-Kenntnisse

Docker-Bereitschaft prüfen und API-Schlüssel exportieren:

# Docker-Installation prüfen
docker --version
docker compose version

# LLM-API-Schlüssel exportieren (zum Shell-Profil hinzufügen für Persistenz)
export OPENAI_API_KEY="sk-..."
export ANTHROPIC_API_KEY="sk-ant-..."

# Optional: einen Master-Schlüssel für Ihren Proxy festlegen (wird später benötigt)
export LITELLM_MASTER_KEY="sk-master-ihr-geheimer-schlüssel"

Das war's. Keine spezielle Python-Version, keine betriebssystemspezifischen Tools. Wenn Docker auf Ihrem Rechner läuft, sind Sie startklar.

Schnellstart -- Ihr erster LiteLLM Proxy in 60 Sekunden

Ein Befehl, um einen Proxy mit GPT-4o zu starten:

docker run -d \
  --name litellm-proxy \
  -p 4000:4000 \
  -e OPENAI_API_KEY=$OPENAI_API_KEY \
  -e LITELLM_MASTER_KEY=$LITELLM_MASTER_KEY \
  ghcr.io/berriai/litellm:main-stable \
  --model openai/gpt-4o

Mit curl testen:

curl http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o",
    "messages": [{"role": "user", "content": "Say hello from LiteLLM"}]
  }'

Oder aus Python testen:

from openai import OpenAI

# Das Standard-OpenAI-SDK auf Ihren Proxy zeigen
client = OpenAI(
    api_key="sk-master-ihr-geheimer-schlüssel",
    base_url="http://localhost:4000/v1"
)

response = client.chat.completions.create(
    model="openai/gpt-4o",
    messages=[{"role": "user", "content": "Say hello from LiteLLM"}]
)
print(response.choices[0].message.content)

Was ist gerade passiert? Ihr Code spricht mit localhost:4000 über das Standard-OpenAI-SDK-Format. Der Proxy empfängt die Anfrage, leitet sie mit dem echten Schlüssel an OpenAIs API weiter und gibt die Antwort zurück. Ihr Anwendungscode berührt den eigentlichen API-Schlüssel nie.

Das ist der Kerngedanke. Jetzt bauen wir ein Produktions-Setup.

Produktions-Docker-Compose-Setup mit PostgreSQL

Der einzelne docker run-Befehl funktioniert zum Testen, aber Produktionsteams benötigen persistente Kostenverfolgung, virtuelle Schlüssel und ordentliche Datenbankspeicherung. Das bedeutet Docker Compose mit PostgreSQL.

Die Docker Compose-Datei

# docker-compose.yml
version: "3.9"

services:
  litellm:
    image: ghcr.io/berriai/litellm:main-stable
    container_name: litellm-proxy
    ports:
      - "4000:4000"         # Proxy-API-Port
    volumes:
      - ./config.yaml:/app/config.yaml   # Konfigurationsdatei einbinden
    environment:
      - LITELLM_MASTER_KEY=${LITELLM_MASTER_KEY}
      - OPENAI_API_KEY=${OPENAI_API_KEY}
      - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
      - DATABASE_URL=postgresql://litellm:litellm_password@postgres:5432/litellm
      - LITELLM_SALT_KEY=${LITELLM_SALT_KEY:-sk-salt-random-string}
    command: --config /app/config.yaml --detailed_debug
    depends_on:
      postgres:
        condition: service_healthy
    restart: unless-stopped

  postgres:
    image: postgres:16-alpine
    container_name: litellm-db
    environment:
      POSTGRES_DB: litellm
      POSTGRES_USER: litellm
      POSTGRES_PASSWORD: litellm_password
    volumes:
      - litellm_pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U litellm"]
      interval: 5s
      timeout: 5s
      retries: 5
    restart: unless-stopped

volumes:
  litellm_pgdata:

Der LITELLM_SALT_KEY verschlüsselt virtuelle Schlüsseldaten in der Datenbank. Die LiteLLM-Produktions-Best-Practices-Dokumentation empfiehlt, dies für jedes Team-Deployment zu setzen.

Den Stack starten

# Eine .env-Datei mit Ihren Schlüsseln erstellen (nicht ins Git einchecken)
echo "LITELLM_MASTER_KEY=sk-master-ihr-geheimnis" > .env
echo "OPENAI_API_KEY=sk-..." >> .env
echo "ANTHROPIC_API_KEY=sk-ant-..." >> .env
echo "LITELLM_SALT_KEY=sk-salt-$(openssl rand -hex 16)" >> .env

# Alles starten
docker compose up -d

# Logs prüfen
docker compose logs -f litellm

Alles überprüfen

# Gesundheitscheck
curl http://localhost:4000/health

# Eine Anfrage testen
curl http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "gpt-4o", "messages": [{"role": "user", "content": "ping"}]}'

Wenn Sie eine erfolgreiche Antwort sehen, läuft Ihr Produktions-Stack. PostgreSQL speichert alle Kostendaten, virtuellen Schlüssel und Nutzungsmetriken über Container-Neustarts hinweg.

Fazit: Docker Compose + PostgreSQL ist das empfohlene Produktions-Setup. Es gibt Ihnen persistenten Speicher, Kostenverfolgung und virtuelle Schlüssel mit etwa 10 Minuten Arbeit. Die Docker Deployment-Dokumentation deckt Kubernetes und Helm ab, falls Sie später Auto-Skalierung benötigen.

Config.yaml-Erklärung -- Ein echtes Multi-Provider-Setup

Die meisten Tutorials zeigen eine config.yaml mit einem Modell. Hier sieht eine echte Team-Konfiguration mit drei Anbietern, Fallbacks und Load Balancing aus.

Die Konfigurationsdatei

# config.yaml -- Echtes Multi-Provider-Setup
model_list:
  # Primär: OpenAI GPT-4o
  - model_name: gpt-4o          # Der Name, den IHR Code verwendet
    litellm_params:
      model: openai/gpt-4o      # Der tatsächliche Anbieter/Modell
      api_key: os.environ/OPENAI_API_KEY

  # Sekundär: Anthropic Claude
  - model_name: claude-sonnet
    litellm_params:
      model: anthropic/claude-sonnet-4-20250514
      api_key: os.environ/ANTHROPIC_API_KEY

  # Lokal: Ollama für Entwicklung / kostenfreies Testen
  - model_name: local-llama
    litellm_params:
      model: ollama/llama3.1
      api_base: http://host.docker.internal:11434

  # Fallback: "gpt-4o" zu Claude routen, wenn OpenAI ausgefallen ist
  - model_name: gpt-4o
    litellm_params:
      model: anthropic/claude-sonnet-4-20250514
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  routing_strategy: least-busy    # Last auf Modelle mit gleichem Namen verteilen
  num_retries: 3
  retry_after: 5                  # Sekunden zwischen Wiederholungsversuchen
  fallbacks: [{"gpt-4o": ["claude-sonnet"]}]

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  database_url: os.environ/DATABASE_URL

Modell-Aliase und Routing

Beachten Sie, dass gpt-4o zweimal in der Konfiguration erscheint -- einmal zeigt es auf OpenAI, einmal auf Anthropic. Wenn Ihr Code gpt-4o anfordert, versucht LiteLLM zuerst OpenAI. Wenn das fehlschlägt, leitet die fallbacks-Einstellung automatisch zu Claude weiter. Ihr Anwendungscode ändert sich überhaupt nicht.

Wenn Sie Produktionsinferenz-Backends wie vLLM oder SGLang verwenden, können Sie sie auf dieselbe Weise hinzufügen -- setzen Sie einfach die api_base auf Ihren Inferenz-Server.

Anbieter-Schnellreferenz

Die Einstellung routing_strategy: least-busy verteilt Anfragen auf Modelle mit demselben model_name. Wenn Sie zwei OpenAI-Schlüssel haben (vielleicht verschiedene Organisationen mit unterschiedlichen Rate Limits), listen Sie beide unter gpt-4o auf und LiteLLM balanciert die Last.

Virtuelle Schlüssel -- Team-API-Schlüssel mit Budgets und Rate Limits

Hier hört LiteLLM auf, "nur ein Proxy" zu sein, und wird zu einem Team-Management-Tool. Virtuelle Schlüssel ermöglichen es Ihnen, jedem Teammitglied oder Service seinen eigenen API-Schlüssel mit Ausgabenlimits und Rate Caps zu geben -- alles über Ihren einzigen Satz von Anbieter-API-Schlüsseln geleitet.

Einen Team-Schlüssel mit Budget erstellen

# Einen virtuellen Schlüssel mit einem Budget von 50 $/Monat erstellen
curl http://localhost:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "team_id": "frontend-team",
    "max_budget": 50.0,
    "budget_duration": "1mo",
    "models": ["gpt-4o", "claude-sonnet"],
    "metadata": {"purpose": "frontend AI features"}
  }'

Die Antwort gibt Ihnen einen neuen Schlüssel wie sk-team-abc123.... Geben Sie diesen dem Frontend-Team. Sie können ihn genau wie einen OpenAI-Schlüssel verwenden, aber er ist auf 50 $/Monat begrenzt und hat nur Zugriff auf die von Ihnen angegebenen Modelle.

Rate Limits festlegen

# Einen Schlüssel mit Rate Limits erstellen: 100 Anfragen/Minute, 50K Token/Minute
curl http://localhost:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "team_id": "backend-team",
    "max_budget": 200.0,
    "budget_duration": "1mo",
    "rpm_limit": 100,
    "tpm_limit": 50000,
    "models": ["gpt-4o", "claude-sonnet", "local-llama"]
  }'

Die Dokumentation zu virtuellen Schlüsseln deckt jeden Parameter ab. Sie können auch Budgets und Rate Limits pro Benutzer für noch granularere Kontrolle festlegen.

Schlüsselnutzung überwachen

import requests

# Aktuellen Verbrauch und Limits eines Schlüssels prüfen
response = requests.get(
    "http://localhost:4000/key/info",
    headers={"Authorization": f"Bearer {MASTER_KEY}"},
    params={"key": "sk-team-abc123..."}
)
info = response.json()
print(f"Ausgegeben: ${info['spend']:.2f} / ${info['max_budget']:.2f}")
print(f"RPM verwendet: {info['rpm_limit_used']} / {info['rpm_limit']}")

Müssen Sie einen kompromittierten Schlüssel widerrufen? Ein API-Aufruf:

curl -X POST http://localhost:4000/key/delete \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"keys": ["sk-team-abc123..."]}'

Fazit: Virtuelle Schlüssel machen LiteLLM zu einem Team-Tool, nicht nur zu einem persönlichen Proxy. Ohne sie fügen Sie nur einen Hop zwischen Ihrem Code und dem LLM hinzu. Mit ihnen haben Sie Zugriffskontrolle, Budgetdurchsetzung und Nutzungszuordnung -- die Art von Dinge, die Ihren CFO davon abhält, in Panik zu geraten.

Kostenverfolgung und das LiteLLM-Dashboard

Sobald PostgreSQL verbunden ist, verfolgt LiteLLM die Kosten jeder Anfrage automatisch. Sie müssen nichts konfigurieren -- es kennt die Pro-Token-Preise für jedes unterstützte Modell.

Das Dashboard

Greifen Sie auf die integrierte Oberfläche unter http://localhost:4000/ui zu (mit Ihrem Master-Schlüssel anmelden). Sie sehen:

• Gesamtausgaben über alle Teams und Schlüssel
• Pro-Modell-Aufschlüsselung -- welche Modelle Ihr Budget auffressen
• Pro-Team-Ausgaben -- wer was verwendet
• Anfragevolumen im Zeitverlauf

Für Teams, die ernsthaft daran interessiert sind, LLM-API-Kosten zu reduzieren, rechtfertigt das Dashboard allein den Betrieb des Proxys. Sie können LiteLLM auch mit externen KI-Observability-Plattformen wie Langfuse oder Helicone für tiefere Analysen verbinden.

Pro-Anbieter-Kostenvergleich

Hier sind die Kosten der wichtigsten Modelle pro Million Token (Stand April 2026):

Wenn Sie diese Zahlen im Dashboard aufgeschlüsselt nach Team sehen, werden die Gespräche über "Sollten wir für diesen Anwendungsfall ein günstigeres Modell verwenden?" sehr konkret.

Fazit: Kostenverfolgung allein rechtfertigt den Proxy für jedes Team, das mehr als 100 $/Monat für LLM-APIs ausgibt. Sie können nicht optimieren, was Sie nicht messen.

KI-IDEs verbinden -- Claude Code, Cursor und Continue

Hier ist etwas, das die meisten LiteLLM-Anleitungen völlig überspringen: Sie können Ihre KI-Coding-Tools auch auf den Proxy zeigen. Ein Proxy, alle Ihre IDE-Tools, einheitliche Abrechnung.

Claude Code

# Claude Code auf Ihren LiteLLM-Proxy setzen
export ANTHROPIC_BASE_URL=http://localhost:4000/v1
export ANTHROPIC_API_KEY=sk-team-ihr-virtueller-schlüssel

Das war's. Claude Code sendet Anfragen an Ihren Proxy, der sie an Anthropic weiterleitet (oder wohin Ihre Konfiguration sagt) und dabei Kosten unter Ihrem virtuellen Schlüssel verfolgt.

Cursor

In den Cursor-Einstellungen einen benutzerdefinierten OpenAI-kompatiblen Endpunkt hinzufügen:

{
  "openai.apiBaseUrl": "http://localhost:4000/v1",
  "openai.apiKey": "sk-team-ihr-virtueller-schlüssel"
}

Continue (VS Code)

In Continues config.json:

{
  "models": [
    {
      "title": "GPT-4o über LiteLLM",
      "provider": "openai",
      "model": "gpt-4o",
      "apiBase": "http://localhost:4000/v1",
      "apiKey": "sk-team-ihr-virtueller-schlüssel"
    }
  ]
}

Warum der Aufwand? Weil jetzt die IDE-Nutzung jedes Entwicklers durch den Proxy läuft. Sie erhalten Pro-Person-Kostenverfolgung für KI-Coding-Assistenten, Rate Limits damit niemand versehentlich 500 € in einer Coding-Session verbrennt, und einen einzigen Ort zum Wechseln von Modellen, wenn Sie eine bessere Option finden.

Fehlerbehebung bei häufigen Problemen

"Konfigurationsdatei nicht gefunden"

Dies bedeutet normalerweise, dass der Volume-Mount-Pfad in Docker falsch ist. Stellen Sie sicher, dass Ihre config.yaml in dem Verzeichnis liegt, aus dem Sie mounten:

# Prüfen ob die Datei existiert, wo Sie denken
ls -la ./config.yaml

# Der Volume-Mount in docker-compose.yml sollte übereinstimmen
# volumes:
#   - ./config.yaml:/app/config.yaml

"Verbindung abgelehnt" zu PostgreSQL

Docker-Netzwerke erwischen jeden mindestens einmal. Wenn LiteLLM Postgres nicht erreichen kann, prüfen Sie:

• Der Service-Name in DATABASE_URL stimmt mit dem Docker Compose-Service-Namen überein (postgres, nicht localhost)
• Das depends_on mit condition: service_healthy ist gesetzt (damit LiteLLM wartet bis Postgres bereit ist)
• Beide Services sind im selben Docker-Netzwerk (sie sind es standardmäßig in Compose)

"Ungültiges API-Schlüssel-Format"

Die häufigste Verwechslung: Ihr LITELLM_MASTER_KEY ist für Admin-Operationen (virtuelle Schlüssel erstellen, auf das Dashboard zugreifen). Virtuelle Schlüssel (sk-team-...) sind das, was Ihre Anwendungen verwenden. Verwechseln Sie sie nicht.

"Modell nicht gefunden"

Das model-Feld in Ihrer Anfrage muss mit einem model_name in config.yaml übereinstimmen. Wenn Ihre Konfiguration gpt-4o definiert, Ihr Code aber openai/gpt-4o anfordert, stimmt es nicht überein. Überprüfen Sie die genaue Schreibweise.

Proxy startet aber Anfragen hängen

Normalerweise ein Firewall- oder Port-Binding-Problem. Prüfen Sie ob Port 4000 freigegeben und nicht blockiert ist:

# Prüfen ob der Port lauscht
docker port litellm-proxy
# Sollte zeigen: 4000/tcp -> 0.0.0.0:4000

Sicherheit: Versionen 1.82.7 und 1.82.8 vermeiden

Im März 2026 betraf ein Supply-Chain-Vorfall die LiteLLM-Versionen 1.82.7 und 1.82.8. Die kompromittierten Versionen wurden zurückgezogen, und ein sauberes Release kam bei 1.83.0 heraus. Pinnen Sie immer Ihr Docker-Image auf eine bestimmte Version und prüfen Sie das offizielle Sicherheitsupdate vor dem Upgrade. Wenn Sie auf 1.82.7 oder 1.82.8 sind, aktualisieren Sie sofort.

Welche LiteLLM-Einrichtungsmethode sollten Sie wählen?

Wenn Sie diese Anleitung zum ersten Mal lesen, beginnen Sie mit Docker Compose + PostgreSQL. Sie können später immer zu Kubernetes migrieren -- die config.yaml bleibt dieselbe.

FAQ

Was ist der LiteLLM-Proxy und wie funktioniert er?

Der LiteLLM-Proxy ist ein Open-Source-KI-Gateway-Server, der zwischen Ihren Anwendungen und LLM-Anbietern wie OpenAI und Anthropic sitzt. Er stellt einen einzigen OpenAI-kompatiblen Endpunkt bereit, sodass Ihr Code mit einer URL kommuniziert, während der Proxy Routing, Schlüsselverwaltung, Kostenverfolgung und Fallbacks im Hintergrund handhabt.

Wie richte ich den LiteLLM-Proxy mit Docker Compose ein?

Erstellen Sie eine docker-compose.yml mit dem LiteLLM-Proxy-Image und einer PostgreSQL-Datenbank, binden Sie Ihre config.yaml ein, setzen Sie Ihre API-Schlüssel als Umgebungsvariablen und führen Sie docker compose up -d aus. Der Abschnitt "Produktions-Docker-Compose-Setup" oben enthält eine vollständige, kopierfertige Datei.

Wie verwalte ich Team-API-Schlüssel mit LiteLLM?

Verwenden Sie virtuelle Schlüssel. Rufen Sie den /key/generate-Endpunkt mit Ihrem Master-Schlüssel auf, um Pro-Team- oder Pro-Benutzer-Schlüssel zu erstellen. Jeder virtuelle Schlüssel kann sein eigenes monatliches Budget, Rate Limits (RPM und TPM) und Modellzugriffsbeschränkungen haben. Der Abschnitt "Virtuelle Schlüssel" deckt den vollständigen Workflow ab.

Wie füge ich Kostenverfolgung und Rate Limits zu meiner LLM-API hinzu?

Verbinden Sie PostgreSQL mit dem Proxy (über DATABASE_URL), und die Kostenverfolgung erfolgt automatisch. Für Rate Limits setzen Sie rpm_limit und tpm_limit beim Generieren virtueller Schlüssel. Das integrierte Dashboard unter /ui zeigt Pro-Team- und Pro-Modell-Ausgaben.

Ist der LiteLLM-Proxy sicher für den Produktionseinsatz?

Ja, mit einem Vorbehalt: Vermeiden Sie die Versionen 1.82.7 und 1.82.8, die von einem Supply-Chain-Vorfall im März 2026 betroffen waren. Verwenden Sie Version 1.83.0 oder später. Pinnen Sie Ihre Docker-Image-Version, setzen Sie den LITELLM_SALT_KEY zur Verschlüsselung und befolgen Sie die offiziellen Produktions-Best-Practices.

Was ist der Unterschied zwischen LiteLLM SDK und LiteLLM-Proxy?

Das SDK ist eine Python-Bibliothek zum Aufrufen mehrerer LLM-APIs aus Ihrem Code. Der Proxy ist ein eigenständiger Server, mit dem Ihr gesamtes Team verbindet. Verwenden Sie das SDK, wenn Sie ein Solo-Entwickler sind, der ein Skript schreibt. Verwenden Sie den Proxy, wenn Sie gemeinsame Zugriffskontrolle, Kostenverfolgung und Rate Limiting über ein Team hinweg benötigen.

Kann ich den LiteLLM-Proxy mit Ollama und lokalen Modellen verwenden?

Absolut. Fügen Sie einen Eintrag zu Ihrer config.yaml mit model: ollama/llama3.1 und api_base: http://host.docker.internal:11434 (oder Ihrem Ollama-Host) hinzu. Ihr Team kann dann über denselben Proxy-Endpunkt auf lokale Modelle zugreifen, was großartig für Entwicklung und kostenfreies Testen ist.

Wie viel kostet der LiteLLM-Proxy?

Der LiteLLM-Proxy ist kostenlos und Open-Source (MIT-Lizenz). Sie hosten ihn selbst auf Ihrer eigenen Infrastruktur. Die einzigen Kosten sind Ihr Server (ein kleiner VPS reicht für die meisten Teams) und die LLM-API-Kosten, die Sie bereits zahlen. BerriAI bietet auch eine verwaltete Cloud-Version an, wenn Sie nicht selbst hosten möchten.

Welche Anbieter unterstützt LiteLLM?

Über 100, darunter OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI, Ollama, Hugging Face, Cohere, Replicate und viele mehr. Die vollständige Liste finden Sie im LiteLLM GitHub-Repository.

Wie aktualisiere ich den LiteLLM-Proxy sicher?

Pinnen Sie immer eine bestimmte Version in Ihrem Docker-Image-Tag (z. B. ghcr.io/berriai/litellm:v1.83.2-stable). Prüfen Sie vor dem Upgrade das Changelog auf breaking changes. Verwenden Sie latest nie in der Produktion. Und überprüfen Sie immer, ob die neue Version nicht auf der Sicherheitshinweisliste steht -- der Vorfall vom März 2026 hat bewiesen, dass selbst vertrauenswürdige Pakete kompromittiert werden können.

Abschlussfazit und nächste Schritte

Wenn Ihr Team Geld für LLM-APIs ausgibt und Sie noch keinen Proxy haben, beginnen Sie heute mit Docker Compose + Postgres. Die Einrichtung dauert 15 Minuten, und Sie haben am Ende Kostentransparenz und Zugriffskontrolle.

Sobald Sie laufen, erkunden Sie das Hinzufügen von Guardrails zu Ihrer LLM-Pipeline für Inhaltsfilterung und Sicherheitsprüfungen. Der Proxy ist das Fundament -- alles andere baut darauf auf.

Quellen

• LiteLLM Proxy Schnellstart -- Offizielle Dokumentation
• LiteLLM Docker Deployment-Anleitung
• LiteLLM Dokumentation zu virtuellen Schlüsseln
• LiteLLM Produktions-Best-Practices
• LiteLLM Sicherheitsupdate -- März 2026
• BerriAI/litellm -- GitHub-Repository