Cloudflare AI Gateway：别让客户请求记到你的账上

Cloudflare AI Gateway 现在可以在客户未提供模型密钥时，让请求在计入你的 Cloudflare AI 账单前直接失败。2026 年 9 月 14 日，AI Gateway 新增了提供商凭据要求：第三方请求若找不到适用密钥，将返回 HTTP 400，而不再消耗 Unified Billing 额度。

Cloudflare AI Gateway 这次改动，核心是谁来买单

AI Gateway 可以通过多条凭据路径发送同一个模型请求。所谓凭据，就是用来告诉上游模型提供商“该由哪个账户付费”的密钥。

在这次改动之前，处理顺序很简单。Cloudflare 先查找请求中携带的提供商密钥；如果没有，再查找网关中以 default 别名保存的自带密钥，也就是 Bring Your Own Key（BYOK）。两者都不存在时，系统还可以通过 Unified Billing 使用 Cloudflare 托管的凭据，并从你的 Cloudflare 额度中扣除用量。

如果本来就希望由 Cloudflare 付款，最后这层回退很有用。但如果请求属于应当自行提供 OpenAI、Anthropic、Google 或其他提供商密钥的客户，它就会变成预算漏洞。

Cloudflare 现在允许你禁止第三方提供商流量进入第三步。在网关中开启 Require provider credentials（要求提供商凭据），对应 API 中的 byok_only: true；此后，没有适用客户凭据的请求会以 HTTP 400 终止。也可以通过 cf-aig-no-wholesale: true 只对单次请求施加同样的限制。Cloudflare 在这里完整说明了凭据顺序和这两项控制。

最容易理解的方式，是把它看作排队等候的三种付款方：

1. 请求凭据： 客户在这次调用中发送自己的提供商密钥。AI Gateway 会原样转发，因此费用由该密钥对应的账户承担。
2. 网关已存凭据： 调用没有携带提供商密钥，AI Gateway 便使用保存在 Cloudflare Secrets Store 中的提供商密钥。在 Unified Billing 端点上，适用的已存密钥必须使用 default 别名。
3. Cloudflare Unified Billing： 既没有适用的客户密钥，也没有已存密钥时，Cloudflare 可以使用其托管凭据，并从 Cloudflare 账户额度中扣费。

新规则让这条队列在第二步后就结束。这正是它对业务的全部影响：凭据缺失会变成看得见的停机，而不是悄无声息的成本转嫁。

成本问题从事后对账，变成当场拒绝

购买 Unified Billing 额度时会加收 5% 的费用。Cloudflare 自己给出的例子很直观：$100 额度对应 $105 的扣款，而提供商的推理价格本身不加价。

把这套机制放进客户工作流里看：某项客户任务本应使用客户自己的提供商账户，但如果密钥丢失，价值 $100 的模型用量就可能改为消耗运营方的 Cloudflare 额度。补充这部分额度需要支付 $105。客户的提供商账户不会记录任何回退用量，运营方却要独自承担全部 $105 现金支出，还得事后证明是哪位客户造成的。

真正的问题并不是 5% 的费用，而是整笔 $100 工作负载落到了错误的预算上。额外的 $5 只会让这个错误代价更高。

要求提供商凭据，会把一场财务调查变成应用错误。代价是失去自动兜底，换来的则是明确的付款边界。若想更全面地比较网关费用与直接向提供商付费的差异，可参阅这篇 AI 网关成本拆解。

哪些团队应该开启它

为客户运行自动化的服务商

服务商可能统一运营一个 Cloudflare 账户，同时让每位客户使用各自与模型提供商签订的协议。对于由客户付费的路由，应当启用网关规则。这样，无论是接入时漏配密钥，还是轮换密钥时将其移除，任务都会停止，而不会动用服务商预付的余额。

好处是费用归属一目了然：客户要么提供有效凭据，要么收到配置失败提示。服务商不必等任务跑完，再从一张共用的额度账单里倒推费用属于谁。

接受客户自带密钥的 SaaS 团队

允许客户提供密钥的 SaaS 产品，可以把 HTTP 400 视为一种待完成的配置状态。产品可明确提示客户缺少提供商凭据，同时阻止请求进入平台自己的 Cloudflare 额度池。

