前两天我把一个 AI 问答 Demo 从“本地能跑”推到“线上能用”整个链路从写代码到部署上线只花了不到二十分钟。让我意外的是整个过程里我几乎没有碰过“基础设施”这四个字不用买服务器不用配 GPU 驱动不用自己搭网关甚至连数据库和缓存都是平台顺手提供的。放在两年前这条路上光是环境就够折腾一整天的。所以当大家都在聊模型效果、提示词怎么调的时候我更想聊聊另一件事Cloudflare 到底给 AI 开发者配了一把什么样的新钥匙是怎么把“上线”这件麻烦事变得像写代码一样自然的。这篇文章会围绕我最近做的一个文档问答小服务展开把里面的完整链路拆开讲清楚为什么最终选了 Cloudflare、几个核心组件分别是干什么的、从零到部署的具体操作步骤以及我在实操中踩过的坑。无论你是刚开始接触 AI 应用开发还是已经会调模型 API 但被部署流程拖过后腿这篇内容都可以直接当作业来抄。1. 为什么是 CloudflareAI 应用上线的路径变了1.1 传统部署流程的四道坎先回忆一下传统 AI 应用上线要过的路。第一步就够劝退的你得先有一台带 GPU 的机器或者至少一台配置合理的云服务器。拿到机器之后装 CUDA、配 Python 环境、部署模型推理服务每一步都可能因为版本不对、驱动不兼容而磨掉好几个小时。模型好不容易跑起来了后面还有更琐碎的事——你得写后端 API 接口把模型包装成 HTTP 服务得设计数据库存用户数据得做身份鉴权避免接口被刷还得处理日志、监控、报警。我把这总结成四道坎模型部署难GPU 驱动、显存管理、推理框架每个环节都是独立的知识域。后端链路多模型服务只是入口背后还有数据库、缓存、对象存储、消息队列。运维成本重扩容、回滚、日志、配额控制都是 7x24 小时的事。全球访问难服务部署在单一区域跨地域用户访问延迟高体验不稳定。对于大公司来说这些问题可以靠专门的平台工程团队解决。但对个人开发者、独立产品、小团队而言每一道坎都可能让项目的上线时间从“一个周末”变成“一个月”。1.2 新钥匙的形态平台代替基础设施Cloudflare 的思路和传统做法完全不同。它不是给你一台服务器让你自己折腾而是把“运行环境、模型、存储、网关”全部封装成平台能力你只需要写业务逻辑。我在这个问答 Demo 里的体验是这样的模型调用被封装成一个函数直接传参数就能拿到结果数据库、键值缓存、对象存储都是声明式绑定在配置文件里写几行就能用部署只需要一条命令平台自动把代码分发到全球节点。整个过程里我还真没手动配置过一台虚拟机。可以这样理解传统方案是给你一堆食材和一口锅你自己生火、自己调味Cloudflare 的模式是给你一个配好所有工具和调料的厨房你只需要按菜谱把菜下锅。对于大多数中小型 AI 应用来说后者要务实得多。传统 AI 应用上线流程Cloudflare 模式准备服务器与 GPU 环境开通 Workers AI模型即服务配置 Python/Node 运行环境直接部署 Workers 脚本自建 API 框架与鉴权平台内置路由、HTTPS 与安全手动搭建数据库与缓存D1、KV、R2 开箱即用自建网关做限流与监控AI Gateway 统一处理调用2. 新钥匙的核心组件拆解2.1 Workers AI把模型调用变成函数调用Cloudflare 这套体系里最先和 AI 开发者打交道的是 Workers AI。它打通了 Workers 运行时和大模型推理服务你不需要关心模型跑在哪台机器上、显存够不够只要在代码里调用env.AI.run就能拿到结果。我们实际用的模型是 Llama 3.1 8B Instruct。调用方式非常直接以消息数组作为输入const res await env.AI.run(cf/meta/llama-3.1-8b-instruct, { messages: [ { role: system, content: 你是一个只回复中文的简洁助手。 }, { role: user, content: 帮我总结这段话。 } ] }); console.log(res.response); // 模型生成的文本如果你用过 OpenAI 或其它大模型 API会发现这套交互很熟悉几乎零学习成本。Workers AI 支持文本生成、Embedding 向量化、图像模型等能力能满足问答、摘要、RAG 检索、内容分类等常见场景。一个关键点在于模型本身由平台维护升级。你不需要关心底层基础设施也不用在代码里维护模型版本分身后续要切换模型时只需要改模型标识符。2.2 Workers 运行时写代码的“函数即服务”体验真正承载业务逻辑的是 Workers 运行时。它本质是一个无服务器函数平台支持 JavaScript、TypeScript、WebAssembly你写的 Worker 会被分发到全球边缘节点上执行用户的请求会就近路由到离他最近的节点。对我个人来说Workers 最大的价值是“简单直接”。你不需要知道进程怎么管理、不需要配置 Nginx、不需要写 systemd 服务文件代码写完之后一个wrangler deploy整个服务就上线了。它的收费模式也比较适合 AI 应用起步阶段。免费档已经能覆盖相当一部分个人项目和原型。付费档主要用于突破 CPU 时长和请求数的限制起步价不高。这个体系天然适合从零到一验证想法之后再根据业务规模调整。2.3 D1、KV、R2AI 应用的数据三件套AI 应用不是只调用模型就够了聊天记录、用户配置、文件资料都需要存储。Cloudflare 在这个平台上提供了三个不同特性的存储它们的分工非常清晰KV全球分布式键值存储读延迟低适合缓存和配置类数据。但注意它是最终一致性刚写入的数据在极短时间内可能读到旧值。D1基于 SQLite 的关系型数据库支持标准 SQL 查询适合用户表、对话记录、结构化数据。R2S3 兼容的对象存储适合存文档、图片、音视频等大文件最大的特点是出站流量不收费这对高流量场景是巨大的成本优势。在这套体系里还有一个常被忽略的服务Vectorize它是平台上的向量数据库专门用于存储 Embedding 向量做相似度检索正好可以和 Workers AI 的 Embedding 模型配合实现 RAG。在这个问答 Demo 里我的分工是文档文件放 R2问答缓存放 KV对话日志写 D1向量索引未来会放到 Vectorize。每种数据放在最合适的存储里这是这套架构比较舒适的地方。2.4 AI Gateway给模型调用加上管理能力调用模型的成本、稳定性、观测性是上线后必须面对的问题。AI Gateway 在模型 API 前面提供了一层管理能力缓存重复请求、设置限流、自动重试、记录调用日志。我在项目中就发现AI 模型的调用频率其实很不均匀。热点问题被反复问同一段内容生成的答案基本是固定模板。AI Gateway 开启缓存后完全相同的请求会直接命中缓存不再消耗模型计算资源这在高峰期能省不少成本。AI Gateway 还能统一记录 prompt 和响应时间排查问题的时候特别省心。比如用户反馈“AI 回答变慢了”我可以直接按时间线看是哪一次调用耗时异常、是模型问题还是网络问题。这种可观测性在传统方案里往往要额外搭一整套监控系统才能实现。3. 零到上线一个 AI 应用的完整实操3.1 项目定调只做一个足够小的文档问答 API实操部分我以刚完成的文档问答服务为例来说明。这个服务的需求很简单用户上传一段文本和一个问题AI 基于这段文本内容进行回答。为什么选这个场景因为它麻雀虽小但五脏俱全——要用到大模型推理、需要缓存历史调用、需要记录结构化日志、未来可能扩展文件存储。一个足够小的闭环既能跑通流程又能覆盖所有关键组件。我把它拆成三个子任务模型调用、结果缓存、对话日志。模型调用使用 Workers AI 的 Llama 3.1 8B输入是文档加问题。结果缓存相同文档和问题组合在短时间内命中缓存直接返回。对话日志每次问答都写入 D1 数据库方便后续分析和数据标注。3.2 环境准备装好 Wrangler 并完成认证上路的起点是安装命令行工具。Cloudflare 官方提供了 Wrangler CLI它是整个部署流程的核心控制端。许多新手会在这里踩到网络或权限相关的坑所以我把完整步骤写在这里。# 安装 Wrangler CLI npm install -g wrangler # 登录 Cloudflare 账号 wrangler login # 初始化一个 Worker 项目 wrangler init ai-demo cd ai-demo初始化完成后项目里会自动生成wrangler.toml配置文件和一个src/index.js入口文件。这一步的重点在于wrangler login必须在浏览器里完成授权授权成功后本地会保存身份凭据。如果这一步没成功后面的deploy都会报认证失败。3.3 核心实现写 Workers AI 调用代码这个 Demo 的入口代码非常短核心逻辑就是接收 POST 请求、解析文档和问题、调用模型、返回结果。我先把最简单的版本跑通export default { async fetch(request, env) { const url new URL(request.url); if (url.pathname /api/ask request.method POST) { const { document, question } await request.json(); const messages [ { role: system, content: 你是一个严谨的AI助手请只根据用户提供的文档内容回答问题不要编造信息。 }, { role: user, content: 文档内容${document}\n\n用户问题${question} } ]; const result await env.AI.run( cf/meta/llama-3.1-8b-instruct, { messages } ); return Response.json({ answer: result.response, timestamp: Date.now() }); } return new Response(Not Found, { status: 404 }); } };为了让 Worker 能识别env.AI这个绑定还需要在wrangler.toml里启用 AI 绑定name ai-demo main src/index.js compatibility_date 2025-01-20 [ai] binding AI写完配置直接部署wrangler deploy部署完成后命令行会返回一个*.workers.dev的域名。用 curl 或者 Postman 发一个 POST 请求就能看到模型返回的答案。我第一次跑通的时候整个流程不到五分钟那种“只管写代码不管服务器”的感觉确实很爽。3.4 挂上数据D1、KV、R2 的绑定步骤模型调用跑通之后我开始补数据层。首先是 KV用来做缓存。创建 KV namespace 的命令是wrangler kv namespace create DOCS执行后命令行会输出一个id把它写进wrangler.toml[[kv_namespaces]] binding DOCS id xxxxxxxx其次是 D1 数据库。创建命令wrangler d1 create ai-demo-db同样拿到database_id后写进配置[[d1_databases]] binding DB database_name ai-demo-db database_id yyyyyyyy然后建一张问答日志表CREATE TABLE IF NOT EXISTS qa_log ( id INTEGER PRIMARY KEY AUTOINCREMENT, question TEXT, answer TEXT, created_at INTEGER );执行建表语句wrangler d1 execute ai-demo-db --fileschema.sql最后把缓存和日志逻辑加到 Worker 里。这里我特别想强调一个设计原则为什么答案缓存要用 KV 而不是 D1因为 KV 是全局分布式存储读路径短、延迟低适合高频读取和过期淘汰。D1 的强项是 SQL 查询适合做结构化分析不适合扛热点缓存这种场景。两者各司其职不要混用。改进后的代码片段async function askWithCache(env, document, question) { const cacheKey ${document.slice(0, 64)}:${question}; // 1. 先查 KV 缓存 const cached await env.DOCS.get(cacheKey); if (cached) { return JSON.parse(cached); } // 2. 缓存未命中调用模型 const messages [ { role: system, content: 你是一个严谨的AI助手请只根据文档内容回答。 }, { role: user, content: 文档${document}\n\n问题${question} } ]; const result await env.AI.run(cf/meta/llama-3.1-8b-instruct, { messages }); const answer { answer: result.response, timestamp: Date.now() }; // 3. 写入 KV1小时过期 await env.DOCS.put(cacheKey, JSON.stringify(answer), { expirationTtl: 3600 }); // 4. 异步写入 D1 日志 await env.DB.prepare( INSERT INTO qa_log (question, answer, created_at) VALUES (?, ?, ?) ).bind(question, result.response, Date.now()).run(); return answer; }这个版本其实已经可以交付给中小流量用户了。缓存层挡住了大量重复请求D1 记录全部调用日志模型服务被收敛到 KV 未命中时才触发成本和响应速度都在可控范围。3.5 前端托管与自定义域名最后一百米后端 API 上线后如果想让普通用户直接用还得有一个前页面。这一步我用的方案是 Cloudflare Pages。Pages 是面向静态网站和前端的托管平台直接连接 Git 仓库后自动构建部署自带 CDN。我在这里用的是 React 做了一个最简单的问答输入框。如果你不熟悉前端工程化也可以直接用纯 HTML 文件放在 Pages 里一样能跑。Pages 构建完成之后在项目设置里添加自定义域名比如ask.example.com平台会自动处理证书和 HTTPS 配置。到这一步“从写代码到部署上线”就真正闭环了写代码在本地上线在云端中间几乎没有任何手动运维动作。哪怕后续要增加更多模型、接入 RAG、做多租户也都是在这个框架上继续叠加。4. 实操避坑清单我在真实项目里踩过的坑4.1 首次请求慢模型冷启动被低估我最开始测试时发现第一次请求经常要等两三秒才能返回后面再请求就快很多。原因是在模型实例被唤醒时需要加载权重这就是冷启动。如果流量不大且间隔时间长每次请求都可能撞上冷启动。我的处理办法有两个一是在业务上接受这个延迟把应用设计成“先返回加载状态、再轮询结果”的模式二是利用平台监测面板观察模型所在区域尽量让部署区域和用户区域匹配。如果你做的是实时性要求极高的场景比如语音对话冷启动可能成为问题这时候更适合考虑专用的推理服务。4.2 绑定配置改了不生效我遇到过最无语的坑改了wrangler.toml里的 KV 绑定代码里也写了env.DOCS.get但本地调试一直报错DOCS is undefined。原因是修改配置之后没有重新部署也没有重启本地开发服务器。如果你的本地wrangler dev还在跑旧配置那么它仍然按旧代码和旧配置执行。正确流程是改配置文件后重启wrangler dev部署线上时重新执行wrangler deploy。排查这类问题时用wrangler tail看实时日志可以清楚地看到环境变量是否注入。4.3 免费额度边缘反复横跳我对免费的额度边界做了实测发现很多细节和直觉不一致Workers 请求数、CPU 时长、KV 读写次数、D1 读行数、R2 流出量、AI 模型调用量各自独立计算。其中最容易被忽视的是 CPU 时长模型生成 token 多时Worker 的 CPU 时间会快速增长可能在请求数远没到上限时就触发额度限制。建议在任何模型调用里都显式限制输出长度比如设置max_tokens参数。AI Gateway 的限流功能也可以提前设好避免某个用户刷接口把额度耗尽。4.4 D1 和 KV 不是万能存储D1 本质是一个分布式 SQLite它在底层是单库文件写并发和复杂事务能力有天然的边界。如果你把它当成 MySQL 来设计高并发写入业务很快会遇到瓶颈。KV 则是最终一致性刚写入的数据立即读可能读不到所以不适合记账、库存这类需要强一致性的场景。在这套体系里正确的心态是KV 管缓存和配置D1 管结构化业务数据R2 管文件和静态资源Vectorize 管向量索引。每种数据用对工具才不会在某个场景里纠结为什么它表现不好。4.5 排错工具日志、CID 与慢请求追踪市面上的无服务器平台都有“logs 难查”的共性Cloudflare 用wrangler tail解决了很大一部分问题。直接执行wrangler tail ai-demo就能把线上请求的实时日志、console.log输出、异常堆栈全部推到终端。如果某次请求出了问题还可以把响应头里的cf-ray请求 ID 记录下来到平台控制台里按请求 ID 检索很快就能定位那次请求经过了哪些节点、耗时多少、在哪一步抛错。5. 什么时候用它什么时候别用它5.1 适用边界Cloudflare 这套方案不是万能的。经过这个项目之后我给自己划了一条清晰的使用边界适合原型验证、MVP、活动页、中小流量 API、全球用户访问的产品、不想投入运维精力的独立开发者。不适合需要超低延迟且持续高并发的生成任务、强一致性要求极高的金融类系统、必须绑定特定 GPU 或专用硬件的推理任务、超大规模模型在自有机房部署的合规诉求。如果你的核心诉求是“快速做出一个能被人访问的 AI 服务”那 Cloudflare 基本是当前最顺滑的选择之一。如果你的核心诉求是“极致控制底层的每一毫秒”那还是得回到私有集群方案。5.2 成本模型和替代选型成本上这套方案在起步阶段几乎是零成本。个人项目完全可以在免费档内运行。日均几千次请求的场景托管方案比自建 GPU 服务器便宜得多。但如果你进入了一个每秒钟都有几十个并发生成请求的阶段长期算下来自建推理集群可能会有成本优势。替代选型方面如果你已经有比较成熟的容器化运维能力完全可以继续用传统云服务器加自建网关的方式。但如果你是从零开始起项目我强烈建议先从这里入手用最低的试错成本把业务逻辑跑通再根据实际情况迁移或扩容。最后再分享一个我实际操作中的体会使用这类平台时不要在一开始就急着把所有组件全部挂上。先跑通 Workers AI Worker 的最小链路确认模型能正常返回再逐步增加 KV 缓存、D1 日志、AI Gateway、Vectorize。每加一个依赖排错范围就扩大一圈先把一把钥匙用熟再去开下一扇门。这套思路能让你的 AI 应用从写代码到部署上线都保持清爽。