AI API网关LiteLLM实战：零代码实现多模型故障转移与自动切换

上个月深夜两点，我被一个电话吵醒。运维说线上服务崩了，用户反馈刷不出来任何东西。排查下来，不是代码 bug，不是数据库挂了，而是一个简单到离谱的原因——OpenAI API 返回了 429 Too Many Requests，而我们的代码没有做任何 fallback 处理。

那个凌晨我花了 40 分钟手动切到 Claude API，重新部署，然后对着屏幕骂了一句脏话。第二天我就开始找 AI API 网关方案，然后发现了 LiteLLM。这篇文章就是从那场事故里长出来的，记录了我在生产环境搭建多模型网关的全过程。

先搞清楚：为什么你的应用需要一个 AI API 网关

如果你只对接一个模型、一个 API Key、一个账号，那可能确实不需要网关。但现实是，2026 年的 AI 应用场景远比这复杂：

AI API 网关解决的就是这些问题的交集。它在你的应用和各家 API 之间架了一层统一入口，像一个智能路由器，根据请求类型、实时负载和成本，把请求分发到最合适的模型。

为什么选 LiteLLM？对比了 5 个方案后的选择

市面上的 AI 网关方案不少，我花了一周时间对比了主流选项：

LiteLLM 最后胜出，原因有三：

• GitHub 40k+ Star，社区活跃度碾压同类方案，issue 响应时间通常在 24 小时内
• 原生 OpenAI 协议兼容，你现有的代码不需要改动一行，只需把 Base URL 指向 LiteLLM Proxy
• 一个 YAML 文件搞定所有配置，模型路由、fallback 链、rate limit、成本追踪，全部声明式管理

搭建步骤：从零到生产环境

第一步：安装和基础配置

最简安装只需要一行命令：

pip install litellm[proxy]

然后创建一个 config.yaml，这是整个网关的核心配置文件：

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY

model_list:
  # 主力模型 - GPT-5.4
  - model_name: gpt-5.4
    litellm_params:
      model: openai/gpt-5.4
      api_key: os.environ/OPENAI_API_KEY
  
  # 备用模型1 - Claude Sonnet 4.5
  - model_name: claude-sonnet-4.5
    litellm_params:
      model: anthropic/claude-sonnet-4-5-20250929
      api_key: os.environ/ANTHROPIC_API_KEY
  
  # 经济模型 - DeepSeek V4 Flash
  - model_name: deepseek-v4-flash
    litellm_params:
      model: deepseek/deepseek-v4-flash
      api_key: os.environ/DEEPSEEK_API_KEY

# 路由策略：定义故障转移链
router_settings:
  routing_strategy: "latency-based-routing"
  allowed_fails: 3
  num_retries: 3
  fallbacks:
    - gpt-5.4: ["claude-sonnet-4.5", "deepseek-v4-flash"]
    - claude-sonnet-4.5: ["gpt-5.4", "deepseek-v4-flash"]

litellm_settings:
  set_verbose: false
  drop_params: true
  request_timeout: 120

启动网关：

litellm --config config.yaml --port 4000

就这三步，你就有了一台跑在 localhost:4000 的 AI API 网关。你的应用代码只需要把 https://api.openai.com/v1 改成 http://localhost:4000/v1，其他什么都不用改。

第二步：配置故障转移——这才是核心价值

上面那个深夜事故的教训告诉我：fallback 机制是网关最重要的功能，没有之一。LiteLLM 的 fallback 配置非常直观：

# 三层 fallback 策略
fallbacks:
  # 第一层：GPT 主模型挂了 → 切 Claude
  - gpt-5.4: ["claude-sonnet-4.5"]
  
  # 第二层：Claude 也挂了 → 切 DeepSeek
  - claude-sonnet-4.5: ["deepseek-v4-flash"]
  
  # 按请求类型路由
  - gpt-5.4-mini: ["deepseek-v4-flash"]  # 简单任务直接切便宜模型

