All articles

· Elliot Hu

赛博菩萨的账本：Cloudflare 为什么敢把 Workers 卖到五美元？

赛博菩萨的账本：Cloudflare 为什么敢把 Workers 卖到五美元？ cover

在这个万物 Subscription、路边的狗来了都得收你 20 刀的今天，Cloudflare Workers 依旧坚持极其慷慨的免费额度和 $5 的超低价格，很多人称之为“赛博菩萨”。我觉得这个外号除了感谢，还藏着一点朴素的疑问：给我这么多，你到底图什么？

Workers 免费方案每天提供十万次请求；每月五美元起的付费方案，包含一千万次请求和三千万 CPU 毫秒。对于一个刚上线的小工具、一段接口，或者公司内部没多少人访问的应用，这是一个很难挑剔的起点。

再把股票行情打开，反差更明显。2026 年 9 月 30 日，Cloudflare 的总市值约为 1,236.6 亿美元。门口写着五美元，公司却被挂上了千亿美元的价签。（BTW. 我个人长期看好 CF 的股票，在 150 多的价格买入并长期持有）

价格表上的“便宜”，与股票市场上的“贵”，本来就不是同一件事。前者取决于它怎样组织计算资源，后者取决于投资人相信这套平台以后能承接多少生意。

这篇文章想把中间那段容易被略过的工程讲清楚：为什么同样是执行代码，Cloudflare 能把入口价格做得这么低？用户真把额度用满，它还撑不撑得住？

先把卖的东西认清楚，再拿计算器。

01｜五美元只是开始

设想你周末做了一个活动报名工具。

最开始只有一个页面和一个提交接口，Worker 收到表单，把结果返回去。过几天，报名记录需要保存，于是要数据库；参加者要上传照片，于是要对象存储；报名成功之后还要发通知，最好别让用户一直等，于是又要队列。

等这个工具真的有人用了，你会关心部署有没有成功、某次请求为什么出错、更新之后能不能回滚。此前看起来只有几十行的程序，渐渐变成一个完整应用。

把这个过程放回 Cloudflare 的产品目录，就能看出 Workers Platform 的轮廓。它已经不只是一个执行函数的地方，而是一组围绕应用运行组织起来的服务。（下表是为了理解业务所做的分组，并不是公司的财务分部）

应用需要做什么对应的产品或能力
接收请求、执行代码、发布应用Workers、Static Assets、Pages、构建与部署
保存文件和业务数据R2、KV、D1
管理状态、消息和长任务Durable Objects、Queues、Workflows、Cron
接入模型、检索知识Workers AI、AI Gateway、Vectorize、AI Search
运行更完整的程序或浏览器Containers、Browser Run
托管其他人的代码、维护生产环境Workers for Platforms、日志、可观测性、控制 API

这里当然有不同的计费方式。数据库操作、对象存储、GPU 推理与 CPU 执行，成本结构也不同。五美元不是整张产品目录的无限配额。

一个开发者第一次付款，也许只付了五美元。但平台真正争取的，是这个应用接下来要在哪里保存数据、执行任务、处理流量，以及从一个周末项目长成一门生意之后，继续使用谁的基础设施。

所以，拿“开发者数量乘以五美元”估算这块业务，会漏掉大部分故事。那算的是入门账户，不是一个应用与平台之间可能持续多年的关系。

Workers 是入口；入口后面还有存储、状态、队列、AI 和运维整套平台。

02｜这套平台，单独拆出来值多少钱？

截至 2026 年 9 月 30 日，Cloudflare 的总市值约为 1,236.6 亿美元。公司给出的全年收入指引中点为 28.67 亿美元，相当于市场按约 43.1 倍年度收入 给它定价。第二季度，公司毛利率为 71.8%，调整后营业利润率为 13.8%，按美国会计准则计算仍然净亏损。高估值显然不只是在购买当期利润。

