DeepSeek 团队近日发布了一篇由梁文锋署名的技术论文，公开了其为 Agent 训练构建的沙盒系统 DSec（DeepSeek Elastic Compute）。该系统每秒可生成超过 5000 个沙盒，单日产量达 300 万个，峰值同时运行 38 万个沙盒。支撑这一规模的单集群约包含 160 个节点、3 万核 CPU 和 250TB 内存。
与依赖 GPU 集群的大模型训练不同，Agent 训练需要在沙盒环境中执行写代码、编译、运行浏览器乃至安装操作系统等操作，每步执行都会改变环境状态，因此每轮训练都要求一个全新且干净的沙盒，且随用随抛。这给底层基础设施带来了巨大压力：需要在每秒 5000 个的速度下为每个沙盒装配完整的操作系统与工具链，同时避免数十万并发沙盒挤爆集群的内存和 CPU。
DSec 针对四类 Agent 任务场景设计了四种后端：FnCall 处理无状态函数调用，Container 运行 Docker 容器，MicroVM 基于 Firecracker 提供轻量级虚拟机，Full VM 通过 QEMU 运行完整操作系统。四种后端的隔离强度与资源开销逐级递增，但训练框架侧统一通过 Python SDK libdsec 调用，创建沙盒、执行命令、获取结果的接口完全一致。平台调度链路拆分为六层，从训练框架发起请求，经 IAM 认证鉴权、API Server、调度引擎选点，到节点上的 Edge 组件拉起沙盒，网络出口与包管理镜像由 Aether 统一代理，沙盒内命令与输出通过 Chronus 组件回传训练框架。依靠资源超分和高密度部署，单节点可同时承载 3200 个容器或 800 个 MicroVM。
环境构建是规模化面临的核心挑战。DSec 容器后端累计使用 11266 个基础镜像和 102171 个工作区，67.8％ 的沙盒需要在基础镜像之上叠加至少一层工作区或工具包。传统 Docker 将基础镜像、工作区和工具包打包为完整镜像，工具包更新时所有组合镜像均需重建，成本为 O(m·N)。DSec 将环境拆分为三层独立的 EROFS 只读镜像，各自独立版本化，通过 overlayfs 在启动时按需组合，更新成本降至 O(m)+O(k)。
镜像分发方面，论文统计的真实运行数据显示，Python 容器镜像 6.0GB 中 Agent 实际仅读取 6.0％，Java 镜像 12.1GB 中仅访问 9.2％，C++ 镜像 4.9GB 中仅访问 8.7％。DSec 因此采用按需加载，镜像以 EROFS 格式存储在 3FS 分布式文件系统上，元数据预取至本地，数据块仅在沙盒实际读取时拉取。实测 8192 个容器的突发部署，按需加载耗时 35 分钟，Docker 冷拉取则需 60 分钟以上；磁盘写入量从约 1600GB 降至约 700GB。
资源争抢方面，DSec 通过 virtio-pmem 配合 DAX 让 MicroVM 跳过自身页缓存、直接映射宿主机物理内存，峰值内存占用降低 40.2％；对可写磁盘使用 DAMON 定期扫描冷内存页并归还宿主机，配合 virtio-balloon 的 free-page reporting 再降 21.2％。CPU 侧将沙盒分为延迟敏感型和尽力而为型，后者设为 SCHED_IDLE 优先级并启用 core scheduling，50％ 背景负载下延迟敏感任务的延迟膨胀从 45.2％ 降至 17.3％。从 DeepSeek-V4.1 开始，Agent 循环被拆出独立运行在 DSec 的 worker container 中，不再绑定 GPU Pod 生命周期，GPU 被抢占时沙盒挂起保存状态、恢复后继续执行。当集群利用率超过 80％ 时，DSec 自动触发 cloud bursting，200 台云 VM 可吸收约 30％ 的峰值负载。
该文观点仅代表作者本人，企服科学平台仅提供信息存储空间服务。