触发的条件是：连续失败 3 次（allowed_fails: 3），自动切换到 fallback 链的下一个模型。整个过程对调用方完全透明，你的应用代码不需要任何 try-catch。

第三步：限流保护——别再打爆 API Key

LiteLLM 的 rate limit 有两种模式：

# 在 config.yaml 中为每个模型设置限流
- model_name: gpt-5.4
  litellm_params:
    model: openai/gpt-5.4
    api_key: os.environ/OPENAI_API_KEY
    rpm: 400          # 每分钟最多 400 个请求
    tpm: 800000       # 每分钟最多 80 万 Token

# 也可以创建虚拟 Key，每个 Key 有独立的预算和限制
# curl -X POST http://localhost:4000/key/generate \
#   -H "Authorization: Bearer sk-xxx" \
#   -d '{"models": ["gpt-5.4"], "max_budget": 50, "duration": "1d"}'

虚拟 Key 这个功能特别适合团队协作。你可以给前端团队一个 Key 只能用 GPT-4o-mini，给后端团队一个 Key 可以用所有模型但日预算 $20，给实习生一个 Key 只能用 DeepSeek。所有用量和费用都在 dashboard 里一目了然。

第四步：Docker 部署——生产环境就绪

开发环境跑通了，上生产需要 Docker 部署：

# docker-compose.yml
version: '3.8'
services:
  litellm:
    image: ghcr.io/berriai/litellm:main-latest
    ports:
      - "4000:4000"
    volumes:
      - ./config.yaml:/app/config.yaml
    environment:
      - LITELLM_MASTER_KEY=${LITELLM_MASTER_KEY}
      - OPENAI_API_KEY=${OPENAI_API_KEY}
      - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
      - DEEPSEEK_API_KEY=${DEEPSEEK_API_KEY}
      - DATABASE_URL=postgresql://user:pass@db:5432/litellm
    depends_on:
      - db
    restart: always

  db:
    image: postgres:16
    environment:
      - POSTGRES_DB=litellm
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

启动：docker compose up -d。加上 PostgreSQL 后会记录所有请求日志、成本数据和 Token 使用量，方便后续分析。如果只需要基础功能，不配置数据库也能跑。

避坑指南：我踩过的 3 个坑

坑1：DeepSeek 的 API 格式兼容性问题

LiteLLM 对 DeepSeek 的支持是 2026 年才完善的。早期版本中，DeepSeek 的 streaming 响应格式与 OpenAI 有细微差异，导致某些客户端解析失败。解决方法是在配置中显式指定 model: deepseek/deepseek-chat 而不是直接用 OpenAI 兼容模式。

坑2：fallback 链太长导致超时

我最初配置了 5 层 fallback，结果一个请求从 GPT 切到 Claude 再切到 DeepSeek，耗时超过 120 秒。建议 fallback 链不超过 3 层，每层设置合理的超时时间（我用的 30 秒），超时即切换。

坑3：成本追踪不准确

LiteLLM 默认用参考价格计算成本，但实际价格经常变动（比如 DeepSeek V4 在 2026 年 7 月引入了峰谷定价）。建议在 litellm_params 中手动设置 input_cost_per_token 和 output_cost_per_token，确保成本数据准确。

选型建议：什么样的团队适合用 LiteLLM？

如果你恰好是 5-20 人的团队、有 2-3 个 AI 模型在跑，LiteLLM 用半天时间就能搭起来，而且基本不需要后续维护。我在 DeepSeek、OpenAI 和 Claude 三个模型之间切换现在就靠这一套，跑了一个多月没出过问题。

也可以看看 2026 年 AI API 价格地震与多模型路由策略，了解不同模型的定价趋势和选型分析。

如果你也在搭建 AI API 网关，或者对上面提到的方案有疑问，欢迎在 TokenNexus 平台数据库 里对比更多 AI API 平台的详细参数，或者去 LiteLLM GitHub 看官方文档。