5 项实测、12 组数据：Cube Sandbox 核心操作性能基准测试公开

◆一、前言◆

CubeSandbox 面向 AI Agent 代码执行场景设计，极速冷启动和高并发是最关键的两项指标。本文给出在腾讯云标准型 CVM（运行 PVM 内核）上测量的性能基准数据，分为两大部分：

• 第三章：基于Template创建沙箱— 启动延迟、并发扩展能力、单机部署密度
• 第四章：Snapshot相关操作— Snapshot 制作、基于 Snapshot 启动沙箱、Rollback、Clone

每节均附有完整的测试命令，读者可直接照步骤在自己的环境中复现。

重要说明：所有测试数据与测试环境、测试场景高度相关。影响因子包含但不限于：Host 的 CPU、内存、IO 性能，以及 Sandbox 内部负载（例如 Sandbox 中运行的程序越复杂、脏页越多，Snapshot 制作耗时也随之上升）。实际部署时请结合自身硬件和负载情况进行评估。

更极致的性能要求，推荐使用裸金属机器部署，对应裸金属版性能测试报告可查看（https://cubesandbox.com/zh/blog/posts/2026-06-01-cubesandbox-perf-benchmark.html）。

◆二、测试环境◆

2.1硬件信息

SA9.4XLARGE32 是腾讯云标准型第九代实例，搭载 AMD EPYC 9K65 处理器，适合通用计算场景。本文运行 PVM（Parallel Virtual Machine）内核，支持嵌套虚拟化，可在普通云服务器上运行 CubeSandbox。如需复现本文测试，可前往腾讯云 CVM 购买页选购同款。Cube Sandbox 部署请参考Cubesandbox Github主页或官网「Quick Start」章节。

2.2沙箱规格与模板制作

所有测试统一使用以下规格的沙箱：

测试前需先制作模板（国内使用 cn 镜像仓库，境外使用 int）：

cubemastercli tpl create-from-image \--image cube-sandbox-cn.tencentcloudcr.com/cube-sandbox/sandbox-code:latest \--writable-layer-size 1G \--expose-port 49999 \--expose-port 49983 \--probe 49999

等待构建完成后，记录模板 ID：

# 查看模板列表，取第一行 tpl- 开头的 IDcubemastercli tpl list

2.3指标说明

所有时间单位均为毫秒（ms）。每轮测试开始前执行Warm-up（首轮结果丢弃），消除 page cache 冷读干扰；并发测试的各轮次之间串行发起，无交叉并发。

◆三、基于 Template 创建沙箱◆

本章测试「从零启动一个可用沙箱」的端到端耗时，即调用 POST /sandboxes（指定 template_id）到沙箱进入 running 状态的时间。这是最常见的使用场景。

3.1环境准备与验证

第一步：安装Python SDK并设置环境变量

​​​​​​​pip install e2b-code-interpreterexport CUBE_API_URL=http://<your-server-ip>:3000export E2B_API_KEY=e2b_000000 # 本地部署填任意非空字符串export CUBE_TEMPLATE_ID=<your-template-id> # 上一步 cubemastercli tpl list 查到的 IDexport SSL_CERT_FILE=/root/.local/share/mkcert/rootCA.pem # mkcert 证书路径

第二步：跑一个Hello World验证环境正常

在执行任何基准测试前，先运行以下脚本确认沙箱可以正常创建和执行代码：

​​​​​​​import osfrom e2b_code_interpreter import Sandboxwith Sandbox.create(template=os.environ["CUBE_TEMPLATE_ID"]) as sandbox:result = sandbox.run_code("print('Hello from Cube Sandbox, safely isolated!')")print(result)print("✅ 环境验证通过，可以开始基准测试")

保存为 hello.py 并执行：

python hello.py

看到 ✅ 环境验证通过 字样即说明 CubeSandbox 部署正常，可继续后续测试。如果报错，请先参考Quick Start 排查环境问题。

3.2启动延迟与并发扩展

