Zum Hauptinhalt springen

End-to-end Key-Management mit LiteLLM

Dein Dedicated-Endpunkt enthält einen einzigen Upstream-API-Key. Mit LiteLLM machst du daraus eine vollständige Key-Management-Ebene: Keys pro App/Team/Kunde, Limits, Sperrung, Rotation und Nutzungsstatistiken.

Das ist besonders relevant für deutsche Web- und Kreativagenturen mit vielen parallelen Kundenprojekten und klarer Mandantentrennung.

Was LiteLLM ergänzt​

  • Virtuelle Keys pro Anwendung, Team oder Endkunde
  • Limits pro Key (Requests/Minute, Tokens/Minute, Budget)
  • Key-Lifecycle-Steuerung (sperren, entsperren, rotieren, Ablaufzeit)
  • Nutzungs- und Kostenansicht pro Key, User und Team
  • Admin-UI plus API für Automatisierung

Voraussetzungen​

  • Docker und Docker Compose
  • Dein Dedicated-Endpunkt und der Upstream-API-Key von mittwald
  • PostgreSQL (für persistentes Key-Management erforderlich)

A-bis-Z Setup​

1. .env Datei anlegen​

LITELLM_MASTER_KEY=sk-master-key-aendern
UPSTREAM_BASE_URL=https://dein-unternehmen.llm.aihosting.mittwald.de
UPSTREAM_API_KEY=YOUR_DEDICATED_API_KEY
POSTGRES_USER=litellm
POSTGRES_PASSWORD=db-passwort-aendern
POSTGRES_DB=litellm
UI_USERNAME=admin
UI_PASSWORD=ui-passwort-aendern

2. litellm_config.yaml anlegen​

model_list:
  - model_name: YOUR_MODEL_ID
    litellm_params:
      model: openai/YOUR_MODEL_ID
      api_base: os.environ/UPSTREAM_BASE_URL
      api_key: os.environ/UPSTREAM_API_KEY

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

3. docker-compose.yml anlegen​

services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    volumes:
      - litellm-postgres:/var/lib/postgresql/data

  litellm:
    image: docker.litellm.ai/berriai/litellm:main-latest
    depends_on:
      - postgres
    ports:
      - "4000:4000"
    environment:
      LITELLM_MASTER_KEY: ${LITELLM_MASTER_KEY}
      UPSTREAM_BASE_URL: ${UPSTREAM_BASE_URL}
      UPSTREAM_API_KEY: ${UPSTREAM_API_KEY}
      DATABASE_URL: postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB}
    volumes:
      - ./litellm_config.yaml:/app/config.yaml
    command: ["--config", "/app/config.yaml"]

volumes:
  litellm-postgres:

4. Services starten​

user@local $ docker compose up -d

5. Gateway + Modell-Passthrough prüfen​

user@local $ curl http://localhost:4000/v1/models \
  -H "Authorization: Bearer ${LITELLM_MASTER_KEY}"

Danach http://localhost:4000/ui öffnen und mit den UI_USERNAME / UI_PASSWORD-Werten aus der .env-Datei anmelden. Die Admin-UI startet automatisch zusammen mit dem Proxy — kein zusätzliches Flag notwendig.

Key-Lifecycle per API​

Die Endpunkte sind in den LiteLLM Virtual-Keys Docs und im Swagger dokumentiert.

Virtuellen Key erzeugen​

user@local $ curl http://localhost:4000/key/generate \
  -H "Authorization: Bearer ${LITELLM_MASTER_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "models": ["YOUR_MODEL_ID"],
    "key_alias": "team-a-prod",
    "metadata": {"owner": "team-a"},
    "tpm_limit": 120000,
    "rpm_limit": 300,
    "max_budget": 250
  }'

Key-Infos, Limits und Nutzung abrufen​

user@local $ curl "http://localhost:4000/key/info?key=sk-virtual-key" \
  -H "Authorization: Bearer ${LITELLM_MASTER_KEY}"

In manchen Deployments gibt es zusätzlich versionierte Info-Routen (/v2/key/info).

Key sofort sperren​

user@local $ curl -X POST http://localhost:4000/key/block \
  -H "Authorization: Bearer ${LITELLM_MASTER_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"key":"sk-virtual-key"}'

Key entsperren​

user@local $ curl -X POST http://localhost:4000/key/unblock \
  -H "Authorization: Bearer ${LITELLM_MASTER_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"key":"sk-virtual-key"}'

Key rotieren​

Key-Rotation erfolgt durch Erstellen eines neuen Keys mit denselben Einstellungen und anschließendes Löschen des alten:

