Zum Hauptinhalt springen

⚡ Best Practices for Production

1. Verwenden Sie diese config.yaml​

Verwenden Sie diese config.yaml in der Produktion (mit Ihren eigenen LLMs)

model_list:
  - model_name: fake-openai-endpoint
    litellm_params:
      model: openai/fake
      api_key: fake-key
      api_base: https://exampleopenaiendpoint-production.up.railway.app/

general_settings:
  master_key: sk-1234      # enter your own master key, ensure it starts with 'sk-'
  alerting: ["slack"]      # Setup slack alerting - get alerts on LLM exceptions, Budget Alerts, Slow LLM Responses
  proxy_batch_write_at: 60 # Batch write spend updates every 60s
  database_connection_pool_limit: 10 # limit the number of database connections to = MAX Number of DB Connections/Number of instances of litellm proxy (Around 10-20 is good number)

  # OPTIONAL Best Practices
  disable_spend_logs: True # turn off writing each transaction to the db. We recommend doing this is you don't need to see Usage on the LiteLLM UI and are tracking metrics via Prometheus
  disable_error_logs: True # turn off writing LLM Exceptions to DB
  allow_requests_on_db_unavailable: True # Only USE when running LiteLLM on your VPC. Allow requests to still be processed even if the DB is unavailable. We recommend doing this if you're running LiteLLM on VPC that cannot be accessed from the public internet.

litellm_settings:
  request_timeout: 600    # raise Timeout error if call takes longer than 600 seconds. Default value is 6000seconds if not set
  set_verbose: False      # Switch off Debug Logging, ensure your logs do not have any debugging on
  json_logs: true         # Get debug logs in json format

Setzen Sie die Slack-Webhook-URL in Ihrer Umgebung

export SLACK_WEBHOOK_URL="https://hooks.slack.com/services/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"

Schalten Sie die standardmäßigen Info-Logs von FastAPI aus

export LITELLM_LOG="ERROR"
Info

