The Hidden Cost of LLM Routing: Why Switching Models Costs More

LLM路由的隐藏成本：为什么切换模型更昂贵 | Towards Data Science

大型语言模型

LLM路由的隐藏成本：为什么切换模型更昂贵

我测试了LLM路由，以理解为什么在会话中途切换模型会抵消廉价推理带来的成本节约

Nhu Hoang

2026年10月20日

23分钟阅读

在Google上关注我们

分享

照片由Sixteen Miles Out在Unsplash提供

1. 引言

自从我开始使用大型语言模型（LLM）以来，如何高效使用它们的问题一直萦绕在我的脑海中。其中似乎最有效的解决方案之一是：当某个模型的配额即将耗尽，或希望在某个任务上节省预算时，将部分请求路由到另一个更便宜的LLM。这种做法的期望是最终成本会低于原始模型。这是因为能力相当的模型之间价格可能相差5倍到50倍，为什么不设置一个智能代理，在网关处将简单请求发送到廉价模型，而将复杂请求发送到前沿模型呢？起初我认为这个想法非常巧妙。但当我尝试应用时，一个疑问立即浮现：切换本身的成本是多少？不是每token的价格差异——而是切换操作本身。

假设一个路由器将对话的第8轮从模型A切换到模型B。模型B从未见过前7轮对话。在生成任何新token之前，它必须从头开始以全价处理整个对话历史。因此，本应节省成本的路由器可能刚刚触发了LLM服务中最昂贵的操作之一：对整个会话进行冷缓存预填充。

图1——前7轮对话在模型A上以热缓存方式运行，然后第8轮切换到从未见过这些内容的模型B。图片由作者提供。

这不是一个假设性问题。2026年8月，微软Azure研究团队发表了首个关于代理式编码工作负载的生产级研究：对GitHub Copilot流量进行一周抽样，覆盖1350万次会话和7.6亿次模型调用（Liu等，2026，arXiv:2608.00101）。研究内容与缓存行为一样令人震惊。在单轮对话中，约90%的提示内容可从缓存中复用。在同模型跨轮对话时，这一比例降至55%。切换模型后，这一比例骤降至仅8%。

这些损失部分源于轮次边界本身，其余则来自切换到缓存不兼容的模型。根据最新研究，约6.4%的会话涉及模型切换，最常见的原因是错误或速率限制。许多人早已在无意中承担了这部分成本。

因此，我构建了一个测试来直接测量这一成本，并评估切换对用户最终账单的影响。在测试中，我将相同的20轮代理会话通过三种路由策略进行处理：粘性路由、按请求交替和阶段边界切换。所有策略均使用启用了前缀缓存的相同vLLM服务器。我从服务器指标中读取了精确的缓存token计数。所有其他条件保持一致，包括对话内容和token。唯一变化的是路由策略。

结果：网关处的按请求路由破坏的缓存量几乎是粘性路由的两倍。在实际计价下，它仅实现了原始模型价格差异所建议的40个百分点中13个的节约。阶段边界路由表现显著更好。由于框架能识别代理工作流阶段的结束与开始，它成功捕获了这40个百分点中的29个。

在极端情况下，即使两者处理相同的 token，前沿模型上的无缓存感知路由策略成本是缓存感知基线的 4.88 倍。

如果你构建或运营 LLM 代理，当有人提议添加路由器以减少推理成本时，这个数字就是关键。节省的成本不仅取决于模型价格，更取决于路由如何与状态、上下文和缓存重用相互作用。

路由不仅仅是定价决策。它是状态管理决策，而 harness 是存储该状态的地方。

2. 路由重要的地方

当人们谈论“模型路由”时，通常指的是以下两种不同架构之一。

第一种是网关路由，其中路由决策发生在你的应用与模型提供商之间的代理层。可以参考 LiteLLM、OpenRouter 或 RouteLLM（Ong 等，2024，arXiv:2406.18665）中学习型路由器的实现方式。网关逐个查看请求，接收一组消息，估算请求的难度，选择模型并转发请求，以回答问题：“哪个模型能以足够低的成本处理这个请求？”

当请求基本独立时，这种方法效果良好。FrugalGPT 通过模型级联（Chen、Zaharia & Zou，2023，arXiv:2305.05176）探索了这一思路，证明可以在远低于 GPT-4 的成本下接近其基准质量。但这些实验主要围绕无状态、独立查询构建。

