端侧计算扩展架构
解决什么问题
设计要服务海量用户（尤其带慷慨免费层）的 web 产品/AI 产品时，选择计算架构：云端 VM per user 还是端侧计算？
核心内容
核心判断：历史上唯一 scale 到 10 亿用户的 web 计算模型是端侧计算。 Figma 打开文档时没有云 VM 在帮你渲染，用的是你自己的 CPU 和内存；Google Docs 同理。
云 VM per user 模型（Cloud 9 以来的 Cloud IDE、多数 text-to-app 工具）的结构性缺陷：
- 供给上限：全球可租的 VM 不到 1 亿台，但终端设备有 10 亿+。
- 延迟与可靠性：云端环境启动要几分钟、经常卡死要联系客服；端侧毫秒级启动。
- 免费层不可持续：服务器免费层必然被滥用（挖矿、DDoS 跳板），最终只能 nerf 回收；端侧计算的免费层边际成本为零，可以无限慷慨。
- 成本：Bolt 的构建、部署预览全在用户浏览器里完成，"对我们零成本"。
Bolt 的具体实现： WebContainer——用 WebAssembly 写的、可在浏览器内百毫秒级启动、能跑 Node.js/npm 完整工具链的操作系统，花了 5-7 年建成。AI agent 与这个浏览器内 OS 双向通信（写代码、跑 dev server、读报错），是 Bolt 比同类（当时的 Lovable/v0/Replit）更快更可靠的根本原因。
推论： 如果你的产品要靠免费层病毒式增长 + 海量并发，先检查计算发生在哪一端。"最好的体验 = 零延迟 + 趋零成本 + 免费层可持续"往往只有端侧模型同时满足。
适用边界
- 适用于计算可以下放到终端的场景（开发环境、文档、设计工具）；模型推理本身（LLM inference）当时仍必须在云端，Bolt 的 GPU 供给同样被 Anthropic 卡过脖子。
- 大规模已有代码库的重型工作负载不适合浏览器内环境。
关键引述 · 原话
"There's not even a 100 million VMs to rent on the planet. But there are a billion devices that you can run this stuff on." — Eric Simons
"That's the only model that's ever scaled to a billion users." — Eric Simons（指 Figma/Google Docs 的端侧计算）
关联卡片
- 同源卡片：deep-tech-platform-bet-with-low-burn（WebContainer 正是那个七年赌注） - 与 Figma 的 WebGL 渲染引擎故事同构（Dylan Field/Evan Wallace 的最初 pitch）
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast（2019–2026）。本站为个人学习用途的二次创作，与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2