Benötigen Sie Hilfe oder wünschen Sie dedizierten Support? Sprechen Sie mit einem Gründer[hier]: (https://calendly.com/d/4mp-gd3-k5k/litellm-1-1-onboarding-chat)

2. Auf Kubernetes – Verwenden Sie 1 Uvicorn-Worker[Empfohlener CMD]​

Verwenden Sie diesen Docker CMD. Damit wird der Proxy mit 1 Uvicorn Async Worker gestartet

(Stellen Sie sicher, dass Sie run_gunicorn oder num_workers nicht im CMD setzen).

CMD ["--port", "4000", "--config", "./proxy_server_config.yaml"]

3. Verwenden Sie Redis 'port', 'host', 'password'. NICHT 'redis_url'​

Wenn Sie sich für die Verwendung von Redis entscheiden, verwenden Sie NICHT 'redis_url'. Wir empfehlen die Verwendung der Parameter für Redis-Port, -Host und -Passwort.

redis_url ist 80 RPS langsamer

Dies ist immer noch etwas, das wir untersuchen. Behalten Sie es im Auge hier

Empfohlen für die Produktion

router_settings:
  routing_strategy: usage-based-routing-v2 
  # redis_url: "os.environ/REDIS_URL"
  redis_host: os.environ/REDIS_HOST
  redis_port: os.environ/REDIS_PORT
  redis_password: os.environ/REDIS_PASSWORD

litellm_settings:
  cache: True
  cache_params:
    type: redis
    host: os.environ/REDIS_HOST
    port: os.environ/REDIS_PORT
    password: os.environ/REDIS_PASSWORD

4. Deaktivieren Sie 'load_dotenv'​

Setzen Sie export LITELLM_MODE="PRODUCTION"

Dadurch wird die load_dotenv()-Funktionalität deaktiviert, die Ihre Umgebung-Zugangsdaten automatisch aus der lokalen .env-Datei lädt.

5. Wenn Sie LiteLLM auf VPC ausführen, behandeln Sie DB-Nichtverfügbarkeit graceful​

Wenn Sie LiteLLM auf einer VPC ausführen (und nicht über das öffentliche Internet erreichbar sind), können Sie eine graceful Degradation aktivieren, sodass die Anfrageverarbeitung auch dann fortgesetzt wird, wenn die Datenbank vorübergehend nicht verfügbar ist.

WARNUNG: Tun Sie dies nur, wenn Sie LiteLLM auf einer VPC ausführen, die nicht über das öffentliche Internet zugänglich ist.

Konfiguration​

litellm config.yaml
general_settings:
  allow_requests_on_db_unavailable: True

Erwartetes Verhalten​

Wenn allow_requests_on_db_unavailable auf true gesetzt ist, behandelt LiteLLM Fehler wie folgt

Art des FehlersErwartetes VerhaltenDetails
Prisma-Fehler✅ Anfrage wird zugelassenUmfasst Probleme wie DB-Verbindungsunterbrechungen oder Ablehnungen von der DB über Prisma, dem von LiteLLM verwendeten ORM.
Httpx-Fehler✅ Anfrage wird zugelassenTritt auf, wenn die Datenbank nicht erreichbar ist, sodass die Anfrage trotz des DB-Ausfalls fortgesetzt werden kann.
Pod-Startverhalten✅ Pods starten trotzdemLiteLLM-Pods starten auch dann, wenn die Datenbank nicht verfügbar oder nicht erreichbar ist, was eine höhere Verfügbarkeit für Deployments gewährleistet.
Health/Readiness-Prüfung✅ Gibt immer 200 OK zurückDer Endpunkt /health/readiness gibt einen 200 OK-Status zurück, um sicherzustellen, dass Pods auch dann betriebsbereit bleiben, wenn die Datenbank nicht verfügbar ist.
LiteLLM-Budgetfehler oder Modellfehler❌ Anfrage wird blockiertAusgelöst, wenn die DB erreichbar ist, aber das Authentifizierungstoken ungültig ist, keine Zugriffsrechte hat oder Budgetlimits überschreitet.

6. Deaktivieren Sie spend_logs & error_logs, wenn Sie die LiteLLM UI nicht verwenden​

Standardmäßig schreibt LiteLLM verschiedene Arten von Protokollen in die Datenbank

  • Jede LLM-API-Anfrage an die Tabelle LiteLLM_SpendLogs
  • LLM-Ausnahmen an die Tabelle LiteLLM_SpendLogs

Wenn Sie diese Protokolle nicht in der LiteLLM-UI anzeigen, können Sie sie deaktivieren, indem Sie die folgenden Flags auf True setzen

general_settings:
  disable_spend_logs: True    # Disable writing spend logs to DB
  disable_error_logs: True    # Disable writing error logs to DB

Mehr Informationen darüber, wofür die Datenbank verwendet wird, finden Sie hier

7. Verwenden Sie den Helm PreSync Hook für Datenbankmigrationen[BETA]​

Um sicherzustellen, dass nur ein Dienst Datenbankmigrationen verwaltet, verwenden Sie unseren Helm PreSync Hook für Datenbankmigrationen. Dies stellt sicher, dass Migrationen während helm upgrade oder helm install durchgeführt werden, während LiteLLM-Pods explizit Migrationen deaktivieren.

  1. Helm PreSync Hook:

    • Der Helm PreSync Hook ist im Chart konfiguriert, um Datenbankmigrationen während Deployments auszuführen.
    • Der Hook setzt immer DISABLE_SCHEMA_UPDATE=false, um sicherzustellen, dass Migrationen zuverlässig ausgeführt werden.

    Referenzeinstellungen für ArgoCD für values.yaml

    db:
      useExisting: true # use existing Postgres DB
      url: postgresql://ishaanjaffer0324:... # url of existing Postgres DB

  2. LiteLLM-Pods:

    • Setzen Sie DISABLE_SCHEMA_UPDATE=true in den LiteLLM-Pod-Konfigurationen, um zu verhindern, dass sie Migrationen ausführen.

    Beispielkonfiguration für LiteLLM-Pod

    env:
      - name: DISABLE_SCHEMA_UPDATE
        value: "true"

8. Setzen Sie den LiteLLM Salt Key​

Wenn Sie die DB verwenden möchten, setzen Sie einen Salt Key zum Verschlüsseln/Entschlüsseln von Variablen in der DB.

Ändern Sie dies nicht, nachdem Sie ein Modell hinzugefügt haben. Es wird verwendet, um Ihre LLM-API-Schlüssel-Zugangsdaten zu verschlüsseln / entschlüsseln.

Wir empfehlen: https://1password.com/password-generator/ Passwortgenerator, um einen zufälligen Hash für den LiteLLM Salt Key zu erhalten.

export LITELLM_SALT_KEY="sk-1234"

Code anzeigen

9. Verwenden Sie prisma migrate deploy​

Verwenden Sie dies, um DB-Migrationen über LiteLLM-Versionen hinweg in der Produktion zu handhaben

USE_PRISMA_MIGRATE="True"

Vorteile

Der migrate deploy Befehl

  • Gibt **keine** Warnung aus, wenn eine bereits angewendete Migration in der Migrationshistorie fehlt
  • Erkennt **keine** Abweichungen (Produktionsdatenbank-Schema weicht vom Endzustand der Migrationshistorie ab – z. B. aufgrund eines Hotfixes)
  • Setzt die Datenbank **nicht** zurück und generiert keine Artefakte (wie Prisma Client)
  • Verlässt sich **nicht** auf eine Schatten-Datenbank

Wie behandelt LiteLLM DB-Migrationen in der Produktion?​

  1. Eine neue Migrationsdatei wird in unser Paket litellm-proxy-extras geschrieben. Alle anzeigen

  2. Das Kern-pip-Paket litellm wird angehoben, um auf das neue Paket litellm-proxy-extras zu verweisen. Dies stellt sicher, dass ältere Versionen von LiteLLM die alten Migrationen weiterhin verwenden. Code anzeigen

  3. Wenn Sie auf eine neue Version von LiteLLM upgraden, wird die Migrationsdatei auf die Datenbank angewendet. Code anzeigen

Schreibgeschütztes Dateisystem​

Wenn Sie eine Fehlermeldung "Permission denied" sehen, bedeutet dies, dass der LiteLLM-Pod mit einem schreibgeschützten Dateisystem ausgeführt wird.

Um dies zu beheben, setzen Sie einfach LITELLM_MIGRATION_DIR="/path/to/writeable/directory" in Ihrer Umgebung.

LiteLLM verwendet dieses Verzeichnis zum Schreiben von Migrationsdateien.

Extras​

Erwartete Leistung in der Produktion​

1 LiteLLM Uvicorn Worker auf Kubernetes

BeschreibungWert
Durchschnittliche Latenz50ms
Median-Latenz51ms
/chat/completions Anfragen/Sekunde100
/chat/completions Anfragen/Minute6000
/chat/completions Anfragen/Stunde360K

Überprüfung, ob Debugging-Logs deaktiviert sind​

Sie sollten nur die folgenden Detailierungsstufen in den Logs auf dem Proxy-Server sehen

# INFO:     192.168.2.205:11774 - "POST /chat/completions HTTP/1.1" 200 OK
# INFO:     192.168.2.205:34717 - "POST /chat/completions HTTP/1.1" 200 OK
# INFO:     192.168.2.205:29734 - "POST /chat/completions HTTP/1.1" 200 OK