模式

为什么我把整个产品都建在 Cloudflare 上

大多数 AI 产品跑在 AWS 或 Vercel 上 + 某处的数据库。我把每一层都跑 在 Cloudflare 上——Workers、D1、R2、KV、Vectorize、AI Gateway、Pages。 六个理由它加起来意味着更少的代码和更低的账单，以及两种我不会用它的 情况。

30 秒版

今天典型的 AI 产品跑在三四片云上：Vercel/Netlify 做前端、AWS 或 Render 做后端、OpenAI 做模型、Supabase 或某处 Postgres 做存储。 我把全部跑在 Cloudflare 上——Workers 做计算、D1 做 SQL、R2 做 文件、KV 做缓存、Vectorize 做 embedding、AI Gateway 做路由、Pages 做静态、Durable Objects 做状态。账单大约是 AWS 等价方案的 1/10， 部署故事从”看情况”塌缩成 wrangler deploy。

我怎么收敛到这里

我先试了多云版。一个普通 AI 产品的架构图长这样：

  • Vercel 做前端
  • Railway 做后端
  • OpenAI 做推理
  • Supabase 做 Postgres + 认证
  • Pinecone 做向量检索
  • S3 做文件
  • Sentry 做监控

七个服务、七张账单、七种失败模式、七套 secrets。每一个都是”同类最佳” 的选择，合起来却不连贯。一个月内我感受到三个问题：

  1. 跨云延迟是真实的。 前端在一个区，后端在另一个区，向量检索 在第三个区——每次 API 调用都累计 round-trip。
  2. 心智模型是税。 每个服务有自己的 dashboard、自己的定价模型、 自己的留存怪癖。带一个合作者上手要一周。
  3. 账单非线性叠加。 每个服务都有免费档，但你任意一个超过任一 阈值的瞬间，账单就涨。它们之间的 egress 是沉默的杀手。

我把整个东西重做在 Cloudflare 上。架构图变成：

  • Pages 做前端
  • Workers 做后端
  • AI Gateway → OpenAI/Claude 做推理
  • D1 做 SQL
  • R2 做文件
  • KV 做缓存
  • Vectorize 做 embedding
  • Durable Objects 做状态
  • Workers Logs 做监控

一张账单。一个 CLI（wrangler）。一个 dashboard。 组件之间的延迟 亚毫秒，因为它们在同一个 edge。

这件事加起来的六个理由

1. 计算在 edge，不在某个 region。 Workers 跑在数百个城市。东京 的用户打 Worker 在东京，它和 D1（全球只读副本）和 Vectorize（也 edge 部署）说话。整个 stack 默认地理分布。AWS 等价方案要求你选 region、配只读副本、装 CloudFront，然后解释为什么 API Gateway 还是 在 us-east-1。

2. Runtime 小到能真的理解。 Workers 是 V8 isolate + 受限的 API 表面。不能跑原生二进制；你有一小套 binding（KV、R2、D1、Queue、 Vectorize）。约束严苛。约束也正是它能扩展的原因。没有 Lambda 那种”冷启动”，因为没有 node_modules 要加载。

3. Cloudflare 服务之间 egress 免费。 这是打破 AWS 定价模型的部分。 R2 零 egress。Workers 调 D1 或 KV 零 egress。“一堆小服务互相说话” 的架构在 AWS 上贵（因为跨服务流量），在 Cloudflare 上免费。

4. 部署原子且即时。 wrangler deploy 构建你的 worker 并在几秒 内全球推送。没有 CI 流水线、没有镜像仓库、没有 rolling deploy。 要 staging？推到不同的名字。要回滚？重新部署上一个 artifact。

5. 认证终于可承受。 Workers + KV + 一个 JWT 库够大多数 app 用。 更复杂的，Cloudflare Access 给内部 app，better-auth（或任何 JWT 库）给终端用户。这些都不需要 Auth0 或 Cognito 或自己造。

6. AI Gateway 是被低估的杀手特性。 我所有的 LLM 调用都过 AI Gateway。它给我缓存、重试、回退到备用提供商、按路由的成本追踪、 按功能的分析——免费，一个 binding。我加上它的时候删的代码量 让我尴尬。

你放弃的东西

三个真实约束：

1. 没有长任务计算。 Workers 有 30 秒 CPU 上限（付费档 5 分钟）。 更长的（大模型推理、视频处理、长批处理）你需要别的服务。我用 Modal 或 Replicate。Cloudflare 是给 edge 逻辑和存储的；重 ML 在别处发生。

2. 没有原生二进制。 支持 WASM，但如果你的依赖是没有 JS binding 的 C++ 库，没办法。这排除的东西比你想的少，但值得提前检查。

3. 生态更年轻。 AWS 17 年了，对每个奇怪需求都有答案。Cloudflare 对开发者平台认真大约 5 年，缺一些细分服务（FTS5 之外的托管搜索、 托管 ML 训练、完整的图数据库）。对 90% 的产品没问题。对剩下的 10%，你付 AWS 税。

我不会选 Cloudflare 的两种情况

  1. 重 ML 训练流水线。 如果你的产品是训练模型而不是调用 模型，Cloudflare 的计算模型不是为这个建的。用任何有你需要的 GPU/ TPU 价格的云。
  2. 严格监管数据驻留。 Workers 设计上就在 edge 跑，意味着你的 数据可能在数百个城市中的任一个被处理。HIPAA、严格的 GDPR、有数据 驻留要求的政府项目，你需要更受限的部署模型。

其他一切——也就是大多数 AI 产品——从 Cloudflare 开始。你随时 可以为某个具体场景在另一片云上加服务；不用一开始就去那里。

我会怎么在面试里讲

“你为什么选这个 stack？“——一个大多数候选人靠列服务就错过的软球。 更好的答案：

我优化两个指标：从想法到部署的时间，和 10 倍规模时的账单。两个 都指向 Cloudflare 端到端。部署故事是 wrangler deploy。账单由 AI 推理主导，不是基建。约束（无长任务计算、无原生二进制）让我付的 代价比 AWS 多区域复杂度让我付的代价小。需要重 ML 时我加 Modal—— 但 edge 逻辑和存储都留在 Cloudflare。

这个答案有立场、有权衡、点名了具体约束。能说出自己放弃了什么的 候选人，比说不出的更可信。