在 417 个真实 Agent 任务的实测中，标价更便宜的 GPT-4.1 反而比 Claude Sonnet 4.6 贵了将近一倍。Hugging Face 团队由此得出结论：把模型路由当作"给任务挑最合适模型"的分类题，是在优化错误的数字。
在 AppWorld Test Challenge 的 417 个任务上，使用同一个 CodeAct Agent，两家的实测账单是这样的：
注：柱形按单任务成本线性缩放，GPT-4.1 的 $0.37 对应满格。两方使用同一 Agent 框架、同一任务集，差异仅来自模型与服务端。
按纸面算，这说不通：GPT-4.1 的输入输出单价都更低，Sonnet 完成同样任务大约需要三倍的推理步数。 sticker price 上 GPT-4.1 本该轻松取胜。
读定价表 → 估任务难度 → 选"更便宜"的那个。忽略缓存、轨迹长度、服务端状态的相互作用。
模型 × 工作负载 × 服务基础设施，三者交互。Agent 跨步骤复用大段上下文时，缓存命中率会让有效输入成本断崖式下跌。
Sonnet 的缓存读定价更低，在高复用的工作负载里吃满了红利，足以抵消它更高的基础定价和更长的轨迹。只看定价表的路由器，是在对错误的数字做优化。
常见的路由策略是：估一估任务难不难，难的扔给强模型。直觉上很合理，但在生产环境里会在两个地方崩掉。
延迟的幻觉也类似。直觉上"大模型慢、小模型快"，但用户实际感知的端到端响应时间，往往被基础设施因素主导：模型跑在什么硬件上、缓存是不是热的、端点有多忙。一个理论上更快的模型，在服务条件不对时照样给出更慢的体验。
更别提路由粒度本身的开销：每个任务路由一次几乎不耗资源；但每一步都路由（为了中途自适应）意味着每个决策点都在叠加延迟与运维复杂度。
Hugging Face 团队的关键转向：不再问"哪个模型最适合这个任务"，而是在成本、质量、延迟三个维度上同时做优化——同时让路由器自身足够轻，不变成新的瓶颈。
在 AppWorld + CodeAct 的实测里，这套优化器绘出了一条成本-精度前沿，而不是给出一个"最优解"。运维方可以按当下更在意什么，在前沿上选不同的 operating point：
作为对照，一个标准的难度路由器（图中青色菱形）落在相近的精度区间，但成本更高——它没法像优化器那样探索完整的 tradeoff 空间。
而这套优化器本身极轻：单任务大约 6 毫秒、2KB 内存，不会成为它自己警告过的那种瓶颈。
本文数据来自 Hugging Face 团队的单方披露，417 个任务、CodeAct Agent、AppWorld 测试集是特定切片，未见第三方独立复测；缓存红利结论高度依赖 Agent 工作负载的上下文复用模式，换到非 Agent 场景或低复用工作流里，成本对比可能反转。读者宜把它当作"路由问题被重新定义"的论据，而非"GPT-4.1 比 Sonnet 贵"的通论。
支线值得记一笔：原文坦承"我们本以为 GPT-4.1 会更便宜，结果不是"——这种反直觉的诚实本身就是工程信号，说明行业对模型成本的常识还停留在 sticker price 层面。
当模型路由从"挑模型"变成"调系统"，决定 AI 产品成本结构的，正在从模型供应商的定价表，转移到自研路由层的工程能力上。
原文发布于 Hugging Face 官方博客，团队预告将在后续文章中公开更多技术细节。如果你正在自研 Agent 系统的路由层，原文末尾开放了读者反馈渠道。
huggingface.co/blog → 搜 "Model Routing"