第二种架构是 harness 路由。在此架构中，路由决策发生在代理运行时内部：即运行代理循环、构建提示、调用工具并跨任务跟踪状态的层级。Claude Code、OpenHands、Factory 的 droids 或内部代理运行器均符合此模型。

关键区别在于 harness 能看到的不仅仅是当前请求。它了解代理正在执行的操作、会话中之前发生的事情、已调用的工具以及已有的上下文。由于它本身就是构建下一个请求的组件，因此可以在构建请求前选择模型。

这改变了路由问题的本质。

不再是问：

“哪个模型应该回答这个请求？”

harness 可以问：

“考虑到当前会话阶段以及切换模型的成本，哪个模型应该处理这个任务环节？”

| 信号 | 网关能看到？ | harness 能看到？ | |------|-------------|----------------| | 当前请求的文本 | 是 | 是 | | 这是会话的第 2 轮还是第 60 轮 | 否 | 是 | | 哪个模型的 KV 缓存已预热 | 否 | 是 | | 任务阶段（探索 vs. 实现 vs. 遇阻） | 否 | 是 | | 最近三次编辑是否失败测试 | 否 | 是 | | 提示是如何构建的，以及为哪个模型构建的 | 否 | 是 |

这种区别在长期运行的代理会话中尤为重要。网关无法真正识别它正在处理的是编码任务的第 40 轮而非独立提示。它能看到请求，但看不到背后的完整执行上下文。Abhay Singhal 使用 Factory 生产路由器的数据描述了这种影响：通过 harness 侧路由，在保持八项指标质量的同时，成本降低了 58%；而网关式切换在长会话中导致有效缓存重用受损，产生 2.1–2.4 倍的惩罚。

这些数据来自Factory自身的工作负载和遥测信息，因此我不想将其视为普遍适用的结论。我更感兴趣的是结果背后的工作机制。因此，我想要观察是否能在自己的测量中看到相同的效果。

3. 缓存使得长时间的代理会话变得可行

一个LLM本身只是接收一些文本并预测接下来的内容。代理框架是围绕模型的软件，它将这些预测转化为实际工作。它会跟踪系统提示、工具定义、用户消息和工具结果。在每次交互中，它会将对话重新发送给模型，执行模型要求的工具调用，将结果添加到对话记录中，并重复这一过程。结果是，每个新请求都会再次包含完整的对话历史。一个20轮的代理会话并不是20个独立的提示。它实际上是相同的提示内容反复发送，每次仅增加少量上下文。

我在其中一个测量会话中直接观察到了这一点。到第20轮时，单个请求已经包含了10,135个提示标记。但在整个会话中，服务器为了维护一个最终只有10,135个标记长度的对话记录，处理了111,871个提示标记。换句话说，相同的上下文被处理了大约11次。

Singhal的生产数据在更大规模上展示了相同的模式：在第61到150轮之间，输入大小增长了7.6倍。这就是为什么长时间运行的代理会话会迅速变得昂贵的原因。成本不仅仅在于生成新标记，还在于反复将之前的所有内容重新输入模型。

图2 — 模型在调用之间不保留任何信息，因此框架必须在每次交互中重新发送整个对话记录。图片由作者提供。

使这种机制可行的关键是前缀缓存。当模型处理提示时，它会构建一个键值（KV）缓存。可以将其视为模型对已读标记的计算表示。如果下一个请求以完全相同的标记序列开头，推理服务器无需重新计算整个前缀。它可以复用缓存状态，仅处理新标记。像vLLM这样的系统通过自动前缀缓存（Automatic Prefix Caching, vLLM文档）自动支持这一功能。商业API也直接暴露了相关的经济性。例如，在Claude API中，读取缓存输入标记的成本是正常输入价格的0.1倍，而将标记写入五分钟缓存的成本是正常价格的1.25倍（Anthropic提示缓存文档）。

长时间的代理会话几乎是这种缓存机制的理想工作负载。每次交互通常只是前一次交互加上一些新文本。如果会话保持在同一个模型上，大部分提示内容都可以从上一次请求中复用。只有新增的消息和工具结果需要重新计算。由于KV缓存属于特定模型，因此路由到不同模型可能会引发问题。模型B无法复用模型A生成的缓存。两个模型可能具有不同的权重、隐藏维度、架构，甚至分词器。一个模型的缓存状态对另一个模型来说毫无意义。

