Sherconan.

· 14 min read · LLM · Multi-Model Routing · AI Product · Cost Optimization

企业 AI 的 Multi-Model Routing 决策框架：跨 7 家前沿模型的工程化实践

在企业 AI 场景里，单模型方案永远是次优解。本文沉淀我跨 Claude / GPT / Gemini / DeepSeek / Kimi / Qwen / GLM 七家模型做路由决策的五维框架与工程化实践。

TL;DR

  • 单模型方案是 demo 思维。真实企业场景必然是多模型 Routing——因为没有任何一个模型在所有维度都最优。
  • 路由决策的五个核心维度：场景适配度 × 成本 × 延迟 × 上下文窗口 × 合规边界。
  • 实战中 Routing 不是简单的”贵模型走重要 case、便宜模型走简单 case”——你需要场景级 router（按任务类型）+ 降级 fallback（贵的挂了走便宜的）+ 成本闸（每天 / 每用户的硬上限）。
  • 我跨 Claude · GPT · Gemini · DeepSeek · Kimi · Qwen · GLM 七家模型在企业 AI 平台落地的经验沉淀。

一、为什么 Routing 是必选项不是可选项

我见过最常见的反模式是：一个企业 AI 平台从 0→1 时把所有流量全部接到一个模型——通常是某家最贵的旗舰。

理由听起来都很对：“质量最重要”、“我们不差这点钱”、“统一架构好维护”。

但 6 个月以后这套系统会变成什么？

  1. 账单失控：每月 API 费用涨到不可持续，CFO 来问。
  2. 延迟体感差：长上下文场景 API 飙到 30 秒，用户骂。
  3. 合规挂掉：某些数据不能出境 / 不能走某家厂商，整个场景被砍。
  4. 黑天鹅：唯一的模型供应商挂了一小时，你的产品就宕一小时。

核心结论一句话：多模型 Routing 不是”省钱手段”，是企业 AI 产品的健壮性底座。

二、路由决策的五个维度

我用一个五维矩阵评估每个路由分支：

维度关键问题落地表征
Capability · 能力适配这个模型在这类任务上做得怎么样？做完私有 Eval 集打分，不看 leaderboard
Cost · 成本每千 token 多少钱？平均一次调用多少钱？把 prompt + completion 一起算，不只算 input
Latency · 延迟P50 / P95 多少？流式 vs. 非流式？真实业务时段实测，不看官方 benchmark
Context Window · 上下文最大输入多少 token？长上下文性能稳不稳？模型宣称的窗口 ≠ 它在这个长度下还能稳定推理
Compliance · 合规数据能否出境？哪些行业有红线？厂商资质？没确认就别用，事后被砍代价巨大

每个维度都要打分，然后按场景加权——不同场景权重不同。

举个例子：

  • 智能投研场景：Capability 权重高（要拿专业数据说话）+ Context Window 高（研报很长）+ Cost 中（成本可接受）+ Latency 中（用户能等几秒）+ Compliance 高（金融数据红线多）→ Claude Opus / GPT-5 一线
  • 内部 FAQ 检索：Cost 高（用户量大）+ Latency 高（用户体感）+ Capability 中（任务简单）+ Context 低（短查询）→ DeepSeek / Qwen / Kimi 长尾
  • 多模态文档审阅：Capability 高（多模态强）+ Context 高（文档长）+ Compliance 高 → Gemini / Claude Opus
  • 代码生成调用工具：Capability 高（tool use 准）+ Latency 中 → Claude Sonnet / GPT 系列

三、Routing 的工程化模式

Pattern 1 · Scenario-based Router

最朴素的路由，按”业务场景 → 模型”的硬编码映射。

SCENARIO_ROUTING = {
    "research_long_context": "claude-opus-4",
    "internal_faq": "deepseek-v3",
    "code_with_tools": "claude-sonnet-4",
    "multimodal_doc_review": "gemini-2.5-pro",
    "compliance_review": "claude-opus-4",
}

适合：场景边界清晰、流量稳定。 不适合：场景边界模糊、需要内部 LLM 自己决定走哪个分支。

Pattern 2 · Capability-based Classifier

用一个轻量分类器（甚至一个小模型）先判断 query 类型，再路由。

