几乎所有生产系统的流量都长成同一个形状：大量简单请求 + 少量困难请求。「帮我把这段话改得正式一点」和「分析这三份财报的矛盾之处」被同一个入口接收，然后被同一个最强的模型处理。前者用一个小两个数量级的模型也能做得很好，你却为它付了旗舰价格。
与此同时，模型的能力-价格谱系非常宽：同一家厂商的小模型与旗舰模型之间，单位 token 价格常常差出一到两个数量级，自托管的小模型更是可以把边际成本压到接近于零。model routing（模型路由）要做的就是把这两件事对上：让每个请求落到「刚好够用」的那一档模型上。
这里的收益结构值得先算清楚。假设 80% 的请求可以由便宜 20 倍的小模型胜任：
注意最后一行——这是路由最重要的直觉：即使小模型完全免费，成本也降不到 0.20 以下。困难请求构成了成本的地板。所以路由的收益天花板由「简单请求的占比」决定，而不是由「小模型有多便宜」决定。在动手之前，先去测你的流量里简单请求究竟占多少；如果只有 30%，那么再精妙的路由也救不了你。
① 静态路由：按任务类型硬编码。「意图分类走小模型、复杂推理走大模型」。优点是可预测、可解释、零额外延迟；缺点是粒度粗——同一类任务里也有难有易。这是绝大多数团队应该先做的版本，往往已经吃掉了大部分收益。
② 学习式路由：训一个轻量分类器，直接预测「这个请求小模型能不能搞定」。粒度细得多，但它要解决一个本质困难——在没看到答案之前判断答案好不好。这个判断天然不可靠，且需要标注数据来训练。
③ 级联（cascade）：先用小模型跑，再用某种手段检验结果（置信度信号、规则校验、甚至让模型自评），不合格则升级到大模型重做。它把「预测难度」换成了「验证质量」——后者通常容易得多。代价是被升级的请求付了两遍成本、两倍延迟。
这个推导给出一个反直觉的结论：只要两档模型的价差够大，级联在成本上几乎稳赚。它真正的代价在延迟——被升级的请求要串行经历两次完整推理，P99 延迟会明显恶化。所以级联适合对成本敏感、对尾部延迟宽容的场景（如异步批处理、后台任务），不适合语音对话这类 TTFT 敏感的场景。
这是设计路由时最容易被忽略的一点。两类错误的后果完全不同：
把简单请求路由到大模型——多花了钱，用户毫无感知。这是一个可以承受的错误。
把困难请求路由到小模型——用户收到一个错误或劣质的回答。这是产品事故，而且往往悄无声息：没有报警、没有异常日志，只有用户默默流失。
因此路由阈值不应该按准确率最优来调，而应该按代价最优来调——刻意偏保守，宁可多走一些大模型。一个实用的做法是：把阈值调到「小模型误接困难请求」的比例低于某个业务可接受的上限，然后在这个约束下最大化小模型的分流比例。先定质量底线，再谈省钱。
LMSYS 团队把「该用强模型还是弱模型」形式化成一个可学习的问题，并用一个现成的数据源来训练它：Chatbot Arena 的人类偏好数据——大量「同一个问题，两个模型的回答，人类选了哪个」的记录。这些数据天然编码了「哪类问题上强弱模型的差距大、哪类问题上差不多」的信息，而后者正是路由决策所需的全部。
三个数字的差异比数字本身更有信息量。同一套方法，在 MT Bench 上省 85%，在 GSM8K 上只省 35%——这不是方法不稳定，而是三个基准的请求难度分布不同。MT Bench 含大量开放式对话，弱模型也能给出人类满意的回答；GSM8K 是数学推理，强弱模型的能力差距真实存在且难以回避。
这印证了本章开头的判断：路由的收益上限由你的流量构成决定。别人报告的节省比例对你几乎没有参考价值，除非你的请求难度分布和他相似。上线路由前的第一件事不是选算法，而是在自己的真实流量上测出「小模型足够好」的请求占比。
另一个值得借鉴的是数据来源的选择：他们没有专门标注「这个问题难不难」，而是复用了已有的偏好对比数据。这个思路可以直接搬到自己的系统里——线上已有的用户重试、点踩、人工接管记录，就是现成的路由训练信号。
开源框架：RouteLLM 提供可直接替换 OpenAI 客户端的路由实现，附带在偏好数据上训好的路由器；各类 LLM 网关（LiteLLM 等）普遍支持基于规则的多模型路由与自动回退。
厂商内置：部分商业 API 已提供「自动选择模型档位」的接口形态，由服务端决定用哪一档。便利之处是零改造，代价是路由逻辑不透明、无法按自己的质量底线调整阈值——对质量敏感的场景应保留自己控制路由的能力。
路由器本身的成本：学习式路由的分类器必须极轻（小型 embedding 模型 + 逻辑回归量级），否则路由开销会吃掉分流省下的钱，还会给每个请求加上一段固定延迟。用 LLM 做路由判断通常是错误的选择——你为了省钱又多调了一次模型。
与缓存的相互作用：路由到不同模型意味着缓存池也被分割（见 2.2）。若两档模型各自维护前缀缓存，分流会降低各自的命中率。流量不大时，路由省下的钱可能抵不过缓存命中率下降的损失，值得实测。
必须监控的三个指标：各档模型的分流比例、级联的升级率、以及按档位分开统计的质量指标。第三个最常被遗漏——总体质量指标会把小模型的退化平均掉，必须按档位分桶才能看见。
第一步：先算收益上限，判断值不值得做。理想情况（60% 完美分流）成本 = 0.6 × (1/15) + 0.4 × 1 = 0.04 + 0.40 = 0.44，即最多省 56%。关键认识：那 40% 的困难请求锁死了 0.40 的成本地板，任何路由方案都突破不了。如果省 56% 不足以改变项目的经济性，就不该在这上面投入。
第二步：先上静态路由，不要一上来就训模型。把可以按规则识别的简单任务（摘要、格式化、关键词抽取、短问答）直接指向小模型。这通常能拿到理论收益的大半，且当天就能上线、随时可回滚。
第三步：用级联覆盖规则识别不了的部分。文档问答对尾部延迟通常宽容（用户已经准备好等一会儿），符合级联的适用条件。按上文公式，价差 1/15 时只要升级率 < 93% 就比全走大模型便宜——成本上几乎稳赚。检验手段优先选确定性的：答案是否包含有效引用、是否符合输出 schema、是否回答了问题（而非拒答）。
第四步：有了线上数据再考虑学习式路由。级联的升级记录天然就是训练数据——「这条请求小模型失败了」就是标签。此时训路由器的边际成本很低，且能把两次调用的延迟代价降下来。
贯穿始终：先定质量底线。上线前明确「小模型误接困难请求」的可接受上限，按它调阈值；监控必须按档位分桶，否则小模型的质量退化会被平均掉。灰度发布，从 10% 流量开始。
成本：E = 1 + 0.25 × 12 = 4 单位，相比全走大模型的 12 单位，省 67%。
平均延迟：E = 500 + 0.25 × 2000 = 1000ms，相比 2000ms 改善 50%（75% 的请求只花 500ms 就返回了）。
P99 延迟：这是要害。被升级的请求延迟 = 500 + 2000 = 2500ms，比全走大模型的 2000ms 恶化了 25%。由于升级率 25% > 1%，P99 必然落在被升级的那部分里。
结论：级联同时改善了成本和平均延迟，却恶化了尾部延迟——而尾部延迟恰恰是 SLA 通常约束的那个。这就是为什么级联适合异步与后台任务，在交互式场景中要格外谨慎。
可行的缓解：对判定为「大概率会升级」的请求跳过小模型直接走大模型（即用轻量路由器为级联做预筛），把两种模式组合起来。
两类错误后果完全不同。把简单请求送给大模型：多花钱，用户无感知，可测量、可容忍。把困难请求送给小模型：用户拿到劣质答案，是产品事故——而且它不会触发任何报警，系统一切正常，只有用户在沉默中流失。
对阈值的影响：不能按「路由准确率最高」来调阈值，因为准确率把两类错误同等看待。应当刻意偏向保守：先设定「困难请求被误路由到小模型」的可接受上限（由业务定，例如 < 2%），在这个硬约束下再最大化小模型的分流比例。
这个模式在别处也成立：凡是两类错误代价不对称的判定问题（拒答设计、内容安全过滤、降级开关），都应该先固定代价高的那一侧的上限，再优化另一侧。见 6.3 的拒答设计。
问题一：成本自相矛盾。路由的目的是省钱，但你为每个请求都额外加了一次 LLM 调用。除非这个判断模型比最便宜的那一档还便宜一个数量级，否则收益会被路由开销吃掉相当一部分。
问题二：延迟串行叠加。路由判断必须在实际调用之前完成，它的延迟无法与主调用并行，直接加到每一个请求的 TTFT 上——包括那些本来就要走大模型的请求。
问题三：判断任务本身并不需要 LLM。「这个请求难不难」是一个二分类问题，用小型 embedding 模型 + 轻量分类器就能做，推理开销可以低到毫秒级且几乎零成本。用 LLM 属于杀鸡用牛刀。
什么时候它反而合理：如果这次判断的结果可以被复用（例如在会话开始时判断一次，整个会话沿用），摊薄后的开销就可以接受。这是判断的关键——路由开销必须能被摊薄到多次调用上，否则就不成立。