LiteLLM selbst hosten: LLM-Gateway mit einem Endpunkt

Was ein selbst gehostetes LLM-Gateway leistet

LiteLLM ist ein Open-Source-LLM-Gateway, das Sie selbst hosten: ein HTTP-Endpunkt, den alle Ihre Anwendungen aufrufen. Anschließend leitet das Gateway jede Anfrage an den passenden Anbieter weiter. LLM steht für Large Language Model. Das Gateway verwendet die OpenAI Chat Completions API (Application Programming Interface). Daher funktioniert jede Client-Bibliothek, die bereits mit OpenAI kommuniziert, nach zwei Änderungen damit: der Basis-URL und dem Schlüssel.

Genau diese Indirektionsschicht ist der entscheidende Punkt. Ihre Anwendungen enthalten keine Zugangsdaten der Anbieter mehr. Ein Modell wechseln Sie mit einer Zeile in einer Konfigurationsdatei auf dem Server statt durch eine Codeänderung in fünf Diensten. Da jeder Aufruf durch einen Prozess läuft, haben Sie außerdem eine zentrale Stelle für ein Budget und für die Aufzeichnung der Ausgaben.

Nach der Einrichtung stehen Ihnen folgende Funktionen zur Verfügung:

• Ein Endpunkt. Anwendungen verwenden https://gateway.example.com/v1 und fordern einen von Ihnen festgelegten Modellnamen an, beispielsweise bulk oder strong.
• Virtuelle Schlüssel. Jede Anwendung erhält einen eigenen Schlüssel mit einer eigenen Liste zulässiger Modelle und einer eigenen Ausgabenobergrenze. Sie können einen Schlüssel widerrufen, ohne die anderen zu ändern.
• Fallbacks. Ein fehlgeschlagener Aufruf oder ein zu großer Prompt wird automatisch mit einem anderen Modell wiederholt.
• Ein protokollierter Datensatz. Jede Anfrage schreibt eine Zeile mit den entstandenen Kosten. Damit lässt sich feststellen, welche Anwendung die Ausgaben verursacht hat.

Warum Sie das Gateway selbst betreiben sollten

Ein verwalteter Router funktioniert nach demselben Prinzip, wobei bei jeder Anfrage der Prozess eines anderen Anbieters zwischengeschaltet ist. Wenn Sie das Gateway selbst betreiben, bleiben Ihre Provider-Schlüssel und Ihre Prompt-Texte auf einem System, das Sie kontrollieren. Der Aufwand ist real: Sie betreiben nun die Komponente, von der jede Anwendung abhängt. Der letzte Abschnitt dieses Leitfadens behandelt diesen Aufwand, weil er in den meisten Anleitungen ausgelassen wird.

Was Sie benötigen

• Einen VPS (virtual private server) mit Ubuntu 24.04, auf dem Docker und das Compose-Plugin installiert sind.
• Einen Domainnamen, der auf den VPS zeigt, wenn Rechner außerhalb des Servers das Gateway über TLS (transport layer security) erreichen.
• Mindestens einen API-Schlüssel eines Providers.

Das Gateway führt keine Inferenz aus. Es leitet Anfragen weiter und streamt die Antworten zurück. Die CPU-Auslastung hängt daher vom Anfragevolumen und nicht von der Modellgröße ab. Ein System mit 1 vCPU kann problemlos einige interne Anwendungen bedienen. Das Wachstum betrifft die Datenbank, weil das Gateway für jede Anfrage einen Ausgabeposten erfasst.

Schreiben Sie zuerst config.yaml

Die Konfigurationsdatei legt fest, welche Modelle ein Client anfordern darf. Vier Abschnitte der obersten Ebene sind relevant: model_list, litellm_settings, router_settings und general_settings.

model_list:
  - model_name: bulk
    litellm_params:
      model: anthropic/claude-haiku-4-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: strong
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: strong
    litellm_params:
      model: openai/gpt-5.5
      api_key: os.environ/OPENAI_API_KEY