使用cube-bench工具测量不同并发度下的沙箱创建延迟。cube-bench 用 Go 协程并发驱动 CubeAPI，测量结果包含完整百分位统计。

编译工具（需要Go 1.21+）：

cd examples/cube-bench

make# 产出: ./bin/cube-bench

执行测试：

# 设置环境变量

export E2B_API_URL=http://<your-server-ip>:3000export E2B_API_KEY=e2b_000000export CUBE_TEMPLATE_ID=<your-template-id># 1 并发，共 20 次（创建后立即删除）./bin/cube-bench -c 1 -n 20 -w 3# 10 并发，共 200 次./bin/cube-bench -c 10 -n 200 -w 3# 20 并发，共 300 次./bin/cube-bench -c 20 -n 300 -w 3

-w 3 表示先做 3 轮热身，热身结果不计入统计。

测试数据（腾讯云SA9.4XLARGE32 PVM，2 vCPU / 2 GiB沙箱）：

各档均独立测试，档间清空所有沙箱并留出资源池恢复时间，避免相互干扰。所有档位成功率均为 100%。

关键结论：

• 单并发创建延迟约67 ms（min 55.9 / P95 78.2），延迟极低且非常稳定

• 10 并发 avg 171 ms，均摊单沙箱仅 17.1 ms，并发扩展势头良好

• 20 并发 avg 365 ms，均摊单沙箱18.2 ms，P99 674 ms 显示少量长尾请求受队列压力影响

3.3单机部署密度（内存开销）

CubeSandbox 通过内核共享与写时复制（CoW）将自身额外开销压缩到极低水平。本节通过「清空机器 → 分批启动沙箱 → 记录内存变化」的方式，实测单实例净开销。

⚠️⚠️⚠️ 重要安全提醒

每次启动沙箱前，务必先用 free -h 确认机器剩余内存充足，每次只启动少量，边启动边观察内存余量，确认安全后再继续下一批，切勿一次性启动过多！ 内存耗尽会触发 OOM Killer，轻则进程被杀，重则损坏运行环境，需重新部署。请根据自己机器的实际内存容量决定每批启动的数量。

第一步：记录基线（空机内存）

export E2B_API_URL=http://<your-server-ip>:3000

export E2B_API_KEY=e2b_000000export CUBE_TEMPLATE_ID=<your-template-id># 确保没有残留沙箱cubemastercli list# 记录空机内存用量free -h# 同时记录 shim 进程数（应为 0）ps --no-headers -C containerd-shim-cube-rs | wc -l

第二步：分批启动沙箱，每批结束后用free -h记录当前已用内存

用 cube-bench 的 create-only 模式批量创建并保持沙箱存活。# 设置环境变量（与 §3.2 一致；换新终端窗口需重新 export）

export E2B_API_URL=http://<your-server-ip>:3000export E2B_API_KEY=e2b_000000 # 本地部署填任意非空字符串export CUBE_TEMPLATE_ID=<your-template-id> # cubemastercli tpl list 查到的 ID./bin/cube-bench -c 1 -n 1 -m create-only && free -m # 累计 1./bin/cube-bench -c 4 -n 4 -m create-only && free -m # 累计 5./bin/cube-bench -c 5 -n 5 -m create-only && free -m # 累计 10./bin/cube-bench -c 10 -n 10 -m create-only && free -m # 累计 20

第三步：计算单实例开销

单 VM 均摊开销 = (当前 used - 基线 used) ÷ VM 数量

测试数据（腾讯云SA9.4XLARGE32 PVM，2 vCPU / 2 GiB规格沙箱）：

实测单 VM 均摊开销约 27～34 MB，CoW 按需分配效果显著——2 GiB 规格的沙箱空载时实际仅占用约 30 MB。

单机可运行实例数估算（SA9.4XLARGE32，32 GiB内存）：总内存： 32768 MB

