Token Spend Out of Control? The Case for Smarter Routing

TL;DR · AI 摘要
Token Spend Out of Control? The Case for Smarter Routing ByteByteGo Jun 08, 2026 Code review needed a new architecture....
核心要点
- 主题聚焦:Token Spend Out of Control? The Case for Smarter
- 来源:ByteByteGo Newsletter,建议结合原文判断细节。
- AI 分析暂不可用,本条为保底评分与摘要。
令牌消耗失控?智能路由的必要性
ByteByteGo
2026年6月8日
代码审查需要新的架构。我们开源了它。(赞助)
当AI开始编写代码时,代码审查变得不再有效。
AgentField刚刚发布了一个具有动态元协调功能的多代理代码审查工具。规划器首先阅读每个PR,然后为它编译一个自定义的审查策略 - 对于身份验证更改使用安全代理,对于迁移使用模式代理,对于重构使用行为代理。每个团队都可以进行配置。使用一个docker compose即可部署。它可以在开放或封闭模型(Kimi、DeepSeek、Claude)上运行。在开放模型上,每次审查的费用仅需几美分 - 不需要按座位数的许可证。
AgentField的说明:代码审查的四个职责,其中三个在AI撰写初稿后仍然承担负载,以及为什么静态流水线会失败。
→ 星标并部署
大型语言模型代理可以在单个任务上消耗数百万个令牌。它们将模型置于循环中,每一步都重新发送完整的上下文,并且通常调用最昂贵的模型。成本增长非常迅速。
为了了解团队如何在生产环境中控制这一点,我们与Kilo的联合创始人Scott Breitenother和Sid Sijbrandij进行了交谈,Kilo是一个开源的编码代理,每天都要处理大量的这些循环。他们分享的模式并不特定于编码,而且其中大部分也不仅限于Kilo。类似的方法出现在Cursor、Cline和Aider等工具中,以及OpenRouter和RouteLLM等共享基础设施中。如果你构建的是任何需要进行多次模型调用的代理,这些想法同样适用。
为什么运行一个大型语言模型代理会变得昂贵
向语言模型发出一个请求通常是便宜的。但基于同一模型构建的代理却并非如此。区别在于代理会进行多次调用,而不是一次,而且它倾向于将这些调用发送到最昂贵的模型。这两点都会推高成本。
1. 前沿模型每令牌成本很高
最强大的模型被称为前沿模型。它们位于可能性的最前沿,并且每令牌的成本最高。它们之下是一系列更便宜的模型,这些模型在价格上有所降低,但牺牲了一些能力,直到小型模型,它们非常便宜,但仍能很好地处理简单的工作。
成本阶梯:前沿模型 vs 小型模型
这之间的差距很大。对于相同的工作,顶级模型的成本通常是小型模型的十倍以上。使用前沿模型来驱动其应用程序的团队,对所有内容都支付前沿模型的价格,这使得整个系统变得昂贵。
LLM输入/输出成本(来源:Together AI)
2. 代理循环会将每次调用乘以数倍
前沿模型每令牌成本很高,但在标准的聊天机器人设置中,成本是可控的。例如,Claude Opus 4.7的输入令牌成本为每百万个5美元,输出令牌成本为每百万个25美元。一个单一的问题和答案只有几千个令牌,因此成本不到两美分。以这个速度,你可以提出很多问题,而成本才变得重要。
聊天机器人调用成本只需几美分
LLM代理则不同。它们不会立即产生答案。它们在一个循环中运行。代理读取任务,执行诸如运行工具或读取文件之类的操作,查看结果,然后决定下一步该做什么。要了解为什么这会变得昂贵,请看每一步向LLM发送了什么内容。
代理循环
由于大语言模型(LLM)本身没有记忆,每一步都需要将所有内容打包到上下文中。这包括指令、问题、工具的模式、工具调用、工具结果以及LLM的中间思考过程。代理在每一轮都会重新发送所有内容,因此随着循环的运行,上下文会不断增长,每次对LLM的调用成本都会比上一次更高。
上下文随着轮数增加而增长
一个会话可能一开始只有几千个标记。当代理读取了十几个文件并运行了十几个工具后,接近结束时的一个请求可能携带超过十万个标记。因此,代理使用的标记数量可能比一个聊天机器人的问题多出许多倍。
不断增长的上下文只是问题的一半。另一半是代理调用模型的频率。在正常的聊天中,人们需要花时间输入问题并花精力阅读答案,因此他们只会问有限的问题。而代理则没有这样的限制。一个代理如果审查每一个代码更改、对每一个提交进行评论、为每一个函数编写测试,就会以软件允许的最快速度发出请求。
你的AI流水线通过了所有测试。然后它上线了。(赞助)
Datadog的AI时代免费开发者工具包为你提供四种资源,帮助你弥补差距,从在发布前发现易碎测试和CI瓶颈,到对每个LLM调用进行监控,以确保质量、延迟和成本没有退化。
你将学到如何:
- 在AI交付周期中发现并消除CI流水线故障,防止其阻塞发布。
- 使用功能标志控制AI的发布,并使用DORA指标衡量团队的交付效率。
- 评估LLM输出的质量,并在生产环境中检测每个模型调用的延迟漂移。
下载工具包
标准方法:将请求路由到合适的模型
不断增长的上下文和没有人为限制的代理运行方式都是代理工作方式的固有特性,因此你无法真正减少发送的标记数量。你能改变的是哪个模型接收这些请求,这就是路由的作用。路由器会查看每个请求,决定哪个模型足够好,然后将其发送到该模型。
将每个请求路由到合适的模型
例如,考虑一个代码代理在执行任务时发出的请求。其中一些请求很困难,比如设计系统应该如何构建。大多数请求则很简单,比如重命名变量或总结文件。困难的请求需要前沿模型。简单的请求不需要前沿模型,但如果将它们发送到前沿模型,成本却是一样的。通过路由,可以将每个请求发送到最便宜的能够处理它的模型,这样你只有在真正需要前沿模型时才为其付费。
根据请求的复杂性进行路由
路由器内部的工作原理
路由器需要两样东西。它需要一种将请求发送到多个不同模型的方式。它还需要决定每个请求应该使用哪个模型。这两个问题是分开的,保持它们的分离可以使设计更加清晰。
路由器的两个组件
第一个问题是入口点。通常每个模型提供商都有自己的请求格式,因此使用多个模型意味着为每个模型编写单独的代码。一个统一的入口点可以提供一种标准的请求格式,路由器将其转换为所选提供商期望的格式,发送请求,并将响应转换回来。你只需使用一种格式进行编写。路由器会为你与所有提供商进行通信。没有这个入口点,模型之间的路由从一开始就不具备可行性。
一个入口点,多个提供商
第二个问题是决策。给定的请求应该使用哪个模型?实际上,决策通过两种方式处理。
第一种方式是根据已有的信号进行路由。如果系统已经知道请求的类型,就可以将该类型的工作映射到对应的模型。已知是规划任务的请求会映射到一个强大的推理模型,已知是简单编辑的请求会映射到一个成本较低的模型。这种方式非常可靠,几乎不需要额外的运行成本,因为决策只是一个查找操作。但问题是,你一开始就需要一个可信的信号。
根据已知信号进行路由
第二种方式是根据请求本身预测出正确的模型。系统读取请求,判断其难度,然后选择一个最有可能正确回答该请求的最便宜的模型。即使你对请求没有任何先验信息,这种方式也能正常工作。代价是,这种预测必须从数据中学习,并且随着模型的变化而持续更新。错误的预测会将一个复杂的请求发送到无法处理它的模型上。
从请求中进行预测
大多数实际系统使用一个入口点,并在其上使用上述两种决策方法之一。入口点提供了对多个模型的访问。决策技术则在这些模型中进行选择。
路由实际节省了多少成本
路由节省了成本,因为大多数请求并不需要前沿模型,而廉价模型已经足够好,可以处理这些请求。节省的成本是前沿模型价格与实际支付的廉价模型价格之间的差额,累计所有不需要昂贵模型的请求。
正确路由的效果非常明显。在一项由加州大学伯克利分校和Anyscale研究人员广泛引用的研究中,一个路由器在保持前沿模型95%质量的同时,将成本降低了约一半。它通过仅将困难请求发送到前沿模型,其余请求发送到更便宜的模型来实现这一点。更广泛地说,该领域的研究结果通常在成本节省方面介于40%到70%之间,且在困难任务上的质量下降很小。
路由器成本节省(来源:Github)
不过,这些节省也伴随着权衡。决策步骤会为每个请求增加一点延迟,并且成为另一个可能出错的因素。错误的决策会通过将困难请求发送到弱模型而影响质量。预测路由器需要数据和维护来保持准确性。此外,在一个任务中切换不同模型家族可能会带来问题,因为一个模型产生的内部推理并不总是可以被另一个模型读取。这些都不是否定这个想法的理由。它们正是为什么路由是一个重要但具有挑战性的问题。
案例研究:Kilo如何在生产环境中路由请求
为了使这个概念更加具体,我们可以看一下一个能够端到端实现这一功能的系统。Kilo开发了一个开源的AI编码代理,该代理通过长循环驱动模型来编写和修复代码,其用户群体的请求量非常高。为了在不使成本失控的情况下处理如此大的请求量,Kilo团队构建了自己的路由层——Kilo网关,并将所有流量通过该网关进行处理。以下部分的数字和设计选择均来自该生产系统。
网关
Kilo 网关是前面提到的入口点。它在超过五百个模型前面提供了一种统一的请求方式,因此从一个模型切换到另一个模型只需一行代码的更改。它使用了大多数现有代码已经编写好的请求格式,因此只需将现有代码指向网关即可使用。此外,它还允许团队使用自己的提供商账户,并仅支付路由费用,而不是模型的溢价费用。
决策层是其中最有趣的部分。Kilo 使用第一种方法:它根据已经拥有的信号进行路由。其编码代理始终知道自己当前处于什么模式,因为它在不同的模式下工作,例如规划、编写代码或调试。代理会在每次请求中发送该模式。网关读取该模式,并将其映射到一个模型。该模式是工作难度的可信信号,因此系统可以在不从请求文本中猜测难度的情况下,获得大部分路由的好处。
Kilo 网关:按模式路由
路由被组织成用户可以选择的不同层级。最高层级将要求较高的模式(如规划和调试)发送到最强的模型,而将常规模式(如代码编辑)发送到功能强大但成本较低的模型。平衡层级将所有内容发送到经济型模型。免费层级映射到无成本模型。一个独立的内部层级则静默地处理后台任务,如编写提交信息,使用小型模型以避免消耗昂贵的计算资源。
路由层级
一个设计选择解释了系统如何保持最新。从模式到特定模型的映射并不存储在您机器上的软件中。它由 Kilo 自己的系统提供,并经常更新。因此,随着价格和质量的变化,底层模型可以被替换,而您选择的层级保持不变。
这种灵活性有一个需要理解的成本。例如,在单个任务的回合之间,一个层级可能会更改模型,例如随着模式的变化,从一个提供商的模型切换到另一个提供商的模型。问题是,推理模型以自己的格式生成内部思考,一个提供商的模型无法读取另一个模型生成的思考。因此,当层级在任务中途切换模型家族时,Kilo 必须在下一次调用之前丢弃中间的推理。代理继续工作,但会丢失一些之前构建的上下文,这可能会在下一步中略微影响质量。
Kilo 的生产数据所显示的内容
Kilo 在 2026 年第一季度发布了其自身生产流量的数据。这些是公司内部从付费使用中获得的数字,未经独立验证,但它们是有用的,因为它们来自实际的工作负载,而不是基准测试。
当团队允许网关自行路由,而不是让用户手动选择模型时,每次请求的平均成本下降了约三分之一。Kilo 发现,80% 到 90% 的请求并不需要前沿模型。在数百万次请求中,将这些任务路由到更便宜的模型,确实带来了实际的节省。
自动路由使成本降低三分之一(Kilo 内部付费生产流量,2026 年 3 月)
更大的惊喜在于,层级选择对成本的影响远超预期。对于相同的编码工作,使用较便宜的均衡层级运行,每请求的成本比使用顶级层级运行低了十倍以上,这种差距在团队测量的所有类型的工作中都表现出来。即使是那些由小型模型处理的最小后台任务,成本也仅需几分钱。大多数节省的成本并非来自于任何巧妙的策略,而是来自于简单地将常规工作从最昂贵的模型中移除。
均衡层级与顶级层级的成本节约
为了量化这一价值,团队估计,如果在该季度将常规流量强制路由到顶级模型上,将会多花费约八万七千美元。这大致相当于在真实工作负载上路由错误所造成的成本。
Kilo团队还分享了一个关于缓存的有用发现。缓存,即系统保存重复上下文以避免重复计费,通常被视为削减账单的主要方式。Kilo发现,即使在许多功能上缓存重用率超过80%,总支出仍然很高,因为请求数量太多,而每个上下文中无法缓存的部分仍然很大。缓存确实有帮助,但无法单独解决数量问题。路由作用于成本的另一个部分,这也是为什么团队倾向于将两者结合使用的原因。
对于任何大规模运行代理的团队的启示
Kilo的数据指出了几个适用于任何大规模运行代理团队的教训,无论他们使用的是哪种路由器或模型。
设定预算,并将AI支出视为任何其他基础设施成本一样对待。仅仅切换到更便宜的模型并降低每token的费率可能很诱人。但较低的费率通常会导致使用量增加,因为之前过于昂贵的工作现在看起来变得可负担。因此,即使每个请求的成本降低,总账单往往会增加。
为整个工作负载设定一个月度预算,并将其视为固定值。然后目标不是每个请求的最低价格,而是在这个预算内能完成的最有用的工作。
优化之前先进行测量。成本主要由每个请求的token数量驱动,这主要是上下文大小的函数,而不是请求来自产品哪个部分。两个请求都可以标记为“聊天”,但一个可能携带一千个token,而另一个可能携带十万个token。
因此,记录每个请求的token数量,并为每个请求标记任务类型和发送它的功能。然后按组汇总token数量。主导你token总数的组,而不是发送请求数最多的组,才是你实际支出的地方,也是路由效果最显著的地方。
基于你已有的最强信号进行路由。如果系统已经知道任务类型,例如请求是计划还是简单的编辑,就直接根据任务类型进行路由。从任务类型到模型的映射是静态的,运行成本低、可预测,并且在路由看起来错误时易于调试。只有在没有这种信号时,才退而求其次,从请求文本中推断难度,因为这意味着要运行一个需要训练、评估并随着模型变化而持续更新的分类器。
无论哪种方式,路由器只有在背后有真正多样化的模型时才能发挥作用。让它可以访问从前沿模型到小型便宜模型的完整范围,这样当工作允许时,它就可以选择一个真正更便宜的选项。
如今,路由仍然需要手动操作。你必须选择一个层级,设置它所路由的信号,并决定哪些任务可以安全地发送到更便宜的模型上。这方法可行,但你需要持续关注。
未来这将变得更容易。路由器开始自行做出这些选择。不再需要被告知任务类型,路由器将阅读请求,判断其难度,并自行选择模型。随着时间推移,它会越来越精准,为任务的每个步骤选择合适的模型,而不是为整个任务选择一个模型。目标是让路由逐渐退居幕后,就像负载均衡那样。你只需设定预算和质量标准,系统将处理其余部分。
每年,这一点变得越来越重要,因为代理程序的能力持续增强。它们运行时间更长,能够自主行动,并在无人监督的情况下发送更多令牌。随着这一趋势的发展,选择合适的模型不再只是节省一点成本的方式,而是决定运行代理程序是否可行的关键因素。主要结论是:路由不再是成本优化的手段,它正在成为实现雄心勃勃的代理程序的重要组成部分。