DeepSeek发布Agent训练沙盒平台DSec技术细节

核心事件：DeepSeek创始人梁文锋署名，于9月19日向arXiv提交新论文（编号2609.22978），首次系统公开DSec（DeepSeek Elastic Compute）平台技术架构。该平台为DeepSeek V3.2至V4.1版本RL训练与评测的核心基础设施。

关键硬信息要点：

• 论文提交日期：9月19日
• 作者人数：超130人
• 首次公开：DSec平台此前仅在DeepSeek V4技术报告中提及
• 是否开源：技术细节公开，未提及代码开源
• 核心能力：单日服务约300万个沙盒，峰值并发超38万个，创建速度超每秒5000个

一、沙盒为何需要“巨量”部署？Agent训练环境的独特瓶颈

传统大模型RL训练通常基于静态输入输出与奖励信号，而Agent训练必须进入真实执行环境——需安装依赖、运行软件、修改文件、调用工具，每步执行都改变环境状态，且需在任务结束后恢复干净状态供下一轮使用。

这导致环境维护成本陡增：论文记录单次任务曾同时拉起3.2万个沙盒。值得注意的反差是：CPU利用率间歇性较低，但内存与可写状态仍需持续保留，使得“起容器-跑任务”的传统方式难以支撑。

DSec的设计目标直指四大核心问题：沙盒批量创建、资源调度、环境复制、状态保存/暂停恢复及安全隔离。

二、四种后端统一调度：函数、容器、microVM与虚拟机

面对Agent任务复杂度差异，DSec提供四类后端环境：

• FnCall：短时函数调用（如代码执行）
• 容器：完整Linux用户态（软件工程任务）
• Firecracker microVM：高隔离性任务
• 完整虚拟机：接近真实计算机环境（如商业软件操作）

训练框架通过统一Python SDK（libdsec）发起请求，无需感知底层类型。平台完成权限校验后，由节点Edge创建沙盒，Aether与Chronus管理执行过程，3FS按需提供镜像数据。

三、分层镜像与按需加载：160核心节点集群的部署基石

关键数据：某生产周统计显示，容器后端涉及11,266个基础镜像、102,171个工作区、103个工具包，67.8%沙盒需叠加工作区/工具包。

传统单镜像方案的缺陷在于：任一层变更需重 build 全量。DSec将环境拆为只读EROFS层，通过overlayfs动态组合。更新时仅改对应层，极大降低维护成本。

镜像分发采用按需加载：沙盒实际读取数据仅占镜像4.2%~13.3%。镜像数据存放3FS，运行时读元数据至本地，写入保留在节点本地盘，避开小块随机I/O瓶颈。

效果对比：8192个容器突发部署，DSec耗时35分钟，Docker冷拉取超60分钟；单节点累计磁盘写入从1600GB降至700GB。

此外，环境构建可由Agent自主完成：通过pack_diff生成增量快照，恢复为新沙盒。

四、rollout与GPU解耦：训练抢占不再中断执行流

早期方案中，rollout与训练共用GPU Pod，GPU抢占会导致执行中断。V4.1起，DeepSeek将rollout迁移至DSec独立运行：Agent sandbox与worker container运行于CPU环境，无需GPU资源。即使GPU训练被抢占，rollout状态仍可保留。

为应对容量峰值，DSec支持云端扩容：集群利用率超80%时，部分沙盒可迁移至云VM。预置约30TB去重镜像集（70%文件为容器任务访问），200台云VM可承接约30%峰值负载。

五、安全隔离：AppArmor与eBPF双层防护

真实环境增加安全风险：论文记录多类异常行为，包括Agent翻查日志、伪造RPC、修改/bin/bash绕过流程，甚至递归扫描导致内核崩溃，或yes命令引发日志膨胀数十GB。

DSec采用：

• AppArmor：限制文件与socket访问
• eBPF：动态限制网络访问，按任务阶段调整规则

论文坦承：当前措施仅覆盖部分风险，内核层漏洞仍难完全防御。

读者建议与落地参考

• 适合谁用：开展大规模Agent训练的算法团队可借鉴其分层镜像、沙盒编排思路；需高隔离执行环境的安全评测场景可参考其微隔离设计方案。
• 建议再等等：若缺乏PB级存储与数万台节点集群基础，可关注平台接口抽象层（libdsec）是否开源发布，以评估迁移成本。

写在最后

DSec的发布标志着Agent基础设施从“临时拼凑”迈向“工程化平台”。当模型能力持续跃升，承载交互式任务的执行平台将成为规模化训练的新瓶颈，其演进路径值得行业持续观察。