拿这个定价做参照：假设 Workers Platform 独立后的年收入为 5 亿美元，承担基础设施等成本后，仍能保持接近母公司的利润率，并获得相同的收入估值倍数，那么它对应的年毛利约为 3.59 亿美元，调整后营业利润约为 6,900 万美元，估值则是：

5 亿美元年收入×43.1=215.5 亿美元5\text{ 亿美元年收入}\times43.1 =\boxed{215.5\text{ 亿美元}}
把假设收入放宽到 3 亿至 7 亿美元，对应的估值约为 130 亿至 300 亿美元。这里沿用的是母公司当前已经包含增长预期的市场定价，不是按照成熟企业的利润倍数估算。

这些收入是假设，不是已披露业绩。 Cloudflare 没有单列 Workers 的收入和利润，因此目前只能做情景估值，不能把两百亿美元写成确定的拆分价格。但它给出了一个清楚的尺度：在上述条件下，这是一块百亿美元级的平台业务。

接下来更值得拆解的是，它为什么能把计算资源卖得那么便宜——用户真把额度用满，背后的硬件究竟花了多少钱？

03｜三千万毫秒，原来只有八小时二十分

这笔账最容易算错的地方，是看到“一千万次请求”，脑子里就自动出现了一台整月忙个不停的服务器。

Workers Standard 的基础计算额度，是每月一千万次请求、三千万 CPU 毫秒。后者换算成 CPU 真正执行的时间：

30,000,000 毫秒=30,000 秒=8.3333 小时30,000,000\text{ 毫秒} =30,000\text{ 秒} =8.3333\text{ 小时}
也就是八小时二十分。

如果请求数和 CPU 配额恰好同时用满，平均每次请求消耗：

30,000,000÷10,000,000=3 毫秒30,000,000\div10,000,000=3\text{ 毫秒}
再把一千万次请求均匀摊到三十天里，平均每秒约 3.86 次。八小时二十分，只相当于一个核心整月时间的约 1.16%。

真实流量不会这么均匀，平台当然需要为峰值准备容量。但先分清两件事：用户看到的是一千万次请求；实际计入账单的 CPU 执行时间，合计只有八小时二十分。

Cloudflare 在 2024 年公布的第十二代服务器设计，使用单路 AMD EPYC 9684X，拥有 96 个物理核心，配备 384GB 内存、两块 7.68TB NVMe 固态硬盘和双口 25GbE 网络接口。官方文章披露，在约 25℃环境下，整机功耗约为 600W。它可以作为一个计算参照，但不能代表 2026 年整个现网的统一配置。

Cloudflare 的真实采购价、长期利用率和内部折旧政策，我们不知道。这里采用合理的假设：

参数本文采用值性质
整机采购价20,000 美元演算假设
物理核心数96公开硬件规格
折旧周期4 年演算假设，残值为零
长期平均 CPU 利用率50%演算假设
整机功耗600W采用公开值作为固定模型输入
PUE1.3演算假设
电价0.10 美元／kWh演算假设

按照每年 365 天，四年共有 35,040 小时。96 个核心、50% 平均利用率，四年可以交付：

35,040×96×50%=1,681,920 有效核时35,040\times96\times50\% =1,681,920\text{ 有效核时}
把整机两万美元的采购成本摊进去，再取出用户消耗的 8.3333 核时：
20,0001,681,920×8.3333≈0.09909 美元\frac{20,000}{1,681,920}\times8.3333 \approx0.09909\text{ 美元}
*约十美分。*

再加电费。600W 乘以 PUE 1.3，再乘每千瓦时 0.10 美元，整机每小时设施用电成本为 0.078 美元。96 核在 50%
利用率下，每小时交付 48 个有效核时，所以：

0.07848×8.3333≈0.01354 美元\frac{0.078}{48}\times8.3333 \approx0.01354\text{ 美元}
硬件摊销加电费：
0.09909+0.01354≈0.11263 美元0.09909+0.01354 \approx\boxed{0.11263\text{ 美元}}
*大约十一美分。*