系统基线占用（实测）： 7198 MB（= 32768 - 25570，空机 available 实测值）安全水位预留（10%）： 3276 MB可分配给沙箱： 22294 MB（= 32768 - 7198 - 3276）空载/轻载场景（CoW 按需分配，均摊 ~30 MB/个）：22294 ÷ 30 ≈ 743 个满载场景（每沙箱实际写满 2 GiB）：22294 ÷ (2048 + 30) ≈ 10 个

◆四、Snapshot 相关操作◆

Snapshot 是 CubeSandbox 的核心功能之一，支持在运行中的沙箱上制作内存 + 文件系统快照，后续可基于快照极速恢复（Clone / Rollback）。

安装依赖：

cd examples/snapshot-rollback-clone

pip install -r requirements.txt # 安装 cubesandbox SDK# 以下环境变量为所有 4.x 压测脚本的前置，每个新 shell 都需先 export（或写入 env.sh 后 source）export E2B_API_URL=http://<your-server-ip>:3000export CUBE_API_URL=http://<your-server-ip>:3000 # 与 E2B_API_URL 保持一致export E2B_API_KEY=e2b_000000 # 本地部署填任意非空字符串export CUBE_TEMPLATE_ID=<your-template-id> # cubemastercli tpl list 查到的 ID

下文 4.1~4.5 各节命令块默认你已在当前 shell 完成上述 export（脚本通过 env.py 读取这些变量）。换新终端窗口请重新 export。

4.1 Snapshot制作耗时与并发的关系

测试方式：在运行中的沙箱上调用 POST /sandboxes/{id}/snapshots，N 并发时同时对 N 个沙箱各发起一次快照请求，测量整批完成的 wall time。

CubeSandbox 对同一个沙箱的快照请求内部串行化，因此并发测试中每个沙箱对应独立的快照请求，实际成功数等于并发数。

执行命令：（脚本地址：https://github.com/TencentCloud/CubeSandbox/blob/master/examples/snapshot-rollback-clone/bench_snapshot_concurrency.py）

cd examples/snapshot-rollback-clone

# 若是新开的终端，先设置环境变量（同 4.0 安装依赖一节）：export E2B_API_URL=http://<your-server-ip>:3000export E2B_API_KEY=e2b_000000export CUBE_TEMPLATE_ID=<your-template-id># 脚本只提供单档机制，并发档位在命令行控制；逐档串行调用：python bench_snapshot_concurrency.py -c 1 -n 5python bench_snapshot_concurrency.py -c 5 -n 5 --no-headerpython bench_snapshot_concurrency.py -c 10 -n 5 --no-header

测试数据（全新沙箱原样打快照，实测脏页约8 MB，由 /data/log/CubeVmm/vmm.log 中 PagemapAnon snapshot saved 记录确认；该值为沙箱基线匿名内存页大小，本节不作为变量）：

串行单 Snapshot 约41 ms；5 并发时整批 wall 约58 ms，per-snapshot 均摊降至约11.6 ms；10 并发时整批 wall 约114 ms，均摊进一步降至约11.4 ms，并发摊薄效果显著。

4.2 Snapshot制作耗时与Dirty Page的关系

背景：CubeSandbox 使用 soft-dirty 机制，只保存自上次 Snapshot 以来被修改过的内存页。实际写入量 = 脏页数 × 4 KiB，通常远小于沙箱总内存（2 GiB）。

测试通过在 /dev/shm（tmpfs）预先写入数据来精确控制脏页大小。"Dirty Page" 列为从 /data/log/CubeVmm/vmm.log 读取到的实际写入量，与理论值因 Guest OS 自身活动存在差异。

执行命令：（脚本地址：https://github.com/TencentCloud/CubeSandbox/blob/master/examples/snapshot-rollback-clone/bench_snapshot_dirty.py）

cd examples/snapshot-rollback-clone

