- 为什么需要 AI Gateway 这样的层
- Cloudflare AI Gateway 实际提供了什么
- 目前最实用的入门方式
- 什么时候该用 Dynamic Routing
- 自动 retries 能相信到什么程度
- 实务中最重要的使用场景
- 常见的错误
- 引入检查清单
- 结语
- 参考资料
为什么需要 AI Gateway 这样的层
AI 应用刚开始看起来很简单，但一旦进入实际运营，很快就会出现共同的问题。需要看清是谁调用了多少次，需要追踪成本在哪里增加，还需要保证模型失败时服务不会中断。如果团队只维持直接调用模型的结构，这些问题就得在每一份应用代码里分别解决。
Cloudflare AI Gateway 把这一点梳理了出来。Cloudflare 说明，团队可以通过 AI Gateway 对 AI 应用进行 observe and control，只要接入，就能立刻使用 analytics、logging、caching、rate limiting、request retries、model fallback 等功能。文档中也强调，起步几乎接近 一行代码级别的集成。
从实务角度看，这一点相当重要。因为应用代码可以专注于业务逻辑，而观测与控制可以在网关层统一处理。
Cloudflare AI Gateway 实际提供了什么
接入 AI Gateway 之后，最先看到的价值是可观测性。通过查看请求数、token 数、成本等指标，可以掌握是哪些功能在产生流量，也可以通过日志追踪失败的原因与模式。
接下来是控制。
- 通过 caching 快速响应相同的请求。
- 通过 rate limiting 防止超支与滥用。
- 通过 request retries 自动缓解临时性错误。
- 失败时可通过 model fallback 切换到其他模型或供应商。
这套组合之所以重要，是因为 AI 运营中的失败不会只以一种形态出现。有些请求只靠简单重试就够了，有些请求需要切换到别的模型，还有些请求需要在超出成本上限之前被拦截。AI Gateway 把这些判断都提升到了网关层。
目前最实用的入门方式
Cloudflare 文档里最强力推荐的方式，是使用 OpenAI 兼容 endpoint。不用大幅改动现有的 SDK 和工具，也能通过 compat/chat/completions 路径接入，因此起步门槛很低。
https://gateway.ai.cloudflare.com/v1/ACCOUNT_ID/GATEWAY_ID/compat/chat/completions
default 网关可能会在第一次请求时自动创建，Cloudflare 在 2026 年 3 月 2 日的 changelog 中也说明，AI Gateway 可以用 single API call 来启动。也就是说，一开始并不需要做复杂的基础设施工作。
推荐的上线顺序
- 先接入只读流量或低风险的工作负载。
- 查看日志和指标，确认哪些请求被大量重复。
- 分阶段开启 caching 和 rate limiting。
- 只在失败频繁的区段应用 retries 与 fallback。
- 当模型选择变得复杂时，转向 Dynamic Routing 分流。
什么时候该用 Dynamic Routing
Cloudflare 的 Dynamic Routing 文档 最近一次更新是在 2026 年 1 月 10 日。该文档描述的方式比单纯的模型 fallback 更进一步，把条件判断、quota enforcement、模型选择、fallback 整合成一个流程。
文档的核心节点如下。
- Conditional
- Percentage
- Model
- Rate Limit
- Budget Limit
- End
这套结构在实务中相当有用。例如可以把付费用户和免费用户导向不同的模型，也可以只把一部分流量分流到新模型，还可以把超出预算上限的请求自动转到其他路径。
重要的一点是，Dynamic Routing 并不是单纯的重试功能。它更接近于把条件、quota、模型选择、fallback 结合在一起的 策略路由器。所以正如 Cloudflare changelog 所说，如果需要更复杂的 failover across providers，用 Dynamic Routing 会比用 retries 更合适。
自动 retries 能相信到什么程度
根据 2026 年 4 月 2 日的 changelog，AI Gateway 在 gateway level 支持 automatic retries。可配置的范围如下。
- 最多 5 次 attempts
- 100ms 到 5 seconds 之间的 delay
- Constant、Linear、Exponential backoff
这项功能在无法直接控制调用方客户端时特别有用。比如外部合作伙伴、遗留批处理、多个团队共用的 SDK，这类场景往往很难在 caller side 加入 retry 逻辑。这种情况下，在网关层用统一策略应用重试，运营上会更安全。
不过，retries 和 fallback 并不是一回事。
- retries 更接近于对同一路径的重新尝试。
- fallback 则是切换到另一个模型或另一个 provider。
也就是说，临时性的网络错误或 upstream 错误，用 retries 来缓解；如果是 provider 本身持续失败，或者是功能差异造成的问题，最好转向 Dynamic Routing。
实务中最重要的使用场景
1. 想同时抓住可观测性与费用控制时
随着 AI 应用增多，最先需要的是看清「用了多少」。AI Gateway 把 analytics 和 logging 作为基本轴心，因此便于在同一个画面里查看成本与使用模式。
2. 相同请求大量重复时
caching 特别适合重复请求多的客服机器人、固定问题多的内部工具、模板型 agent。相同请求越多，cache hit 就积累得越有意义。
3. 需要防止滥用与突发流量时
rate limiting 既是成本防线，也是质量防线。对于像对外公开功能、公司内部共用工具这类使用模式可能急剧变化的服务，尤其重要。
4. 需要同时管理模型质量与可用性时
单一模型并不总是最优解。因为质量、响应速度、可用性、成本会因工作负载而不同，所以通过 model fallback 和 Dynamic Routing，按请求类型分离路径，是更现实的做法。
常见的错误
- 只想在应用代码里处理重试与 fallback。
- 想等到很晚才加入 caching 和 rate limiting。
- 对所有请求都强制使用同一条模型路径。
- 把 provider 故障和模型功能差异当作同一个问题看待。
- 看了日志，却没有制定实际的运营标准。
最大的错误，是把 AI Gateway 当成单纯的代理来看待。实际上，它更接近于把观测、成本控制、稳定性控制一次性绑在一起的运营层。
引入检查清单
- 首先确认哪些请求成本高、且频繁重复。
- 从日志中对失败类型进行分类。
- 确定 cache、retry、rate limit、fallback 之中，哪个最先需要。
- 如果需要使用多个 provider，优先考虑 Dynamic Routing。
- 先定好运营标准，再扩展到 production traffic。
结语
Cloudflare AI Gateway 的优点不在于功能列表有多长，而在于它能把 AI 流量提升到应用代码之外的公共层，从而把 可观测性、稳定性、成本控制、路由策略 一并处理。截至 2026 年 4 月，网关层的自动 retries 变得更简单了，更复杂的 failover 由 Dynamic Routing 负责的结构也更加清晰了。
从小处开始也无妨。但只要有一个正在运营的 AI 应用，网关层就会比想象中更快地变得必要。
参考资料
현재 단락 (1/62)
AI 应用刚开始看起来很简单，但一旦进入实际运营，很快就会出现共同的问题。需要看清是谁调用了多少次，需要追踪成本在哪里增加，还需要保证模型失败时服务不会中断。如果团队只维持直接调用模型的结构，这些问题...