litellm_settings:
  num_retries: 2
  request_timeout: 120
  allowed_fails: 3
  cooldown_time: 30
  json_logs: true
  set_verbose: false

router_settings:
  fallbacks: [{"bulk": ["strong"]}]
  context_window_fallbacks: [{"bulk": ["strong"]}]

general_settings:
  background_health_checks: true
  health_check_interval: 300

model_name ist der Name, den Ihre Clients senden. litellm_params.model ist das tatsächliche Modell und wird als provider/model angegeben. Benennen Sie Modelle nach ihrem Einsatzzweck und nicht nach dem Anbieter. Eine Anwendung, die bulk anfordert, funktioniert weiter, wenn bulk im nächsten Monat ein anderes Modell sein soll.

api_key: os.environ/ANTHROPIC_API_KEY weist LiteLLM an, diese Variable zur Laufzeit zu lesen. Der eigentliche Schlüssel erscheint nie in der Datei. Das ist wichtig, weil Sie config.yaml in das Repository übernehmen.

Zwei Einträge verwenden absichtlich den Namen strong. Wenn mehrere Deployments denselben model_name tragen, behandelt der Router sie als austauschbar und versucht das andere Deployment, wenn das erste fehlschlägt. Dadurch bleibt strong verfügbar, wenn ein Anbieter vorübergehend Probleme hat.

num_retries: 2 wiederholt dasselbe Deployment bei einem wiederholbaren Fehler. Ein Fallback wird erst verwendet, wenn diese Wiederholungen ausgeschöpft sind. allowed_fails: 3 zusammen mit cooldown_time: 30 nimmt ein Deployment 30 Sekunden lang aus der Rotation, sobald es 3-mal fehlgeschlagen ist. Dadurch wird ein Anbieter, der 500-Fehler zurückgibt, nicht bei jeder einzelnen Anfrage erneut versucht.

fallbacks und context_window_fallbacks haben unterschiedliche Auslöser. Der zweite wird häufig übersehen, ist aber besonders nützlich.

• fallbacks wird ausgelöst, wenn der primäre Aufruf fehlschlägt.
• context_window_fallbacks wird ausgelöst, wenn der Anbieter die Anfrage ablehnt, weil sie länger als das Kontextfenster des Modells ist. Ein zu großer Prompt wird dadurch an ein Modell mit ausreichender Kapazität weitergeleitet, statt dem Aufrufer einen Fehler zurückzugeben.

Außerdem gibt es content_policy_fallbacks für den Fall, dass ein Anbieter eine Anfrage aufgrund von Inhaltsrichtlinien ablehnt. Setzen Sie diese Option nur, wenn Sie einen sinnvollen Zielpfad für solche Anfragen haben.

LiteLLM mit Docker Compose auf einem VPS bereitstellen

Erstellen Sie ein Verzeichnis mit den drei Dateien config.yaml, docker-compose.yml und .env. Der Upstream-Schnellstart verwendet den Tag latest. Pinnen Sie stattdessen einen Release-Tag. Dann liefert docker compose up -d im nächsten Monat dasselbe Gateway wie heute. Ein Rollback besteht dann aus einer einzigen Zeile.

services:
  litellm:
    image: ghcr.io/berriai/litellm:v1.95.0
    restart: unless-stopped
    command: ["--config", "/app/config.yaml", "--num_workers", "1"]
    ports:
      - "127.0.0.1:4000:4000"
    volumes:
      - ./config.yaml:/app/config.yaml:ro
    env_file: .env
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: litellm
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?set POSTGRES_PASSWORD in .env}
      POSTGRES_DB: litellm
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U litellm"]
      interval: 5s
      timeout: 5s
      retries: 10
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

