统一 Workers AI 与 AI Gateway 为单一 AI 控制平面

AI Gateway 和 Workers AI 最初是作为两个独立的产品推出的，但随着时间的推移，我们注意到用户的使用方式正在趋同。通过 AI Gateway，你可以代理请求到任何模型提供商，并获得内置的可观测性、日志记录、访问控制和安全性。在 Workers AI 上，我们将模型托管在我们管理的 GPU 基础设施上，并提供一个 API 端点，供你以服务形式调用推理能力。这些产品的架构看起来不同，但对最终用户而言，它们实现的是同一个目标：通过一个复杂的控制平面将你连接到模型。今天，我们很高兴分享这些产品如何融合为一条统一路径的计划，让你能够连接到任何模型提供商（包括 Workers AI），同时从单一控制平面管理可观测性、计费、安全性和日志记录。这是我们迈向一些宏大计划的下一步——继续阅读，了解统一控制平面对于模型路由的未来意味着什么。

合并绑定和 API

我们一直在通过入口点（即 Workers binding 和 REST API）暗示这些产品正变得更加统一。我们有一个 AI binding，你可以用它来调用 AI Gateway 和 Workers AI。这里没有单独的 AI Gateway 和 Workers AI binding 的概念：一切都通过同一条路径。几个月前，我们推出了“默认”网关的概念，这样即使你从未设置过 AI Gateway，也能自动继承 AI Gateway 的可观测性和日志记录。当然，如果你希望将应用程序拆分为多个项目，你仍然可以指定自己的网关。以下是通过 AI Gateway 调用 Workers AI 时 binding 调用的样子：

我们还宣布了一个统一的 REST API——/ai/ 端点，允许你通过 AI Gateway 对 Workers AI 进行类似的调用。这样做使我们能够统一 AI Gateway 和 Workers AI 的入口点，因此你无需在首先使用哪个产品之间做出选择：一切都开箱即用。

为所有 Workers AI 用户提供自动可观测性和控制

这种融合最直接的好处之一是，你不再需要显式创建 AI Gateway 才能开始获得推理流量的可见性。如果你从未设置过网关，只需在 binding 或 REST API 调用中将 default 作为网关 ID 传入，AI Gateway 会在第一次经过身份验证的请求时自动创建它。这样，每个请求都会记录完整的请求和响应负载，每个模型的 token 计数都会被跟踪，并且无需任何仪表板设置即可获得成本归属。如果之后默认网关不再满足你的需求——例如你想要自定义缓存规则或按应用程序拆分流量——你可以创建一个命名网关，并通过更改一个参数将请求指向它。以下是它在 binding 中的样子。

之前，你直接调用 Workers AI：

现在，添加第三个参数以通过 AI Gateway 路由并获得完整的可观测性：

前往 Cloudflare AI Gateway 仪表板，你会看到每个请求：延迟分解、token 使用量、错误率以及确切的 prompt 和响应。对于调试模型行为或审计 AI 输出的团队来说，这相比盲目操作是一次巨大的升级。

新增：将 AI Gateway 积分用于 Workers AI

我们今天推出的一个新功能是能够将 AI Gateway 积分用于 Workers AI。之前，你只能在外部模型提供商（例如 OpenAI、Anthropic）上使用 AI Gateway 积分，但还不能将 AI Gateway 积分应用于 Workers AI 的使用。我们终于启用了系统，允许对 Workers AI 进行统一计费。这意味着你可以加载一个充满积分的钱包，然后选择在 OpenAI、Anthropic、Workers AI 或我们支持的任何提供商之间消费这些积分。由于我们现在为 Workers AI 提供预付费计费，并希望鼓励用户使用这条新路径，如果你使用 AI Gateway 统一计费，我们还将在 Workers AI 模型上提供更高的速率限制。请参阅开发者文档以获取有关速率限制以及如何请求更高速率限制的最新信息。

即将推出：模型优先路由

当所有推理流量都流经一个统一控制平面时，我们可以开始对如何服务每个请求做出更智能的决策，从你想要的模型开始，而不是从你必须管理的提供商开始。提供商优先路由迫使你考虑基础设施：“我调用哪个提供商？如果他们宕机了怎么办？”模型优先路由则颠覆了这一点。你考虑的是你的需求——一个强大的推理模型、一个快速的摘要器、一个廉价的 embedding 模型——而控制平面负责提供商选择、故障转移和负载均衡。今天，如果你想调用一个模型，你必须知道哪个提供商托管它。如果该提供商宕机或对你进行速率限制，你的应用程序就会中断。我们正在朝着一个你指定模型、AI Gateway 处理其余事务的世界迈进。这样，你可以请求 Kimi K2.7 Code，而不必关心它来自 Workers AI、Moonshot 自己的 API 还是托管相同权重的其他提供商。如果 Workers AI 有容量，你将受益于我们托管的基础设施。如果 Workers AI 容量已满，网关会透明地将你负载均衡到另一个可以提供相同模型的提供商。如果你愿意，你仍然可以选择坚持使用单一提供商，但如果你关心弹性，模型优先路由能为你提供更多灵活性。我们与经过审查的提供商合作，因此模型输出的质量仍然是首要任务，并且我们还将能够满足诸如零数据保留（ZDR）之类的要求。这也意味着默认情况下具有更好的弹性。如果某个提供商的模型版本出现问题，流量会转移到另一个提供商，而无需在 Workers 中进行应用程序级别的重试或复杂的回退逻辑。网关将模型可用性视为一个路由问题。我们希望在接下来的几个月内为所有 AI Gateway 和 Workers AI 用户试点这一功能。

下一步：智能路由

路由的下一个演进超越了简单的故障转移。我们正在构建智能路由，它能够理解你在问什么，并在无需任何配置的情况下为任务选择正确的模型。你可以不指定模型，而是让网关来决定。在底层，一个运行在 Workers AI 上的分类器会读取你的 prompt，并预测它是什么类型的任务（编码、研究、摘要、通用问答）、它的复杂程度以及上下文的重要性。然后，一个启发式评分器会将其映射到精选池中的最佳模型。对于想要控制的团队，你仍然可以指定确切的模型。对于其他所有人来说，零配置路径意味着你可以在不维护自己的路由逻辑的情况下获得更好的经济性和性能。我们目前正在内部试点这一功能，并将在未来几周内积极测试和迭代，然后发布。

立即开始

如果你已经在使用 Workers AI，尝试这一功能的最简单方法是开始将你现有的调用路由到默认网关。你将立即获得请求日志记录、token 跟踪和成本归属，而无需更改调用模型的任何其他方式。如果你已经在使用 AI Gateway，将 Workers AI 加入其中就像调用一个 Workers AI 模型一样简单。加载你的 AI Gateway 钱包，你将获得我们支持的每个提供商的统一计费，以及 Workers AI 模型上的更高速率限制。设置你的第一个网关，浏览 Workers AI 模型目录，并立即开始构建。