4.1 多模型路由策略

4.1 多模型路由策略

当你的系统里同时存在多个模型时，第一个要回答的问题不是"哪个模型最强"，而是"这个请求，应该交给谁"。路由策略的本质，是把业务诉求翻译成一条确定性的模型选择链路。

路由矩阵该怎么写

落到工程上，路由矩阵就是一张把「业务场景 → 候选模型集合 → 默认优先级」固化的配置表。它不该散落在代码里，而应该是独立、可热更新的配置，最好带版本。举个例子（字段为示意）：

routes:
  - scene: 实时语音补全
    latency_sla_ms: 200
    candidates: [small_model_a, small_model_b]
    default: small_model_a
    fallback: mid_model
  - scene: 复杂代码生成
    latency_sla_ms: 8000
    candidates: [flagship_model, mid_model]
    default: flagship_model
    fallback: mid_model
  - scene: 金融合规问答
    compliance: in_region_cn
    candidates: [local_compliant_model]
    default: local_compliant_model
    fallback: none   # 合规场景不允许降级到境外
​

这张表的妙处在于：路由引擎只认表，不认硬编码。供应商谈判降价、新模型上线、某供应商限流，都只是改表 + 灰度，不动业务逻辑。这也是我把路由称为「可迭代资产」的原因。

难度分类器的训练与冷启动

如果你决定上分类器，冷启动阶段可以用「规则先跑、人工抽样标注」快速攒第一批训练数据；随后用轻模型（如几亿参数的小模型）做二分类或三分类（简单/中等/复杂）。注意几点：

• 标签要基于结果而非直觉：「这条请求是否真的被小模型答好」才是金标准，而不是工程师觉得它简不简单。
• 类别要可行动：分类的档位必须直接对应到你的模型档位，避免出现「分了类却不知道该调谁」的尴尬。
• 保留拒绝通道：分类置信度低于阈值的请求，宁可走默认强模型或升级，也不要赌。

路由的四个核心维度

实际工程中，路由几乎总是围绕四个维度展开，它们彼此叠加而非互斥。理解这四个维度，是设计路由层的前提。

1. 按难度路由

这是收益最直接、也最容易上手的维度。大量真实流量里，闲聊、问候、格式转换、简单抽取这类请求，轻量模型完全能胜任；而多步推理、复杂代码、长文写作才需要旗舰模型。

难点在于"如何判断难度"。常见有三种做法：

• 启发式规则：根据意图分类、输入长度、是否含代码块、是否要求"逐步思考"等特征直接判定。好处是零延迟、可解释；坏处是覆盖不全，长尾难处理。
• 轻模型分类器：用一个小型模型对请求打"难度分"，本质是个文本分类任务。成本极低，效果通常优于纯规则，适合中等规模团队。
• LLM-as-Judge 兜底：对高价值或高不确定请求，用强模型评估"弱模型能否答好"，据此动态升级。这是质量优先场景的常用保险，代价是额外一次调用。

我的建议是：先用规则把明显的简单/复杂分流，再用分类器兜住中间地带，最后对关键路径保留"升级通道"。不要一上来就追求全自动判断，那样你会花大量时间调分类器，却忘了路由的初衷是降本增效。先让"省下来的钱"可见，再逐步精细化。

2. 按成本路由

成本路由和难度路由高度相关，但视角不同：它是从"这条链路值不值这个价"出发。典型做法是分层定价——非关键路径（如内部质检、日志摘要、草稿生成）一律走低价的本地或开源模型；直接面向用户且影响转化的核心链路，才允许调用高成本模型。

实践中建议维护一张"成本-质量"对照矩阵，把每个业务场景映射到允许的模型集合，路由时再在集合内做延迟/可用性择优。这比硬编码"某场景必须用某模型"要灵活得多，也方便后续供应商谈判后整体切换。

举一个量化的例子。假设旗舰模型每千 token 成本是小模型的 10 倍，而你日常流量里 60% 是闲聊与简单问答。若成功把这些流量导到小模型，单次对话平均成本可能直接下降 40%–55%，而用户侧感知的"答得变差"比例可能不到 2%，前提是你的难度分类足够准。这个账，是路由层最硬的价值证明。它也是你和财务、和业务方谈资源时最有说服力的材料——用数字说话，而不是用「我觉得小模型够用」去争论。

再补一个反例：某团队把"所有含代码的请求"一刀切路由到旗舰模型，结果大量"把这段话改成驼峰命名"之类的轻量需求也吃掉了旗舰模型额度，月末账单暴涨，而用户根本没感知到质量差异。这就是没做难度细分、只按关键词硬路由的典型代价。

3. 按延迟路由