Compose liest .env hier zweimal. Einmal, um ${POSTGRES_PASSWORD} direkt in der Compose-Datei zu ersetzen. Ein weiteres Mal über env_file, um jede Variable an den Container zu übergeben.

v1.95.0 war im August 2026 das aktuelle Release. Prüfen Sie die Release-Seite des Projekts und pinnen Sie beim Deployment die dann aktuelle Version. Für jedes Release wird eine Signatur veröffentlicht. Sie können das Image daher prüfen, bevor Sie ihm vertrauen:

cosign verify --key https://raw.githubusercontent.com/BerriAI/litellm/v1.95.0/cosign.pub ghcr.io/berriai/litellm:v1.95.0

Die Port-Zeile lautet 127.0.0.1:4000:4000. Dadurch wird der Port nur auf der Loopback-Schnittstelle veröffentlicht. Schreiben Sie stattdessen 4000:4000, ist Ihr Gateway aus dem gesamten Internet erreichbar. Docker fügt eigene Regeln in die FORWARD-Kette von iptables ein. Diese werden vor den Regeln von ufw ausgewertet. Daher verhindert ufw deny 4000 den Zugriff nicht. Auf diese Weise wird ein selbst gehostetes Gateway am häufigsten versehentlich öffentlich erreichbar: siehe wie Docker einen Container-Port direkt an ufw vorbei veröffentlicht. Externer Datenverkehr kommt stattdessen über den Reverse Proxy an.

Provider-Schlüssel aus dem Image heraushalten

Die Datei .env enthält alle Secrets. Sie wird zur Laufzeit als Umgebung übergeben. Dadurch wird sie niemals in das Image eingebaut und niemals in das Repository committed.

LITELLM_MASTER_KEY=sk-REPLACE_ME
LITELLM_SALT_KEY=sk-REPLACE_ME_TOO
POSTGRES_PASSWORD=REPLACE_ME_AS_WELL
DATABASE_URL=postgresql://litellm:REPLACE_ME_AS_WELL@db:5432/litellm
STORE_MODEL_IN_DB=True
LITELLM_MODE=PRODUCTION
LITELLM_LOG=ERROR
ANTHROPIC_API_KEY=sk-ant-...
OPENAI_API_KEY=sk-proj-...

Erzeugen Sie die beiden LiteLLM-Schlüssel mit echter Zufallsquelle. Schränken Sie anschließend die Dateiberechtigungen ein:

printf 'sk-%s\n' "$(openssl rand -hex 32)"
chmod 600 .env

LITELLM_MASTER_KEY ist das Administratorkennwort. Es authentifiziert die Management-API und ist das Kennwort für die Admin UI unter /ui. Keine Anwendung sollte diesen Schlüssel jemals enthalten.

LITELLM_SALT_KEY verschlüsselt die in der Datenbank gespeicherten Zugangsdaten der Provider. Setzen Sie den Wert einmal und ändern Sie ihn danach nicht mehr. Wenn Sie ihn später ändern, können die bereits gespeicherten Zugangsdaten nicht mehr entschlüsselt werden. Das Gateway startet dann zwar normal, aber jeder Aufruf dieser Provider schlägt bei der Authentifizierung fehl.

Mit STORE_MODEL_IN_DB=True können Sie Modelle über die Admin UI hinzufügen und bearbeiten, ohne config.yaml anzupassen. Das ist praktisch, teilt jedoch die Quelle der Wahrheit in zwei Teile. Legen Sie fest, welche Quelle maßgeblich ist, und dokumentieren Sie diese Entscheidung neben der Konfiguration.

Der Grund, Provider-Schlüssel aus der Konfigurationsdatei herauszuhalten, gilt auch für die Werkzeuge, die Sie einem Agenten übergeben. Provider-Secrets aus KI-Agenten heraushalten beschreibt dieses Muster. env-Dateien und Secrets in Docker Compose erläutert die technische Umsetzung.

Starten Sie den Stack und überwachen Sie den ersten Start:

docker compose up -d
docker compose logs -f litellm

Prüfen, ob der Dienst tatsächlich funktioniert

Es gibt zwei nicht authentifizierte Prüfungen und eine authentifizierte Prüfung. Sie schlagen aus unterschiedlichen Gründen fehl.

curl -s http://127.0.0.1:4000/health/liveliness
curl -s http://127.0.0.1:4000/health/readiness

/health/liveliness benötigt keine Authentifizierung und antwortet mit "I'm alive!", solange der Prozess läuft. Auch /health/readiness benötigt keine Authentifizierung. Die Prüfung gibt ein JSON-Objekt mit "status": "healthy" und einem Feld db zurück oder 503, wenn die Datenbank nicht erreichbar ist. Richten Sie Ihr Monitoring auf die Readiness-Prüfung. Die Liveness-Prüfung bleibt auf einem Gateway grün, das keinen einzigen virtuellen Schlüssel auflösen kann.

Die authentifizierte Prüfung kommuniziert mit den Providern:

curl -s http://127.0.0.1:4000/health \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY"

Sie antwortet mit den Arrays healthy_endpoints und unhealthy_endpoints. Ein Modell in unhealthy_endpoints mit einem Authentifizierungsfehler weist darauf hin, dass der Provider-Schlüssel in .env falsch ist oder fehlt. Das ist der Fehler, den Sie jetzt finden möchten. Da background_health_checks: true gesetzt ist, führt der Proxy diese Prüfungen alle health_check_interval Sekunden selbstständig aus, und /health gibt das letzte Ergebnis zurück. Das Abrufen dieses Endpunkts sendet daher nicht jedes Mal eine Testanfrage an Ihre Provider.

Virtuelle Schlüssel und Budgets pro Schlüssel

Jede Anwendung erhält einen eigenen Schlüssel, der mit dem Hauptschlüssel ausgestellt wird.

curl -s http://127.0.0.1:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "key_alias": "nightly-summariser",
    "models": ["bulk"],
    "max_budget": 5,
    "budget_duration": "30d",
    "rpm_limit": 60,
    "tpm_limit": 200000
  }'

Die Antwort enthält ein Feld key, das mit sk- beginnt. Diese Zeichenfolge erhält die Anwendung. Sie ist das Einzige, was die Anwendung jemals erhält.

• models ist eine Allowlist der Aktionen, die dieser Schlüssel anfordern darf. Mit dem oben gezeigten Schlüssel kann die Anwendung bulk anfordern und nichts anderes.
• max_budget: 5 mit budget_duration: "30d" beträgt fünf US-Dollar pro rollierenden 30-Tage-Zeitraum. Danach funktioniert der Schlüssel nicht mehr.
• rpm_limit und tpm_limit begrenzen die Anfragen pro Minute und die Tokens pro Minute ausschließlich für diesen Schlüssel.
• key_alias ist der Eintrag, den Sie sechs Wochen später im Ausgabenprotokoll wiedererkennen. Setzen Sie ihn immer.

Wenn das Budget aufgebraucht ist, schlägt der Aufruf mit HTTP 401 fehl. Der Antworttext hat diese Form:

ExceededBudget: Current spend for token: 7.2e-05; Max Budget for Token: 2e-07

Der Statuscode macht das Problem schwer verständlich. Eine Clientbibliothek meldet 401 als Authentifizierungsproblem. Der Entwickler, der den Stacktrace liest, prüft dann zunächst, ob der Schlüssel gültig ist. Protokollieren Sie den Antworttext zusammen mit dem Statuscode. Andernfalls wirkt ein aufgebrauchtes Budget jedes Mal wie eine fehlerhafte Zugangsdaten.

Prüfen und ändern Sie Schlüssel über dieselbe Management-API:

curl -s "http://127.0.0.1:4000/key/info?key=sk-..." \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY"