为了避免结果只是碰巧挑中了一组好看的参数，再把条件拉开一些：

整机价格、折旧周期与利用率CPU 额度对应的硬件摊销加上模型电费
15,000 美元、4 年、70%0.053 美元0.063 美元
20,000 美元、4 年、50%0.099 美元0.113 美元
30,000 美元、3 年、20%0.495 美元0.529 美元

这些情景不是实际成本的上下界。它们说明的是，在一组并不完全相同的参数下，用满这份 CPU 配额，分摊到的硬件与用电仍然可能只有几美分到几十美分。

甚至从 Cloudflare 自己的边际定价看，这件事也没那么神秘。超过基础额度后，CPU 每百万毫秒收费 0.02 美元，折合每核时 0.072 美元。三千万 CPU 毫秒按这个费率计算，也只有 0.60 美元。五美元本来就不是一张只卖 CPU 时间的账单。

不过，先别急着得出 CF “成本十一美分，售价五美元”的结论。前面算的只是客户账单上那部分 CPU 时间的硬件与电费，还没算请求路径上的其它开销。

04｜十一美分之外，还有什么？

用户被计量的 CPU 时间，不等于整个系统为他消耗的所有 CPU 时间。

请求进入平台之后，还要经过协议处理、路由、调度、计量等环节。官方对 Worker CPU 时间的定义围绕代码执行展开，网络、数据库等等待不计入这部分时间。不能拿客户账单上的计量值，直接替代全平台的资源消耗。

假设每次请求另有一毫秒没有包含在客户计量里的 CPU 开销，一千万次请求就会额外增加 2.7778 核时。总量从 8.3333 核时变成 11.1111 核时，基准模型中的硬件与电费，也就从约 0.113 美元增加到 0.150 美元。

这一毫秒是示例，不是 Cloudflare 的实测数据。

网络差异会更大。同样是一千万次响应，平均每次 10KB，按十进制单位计算约为 100GB；平均每次 1MB，就变成约 10TB。光看 CPU 配额，你不知道它搬走了多少数据，也不知道连接保持了多久、内存里压着多少东西。

前面的硬件分摊还隐含着一个条件：机器的资源搭配相对合理。要是内存已经塞满，CPU 却闲着，就不能继续拿理论 CPU 产能摊成本。机房、网络设备、存储操作、安全、支持和研发，也都不会因为算出十一美分而消失。

因此，这笔账能够推翻的，只是一个直觉：“一千万次请求这么多，用户用满了，平台一定赔钱。”

它不能证明每个五美元账户都赚钱，更不能证明 Cloudflare 的完整服务成本只有十一美分。

还有一个容易被忽略的地方：便宜的 CPU 核时，并不是 Isolate 独有的本事。其他架构在足够高的利用率下，同样可以把单位计算成本压得很低。

关键在 足够高的利用率。

当平台承载的是成千上万个独立应用，其中很多一天没几个人访问，却又要求随时可用，资源就很容易花在代码没有执行的时候：环境还得留着，内存还得占着，下次请求来了还不能等太久。

Isolate 要解决的，正是这些零散却会积少成多的浪费：冷启动、驻留内存、进程固定开销和上下文切换。

因此，就算算上额外的周边 Infra、bandwidth、colo、storage、control plane 等的成本，按照保守估计这部分成本是计算成本的 3 倍，也就是：

$0.113×3≈$0.34\$0.113\times3\approx \$0.34
大约 34 美分。

所以最坏的情况：5 美元 Workers 套餐在 CPU 配额完全用满时，对应的基础设施成本粗估约 0.35 美元。成本率约 6.8%，毛利率约 93.2%。

05｜三毫秒的代码，隔离单位该有多大？

如果一个人每天只执行几次几毫秒的请求，还要为他单独保留一整套常驻环境，固定开销就会远大于业务本身。虚拟机和容器都会面对这个问题：业务很小，供养业务的环境未必小。

