Cloudflare统一Workers AI与AI Gateway
Cloudflare AI··作者 Ming Lu
关键信息
Cloudflare 表示，请求可以使用内置的“default”网关；如果此前没有创建过网关，它会在首次通过身份验证的请求时自动创建。系统会记录完整的请求和响应载荷，按模型跟踪 token 数，并且无需先配置仪表板即可进行成本归因。
资讯摘要
Cloudflare 正在把两个原本独立的产品——Workers AI 和 AI Gateway——合并为一个统一的 AI 控制平面。Workers AI 负责在 Cloudflare 管理的 GPU 基础设施上托管模型，并通过推理 API 对外提供服务；而 AI Gateway 则用于代理到各类模型提供方，同时提供可观测性、日志、访问控制和安全能力。Cloudflare 表示，这两个产品之所以会走向融合，是因为从最终用户的角度看，它们解决的是同一个问题：如何带着控制和可视化能力把应用接到模型上。公司的目标是让用户通过一条统一路径连接到任何模型提供方，包括 Workers AI 本身。
现在，这条路径同时覆盖 Workers 绑定和统一的 REST API。Cloudflare 还引入了内置的“default”网关，因此新用户在没有手动创建网关的情况下，也能自动获得 AI Gateway 的可观测性和日志能力。随后如果用户需要更复杂的配置，比如自定义缓存规则，或按应用拆分流量，也可以创建命名网关，只需改一个参数即可切换。Cloudflare 说明，这次统一是其更大规模模型路由计划中的下一步。
资讯正文
AI Gateway 和 Workers AI 最初是两个独立的产品，但随着时间推移，我们注意到用户的使用方式正在趋同。借助 AI Gateway，你可以将请求代理到任何模型提供商，并获得内置的可观测性、日志记录、访问控制和安全能力。在 Workers AI 上，我们把模型托管在由我们管理的 GPU 基础设施上，提供一个你可以利用的 API 端点，以访问推理即服务。
这两种产品的架构看起来不同，但对最终用户来说，它们实现的是同一个目标：通过一个复杂的控制平面把你连接到模型。今天，我们很高兴分享我们计划如何让这些产品收敛为一条统一路径，这样你就可以连接到任何模型提供商（包括 Workers AI），同时从单一控制平面管理可观测性、计费、安全和日志记录等内容。
这也是我们迈向一系列重大计划的下一步——继续阅读，了解统一控制平面对模型路由未来意味着什么。
合并绑定和 API
我们一直在通过入口点暗示这些产品正在变得更加统一：Workers 绑定和 REST API。我们有一个 AI binding，你可以用它来调用 AI Gateway 和 Workers AI。这里没有单独的 AI Gateway binding 和 Workers AI binding 之分：它们都走同一条路径。几个月前，我们推出了“默认”网关的概念，这样即使你从未设置过 AI Gateway，也可以自动继承 AI Gateway 的可观测性和日志记录。当然，如果你愿意把应用拆分到多个项目中，你仍然可以指定自己的网关。
如果你通过 AI Gateway 调用 Workers AI，绑定调用是这样的：
export default {
async fetch(request, env) {
const response = await env.AI.run(
'@cf/zai-org/glm-5.2',
{
messages: [
{ role: 'user', content: 'What is the capital of France?' },
},
gateway: {
id: 'default', // Use 'default' for the built-in gateway
}
);
return new Response(JSON.stringify(response), {
headers: { 'Content-Type': 'application/json' },
});
};我们还宣布推出一个统一的 REST API——/ai/ 端点，它允许你通过 AI Gateway 对 Workers AI 执行类似的调用。
curl "https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/run/@cf/zai-org/glm-5.2" \
-H "Authorization: Bearer {api_token}" \
-H "Content-Type: application/json" \
-H "cf-aig-gateway-id: default" \
-d '{
"messages": [{"role": "user", "content": "What is the capital of France?"}],
}'
这样做使我们能够统一 AI Gateway 和 Workers AI 的入口点，因此你不需要先在使用哪个产品之间做选择：它们都是开箱即用的。
为所有 Workers AI 用户自动提供可观测性和控制
这种收敛带来的最直接好处之一是，在你开始查看推理流量之前，不再需要显式创建 AI Gateway。如果你以前从未设置过网关，只要在绑定或 REST API 调用中将 default 作为网关 ID 传入，AI Gateway 就会在第一次经过身份验证的请求时自动创建它。
有了这个之后，每个请求都会被记录下来，完整的请求和响应载荷都会保留，token 数量会按模型跟踪，而且你无需做任何仪表盘配置就能获得成本归因。如果以后默认网关不再够用——比如你想要自定义缓存规则，或者按应用拆分流量——你可以创建一个命名网关，只需改一个参数就能把请求指向它。
下面是绑定里的样子。以前，你会直接调用 Workers AI：
const response = await env.AI.run('@cf/zai-org/glm-5.2', {
messages: [{ role: 'user', content: 'Hello!' }],
});现在，只要添加第三个参数，就可以通过 AI Gateway 路由，并获得完整的可观测性：
{ messages: [{ role: 'user', content: 'Hello!' }] },
{ gateway: { id: 'default' } } // 首次使用时自动创建该网关
);前往 Cloudflare AI Gateway 仪表盘，你就能看到每一次请求：延迟分解、token 使用量、错误率，以及精确的提示词和响应。对于需要调试模型行为或审计 AI 输出的团队来说，这比“盲飞”有了巨大提升。
新功能：将 AI Gateway 额度用于 Workers AI
我们今天发布的另一项新功能，是可以将 AI Gateway 额度用于 Workers AI。以前，AI Gateway 额度只能用于外部模型提供商（例如 OpenAI、Anthropic），但你还不能把 AI Gateway 额度用于 Workers AI。我们终于让系统支持了 Workers AI 的统一计费。这意味着你可以充值一个装满额度的钱包，然后把这笔额度花在 OpenAI、Anthropic、Workers AI，或者我们支持的任何提供商上。
由于我们现在为 Workers AI 提供预付费计费，并希望鼓励用户采用这条新路径，如果你使用 AI Gateway 的统一计费，我们也会为 Workers AI 模型提供更高的速率限制。关于速率限制以及如何申请更高速率限制的最新信息，请参阅开发者文档。
即将推出：以模型为中心的路由
随着所有推理流量都通过一个统一控制平面流转，我们可以开始更智能地决定如何处理每个请求——从你想要的模型开始，而不是从你必须管理的提供商开始。以提供商为中心的路由会迫使你考虑基础设施：“我该调用哪个提供商？如果他们宕机了怎么办？”而以模型为中心的路由则反过来。你考虑的是你需要什么——一个能力强大的推理模型、一个快速的摘要模型、一个便宜的嵌入模型——然后由控制平面来处理提供商选择、故障转移和负载均衡。
今天，如果你想调用一个模型，就必须知道它由哪个提供商托管。如果那个提供商宕机了，或者对你做速率限制，你的应用就会出问题。我们正在迈向这样一个世界：你只需指定模型，剩下的交给 AI Gateway 处理。
这样一来，你就可以请求 Kimi K2.7 Code，而不必在意它究竟来自 Workers AI、Moonshot 自家的 API，还是另一家托管相同权重的提供商。如果 Workers AI 有容量，你就能享受到我们托管基础设施带来的优势；如果 Workers AI 已满载，网关会透明地将流量负载均衡到另一家能够提供同一模型的提供商。你仍然可以选择只使用单一提供商，如果你愿意的话，但以模型为先的路由意味着，如果你更看重弹性，就能获得更大的灵活性。我们只与经过审核的提供商合作，因此模型输出质量仍然是首要任务，同时也能够满足 Zero Data Retention（ZDR）等要求。
curl -X POST "https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/v1/chat/completions" \
-H "cf-aig-gateway-id: my-gateway" \
"model": "kimi-k2.7-code",
"messages": [{"role": "user", "content": "Review this function"}]
}'这也意味着默认就拥有更好的弹性。如果某个提供商的某个模型版本出现问题，流量会自动切换到另一家提供商，而无需在应用层进行重试，或在 Workers 中编写复杂的回退逻辑。网关将模型可用性视为一个路由问题。我们希望在未来几个月内，为所有 AI Gateway 和 Workers AI 用户试点这一功能。
下一步：智能路由
路由演进的下一阶段将超越简单的故障转移。我们正在构建一种智能路由，它能够理解你在请求什么，并在无需任何配置的情况下，为任务选择合适的模型。
你无需指定模型，而是可以让网关自行决定。在底层，一个运行在 Workers AI 上的分类器会读取你的提示词，并预测这是哪一类任务（编码、研究、摘要、通用问答）、任务有多复杂，以及上下文有多重要。随后，一个启发式评分器会将这些信息映射到从精选模型池中挑出的最佳模型。对于希望掌控一切的团队，你仍然可以指定精确的模型；而对于其他所有人来说，零配置路径意味着你无需维护自己的路由逻辑，就能获得更好的成本效益和性能。我们目前正在内部试点这一方案，并将在发布前的未来几周内积极测试和迭代。
今天就开始使用
如果你已经在使用 Workers AI，最简单的试用方式就是先把现有调用路由到默认网关。这样你无需更改调用模型的任何其他方式，就能立即获得请求日志、token 跟踪和成本归因。
如果你已经在使用 AI Gateway，只需调用一个 Workers AI 模型，就能轻松把 Workers AI 加入其中。为你的 AI Gateway 钱包充值后，你将获得覆盖我们支持的每一家提供商的统一计费，以及 Workers AI 模型更高的速率限制。
设置你的第一个网关，浏览 Workers AI 模型目录，今天就开始构建。
来源与参考
收录于 2026-08-08