模型网关与路由：生产级 LLM Fallback 链设计

当 LLM 应用从 demo 走向生产，"单一模型 + 单一供应商"模式立刻会暴露三大问题：供应商宕机、限流、配额耗尽；不同任务对模型要求不同（代码任务用 Claude 强，闲聊用 GPT-4o 便宜）；多模型 A/B 测试和成本优化。模型网关（Model Gateway）就是为这些问题而设计的统一入口层。本文从工程实战出发，系统讲解模型网关的核心能力、Fallback 链设计、路由策略、限流与配额管理。

为什么需要模型网关

问题 1：供应商故障 2024-2025 年，OpenAI、Anthropic、Google 都发生过不同规模的服务中断（rate limit、SLO 违反、区域性故障）。单供应商应用一旦供应商宕机，整个系统不可用。

问题 2：成本失控 不同任务对模型要求不同：

• 简单闲聊：用 GPT-4o-mini 即可（$0.15/1M input tokens）
• 复杂代码：用 Claude Sonnet 4 ($3/1M input tokens)
• 高级推理：用 o1 / Claude Opus 4.1 ($15-75/1M)

如果所有请求都用最强模型，月度账单会爆炸；如果都用最弱模型，质量又不够。

问题 3：多供应商管理 不同供应商 API 格式不同（OpenAI、Anthropic、Google、Mistral、DeepSeek、Bedrock），每接一个就要写一套适配器。维护成本高。

问题 4：可观测性 直接调供应商 API，缺乏统一的请求日志、token 计数、成本归因、失败统计。

模型网关解决：把以上 4 个问题统一在一个入口层。

主流模型网关对比

网关	形态	多供应商	Fallback	路由策略	部署
LiteLLM	开源	100+	是	丰富	自托管
Portkey	SaaS + 开源	250+	是	丰富	SaaS / 自托管
Bifrost (Maxim)	开源	多	是	中等	自托管
OpenRouter	SaaS	100+	是	路由	SaaS
Cloudflare AI Gateway	SaaS	多	是	简单	SaaS
Kong AI Gateway	开源	多	基础	简单	自托管
MLflow AI Gateway	开源	多	基础	简单	自托管

LiteLLM 是当前最主流的开源选择，100+ 供应商支持，企业级特性完善。Portkey 是 SaaS + 开源混合模式，UI 友好。Maxim Bifrost 是新兴的 Rust-based 网关，性能更好。

LiteLLM 自托管

# config.yaml
model_list:
  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY
      rpm: 10000
      tpm: 1000000
  
  - model_name: claude-sonnet-4
    litellm_params:
      model: bedrock/anthropic.claude-sonnet-4-20250514-v1:0
      aws_access_key_id: os.environ/AWS_ACCESS_KEY_ID
      aws_secret_access_key: os.environ/AWS_SECRET_ACCESS_KEY
      aws_region_name: us-east-1
      rpm: 5000
      tpm: 500000
  
  - model_name: deepseek-chat
    litellm_params:
      model: openai/deepseek-chat
      api_key: os.environ/DEEPSEEK_API_KEY
      api_base: https://api.deepseek.com/v1
      rpm: 50000  # DeepSeek 限额高
      tpm: 5000000

router_settings:
  routing_strategy: usage-based-routing-v2
  num_retries: 3
  timeout: 30
  allowed_fails: 2
  cooldown_time: 30

litellm_settings:
  drop_params: true
  set_verbose: false
  telemetry: false

启动：

docker run -d \
  --name litellm \
  -p 4000:4000 \
  -v $(pwd)/config.yaml:/app/config.yaml \
  -e OPENAI_API_KEY=$OPENAI_API_KEY \
  ghcr.io/berriai/litellm:main-latest \
  --config /app/config.yaml

调用方式（与 OpenAI 客户端兼容）：

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:4000",
    api_key="anything",  # 网关会用自己的 key
)

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Hello"}],
)

Fallback 链设计

Fallback 链是模型网关的核心能力——当主模型失败时，自动切换到备用模型。

基本 Fallback 模式：

# 主 + 备
- model_name: production
  litellm_params:
    model: openai/gpt-4o
    fallbacks: [gpt-4o-mini, claude-sonnet-4]

