11 篇博文 含有标签「model-routing」

大多数 AI 流水线（pipelines）在编写时，都好像每一个请求都值得进行一次完整的 LLM 调用。用户提交一条消息，流水线将其传递给模型，等待响应并返回——每一次都无条件地如此操作。这虽然可行，但既昂贵又缓慢，而且通常是不必要的。

实际上需要完整 LLM 推理的请求比例比大多数工程师预想的要小。关于 token 级别路由的研究表明，1.5B 和 32B 参数模型之间只有约 11% 的 token 存在差异，且只有 4.9% 的 token 是真正的“发散性”的——这意味着如果由较小的模型处理，它们会改变推理路径。生产环境中的语义缓存显示，65% 的传入流量在语义上与流水线已经回答过的内容相似。这些并不是边缘案例。它们占据了流量的大部分，而你却在为处理它们支付全额费用。

解决方法是惰性求值（lazy evaluation）：在确认确实需要昂贵模型之前，不要调用它。

大多数团队通过将更便宜的查询路由到更便宜的模型来优化AI推理成本。这听起来合理——但实际上是本末倒置的。首先被降级到廉价模型的查询，并不是那些简单的。恰恰相反，它们是复杂的查询，因为这些才是FinOps仪表盘标记出来的昂贵查询。

结果是：你的合同续签工作流——那个负责敲定六位数交易的关键环节——却在一个会产生幻觉、捏造条款引用的模型上运行。而你的客户支持分类——真正低风险的入门级任务——却享受着顶级模型的待遇，仅仅因为还没有人抱怨过它。

这就是预算倒置陷阱。它的产生并非源于疏忽，而是在没有价值背景的情况下单纯施加成本压力所带来的可预见结果。

你的路由系统完全按照设计运行。80% 的查询流向廉价模型；20% 升级到高性能模型。延迟降低了，成本下降了 60%，领导层也很满意。然后有人按用户细分提取了数据，你发现了问题：非母语英语用户的查询升级率只有母语人士的一半，而他们的满意度评分低了 18 分。路由系统将查询复杂度信号视为中性的，但事实并非如此——它是语言熟练程度的替代指标，而你已经在几个月的时间里，系统性地向特定用户群体提供了更糟糕的产品。

这就是 20% 问题。这不是路由器的 bug。这是任何经过成本优化的路由系统在无人衡量的情况下，直到为时已晚才显现出来的涌现特性。

打开你的 AI 功能延迟和质量看板，眯起眼睛仔细看。曲线大部分时间是平缓的，偶尔会有一些峰值，你的团队几个月来一直称之为“噪音”或“供应商异常”。现在，按小时和星期几来拆分这些数据。噪音显现出了真面目：在东部时间每个周一上午 9 点到 11 点之间，你的 p95 延迟比周六晚上高出 30–60%，缓存命中率下降 10–20 个点，重试率翻倍，每个任务的 token 支出也在悄然攀升。看板没有撒谎，它只是在做平均。

大多数团队发现这种模式的方式就像发现缓慢漏水一样：通过回溯没人能解释的季度账单。直觉是将其归结为供应商的不稳定性，给推理厂商提个工单，然后就此作罢。但这种模式其实与你的 LLM 供应商无关。事实是，你的 AI 功能现在构建在一堆共享的、对时间敏感的系统之上——模型 API、embedding API、你的 agent 调用的 SaaS 工具、接收 webhook 的客户自身基础设施——而其中每一个系统的周期性负载模式都会发生叠加。你继承了整个依赖链的昼夜曲线，而你的看板向你展示的是所有这些曲线的平均值。

晨会上出现了一个回归问题：支持代理昨晚回答错了三个客户问题。有人说：“我们试试在这个路径上用 Opus，看看能不能解决。”四十分钟后，评估通过率回升了，团队关闭了工单，而该路径上的推理账单悄然翻了三倍。六周后，同样形式的回归出现在另一个路径上，并采用了同样的修复方法。你的团队刚刚训练出了一种巴甫洛夫反射：质量回归 → 增加算力。更大的模型是你的技术栈中最昂贵的调试工具，而你现在却首先想到它。