图3 — 路由决策发生的位置决定了它能看到的上下文：网关在提示构建后进行路由，而框架在提示构建前进行路由。图片由作者提供。

当路由器将一个活动会话从一个模型迁移到另一个模型时，新模型显然会从零开始。该会话的缓存命中率会降至零，必须重新处理整个对话历史记录。对于短请求，这可能影响不大。但对于长期代理会话，这会主导成本。

图4 — 绿色方块来自缓存，红色方块需按原价重新支付。图片由作者提供。

4. 服务系统能解决的问题——以及仍无法解决的问题

过去几年，服务堆栈在缓存重用方面有了显著改进。其中很多工作确实有效。但大多数解决的是三个更具体的问题：确保缓存位于正确的副本上、延长缓存存活时间，或在相关模型之间重用缓存。更困难的情况是切换非常不同的模型。现有技术大多在此处止步。

4.1 首先，将请求路由到已预热的副本

在生产环境中，一个模型通常会跨多个容器运行。如果轮询负载均衡器将对话的第5轮发送到从未处理过前4轮的容器，该容器必须从零开始重建前缀缓存，这会带来成本。前缀缓存感知的调度解决了这个问题。每个vLLM容器报告其已持有的缓存块，调度器会将下一个请求发送到已缓存最有用前缀的容器。

这已成为标准基础设施。它出现在llm-d、NVIDIA Dynamo和SGLang的路由器中。在Red Hat的llm-d演示中，前缀感知路由达到了87.4%的缓存命中率，将冷请求的首次生成时间从2850毫秒缩短到预热请求的340毫秒。这与下面实验2的基本效果相同，但加速倍数更大——8.4倍对比4.8倍——因为他们的模型远大于我这里使用的0.9B模型。

4.2 延长缓存存活时间

另一类系统从时间维度而非位置维度解决这个问题。LMCache和Dynamo的块管理器可以将KV缓存块从GPU内存移动到CPU内存或磁盘，而不是立即丢弃。CacheWise更进一步，专门针对代码代理工作负载调整了驱逐策略（Tiwari等，2026，arXiv:2606.16824）。

Copilot的追踪数据说明了为什么这很重要。当空闲间隔低于两分钟时，缓存命中率保持在95%以上。在两到十分钟之间，命中率迅速下降。十分钟之后，有用的缓存实际上已经消失。对话轮次之间的中位数间隔是2.9分钟。Claude的API缓存寿命是五分钟。换句话说，普通的人类暂停就足以将预热请求变成冷请求。

4.3 在密切相关模型之间重用缓存状态

这是唯一直接针对模型切换的解决方案。DroidSpeak允许一个模型重用另一个模型生成的大量KV状态，同时重新计算选定的层以保持输出质量（Liu等，2024，arXiv:2411.02820，NSDI '26）。

但有一个重要限制：模型需要共享相同的底层架构。实际上，这通常意味着同一基础模型的不同微调版本。如果我从前沿模型切换到完全不同家族的较小模型，就没有可重用的兼容层。缓存无法简单迁移。这就是重要的边界。

Figure 5 — 三个已部署的修复方案，一个共享边界：每个方案仅保持单个模型的缓存热状态，但都无法弥合不同模型之间的差距。图片由作者提供。

当前的服务系统可以在副本之间、空闲时间以及某些相关模型之间保持缓存状态。但它们无法将一个不相关模型的热会话传递到另一个模型。因此，真正的解决方案不是降低任意模型切换的成本，而是从根本上避免不必要的切换。

这引出了两个有效的策略：尽可能在相同模型上保持会话；当确实需要切换模型时，在请求到达前就开始预热下一个模型，而不是在请求处理时才发现需要切换。要实现这一点，我们需要代理工具（agent harness）。

5. 实验

#

问题

单行结果

1

仅路由策略对缓存流量的影响有多大？

相同token输入；粘性重计算10,191次，交替模式19,855次（1.9倍），阶段路由17,455次

2

一次会话中途切换的成本是多少？

0缓存命中，第8轮时需重新计算4,395次；首个token冷启动耗时287ms，热启动仅需60ms

3

这会带来多少成本差异？

无缓存感知的前沿模型成本是基准值的4.88倍；网关节省13%，代理工具节省29%

