LLM 路由与多模型网关降本实战：一份生产级多模型架构

一个生产级 LLM 应用不会只接一个模型。当你同时跑 GPT-4o 做复杂推理、GPT-4o-mini 做摘要、Claude Sonnet 做代码、Llama 3.1 70B 跑本地兜底时，你面对的不是"接一个 API"，而是"管理 4 个 provider × N 个模型 × 几十个 fail 模式"。这就是 LLM 网关存在的理由——把所有模型访问抽象成统一接口，附带给一份按请求级别的成本/延迟观测。本文横评四款主流方案（Portkey、AgentGateway、OpenRouter Agents、Claude Code Router），给出一份可直接抄走的生产架构。

为什么需要 LLM 网关

直接 import openai; import anthropic; ... 能跑，但有三个硬伤会在生产里爆发：

1. Provider fail-over 缺位。OpenAI 一次 5xx，你只能在自己的代码里加 try/except；多 provider 切换意味着每条路径都要写一遍。
2. 成本不可观测。哪个用户在用什么模型、消耗了多少 token、为什么一周账单突然翻倍——没有统一埋点就答不上来。
3. 路由策略散落。A 类请求用 Sonnet、B 类用 mini、C 类用本地模型——把这些规则硬编码在业务代码里，重构时就是噩梦。

LLM 网关把这三件事从业务层抽出来，变成配置项 + middleware。

四款主流方案速览

维度	Portkey	AgentGateway	OpenRouter Agents	Claude Code Router
部署	SaaS + 自托管	自托管	SaaS	本地 CLI
支持 provider 数	200+	通用（HTTP/MCP）	100+	主要面向 Claude
路由策略	标签 + 条件	通用 middleware	自动 + 手动	编程场景规则
成本观测	内置 dashboard	需外接	内置	基础日志
接入方式	SDK / HTTP proxy	HTTP proxy	SDK / HTTP	CLI 配置
最强项	厂商中立 + 完备观测	多协议适配（MCP/HTTP）	自动路由	代码 Agent 场景调优
最弱项	自托管复杂	文档较少	锁定 OpenRouter	仅 Claude Code

模式一：多模型 fallback ——「不要把鸡蛋放一个篮子」

最朴素的诉求：OpenAI 挂了，Claude 顶上；GPT-4o 限流了，mini 顶上。Portkey 的配置长这样：

# portkey-config.yaml
targets:
  - provider: openai
    model: gpt-4o
  - provider: openai
    model: gpt-4o-mini
  - provider: anthropic
    model: claude-sonnet-4-20250514

# 路由策略：主备 + 自动降级
strategy:
  mode: fallback
  conditions:
    - if: "status_code == 429"   # 限流
      then: jump_to_next
    - if: "latency_ms > 5000"    # 慢
      then: jump_to_next
    - if: "status_code >= 500"   # 5xx
      then: jump_to_next

AgentGateway 用 middleware 表达同样的逻辑：

# agentgateway.yaml
routes:
  - match: { path: /v1/chat }
    chain:
      - retry: { max: 2, backoff: exponential }
      - fallback:
          - { provider: openai, model: gpt-4o }
          - { provider: anthropic, model: claude-sonnet-4-20250514 }
          - { provider: ollama, model: llama3.1:70b }   # 本地兜底

fallback 的关键不是「写配置」而是「定义降级链」。一个稳健的降级链遵循三个原则：

• 从强到弱：Sonnet → GPT-4o → mini → 本地模型
• 从快到慢：Sonnet → GPT-4o mini（高频低延迟） → 本地（保底不报错）
• 从贵到便宜：业务压力大时降级是隐性省钱

模式二：智能路由 —— 按请求特征选模型

更进阶的玩法是「按请求内容选模型」——gpt-4o 处理长 reasoning、gpt-4o-mini 处理短摘要、本地模型处理 PII 敏感的内部请求。OpenRouter Agents 的「auto」模式内置了这个能力：

from openrouter import OpenRouter

client = OpenRouter(auto_route=True)
resp = client.chat(
    messages=[{"role": "user", "content": "总结这段 200 字文档"}],
    # 内部根据 token 数、复杂度、可用性自动选模型
)
print(resp.model)        # 'gpt-4o-mini'
print(resp.routing_log)  # 路由决策的 trace

自定义路由规则用 Portkey 的 conditional 模式：

# portkey-config.yaml
strategy:
  mode: conditional
  conditions:
    - if: "request.tokens < 500"
      then: { provider: openai, model: gpt-4o-mini }
    - if: "request.tokens > 500 && request.tokens < 4000"
      then: { provider: openai, model: gpt-4o }
    - if: "request.metadata.contains_pii == true"
      then: { provider: ollama, model: llama3.1:70b }
    - else: { provider: openai, model: gpt-4o-mini }

