生产环境中的模型路由：当路由器成本超过节省时

某中型 SaaS 公司的团队六个月前部署了一套模型路由器，目标明确：不再为 70% 的简单查询和格式转换任务支付前沿模型的高昂费用。他们运行了三个月，直到有人做了一道算术题。总推理成本上涨了 12%。

路由器本身并不贵——一个轻量级分类器，每个请求增加约 2ms 的开销。但分类器的决策边界校准有误：它将 60% 的查询升级到了昂贵模型，而非预期的 30%。那 40% 在本地处理的请求质量较差，导致用户重试率上升，进而拉高了总请求量。路由器的遥测数据显示"路由运行正常"，因为它确实在路由——只是路由得不好。

这种失败模式远比成功案例更为普遍。以下是如何构建真正能省钱的路由系统。

你正在承担的"路由税"

每套模型路由系统都有三个成本层次，而大多数团队只考虑了第一层。

第一层：路由器本身。 轻量级分类器每个请求增加数毫秒和少量计算成本。在规模化场景下，这几乎可以忽略不计——实现良好的规则型路由器延迟增加不超过 5ms，即便是基于机器学习的路由器通常也在 20ms 以内。这一层几乎不会破坏你的经济账。

第二层：分类器错误。 每当路由器将复杂查询发送到廉价模型，你要么得到质量较差的输出（质量成本），要么触发回退到昂贵模型（双重成本）。每当它将简单查询发送到昂贵模型，你就按价格差额多付了费用。这些错误的比例决定了路由是帮助还是伤害。大多数团队对两者都没有度量。

第三层：系统效应。 降低输出质量的路由器会提高用户重试率、支持工单量以及下游故障——这些成本不会出现在你的推理账单上，却会体现在业务指标中。一个只优化原始 Token 成本而忽视质量的路由器，即便在每 Token 数学上看起来合算，也可能是净负收益。

唯一有效的路由策略是同时对三个层次进行监控。

决策框架：四条路径，而非两条

"廉价模型 vs. 昂贵模型"的框架是首先要抛弃的。真实的生产路由策略至少有四条路径：

直接发送到小模型。 输入域较窄且可以通过结构验证质量的任务——格式转换、固定标签集的分类、模板化输入的提取。这里不需要置信度分数，需要的是对输出的 Schema 验证。如果输出通过验证，任务就被正确处理了；如果失败，你已经有了回退触发器。

置信度阈值级联。 小模型可能足够胜任但事先无法确定的任务。先让小模型运行并产生置信度信号。如果置信度超过阈值，返回结果；否则升级到大模型。这是大多数团队实现的模式——但失败往往在于置信度阈值的校准。

阈值设太高（保守：只在非常不确定时才升级），会让大量低置信度的响应流入生产，用户体验到质量下降。阈值设太低（激进：稍有不确定就升级），意味着大多数请求你在同时运行两个模型，最终只返回昂贵模型的结果——比不用路由还糟糕。

正确的校准取决于你的任务领域和质量容忍度，需要有标注的评估数据和反复的阈值调优。如果你没有做这项工作，阈值很可能是错的。

延迟预算调度。 对于有严格延迟 SLO 的交互式面向用户的应用，路由决策需要综合当前各模型端点的队列深度和预期等待时间——而不仅仅是每 Token 成本。队列积压 3 秒的廉价模型往往比延迟 200ms 的昂贵模型更糟糕。忽略当前基础设施状态的生产路由系统，会在高峰负载时做出系统性错误的决策，而那恰恰是决策最重要的时刻。

完全跳过路由。 对于输入域真正均匀、且你已经分析过哪个最廉价的模型能可靠处理该领域的任务，路由只会增加复杂度而没有收益。在设计阶段一次性选好正确的模型，不要为每个请求支付分类开销。

复杂度代理：真正有效的方法

"按复杂度分类"听起来简单直接。但在实践中，在运行模型之前衡量复杂度是个微妙的问题。

Token 数量是弱代理。 长输入不一定困难——一个 2000 Token 的文档检索任务远比一个 50 Token 的多步推理问题简单。纯粹按输入长度路由的团队，最终会把简单但冗长的查询发送到昂贵模型，同时自信地错误路由短小但复杂的查询。

意图信号更强。 任务类型——摘要、提取、代码生成、开放性推理——比原始大小更能预测复杂度。基于任务类型分类器训练的路由器往往比使用提示词长度启发式的路由器做出更好的决策。代价是：建立良好的任务类型分类器需要来自实际流量的标注样本，这需要时间积累。

冷启动阶段，结构特征胜过语义特征。 当你没有标注数据时，结构信号——提示词中不同指令的数量、嵌套条件的存在、所需工具调用的数量——能给你一个可用的基线。它们不是最优的，但比单纯的 Token 数量更好，而且不需要标注数据。