4

远离前沿模型的路由会影响质量吗？

30个实时编码任务：阶段路由在30/30任务中达到前沿模型31%的成本效率

5.1 测试环境

• 机器：基于NVIDIA DGX Spark（GB10，128GB统一内存）的vLLM服务器（enable_prefix_caching=True，块大小16）

• 模型：0.9B参数模型（我统计的是token数量而非判断答案质量，vLLM的指标接口会报告精确的缓存计数器（prefix_cache_queries_total，prefix_cache_hits_total，单位均为token），无论模型规模如何，因此小型模型已足够完成本测试）

• 会话设置：每次运行均为相同脚本：约1,000个token的系统提示+20轮各约475个token的对话，到第20轮时总提示token数达10,135个

• 重放响应的原因：如果实时生成助手响应，不同策略会产生不同对话，导致对比失去控制。因此所有测试臂均重放相同字节序列，仅路由策略不同

• 模型隔离：两个"模型"在同服务器上实现为两个独立缓存流。系统提示以MODEL-A :: 或MODEL-B :: 开头。由于前缀缓存需要精确前缀匹配，修改首个token可防止两个流共享缓存条目。这种方式实现了与独立模型相同的缓存隔离效果，同时保持分词一致性。因此中途切换标签会产生与路由到不同后端相同的缓存效果。

• 测量控制：三种保障措施使比较过程可控。首先，所有三种策略都会精确重放相同的请求字节，因此路由是唯一变量。其次，缓存和重新计算的标记直接来自服务器的计数器，在每次请求前后立即采样。对于每个请求，prefix_cache_queries_total 的增长与报告的 prompt_tokens 完全一致，确认没有无关流量污染测量结果。第三，交替策略有意对网关式路由有利：它在每次回合之间仅在两个模型之间切换，因此每个模型的缓存最多落后两回合。这与按请求切换的缓存友好性相当。拥有更多后端的网关，或缓存过期时间较短（例如五分钟）的 API，通常会比这种设置经历更多的缓存丢失。

三种路由策略如下：

• 粘性（Sticky）——所有 20 回合都发送到模型 A。这是粘性会话或适配器的默认行为。

• 交替（Alternate）——奇数回合发送到 A，偶数回合发送到 B。这近似于按请求网关路由。

• 阶段（Phase）——回合 1-7 发送到 A，回合 8-14 发送到 B，回合 15-20 返回到 A。这代表一种仅在阶段边界切换模型的适配器——例如，用较便宜的模型进行探索，用更强的模型进行推理，再用较便宜的模型进行最终处理。

5.2 实验 1 —— 路由策略单独使重新计算费用翻倍

图 6 —— 实验 1：在三种路由策略下重放相同对话，为每个分支读取服务器的重新计算计数器。图片由作者提供。

每个分支中相同的 111,871 个提示标记都会通过服务器；只有重新计算成本发生变化。

策略 | 重新计算标记 | 缓存命中率 | 与粘性对比 --- | --- | --- | --- 粘性（Sticky） | 10,191 | 90.9% | 1.0× 阶段（Phase，2 次切换） | 17,455 | 84.4% | 1.7× 交替（Alternate，19 次切换） | 19,855 | 82.2% | 1.9×

图 7 —— 每个请求的提示标记，分为缓存命中（青色）和全价重新计算（橙色）。图片由作者提供。

在稳定状态下，粘性分支每回合重新计算约 479 个标记——仅最新回合。交替分支重新计算 957 个，因为每个模型落后两回合，必须在每次请求时追上。切换成本等于新模型未见过的标记数。交替策略保持差距较小但持续支付该成本。更多后端或无缓存亲和力的负载均衡会导致重新计算惩罚增加，可能接近完整会话成本。

图 8 —— 累计全价标记；线条之间的差距是纯路由开销，基于相同对话。图片由作者提供。

5.3 实验 2 —— 切换成本

图 9 —— 实验 2：切换点附近每个请求的分解，包括服务器已持有的内容和必须重新支付的部分。图片由作者提供。

在第二个实验中，阶段分支使切换成本可见。第 8 回合是模型 B 的首次请求：

• 第 7 回合（模型 A，预热状态）：3,920 个提示标记，3,440 个缓存 — 480 个重新计算。

