竞品对比与选型
Cloudflare AI Gateway 替代方案 7 个选择完整对比
筛选 Cloudflare AI Gateway 方案，并核对路由控制、兼容性、可观测性与运维成本。
概要
如果团队希望在一个托管平台里同时获得路由、可观测性、护栏和生产控制，Portkey 是最接近的替代选择。
需要 OpenAI 兼容代理、广泛供应商支持，并希望自己掌握基础设施的团队，更适合 LiteLLM。
如果核心需求是快速接入大量模型并使用托管供应商路由，而不想运维网关服务，OpenRouter 更直接。
QVeris 不替代模型流量治理，而是为 Agent 增加可发现的金融数据、工具和可审计能力调用。
为什么团队会寻找 Cloudflare AI Gateway 替代方案
当应用本来就运行在 Cloudflare 技术栈附近时，Cloudflare AI Gateway 是很实用的选择。其官方文档重点覆盖分析、日志、缓存、限流、重试和模型回退。真正的问题不是它是否能用，而是这种运行模式是否匹配团队所需的控制平面。
搜索替代方案通常意味着五类缺口：希望自托管、需要更深入的 LLM 护栏、偏好模型市场、要求脱离单一边缘生态部署，或者希望把模型输出连接到真实数据与工具。这些是不同任务，不应压缩成一张泛化功能表。
因此，选择替代产品时应围绕迁移动机、希望掌握的流量路径，以及团队愿意承担的运维工作量进行评分。
7 个替代方案分别适合什么场景
| 替代方案 | 最适合 | 部署 | 主要取舍 |
|---|---|---|---|
| Portkey | 托管网关与护栏 | 托管或自托管网关 | 需要治理更多平台能力 |
| LiteLLM | 基础设施自主权 | 自托管代理或 SDK | 团队承担运维 |
| OpenRouter | 快速多模型接入 | 托管 API | 基础设施控制较少 |
| Helicone | 可观测性优先 | 云端或自托管 | 路由深度取决于配置 |
| Kong AI Gateway | 已有 API 平台团队 | 网关基础设施 | 平台运维较重 |
| Envoy AI Gateway | Kubernetes 原生控制 | 自行管理 | 需要平台工程能力 |
| QVeris | Agent 数据与工具能力 | 互补能力层 | 不是模型网关替代品 |
迁移清单：先保持行为一致，再更换供应商
列出供应商端点、请求头、重试规则、缓存键、限流、日志字段、预算规则和回退顺序。看似一行的端点替换，背后可能隐藏许多策略差异。
重放流式输出、工具调用、图像、结构化输出、超时和供应商错误等代表性场景。不要只比较成功文本，还要比较状态码和响应结构。
把少量非敏感请求镜像到新路径，对比延迟与输出元数据，再按阶段提升流量，并提前写明回滚触发条件。
供应商路由继续留在网关中；实时金融数据、工具和外部动作则通过具备发现与审计控制的能力层处理。
会改变选型答案的架构因素
当 Workers、边缘缓存和现有 Cloudflare 策略是应用核心时，继续使用 Cloudflare 仍然很有吸引力。
当基础设施团队必须控制部署、网络、数据路径和升级时，LiteLLM、Envoy 或 Kong 更有吸引力。
当模型覆盖和供应商回退比基础设施所有权更重要时，OpenRouter 可以明显减少接入工作。
网关负责模型流量；当 Agent 需要发现并调用实时数据集、金融 API 或外部工具时，再增加 QVeris。
替换 Cloudflare AI Gateway 时的常见错误
只有先定义部署、隐私、可观测性、路由和所有权要求，厂商对比表才真正有价值。
请求结构兼容并不保证流事件、工具 schema、错误、重试和供应商特有参数完全一致。
保留项目、客户、环境和模型标签，让新网关从第一天起就能解释成本。
模型路由与真实世界能力访问是不同架构层，可靠性和审计要求也不同。
不同 Cloudflare 迁移场景应该选谁？
当产品团队希望获得路由、护栏、可观测性和策略工作流，又不想运维所有配套服务时，可优先评估 Portkey。承诺采购前要核对日志留存、脱敏、区域要求，以及生产控制所需的具体套餐。
当部署、网络、数据路径、升级和故障响应必须掌握在内部时，可优先评估 LiteLLM、Envoy AI Gateway 或 Kong。最终差异通常取决于平台团队现有的 Kubernetes、代理、数据库和可观测性成熟度。
当快速接入广泛模型目录和托管供应商路由比基础设施所有权更重要时，可优先评估 OpenRouter。还要检查供应商选择策略、隐私控制、费用、预算、版本固定，以及首选路由不可用时的应用行为。
模型推理继续使用网关，同时增加 QVeris 负责能力发现、检查与调用。这是架构组合，不是替代决策：网关控制模型流量，能力层控制外部数据与动作。
安全、隐私与采购必须追问的问题
询问提示词、响应、元数据、缓存条目、日志、追踪和评测数据集在哪里处理与存储。不能只看网关供应商，还要包含底层模型供应商，并记录每项留存时间与跨区域传输。
测试产品如何隔离组织、项目、客户、环境和人工运维者。确认 Key 轮换、撤销、最小权限角色、服务账户和审计日志，并验证项目 Key 泄露后是否可能跨越租户边界。
比较支持响应、可用性承诺、泄露通知、子处理方披露、数据处理条款、导出权、终止协助和企业最低消费。法律或支持要求后期出现时，技术上便宜的网关可能变得昂贵。
签约前导出代表性日志与配置，轮换凭证，并把一条路由迁到直连供应商或另一网关。记录完成演练所需时间、缺失元数据、应用改动和供应商协助。
切换前需要收集的迁移证据
采集经过隐私处理的流式、结构化输出、工具调用、长上下文与失败样本，并通过每个候选方案回放，让决策基于真实工作负载而不是供应商功能表。
盘点与 Cloudflare 绑定的 Workers、分析导出、缓存、鉴权和网络策略，在估算迁移工作前区分可移植网关逻辑与边缘特有便利能力。
测试超时、429、供应商 5xx、流中断和预算耗尽，记录重试归属、回退顺序、错误归一化、告警时机以及所有路由失败时的用户体验。
确保别名、Key、配置、日志和仪表板可导出。只有团队能切换小部分流量、比较结果并在不丢失追踪的情况下返回原路由，迁移才算就绪。
QVeris 的位置：模型路由之后的能力路由
模型网关与 QVeris 解决相邻但不同的问题。网关治理推理流量，包括供应商凭证、模型选择、重试、预算、限流和日志。QVeris 则治理 Agent 需要真实能力后的下一步：发现合适工具或数据集、检查契约、执行调用并保留可审计记录。
以金融研究 Agent 为例，网关可以把规划提示词路由到合适模型；QVeris 再提供完成计划所需的市场数据、财报、基本面、新闻或外部工具。这样可以让模型策略和能力策略保持清晰，而不是让一个网关假装管理所有外部动作。
推荐架构是“模型网关 + QVeris”，而不是“模型网关 vs QVeris”。每一层只负责自己擅长治理的流量，再通过明确的身份、预算、追踪和审计元数据连接起来。
- 把推理请求发送到选定的网关或聚合器。
- 为每条路由附加项目、客户、环境和追踪身份。
- Agent 调用实时能力前，先使用 QVeris 发现与检查。
- 分别计量模型成本和能力成本，再报告完整任务成本。
FAQ
综合托管能力最接近的是 Portkey；自托管更适合 LiteLLM；广泛模型接入更适合 OpenRouter。关键取决于你为何离开 Cloudflare。
Cloudflare 文档显示 AI Gateway 可用于所有套餐，但不同套餐的网关、日志和请求限制不同。生产规划前应核对最新官方限制。
如果团队愿意运维服务及其配套数据存储，LiteLLM 可以替代许多代理、路由、回退、预算和日志功能。
不会。QVeris 是面向可发现工具与数据的互补能力层。模型流量使用网关，Agent 能力调用使用 QVeris。
应测试流式输出、结构化输出、工具调用、供应商错误、超时、回退、缓存行为、限流、用量归因和日志脱敏。
需要综合部署、留存、区域路由、合同控制和具体供应商路径。自托管可能提升控制力，但也会增加运维责任。
来源、方法与更新政策
本指南使用公开产品文档和基于工作负载的决策框架。产品限制、价格、支持模型和套餐边界会频繁变化；采购或生产迁移前，请直接向各供应商核对最新条款。
QVeris 是本指南的发布方，文中仅按其互补能力层定位进行说明。对比明确区分模型推理路由与 Agent 能力路由，使商业关系保持透明，而不是隐藏在泛化排名中。