curl -s -X POST http://127.0.0.1:4000/key/update \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"key": "sk-...", "max_budget": 25}'

Ein am Gateway durchgesetztes Budget bleibt auch dann wirksam, wenn der Agent selbst die Ursache des Problems ist. Deshalb bildet es das Rückgrat der Kostenkontrolle für KI-Agenten auf einem VPS.

Massenverarbeitung an ein günstiges Modell senden

Richten Sie einen Client auf das Gateway. Basis-URL, Schlüssel und Modellname:

curl -s http://127.0.0.1:4000/v1/chat/completions \
  -H "Authorization: Bearer sk-<the virtual key>" \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "bulk",
    "messages": [{"role": "user", "content": "Say hello in five words."}]
  }'

Jede OpenAI-Clientbibliothek funktioniert auf dieselbe Weise: Setzen Sie base_url auf https://gateway.example.com/v1 und api_key auf den virtuellen Schlüssel.

Die Routing-Richtlinie aus config.yaml wird nun angewendet, ohne dass der Aufrufer davon wissen muss. Eine Anfrage für bulk wird an das günstige Modell gesendet. Wenn dieser Aufruf nach seinen Wiederholungsversuchen fehlschlägt, wird die Anfrage erneut an strong gesendet. Wenn die Eingabeaufforderung für bulk zu lang ist, sendet context_window_fallbacks sie stattdessen an strong, anstatt einen Fehler zurückzugeben. Massenverarbeitung wie ein Klassifizierungslauf oder die Zusammenfassung eines Rückstands wird standardmäßig günstig ausgeführt. Nur anspruchsvolle Anfragen verursachen höhere Kosten.

Hier zeigt sich auch der Nutzen eines Gateways für Agenten, die Tools verwenden. Ein MCP-Server (Model Context Protocol) auf demselben VPS und der ihn steuernde Agent können beide auf einen einzigen Endpunkt zeigen. Dadurch kann das dahinterliegende Modell gewechselt werden, ohne einen der beiden Dienste erneut bereitzustellen.

Woran erkennen Sie, dass ein Fallback stattgefunden hat?

Dieser Fehlerfall verursacht Kosten, weil nichts offensichtlich kaputt aussieht. Ein erfolgreicher Fallback liefert HTTP 200 mit einem normalen Antworttext. Ihr günstiges Modell kann einen Tag lang ausgefallen sein, während jede Anfrage unbemerkt vom teuren Modell verarbeitet wird. Der erste Hinweis ist dann die Rechnung.

Die Informationen stehen in den Response-Headern. Fordern Sie sie an:

curl -s -D - -o /dev/null http://127.0.0.1:4000/v1/chat/completions \
  -H "Authorization: Bearer sk-<the virtual key>" \
  -H 'Content-Type: application/json' \
  -d '{"model":"bulk","messages":[{"role":"user","content":"ping"}]}' \
  | grep -i '^x-litellm'

• x-litellm-model-group zeigt, welches Modell der Client angefordert hat. x-litellm-model-id zeigt, welches Deployment geantwortet hat. Wenn diese beiden Werte nicht übereinstimmen, hat ein Fallback stattgefunden.
• x-litellm-attempted-fallbacks und x-litellm-attempted-retries zählen die Fallbacks. Bei einer fehlerfreien Anfrage sind beide Werte 0.
• x-litellm-response-cost enthält die Kosten dieser einzelnen Anfrage in US-Dollar.
• x-litellm-call-id ist die Kennung, mit der Sie dieselbe Anfrage in Ihren Logs finden.

Zeichnen Sie x-litellm-attempted-fallbacks bei jeder Anfrage auf und lösen Sie einen Alarm aus, sobald der Wert nicht mehr 0 ist. Diese eine Zahl entscheidet, ob eine Routing-Richtlinie funktioniert oder ob sie unbemerkt zu „immer das teure Modell verwenden“ geworden ist.

