Cloudflare vs Vercel AI Gateway Cloudflare 与 Vercel AI Gateway 对比

TL;DR: choose by platform gravity, then prove it with your trafficTL;DR：先按平台重心筛选，再用真实流量证明

What this comparison must help you decide这篇对比真正要帮你决定什么

People searching “Cloudflare vs Vercel AI Gateway” usually already understand the category. They need to know which gateway fits their stack, whether current APIs are compatible, how routing and caching actually behave, what gets logged, how costs are composed, and whether migration is reversible. Marketing summaries do not answer those questions; an executable decision contract does.

搜索“Cloudflare vs Vercel AI Gateway”的用户通常已经知道 AI Gateway 是什么。他们真正关心：哪个更适合现有技术栈、当前 API 是否兼容、路由与缓存如何工作、哪些内容会进入日志、成本如何组成，以及迁移是否可回滚。营销式摘要回答不了这些问题，可执行的决策契约可以。

Who this guide is for and prerequisites适用人群与前置条件

This guide is for teams moving from direct provider calls, standardizing several model vendors, or choosing a gateway for an AI application already deployed on Cloudflare or Vercel.

本指南适合从模型厂商直连迁移、统一多个模型供应商，或为已部署在 Cloudflare / Vercel 上的 AI 应用选择 Gateway 的团队。

• One representative model and one fallback model with access confirmed on both candidates.确定一个代表性模型和一个回退模型，并确认两边都可访问。
• A fixed prompt set containing short, long, streaming, tool-call, structured-output, and safety-sensitive cases.固定 Prompt 集，包含短文本、长文本、Streaming、Tool Call、Structured Output 和敏感场景。
• Server-side secrets, a request ID, tenant identity, timeout budget, and a redaction policy.服务端 Secret、Request ID、租户身份、超时预算和脱敏策略。
• Success thresholds for p95 latency, error rate, fallback rate, output validity, and cost per accepted response.预先定义 p95 延迟、错误率、回退率、输出有效率和每个有效响应成本阈值。

Decision matrix: when each gateway is the stronger default决策矩阵：什么情况下哪一方更适合作为默认选择

Architecture: keep gateway policy out of business logic架构：不要把 Gateway 策略写进业务逻辑

Cloudflare vs Vercel AI Gateway: current capability comparisonCloudflare 与 Vercel AI Gateway 当前能力对比

Step-by-step implementation with the same client contract使用同一客户端契约的分步实现

Start with the OpenAI client because both gateways document compatible chat completion paths. Discover and pin a model available in your account; model catalogs change, so the example intentionally uses an environment variable rather than a hard-coded “latest” model.

从 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),
  };
}

For Cloudflare’s REST API, the account token authenticates the call and third-party models use author/model naming. Provider-specific Cloudflare endpoints use different credential/header patterns, so choose one path and document it. For Vercel, query the model catalog before pinning an ID.

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.

Routing and fallback: make failure semantics explicit路由与回退：明确失败语义

Caching: optimize only requests that are semantically reusable缓存：只优化语义上可复用的请求

Cloudflare documents an exact-match cache key that includes provider, endpoint, model, provider authorization header, and full request body. That makes repeated deterministic calls a natural candidate, but identity, tool state, retrieval freshness, and authorization can make two text-identical prompts semantically different.

Cloudflare 官方说明精确匹配 Cache Key 包含 Provider、Endpoint、Model、Provider Authorization Header 和完整请求体。这适合重复的确定性调用，但 Identity、Tool State、Retrieval Freshness 和 Authorization 可能让两个文本相同的 Prompt 在语义上不同。

