Hugging Face Blog

Model Routing Is Simple. Until It Isn’t.

8.5内容质量

TL;DR · AI 摘要

模型路由看似简单,实则涉及成本、复杂性和延迟的多维优化,需考虑缓存、任务不可见性及系统交互等隐藏因素。

核心要点

  • 模型成本受缓存机制影响显著,Sonnet因低缓存读取费用抵消了更高基础定价
  • 任务难度在路由时难以预估,实际执行中可能触发复杂流程
  • 延迟不仅取决于模型速度,还与系统交互和缓存效率密切相关

结构提纲

按章节快速跳转。

  1. 模型路由看似简单,实际面临三大复杂性挑战。

  2. 模型成本受缓存机制影响,实际费用与预期定价存在显著差异。

  3. 任务难度在路由时难以准确评估,需平衡多维度约束条件。

  4. 模型延迟受系统交互影响,单纯优化模型速度效果有限。

  5. 模型路由需构建多目标优化系统,而非单一维度决策。

思维导图

用一张图看清主题之间的关系。

查看大纲文本(无障碍 / 无 JS 友好)
  • 模型路由复杂性
    • 成本维度
      • 缓存机制影响
      • 定价与实际费用差异
    • 复杂性维度
      • 任务难度不可见
      • 多约束平衡
    • 延迟维度
      • 系统交互影响
      • 缓存效率

金句 / Highlights

值得收藏与分享的关键句。

#模型路由#AI系统优化#HuggingFace#IBMResearch
打开原文

模型路由看似简单。直到它变得复杂。

返回文章列表

[0

[-1

企业

]

文章

发布于2026年7月15日

点赞

20

[

  • +14

Yara Rizk

yarizk

关注

ibm-research

Eyal Shnarch

eishna

Jason Tsay

jsntsay

Merve Unuvar

mrvnvr

在代理中构建路由器听起来像是一个简单的胜利。将简单请求发送到价格较低的模型,将昂贵的模型保留给复杂任务,或按专业领域进行路由——用Claude处理代码,用Gemini处理多模态任务等。分类器或启发式方法做出决策,成本降低,性能保持稳定。完成。

但事实并非如此。大多数路由系统假设模型选择是一个分类问题。在我们为智能体系统构建路由的实际经验中,看似模型选择的问题很快就会演变为系统优化问题。三个维度让这个问题变得出乎意料地困难。

1. 成本不仅仅是模型定价

我们原本预计GPT-4.1会比Claude Sonnet 4.6更便宜。事实并非如此。

AppWorld测试挑战的417个任务中,使用相同的CodeAct代理,Sonnet总成本为79美元(每任务0.19美元),而GPT-4.1总成本为155美元(每任务0.37美元)——几乎是两倍。从纸面数据来看,这似乎毫无道理。GPT-4.1的输入和输出令牌价格都更低,而Sonnet完成相同任务需要大约三倍的推理步骤。仅从标价来看,GPT-4.1应该明显占优。

解释原因?缓存——这是大多数路由讨论完全忽略的因素。智能体工作负载往往在不同步骤之间重复使用大量上下文。当缓存命中率较高时,有效输入成本会大幅下降。Sonnet较低的缓存读取价格使其在这种模式中获得不成比例的优势,足以抵消其较高的基础定价和较长的推理路径。

启示:实际成本取决于模型、工作负载和服务基础设施之间的相互作用。只查看定价表的路由器是在针对错误的指标进行优化。

2. 复杂性不仅仅是任务难度

一种常见的路由策略是估计任务难度并将困难任务发送给更强的模型。这个思路直观,但在两个方面存在缺陷。

首先,难度在路由时往往不可见。像"总结这份合同"这样的请求看似简单,但可能需要触发检索、合规检查、工具使用和多轮优化才能完成。同时,一个高度技术性的提示可能被小型专业模型高效处理。你通常要等到执行开始后才能知道任务的实际难度。

其次,即使你能完美估计难度,它也只是众多信号中的一个。在生产环境中,路由器需要同时平衡成本、延迟、模型专业性和可靠性。企业部署还会增加更多因素:合规要求、数据驻留规则、隐私限制、批准模型列表。一个理想情况下应发送到某个模型的任务可能因为治理要求需要发送到其他模型,而路由器必须优雅地处理这种情况。

路由器不是在解决一个问题。它们一直在同时权衡成本、质量、延迟、合规性和可靠性。

路由本身会增加开销。基础设施因素——模型运行的硬件、缓存是否预热、端点的负载情况——通常主导着端到端的响应时间。如果服务条件不理想,理论上更快的模型仍可能导致更差的用户体验。

然后是路由粒度问题。每任务路由一次只会带来最小的开销。但若在每个步骤都进行路由(这能提供执行中途调整的灵活性),则每个额外的决策点都会引入延迟和操作复杂性。

忽视服务系统的路由器实际上是在针对错误的现实进行优化。

那我们是如何应对的?

这些经验教训塑造了我们路由器的设计。关键转变在于:我们停止将路由视为分类问题,转而将其视为优化问题。算法不再问"哪个模型最适合这个任务?",而是同时在成本、质量和延迟之间进行优化——同时保持足够轻量,避免自身成为瓶颈。

下图展示了CodeAct代理在AppWorld测试挑战中的结果。每个蓝色方块代表我们路由器的不同配置,描绘出成本-准确率前沿。重要的是不是某个单一节点——而是路由器能根据你希望优先考虑成本、延迟还是准确率,提供一系列操作点选择。配置1(延迟优化)在84%准确率下实现93美元成本和83秒耗时——相比单独运行Opus,成本降低21%,延迟降低9%,仅损失4%准确率。配置2进一步降低了成本。

请注意标准基于难度的路由器(青色菱形)虽然准确率范围相似,但成本更高——它无法像基于优化的方法那样探索完整的权衡空间。由于优化本身非常轻量(每任务约6毫秒和2KB内存),路由器不会成为我们之前警告的瓶颈。

更宏观的视角

从这项工作中我们得到的教训是:路由本质上不是关于选择模型。它是关于优化系统。模型只是一个变量——虽然重要,但只是众多变量中的一个,包括缓存行为、基础设施状态、合规约束和工作负载模式。

当路由效果良好时,很少是因为找到了某个任务的"最佳"模型。而是因为找到了整个系统的最佳运行点。这比分类问题更难,但正是值得解决的问题。

我们将在后续文章中分享更多关于方法技术细节的内容。与此同时,如果你正在为自己的智能体系统构建路由功能,我们很乐意了解你遇到的权衡取舍。

致谢

本文受到与多位同事深入讨论的影响,他们提出的深刻问题、反馈和见解帮助完善了我们的思考。

更多该作者的文章

ScarfBench:用于企业Java框架迁移的AI代理基准测试

24

2026年6月30日

使用CUGA构建真实智能体应用:轻量级框架上的二十余个工作示例

38

2026年6月23日

社区

编辑

预览

通过拖拽、粘贴或

点击此处

上传图片、音频和视频。

点击此处上传图片

评论

· 注册或登录以评论

  • +8

/think