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

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

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

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

你正在承担的"路由税"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

加载中…