大家好，我是herosunly。985院校硕士毕业，现担任算法工程师一职，获得CSDN博客之星第一名，热衷于大模型算法的研究与应用。曾担任百度千帆大模型比赛、英特尔AI大赛评委，编写微软OpenAI考试认证指导手册，科大讯飞AI大学堂荣誉讲师。曾获得多项AI顶级比赛的Top名次，其中包括阿里云、科大讯飞比赛第一名，CCF、开放原子比赛二等奖。在技术创新领域拥有多项授权发明。曾辅导多位非科班出身的同学成功进入算法行业就业。希望和大家一起成长进步。
本文主要介绍了CubeSandbox 极速冷启动架构拆解，希望对学习和使用Agent的同学们有所帮助。
文章目录
- [1. 前言](#1. 前言)
- [2. 传统启动慢，慢在每次都重新构造世界](#2. 传统启动慢，慢在每次都重新构造世界)
- [3. 第一层：Template 把"开机到就绪"前移了](#3. 第一层：Template 把“开机到就绪”前移了)
- [4. 第二层：rootfs 不是复制出来的，而是元数据克隆出来的](#4. 第二层：rootfs 不是复制出来的，而是元数据克隆出来的)
- [5. 第三层：内存不是读回来的，而是映射出来的](#5. 第三层：内存不是读回来的，而是映射出来的)
- [6. 第四层：节点本地闭环，别让协调成本吃掉毫秒](#6. 第四层：节点本地闭环，别让协调成本吃掉毫秒)
- [7. 把账合起来：60ms 到底少做了什么](#7. 把账合起来：60ms 到底少做了什么)
- [8. 这套设计的边界](#8. 这套设计的边界)
- [9. 结尾：快在少启动一次](#9. 结尾：快在少启动一次)
- [10. 参考资料](#10. 参考资料)
1. 前言
最近刷 GitHub Trending时，注意到一个叫 CubeSandbox 的项目 star 涨得很快，就顺手研究了一下它的源码和架构。它是腾讯云开源的一套面向 AI Agent、代码执行等场景的 MicroVM 沙箱运行时，提供硬件级隔离。很多人第一次看到 CubeSandbox 的启动数据，都会先被一个数字抓住：可在 60ms 内创建具备完整服务能力的硬件隔离沙箱。
在已有裸金属基准报告中，腾讯云 BMI5 裸金属、2 vCPU / 2 GiB 沙箱规格下，基于 Template 创建沙箱的 1 并发平均耗时是 47.8 ms ，min 43.5 ms ，p95 57.4 ms ；10 并发时 avg 88.7 ms ，均摊 9.9 ms/个 。另一组 PVM 云服务器测试中，在 SA9.4XLARGE32、同样 2 vCPU / 2 GiB 沙箱规格下，1 并发平均耗时是 66.7 ms ，min 55.9 ms ，P95 78.2 ms。
也就是说，裸金属环境里的约 48ms 支撑了官方"60ms 内"的表述；PVM 环境里的约 67ms 则提醒我们，同一套架构落到不同硬件和虚拟化条件下，数字会有差异。具体结果还会受并发度、模板内容和沙箱负载影响。
但这篇文章不打算复述 benchmark。真正值得追问的不是"这个数字漂亮不漂亮"，而是：如果 CubeSandbox 交付的是一个具备硬件隔离能力的 MicroVM 沙箱，为什么它不需要像传统虚拟机那样经历完整开机？
答案不是"它把开机做得特别快"。更准确地说，CubeSandbox 把"开机"这件事从用户请求路径里搬走了。用户创建沙箱时，系统做的不是重新启动一个世界，而是从一个已经启动过、已经准备好的状态里恢复出一个新沙箱。
这就是本文的主线：60ms 不是启动快，而是不用重新启动。
2. 传统启动慢，慢在每次都重新构造世界
一个运行环境从无到有，通常不是一个动作，而是一串动作。
下面是传统沙箱从镜像准备到服务就绪的完整启动链路：
图1 传统沙箱从镜像准备到服务就绪的完整启动链路
如果每次创建沙箱都完整跑一遍这条链路，请求就必须同步等待很多成本：
| 阶段 | 请求路径上要等什么 |
|---|---|
| 镜像 / rootfs | 镜像层处理、挂载、可写层准备 |
| OS / runtime | 内核或运行时启动、初始化 |
| 应用 / Agent | 进程拉起、依赖加载、服务探活 |
| 内存状态 | 从空状态逐步建立运行时热状态 |
| 网络 / 资源 | 设备、代理通道、网络资源绑定 |
传统路径的问题不一定是某一步特别慢，而是每次都像重新装修一间房：地板、家具、电路、门锁都要在客人站门口时再来一遍。哪怕每一步都优化一点，整条链路仍然很难短到几十毫秒。
CubeSandbox 的思路反过来：不要在请求到来时装修房间。提前把房间装修好，冻结起来；请求到来时，只恢复一个已经可用的现场。
图2 传统启动链路与 CubeSandbox 基于模板快照恢复链路的对比
这条变化，是理解 CubeSandbox 冷启动的钥匙。
3. 第一层：Template 把"开机到就绪"前移了
CubeSandbox 的 Template 不应该被简单理解成"镜像缓存"。它更像一个已经启动到可服务状态的基线。
读 Template 这层时，最容易问错问题。如果把 Template 当成"拉镜像更快"的缓存，就会错过 CubeSandbox 真正改变的地方：它缓存的不是文件列表，而是一个已经跑到就绪点的运行现场。
可以把它拆成两个阶段看：
图3 CubeSandbox 将开机到就绪的成本前移到 Template 构建期
传统沙箱创建时要等待的很多动作，在 CubeSandbox 里已经前移到 Template 构建期：rootfs 准备、MicroVM 启动、基础进程拉起、服务探活、依赖和缓存预热。用户发起创建请求时，系统不再从零开机，而是从这个已经就绪的模板状态恢复。
这和 warm pool 不一样。
| 方案 | 直觉 | 代价 |
|---|---|---|
| Warm pool | 提前养着一批活 VM，来了请求就分配 | 常驻消耗 CPU / 内存，池子可能被打穿 |
| Template snapshot | 提前冻结一个可恢复状态，请求时激活 | 主要消耗存储，运行时再恢复 |
Warm pool 是"提前运行一批实例"。CubeSandbox 的 Template 更像"提前保存一个已经运行到位的状态"。这也是为什么它能在不常驻大量空闲 VM 的前提下，把请求期的启动链路压短。
从工程取舍上看，这一步不是把 warm pool 做轻一点，而是换了一种账本：少付常驻资源，多付模板构建和状态管理。
一句话总结这一层：CubeSandbox 不是在请求时开机，而是在构建期已经开过机；请求期只是恢复那个开过机的状态。
4. 第二层：rootfs 不是复制出来的，而是元数据克隆出来的
即使不用重新开机，每个沙箱也需要自己的文件系统视图。用户代码会写文件、装依赖、改缓存，不可能所有沙箱都直接写同一份 rootfs。
直觉上，给每个沙箱一份独立 rootfs，似乎就要复制一整份文件系统。但这会把大量文件内容拷贝重新塞回请求路径。
CubeSandbox 这里依赖的是文件系统级 CoW。模板 rootfs 可以通过 XFS reflink / FICLONE 生成沙箱自己的 rootfs 视图：
图4 通过 reflink / FICLONE 将模板 rootfs 克隆为沙箱 rootfs<\div>
这个动作的关键是：刚创建副本时，并不复制全部数据块，而是让新文件共享旧文件的底层 extent。只有某个沙箱真的写入某个文件块时，文件系统才为这个沙箱分裂出新的数据块。
用一个更直观的说法：刚创建时，多个沙箱共享同一份底稿；谁在自己的副本上改字，文件系统才为谁单独复印那一页。
这同时解释了两件事：创建 rootfs 很快，因为主要是元数据操作，不是逐字节复制文件内容。
图5 多个沙箱初始共享 rootfs 底层 extent，写入时再分裂私有数据块
这一层把"复制文件系统"的重活，变成了"共享基线 + 写时分裂"。
5. 第三层：内存不是读回来的，而是映射出来的
更反直觉的是内存。
如果一个沙箱规格是 2 GiB，很多人会自然以为：恢复它的内存快照，至少要把 2 GiB 数据读回内存。这样一来，几十毫秒的创建时间就很难解释。
第一次对着 47.8 ms 这个数往回推时，卡住的就是内存这一环：磁盘和 rootfs 的优化比较好想象，内存如果仍然按"全量读回"理解，后面的几十毫秒就永远对不上账。
CubeSandbox 走的是另一条路径。根据已有快照深潜文章的描述，CubeSandbox 的 VMM 在恢复时不会把整份内存镜像 read() 到一段匿名内存里，而是用类似下面的方式建立映射：
图6 内存快照通过 mmap 映射到 VMM 地址空间，而不是恢复时全量读回
mmap 的关键意义是：先建立"虚拟地址区间"和"快照文件偏移"的关系，而不是立刻把所有页读入物理内存。沙箱真正运行起来后，guest 访问到哪一页，内核才按需把那一页从文件页带进来。
再加上 MAP_PRIVATE 的 CoW 语义，内存页会自然分成三类：
| 页面状态 | Host 侧发生了什么 | 对冷启动的意义 |
|---|---|---|
| 从未访问 | 不建立实际私有物理页 | 不拖慢 ready |
| 只读访问 | 使用快照文件的 page cache | 多个沙箱可共享 |
| 写入 | CoW 成当前沙箱的私有匿名页 | 只为真实变化付费 |
这一层的核心是：ready 之前不需要把全部 guest RAM 都搬回来。大量页面可能还没被访问；只读页面可以共享；真正写过的页面才变成当前沙箱独占。
所以"恢复内存快照"在这里不是一次全量读盘，而是一次按需承诺：这片内存地址空间已经可以访问，但具体哪一页要加载、哪一页要分裂，交给后续真实访问来决定。
这条路径让冷启动延迟变短，但它不是魔法。第一次访问某些页面时仍会触发缺页；如果 workload 对启动后最初几毫秒的抖动极端敏感，可以选择 prefault 一类策略提前 fault in，但代价就是把部分内存加载成本重新拉回启动路径。
CubeSandbox 默认的取舍很明确：优先让沙箱尽快 ready，把不一定会发生的内存成本延后到真的访问时。
我们可以把这看成一种"延迟支付"设计，而不是单纯的内存优化。它的厉害之处在于，内核原本就有的 MAP_PRIVATE 语义，被放到了沙箱生命周期的关键位置上。
6. 第四层：节点本地闭环，别让协调成本吃掉毫秒
前面三层解决的是"少做重活"：不重新开机、不复制完整 rootfs、不全量读内存。但如果控制面路径很长，冷启动仍然会被协调成本吃掉。
一次创建请求可以简化成这样：
图7 一次创建请求的简化关键路径：中心侧选节点，节点内完成恢复与资源绑定
这里不需要把所有组件职责都展开。关键取舍是：中心侧尽量负责入口和调度，真正创建沙箱的动作尽量在节点本地闭环。Cubelet 在节点内协调 rootfs 克隆、VMM restore、网络资源绑定等动作，避免每个细节都绕回中心服务等待强协调。
这也是资源池化和节点本地闭环重要的原因。当前面把磁盘、内存成本都压下去之后，剩下的几毫秒很容易被"等远端服务、等全局锁、等设备创建"吃掉。要守住几十毫秒的 ready latency，控制路径也必须短。
这层不展开网络安全，只保留和冷启动相关的结论：60ms 级创建不仅要求数据面少搬东西，也要求控制面少绕路。
7. 把账合起来：60ms 到底少做了什么
如果只看结果，CubeSandbox 像是在几十毫秒里"启动"了一个 MicroVM 沙箱。但从架构账本看，它真正做的是把传统启动路径拆开，再把成本放到更合适的位置。
| 传统创建路径要同步做的事 | CubeSandbox 的处理 |
|---|---|
| 从镜像构造运行环境 | Template 构建期完成 |
| 从零启动 OS / Agent | 从模板内存快照恢复 |
| 复制完整 rootfs | reflink 元数据克隆 |
| 读回完整内存 | mmap(MAP_PRIVATE) + lazy load |
| 每份资源提前独占 | 写时 CoW |
| 多层中心协调 | 节点本地闭环 |
这张表比单个性能数字更重要。
裸金属 benchmark 里 1 并发 avg 47.8 ms、p95 57.4 ms，说明这条路径在高性能物理节点上可以支撑官方"60ms 内"的公开口径。PVM 云服务器环境下 1 并发 avg 66.7 ms、P95 78.2 ms，则提醒我们：同一套架构在不同硬件和虚拟化条件下会有不同表现。数字要看环境，原理才是稳定的。
所以本文说"60ms 不是启动快"，不是否认启动链路里有大量优化，而是强调一个更关键的事实：请求路径里已经不再做完整启动。
8. 这套设计的边界
好的架构不是没有成本，而是知道成本被放到了哪里。CubeSandbox 这条路径也有清晰边界。
第一，Template 构建成本被前移了。镜像转换、rootfs 准备、MicroVM 启动、服务探活、快照生成仍然要花时间，只是不在每一次 CreateSandbox 请求里支付。模板更新越频繁，这部分成本越需要被管理好。
第二，lazy load 会带来首次访问成本。ready 快，不等于运行后每一次访问都没有代价。第一次访问某些页时，仍可能触发缺页；是否要 prefault，本质上是在"ready latency"和"启动后抖动"之间做取舍。
第三，大量写入会产生真实资源消耗。CoW 推迟了复制，不是消灭了复制。沙箱真的写很多文件、修改很多内存页，底层数据块和私有匿名页都会增长。
第四，部署环境有前提。XFS reflink、KVM / RustVMM 的 restore 能力、内存快照、mmap CoW 等机制，是这套架构成立的基础。如果底层能力缺失或降级，性能特征也会变化。
这些边界不削弱 CubeSandbox 的价值，反而说明它的设计思路很清楚：把成本从最敏感的请求路径挪开，放到构建期、元数据层、首次访问时，或者真正发生写入时。
9. 结尾：快在少启动一次
传统思路会问：怎么让启动更快？
CubeSandbox 的思路更像：为什么每次都要重新启动？
这两句话之间，是架构取舍的差别。
如果把沙箱看成一次性对象，那每次创建都要从镜像、rootfs、OS、进程一路构造到 ready。如果把沙箱看成可冻结、可恢复、可分裂的状态对象，创建路径就完全不同：先在模板构建期启动一次，再把可用状态冻结下来；运行期只做元数据克隆、快照恢复、按需加载和写时分裂。
这也是 CubeSandbox 比单点优化更有意思的地方：它没有只盯着某个热函数省几毫秒，而是把 Sandbox 的生命周期重新划了一遍。如果要借鉴它，更值得借鉴的是这个判断：把不该出现在请求期的成本，从架构上搬走。
这就是 CubeSandbox 冷启动的核心判断。
它不是把一条传统开机链路压缩到极限，而是重写了沙箱生命周期：先启动，再冻结；请求到来时恢复；访问时加载；写入时分裂。
60ms 的快，快在这里。
如果你想把这套路径和真实实现对上，可以打开 CubeSandbox 的 GitHub 仓库对照源码和示例继续看：https://github.com/TencentCloud/CubeSandbox。这类系统的很多设计细节，只有顺着代码和 benchmark 一起读才会更有味道；如果这个项目正好帮你理解了 Agent 沙箱的下一种形态，也可以顺手点个 Star，后续看它怎么继续演进。
10. 参考资料
• TencentCloud/CubeSandbox GitHub 仓库：https://github.com/TencentCloud/CubeSandbox
• 中文 README：https://github.com/TencentCloud/CubeSandbox/blob/master/README_zh.md
• 架构文档：https://github.com/TencentCloud/CubeSandbox/blob/master/docs/zh/architecture/overview.md
• CubeSandbox 核心操作性能基准测试报告：https://cubesandbox.com/zh/blog/posts/2026-06-01-cubesandbox-perf-benchmark.html
• CubeSandbox 核心操作性能基准测试报告（PVM 云服务器）：https://cubesandbox.com/zh/blog/posts/2026-06-03-cubesandbox-perf-benchmark-pvm.html
• 几十 GiB 快照秒回、克隆"零拷贝"：Cube 快照克隆回滚技术原理深层揭秘：https://cubesandbox.com/zh/blog/posts/2026-06-25-cubesandbox-snapshot-clone-rollback-deep-dive.html