- model_name: gpt-4o-mini
  litellm_params:
    model: openai/gpt-4o-mini

- model_name: claude-sonnet-4
  litellm_params:
    model: bedrock/anthropic.claude-sonnet-4-20250514-v1:0

fallbacks 参数：定义主模型失败时尝试的备选模型列表，按顺序尝试。

实际生产场景的 Fallback 策略：

# 场景 1: 主备（成本优化）
- model_name: gpt-4o
  fallbacks: [gpt-4o-mini, claude-sonnet-4]
  # gpt-4o 失败 -> gpt-4o-mini -> claude-sonnet-4

# 场景 2: 多供应商（可靠性）
- model_name: production-premium
  fallbacks: [openai-premium, anthropic-premium, google-premium]
  # 任一顶级模型失败，切换到下一个

# 场景 3: 任务感知（智能路由）
- model_name: code-task
  fallbacks: [claude-sonnet-4, gpt-4o, deepseek-coder]
  # 代码任务：首选 Claude，失败切到 GPT-4o，再切到 DeepSeek Coder

- model_name: chat-task
  fallbacks: [gpt-4o-mini, claude-haiku, deepseek-chat]
  # 闲聊任务：优先用便宜模型

Fallback 触发条件（LiteLLM 默认）：

• 429 限流
• 408/504 超时
• 5xx 服务器错误
• 上下文超限
• 显式 throw 异常

重试与冷却：

router_settings:
  num_retries: 3              # 失败重试 3 次
  timeout: 30                 # 单次请求超时 30s
  allowed_fails: 2            # 允许连续失败 2 次
  cooldown_time: 30           # 冷却时间 30s

cooldown_time 机制：模型失败后，30s 内不直接调用，先尝试其他模型；30s 后再次尝试主模型。

路由策略

1. 任务感知路由

from litellm import Router

router = Router(model_list=[
    {"model_name": "fast-model", "litellm_params": {"model": "openai/gpt-4o-mini"}},
    {"model_name": "smart-model", "litellm_params": {"model": "openai/gpt-4o"}},
    {"model_name": "code-model", "litellm_params": {"model": "bedrock/anthropic.claude-sonnet-4-20250514-v1:0"}},
])

async def route_request(prompt: str, task_type: str):
    if task_type == "code":
        model = "code-model"
    elif task_type == "complex":
        model = "smart-model"
    else:
        model = "fast-model"
    
    return await router.acompletion(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )

2. 成本感知路由

import random

# 90% 简单任务用便宜模型，10% 复杂任务用贵模型
def cost_aware_route(prompt: str) -> str:
    if is_complex(prompt):
        return "gpt-4o"  # 复杂任务用强模型
    
    # 简单任务：50% gpt-4o-mini，30% claude-haiku，20% gpt-4o
    rand = random.random()
    if rand < 0.5:
        return "gpt-4o-mini"
    elif rand < 0.8:
        return "claude-haiku"
    else:
        return "gpt-4o"

3. 用户/租户路由

# 不同租户用不同模型
TENANT_MODEL_MAPPING = {
    "free": "gpt-4o-mini",
    "pro": "gpt-4o",
    "enterprise": "claude-sonnet-4",
}

def tenant_route(tenant_id: str) -> str:
    tier = get_tenant_tier(tenant_id)
    return TENANT_MODEL_MAPPING[tier]

4. A/B 测试路由

import hashlib

# 按 user_id 哈希分桶
def ab_route(user_id: str) -> str:
    bucket = int(hashlib.md5(user_id.encode()).hexdigest(), 16) % 100
    if bucket < 50:
        return "gpt-4o"  # 50% 用户
    else:
        return "claude-sonnet-4"  # 50% 用户

限流与配额

# 按租户限流
- model_name: gpt-4o
  litellm_params:
    model: openai/gpt-4o
  model_info:
    rpm: 10000        # 每分钟请求数
    tpm: 1000000      # 每分钟 token 数

# 虚拟模型 + 别名（rate limiting by alias）
- model_name: free-tier-gpt-4o
  litellm_params:
    model: openai/gpt-4o
  model_info:
    rpm: 60          # 限制每分钟 60 次

