⚡ 生产环境最佳实践

1. 使用此 config.yaml

在生产环境中使用此 config.yaml (搭配您自己的 LLM)

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

在您的 env 中设置 slack webhook url

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

关闭 FASTAPI 的默认 info 日志

export LITELLM_LOG="ERROR"

信息

需要帮助或希望获得专属支持？与创始人联系[此处]：(https://calendly.com/d/4mp-gd3-k5k/litellm-1-1-onboarding-chat)

2. 在 Kubernetes 上 - 使用 1 个 Uvicorn worker[建议的 CMD]

使用此 Docker CMD。这将使用 1 个 Uvicorn 异步 worker 启动代理

(确保您未在 CMD 中设置 run_gunicorn 或 num_workers)。

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

3. 使用 Redis 的 'port', 'host', 'password'。不要使用 'redis_url'

如果您决定使用 Redis，请勿使用 'redis_url'。我们建议使用 Redis 的 port、host 和 password 参数。

使用 redis_url 速度慢 80 RPS

我们仍在调查此问题。请在此处关注进展：此处

建议在生产环境这样做

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. 禁用 'load_dotenv'

设置 export LITELLM_MODE="PRODUCTION"

这将禁用 load_dotenv() 功能，该功能会自动从本地 .env 加载您的环境变量凭据。

5. 如果在 VPC 上运行 LiteLLM，优雅地处理数据库不可用

当在 VPC 上（且无法从公共互联网访问）运行 LiteLLM 时，您可以启用优雅降级，以便即使数据库暂时不可用，请求处理也能继续进行。

警告：仅当您在 VPC 上运行 LiteLLM 且无法从公共互联网访问时执行此操作。

配置

litellm config.yaml
general_settings:
  allow_requests_on_db_unavailable: True

预期行为

当 allow_requests_on_db_unavailable 设置为 true 时，LiteLLM 将按以下方式处理错误

错误类型	预期行为	详情
Prisma 错误	✅ 允许请求	涵盖通过 LiteLLM 使用的 ORM Prisma 发生的数据库连接重置或拒绝等问题。
Httpx 错误	✅ 允许请求	当数据库无法访问时发生，允许请求在数据库中断时继续进行。
Pod 启动行为	✅ Pods 照常启动	LiteLLM Pods 即使在数据库宕机或无法访问时也会启动，确保部署具有更高的正常运行时间。
健康/就绪检查	✅ 始终返回 200 OK	/health/readiness 端点返回 200 OK 状态，以确保 Pods 即使在数据库不可用时也能保持运行。
LiteLLM 预算错误或模型错误	❌ 请求将被阻止	当数据库可访问但认证令牌无效、缺乏访问权限或超出预算限制时触发。

6. 如果不使用 LiteLLM UI，禁用 spend_logs 和 error_logs

默认情况下，LiteLLM 会将几种类型的日志写入数据库

每个 LLM API 请求都写入 LiteLLM_SpendLogs 表
LLM 异常写入 LiteLLM_SpendLogs 表

如果您不在 LiteLLM UI 上查看这些日志，可以通过将以下标志设置为 True 来禁用它们

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

关于数据库用途的更多信息，请参阅此处

7. 使用 Helm PreSync Hook 进行数据库迁移[Beta]

为确保只有一个服务管理数据库迁移，请使用我们的Helm PreSync hook for Database Migrations。这确保了在 helm upgrade 或 helm install 期间处理迁移，而 LiteLLM Pods 则明确禁用迁移。

Helm PreSync Hook:
- Helm PreSync hook 在 chart 中配置，以便在部署期间运行数据库迁移。
- 该 hook 始终将 DISABLE_SCHEMA_UPDATE 设置为 false，确保可靠地执行迁移。
ArgoCD 的 values.yaml 参考设置
```
db:
  useExisting: true # use existing Postgres DB
  url: postgresql://ishaanjaffer0324:... # url of existing Postgres DB
```
LiteLLM Pods:
- 在 LiteLLM Pod 配置中设置 DISABLE_SCHEMA_UPDATE=true，以防止它们运行迁移。
LiteLLM Pod 示例配置
```
env:
  - name: DISABLE_SCHEMA_UPDATE
    value: "true"
```

8. 设置 LiteLLM Salt Key

如果您打算使用数据库，请设置一个 Salt Key 用于数据库中变量的加密/解密。

添加模型后请勿更改此项。它用于加密/解密您的 LLM API Key 凭据

我们推荐使用 - https://1password.com/password-generator/ 密码生成器获取 LiteLLM Salt Key 的随机哈希值。

export LITELLM_SALT_KEY="sk-1234"

查看代码

9. 使用 `prisma migrate deploy`

在生产环境中用于处理不同 LiteLLM 版本之间的数据库迁移

环境变量
命令行

USE_PRISMA_MIGRATE="True"

litellm --use_prisma_migrate

优势

migrate deploy 命令

如果迁移历史记录中缺少已应用的迁移，不会发出警告
不会检测漂移（生产数据库 schema 与迁移历史记录的最终状态不同 - 例如，由于热修复）
不会重置数据库或生成工件（如 Prisma Client）
不依赖于影子数据库

LiteLLM 如何在生产环境中处理数据库迁移？

新的迁移文件被写入我们的 litellm-proxy-extras 包。查看全部
核心 litellm pip 包被更新，指向新的 litellm-proxy-extras 包。这确保了旧版本的 LiteLLM 将继续使用旧的迁移。查看代码
当您升级到新版本的 LiteLLM 时，迁移文件将应用于数据库。查看代码

只读文件系统

如果您看到 Permission denied 错误，这意味着 LiteLLM Pod 正在只读文件系统上运行。

要解决此问题，只需在您的环境变量中设置 LITELLM_MIGRATION_DIR="/path/to/writeable/directory"。

LiteLLM 将使用此目录写入迁移文件。

其他信息

生产环境下的预期性能

在 Kubernetes 上运行 1 个 LiteLLM Uvicorn Worker

描述	值
平均延迟	`50ms`
中位延迟	`51ms`
`/chat/completions` 每秒请求数	`100`
`/chat/completions` 每分钟请求数	`6000`
`/chat/completions` 每小时请求数	`360K`

验证调试日志是否已关闭

您在代理服务器上只应看到以下级别的日志详细信息

# 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

⚡ 生产环境最佳实践

1. 使用此 config.yaml​

2. 在 Kubernetes 上 - 使用 1 个 Uvicorn worker[建议的 CMD]​

3. 使用 Redis 的 'port', 'host', 'password'。不要使用 'redis_url'​

4. 禁用 'load_dotenv'​

5. 如果在 VPC 上运行 LiteLLM，优雅地处理数据库不可用​

配置​

预期行为​

6. 如果不使用 LiteLLM UI，禁用 spend_logs 和 error_logs​

7. 使用 Helm PreSync Hook 进行数据库迁移[Beta]​

8. 设置 LiteLLM Salt Key​

9. 使用 prisma migrate deploy​

LiteLLM 如何在生产环境中处理数据库迁移？​