# 若是新开的终端，先设置环境变量（同 4.0 安装依赖一节）：export E2B_API_URL=http://<your-server-ip>:3000export E2B_API_KEY=e2b_000000export CUBE_TEMPLATE_ID=<your-template-id># 脚本只提供单档机制，脏页大小在命令行控制（-d 即写入量 MB）；按需逐档调用：python bench_snapshot_dirty.py -d 0 -n 3python bench_snapshot_dirty.py -d 10 -n 3 --no-headerpython bench_snapshot_dirty.py -d 50 -n 3 --no-headerpython bench_snapshot_dirty.py -d 100 -n 3 --no-headerpython bench_snapshot_dirty.py -d 200 -n 3 --no-headerpython bench_snapshot_dirty.py -d 500 -n 3 --no-headerpython bench_snapshot_dirty.py -d 800 -n 3 --no-headerpython bench_snapshot_dirty.py -d 1024 -n 3 --no-header

测试在串行模式下进行，每个数据点先预热（丢弃首次结果），再正式测量 3 次取均值。"create sandbox avg" 列为基于该 Snapshot 创建新沙箱的耗时，反映 Dirty Page 大小对恢复速度的影响。

测试数据：

关键结论：

• Snapshot制作耗时与Dirty Page大小近线性相关：基线（8.3 MB 脏页）约 42 ms，每增加 100 MB 脏数据约增加 22 ms，1024 MB 时约 258 ms。
• 基于Snapshot创建新沙箱的耗时与Dirty Page大小无关：恢复耗时稳定在54–83 ms，因为恢复采用 CoW（写时复制）按需加载，不依赖 Dirty Page 的大小。

4.3基于Snapshot启动沙箱

测试方式：先制作一个快照，然后并发调用 POST /sandboxes（指定 snapshot_id），测量从请求发出到所有沙箱进入 running 的端到端 wall time。

执行命令：（脚本地址：https://github.com/TencentCloud/CubeSandbox/blob/master/examples/snapshot-rollback-clone/bench_create_concurrency.py）

​​​​​​​cd examples/snapshot-rollback-clone# 若是新开的终端，先设置环境变量（同 4.0 安装依赖一节）：export E2B_API_URL=http://<your-server-ip>:3000export E2B_API_KEY=e2b_000000export CUBE_TEMPLATE_ID=<your-template-id># 脚本只提供单档机制，档位在命令行控制；按需逐档调用：python bench_create_concurrency.py -c 1 -n 3python bench_create_concurrency.py -c 10 -n 3 --no-headerpython bench_create_concurrency.py -c 20 -n 3 --no-header

测试数据：

单沙箱启动约67ms；10 并发时 wall 约 388ms，均摊仅38.8ms/个；20 并发时 wall 约701ms，均摊仅35.1ms/个，展现出良好的并发扩展能力。

4.4 Rollback

测试方式：对运行中的沙箱调用 POST /sandboxes/{id}/rollback，将沙箱内存和文件系统状态原地恢复至指定 Snapshot，无需重建沙箱。

快照所有权约束： CubeSandbox 只允许沙箱回滚到自己创建的 checkpoint，每个并发沙箱均需独立完成「打快照 + 回滚」全流程。

执行命令：（脚本地址：https://github.com/TencentCloud/CubeSandbox/blob/master/examples/snapshot-rollback-clone/bench_rollback_concurrency.py）

​​​​​​​cd examples/snapshot-rollback-clone# 若是新开的终端，先设置环境变量（同 4.0 安装依赖一节）：export E2B_API_URL=http://<your-server-ip>:3000export E2B_API_KEY=e2b_000000export CUBE_TEMPLATE_ID=<your-template-id># 脚本只提供单档机制，档位在命令行控制；按需逐档调用：python bench_rollback_concurrency.py -c 1 -n 5python bench_rollback_concurrency.py -c 5 -n 5 --no-headerpython bench_rollback_concurrency.py -c 10 -n 5 --no-header

测试数据：

单次 Rollback 流程（create_snapshot打点 →rollback回滚到自身 checkpoint）约90 ms；5 并发时整批 wall 约326 ms，per-rollback 均摊降至约65 ms；10 并发时整批 wall 约821 ms，均摊约82 ms/次。

