在大模型应用从单轮对话向多轮协作演进的今天，AI Agent 的基础设施需求已远超传统 API 调用的范畴。Cloudflare 于 2025 年底正式推出面向 Agent 的推理服务层，通过 AI Gateway 与自研推理引擎 Infire 的协同，为代理工作负载提供了从模型编排到边缘推理的完整工程方案。本文从架构设计视角出发，拆解这一推理基础设施的核心组件与可落地参数。
AI Gateway：代理工作负载的统一编排层
AI Gateway 是 Cloudflare 推理服务层的顶层抽象，它解决的问题并非单纯的模型调用，而是 Agent 场景下多模型协同的复杂性。一个典型的代理系统往往包含规划模型、分类模型、视觉理解模型等多个角色，这些模型可能来自不同的推理供应商，且各自的延迟、可用性和成本结构差异显著。AI Gateway 通过统一入口屏蔽了这些底层差异，开发者只需面向单一接口编程，底层由 Gateway 完成模型路由、流量控制和可观测性收集。
从支持的供应商规模来看，AI Gateway 目前已接入超过 14 家主流模型提供商，包括 OpenAI、Anthropic、Google、Meta 等头部厂商，以及各类开源模型。这意味着 Agent 开发者可以在不修改业务代码的前提下，动态切换底层模型或实现多模型冗余。这种多供应商架构对于生产级代理系统尤为重要 —— 当某一供应商出现区域性降级时，流量可以在秒级切换到备用模型，保障代理任务的连续性。
在代理工作负载的特殊优化方面，AI Gateway 提供了两项关键能力：自动重试与跨供应商回退。自动重试机制针对瞬态故障设计，支持配置 1 至 5 次重试尝试，延迟范围从 100 毫秒到 5 秒可调，并支持常数、线性、指数三种退避策略。指数退避策略配合 jitter（随机抖动）可以有效避免重试风暴，在真实生产环境中，建议将首次重试延迟设置为 500 毫秒，后续重试采用指数增长，最大延迟不超过 3 秒。跨供应商回退则通过 Universal Endpoint 实现，当主模型响应超时或返回 5xx 错误时，请求会自动流向配置的备用模型。响应头中的 cf-aig-step 字段会记录当前成功的是第几个模型（0 表示主模型成功，1 及以上表示回退成功），这对于调试和监控代理系统的容灾表现非常有用。
Infire 推理引擎：Rust 编写与边缘 GPU 优化
如果说 AI Gateway 负责流量层面的编排，那么 Infire 则是 Cloudflare 在推理计算层面的核心竞争力。Infire 是一个完全使用 Rust 编写的 LLM 推理引擎，其设计目标是在 Cloudflare 遍布全球的边缘网络上提供高吞吐、低延迟的模型服务。与传统的 Python-based 推理 Serving 栈不同，Rust 带来的核心优势在于极低的 CPU 开销和更高的并发处理能力，这对于需要同时服务海量租户的边缘环境至关重要。
Infire 针对 NVIDIA Hopper 架构 GPU 进行了深度优化，采用了多项行业前沿的推理加速技术。连续批处理（Continuous Batching）替代了传统的静态批处理，允许在推理过程中动态将新请求加入批次，从而将 GPU 利用率推向更高水平。分块预填充（Chunked Prefill）技术将长序列的预填充阶段拆解为多个小块，避免单次大内存分配导致的显存瓶颈。CUDA Graphs 通过预编译计算图减少内核启动开销，而分页 KV 缓存（Paged KV Cache）则借鉴了操作系统的虚拟内存管理思想，将显存分配粒度从固定分配改为按需分页，显著提升了显存利用率。
从工程实测数据来看，Infire 可以在 4 秒内完成 Llama-3-8B 级别模型的加载启动，这一指标对于边缘部署场景意义重大 —— 当需要根据流量弹性扩容或在不同边缘节点间迁移模型时，冷启动时间直接决定了用户体验。Cloudflare 官方公布的 GPU 利用率数据超过 80%，在边缘推理场景中属于相当高的水平，这主要得益于其自定义 JIT 编译的 CUDA 内核 —— 这些内核针对特定模型结构和硬件配置进行了手工调优，而非使用通用 kernel。
面向 Agent 的可靠性设计参数
将上述架构落实到生产环境，需要关注一组可操作的工程参数。以下是面向代理工作负载的推荐配置区间：
在重试策略层面，对于非关键路径的代理任务，建议将重试次数设置为 3 次、退避策略选择指数退避、初始延迟 500 毫秒、最大延迟 2 秒。对于涉及状态修改的关键路径任务，建议将重试次数提升至 5 次，并在代码层面配合幂等性设计，避免重试导致的状态不一致。在成本控制层面，AI Gateway 支持按请求数和 token 数分别设置限额，代理开发者应根据单次任务的最大预期 token 消耗乘以并发因子来设定上限，避免因代理循环调用导致的费用失控。
在部署架构层面，Workers AI 与 Infire 的组合已经覆盖了全球 200 多个城市的边缘节点。对于延迟敏感型 Agent，建议将推理请求路由到最近的数据中心，这通常可以通过在请求中指定 cf-aig-node-hint 响应头实现。若代理任务需要处理长上下文（例如多轮对话记忆或文档分析），建议将上下文窗口拆分后分段调用，而非一次性发送完整上下文，以降低单次请求的超时风险。
工程落地的监控与回滚要点
代理系统的可观测性是运维稳定性的基础。AI Gateway 提供了开箱即用的监控指标，包括每个模型的请求延迟分布、错误率、token 消耗量和回退触发次数。建议在告警系统中配置两个关键指标：单个模型的错误率超过 5% 时触发回退检查，以及回退请求占比超过 10% 时触发供应商健康检查。当发现特定供应商持续出现异常时，可以通过 AI Gateway 的动态路由规则将该供应商权重降为 0，实现无感知切换。
回滚策略方面，由于 AI Gateway 的配置变更会在秒级生效，建议在调整重试策略或切换主模型前，先在灰度流量（占总流量的 1% 至 5%）上验证新配置的有效性，确认无异常后再全量推送。这一原则对于任何涉及代理行为变更的配置调整都适用 —— 代理系统的非确定性特征使得小范围验证比传统后端服务更为必要。
综合来看，Cloudflare 的 Agent 推理服务层通过 AI Gateway 解决了多模型编排与可靠性问题，通过 Infire 解决了边缘推理效率问题，二者共同构成了面向代理工作负载的完整基础设施层。对于正在构建生产级 AI Agent 的团队，理解并合理配置这些基础设施参数，是保障代理系统稳定运行的关键一步。
资料来源：本文技术细节参考 Cloudflare 官方博客关于 Infire 推理引擎的架构介绍、AI Gateway 产品文档中关于重试与回退的配置说明，以及 Cloudflare 开发者文档中关于边缘推理能力的描述。