动态模型路由：如何在削减LLM成本的同时不牺牲能力

大多数企业的LLM账单问题，表面上看是"模型选型"问题，实际上是一个路由问题：当统一使用前沿模型处理所有任务时，大量本可以用更便宜模型完成的琐碎请求，被迫按推理价格计费。

这种浪费并非一开始就暴露。团队先用前沿模型快速跑通一个可用产品，采用率上升，六个月后月度账单成为会议议题。第一反应通常是全局换成便宜模型，质量下滑，再换回来，最终得出结论：能力就是这个价格。

这个结论的错误在于，它把一个异质性工作负载当成了单一决策。一个受治理的网关，可以把每个请求路由到恰好能完成该任务的最便宜模型，从而在不触碰质量上限的前提下改变经济性。

企业流量的真实形状

路由之所以有效，是因为生产环境中的LLM流量并不是均匀苛刻的。

当系统嵌入真实工作流后，很大一部分请求是"披着自然语言接口的确定性转换"：从文档中抽取五个字段、把工单分类到九个队列之一、按固定语气重写段落、把回复转成合法JSON。这类请求上下文短、无多步推理、有可验证的正确答案。

而真正需要前沿模型的那一小部分，才是系统被采购的原因：开放式分析、多步规划、工具编排，以及任何需要模型同时保持多个约束并做出决策的任务。

把两类请求都发往同一个前沿端点，等于用推理价格支付格式化工作。这个分布差异就是机会所在，也是为什么第一个要建的不是路由器，而是埋点（instrumentation）。在不知道流量真实形状之前，无法设计分层。需要记录：prompt长度、上下文大小、是否请求工具调用、输出是否受schema约束、人类是否接受了结果。两周这样的数据就足以判断路由是否值得做。

埋点（instrumentation） 在此处并非泛指日志记录，而是指在网关层面对每个请求结构化地采集一组最小元数据：prompt 与上下文的 token 长度、是否携带工具调用 schema、输出是否受 JSON schema 或正则约束、命中了哪个提示模板、模型返回后人类是否最终接受了结果（即下游任务是否成功）。这些字段共同刻画了请求的"难度指纹"。之所以强调两周数据，是因为路由分层本质上是一个分布估计问题：样本太少无法区分模板化流量与罕见困难请求的比例，样本太长则会在构建埋点价值尚未兑现前消耗政治资本。埋点数据同时是后续三类分类器的训练与校准来源——启发式规则的阈值、嵌入聚类的标签、小型分类器的监督信号，都来自这份日志。

网关做什么

网关是所有模型调用的唯一入口。应用层不直接与任何模型提供商通信，这个约束是其他一切能力的前提。

[ App / Agent ]
       │
       ▼
┌──────────────────────────────────────────┐
│  AI GATEWAY                              │
│                                          │
│  1. 认证 + 打标签（团队、工作负载）       │
│  2. 分类任务复杂度                        │
│  3. 路由到相应层级                        │
│  4. 验证输出                              │
│  5. 失败时升级                            │
│  6. 计量 + 日志                           │
└──────────────────────────────────────────┘
       │                    │
       ▼                    ▼
[ 本地/小模型 ]        [ 前沿模型 ]

这六步中有五步是平淡无奇的管道工作，但正是它们让第六步可以安全开启。

路由层级	模型原型	平均输入成本/1M	延迟目标	最适合的工作负载
Tier 1: 本地/边缘	Llama 3 8B, Mistral 7B	$0.05 – $0.15	< 250ms	分类、JSON抽取、实体标注
Tier 2: 中端托管	Claude 3.5 Haiku, GPT-4o-mini	$0.25 – $0.60	< 800ms	摘要、上下文问答、草稿生成
Tier 3: 前沿推理	Claude 3.5 Sonnet, o1, GPT-4o	$3.00 – $15.00	2s – 8s	多步规划、复杂代码生成、工具集群

说个细节，网关还是那些与成本无关的控制的天然居所：出口检查、PII脱敏、提示注入筛查、按团队的预算执行。把路由层和安全层分开建设，最终会得到两个瓶颈点、两套凭证、两份不完整的日志。应该合成一个。

