LLM 路由与模型级联：如何在不牺牲质量的情况下降低 AI 成本

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

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

这篇文章涵盖了 LLM 路由和模型级联 (model cascades) 的实际运作方式、在生产环境中经得起考验的具体策略，以及导致大多数实现方案失败的陷阱。

路由与级联的区别

这两个术语经常被混淆，但它们描述的是截然不同的模式。

路由 (Routing) 是一种单次决策：在执行查询之前，路由层对其进行分类并将其发送到唯一的一个模型。路由层可能使用意图分类（“这是一个编程问题，发送给代码专用模型”）、复杂度估算（“简短的事实查询，发送给小模型”）或与过去查询的语义相似度。一次决策，一次执行。

级联 (Cascading) 是一种顺序升级：查询首先发送到最便宜的模型。如果该模型的输出置信度低于阈值，查询将升级到下一级，依此类推，直到产生足够置信度的答案，或由能力最强的模型处理。你总是从低成本开始，仅在便宜模型无法处理时才支付昂贵的计算费用。

这种区别对于你如何实现和调整每种方法至关重要。路由需要一个准确的前置分类器，这会在任何生成开始前增加延迟。级联需要良好的置信度校准 (confidence calibration)，并且必须接受可能顺序运行多个模型带来的延迟。在实践中，混合方法通常效果最好——先进行路由以避免明显不匹配的层级，然后在层级内进行级联。

基于置信度的级联是如何运作的

级联系统的核心机制是将小模型的不确定性作为是否需要升级的指标。当模型生成响应时，其 token 概率分布包含了一些信息：高置信度的生成会将概率质量聚集在少数几个 token 上，而不确定的生成则会分散在许多候选 token 中。这种分布中的高熵 (entropy) 信号表明模型不确定。

挑战在于，LLM 自我报告的置信度校准得并不好。模型可能会产生一个流畅、听起来很权威、token 概率很高但事实错误的响应。相反，对于真正模棱两可的问题，正确的答案可能会触发错误的升级。这是朴素级联实现中最主要的实际问题。

更好的方法通过以下几种方式处理：

早期弃权 (Early abstention) 训练模型在查询超出其能力时明确发出信号，而不是尝试给出一个不确定的答案。一项研究方法通过接受 4.1% 的弃权率增加，实现了成本降低 13% 和错误率降低 5%——模型说“我不知道”而不是产生低置信度的错误答案，从而触发升级。

检索耦合置信度 (Retrieval-coupled confidence) 在 RAG 系统中将模型的不确定性与检索质量信号相结合。如果检索到的文档相关且模型置信度高，则跳过升级。如果检索质量差，则无论模型置信度如何都进行升级。

经验校准阈值 (Empirically calibrated thresholds) 是必不可少的。任何凭直觉设置置信度阈值的系统都会出现校准偏差。正确的方法是评估你的特定工作负载——在每个置信度级别上小模型回答正确的比例是多少——并根据你可接受的错误率设置阈值。这需要来自你业务领域的标注数据，而不是学术论文中的基准测试结果。

意图路由：实用的起点

在尝试基于置信度的级联之前，大多数团队更适合采用更简单的意图路由。其思路非常直接：将传入的查询分为几类，将每一类路由到最适合处理它的模型。

客户支持系统可能会这样路由：

• 简单的事实查询（订单状态、发货时间）→ 小型、快速的模型
• 政策解读问题 → 中层模型
• 需要判断的复杂投诉或边缘案例 → 最强模型 (frontier model)

分类器本身可以非常小——一个经过微调的 0.5B 参数模型可以实现约 90% 的路由准确率，同时仅增加几毫秒的延迟。关键在于定义那些真正与所需模型能力相关的类别，而不仅仅是主题类别。

这种方法失效的地方在于：设计文档中听起来很清晰的意图类别在生产中往往重叠得很乱。“简单的事实查询”有时包含隐含的复杂性。“需要判断的边缘案例”有时能被简单解决。你需要对路由决策进行监控，并建立一种机制来捕捉系统性的错误路由。

一个实用的保障措施是，对于模糊的查询，默认路由到保守的层级。不必要地路由到中层模型的成本，远低于小模型给出错误答案（本应升级）的代价。

语义缓存：复利倍增器

路由（Routing）和级联（Cascading）降低了新查询的成本。语义缓存则消除了你已经回答过的查询的成本。

其机制是：当一个查询得到解答时，将其向量化（embed）并将该向量与响应一同存储。对于每个新查询，计算其向量并检查与缓存的余弦相似度。如果超过相似度阈值，则直接返回缓存的响应，无需调用任何模型。如果低于阈值，则执行查询并缓存结果。