当一次成功响应反而会掩盖错误时，这项能力尤其重要。没有该限制，功能照常运行，却由错误的公司买单；启用后，产品会足够早地失败，让团队及时修复账户配置。

先从一条路由开始的平台工程师

请求头提供了更小的上线范围。先在一条第三方请求路径中添加 cf-aig-no-wholesale: true，验证缺少密钥时的行为，并把该错误接入监控，再考虑修改整个网关。

优先级只会朝更严格的方向生效：请求头可以让原本宽松的网关收紧限制；但如果网关已经开启 Require provider credentials，请求无法把该请求头设为 false 来降低限制。Cloudflare 将这些限制定义为叠加生效。

将付款方控制与预算控制分开的 FinOps 负责人

用这项设置决定哪个账户可以付款；用 AI Gateway 支出上限决定最多可以花多少。它们是两种不同的控制，测试也应分开进行。

只要 Cloudflare 掌握模型价格，支出上限就能覆盖 BYOK 和 Unified Billing 请求，也可以按模型、提供商或元数据限定范围。但成本只是尽力而为的估算，Cloudflare 也明确要求以提供商控制台为准核对准确账单。因此，应把提供商凭据规则当作付款方边界，再单独验证支出上限。

配置到位，同时避免莫名停机

1. 1

   明确每条路由应由谁付款

   先把第三方提供商流量与 Workers AI 分开。针对每条第三方路由，写清楚提供商密钥应随请求传入，还是应来自网关中保存的 default 密钥。在付款归属尚未明确前，不要启用缺少凭据即拒绝请求的规则。

2. 2

   选择最小的强制范围

   如只限制一条路径，请发送 cf-aig-no-wholesale: true。如要限制整个网关，请依次打开 AI > AI Gateway，选择相应网关，进入 Settings，开启 Require provider credentials 并确认。通过 API 管理的网关，需要在更新请求中使用 byok_only: true。

3. 3

   验证两条有效凭据路径

   先在预发布环境发送一次携带提供商密钥的请求，再发送一次依赖 default 下已存密钥的请求。分别确认预期的提供商账户记录了用量。如果 Unified Billing 端点依赖名为 production 的密钥，应先修正别名，再继续操作。

4. 4

   主动移除密钥进行测试

   在预发布环境中，发送同一个第三方请求，但不带提供商密钥，也不提供适用的 default 已存密钥。预期结果应是 HTTP 400，而不是成功的模型响应。同时确认重试策略不会反复重试这种配置错误。

5. 5

   为错误指定负责人和处理队列

   应由集成负责人或平台负责人处理这个 HTTP 400，因为请求头、已存密钥和密钥轮换都由他们控制。客服可以解释故障，财务可以审计费用，但这两个团队都不应负责修复。

必须正视的取舍

这项设置用可见的失败取代无声的回退。如果 Unified Billing 原本就是团队有意设置的可用性兜底，那么开启后，第三方提供商请求将失去这层保障。已经过期或无效的请求密钥也会被转发给提供商，而不是被另一条计费路径替换，因此上游提供商仍可能拒绝请求。

Workers AI 是一个重要例外。Workers AI 请求不使用第三方提供商凭据，因此仍会放行，并继续采用网关中单独配置的 Workers AI 计费模式。启用 byok_only 并不等于全局开启“任何费用都不能记到 Cloudflare”的开关。

支出上限也无法堵住所有缺口。其统计采用最终一致性，因此并发请求可能让支出短暂超过上限；成本同样是根据 token 数量和已知模型价格估算出来的。支出上限值得使用，但准确费用仍需对照提供商和 Cloudflare 的计费界面核算。

本周一先做这件事

选一条由客户付费的第三方路由，先添加请求级限制，再在预发布环境执行缺少凭据的测试。通过标准是：得到责任归属明确的 HTTP 400，且没有成功回退。把这项错误交给集成团队或平台团队的处理队列，点名由谁修复密钥，然后再考虑为整个网关开启规则。

如果团队有意让所有第三方流量都使用 Cloudflare Unified Billing，就不要开启该规则。如果只使用 Workers AI，这项设置不会改变其账单。如果本应由客户或部门的提供商账户付款，就应在本周采取行动，主动测试失败路径，不要等下一次密钥轮换替你测试。

如果希望继续获取这类面向实际运营的更新解读，欢迎订阅邮件通讯。