• 第 8 回合（模型 B，首次接触）：4,395 个提示标记，0 个缓存 — 4,395 个重新计算。

• 第 9 回合（模型 B，预热状态）：4,870 个提示标记，4,400 个缓存 — 约 470 个重新计算。

因此，切换会强制对迄今为止的会话进行完整预填充。切换回来成本较低，但仍需支付模型缺席期间累积的上下文：在第 15 回合，模型 A 重用了 7,740 个标记中的 3,920 个，重新计算了 3,820 个。

这使得偶尔的阶段边界切换变得合理，但每请求路由成本高昂。两次刻意切换在保持会话中间三分之一部分使用不同模型的同时，使粘性路由的重新计算标记增加了7,264个。相比之下，19次无意识切换在未将模型选择与任务阶段对齐的情况下，使标记数量增加了9,664个。

图10 — 通过流式传输测量的相同提示下冷启动与热启动前缀的首次生成时间，三种提示规模下的对比。图片由作者提供。

另一方面，延迟也表现出相同的影响。在约12,000个标记时，相同提示的冷启动耗时287毫秒，而热启动仅需60-95毫秒，速度提升了约3-4.8倍。绝对时间值较小是因为模型规模较小；关键在于比例关系。在前沿模型上，重复的冷启动预填充会直接增加用户可见的延迟数秒。Singhal在前沿规模上也报告了相同趋势：在Harness路由下，回合延迟中位数从81秒降至49秒，部分原因在于缓存热启动路由避免了重复预填充。

5.4 实验3 — 为测量的标记流量定价

图11 — 实验3：使用已发布的Claude API费率对测量的标记流量进行定价，五种路由策略并排对比。图片由作者提供。

一旦应用价格表，标记数量就会转化为成本。我使用Claude API费率对测量流量进行定价：前沿模型为每百万输入标记5美元（Opus 5），高效模型为每百万1美元（Haiku 4.5），缓存读取为0.1倍，缓存写入为1.25倍（定价，缓存）。我仅计算输入侧成本，因为输入在长会话中占主导地位。重新计算的标记按缓存写入计费；缓存命中按读取计费。这是对测量标记的数学计算，而非模拟。

策略（输入侧，20回合测量会话）

成本

对比基准

前沿粘性、缓存感知（基准）

11.45美分

1.00倍

前沿粘性、缓存无感知

55.94美分

4.88倍

每回合交替前沿/高效模型（网关）

10.00美分

0.87倍

阶段路由：高效→前沿→高效（Harness）

8.10美分

0.71倍

高效粘性、缓存感知

2.29美分

0.20倍

图12 — 相同会话的五种实现方式：缓存无感知的成本增加（+388%）超过了模型选择节省的（最多-80%）。图片由作者提供。

三个结果具有重要意义。

• 缓存行为与模型价格同样重要。在前沿模型上采用缓存无感知策略使成本增加4.88倍，这使得更便宜模型的大部分优势消失。Singhal报告了类似但较小的生产惩罚（2.1-2.4倍），输出成本和部分缓存存活率缓解了影响（来源，[1]）。

• 频繁切换消除了网关预期节省的大部分价值。将一半回合转移到便宜5倍的模型理论上应减少40%的输入成本；但实际节省仅为13%，因为额外的重新计算消耗了理论收益的三分之二。随着回合间隔延长或后端数量增加，每回合切换可能比保持在前沿模型更昂贵。

• 粘性路由表现更优。阶段路由在会话的三分之一时间内使用前沿模型，但成本比每回合切换低19%，因为它仅导致两次破坏缓存的切换。它还保持了连续的前沿推理段落，而不是在模型之间来回切换。粘性高效路由的成本仅为前沿基准的0.20倍，仍是那些从不需要前沿推理的会话的最低成本基准。Singhal的生产示例显示了相同的模式：常规会话节省大量成本，混合工作负载部分节省成本，而当硬性会话全程适当保持前沿时则没有节省。

5.5 实验4 —— 在实时路由下测量质量

图13 —— 实验4：30个带有隐藏测试的编码任务，三个实验组，以及在首次运行前通过代码固定的升级规则。图片由作者提供。

前三个实验重放脚本对话，因此无法揭示质量差异。为了测试将某些阶段路由到更便宜模型是否会降低结果质量，我使用付费的Anthropic API进行了第四个实时任务实验。

