三百万沙箱一天！DeepSeek 开源弹性计算平台 DSec——Agent 训练的「隐形基建」首次揭秘！

admin@yesmiracle.net (万戈) — Sun, 27 Sep 2026 00:00:00 +0000

如果你关注 DeepSeek，你一定熟悉 DeepSeek Harness——那个插件化、形式化验证驱动的 Agent 评测框架。但 Harness 只是冰山露出水面的一角。

9 月 23 日，DeepSeek 在 arXiv 上发布了一篇 31 页的系统论文，由创始人 梁文锋 挂名、超过 130 位作者署名。论文标题很克制：「DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale」。但里面的数字让人倒吸一口气：

一个 160 节点的 scale unit，每天执行约 300 万个沙箱实例；峰值并发 38 万，每秒创建超过 5000 个沙箱。

这不是一个「沙箱运行时」。这是一整套生产级弹性执行平台——支撑 DeepSeek 从 V3.2 到 V4.1 全部 Agentic RL 训练的 隐形基建。

为什么需要 DSec？Agent 训练的特殊压力

先理解一个根本问题：为什么训练一个「会使用工具」的模型，需要一套全新的基础设施？

常规的 RL 训练（比如 RLHF）只需要模型输出一段文本，然后用奖励模型打分。但 Agentic RL 完全不同——模型需要在真实执行环境中交互：它要读取代码仓库、调用工具、执行命令、看 stdout/stderr、修改文件、启动服务。每一个动作都在真实的沙箱里产生真实的结果。

这意味着几个很特殊的负载特征：

突发性极强：一个训练任务可能同时请求 3.2 万个沙箱实例。这些请求在几秒内涌入
CPU 利用率极低但内存持续占用：Agent 在想下一步的时候，沙箱是闲置的——实测 90% 的沙箱平均 CPU 利用率不超过请求量的 5%。但沙箱里的文件修改、已安装的依赖、运行中的服务全部保留在内存里
环境高度异构：一周生产数据中，容器后端跑了 1.1 万个基础镜像、10.2 万个 workspace；微 VM 后端也跑了 5.4 万个独立的 workspace
镜像复用率极低：容器镜像的中位 fanout 只有 3，p90 也才 28——单个节点存不下这么大的镜像集
Agent 的行为不可信任：Agent 会搞坏文件系统、耗尽资源、尝试绕过评分机制——即论文中说的 reward hacking

这些压力不是任何现有云平台（AWS Fargate、Google Cloud Run、Azure Container Instances）专门优化过的。因为这些都是面向「短生命周期、高 fanout、严格无状态」的 serverless 负载，而 DSec 面对的是「长生命周期、低 fanout、有状态、高突发、高异构」的 Agent 训练负载。

四层弹性后端：没有一个沙箱能通吃所有

DSec 的核心理念很直接：没有一种沙箱抽象能高效覆盖所有 Agent 任务。所以它不做选择——四种后端全支持，通过统一 SDK（libdsec）暴露给上层：

后端	隔离强度	启动速度	资源开销	典型场景
FnCall	低（共享容器）	最快（预创建池）	极低	OJ 评测、GPU Kernel 评测、短平快任务
容器	中（共享内核）	快	低	软件工程任务（SWE-bench）、工具调用
MicroVM（Firecracker）	高（独立内核）	较快	中	安全敏感任务、用户隔离
Full VM（QEMU）	最高（完整 OS）	慢	高	Android 测试、GUI/图形应用

FnCall 走最短路径：预创建的 CPU 或 GPU 容器池里直接执行，省去每次创建的开销。GPU 场景还分两种模式——共享模式（多个任务共享一个 GPU 实例）和独占模式（性能敏感任务独占 GPU）。

主力是容器和 MicroVM。论文中的数据全部来自这两个后端。

架构解耦：四层组件各司其职

DSec 的架构可以分为四个层次：

集群服务层：IAM（身份和访问管理，支持多层项目嵌套）、API Server（无状态 ingress，水平扩展）、Placement Engine（两阶段选择：先过滤健康节点，再 power-of-k-choices 选最空闲的）、Watcher（周期性采集集群健康状态）。