虚拟机提供完整的系统隔离，容器共享宿主机内核，并且可以容纳各自的进程与运行环境。这些设计都解决了真实问题。不能为了夸 Workers，就把其他平台描绘成“每来一个请求，重新开一台虚拟机”。实际系统会复用实例，也会做各种优化。Cloudflare 的差别，主要在于它进一步缩小了应用隔离的单位。

V8 Isolate 是具有独立状态的执行实例。一个 Isolate 里的对象不能直接拿到另一个 Isolate 里使用；宿主可以创建多个 Isolate，让不同 Isolate 在多个线程上运行，但同一个 Isolate 在同一时刻至多由一个线程进入执行。它不等于一个操作系统进程，也不等于一条专属线程。

这让平台可以在一个运行时进程里放入很多独立应用。Cloudflare 的文档给出的尺度，是一个运行时实例可以承载数百乃至数千个 Isolate。新增一个小应用，不必同时新增一整套独立进程环境。

省下来的首先是每个应用都要承担的固定开销，而不只是几毫秒启动时间。

可以写成一个简单的内存模型：

总内存=共享运行时+应用数量×每应用固定开销+应用实际数据总内存 = 共享运行时 + 应用数量\times每应用固定开销 + 应用实际数据
假设每个驻留应用的固定开销少了 20MB，一万个应用就相差约 200GB。这不是 Cloudflare 的实测数字，只是提醒我们：在多租户系统里，一个看起来不大的数字，后面可能有一个很大的乘数。

更麻烦的是，内存浪费会拖累 CPU 利用率。低频应用先把内存占满了，处理器即使还有余力，也接纳不了更多应用。减少驻留负担，才有机会把更多人的零碎请求拼到同一台机器上。

Workers 的 128MB 也不是每次请求都预留的一块内存，而是每个 Isolate 的内存上限；一个 Isolate 可以处理多个并发请求。把并发请求数量直接乘以 128MB，会把硬件需求算歪。

但“共享运行时”四个字还不够。究竟共享了什么？

V8 有一项很具体的优化，叫 Embedded Builtins。早期，一些内置函数的机器码包含对特定 Isolate 内部对象的地址引用，难以让不同执行环境共用。V8 后来引入了间接寻址：代码不再把某个 Isolate 的地址写死，而是通过指向当前 Isolate 根表的寄存器，加上偏移量，找到它要访问的对象。这样，公共机器码就可以嵌入二进制，并利用操作系统机制共享。

换句话说：Isolate 各自保留状态，但 builtins 的机器码可以在多个 Isolate 之间共享，不必每个环境各拷一份。

这项优化来自 V8，并不是 Cloudflare 独创，也能惠及其他 V8 运行时。

Cloudflare 在 workerd 的架构介绍中，又解释了另一项选择：把基础 API 尽量组织为可共享的原生实现，避免让每个 Isolate 都重新加载一套 JavaScript 基础实现；同时，让大量小服务在同一进程内运行，以减少进程固定成本和不必要的上下文切换。

独立进程也能共享部分只读代码页，所以准确的比较从来不是“别人完全不共享，Cloudflare 全部共享”。工程上的差别，藏在新增一个租户究竟多占多少内存、多做多少初始化、多经过几次切换里。

这些成本落在单个应用上可能不显眼，乘以平台上的应用数量，就足以改变价格表。

06｜程序在等，机器没必要陪着等

再看一种更常见的浪费。

假设一个接口总共用了 200 毫秒才返回，但真正执行代码只花了 3 毫秒，剩下都在等数据库和外部 API。用户确实等了 200 毫秒，CPU 却没有忙那么久。

异步执行允许运行时在等待期间处理其他请求。Workers 的同一个实例，也可以在等待异步操作时继续接收和处理其他请求。

这不是 Cloudflare 发明的技巧。很多运行时都会异步 I/O。

