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

IBM 研究员发文：给 AI Agent 加个“路由”没那么简单，成本、复杂度和延迟全是坑 给 AI Agent 装一个“模型路由器”，听起来是个稳赚不赔的买卖：把简单问题丢给便宜的小模型，复杂任务交给昂贵的大模型，或者按专长分流——写代码用 Claude，多模态任务用 Gemini。一个分类器或一套规则就能搞定，成本降了，性能还稳了，完美。但 IBM 研究院的几位研究员在 HuggingFace 博客上发文泼了一盆冷水：现实远没那么简单。他们在为企业构建 Agent 路由系统时发现，模型选择问题很快就会变成一个系统优化问题，有三个维度让这件事出奇地难。 第一个坑是成本。你以为看定价表就能算清楚账？大错特错。研究员在 AppWorld 测试集上用同一个 CodeAct Agent 跑了 417 个任务，结果令人大跌眼镜：Claude Sonnet 4.6 总花费 79 美元（每任务 0.19 美元），而 GPT-4.1 花了 155 美元（每任务 0.37 美元），几乎是前者的两倍。从定价表上看，GPT-4.1 的输入输出 Token 单价都更低，而且 Sonnet 完成相同任务需要的推理步骤是 GPT-4.1 的三倍左右。按常理，GPT-4.1 应该完胜。问题出在缓存上——这是大多数路由讨论完全忽略的因素。Agent 工作负载会在多个步骤中反复使用大量上下文，当缓存命中率高时，有效输入成本会大幅下降。Sonnet 的缓存读取定价更低，让它从这种模式中获得了不成比例的好处，足以抵消其更高的基础定价和更长的推理轨迹。结论很扎心：实际成本取决于模型、工作负载和服务基础设施之间的相互作用。一个只看定价表的路由器，从一开始就在对着错误的数据做优化。 第二个坑是任务复杂度。常见的路由策略是预估任务难度，把难的交给更强的模型。直觉上没问题，但实际操作中会从两个方向崩塌。首先，难度在路由时往往是不可见的。一个“总结这份合同”的请求看起来很简单，但可能触发检索、合规检查、工具调用和多轮精炼才能完成；而一个高度技术性的提示词，可能被一个小型专业模型高效处理。你通常要到执行过程中才知道任务到底有多难。其次，就算你能完美预估难度，它也只是众多信号中的一个。在生产环境中，路由器需要同时平衡成本、延迟、模型专业性和可靠性。企业部署还会叠加更多约束：合规要求、数据驻留规则、隐私限制、批准的模型列表。一个理想情况下应该发给某个模型的任务，可能因为治理原因必须发给另一个——路由器必须优雅地处理这种切换。路由器不是在解决一个问题，而是在不断权衡成本、质量、延迟、合规和可靠性。 第三个坑是延迟。你可能会觉得延迟纯粹由模型大小决定——大模型慢，小模型快。但用户实际感受到的延迟远不止于此。路由本身就会带来开销，基础设施因素——模型跑在什么硬件上、缓存是否已预热、端点有多繁忙——往往主导端到端的响应时间。一个理论上更快的模型，如果服务条件不对，仍然可能带来更慢的体验。此外还有路由粒度的问题：每个任务路由一次，额外开销很小；但如果在每个步骤都路由——这能让你在执行过程中更灵活地调整——那么每一个额外的决策点都会引入延迟和操作复杂性。一个忽略服务系统的路由器，同样是在对着错误的现实做优化。