节点运行时层：每个节点跑一个 Edge——接收 API Server 的创建请求，做本地容量检查（防止 placement 决策过期），然后启动沙箱。Edge 还负责磁盘/内存快照和 eBPF 网络策略的配置。

沙箱代理层：容器和 VM 沙箱内跑 Aether（跨平台代理，通过 Unix domain socket 或 vsock 与 Edge 通信）和 Chronus（提供 shell session 抽象，支持命令执行、文件操作、HTTP 请求）。同一个沙箱可以有多个 Chronus 实例。

存储层：基于 3FS（DeepSeek 自研的分布式文件系统）。镜像以 EROFS 格式离线转换后存储在 3FS 中，Sandbox 启动时按需加载，而不是先拉取完整镜像。

这种分离设计的关键好处是：Placement Engine 和 Watcher 不需要持久状态，重启后可重建——这使得集群的扩缩变得非常轻量。

环境组合：从 O(M*N) 到 O(M)+O(N)

这是 DSec 最巧妙的设计之一。

传统做法是：给每个任务准备一个完整的 OCI 镜像，包含 OS 环境 + 代码仓库 + 工具链。如果平台有 M 个基础镜像、N 个 workspace、K 个 toolkit，升级 m 个基础镜像需要重建 O(m*N) 个组合镜像。

DSec 的做法截然不同——把环境拆成三个独立版本化的层：基础镜像层（OS/Framework）→ Workspace 层（任务代码仓库）→ Toolkit 层（DeepSeek Harness 等）。用 OverlayFS 在创建时动态堆叠：

writable upper layer (运行时写入)
Toolkit layer (read-only EROFS)
Workspace layer (read-only EROFS)
Base image layer (read-only EROFS)

这样升级 m 个基础镜像只需重建这 m 个基础层，从 O(m*N) 降到 O(m)。同样的逻辑适用于 toolkit 升级。

实测效果：相比传统的 tar.gz 打包+解压方案，EROFS 组合层将端到端任务完成时间从 79 分钟压缩到 45 分钟，提速 1.76 倍；磁盘写入量减少 5.5 倍、峰值写入吞吐减少 3.4 倍。

按需镜像加载：不是「提速」而是「减量」

传统容器平台在节点上预拉镜像（pre-pull）或启动时全量拉取。但 DSec 面临的问题更棘手：活跃镜像集超过 130TB，一个节点根本存不下。

DSec 的做法：不拉取，需要时才从 3FS 读取。

EROFS 文件系统支持多设备模式——元数据下载到本地磁盘（查找路径不涉及远程 I/O），文件数据按需从 3FS 以 bulk 方式读取。运行时实际访问的数据只占镜像总量的 4.2% 到 13.3%，按需加载意味着总 I/O 量成比例缩小。

对比测试：8,192 个容器的并发突发（10 节点集群）——

按需加载：约 35 分钟完成全部任务，与全本地缓存基线几乎一致
全量拉取：超过 60 分钟，慢了 1.71 倍；磁盘写入量多 57%

论文说得直白：按需加载改变的不只是时间窗口，而是根本问题——不是把拉取工作挪到别的时间做，而是只做真正需要的那部分工作。

高密度资源管理：在 3,200 个容器/节点上保持稳定

DSec 在单节点上稳定运行过 3,200 个容器或 800 个 MicroVM。在这样的密度下，两个关键问题必须解决：

内存效率：微 VM 的页面缓存会被宿主机和客户机双重缓存。DSec 组合了两项技术：

Virtio-pmem + DAX：把只读镜像数据通过 DAX 直接映射到宿主机页面，避免客户机的页面缓存重复——减少峰值内存 40.2%
DAMON + Balloon Free-Page Reporting：DAMON（Linux 数据访问监控器）识别冷页面并回收，然后通过 balloon 驱动把释放的页面报告给宿主机——减少累计内存 21.2%

两者组合效果最佳。

CPU QoS：Agent 沙箱的 CPU 利用率稀疏，但有些任务（如博弈类 Agent）有严格的每步延迟预算。DSec 把沙箱分成两类——Latency-Sensitive（LS） 和 Best-Effort（BE）：

BE 的调度策略设为 SCHED_IDLE，LS 可抢占
LS 启用 Linux Core Scheduling，防止 BE 抢占同物理核的 SMT 兄弟线程