提示缓存（prompt caching） 是前沿模型提供商为降低重复前缀计费而推出的机制：当多次请求共享一段稳定前缀（如长系统提示、固定工具定义、共享文档上下文）时，供应商会缓存该前缀的 KV 状态，后续请求按显著更低的"缓存读取"费率计费，而非标准输入 token 价格。这意味着请求的实际边际成本高度依赖于它是否复用了已有前缀。对于路由而言，把一个高缓存命中率的请求迁往本地模型，看似把单价从 $3 降到 $0.1，但实际比较基准应是"前沿模型缓存读取费率"（可能低至标准价的 10%）对"本地模型完整推理成本"，后者还需要自建 GPU 摊销。忽略这一层，就会得到支出持平但延迟更差的负向优化。

任务分类的三种方法

按成本与准确度递增排列：

启发式规则。 上下文长度、是否存在工具调用schema、输出token上限、prompt是否匹配已知模板。几乎免费，出奇地有效，并且以你可以预料的方式脆弱。适合起步，也适合长期处理高体量的模板化流量——这类调用方已经知道任务形状。

嵌入相似度。 将传入prompt嵌入，与已知结果的过往请求标注聚类比较。能处理启发式规则漏掉的新颖表述，但前提是你一直在记录结果——这正是先做埋点的理由。

小型分类器模型。 微调的编码器或小型LLM直接给复杂度打分。最准确、最昂贵，并引入了一个自身需要监控和重训练的依赖。

务实的架构是分层的：启发式规则解决明显的大多数，只有模糊的剩余部分才进入更昂贵的分类器。路由路由器不是玩笑，而是同一原则向下应用一层。

一个需要警惕的捷径：不要按调用者身份分类。 按团队或用户路由易于实现但结构上是错误的，因为同一团队既提交琐碎请求也提交困难请求。它优化了错误的变量，并制造出那些让路由项目被取消的质量投诉。

嵌入相似度分类 的工作方式是：用同一编码器把传入 prompt 映射为向量，在过往已标注结果的请求向量库中做近邻检索，看相似历史请求大多落在哪个层级，从而决定本次路由。它的优势是对未见过的措辞变化比关键词启发式更稳健，但前提是历史库中带有"结果标签"——即那次请求最终成功与否、由哪个层级完成、是否被人工接受。这正是前文强调先做埋点的原因：没有标注历史，嵌入检索只能比较 prompt 文本相似度而无法判断难度。缺陷是冷启动阶段库为空或稀疏，对真正新颖的请求会退化为随机路由，因此它通常只作为启发式规则的补充，而非替代。

延迟预算

路由器在每个请求上运行，包括它决定不重新路由的请求。它的成本是无条件支付的，必须小到消失。

两个预算很关键：

延迟。 分类器位于关键路径上。如果分类引入的延迟超过层级切换节省的延迟，用户体验会恶化而账单改善，功能就会被关掉。启发式分类应当实际上免费。基于模型的分类器必须真正小、真正本地；为了决定用哪个提供商而网络跳转到另一个提供商，是经不起评审的设计。

成本。 路由器推理也不是免费的。如果分类器的成本占其所路由到的廉价层级的可观比例，那么在高体量、低复杂度流量上，算术就崩了——而这恰恰是路由本应最划算的流量。

两个预算指向同一件事：用尽可能便宜的信号解决尽可能多的问题。

故障模式

这部分决定了路由层能否挺过生产环境的第一个季度。

升级级联

没有升级路径的路由不是路由，是降级。每个层级都需要明确的失败条件（如schema验证失败、低置信度、拒答、超时），将请求提升到更高层级。

后果是有些请求被付费两次。如果升级率是10%，有效成本就是廉价层跑全部，加上昂贵层跑十分之一，再加上两者串行的延迟。升级率不是随意的质量指标，而是成本模型中的核心项。一个把40%流量错误向下分类的路由器，可能比没有路由器更贵，同时还更慢。