它的好处在于，异步执行与轻量环境放到一起之后，平台既不用让 CPU 陪着等，也不必为每个等待中的小应用保留很重的独立环境。大量应用各自零碎的工作时间，才有机会拼成机器比较连续的忙碌时间。

冷启动的价值，也要放到这里看。

如果一个环境重建很慢，平台为了让下一次请求尽快响应，就更有动力一直养着温热实例。重建便宜一些，闲置环境回收之后，下次再叫起来的代价也就小一些。

Cloudflare 在 2020 年公开过一个具体做法：在适用场景中，收到 TLS 握手的 ClientHello、识别主机名后，就提前提示运行时加载相应 Worker，把一部分初始化工作藏进网络握手的等待里。代码还是要加载，只是不必等用户的完整请求已经到了，才开始准备。

所以，“启动快”不仅是体验指标。它还影响平台需要为尚未到来的请求，提前保留多少资源。

这里也别把话说过头：Isolate 不会让一段确实需要计算一分钟的程序，突然只算一毫秒。它主要减少的是驻留、等待和调度这些工作所需的额外负担。业务真正需要的计算，仍然要老老实实执行。

当然，很多人的代码住进同一个进程，读者自然会问：安全吗？

Cloudflare 并没有把所有租户放进一个大进程。它运行多个运行时进程，按信任程度分组，并在需要时使用额外进程隔离；外面再有 Linux namespaces、seccomp 等操作系统层的限制。其文档举的一个具体例子是，免费账户的代码不会与企业客户的代码被调度到同一个进程里。

这是一种分层安排。语言运行时承担高密度的应用隔离，进程和操作系统防护再提供额外边界。能共用的地方共用，不能共用的地方仍然要付出隔离成本。

开源 workerd 本身也不等于托管 Workers 的完整安全体系。Cloudflare 明确提醒，拿它运行可能恶意的代码，仍需部署适当的额外沙箱。

“用了 V8”是一个技术选择，离“具备 Cloudflare 的成本、安全和运营能力”，还隔着许多这样的安排。

07｜数据库为什么非得在另一个房间？

理解了 Isolate，再看 Cloudflare 的其他设计，会发现它反复在问一个问题：这一步真的需要跨出去吗？

比如两个服务，由不同团队维护，各自部署，各自更新。我们很容易顺着想：既然是两个服务，那就分别部署，再通过 HTTP 调用。

但团队边界和机器边界，其实没有那么必然的关系。

Cloudflare 的 Service Bindings 允许一个 Worker 调用另一个 Worker，不必绕过公开 HTTP 地址。默认情况下，两者可以运行在同一台服务器、同一线程上；启用不同的放置策略后，实际位置也可能变化。这样，独立发布可以保留，一部分不必要的网络往返却可以省掉。

数据库也是一样。

在 SQLite-backed Durable Objects 中，SQLite 以库的形式被调用，与负责这份状态的应用代码运行在同一进程、同一线程里。查询不必先打包成一个远程数据库请求，再等另一台机器回复。

不过，数据就在旁边，不代表写入可以不管可靠性。

这里有个很有意思的细节，叫 Output Gates。应用提交写入之后，可以继续准备返回给用户的内容；但“成功”真正发出去之前，平台要等相关写入获得持久化确认。也就是说，响应构造与持久化确认可以重叠，但确认完成前，成功结果不会先交给用户。

KV 则做了另一种取舍。它面向读多写少的使用方式，利用多层缓存组织读取，并接受最终一致性。一个刚写入的值，不承诺立即在所有位置同时可见，换来的是不必让每次操作都承担同样的全球协调成本。

这些设计的共同之处，并不是笼统地“让数据库更快”。它们把工作重新分了一遍：哪些数据由谁负责，哪些操作可以留在本地，哪些结果必须等确认，哪些场景可以接受稍后的传播。

少做一次没有必要的远程调用，往往比把那次调用优化得漂亮更划算。

08｜真正省钱的地方，还得靠工程化