我创建了30个Python任务，每个任务都有一个规范和隐藏的pytest套件，并通过一个最多四次尝试的编写-测试-重试循环运行。在三个策略下，相同任务以相同顺序进行评估：粘性Opus 5、粘性Haiku 4.5和阶段路由。路由组从Haiku开始，在连续两次测试失败后将任务其余部分切换到Opus。我在实验前固定了该升级规则和解释标准。早期任务集在每个实验组中都实现了30/30的通过率，因此我替换成更难的任务集，并在重新运行前再次锁定规则。

工厂报告了一个生产规模的类比：在Terminal-Bench 2上，前沿模型的通过率高达99%，每成功一次的成本大约低20%（来源，[1]）。

下表显示了使用Claude Opus 5、Haiku 4.5和阶段路由在30个自编Python任务中的质量。每成功一次的成本根据记录的令牌使用量和列表价格计算。

配置

通过率

每成功成本

中位墙钟时间

粘性前沿

30/30（100%）

4.66美分

17.4秒

粘性高效

29/30（96.7%）

0.90美分

6.6秒

阶段路由

1.43美分

6.1秒

阶段路由在每成功成本仅为粘性Opus的31%的情况下，匹配了粘性Opus的通过率。Haiku单独无法解决的唯一任务在升级后得以恢复。然而，这并不能强有力地证明总体质量的均衡性：Haiku在没有帮助的情况下解决了30个任务中的29个，仅剩一个任务用于区分策略。

更明确的结果是切换成本。在首次升级时，Opus没有缓存Haiku所携带对话的前缀，因此10,963个提示令牌以全价重新处理，且没有缓存命中。该任务使路由组的成本达到粘性Opus的2.1倍，而粘性Opus仅用一次尝试就解决了该任务。

这与实验2中看到的切换税相同，但这次是在实时质量循环中测量，而非重放。升级成本很高，但由于只有30个任务中的2个升级，路由仍降低了总成本。这意味着不应避免切换，而应在切换前定价。

6. 决策规则与结论

以上所有内容归结为一个原则：

模型切换是一种购买行为。其价格是重新阅读新模型未见过的上下文。只有拥有会话的层级能看到这个价格，因此只有该层级能智能地进行路由。

这是该实验试图验证的前提。网关路由将模型选择视为每个请求的决策。但一旦请求属于共享会话，这种抽象就会失效：在同一个20轮会话中，按请求切换的路由重新计算了1.9倍于粘性路由的令牌数；一次会话中途的切换触发了4,395个令牌的重新阅读；在真实API计价下，网关节省了13%，而价格表显示应为40%。相比之下，阶段边界路由节省了29%，同时仍将三分之一的轮次分配给前沿模型。

这种差异并不是说网关不好。它们是处理无状态流量的正确路由方式——分类、一次性提取或独立查询——并且作为已经选择模型的框架下的传输层也非常实用。在没有共享会话的情况下，没有累积的上下文需要失效。

另一方面，阶段路由表现良好是因为它进行了切换：两次，有意地，在预期收益足以抵消冷启动的边界处。因此，实际规则不是"坚持使用一个模型"，而是将切换作为会话感知的决策。

图14 —— 一张图说明决策：无状态流量发送到网关路由器，会话发送到框架，默认使用粘性路由。图片由作者提供。

框架是做出该决策的自然位置，因为它能看到的不只是上下文长度。它了解任务状态、工具结果、测试结果和阶段边界。它还构建提示。如果网关之后切换模型，模型B可能会继承为模型A设计的工具模式和指令——这在缓存惩罚之外又增加了质量损失。

由此得出的行动方案如下：

• 默认保持粘性。从高效模型开始，仅在有意时切换。

• 根据任务状态信号升级，而非查询外观。重复的工具失败、失败的测试或规划边界比某一轮听起来有多难是更好的触发条件。

• 为切换定价。将未缓存令牌数×输入价格与预期收益进行比较。在我的第8轮示例中，切换成本为4,395个未缓存令牌；在长期会话中，这个成本可能变得显著。

• 需要更强推理时使用子代理。新的子代理可以在保留父模型温暖缓存的同时，为前沿模型提供少量上下文。

• 从结果中学习。框架可以看到编辑是否通过测试或工具调用是否成功，从而创建网关通常缺乏的反馈。

