模型路由看似简单，实则不然。

来源：https://huggingface.co/blog/ibm-research/model-routing-is-simple-until-it-isnt 返回文章列表 (https://huggingface.co/blog)

• 1. 成本不止是模型定价 (https://huggingface.co/blog/ibm-research/model-routing-is-simple-until-it-isnt#1-cost-is-more-than-model-pricing)
• 2. 复杂性不止是任务难度 (https://huggingface.co/blog/ibm-research/model-routing-is-simple-until-it-isnt#2-complexity-is-more-than-task-difficulty)
• 3. 延迟不止是模型速度 (https://huggingface.co/blog/ibm-research/model-routing-is-simple-until-it-isnt#3-latency-is-more-than-model-speed)
• 我们是如何处理的？ (https://huggingface.co/blog/ibm-research/model-routing-is-simple-until-it-isnt#so-how-did-we-handle-this)
• 更广阔的视角 (https://huggingface.co/blog/ibm-research/model-routing-is-simple-until-it-isnt#the-bigger-picture)
• 致谢 (https://huggingface.co/blog/ibm-research/model-routing-is-simple-until-it-isnt#acknowledgement)

在你的智能体中构建一个路由器，听起来像是一笔稳赚不赔的买卖。将简单请求发送给更便宜的模型，把昂贵的模型留给更困难的任务，或者按专长路由——Claude 处理代码，Gemini 处理多模态，诸如此类。一个分类器或启发式算法做出判断，成本下降，性能保持。搞定。

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

https://huggingface.co/blog/ibm-research/model-routing-is-simple-until-it-isnt#1-cost-is-more-than-model-pricing1. 成本不止是模型定价

我们原以为 GPT-4.1 会比 Claude Sonnet 4.6 更便宜。结果并非如此。

在 AppWorld Test Challenge 上使用相同的 CodeAct 智能体进行 417 项任务，Sonnet 总成本为 79 美元（0.19 美元/任务），而 GPT-4.1 成本为 155 美元（0.37 美元/任务）——几乎是两倍。从纸面上看，这毫无道理。GPT-4.1 的 token 定价在输入和输出上都更低，而 Sonnet 完成相同任务需要的推理步骤大约是前者的三倍。单看标价，GPT-4.1 应该轻松胜出。

原因何在？缓存——这是大多数路由讨论完全忽略的因素。智能体工作负载往往会在多个步骤中重复使用大量上下文。当缓存命中率很高时，有效输入成本会大幅下降。Sonnet 更低的缓存读取定价使其从这种模式中获益不成比例，足以抵消其较高的基础定价和更长的轨迹路径。

结论：实际成本取决于模型、工作负载和服务基础设施之间的相互作用。一个只看定价表的路由器，是在用错误的数据进行优化。

https://huggingface.co/blog/ibm-research/model-routing-is-simple-until-it-isnt#2-complexity-is-more-than-task-difficulty2. 复杂性不止是任务难度

一种常见的路由策略是估算任务的难度，然后将困难的任务发送给更强的模型。这很直观，但会在两个方面失效。

首先，难度在路由时往往是不可见的。像“总结这份合同”这样的请求看起来很简单，但可能触发检索、合规检查、工具使用以及多轮优化才能完成。与此同时，一个高度技术性的提示词可能被一个较小的专用模型高效处理。你通常在任务执行开始后才知道它实际上有多难。

其次，即使你能完美估算难度，它也只是众多信号中的一个。在生产环境中，路由器需要同时平衡成本、延迟、模型专长和可靠性。企业部署会叠加更多因素：合规要求、数据驻留规则、隐私约束、批准的模型列表。一个理想情况下应交给某个模型的任务，可能因治理原因需要转到别处——路由器必须优雅地处理这种情况。

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

https://huggingface.co/blog/ibm-research/model-routing-is-simple-until-it-isnt#3-latency-is-more-than-model-speed3. 延迟不止是模型速度

人们很容易仅从模型大小的角度考虑延迟——更大的模型更慢，更小的模型更快。但用户实际体验到的延迟取决于更多因素。

路由本身会引入开销。基础设施因素——模型运行在什么硬件上、缓存是否已预热、端点有多繁忙——通常主导端到端的响应时间。如果服务条件不佳，理论上更快的模型仍然可能产生更慢的体验。

此外还有路由的粒度。每个任务路由一次增加的开销很小。但在每一步都路由——这让你能在执行过程中更灵活地调整——意味着每个额外的决策点都会引入延迟和操作复杂性。

忽略服务系统的路由器，是在用错误的现实进行优化。

https://huggingface.co/blog/ibm-research/model-routing-is-simple-until-it-isnt#so-how-did-we-handle-this我们是如何处理的？

这些经验教训塑造了我们构建路由器的方式。关键的转变是：我们不再将路由视为分类问题，而是将其视为优化问题。我们的算法不是问“哪个模型最适合这个任务？”，而是同时优化成本、质量和延迟——同时保持足够轻量，以避免自身成为瓶颈。

下图显示了在 AppWorld Test Challenge 中使用 CodeAct 智能体的结果。每个蓝色方块是我们路由器的不同配置，勾勒出一条成本-准确率前沿曲线。重要的不是任何单个点——而是路由器提供了一系列可操作点供你选择，取决于你是想优先考虑成本、延迟还是准确率。配置 1（延迟优化）在成本 93 美元、时间 83 秒的情况下达到 84% 的准确率——与单独运行 Opus 相比，成本降低 21%，延迟降低 9%，准确率仅下降 4%。配置 2 进一步降低了成本。

在 AppWorld Test Challenge 上使用 CodeAct 智能体的路由结果 (https://raw.githubusercontent.com/AgentToolkit/altk-main/main/assets/routing-results-hf-blog.png)

请注意，一个标准的基于难度的路由器（青色菱形）落在相似的准确率范围内，但成本更高——它无法像基于优化的方法那样探索完整的权衡空间。而且由于优化本身很轻量（每个任务约 6 毫秒和 2 kB 内存），路由器不会成为我们之前警告过的瓶颈。

https://huggingface.co/blog/ibm-research/model-routing-is-simple-until-it-isnt#the-bigger-picture更广阔的视角

我们从这项工作中得到的教训是，路由实际上不是关于选择模型，而是关于优化系统。模型是一个变量——一个重要的变量，但只是缓存行为、基础设施状态、合规约束和工作负载模式等众多因素中的一个。

当路由工作良好时，很少是因为它找到了给定任务的“最佳”模型，而是因为它找到了整个系统的最佳操作点。这是一个比分类更难的问题，但却是值得解决的那个。

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

https://huggingface.co/blog/ibm-research/model-routing-is-simple-until-it-isnt#acknowledgement致谢

本文的撰写得益于与同事们的多次交流，他们富有洞察力的提问、反馈和见解帮助完善了我们的思考。