如果一篇文章只讲到 V8、Rust、SQLite，读者很容易得到一种错觉：挑对几个技术名词，成本就降下来了。

实际工程要琐碎得多。

Cloudflare 在 2022 年介绍代理系统 Pingora 时，讲过一个很具体的问题。旧架构的连接池分散在不同工作进程里，一个请求落到某个进程，往往只能复用那个进程已有的连接。别的进程明明有现成连接，它也未必用得上。工作进程增加之后，连接池更分散，复用反而可能变差。

Pingora 改用能够更充分共享连接和数据的多线程架构，并减少了旧实现中的部分复制、分配和语言边界开销。Cloudflare 披露，在当时相同生产流量下，新系统的 CPU 使用量降低约 70%，内存使用量降低约 67%。这是特定新旧代理系统的比较，不是公司全部成本下降七成，更不是“换成 Rust，自动省七成”。

硬件选型也没有那么简单。Cloudflare 第十二代服务器的测试中，同为 96 核的两款处理器，因为三级缓存等差异，在相同 CPU 功率配置下出现了约 22.5% 的生产负载性能差距。表现更好的 Genoa-X 有 1,152MB L3 缓存，是另一款的三倍。这个结果属于其当时的混合生产负载，不能直接当成 Workers 单项测试。

核心并非越多越好，还得看它们有多少时间在等内存。线程并非越多越好，还得看连接和数据能不能合理共用。

网络也是这本账的一部分。Cloudflare 的多种服务建立在统一网络与平台能力之上，新产品因此有机会复用已有的流量入口、网络接入和运维能力，而不是每推出一个产品，都从头建设另一套系统。这是对其架构的经济性推论，不意味着每项产品都运行在每台服务器上。

直接互联也能改变流量成本。Cloudflare 曾公开解释，peering 可以减少部分流量对付费 transit 的依赖。但端口、线路、设备、机房和人员仍然要花钱，“直接互联”不能被翻译成“带宽免费”。

缓存则是在减少重复劳动。Tiered Cache 让下层缓存先向上层取内容，必要时才访问源站，避免大量边缘位置分别重复回源。最终内容还是要送给用户，但中间不必每次都从头跑一遍。

一段基础实现少加载一份，一次连接多复用几回，一条请求少搬一次数据，这些事情很难单独写成激动人心的商业故事。但发生足够多次之后，它们就会进入利润表。

这类工程的价值，也恰好在这里。它不靠某一个特别醒目的发明，而是有人真的愿意沿着请求经过的每一段路，问一句：这里为什么还要花这笔钱？

09｜成本低了，为什么愿意让用户也便宜？

到这里，我们解释了 Cloudflare 为什么有能力把某些服务做得便宜。至于为什么愿意提供免费额度，那是另一项选择。

成本降下来之后，公司可以保持原价，也可以把其中一部分让给用户。后者的价值，要从更长的客户关系里看。

Cloudflare 对网站安全免费方案的公开解释中，既提到降低网络运营成本，也提到保护更多网站能够获得更丰富的攻击模式信息，帮助改善整体安全能力。这是它对网站安全免费层的解释，不能自动套到所有免费产品上。

开发者平台还有另一层很重要的逻辑：一个还没证明自己能成功的应用，最不愿意承担的，就是昂贵的开始。

有些项目只活一个周末，有些会服务几十个人，也有些后来真能长成公司。平台事先不知道哪一个会留下来。把试用和起步的门槛压低，就是让更多可能性先发生，再从其中成长起来的需求获得收入。

这不要求每个免费用户最终付费，也不要求每个五美元账户有完全一样的利润率。但它要求平台足够会算账：失败和沉寂的项目不能长期背着过重的资源成本，成功的项目则需要有足够完整的服务去承接。

因此，前面的技术与后面的商业，在这里接上了。

轻量执行让长尾应用更容易被服务，完整平台给应用长大之后留下了空间。资本市场买的，是这件事可能发生很多次。