注：因 CubeSandbox 要求沙箱只能回滚到自己创建的 checkpoint，故无法复用共享快照，每个并发沙箱均需独立完成「打快照 + 回滚」全流程。

4.5 Clone

测试方式：调用 POST /sandboxes/{id}/clone，从一个运行中的沙箱派生出 N 个新沙箱，完整保留源沙箱的内存和文件系统状态（包含脏页）。

说明： 本次 Clone 测试涉及磁盘文件时，相关数据均已在 Page Cache 中，测试结果不含冷读 IO 开销。

执行命令：（脚本地址：https://github.com/TencentCloud/CubeSandbox/blob/master/examples/snapshot-rollback-clone/bench_clone_concurrency.py）

​​​​​​​cd examples/snapshot-rollback-clone# 若是新开的终端，先设置环境变量（同 4.0 安装依赖一节）：export E2B_API_URL=http://<your-server-ip>:3000export E2B_API_KEY=e2b_000000export CUBE_TEMPLATE_ID=<your-template-id># 脚本只提供单场景机制，n/并发/轮数在命令行控制；按需逐场景调用：python bench_clone_concurrency.py -n 1 -c 1 --rounds 5python bench_clone_concurrency.py -n 10 -c 5 --rounds 3 --no-headerpython bench_clone_concurrency.py -n 20 -c 10 --rounds 3 --no-header

测试数据（源沙箱脏页约10 MB）：

Clone 单沙箱约271 ms；10 沙箱 5 并发时整批 wall 约542 ms，per-clone 均摊降至约54 ms；20 沙箱 10 并发时整批 wall 约790 ms，均摊进一步降至约40 ms/个，并发摊薄效果显著。

4.6 Pause / Resume

测试方式：创建 concurrency 个沙箱，并发调用 POST /sandboxes/{id}/pause 暂停全部，再并发调用 POST /sandboxes/{id}/resume 恢复全部，分别记录 pause 和 resume 的 wall time 与均摊耗时。

⚠️ 当前实现说明： Pause 当前采用 full-memory-copy 模式——暂停时会将沙箱的全部匿名内存页写入持久化存储，耗时与沙箱总内存量线性相关（2 GiB 规格约 371 ms/个）。后续版本将升级为 soft-dirty 增量模式，仅保存自上次 checkpoint 以来被修改的脏页，空载沙箱的 pause 耗时预计将大幅降低。

执行命令：（脚本地址：https://github.com/TencentCloud/CubeSandbox/blob/master/examples/snapshot-rollback-clone/bench_pause_resume_concurrency.py）

​​​​​​​cd examples/snapshot-rollback-clone# 若是新开的终端，先设置环境变量（同 4.0 安装依赖一节）：export E2B_API_URL=http://<your-server-ip>:3000export E2B_API_KEY=e2b_000000export CUBE_TEMPLATE_ID=<your-template-id># 脚本只提供单档机制，档位在命令行控制；按需逐档调用：python bench_pause_resume_concurrency.py -c 1 -n 5python bench_pause_resume_concurrency.py -c 10 -n 5 --no-header

Pause测试数据：

Resume测试数据：

关键结论：

• Resume极快且并发扩展良好：单次约 19 ms，10 并发时均摊仅 2.7 ms/个，恢复速度不受 full-copy 影响
• Pause是当前瓶颈：full-copy 模式下单次约 371 ms，10 并发均摊 158.6 ms/个
• soft-dirty版本上线后，pause 耗时预计大幅降低

◆附录：测试脚本索引◆

本文涉及的所有测试脚本均位于仓库目录：

• examples/cube-bench/— 基于 Template 的并发创建基准工具（Go）

  https://github.com/TencentCloud/CubeSandbox/tree/master/examples/cube-bench

• examples/snapshot-rollback-clone/— Snapshot / Rollback / Clone / Pause-Resume 相关 Python 脚本

  https://github.com/TencentCloud/CubeSandbox/tree/master/examples/snapshot-rollback-clone