借助 AI Gateway 的 Auto Router 削减你的 AI 支出
从我们与处于 AI 采用旅程各个阶段的公司的交流中，我们看到了一些共同的模式。首先是一段探索期：你引入每一个新工具，随意分发 API 密钥，让 token 自由流动。随后，你会收敛到组织内的标准工具上——用于智能体编程、用于非技术工作流、用于运行和部署智能体。当公司把 AI 采用正式化之后，他们希望管理和监督用户的 token 支出，但预算和规则的作用终究有限。最好的节省，是用户根本察觉不到的节省。
今天，我们发布 Cloudflare 的 Auto Router 公测版，可通过 AI Gateway 使用。将你的模型设置为 cloudflare/auto
Auto Router 就会自动把每个请求路由到一个对该任务而言能力足够强的模型，而无需最终用户去考虑模型选择。我们通过 OpenCode 工具链在内部使用 Auto Router 的早期结果显示，与仅使用 OpenAI Sol 和 Anthropic Claude Opus 等前沿模型相比，成本节省最高可达 30%。
我们为什么构建它
根据我们在 Cloudflare 跟踪 AI 支出的自身经验，我们了解到管理成本需要多管齐下的方法。此前，我们讨论过如何设置预算以及围绕 AI 支出的限制，还有
__如何查看__在许多工具链中，包括 OpenCode、Claude Code 和 Codex，单个用户仍然手动选择模型。当然，并非所有任务都是平等的，个人往往会使用对其工作而言过于强大的模型。例如，如果你只是想总结一封电子邮件或聊天记录，你并不需要 Opus 级别的智能。然而，你也不会想完全阻止你的安全工程团队使用该模型。
我们的目标是让 AI Gateway 成为组织在内部部署 AI 的控制平面。因为来自每个用户、智能体和工具的每个请求都已经流经它，AI Gateway 处于一个独特的位置，可以做的不仅仅是观察和强制执行。预算、支出限制和身份感知分析为组织提供了可见性和护栏，但它们仍然依赖个人在每个请求上做出有成本意识的决策。下一步是让网关本身代表用户做出智能决策：将每个请求发送到一个对该任务而言能力足够强的模型。这样，组织就能自动减少支出，同时用户在实际工作需要时仍能访问最强大的模型。
结果
我们在 Cloudflare 内部，在我们的 OpenCode 部署以及Cloudflare OS（我们自研的智能体工具链）中使用 Auto Router。在我们的内部使用中，我们看到的结果在编码任务上与前沿模型相当。
Auto Router 在广泛的知识工作任务中表现最佳，比如大型组织中常见的那种横跨技术和非技术团队的工作。我们评估了 cloudflare/auto
与 OpenAI 的 GPT-6 Sol 和 Anthropic 的 Claude Opus 5.5 在我们的内部通用知识工作基准上进行了对比。该基准使用模拟的工作区工具，涵盖电子邮件、日历、Slack、文件、旅行和财务等常见的日常工作流程。每项任务都要求模型使用这些工具来生成可验证的答案或完成一项操作。
模型 | 成功试验次数 | 成功率 | 总成本 | 每次成功成本 |
cloudflare/auto | 252/291 | 86.6% (+6.2/−6.9 pp) | $2.10 | $0.0084 |
Anthropic Claude Opus 5.5 | 281/291 | 96.6% (+2.7/−3.8 pp) | $5.91 | $0.0210 |
OpenAI GPT-6 Sol | 245/291 | 84.2% (+6.5/−6.9 pp) | $2.64 | $0.0108 |
97 项任务，每个模型每项任务三个样本。括号中的值表示 95% 置信区间，通过 10,000 次任务级 bootstrap 重采样估计，保留每项任务内的所有三次重复。“pp”表示百分点。
我们的 Auto Router 实现了与其他最先进的日常驱动模型相似的性能，成本仅为 Sol 的 80% 和 Opus 的 35%。虽然这最初可能看起来令人惊讶，但理解模型路由器所解决问题的一种方式是通过模型间的“锯齿状前沿”。解决问题的能力通常存在于这个模型组合中的某个地方；路由器的工作是为每项任务选择正确的模型，同时平衡质量和价格。节省来自于不为非前沿工作支付前沿费率，并且节省会随着你拥有多少此类工作而增长。
另一个见解是，较低的 token 价格并不总是产生较低成本的结果。一个在纸面上看起来更便宜的模型最终可能会使用不成比例更多的 token 来解决问题。路由器应该最小化预测的轨迹成本，而不仅仅是按每百万 token 的美元进行负载均衡。
这在今天已经很有用，但这只是 Auto Router 可以从 Cloudflare 在推理路径中的位置学到的东西的开始。
工作原理
当你向 cloudflare/auto 发送请求时
，AI Gateway 首先构建实际可以为其提供服务的模型池。它会过滤掉不支持请求格式或执行模式的模型，并考虑附加到网关的凭证、计费配置、访问控制策略和支出限制。它还会在停机期间过滤掉不健康的上游提供商或模型，并在中断后自动将它们重新纳入池中。
对于剩余的候选模型，路由器会查看对话的紧凑视图。它考虑最近的消息，优先考虑最新的轮次。然后，对话被发送到运行在 Workers AI 上并部署在我们边缘网络 GPU 上的多头分类模型。分类器产生两组信号。首先，它在 14 个任务类别（如编码、规划、研究、数据分析）上分配概率。然后，它从一到五的范围内对请求的四个维度进行评分：复杂性、模糊性、利害关系和早期上下文的依赖性。
一个单独的评分矩阵将这些信号与模型基准结果相结合，以估计每个模型对请求的适合程度。为了校准评分矩阵，我们为一组示例任务和难度配置文件定义了首选模型，然后调整权重以产生这些选择。
最后，路由器将预期质量与每个模型的输入和输出 token 价格相结合。对于简单的请求，价格权重更大，因此较小的模型只要能力足够就能胜出。随着难度上升，成本惩罚下降，更强的模型有更多胜出空间。简而言之，cloudflare/auto
选择效用最高的模型，其定义为：
utility = expected quality - adaptive cost penalty
对于调试或编码等长时间智能体会话，成本更多由缓存读取成本驱动，而非模型的标价，且缓存读取成本随会话长度增长。切换模型会丢弃缓存，迫使新模型重新写入整个上下文。这可能值得，因为缓存读取和缓存写入价格更低的模型可以快速收回重写成本。
Auto Router 并非完全避免模型切换，而是会考虑缓存读取和写入的成本。在一个回合内（一次用户输入循环），缓存是热的，切换很少划算，因此最好继续使用同一模型。跨回合时，Auto Router 会施加一个切换惩罚，该惩罚随上下文中已有的 token 数量增长。对于仍持有会话活跃缓存的模型，按其更便宜的缓存读取费率计价。其他所有候选模型则按重写上下文的全部成本计价，因此对话越深入，切换就必须通过更高质量的结果（整体使用更少 token 或更便宜的缓存重读）来收回更多成本。切换模型还有另一个成本：大多数模型无法读取另一个模型的推理 token，因此丢弃推理 token 的模型切换意味着新模型可能不得不以输出价格重做推理。未来，我们希望通过让路由器在切换时优先留在同一模型家族中来考虑这一点。
在此基础上，路由器返回一个排名列表。AI Gateway 首先尝试胜出者，如果该提供商无法服务请求，则可以转向另一个符合条件的模型。
这种整体设计有几个好处。两阶段架构（任务和维度分类器到评分矩阵）意味着路由决策是可解释的，因为你可以检查每个任务的预测类别和复杂度，了解它们如何转化为模型选择。当新模型发布时调整路由器也不需要重新训练——我们只需将其基于基准的权重添加到评分矩阵中。同一个分类器还可以支持不同的路由配置。例如，除了 cloudflare/auto
，我们计划未来发布其他路由器，包括 cloudflare/auto-best
，它使用相同的分类和模型池，但选择预期质量最高的模型，而不应用成本权衡。
下一步
我们今天的发布只是一个起点，我们将继续投资于研究和新的路由策略。短期内，我们希望：
- 扩展通过 cloudflare/auto 提供的模型
- 在筛选模型时纳入零数据保留要求
- 在选择模型时考虑提供商容量
- 为每个请求选择合适的推理或思考级别
- 添加对 Responses API 和 WebSockets 的全面支持
- 探索结构化决策模型作为第一遍分类器
Auto Router 在测试期间免费。更多信息请阅读我们的开发者文档。
致谢：本项目同样得益于 Mats Dodd、Sam Scott、Oliver Yu 和 Jeff Rafter 的努力。