Cloudflare 发布 AI Gateway 自动路由功能 Auto Router

在与处于 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 支出限制，以及如何查看通过将员工与其 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、文件、差旅和财务等常见的日常工作流。每项任务都要求模型使用这些工具来生成可验证的答案或完成操作。

^{97 个任务，每个模型每个任务三个样本。括号内的数值显示了从 10,000 次任务级自助重采样中估计出的 95% 置信区间，并保留了每个任务内的所有三次重复。 “pp”代表百分点。}

我们的 Auto Router 提供了与其他最先进的日常主力模型相当的性能，成本仅为 Sol 的 80% 和 Opus 的 35%。虽然这起初看起来令人惊讶，但理解模型路由所解决问题的一种方式是通过模型间的“锯齿状前沿”（jagged frontier）。解决问题的能力通常存在于这个模型组合中的某处；路由器的任务是为每个任务选择合适的模型，同时平衡质量和价格。节省的费用来自于无需为非前沿工作支付前沿价格，并且随着此类工作量的增加，节省的费用也会增加。

另一个见解是，较低的 Token 价格并不总是能带来较低的成本结果。一个在纸面上看起来更便宜的模型，最终可能会为了解决问题而使用不成比例的更多 Token。路由器应该最小化预测的轨迹成本，而不是仅仅通过每百万 Token 的美元价格进行负载均衡。

这在今天已经很有用，但这仅仅是 Auto Router 可以从 Cloudflare 在推理路径中所处位置学到的东西的开始。

工作原理

当你向 cloudflare/auto 发送请求时，AI Gateway 首先构建一个可以实际处理该请求的 模型池。它会过滤掉不支持该请求格式或执行模式的模型，并考虑与网关关联的凭据、计费配置、访问控制策略和支出限额。它还会在停机期间过滤掉不健康的后端提供商或模型，并在中断结束后自动将它们重新加入池中。

对于剩余的候选模型，路由器会查看对话的精简视图。它会考虑最近的消息，优先处理最新的轮次。随后，对话会被发送到一个在 Workers AI 上运行并部署在我们边缘网络 GPU 上的多头分类模型。该分类器会产生两组信号。首先，它会分配 14 个任务类别（如编码、规划、研究、数据分析）的概率。然后，它会从复杂性、模糊性、风险和对早期上下文的依赖程度四个维度对请求进行一到五分的评分。

一个单独的评分矩阵会将这些信号与模型基准测试结果相结合，以评估每个模型对请求的适配程度。为了校准评分矩阵，我们为一组示例任务和难度配置文件定义了首选模型，然后调整权重以得出这些选择。

最后，路由器将预期质量与每个模型的输入和输出 Token 价格相结合。在简单的请求中，价格权重更高，因此较小的模型在能力足够时可以胜出。随着难度的增加，成本惩罚会降低，更强大的模型会有更多的胜出空间。简而言之，cloudflare/auto 会选择效用最高的模型，其定义如下：

utility = expected quality - adaptive cost penalty

对于调试或编码等长时间的智能体（agentic）会话，成本主要不是由模型的标价驱动的，而是由随会话长度增加的缓存读取成本驱动的。切换模型会丢弃缓存，并迫使新模型重新写入整个上下文。这可能是值得的，因为缓存读取和缓存写入价格更低的模型可以迅速抵消重写成本。

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 的努力。