user@local $ curl http://localhost:4000/key/generate \
  -H "Authorization: Bearer ${LITELLM_MASTER_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "models": ["YOUR_MODEL_ID"],
    "key_alias": "team-a-prod-v2",
    "metadata": {"owner": "team-a"}
  }'

Anschließend den alten Key löschen:

user@local $ curl -X POST http://localhost:4000/key/delete \
  -H "Authorization: Bearer ${LITELLM_MASTER_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"keys":["sk-alter-virtual-key"]}'

Key dauerhaft entziehen​

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

Admin-UI​

Die Admin-UI ist unter http://localhost:4000/ui erreichbar. Anmelden mit den Zugangsdaten aus UI_USERNAME und UI_PASSWORD in deiner .env-Datei.

Die Swagger-API-Referenz (alle Proxy-Endpunkte) ist unter http://localhost:4000/ verfügbar.

Keys​

Der Bereich Keys zeigt alle virtuellen Keys mit aktuellem Verbrauch, Limits und Status.

Verfügbare Aktionen:

AktionWas sie tut
Key erstellenAlias, Modell-Allowlist, TPM/RPM-Limits, Max-Budget, Ablaufdatum, Team-/User-Zuordnung setzen
Key bearbeitenLimits, Budget und Metadaten anpassen ohne den Key neu zu erstellen
Key sperrenZugriff sofort unterbinden — Anfragen mit diesem Key erhalten 401
Key entsperrenZugriff wiederherstellen
Key löschenDauerhaft entziehen — nicht rückgängig zu machen

Verbrauchs- und Nutzungs-Dashboard​

Das Dashboard zeigt Verbrauch und Anfragevolumen aufgeschlüsselt nach:

  • Pro Key — wie viel jeder virtuelle Key verbraucht hat
  • Pro User — Verbrauch je User-ID, die Keys zugewiesen wurde
  • Pro Team — Gesamtverbrauch aller Keys eines Teams

Verbrauchsresets sind per API (POST /global/spend/reset) für Admins möglich.

Teams​

Teams fassen Keys und User unter einem gemeinsamen Budget und einer Modell-Allowlist zusammen. Team erstellen, dann beim Key-Generieren zuweisen. Das Team-Dashboard zeigt aggregierten Verbrauch und Key-Aktivität.

User​

Der Bereich Users zeigt alle User mit zugewiesenen Keys und ihrem Verbrauch. User können erstellt und Teams zugewiesen werden. User können optional eingeladen werden, sich selbst in der UI anzumelden und ihre eigenen Keys zu verwalten.

Modelle​

Im Bereich Models können Modelle hinzugefügt oder angepasst werden, ohne den Proxy neu zu starten. Preisdaten lassen sich von GitHub synchronisieren, um Kostenberechnungen aktuell zu halten.

Nutzungsstatistiken und Kostensteuerung​

LiteLLM trackt Nutzung/Kosten auf Proxy-Requests und bietet:

  • Pro Key: Nutzung/Kosten (/key/info)
  • Pro User/Team: User- und Team-Info-Endpunkte
  • Dashboard-Ansichten für Traffic, Limits und Key-Aktivität

Dedicated-Kapazität an eigene Kunden weiterverkaufen​

Dieses Setup ist für Reseller-Szenarien geeignet. Deine Kunden nutzen dein AI-Produkt, während der Upstream-mittwald-Key privat bleibt.

Empfohlenes Reseller-Muster:

  1. Upstream-Dedicated-Key nur in LiteLLM halten
  2. Pro Kunde/App/Umgebung einen virtuellen Key ausstellen
  3. Pro Key Limits und Budgets nach Tarif setzen
  4. Für den Lifecycle block/unblock/rotate/delete nutzen

So bekommst du Mandantenkontrolle und Abrechnung auf Kundenniveau, ohne Upstream-Credentials offenzulegen.

Für Agenturmodelle passt das sehr gut zu:

  • einem virtuellen Key pro Kundenprojekt
  • getrennten Kontingenten für Staging und Produktion
  • vertraglich abgestuften Limits je Kundentarif

Virtuelle Keys in Apps verwenden​

OPENAI_BASE_URL=http://localhost:4000/v1
OPENAI_API_KEY=sk-virtual-key

Betriebliche Empfehlungen​

  • LiteLLM und Datenbank persistent betreiben (kein In-Memory-only Setup in Produktion)
  • Starken master_key verwenden und regelmäßig rotieren
  • Admin-Oberfläche nur kontrolliert exponieren
  • Key-Richtlinien vor Kunden-Rollout mit Testkeys validieren

Referenzen​