它有可能高估发生的数量，也有可能高估平台最终留住的份额。但即使把那些乐观预期先放到一边，五美元背后的工程也已经值得认真研究。

10｜我们想带回来的，是这部分东西

写到这里，才轮到我们的项目：open-compute 是一个可自托管的 Cloudflare Workers Platform 兼容平台。更直接地说，我们想让这套开发方式，也能运行在用户自己的机器上。

这件事的起点，显然不应该是“替用户省下五美元”。

适合公有云的应用，完全可以继续使用 Cloudflare。真正值得做另一种选择的，是部署位置、数据控制和基础设施所有权有明确要求的时候。比如一个团队需要在自己的内网运行应用，或者希望把软件连同运行环境一起交付，而不是把所有依赖都留在外部服务上。

这些情况下，问题就变成：能不能保留 Workers 的开发体验，而不必换一套编程模型、重接一遍存储和任务系统？

Cloudflare 已经开源了 workerd。这给出了很好的运行时基础，也应该被明确记在 Cloudflare 的贡献里。我们没有重新发明 JavaScript 引擎。

但运行时能执行代码，不等于一个平台已经准备好了。部署怎么更新，路由怎么找到正确版本，状态归谁管理，任务失败怎么恢复，用户如何查看和操作这些资源，仍然需要有人把它们组织起来。

open-compute 做的是这部分工作。

Rust 编写的 ocd 管理入口、控制 API、调度和运行时生命周期；Worker 代码交给固定并经过校验的 workerd 分支执行；SQLite 管理实例的本地权威状态，对象内容默认使用本地存储，也可以选用 S3 兼容存储。

我们把它组织成一个交付文件、一个共享守护进程，以及明确隔离的实例配置和数据目录，不要求用户先准备 Kubernetes、Redis、独立数据库和服务网格。这里的“一个文件”指交付方式，底层仍会有受管理的 workerd 子进程；用户省掉的是一堆需要分别安装、配置和照看的服务。

这与前面那些技术选择，其实是同一个方向：在目标明确的情况下，少承担一些不需要的复杂度。

一个单机部署，不一定需要先拥有分布式控制平面；本地状态，也不一定要为了符合某张流行的架构图，先经过一趟网络。

当然，这种选择有边界。open-compute 不提供 Cloudflare 的全球边缘网络，也不是一个多副本高可用集群。主机安全、出站网络限制、备份和运行责任，仍然需要由部署者安排。把部署放回自己的手里，也意味着把相应的责任接回来。

兼容性则要靠测试说明，而不是靠名字。当前仓库公开的验证矩阵跟踪 2,256 个稳定 API 成员与重载，对 Workers、Cache、KV、D1、R2、Durable Objects、Queues、Vectorize、AI Search 和 Observability 这十个产品面开展与真实 Cloudflare 的逐请求对照。支持范围和单节点差异都需要按文档理解，这些记录并不意味着托管平台的每一个行为细节已经完全相同。

我们没有把一个百亿美元业务复制进二进制文件。客户、品牌、全球网络和运营能力，当然不能这样复制。

我们想留下来的，是其中可以被写成软件、被检验、被复用的那部分：轻量的执行环境，熟悉的接口，以及足以让应用持续运行的平台能力。

回头再看五美元，它其实是一个很好的入口。顺着这个价格往下找，会遇到 CPU 时间、内存、寄存器、连接池，也会遇到数据该放在哪里、系统应该承诺什么。那些看起来遥远的架构选择，最后真的会变成普通开发者账单上的一个小数字。

“赛博菩萨”可以继续叫。只是在这个称号背后，我更愿意把实现细节摊开，看看这份价格表是怎么撑起来的。

我们的那份实现，放在这里：

https://github.com/elliothux/open-compute

open-compute 采用 Apache-2.0 开源许可，打包的 workerd 分支遵循适用的上游许可。欢迎 Star、提交 Issue 和贡献 PR。

参考资料