该结果有一个重要限制。这个实验并未证明路由能保持质量。表1显示升级在30个任务中挽救了一个真实失败；这是证据最薄弱的部分，也是最依赖工作负载的部分。成本结果可以直接测量。质量权衡仍需根据您自己的任务进行验证。

路由只是Harness控制的众多杠杆之一。由于它构建上下文，因此可以缩小上下文范围：按需加载工具模式，返回紧凑引用而非重复大型结果，将冗长的绕行操作卸载到会返回摘要的子代理。Sayed Ali等人将这些技术归类为上下文卸载。在六种基础模型上，他们报告每任务减少38%的token，综合成本降低41%，所有测试模型的成本均降低33%至61%（Sayed Ali等，2026，arXiv:2607.06906）。他们的研究结果强化了从缓存角度得出的相同结论：编排对成本的影响可能比模型菜单本身更为重要。

在安装路由器之前，请问它一个问题：“这个切换操作将产生什么成本？”如果它无法回答，说明它并未全面考虑会话的经济性。

7. 参考文献与资源

来源（报告与文章）

1. Abhay Singhal（Factory AI技术团队成员），“基于Harness的模型路由架构”（Factory Router），X文章，2026。https://x.com/_AbhaySinghal/article/2088361241928732705 · 产品页面：https://factory.ai/product/router — 生产结果：58%的综合节省，缓存盲区2.1–2.4倍，文中引用的Terminal-Bench 2基准数值。

1. Red Hat开发者，“使用llm-d实现KV缓存感知路由，提升AI推理效率”，2025。https://developers.redhat.com/articles/2025/10/07/master-kv-cache-aware-routing-llm-d-efficient-ai-inference — 厂商工程实践；上述87.4%命中率及2,850 ms → 340 ms首令牌延迟数据的来源。

核心技术论文

RouteLLM：使用偏好数据学习路由LLM — Ong, Almahairi, Wu, Chiang等（LMSYS），2024 · arXiv:2406.18665 · ICLR 2025。经典的按查询学习路由器；图14无状态分支的正确工具。

FrugalGPT：在降低成本的同时提升性能的大型语言模型使用方法 — Chen, Zaharia, Zou（斯坦福大学），2023 · arXiv:2305.05176。LLM级联；网关路由的先驱。

野外的智能体编码：生产规模下GitHub Copilot的特征分析 — Liu, Qiu, Goiri, Fonseca, Bianchini, Choukse（UIUC + 微软Azure研究院），2026 · arXiv:2608.00101。1350万采样会话，76亿LLM调用。90%/55%/8%缓存命中率、>275:1输入输出不对称性、两到十分钟空闲悬崖及会话固定建议的来源。

DroidSpeak：微调模型变体间的KV缓存共享 — Liu等，2024 · arXiv:2411.02820 · NSDI '26。我找到的唯一跨模型KV重用方案，且需要共享架构。

Harness效应：编排设计如何定义企业智能体AI的token经济性 — Sayed Ali等，2026 · arXiv:2607.06906。测量的六种编排机制家族：每任务减少38%token，综合成本降低41%，发现编排层比模型选择是更大的成本杠杆。

CacheWise：优化KVCache管理以高效服务LLM编码智能体 — Tiwari, Chugh, Rickert, Peter, Mahajan, Shen，2026 · arXiv:2606.16824。针对编码智能体轨迹优化的驱逐策略。

工具与基础设施

vLLM — 推理引擎；自动前缀缓存设计文档：https://docs.vllm.ai/en/v0.8.1/design/automatic_prefix_caching.html · Apache-2.0。指标计数器 prefix_cache_queries_total / prefix_cache_hits_total（以令牌为单位）是本文的度量工具。- 前缀缓存感知调度器 — llm-d（CNCF）：https://github.com/llm-d/llm-d · Kubernetes Gateway API 推理扩展：https://gateway-api-inference-extension.sigs.k8s.io/ · NVIDIA Dynamo KV感知路由：https://docs.nvidia.com/dynamo/user-guides/kv-cache-aware-routing · SGLang 路由器：https://github.com/sgl-project/sglang。同一模型的所有副本之间均进行路由。

LMCache — vLLM 的 KV 缓存卸载与重用层：https://github.com/LMCache/LMCache · Apache-2.0。延长缓存存活时间；不进行模型间的转换。