• Cache classification, extraction, and static transformations when inputs are complete and deterministic.输入完整且确定时，可缓存分类、抽取和静态转换。
• Do not cache user-private conversations, permission-dependent answers, live balances, or tool results without an explicit identity and freshness key.用户私密对话、权限相关答案、实时余额或 Tool Result，若没有明确身份与新鲜度 Key，不应缓存。
• Measure accepted-answer cache hit rate, not raw cache hit rate.衡量“有效答案缓存命中率”，而不是原始 Cache Hit Rate。
• Define bypass and purge procedures before enabling cache in production.生产启用缓存前，先定义 Bypass 与 Purge 流程。

Logging, privacy, and observability controls日志、隐私与可观测性控制

Cloudflare logging is enabled by default and can include prompts and model responses. Its current docs specify cf-aig-collect-log: false to skip the log and cf-aig-collect-log-payload: false to keep metadata without request and response bodies. Treat these as implementation controls, not a complete privacy program.

Cloudflare Logging 默认开启，并可能包含 Prompt 与模型响应。当前官方文档说明：cf-aig-collect-log: false 可跳过整条日志，cf-aig-collect-log-payload: false 可保留元数据但不保存请求/响应正文。它们只是实现控制，并不等于完整隐私治理。

A same-workload validation plan同负载验证方案

Run both gateways against the same accepted-answer contract. Use at least three regions, cold and warm periods, streaming and non-streaming requests, concurrency ramps, and forced provider failures. Keep the model and provider fixed for baseline latency; test routing policy separately.

让两个 Gateway 执行同一个“有效答案契约”。至少覆盖三个区域、冷/热时段、Streaming/Non-streaming、并发爬坡和强制 Provider 故障。基准延迟测试固定 Model 与 Provider，路由策略另测。

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),
  };
}

Cost model: compare total accepted-output cost成本模型：比较每个有效输出的总成本

Gateway pricing changes, so verify the current plan pages before purchase. The durable comparison is an equation: provider inference + gateway or credit fees + retries and fallbacks + log storage/export + application compute + engineering operations, divided by accepted business results.

Gateway 定价会变化，采购前必须核对当前套餐页。更稳定的比较方式是：Provider Inference + Gateway/Credit Fee + Retry/Fallback + 日志存储与导出 + 应用计算 + 工程运维，再除以有效业务结果。

Common failure modes and fixes常见失败模式与修复

Migration and rollback plan迁移与回滚方案

• Rollback if accepted success rate drops, p95 exceeds budget, retry amplification rises, or trace completeness falls.若有效成功率下降、p95 超预算、重试放大或 Trace 完整率下降，立即回滚。
• Keep old credentials and dashboards active through the observation window.在观察期内保留旧 Credential 与 Dashboard。
• Freeze routing policy during benchmark runs; otherwise you are comparing changing systems.Benchmark 期间冻结路由策略，否则比较的是不断变化的系统。

Where QVeris fits: capability layer, not model gateway replacementQVeris 的位置：能力层，而不是替代模型 Gateway

Cloudflare or Vercel can govern traffic between your application and model providers. QVeris complements that layer when an agent also needs external APIs and tools. The pattern is Discover → Inspect → Call: find a capability, inspect schema and permissions, then invoke it with bounded inputs. Keep model-routing evidence from the gateway and tool-source evidence from QVeris as separate provenance chains.

Cloudflare 或 Vercel 负责应用与模型 Provider 之间的流量治理；当 Agent 还需要外部 API 与工具时，QVeris 补充能力发现层。模式是 Discover → Inspect → Call：发现能力、检查 Schema 与权限，再用受控输入调用。Gateway 的模型路由证据与 QVeris 的工具来源证据应作为两条独立 Provenance Chain 保存。

Cloudflare vs Vercel AI Gateway FAQCloudflare 与 Vercel AI Gateway 常见问题

Official sources官方资料

Gateway APIs, model catalogs, pricing, and plan limits change. These primary sources were checked for this July 2026 revision; verify them again before production rollout.

Gateway API、模型目录、价格和套餐限制会变化。以下第一方资料已在 2026 年 7 月修订时核对；生产上线前请再次确认。