Die vollständige Lösung dafür ist Tracing und verdient eine eigene Einrichtung: Self-hosted Langfuse für das Tracing von Agent-Aufrufen. LiteLLM liefert den Callback mit. Für die Einrichtung benötigen Sie daher zwei Zeilen und die Zugangsdaten.

litellm_settings:
  success_callback: ["langfuse"]
  failure_callback: ["langfuse"]

LANGFUSE_PUBLIC_KEY=pk-lf-...
LANGFUSE_SECRET_KEY=sk-lf-...
LANGFUSE_HOST=https://langfuse.example.com

Setzen Sie failure_callback ebenso wie success_callback. Wenn Sie das überspringen, behalten Sie nur die Traces, bei denen nichts schiefgegangen ist. Unabhängig davon schreibt LiteLLM pro Anfrage eine Ausgabenzeile in Postgres. Die Admin UI unter /ui liest diese Tabelle. Sie wächst mit dem Datenverkehr. Überwachen Sie sie daher auf einem kleinen Datenträger.

Gateway hinter einen Reverse Proxy stellen

Nichts außerhalb des Servers sollte Port 4000 erreichen. Beenden Sie TLS in nginx oder Caddy und leiten Sie die Anfragen an die Loopback-Adresse weiter.

location / {
    proxy_pass http://127.0.0.1:4000;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_buffering off;
    proxy_read_timeout 600s;
}

Zwei dieser Zeilen werden häufig weggelassen. proxy_buffering off ist wichtig, weil eine Streaming-Vervollständigung aus einer Reihe von Server-Sent Events besteht. Bei aktiviertem Buffering hält nginx die Chunks zurück, bis die Antwort beendet ist. Der Client bleibt dann zunächst ohne Ausgabe und erhält anschließend alles auf einmal. proxy_read_timeout 600s ist wichtig, weil eine lange Generierung das nginx-Standardlimit von 60 Sekunden überschreitet. Dann erhält der Client einen 504-Fehler, während das Fehlerprotokoll upstream timed out (110: Connection timed out) while reading response header from upstream erfasst.

Für das Zertifikat ist Certbot mit Let's Encrypt unter nginx der kürzeste Weg. Wenn der Server bereits mehrere Container bereitstellt, übernimmt Traefik vor mehreren Compose-Anwendungen Routing und Zertifikate zentral.

Das Gateway ist jetzt ein Single Point of Failure

Seien Sie sich bewusst, was Sie eingerichtet haben. Jede Ihrer Anwendungen hängt jetzt von einem Container auf einem VPS ab. Solange er nicht verfügbar ist, kann keine Anwendung ein Modell aufrufen, auch keine Anbieter, die problemlos funktionieren. Daraus folgen vier Punkte.

• Eine fehlerhafte Konfiguration legt alles gleichzeitig lahm. restart: unless-stopped startet einen abgestürzten Container neu. Das gilt auch für einen Container, der die Datei config.yaml nicht verarbeiten kann. Er wird dann immer wieder neu gestartet. Lesen Sie docker compose logs litellm nach jeder Konfigurationsänderung. Nehmen Sie Änderungen an der Konfiguration vor, wenn Sie Zeit haben, den Dienst zu beobachten.
• Postgres liegt im Anfragepfad. Die Auflösung virtueller Schlüssel und die Erfassung der Ausgaben verwenden beide die Datenbank. Wenn /health/readiness den Status 503 zurückgibt, läuft das Gateway zwar, kann aber keine dieser beiden Aufgaben ausführen.
• Skalieren Sie durch zusätzliche Instanzen, nicht durch eine größere Instanz. Die Empfehlung des Projekts lautet, pro Instanz einen Worker zu verwenden (--num_workers 1) und mehrere Instanzen auf eine gemeinsame Datenbank zugreifen zu lassen. Zwei kleine Gateways hinter einem Load Balancer entfernen den einzelnen Container als Single Point of Failure. Die Datenbank bleibt jedoch ein Abhängigkeitspunkt.
• Sichern Sie alles, was sich nicht neu erzeugen lässt. Dazu gehören config.yaml und .env sowie ein pg_dump der Datenbank. Wenn LITELLM_SALT_KEY verloren geht, sind die verschlüsselten Zugangsdaten der Anbieter in diesem Dump unbrauchbar. Die Env-Datei und der Dump gehören daher in denselben Sicherungsauftrag: restic-Sicherungen auf externem Speicher.