在实践中，延迟数据非常惊人。带有语义缓存的真实 RAG 管道在处理近乎重复的查询时，延迟降低了 3.4 倍；对于完全匹配的查询，延迟降低了 123 倍。结合路由，语义缓存在查询重复率较高的工作负载中可以将 LLM 总成本降低 60% 或更多。

难点在于校准相似度阈值。设置过高，你会错过有效的缓存命中，白白流失节省成本的机会。设置过低，你可能会针对表面相似但含义不同的查询返回缓存响应，导致答案错误。合适的阈值取决于你的向量模型、查询空间的语义密度以及你对数据陈旧性的容忍度。

对于包含时效性数据的系统，你还需要缓存失效逻辑。关于当前产品库存的缓存响应可能在几小时内就会失效。

扼杀路由系统的生产环境陷阱

在生产部署中，有几种失败模式反复出现：

缺乏可观测性的路由。 如果你看不到哪些查询路由到了哪些模型以及结果如何，你就无法检测到校准偏差。路由层需要对每个路由决策进行结构化日志记录：选定的模型、分类器的置信度、使用的查询特征，以及（如果可能的话）下游的质量信号。没有这些，你就像在盲飞。

单一供应商依赖。 跨成本层级的路由只有在每个层级都可用时才有效。当模型供应商发生故障或对你进行速率限制时，你的路由系统需要自动降级（fallback）——不仅是降级到不同的层级，还可能需要切换到不同的供应商。多供应商降级虽然实现起来更难，但对于生产可靠性是必不可少的。

路由冷启动。 基于历史数据训练的意图分类器在处理训练中未出现的新查询类型时表现较差。新产品发布、新市场或新功能可能会产生路由系统会误判的查询模式。路由系统应该有一种机制来标记低置信度的路由决策，并以更保守的方式进行路由。

级联延迟累积。 每当查询升级时，顺序级联都会增加延迟。在一个三级级联中，一个需要顶层模型的查询已经支付了三次模型调用的延迟代价。对于延迟敏感的应用，这可能比直接路由更糟。在决定采用级联还是直接路由之前，请先分析你的延迟预算。

长尾部分的置信度校准偏差。 你的路由系统在典型查询上的准确性并不能预测其在长尾查询（那些稀少、异常的输入，通常也是错误代价最高的输入）上的表现。请针对长尾分布单独评估路由质量。

总结：分层架构

对于大多数团队来说，正确的实施顺序是：

1. 首先添加语义缓存。 这是最简单的方案，不需要开发分类器，并能立即降低重复查询的成本。使用现成的解决方案（有几种成熟的开源方案），而不是从头开始构建。

2. 为定义明确的类别实施意图路由。 在你的工作负载中识别出最清晰的、适合不同层级的类别——那些显然需要最顶尖（frontier）模型的查询和那些显然不需要的查询。在处理其他问题之前，先对这些查询进行明确路由。

3. 为模糊的中间地带添加基于置信度的级联。 一旦你的意图路由正常运行并受到监控，就可以为那些所属层级确实取决于难度的查询增加置信度级联。

4. 构建可靠的降级链。 每个路由路径都需要一个降级方案。小模型无法给出高置信度的答案，则降级到中层模型。主供应商不可用，则降级到另一个供应商的等效模型。

工具生态系统已经足够成熟，你不需要自己构建路由基础设施。LiteLLM 提供了一个生产就绪的路由器，支持 100 多种模型的负载均衡和降级。RouteLLM 提供了经过研究支持的路由策略，专门针对成本性能权衡进行了优化。对于边缘侧的意图分类，vLLM 的语义路由器可与生产服务基础设施集成。

经济效益现在非常显著

三年前，路由策略在理论上是可行的，但在操作上却很脆弱。当时模型选择稀少，价格差异较小，且工具链需要大量的定制工作。

现在情况变了。目前的模型家族在高效层级和最顶尖层级之间提供了 5 到 25 倍的成本比，且能力边界清晰。路由框架在生产环境中经过了实战检验。关于置信度校准和级联设计的研究也已经跟上了实际需求。

那些没有实施路由的团队本质上是在不必要地补贴他们的 AI 成本。并不是每个查询都需要最顶尖的模型。识别哪些查询需要哪个层级并可靠地路由它们的工程工作，在任何有意义的规模下都能迅速收回成本。

剩下的待解决问题是测量：路由质量取决于你检测错误的能力。能够做好这一点的团队，是那些将路由决策视为一类遥测数据（first-class telemetry），而不仅仅是基础设施管道的团队。