智能路由的实战建议：

• 先做 A/B 测：不要凭直觉选路由规则，用 Langfuse 或 Phoenix 跑 1 周看哪个组合的成本/质量 Pareto 最优
• 路由规则写到 config，不要写进代码：业务代码应该只关心"我需要 LLM"，不关心"用哪个 LLM"
• 路由要可观测：每个请求必须记录"为什么选了模型 X"，否则一个月后没人能解释

模式三：成本观测 —— 一份给 CFO 看的账单

LLM 网关的最大隐性价值是统一的成本观测。Portkey 的 dashboard 默认提供：

• 每日 / 每周 / 每月的 token 消耗
• 按 provider / model / 用户 / tag 拆解
• 慢请求 / 失败请求 / 重试请求占比
• 单条请求的完整 trace

AgentGateway 把这些原始数据导出到 Prometheus：

# agentgateway.yaml
observability:
  metrics:
    export: prometheus
    endpoint: /metrics
  traces:
    export: otlp
    endpoint: http://otel-collector:4317

成本观测的四个关键指标：

1. 单请求 token 成本（按模型 + 业务 tag 聚合）
2. Provider 失败率（触发 fallback 的占比）
3. 路由命中率（cheap 模型能 cover 的请求占比）
4. 月末预测偏差（线性外推 vs 实际账单）

把这四个指标接到 Grafana，配上 Slack 告警，周会汇报时你能直接告诉 PM "上周这功能消耗 X 美元，比预测高 Y%"。这是说服 PM 减配模型的硬数据。

模式四：场景调度 —— 不同任务用不同模型

代码 Agent 场景下，模型选择直接决定 token 成本——一次复杂重构如果用 Sonnet 可能烧 5 美元，用 mini 烧 0.2 美元，效果差异却不大。Claude Code Router 的设计就是为此：

// ~/.claude-code-router/config.json
{
  "default": "anthropic,claude-sonnet-4-20250514",
  "background": "ollama,llama3.1:8b",   // 后台补全用本地
  "longContext": "openai,gpt-4o",         // 长 context 切 GPT
  "think": "anthropic,claude-sonnet-4-20250514",  // 推理任务用最强
  "webSearch": "openai,gpt-4o-mini",     // 简单搜索用最便宜
  "routes": {
    "explain_code": "openai,gpt-4o-mini",
    "write_test": "anthropic,claude-sonnet-4-20250514"
  }
}

场景调度的核心是用对地方用贵的、用错地方用便宜的。一个经验法则：

• 1k token 内的任务（短摘要、分类、改写）→ mini/本地
• 4k-32k token 的推理任务 → Sonnet / GPT-4o
• 32k+ 的长文档任务 → 200k context 的模型（GPT-4o、Claude Sonnet 4.5）
• 代码生成 → Sonnet / Qwen-Coder / Continue
• 多轮对话 / function call → 各家旗舰

决策框架：怎么选

1. 你的请求主要来自编程 Agent（Claude Code / Continue / Cursor）？
   • 是 → 选 Claude Code Router（场景调度最细）
2. 你需要 SaaS 化的成本 dashboard？
   • 是 → 选 Portkey（dashboard 最成熟）
3. 你要在 AI Agent / MCP 场景下做统一流量管理？
   • 是 → 选 AgentGateway（多协议适配）
4. 你不想自托管，预算按 token 走？
   • 是 → 选 OpenRouter Agents（开箱即用）

三个常见失败模式

失败 1：fallback 链没有「保底」。三个云模型都挂了你怎么办？链路末端必须是本地模型或缓存响应——不能直接 502 给用户。

失败 2：路由规则没做灰度。一次切换 100% 流量到新模型可能引发大规模回归。用 5%-10% 灰度 → 30% → 100%，每步观察 1 小时再放大。

失败 3：成本 dashboard 没人看。搭一个 dashboard 然后再也没人打开，账单爆炸时才发现。把「每用户每日 token 成本」告警直接接到 Slack，超阈值就 page。

总结

• LLM 网关 = 统一接口 + 多模型 fallback + 智能路由 + 成本观测。
• Fallback 链必须包含本地模型或缓存保底，不能直接 502。
• 路由规则写在 config 不写代码，让业务层不关心模型选择。
• 成本观测必须告警化，dashboard 没人看 = 没有观测。

下一步可以从 Portkey SaaS 跑通：接 1 个 OpenAI + 1 个 Anthropic，配一个 fallback 链 + 路由规则，让一次请求的成本和 latency 都打到 dashboard 上，看一周后再决定要不要上自托管。