Für ein Upgrade bearbeiten Sie den Image-Tag und führen docker compose up -d aus. LiteLLM führt beim Start standardmäßig prisma migrate deploy aus. Der neue Container migriert das Datenbankschema daher beim ersten Start. Erstellen Sie den Dump, bevor Sie den Tag ändern. Das Zurücksetzen auf das alte Image macht eine bereits ausgeführte Migration nicht rückgängig.

FAQ

Fügt LiteLLM bei jedem Aufruf eine merkliche Latenz hinzu?

Das Projekt gibt im README im August 2026 eine Latenz von 8 ms im 95. Perzentil bei 1000 Requests pro Sekunde an. Betrachten Sie das als Herstellerangabe. Für Ihre tatsächliche Latenz ist die Netzwerkentfernung zwischen Ihren Anwendungen und dem Gateway entscheidend, weil jeder Aufruf einen zusätzlichen Roundtrip enthält. Betreiben Sie das Gateway in derselben Region wie die Anwendungen, die es aufrufen. Messen Sie anschließend den eigenen Overhead mit dem Header x-litellm-overhead-duration-ms in einer echten Antwort.

Warum funktioniert Streaming nicht mehr, nachdem ich nginx vorgeschaltet habe?

nginx puffert Upstream-Antworten standardmäßig. Eine gestreamte Completion besteht jedoch aus einer Reihe von Server-Sent Events. Wenn proxy_buffering aktiviert ist, sammelt nginx die Chunks und gibt sie erst frei, wenn die Antwort vollständig ist. Der Client wartet daher zunächst ohne Ausgabe und erhält anschließend die gesamte Antwort auf einmal. Setzen Sie proxy_buffering off; im location-Block. Erhöhen Sie im selben Block proxy_read_timeout, weil eine lange Generierung andernfalls das nginx-Standardlimit von 60 Sekunden überschreitet und der Client einen 504 erhält.

Was passiert, wenn das Budget eines virtuellen Keys aufgebraucht ist?

Der Aufruf schlägt mit HTTP 401 fehl. Der Response-Body hat die Form ExceededBudget: Current spend for token: 7.2e-05; Max Budget for Token: 2e-07. Der Status 401 ist dabei irreführend: Eine Clientbibliothek meldet ihn als Authentifizierungsfehler. Dadurch prüfen Benutzer oft, ob der Key gültig ist, statt die Meldung zu lesen. Protokollieren Sie den Response-Body zusammen mit dem Statuscode. Prüfen Sie die tatsächliche Position des Keys mit /key/info?key=sk-... gegen den Master-Key. Erhöhen Sie das Limit mit /key/update, wenn das Budget zu niedrig festgelegt wurde.

Kann das Gateway neben gehosteten Modellen auch ein lokales Modell ansprechen?

Ja. Das lokale Modell ist ein weiterer Eintrag in model_list. Verwenden Sie das Präfix ollama_chat/ zusammen mit einem api_base, beispielsweise model: ollama_chat/llama3.1 neben api_base: http://ollama:11434. Innerhalb eines Containers bezeichnet localhost diesen Container selbst. Verwenden Sie daher den Compose-Service-Namen oder die Adresse des Hosts im Docker-Netzwerk, niemals 127.0.0.1. Das Starten des lokalen Modells ist eine separate Aufgabe. Siehe Ein LLM mit Ollama auf einem VPS selbst hosten.