本文目录
概要:先按平台重心筛选,再用真实流量证明
选择 Cloudflare AI Gateway:当边缘策略、精确匹配缓存、逐请求日志控制、显式限额分支和版本化动态路由是核心需求。选择 Vercel AI Gateway:当团队更重视 AI SDK、统一 creator/model 目录、自动 Provider 选择、Vercel OIDC 和应用平台可观测性。如果两边优势都不明显,就保留 OpenAI-compatible 适配层,用 7 天影子流量测试决定,而不是只比功能数量。
流量整形、缓存控制、逐请求日志行为,以及可视化或 JSON 动态路由。
AI SDK、统一模型访问、自动 Provider 选择、OIDC、预算和贴近应用的可观测性。
一次热请求无法说明 p95 延迟、限流、Provider 回退或区域差异。
把 Gateway URL、凭证、模型别名、路由策略和日志解析放在业务逻辑之外。
这篇对比真正要帮你决定什么
搜索“Cloudflare vs Vercel AI Gateway”的用户通常已经知道 AI Gateway 是什么。他们真正关心:哪个更适合现有技术栈、当前 API 是否兼容、路由与缓存如何工作、哪些内容会进入日志、成本如何组成,以及迁移是否可回滚。营销式摘要回答不了这些问题,可执行的决策契约可以。
适用人群与前置条件
本指南适合从模型厂商直连迁移、统一多个模型供应商,或为已部署在 Cloudflare / Vercel 上的 AI 应用选择 Gateway 的团队。
- 确定一个代表性模型和一个回退模型,并确认两边都可访问。
- 固定 Prompt 集,包含短文本、长文本、Streaming、Tool Call、Structured Output 和敏感场景。
- 服务端 Secret、Request ID、租户身份、超时预算和脱敏策略。
- 预先定义 p95 延迟、错误率、回退率、输出有效率和每个有效响应成本阈值。
决策矩阵:什么情况下哪一方更适合作为默认选择
| 主导需求 | 更合适的起点 | 原因 | 上线前证明 |
|---|---|---|---|
| 边缘优先流量策略 | Cloudflare | Dynamic Route 把条件、百分比分流、限流、预算、重试和回退表达为版本化 Flow。 | 规则执行、路由回滚、分区域 p95 |
| Next.js / AI SDK 工作流 | Vercel | Gateway 围绕 AI SDK 以及 OpenAI、Responses、Anthropic-compatible 接入设计。 | 本地、Preview、Production 认证及 Streaming 一致性 |
| 精确匹配 Prompt 缓存 | Cloudflare | 官方说明 Cache Key 与逐请求 Override,行为更显式。 | Key 完整性、陈旧答案风险、实测命中率 |
| 统一目录与 Provider 选择 | Vercel | creator/model ID、模型目录端点和自动 Provider 选择减少应用侧接线。 | 模型可用性、Provider Allowlist、回退轨迹 |
| 逐请求禁止记录 Prompt | Cloudflare | 官方 Header 可关闭整条日志,或只保留元数据、不保存请求/响应正文。 | 检查实际日志记录,并测试保留期与访问权限 |
| 降低平台锁定 | Neutral adapter | 两边都有 OpenAI-compatible 路径,但策略、模型名、认证和遥测仍不同。 | 双跑测试与一键回滚 |
架构:不要把 Gateway 策略写进业务逻辑
统一 Messages、Tools、Structured Output Schema、Streaming、Timeout、Tenant 和 Request ID。
应用只请求 fast、balanced 或 reasoning,由部署配置解析为当前 Gateway 的模型 ID。
转换凭证、Provider 顺序、缓存资格、日志控制、重试预算和 Gateway Metadata。
返回输出,并保留 Gateway、Provider、Model、Request ID、耗时、Token、Cache Status、Fallback Path 和 Policy Version。
只统计 Schema 有效且满足策略的响应;HTTP 成功不等于业务成功。
Cloudflare 与 Vercel AI Gateway 当前能力对比
| 维度 | Cloudflare AI Gateway | Vercel AI Gateway | 决策含义 |
|---|---|---|---|
| 主要 API | Cloudflare REST API 与 OpenAI-compatible Chat/Responses;也有 Provider-specific Path | 统一端点支持 AI SDK、OpenAI Chat/Responses、Anthropic Messages 等客户端 | 两者都可置于适配层后,但扩展字段并不完全相同。 |
| 路由 | 版本化 Dynamic Route,包含条件、百分比、限流、预算、模型、重试和回退节点 | 自动 Provider 选择,并支持逐请求 order/only、Timeout 与 Model Fallback | Cloudflare 更像显式 Flow;Vercel 更强调应用工作流中的 Model/Provider Policy。 |
| 缓存 | 文本与图片精确匹配缓存,官方说明 Key 构成和 Request Override | 可通过 Provider Options 控制 Gateway/Provider Caching | 比较语义安全与实测命中率,而不是功能勾选。 |
| 认证 | REST 使用 Cloudflare API Token;不同路径可使用 Provider Credential、Stored Key 或 Unified Billing | 通用 AI Gateway API Key;Vercel 上可自动使用 OIDC;支持 Team BYOK | 分别测试本地、CI、Preview 与 Production。 |
| 可观测性 | Analytics 与详细日志,可控制 Payload 收集;保留期与导出取决于套餐 | Gateway Usage、Event、Budget 与 Vercel 可观测性集成 | 建立自己的标准事件 Envelope,才能跨 Gateway 比较。 |
| 计费方式 | 核心 Gateway 功能官方标为免费;Unified Billing 收取 Credit Fee;Provider Inference 透传 | Credit-based Gateway Billing 与 BYOK 路径;采购时需核对最新价格 | 模型费用只是总成本的一部分。 |
Cloudflare 已把旧 Universal Endpoint 标记为弃用。新实现应使用 OpenAI-compatible REST Endpoint 与 Dynamic Routing。旧集成仍可继续运行,但不要再把旧的 Array-based Fallback 格式复制进新架构。
使用同一客户端契约的分步实现
从 OpenAI Client 开始,因为两边都提供 Compatible Chat Completion Path。先发现并固定你账户可用的模型;模型目录会变化,因此示例使用环境变量,而不是硬编码“最新模型”。
import OpenAI from "openai";
type Gateway = "cloudflare" | "vercel";
const profiles = {
cloudflare: {
apiKey: process.env.CLOUDFLARE_API_TOKEN!,
baseURL:
"https://api.cloudflare.com/client/v4/accounts/" +
process.env.CLOUDFLARE_ACCOUNT_ID + "/ai/v1",
model: process.env.CLOUDFLARE_MODEL_ID!,
},
vercel: {
apiKey: process.env.AI_GATEWAY_API_KEY!,
baseURL: "https://ai-gateway.vercel.sh/v1",
model: process.env.VERCEL_MODEL_ID!,
},
} satisfies Record<Gateway, {
apiKey: string; baseURL: string; model: string;
}>;
export async function runGateway(gateway: Gateway, prompt: string) {
const profile = profiles[gateway];
const client = new OpenAI({
apiKey: profile.apiKey,
baseURL: profile.baseURL,
timeout: 30_000,
maxRetries: 0, // own retries once; avoid retry multiplication
});
const started = performance.now();
const response = await client.chat.completions.create({
model: profile.model,
messages: [{ role: "user", content: prompt }],
temperature: 0,
});
return {
gateway,
model: response.model,
text: response.choices[0]?.message?.content ?? "",
usage: response.usage,
durationMs: Math.round(performance.now() - started),
};
}
Cloudflare REST API 使用账户 Token 认证,第三方模型采用 author/model 命名。Cloudflare 的 Provider-specific Endpoint 使用不同凭证/Header 方式,因此应固定一种路径并记录。Vercel 则应先查询模型目录,再固定 ID。
curl "https://ai-gateway.vercel.sh/v1/models" \
-H "Authorization: Bearer $AI_GATEWAY_API_KEY" \
-H "Content-Type: application/json"
# Store the reviewed creator/model ID in VERCEL_MODEL_ID.
# Re-run discovery during planned model upgrades, not per request.
路由与回退:明确失败语义
| 策略问题 | 必须明确的答案 | 测试 |
|---|---|---|
| 什么触发回退? | Timeout、Provider 5xx、429、空 Stream、Schema 无效、Policy Reject 并不等价。 | 分别注入每种失败。 |
| 谁负责重试? | Client、Gateway、Provider SDK 和 Job Worker 不能各自独立重试。 | 统计每个用户请求的上游尝试次数。 |
| 回退输出兼容吗? | Tool Call、JSON Schema、安全行为、Context Window 和 Finish Reason 可能不同。 | 每个路由分支之后都验证输出。 |
| 能否还原路径? | 记录请求 Alias、Resolved Model、Provider、Attempt、Policy Version 和最终原因。 | 端到端追踪一次强制回退。 |
设置一个端到端 Deadline 和一个最大上游尝试预算。一个 30 秒请求,如果三层都各重试两次,可能产生 6 次以上计费调用,最终仍错过用户 Deadline。
缓存:只优化语义上可复用的请求
Cloudflare 官方说明精确匹配 Cache Key 包含 Provider、Endpoint、Model、Provider Authorization Header 和完整请求体。这适合重复的确定性调用,但 Identity、Tool State、Retrieval Freshness 和 Authorization 可能让两个文本相同的 Prompt 在语义上不同。
- 输入完整且确定时,可缓存分类、抽取和静态转换。
- 用户私密对话、权限相关答案、实时余额或 Tool Result,若没有明确身份与新鲜度 Key,不应缓存。
- 衡量“有效答案缓存命中率”,而不是原始 Cache Hit Rate。
- 生产启用缓存前,先定义 Bypass 与 Purge 流程。
日志、隐私与可观测性控制
Cloudflare Logging 默认开启,并可能包含 Prompt 与模型响应。当前官方文档说明:cf-aig-collect-log: false 可跳过整条日志,cf-aig-collect-log-payload: false 可保留元数据但不保存请求/响应正文。它们只是实现控制,并不等于完整隐私治理。
选择日志行为前,先标记公开、内部、机密、受监管和禁止 Payload。
进入 Gateway 前移除 Token、Credential、Session Cookie、不必要 PII 和检索到的 Secret。
使用自己的 Request ID 与 Event Schema,让 Dashboard 能跨 Gateway 保留。
发送 Canary Marker,检查日志与导出,再证明删除、保留期和角色访问。
同负载验证方案
让两个 Gateway 执行同一个“有效答案契约”。至少覆盖三个区域、冷/热时段、Streaming/Non-streaming、并发爬坡和强制 Provider 故障。基准延迟测试固定 Model 与 Provider,路由策略另测。
| 指标 | 测量方式 | 为什么重要 |
|---|---|---|
| TTFT p50 / p95 / p99 | 从请求开始到首个内容 Token | 用户感知响应速度 |
| 有效成功率 | Schema 有效且满足策略的结果 / 用户请求数 | 排除空响应或格式错误的 200 |
| 回退恢复率 | 有效回退结果 / 注入的主路径失败数 | 验证真实韧性,而不是配置存在 |
| 每个有效响应成本 | 模型、重试、Gateway、日志与出口成本总和 / 有效结果 | 包含重试和质量浪费 |
| 追踪完整率 | 拥有 Gateway、Provider、Model、Attempt、Token、Timing 和最终原因的请求占比 | 决定事故可诊断性 |
type Run = {
ok: boolean;
schemaValid: boolean;
policyAllowed: boolean;
durationMs: number;
attempts: number;
costUsd?: number;
};
export function summarize(runs: Run[]) {
const accepted = runs.filter(
(r) => r.ok && r.schemaValid && r.policyAllowed
);
return {
requests: runs.length,
acceptedRate: accepted.length / runs.length,
retryAmplification:
runs.reduce((n, r) => n + r.attempts, 0) / runs.length,
costPerAccepted:
runs.reduce((n, r) => n + (r.costUsd ?? 0), 0) /
Math.max(accepted.length, 1),
};
}
成本模型:比较每个有效输出的总成本
Gateway 定价会变化,采购前必须核对当前套餐页。更稳定的比较方式是:Provider Inference + Gateway/Credit Fee + Retry/Fallback + 日志存储与导出 + 应用计算 + 工程运维,再除以有效业务结果。
Cloudflare 当前官方说明核心 Analytics、Caching 和 Rate Limiting 不收 Gateway 费用,日志限额取决于 Workers 套餐;Unified Billing 收取 Credit Fee,Provider Inference 不加价透传。仍应核对最新表格与 Workers 套餐。
常见失败模式与修复
| 现象 | 可能原因 | 修复 |
|---|---|---|
| Cloudflare 返回 401 | 账户 Token 与 Provider Credential 放错 Header,或混用了 Endpoint Style | 严格按所选 REST 或 Provider-specific Path 的官方认证方式配置 |
| 回退导致成本倍增 | Client、Gateway 与 Worker 重试叠加 | 集中重试所有权,并限制上游尝试次数 |
| 缓存答案泄露上下文 | 缓存资格未考虑 Tenant、权限、检索版本或 Tool State | 默认禁用缓存,只对白名单确定性工作负载开启 |
| HTTP 200 仍让应用报错 | 回退模型返回不兼容 JSON 或 Tool-call Shape | 验证每个输出分支,把无效输出计为失败 |
| Benchmark 赢家上线后反转 | 单区域热请求忽略了并发、限流和 Provider 选择 | 执行分区域 p95/p99 测试并受控放量 |
迁移与回滚方案
列出 SDK、Endpoint、Model、Tool、Streaming、Credential、Retry、Timeout 和日志目的地。
把 Base URL、Auth、Model Alias 和 Gateway Extension 移入配置。
使用脱敏后的生产形态 Prompt,比较输出有效性,而不是逐字一致。
镜像符合条件的请求,只有阈值持续满足时才按 1% → 5% → 25% → 50% → 100% 放量。
一个配置开关即可恢复旧 Profile,无需重新部署代码或迁移数据。
- 若有效成功率下降、p95 超预算、重试放大或 Trace 完整率下降,立即回滚。
- 在观察期内保留旧 Credential 与 Dashboard。
- Benchmark 期间冻结路由策略,否则比较的是不断变化的系统。
QVeris 的位置:能力层,而不是替代模型 Gateway
Cloudflare 或 Vercel 负责应用与模型 Provider 之间的流量治理;当 Agent 还需要外部 API 与工具时,QVeris 补充能力发现层。模式是 Discover → Inspect → Call:发现能力、检查 Schema 与权限,再用受控输入调用。Gateway 的模型路由证据与 QVeris 的工具来源证据应作为两条独立 Provenance Chain 保存。
按任务、新鲜度、地区和信任边界搜索外部能力。
检查输入、输出、权限、限制、Provider 身份和失败语义。
调用最小范围工具,保存证据,验证输出,只把必要上下文发送到模型 Gateway。
Cloudflare 与 Vercel AI Gateway 常见问题
Cloudflare 与 Vercel AI Gateway 哪个更好?
没有通用赢家。Cloudflare 更适合边缘策略、显式缓存/日志控制和版本化可视路由;Vercel 更适合 AI SDK、统一模型目录、自动 Provider 选择和 Vercel 原生运维。
Cloudflare Universal Endpoint 还推荐使用吗?
新集成不推荐。Cloudflare 已标记其为弃用,并推荐使用 OpenAI-compatible Endpoint 加 Dynamic Routing 实现回退、重试和条件路由。
两者都能使用 OpenAI-compatible Client 吗?
可以。两边都提供兼容 Chat Completion Endpoint。使用环境专属 Base URL,并把 Model Alias 保存在配置中。
如何公平比较延迟?
固定 Model、Prompt、Region、Streaming Mode、Timeout 和并发,测量 TTFT、总耗时、错误率、回退率以及 p95/p99,而不是一次热请求。
Gateway 缓存一定能降低成本吗?
不一定。精确匹配缓存适合确定性重复请求,但若忽略身份、权限、新鲜度或 Tool State,可能返回陈旧或上下文错误的答案。
如何处理敏感 Prompt?
把日志视为明确的数据治理决策。Cloudflare 提供逐请求关闭整条日志或 Payload 收集的控制。无论哪一平台,都应数据分级、Secret 脱敏、限制访问、设置保留期并检查实际日志。
迁移时可以完全不改应用代码吗?
适配层可以减少改动,但 Model Naming、Auth Header、Provider Policy、Cache Semantics 和 Observability Field 仍需转换与测试。
QVeris 位于哪里?
QVeris 为任一 Gateway 补充外部能力的发现、检查与调用。Gateway 管理模型流量,QVeris 管理更广泛的工具与 API 能力层。
官方资料
Gateway API、模型目录、价格和套餐限制会变化。以下第一方资料已在 2026 年 7 月修订时核对;生产上线前请再次确认。
用证据选型,并让退出保持可逆
先按平台重心缩小范围,再用有效输出指标证明选择,并把 Gateway-specific 配置放在一个适配层后。当 Agent 还需要治理模型流量之外的外部工具发现与调用时,再接入 QVeris。
探索金融 Agent 工具
