模型路由不是分类题：成本、延迟与系统的权衡

在多模型并行的 AI Agent 系统中，将简单请求交给便宜模型、复杂任务分配给更强模型，看似是理所当然的优化策略。然而真正在生产环境里落地路由机制时，工程师们很快会发现：模型选型并不只是分类问题，而是一个复杂的系统优化问题。本文结合 AppWorld Test Challenge 的实测数据，剖析路由设计中三个容易被忽视的维度。

成本不止于模型定价

直觉上 GPT-4.1 应该比 Claude Sonnet 4.6 更便宜，但实测结果恰好相反。在 AppWorld Test Challenge 的 417 个任务上，使用同一个 CodeAct Agent，Sonnet 总成本仅 79 美元（每任务 0.19 美元），而 GPT-4.1 高达 155 美元（每任务 0.37 美元），几乎是前者的两倍。

从公开标价看，GPT-4.1 的输入与输出 token 单价都更低，且 Sonnet 完成同等任务所需的推理步数大约是 GPT-4.1 的三倍。按标价计算，GPT-4.1 应该完胜才对。

关键差异来自缓存：Agent 工作流往往在多个步骤间复用大段上下文，缓存命中率较高时实际输入成本会大幅下降。Sonnet 的缓存读取价格更低，在这种工作模式下获益明显，足以抵消其较高的基础价格和更长的推理轨迹。这意味着，只看定价表的路由器，实际上是在用错误的数字做优化。

复杂度不止于任务难度

按任务难度分配模型是另一种常见策略，但它在两方面都会失效：

• 难度在路由时往往不可见。一句"总结这份合同"看起来简单，背后可能需要检索、合规检查、工具调用和多轮迭代；而一段高度技术化的 prompt，反而可能被一个专用小模型高效处理。真正的难度，常常要等到执行阶段才暴露出来。
• 即使能完美估算难度，它也只是众多信号之一。生产环境中的路由器必须同时平衡成本、延迟、模型特化程度与可靠性；企业级部署还会叠加合规要求、数据驻留规则、隐私约束与白名单等限制。一道本该送往某模型的任务，可能因为治理规则必须改投他处，路由器需要优雅地处理这些情况。

换言之，路由器并不是在解一道题，而是在同时权衡成本、质量、延迟、合规与可靠性。

延迟不止于模型速度

用户感知的端到端响应时间，并不仅仅取决于模型大小：

• 路由本身会引入开销，硬件配置、缓存是否预热、端点负载等基础设施因素往往主导最终响应。理论上更快的模型，如果服务条件不佳，实际体验可能反而更慢。
• 路由粒度也至关重要：每个任务路由一次几乎无额外开销；但如果每一步都路由以获得更灵活的中途调整能力，每个额外决策点都会引入延迟与运维复杂度。

只看模型速度而忽略服务系统的路由器，优化的是错误的现实。

把路由当作优化问题

基于以上教训，团队不再把路由当作分类问题，而是当作优化问题：算法在成本、质量与延迟之间同时寻优，同时保持足够轻量以避免自身成为瓶颈。

在 AppWorld Test Challenge 上的测试中，路由器勾勒出一条成本-精度曲线，每个蓝色方块代表一组配置。延迟优先的配置（Configuration 1）达到 84% 精度，成本 93 美元、平均响应 83 秒，相比单独运行 Opus 节省 21% 成本与 9% 延迟，精度仅下降 4%。而标准的难度基线路由器（青色菱形）在相近精度下成本更高，因为它没有像优化方法那样探索完整的权衡空间。由于优化本身很轻量（每任务约 6 毫秒、2 KB 内存），路由器并未成为新的瓶颈。

结语

模型路由的真正难点，不在于"选对模型"，而在于为整个系统找到最佳运行点。模型只是变量之一，与缓存行为、基础设施状态、合规约束和工作负载模式同等重要。当路由做得好时，往往不是因为找到了任务的"最佳"模型，而是因为找到了系统的最佳操作点。这是一道比分类更难的题，但也是值得去解的题。后续我们将分享更多技术细节。