根据结果而非输入进行校准。 复杂度代理的唯一真实标准是小模型是否真正成功处理了任务。如果你有任何质量信号（用户评分、下游验证、评估套件得分），将其反馈到分类器训练中。仅基于输入特征训练的路由器，随着流量分布的变化会随时间偏离真实情况。

路由会造成损害的场景

除了校准失败，还有一些结构性情况会让路由的经济账更难看：

低于路由盈亏平衡点的小规模应用。 在小规模下，构建和维护路由系统的工程成本——分类器训练、阈值调优、回退逻辑、监控——超过了推理成本的终生节省。大多数团队的盈亏平衡点大约在每月 500 万到 1000 万 Token。低于这个量级，就静态选择合适的模型吧。

输出方差高的任务。 如果同样的输入在不同场合能产生质量迥异的输出，置信度分数就变得不可靠。这在创意任务、模糊指令和多跳推理链中很常见。在这些领域基于置信度路由只会增加噪声而不增加价值。

分类器延迟不成比例时。 如果你的路由分类器需要 50-100ms，而你的快速模型只需要 80ms，你在路由之前就已经增加了高达 125% 的开销。这个数学对交互式应用来说是致命的。如果你的分类器无法在 10ms 内运行，考虑使用基于规则的路由而非基于机器学习的路由，即便它不那么精确。

"边界查询"比例高时。 某些任务分布中，明显简单的查询占少数，明显困难的查询也占少数，中间有大量两个模型都不是明显最优的查询。只有当简单/困难的区分足够清晰以至于可以可靠分类时，路由才能节省成本。如果你的分布主要是边界情况，路由准确率将很低，错误成本将很高，你既得不到成本节省，也得不到质量保证。

遥测：你的路由器真正需要的信号

大多数团队部署路由器时无法回答"这个路由器真的在省钱吗？"这个问题。标准的监控设置追踪路由到各模型的请求数和总 Token 成本。这是必要的，但远远不够。

真正能告诉你路由器是否有效的指标：

升级率 vs. 基线。 有多少比例的请求升级到了昂贵模型？这应该随时间保持稳定。升级率上升意味着你的流量分布已经改变，但分类器没有跟上——这是一种常见的退化模式。你需要对此设置告警。

不同路由路径之间的质量差异。 对于任何有质量信号的任务，按路由路径追踪质量。如果小模型路径在相同任务类型上的质量明显低于大模型路径，你的阈值过于激进，正在输出质量下降的结果。如果质量相当，则阈值过于保守，你在不必要地升级请求。

重试放大。 追踪路由到小模型的请求是否有更高的用户重试或错误率。如果有，你的路由器在削减 Token 成本的同时增加了总请求量——这是路由最终得不偿失的常见方式。

分类器成本占节省额的比例。 记录每个路由决策的成本（分类器推理计算、延迟开销），并从每个请求小模型与大模型之间的成本差中减去它。如果你每天路由 1000 个请求，每次路由节省 0.02 美元，但每次路由在分类器开销上花费 0.01 美元，你的实际总节省只有你以为的 50%。

分布漂移检测。 你的路由器校准所基于的输入，不是六个月后你会收到的输入。随时间追踪输入特征分布，当它们显著变化时触发重新校准。在一月份流量上准确的路由器，到七月份可能已经系统性地校准失误。

实用路由决策树

在构建路由器之前，按顺序回答这些问题：

1. 你每月的 Token 消耗是否超过路由的盈亏平衡阈值？ 如果没有，静态选择一个模型然后继续前进。

2. 你是否有任务领域的质量标注数据？ 如果没有，在构建基于机器学习的路由器之前先开始收集。用基于规则的路由作为临时替代方案。

3. 你的任务分布是否真正呈双峰分布？ 用两个模型对一批流量样本进行分析。如果大多数查询从廉价模型获得同等质量，将所有内容路由到廉价模型——你不需要路由器。如果大多数查询需要昂贵模型，将所有内容路由到昂贵模型。

4. 你的分类信号是否可以通过结构验证？ 对于有结构化输出要求的任务，使用输出验证作为质量信号而非置信度分数。它更可靠且计算成本更低。

5. 你是否在负载下（而不仅仅是平均延迟）测量了延迟？ 在 2 倍峰值流量下测试你的路由系统。如果你的分类器在高负载下成为瓶颈，在你最需要它帮助的时候它会拖累你。

如果五个问题的答案都是肯定的，就构建路由器。从第一天起就用上述遥测进行监控。在至少一周的时间里以影子模式运行——路由但不执行——然后再切换到实时路由。影子期会在影响生产之前暴露校准问题。

那些实现了 70-85% 成本降低的团队，使用的是大多数流量确实很简单、且这些任务的质量要求足够低以至于廉价模型能够可靠处理的任务分布。当适用时，这是真实的机会。失败模式是假设你的流量具有这些属性而不加以验证——然后上线一个让你的经济账悄悄变糟的路由器，同时仪表盘上显示的都是绿色。