对话产品的延迟敏感度差异极大。实时语音转写后的补全要求百毫秒级响应，而后台批量摘要可以容忍数秒。延迟路由就是按 SLA 把请求导向不同档位的模型：低延迟档优先选响应快、参数量小的模型；高延迟容忍档才考虑质量优先。

需要提醒的是，延迟路由和难度路由有时会冲突——一个"简单但用户正在实时等待"的请求，可能既要小模型（够用）又要低延迟（小模型天然更快），两者一致；但一个"复杂且实时"的请求，你就要在"答案质量"和"响应速度"之间做显式取舍，并把结论沉淀进路由矩阵。

4. 按合规与地域路由

这是"非技术性但不可绕开"的维度。数据本地化、行业监管（金融、医疗等）、内容审核策略，决定了某些请求必须落在指定地域的指定模型上。路由层需要把"合规标签"作为最高优先级约束——一旦命中，后面的成本、难度统统让位。

合规路由还有一个容易被忽视的要求：可审计。每一次"因合规而锁定模型"的决策，都应该留痕，方便监管核查。这不是性能问题，而是合规底线，务必在路由引擎里做成一等公民。

路由决策引擎怎么落地

把上面四个维度变成一个可执行的决策，需要一层"路由决策引擎"，它通常包含三步：

1. 特征提取：从请求里取出意图、长度、是否含代码、用户等级、来源场景、合规标签等。
2. 多维打分：每一维给出候选模型集合与优先级，再做交集与加权。合规是硬约束（不满足直接淘汰），其余维度加权后取最优。
3. 决策执行 + 回写：选定模型链路后调用，并把"这次路由选择"连同后续质量反馈写回，用于优化分类器。

一个常被忽略的工程细节：路由结果本身值得缓存。同一用户、同类意图、相似输入的请求，路由选择往往稳定，把路由决策结果短暂缓存（结合第 3 章的缓存思路），可以省掉大量重复分类开销。注意缓存键要避开隐私字段，只基于"路由相关特征"。

路由层的三种部署形态

• 集中式路由服务：独立微服务，所有请求先过路由再调用模型。优点集中治理、易观测；缺点是多一跳延迟，需保证自身高可用。
• Sidecar / 网关内嵌：路由逻辑嵌在网关或 sidecar 里，减少一跳。适合对延迟极敏感的场景，但治理分散。
• SDK 内联：路由逻辑打包成 SDK，业务进程内调用。延迟最低，但版本升级成本高、难统一。

我的倾向是：中大型团队用集中式路由服务，把"路由策略"作为独立可迭代的资产；极致延迟场景再考虑网关内嵌。无论哪种，路由决策都必须可观测、可回放。

路由质量的度量

路由不是"配完就完事"。你需要持续度量它到底有没有达成目标：

• 成本节省率：路由后相比"全量走旗舰模型"省下的比例。这是说服老板继续投入路由层的关键指标。
• 路由准确率：被路由到轻模型的请求中，真正能被轻模型答好的比例（用质量分数或用户反馈衡量）。
• 升级率与误判率：需要二次升级的请求占比，以及因误判导致体验受损的比例。

一个容易被低估的度量对象是 路由分布漂移。每周看一眼「各模型承接流量占比」是否剧烈变化：如果某天小模型占比突然从 60% 跌到 30%，要么分类器出 bug，要么上游流量结构真变了——无论哪种，都值得立刻排查。把路由分布当作核心监控看板，比等用户投诉早发现问题数小时。

我的经验是：先把成本节省率跑出来证明价值，再用升级率守住质量底线。只看成本不看质量，路由会变成"省钱但劝退用户"的陷阱；只看质量不看成本，路由就退化成摆设。

校准闭环

路由策略最好的状态是"越用越准"。做法是把每次调用的结果（质量分、用户点赞/点踩、是否触发升级）回流到分类器训练集，定期重训。这个闭环一旦跑起来，路由准确率会随流量增长而自然提升，形成正反馈。

常见坑

• 过度路由：给每个细微差异都建一条独立链路，最后维护成本爆炸。建议先收敛到 2–3 条主链路。
• 分类器自嗨：花大力气调分类器，却没接质量反馈，导致"路由看起来很智能，实际答得很差"。
• 忽略长尾：绝大多数流量好分，但 1% 的诡异请求会反复触发升级，要单独看长尾、设兜底。
• 合规漏判：把合规当成普通权重，结果敏感数据走了境外模型。合规必须硬约束、且可审计。
• 路由层自身单点：路由服务挂了等于全站不能调模型。路由层必须比被路由的模型更可靠，或至少要有"失败默认链路"。

小结：路由策略不是选"最强模型"，而是给每类请求找到"最合适的模型"。难度、成本、延迟、合规四个维度叠加，配合一个可度量、可回写、可审计的决策引擎，才能在百万 QPS 下既控住成本，又守住体验与合规底线。