更细粒度的限流需要使用 API Gateway（Kong / Apigee）+ LiteLLM 组合。

缓存策略

LiteLLM 内置语义缓存，可以显著降低成本：

litellm_settings:
  cache: true
  cache_params:
    type: redis
    host: redis.internal
    port: 6379
    ttl: 3600        # 缓存 1 小时
    similarity_threshold: 0.95  # 相似度阈值

语义缓存 vs 精确匹配缓存：

• 精确匹配：完全相同的 prompt 才命中
• 语义匹配：相似度 > 0.95 的 prompt 视为相同

成本节省（典型 LLM 应用）：

• 精确匹配：10-30% 命中率
• 语义匹配：40-70% 命中率
• 月度成本节省 30-60%

监控与可观测性

LiteLLM 内置 Prometheus metrics：

litellm_settings:
  telemetry: false
  success_callback: ["prometheus"]
  failure_callback: ["prometheus", "sentry"]

关键 metrics：

• litellm_request_total：按模型/状态/租户统计
• litellm_tokens_total：按模型/方向统计
• litellm_cost_total：按模型/租户统计（美元）
• litellm_latency_seconds：按模型统计 P50/P95/P99
• litellm_fallback_total：fallback 触发次数

Grafana 仪表盘模板：

# 推荐监控面板
panels:
  - title: "Request Volume by Model"
    query: "rate(litellm_request_total[5m]) by (model)"
  
  - title: "Cost per Hour"
    query: "sum(rate(litellm_cost_total[1h]))"
  
  - title: "P95 Latency by Model"
    query: "histogram_quantile(0.95, rate(litellm_latency_seconds_bucket[5m])) by (model)"
  
  - title: "Fallback Rate"
    query: "rate(litellm_fallback_total[5m]) / rate(litellm_request_total[5m])"

告警规则：

• 任意模型错误率 > 5%（5 分钟内）
• Fallback 触发率 > 10%（说明主模型不稳定）
• 单小时成本 > 预算 80%
• P99 延迟 > SLA 2 倍

部署模式

# docker-compose.yml
services:
  litellm:
    image: ghcr.io/berriai/litellm:main-latest
    ports:
      - "4000:4000"
    volumes:
      - ./config.yaml:/app/config.yaml
    environment:
      - OPENAI_API_KEY
      - ANTHROPIC_API_KEY
      - AWS_ACCESS_KEY_ID
      - AWS_SECRET_ACCESS_KEY
    deploy:
      replicas: 2
  
  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"
  
  prometheus:
    image: prom/prometheus:latest
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml

生产环境建议：

• LiteLLM 至少 2 副本（高可用）
• Redis 集群（缓存高可用）
• 接入 OpenTelemetry（统一可观测性）
• 限流在网关层做（LiteLLM 上游）

实施路径

第 1 周：部署 LiteLLM，配置 2-3 个主流模型。第 2 周：在现有应用里替换 OpenAI client 为 LiteLLM client。第 3 周：建立 Fallback 链，覆盖至少 1 个主 + 2 个备。第 4 周：实现任务感知路由（代码用 Claude，闲聊用 GPT-4o-mini）。第 5 周：开启语义缓存，观察成本节省。第 6 周：建立 Grafana 仪表盘和告警规则。

总结

模型网关是 LLM 生产化的"必备基础设施"。从单一供应商到多供应商，从单一模型到任务感知路由，从"乱花钱"到"成本优化"——这些都是规模化 LLM 应用绕不开的问题。

LiteLLM 是当前最成熟的开源选择，Portkey 适合 SaaS 偏好。核心是 Fallback 链 + 任务感知路由 + 语义缓存——这三件事做好，单月成本可以降低 30-50%，可用性从 99.5% 提升到 99.99%。

参考工具：LiteLLM（100+ 模型统一接口）、Portkey（AI Gateway + Observability）、Maxim Bifrost（Rust-based 高性能 AI Gateway）、Bifrost（同 Bifrost）和 Cloudflare AI Gateway（Cloudflare 托管的 AI Gateway）覆盖了模型网关工具链的核心节点。