[user query] → [classifier: Haiku/小模型] → {简单 Q / 复杂推理 / 工具调用 / 多模态}
                                          → 路由到对应模型

适合：用户输入开放、场景边界模糊。 坑：classifier 自己也是个模型，要为它单独建 Eval 集，否则路由错的代价比单模型还大。

Pattern 3 · Cascade · 级联降级

先试便宜模型，如果它”不知道”或”置信度低”，升级到更贵的模型。

[query] → [DeepSeek] → confidence < 0.6 → [Claude Sonnet]
                    → confidence >= 0.6 → return

适合：80% 简单查询 + 20% 复杂查询的场景。 关键：confidence 不是模型自报的”我有 90% 信心”——那是幻觉。要用结构化输出 + 后处理判断（如 RAG hit 数量、答案长度、是否包含 abstain 关键词）。

Pattern 4 · Fallback · 黑天鹅兜底

主路径挂了，自动走备用。

try:
    return claude.chat(...)
except (RateLimit, ServerError, Timeout):
    return gpt.chat(...)  # fallback

关键：fallback 链至少 2-3 层，且不能都来自同一家厂商（厂商整体 outage 时全挂）。我们见过 Anthropic / OpenAI 单家 outage 1-2 小时的情况。

Pattern 5 · Cost Cap · 成本闸

按用户 / 按部门 / 按总账户设置每日成本上限，超限自动降级。

if daily_spent > daily_cap:
    use_cheaper_model()
elif user_spent > user_cap:
    queue_or_throttle()

这一层是 PM 必须主导的——工程师默认不会考虑这个，等账单爆了就晚了。

四、一个真实场景：智能审核如何 Routing

以”内部文档智能审核”为例（场景脱敏，逻辑通用）：

业务输入：每天约 1,000 份文档，每份 5K-50K token，需要按”格式 / 内容 / 合规”三个维度审核。

第一版：单模型方案（Claude Opus 全场跑）

  • ✅ 质量 OK
  • ❌ 月度成本 ~$X 万
  • ❌ P95 延迟 > 30 秒
  • ❌ 单一供应商风险

第二版（迭代后）：Routing

  • 格式审核（规则强、模型简单）→ Qwen / DeepSeek（成本只占 1/8）
  • 内容审核（语义判断、要求稳定）→ Claude Sonnet（性价比甜点）
  • 合规审核（红线多、错误代价高）→ Claude Opus（必须最强）
  • Fallback：任何分支挂了，全部降级到 GPT-4o
  • Cost cap：每日总额度 + 每文档 token 上限

结果：

  • 月成本下降 60%
  • P95 延迟从 30s → 12s
  • 黑天鹅风险散到 3 家厂商
  • 合规审核质量保持不变

五、给 PM 的三条经验

1. Routing 决策权必须在 PM 手里

工程师默认会说”我们就用最强的模型”——因为他们不背成本和延迟的锅。PM 必须主动建立 Routing 框架，把每个场景的五维评分写下来，每季度 review 一次。

2. 不要相信厂商 leaderboard

厂商发布的所有 benchmark 都是为了卖货。只信你自己的私有 Eval 集——把你最关键的 100 个 case 跑一遍，每家模型给个分。

我跨七家前沿模型（Claude / GPT / Gemini / DeepSeek / Kimi / Qwen / GLM）在多个企业场景上跑过——每家都有自己最甜点的场景，没有一家全维度最强。

3. 路由本身需要监控

加上 dashboard：

  • 每个模型的调用次数 / 延迟 / 错误率 / 成本
  • 路由分支的分布（是不是某个分支被打爆？）
  • 用户满意度按模型切片（用户其实能感觉到换模型了——做 A/B 看反馈）

后记

下一篇我会写《从 0 到 1 设计企业 AI Agent 架构》——双层结构（Cognition Layer + Execution Layer）、Anthropic 的 Building Effective Agents 五模式、以及如何让一个内部 AI 产品达到 1/3 员工日活的关键 5 步。

GitHub 作品集 github.com/sherconan · 邮件 shinyashokudo@163.com

—— 刘鹏洋 · AI Builder · AI Product Manager · 北京

← 全部文章