将 Workers AI 和 AI Gateway 统一为一个 AI 控制平面
AI Gateway 和 Workers AI 最初是两个独立的产品，但随着时间的推移，我们注意到用户的使用方式正在靠拢。通过 AI Gateway，你可以把请求代理到任何模型提供商，并获得内置的可观测性、日志、访问和安全管理能力。Workers AI 则把模型托管在我们管理的 GPU 基础设施上，以推理即服务（inference-as-a-service）的形式对外提供 API 端点。这两个产品架构不同，但对最终用户而言，它们要达到的目标是一致的：借助一个成熟的控制平面，把使用者连接到模型。
今天，我们很高兴地公布这两个产品汇聚成一条统一路径的计划——你既能连接包括 Workers AI 在内的任何模型提供商，又能从同一个控制平面统一管理可观测性、计费、安全和日志。这是我们正在筹备的宏大计划的下一步——继续往下读，看看统一的控制平面会给未来的模型路由带来什么变化。
合并绑定与 API
其实，通过产品入口的变化，我们已经暗示过这两个产品正一步步走向统一——这些入口就是 Workers binding 和 REST API。现在你有一个 AI binding，既可以用它调用 AI Gateway，也可以调用 Workers AI。绑定层面不再区分什么功能属于 AI Gateway、什么属于 Workers AI：所有请求都走同一条路径。
几个月前，我们上线了「默认」网关的概念。即使你从未配置过 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 调用里把网关 ID 设为 default，AI Gateway 会在第一个通过认证的请求到达时自动帮你创建好。
这样一来，每个请求都会被完整记录下来，包括请求和响应的全部内容；每个模型的 Token 用量都会单独统计；而且不用配置任何控制台面板，就能看到费用归属。如果以后默认网关不够用了——比如想自定义缓存规则，或者按应用拆分流量——你可以创建一个命名网关，然后只需改动一个参数，就能把请求指向它。
在绑定中的写法如下。之前，你直接调用 Workers AI：
现在，加上第三个参数，让请求经过 AI Gateway，就能获得完整的可观测性：
打开 Cloudflare AI Gateway 控制台，你可以看到每一个请求：延迟明细、Token 用量、错误率，以及具体的提示词和响应。对于需要调试模型行为或审计 AI 输出的团队来说，这比之前完全看不到数据的"盲飞"状态是一次巨大的升级。
新功能：Workers AI 可以使用 AI Gateway 积分
今天我们还发布了一项新能力：Workers AI 可以消耗 AI Gateway 的积分。以前，AI Gateway 积分只能用于外部模型提供商（例如 OpenAI、Anthropic），还不能用在 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 容量满了，网关就会把流量无缝负载均衡到另一家能提供同一模型的服务商。
当然，如果你愿意，仍然可以只绑定一家服务商。但如果你看重服务韧性，模型优先路由能给你更大的灵活性。我们合作的服务商都经过严格审核，模型输出质量始终是第一优先级，同时也能满足零数据保留（Zero Data Retention，ZDR）这类合规要求。
这还意味着默认情况下韧性更好。某家服务商的模型版本出了问题，流量会自动切换到另一家，你的 Workers 里完全不用写应用层重试或复杂的回退逻辑。在网关眼里，模型可用性就是一个路由问题。我们希望在接下来几个月里，面向所有 AI Gateway 和 Workers AI 用户启动试点。
下一步：智能路由
路由的下一个演进方向，不只是简单的故障转移。我们正在构建的智能路由，能够理解你的请求意图，并自动挑选合适的模型来完成任务，全程无需任何配置。你甚至不用指定模型，把决定权交给网关就好。