问题不在于更大的模型没有帮助。它们确实有——有时甚至很大。问题在于，更大的模型是一种绝对占优的“掩盖”策略。当提示词指令冲突、检索返回了过时的块、工具描述被误读，或者评估集没有覆盖失效的分布时，更强大的模型会绕过这些故障而不修复其中的任何一个。下一次回归仍具有相同的根本原因，账单已经复加，而底层系统变得更加脆弱，而非更加稳健，因为升级带来的缓冲空间让所有人都不再去探究底层逻辑。

成本仪表盘本身就很有说服力。60% 的流量是“简单”的，快速评估显示较小模型在全局准确率指标上仅落后几个百分点，路由层在同一周内通过特性开关（feature flag）上线。成本曲线开始下行。财务部皆大欢喜。团队继续推进后续工作。

没有人注意到的是，周二下午走廉价路径、周三上午走昂贵路径的客户，现在实际上在使用两种不同的产品。这两个模型的失败方式不同。格式化方式不同。拒绝的内容不同。它们以不同的默认逻辑处理歧义、追问和部分输入。从客户的角度来看，助手一夜之间失忆了，而且没人能告诉他们原因——因为在公司内部，这次变更被归档为一次 FinOps 的胜利，而不是一次产品发布。

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

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

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

每个部署 LLM 路由的团队都是同样的起步方式：按价格排列模型，将简单查询发送给便宜的模型，复杂查询发送给昂贵的模型，然后庆祝成本降低了 60%。六周后，有人发现合同分析准确率从 94% 降到了 79%，编码助手开始虚构不存在的 API 端点，复杂支持工单的客户满意度直线下滑——而路由仪表盘上仍然显示"质量保持 95%"。

问题不在于路由本身。问题在于，仅优化成本的路由将所有质量下降视为等同，而实际上你降级的那些查询恰恰是质量最重要的那些。

人们的本能总是去选择最大的模型。GPT-4o、Claude Opus、Gemini Ultra——选一个前沿模型，把问题丢给它，然后寄希望于强大的能力来弥补架构上的懒惰。这在演示中行得通，但在生产环境中会失败。

2025 和 2026 年，那些交付最可靠 AI 系统的团队并没有使用单一模型。他们将三个、四个甚至五个专业化模型组合成流水线，每个组件只做好一件事。分类器负责路由，生成器负责产出，验证器负责检查。最终得到的系统不仅优于任何单一模型，而且成本只是"万事皆用前沿模型"方案的一小部分。

大多数团队都会选择一个阵营：要么将所有任务运行在云端，要么将所有任务推向边缘。对于大多数生产负载来说，这两种做法都是错误的。有趣的工程挑战发生在它们之间的路由层（routing layer）——这个组件根据每个请求来决定：该查询是需要 H100 上的 70B 前沿模型，还是在本地芯片上运行的 3B 量化模型。

这种路由决策不仅仅关乎延迟。它是一个涉及成本、隐私和能力的三变量优化过程——而最优的分配方案会根据你的流量模式、监管环境以及对每种查询类型“足够好”的定义而改变。正确处理路由的团队在降低 60–80% 推理成本的同时，还能优化 p95 延迟。处理不当的团队要么在简单的查询上过度消耗云端 GPU，要么让无法处理复杂任务的边缘模型提供质量下降的回答。

大多数生产环境中的 AI 系统在成本管理上都会犯同样的错误：它们上线时仅使用单一的最强模型 (frontier model) 来处理每个请求，眼睁睁看着 API 账单随流量线性增长，然后才手忙脚乱地添加缓存或缩减上下文窗口来补救。真正的解决方法——根据每个查询的实际需求将其路由到不同的模型——事后看来显而易见，但很少能被很好地实现。

数据能够清楚地说明问题。当前的最强模型 (frontier model)，如 Claude Opus，每百万输入 token 的成本约为 5 美元，每百万输出 token 为 25 美元。同系列的高效模型成本分别为 1 美元和 5 美元——比例达 5 倍。使用 RouteLLM 的研究表明，通过合理的路由，你可以在将 85% 的查询路由到更便宜的模型的同时，保持 95% 的最强模型质量，从而根据工作负载实现 45–85% 的成本降低。这不仅仅是边际改进；它改变了大规模部署 AI 的单位经济效益。