I am building a cloud — David Crawshaw 关于 exe.dev 的个人宣言

David Crawshaw · Original

背景

作者 David Crawshaw —— Tailscale 联合创始人，Go 编译器老贡献者，sqlite-in-go 作者。这篇博客是 2026-04-22 exe.dev 融资官宣日的个人版（相对于公司版的”正式安全宣言”），写他为什么在一家运转很好的公司之外又启动一家新公司、这朵云为什么需要存在。

全文立意可以压成两句：

现有 cloud 抽象层本身是错的形状——不是 UX 问题，不是价格问题，是 VM / 盘 / 网 / API 的原语就错了
Agent 时代是重做这一层的时间窗——软件总量爆炸 + agent 也要消费 infra + agent 浪费 context 在 contort API 上

四段挑读

1. VM 抽象的形状错了

VMs are the wrong shape because they are tied to CPU/memory resources. I want to buy some CPUs, memory, and disk, and then run VMs on it. A Linux VM is a process running in another Linux’s cgroup, I should be able to run as many as I like on the computer I have.

AWS / GCP 把计费与调度单位钉在 “一个 VM = 一份 vCPU + 一份 RAM” 上，用户视角看 VM 本该只是 host 上一个 cgroup 里的进程。你买一台机器、想跑几个跑几个。现有云把 hypervisor 的资源切片逻辑暴露成商业模型，想做”一堆轻量小 VM”就得走 gVisor / nested virt，自己叠反向代理、付嵌套虚拟化性能税。

这是抽象层批判不是价格批判——这两者的区分很重要：价格批判可以被 hyperscaler 打折对冲，抽象批判只能重做底层。

2. SSD 时代远程块存储的 10x IOPS 税

Random seeks on a hard drive take 10ms, so 1ms RTT for the Ethernet connection to remote storage is a fine price to pay… But then we all switched to SSD. Seek time went from 10 milliseconds to 20 microseconds… the IOPS overhead of remote systems went from 10% with hard drives to more than 10x with SSDs.

关键数据记住：

HDD：seek 10ms，网络 RTT 1ms，10% overhead → “存储计算分离”叙事成立
SSD：seek 20μs，网络 RTT 1ms（英雄级优化），10x-50x overhead
MacBook 本地 500k IOPS vs EC2 $10k/月才能堆到 200k IOPS

整个云行业”存算分离”叙事是建立在 HDD 性能曲线上的，硬件换代之后假设已经破了，抽象和计费却还停在原处。这段直接解释了 exe.dev 为什么坚持 local NVMe + 异步 off-box 复制——这是技术立场，不是 marketing。

3. K8s 是在猪身上涂高级口红

it is a product attempting to solve an impossible problem: make clouds portable and usable. It cannot be done. You cannot solve the fundamental problems with cloud abstractions by building new abstractions on top.

没走”K8s 太复杂”的廉价批评，做了个更狠的 meta 判断：K8s 项目组水平很高（“admittedly high quality lipstick”），但他们试图解决的问题不可解——在错的抽象之上叠新抽象，底层的错会向上传播，再精致的编排层只是糊胶带。

可迁移的思维武器：看到一个复杂的”兼容层 / 编排层 / abstraction layer”时，先不问它做得多好，而问它底下的原语对不对。原语错的编排层越精致越有害，因为它延长了错误原语的寿命。

这条和 mental-models 里”基础设施厂商的中立税”可以并列——那条讲的是上层向下征税（Snowflake vs Redshift），这条讲的是下层向上渗毒（EBS → K8s）。

4. 为什么是现在——Jevons 悖论 + agent context 是稀缺资源

Agents, by making it easiest to write code, means there will be a lot more software. Economists would call this an instance of Jevons paradox… Every percent of context window the agent spends thinking about how to contort classic clouds into working is context window is not using to solve your problem.

两个论证叠起来：

Jevons：agent 降低软件生产边际成本 → 软件总量爆炸 → 云从”偶尔烦”变成”结构性瓶颈”。用 19 世纪煤炭效率悖论（Jevons, 1865）套到 agent 写代码
Agent context 是经济资源：agent 的 context window 有限，花在”怎么把 AWS API contort 成能用”上的 token 就没花在解决用户问题上。infra 干净 → agent 聪明，这是个 infra 能力 × agent 能力的 dual optimization

这两句加起来打的是 agent 时代的时间窗——在此之前讲”重做云”只是情怀，现在有了 agent 这个需求放大器，“重做”才成立。

一个值得质疑的地方

exe.dev 首发功能清单（buy CPU/mem → run VMs + TLS/auth proxy + local NVMe 异步复制 + anycast）从技术栈看更像 Hetzner / OVH / bare-metal + 运维便利层，不是完全”重新发明云”。立意（racking servers, thinking through every layer）是新抽象，交付的第一版是 bare-metal-as-a-service 加糖。

他自己也写了”There is a lot more to build here”——所以这是路线图问题不是欺骗。但评估 exe.dev 作为”新物种”而不是”Tailscale-flavored Hetzner”，要看他后续 18-24 个月能不能把 VM 抽象、计费模型、disk snapshot UX 推到真正和 hyperscaler 不一样的形状。

判断锚点（未来复盘用）：

计费单位有没有真的脱离”每个 VM 一份费用”，变成 CPU/mem/disk 三维独立计费
本地 NVMe 的 snapshot + replication UX 做到什么程度
Anycast + 自建 DC 有没有推到规模（还是停在少数 region）
能不能吸走 Fly.io / Render / Hetzner 用户

可以串的记忆钩子

mental-models.md → “基础设施厂商的中立税”：上层向下征税 vs 本文的下层向上渗毒，镜像关系
mental-models.md → “模型公司基因障碍清单”：判断 AI infra 赛道会不会被上游吞——云 infra 里，hyperscaler 有没有基因/战略/时间障碍做 exe.dev 这种形状？值得单独跑一轮
Learning/Daily Digest/2026-03-07-latentspace-cursor-third-era-cloud-agents.md：Cursor 的 cloud agent 叙事和这里的 agent infra 叙事可以对照

作者语气与可信度

Crawshaw 不是第一次 infra 起家做 infra——Tailscale 本身就是重做 VPN/网络层的成功 case（绕过 IPsec / OpenVPN 的”错的抽象”，用 WireGuard + NAT traversal + identity 做新原语）。这篇博客可以读成 Tailscale 思路向上挪一层的尝试：Tailscale 重做了网络层抽象，exe.dev 想重做 compute + storage 抽象。从 pattern 看不是空喊。

文章风格是 builder 檄文，不是 BP。技术数字都可验证（SSD seek 20μs、EBS RTT、anycast 架构），没有夸大。可信度在作者背景 + 数据扎实两点上都站得住。