升级率（escalation rate） 应被理解为成本模型中的一阶项，而非质量仪表盘上的旁注。假设廉价层单次调用成本为 C1、前沿层为 C3（C3 通常为 C1 的数十倍），若升级率为 r，则有效成本约为 C1 + r·C3（忽略重试开销）。当 r 从 5% 升至 40% 时，后一项会从可忽略变为主导，甚至在 C3/C1 比值足够大时超过"全部走前沿层"的基准。更隐蔽的是延迟：升级请求串行经过两层，端到端延迟是两者之和，而 p95 恰恰由这些请求构成。因此监控升级率的绝对值和漂移速度，比监控平均成本更早发出预警——它通常先于用户质量投诉数周出现。

提示缓存改写算术

这是大多数成本模型遗漏的故障模式。

前沿提供商对重复的prompt前缀提供大幅折扣。拥有大段稳定系统提示或共享文档上下文的工作负载，其大部分输入可以按降低的缓存读取费率计费。把这些请求转移到本地模型的路由器会失去这些缓存命中，而最初的比较只评估了未缓存的名义价格。

结果是路由器报告节省，但总支出持平甚至更高。任何诚实的成本模型都必须与实际实现的混合费率比较，包含缓存行为，而非价目表。当工作负载缓存命中率高时，正确的路由决策往往是不动它。

验证失败导致token倍增

结构化输出是朴素token优化反噬的地方。便宜模型返回格式错误的JSON会触发重试。两三次重试后，你花的token和墙钟时间比一次调用胜任模型还多。

这就是为什么度量单位必须是每个成功完成任务的成本，而非每个token的成本。优化token数而忽视重试率，就是团队做出token减少30%而支出没有下降的原因。

网关处的确定性验证（包括schema一致性、必需字段、类型检查）计算便宜，能立即捕获这类失败，并驱动升级决策。返回前先验证，永远如此。

阈值会过时

你的prompt组合不是平稳的。新功能上线，用户学会系统擅长什么，上线时70%简单的分布会漂移。一次性校准的路由阈值在几个月内就错了，通常偏向于过于激进地向下路由。

把阈值当作有负责人和评审周期的配置，而非常量。对分布漂移告警：升级率的突然变化是主要预警信号，通常先于质量投诉到来。

应该度量什么

六个数字。少于这个数，你无法为架构辩护；多于这个数，没人看仪表盘。

1. 每个成功完成任务的成本，按工作负载。头条指标。token是输入，不是结果。
2. 升级率，按层级。上升意味着分类器漂移或流量变化。
3. p95端到端延迟，含路由器。 从调用者视角衡量，而非模型视角。
4. 质量回归率。 抽样人工评审或针对固定留出集的自动评估。没有这个，你就没有证据表明节省不是单纯用质量买来的。
5. 实际混合输入费率，含缓存命中。防范上述缓存陷阱。
6. 按团队和工作负载的支出。 需要在网关处对请求打标签，这就是为什么打标签是第一步而非事后补充。

反模式

• 按身份而非任务路由。 上文已述。最常见的设计错误。
• 没有升级路径。 把成本优化变成静默的质量削减。
• 优化token而非任务成本。 产生令人印象深刻的图表和平坦的账单。
• 与价目表定价比较。 忽视缓存并夸大节省，有时完全失真。
• 独立的安全瓶颈点。 两个网关意味着两份不完整的审计轨迹。
• 在埋点之前就发布路由器。 你无法为从未度量过的分布分层。

动态模型路由能减少多少企业LLM账单？

生产部署表明，动态模型路由在不降低输出质量的前提下，将企业LLM总支出降低40%至70%。通过把高体量、低复杂度任务路由到更便宜的本地化模型，并为推理保留前沿端点，组织大幅削减了每个完成任务的成本。

核心结论

诚实的答案是：取决于你的流量。真实工作负载间的范围大到任何单一数字都会误导。以抽取和分类为主的工作负载有可观的优化空间。真正以推理为主、或已经受益于高缓存命中率的工作负载，则不会产生轻松的节省——此时正确的工程答案是不动它。

可靠的是发现本身的形状：先度量，把可度量的部分分层，验证每个输出，保留升级路径，并按照你实际支付的费率而非价目表定价。这样建成的网关，让成本成为可治理的参数，而非季度意外，并且把你最终需要的安全控制放在每个请求已经经过的那一个地方。