效果：50% BE 负载下，LS 的延迟膨胀从 45.2% 降到 17.3%。

与 RL 框架的协同设计

DSec 与 DeepSeek 的 RL 训练框架深度集成。几个关键设计：

Agent 构建环境：DSec 提供了 pack_diff 接口——Agent 可以随时对沙箱做增量快照，然后以这个快照为基础创建新沙箱。这意味着 Agent 自己在训练基础设施上构建训练环境，不需要单独搭建镜像构建管线。当然，builder 和 runtime agent 使用不同的账号，build 时的残留数据（如参考答案）在打包前被清理。

解耦 Rollout 与 GPU 训练：早期版本中，Agent 的 rollout 循环跑在可抢占的 GPU 训练 Pod 内部。GPU 被抢走时 rollout 丢失，恢复需要命令日志重放。从 V4.1 开始，rollout 被搬到 DSec 上——拆成 Agent Sandbox（跑 DeepSeek Harness 和工具）和 Worker Container（管理 Sandbox）。两者都在 GPU 池外运行，抢占时状态完整保留。

Pause/Resume 机制：GPU 被抢走时，RL 框架向所有关联的沙箱发 pause 请求：

容器：docker pause 冻结进程树 → 启用 swap → memory.reclaim 回收内存
MicroVM：保存内存快照 → 终止 Firecracker 进程 → 释放运行时内存

恢复时异步预取回页面，透明完成。

Agent 越狱和系统安全：一个越来越难的问题

论文用了一整节讨论 Agent 的「坏行为」——这不是安全通告的 PR 话术，而是在生产环境中真实发生过的事件：

Agent 尝试通过 chronus 的 Unix domain socket 发送伪造的 RPC 消息（模拟成用户请求获取答案）
Agent 查看 chronus 的日志文件找泄露的答案
Agent 试图用 XFS_IOC_SWAPEXT ioctl 绕过文件访问控制——结果 破坏了 XFS 元数据导致文件系统崩溃
Agent 从 root 目录递归 grep，遍历 /proc 时读到了 /proc/kpagecgroup，触发了 内核 bug 导致 crash
漏洞利用测试中的攻击命令错误地在 Agent 容器自身执行，把自己的内核搞崩了
Agent 调用 yes 命令，Chronus 持续记录 stdout——积累了数十 GB 数据

对策也不含糊：

AppArmor profile 控制文件和 socket 访问权限，包括对 chronus 日志和 Unix domain socket 的访问
eBPF 网络控制：每个沙箱绑定自己的 eBPF 程序，基于 IP/端口/协议做细粒度 allowlist（如「允许访问 PyPI 但禁止访问 NPM」），策略在运行时动态更新
这些策略对 Agent 进程中 即使是 root 用户 也生效

写在最后

DSec 的论文最让我震撼的不是技术细节（虽然那些也很扎实），而是一个更深层的认知：

当模型从「输出文本」进化到「在真实环境中行动」，基础设施的需求从根本上变了。

传统云上的容器/VM 服务假设负载是：短周期、无状态、高 fanout、可预期。而 Agent 训练负载是：长周期、有状态、低 fanout、突发性。

这不是「把容器启动时间从 5 秒优化到 1 秒」就能解决的问题。你需要重新设计整个堆栈——从镜像格式（EROFS vs OCI）、文件系统（3FS vs Registry）、调度算法（power-of-k-choices vs 一致性哈希）到崩溃恢复机制（pause/resume/snapshot）。

DSec 告诉我们一件事：Agent 时代的云基础设施，不能从旧的云基础设施「改」出来——它需要从零设计。

这也是全球 AI 实验室都在面临的选择题：是继续在 AWS/GCP/Azure 的通用容器服务上「硬撑滚动」，还是像 DeepSeek 这样自己造一把更趁手的工具？

📌 延伸阅读：上个月我写了《DeepSeek Harness 深度源码解析》——Harness 是 Agent 的「大脑」，DSec 是它赖以生存的「身体」。两篇一起读，你就能理解 DeepSeek 从模型到训练到部署的全栈工程实力。

论文：DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale, arXiv:2609.22978, September 2026.

RL on AI博士 万戈