DeepSeek DSec撑起38万沙盒并发

DeepSeek 把 Agent 训练背后的“环境工厂”摊开了

DeepSeek 最新公开的不是一个新模型，而是一套支撑 Agent 大规模训练与评估的沙盒基础设施。

9 月 19 日，DeepSeek 团队提交论文《DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale》，梁文锋位列作者名单。这篇由 Jialiang Huang 等 131 名作者完成的论文，首次系统披露了 DeepSeek 如何为 Agent 批量创建、调度和回收执行环境。

**DSec 是 DeepSeek Elastic Compute 的缩写，是一套面向 Agent 后训练与评估的生产级弹性沙盒平台。**它不是负责生成答案的模型，也不是普通容器管理器，而是一座持续给 Agent 提供“临时电脑”的环境工厂。

论文披露，一套生产规模的 DSec 集群大约包含 160 个节点、3 万个 CPU 核心和 250TB 内存，每天可服务约 300 万个沙盒实例。在生产负载下，它支持超过 38 万个沙盒同时运行，沙盒创建吞吐量超过 5000 个/秒。

这组数字需要分开理解：300 万个/天是实际服务规模，折算后平均每秒约 34.7 个；5000 个/秒代表系统在高峰或压力场景下的创建吞吐能力；38 万则是同一时间保持活跃的实例数量。三项指标分别对应日处理量、瞬时供给速度和并发承载能力，不能简单互相换算。

Agent 训练真正消耗的，是“一次性世界”

**Agent 沙盒是一个与宿主系统隔离、可执行代码和工具调用，并能在任务结束后被销毁的临时计算环境。**它既要允许模型自由行动，又要确保模型写坏文件、启动异常进程或触发恶意代码时，不会影响其他任务和底层集群。

传统大模型训练主要在 GPU 集群中完成矩阵计算，基础设施关心的是显存利用率、通信带宽和训练吞吐量。Agent 训练则多了一层复杂性：模型不只是预测下一个 Token，还要写代码、安装依赖、运行编译器、操作浏览器、修改文件，甚至启动完整操作系统。

每一次工具调用都会改变环境状态。例如，一个代码 Agent 执行 pip install 后，依赖树已经变化；修改仓库文件后，后续测试结果也随之改变；浏览器 Agent 登录网站后，Cookie、缓存和页面状态都会被保留。训练系统如果复用被污染的环境，奖励信号就可能失真，不同样本之间还会互相干扰。

因此，Agent 训练需要为大量任务持续提供干净、可复现、随用随抛的执行环境。环境启动得太慢，GPU 或推理服务就会等待；隔离做得太重，CPU 和内存成本又会失控；环境无法恢复和重放，失败样本便很难定位。

这也是 DSec 最值得关注的地方：它解决的不是“怎样让 Agent 更聪明”，而是“怎样让几十万个 Agent 同时有地方干活”。

四种后端，不再拿一种容器硬扛所有任务

DSec 的核心设计是按照任务复杂度和安全需求，提供四种隔离强度不同的执行后端。

| 后端 | 底层方式 | 典型任务 | 隔离强度 | 启动与资源开销 | |---|---|---|---|---| | FnCall | 无状态函数调用 | OJ 判题、数学工具、简单代码执行 | 低 | 最低，适合极高并发 | | Container | Docker 兼容容器 | 代码修改、依赖安装、pytest、SWE-bench 类任务 | 中 | 较低，兼顾灵活性与密度 | | MicroVM | Firecracker 轻量虚拟机 | 安全攻防、运行不可信代码、浏览器任务 | 高 | 高于容器，低于完整虚拟机 | | Full VM | QEMU 完整虚拟机 | Windows、macOS、桌面软件与复杂驱动环境 | 最高 | 最高，但兼容性最完整 |

**FnCall 是一种只暴露输入和输出、不要求持久文件系统的轻量执行环境。**对于 OJ 判题或单个函数验证任务，系统没有必要启动完整 Linux 用户态，只需要运行函数并返回结果。把这类任务塞进虚拟机，等于为了算一道题先开一台电脑，成本明显不合理。

**Container 是基于操作系统级隔离运行应用和工具链的环境。**代码 Agent 往往需要克隆仓库、安装依赖、修改文件并执行测试，容器可以提供相对完整的 Linux 用户态，同时把启动时间和内存开销控制在较低水平。

**MicroVM 是使用硬件虚拟化提供虚拟机级隔离、同时压缩启动成本的轻量虚拟机。**DSec 采用 Firecracker 作为 MicroVM 后端，适合运行来源不明的代码、安全攻防任务以及需要更强内核隔离的浏览器环境。

**Full VM 是通过 QEMU 启动完整客体操作系统的高兼容性环境。**当 Agent 需要操作 Windows 桌面软件、图形界面、设备驱动或特定操作系统功能时，容器和 MicroVM 都不一定够用，完整虚拟机虽然更重，却能提供接近真实电脑的运行条件。

这套分层设计的价值并不在于技术名词多，而在于避免资源错配。轻任务走 FnCall，常规软件工程任务走容器，高风险任务进入 MicroVM，必须模拟真实电脑的任务才使用 Full VM。DSec 本质上是在隔离强度、兼容性、启动速度和资源密度之间做动态选择。

38 万并发，靠的不是简单堆机器

DSec 的规模意味着它不可能为每个沙盒预留固定的 CPU 和内存。

如果把 3 万个 CPU 核心和 250TB 内存机械地平均分给 38 万个并发沙盒，每个沙盒理论上只能对应约 0.079 个核心和 0.66GB 内存。实际调度当然不会这样平均，但这个粗略计算说明了一件事：大量沙盒不可能一直独占物理资源，系统必须依赖分时调度、资源超分和负载感知。

**资源超分是根据工作负载不会同时达到峰值的特征，分配超过物理容量账面值的虚拟资源。**Agent 执行过程通常是突发式的：一段时间等待模型推理，一段时间密集编译，随后又等待网络或磁盘。如果系统按每个任务的最高需求长期保留资源，大量 CPU 和内存会处于空闲状态。

高密度超分的难点是不能把延迟敏感任务拖死。数十万个实例一旦同时解压镜像、安装依赖或启动进程，节点会出现 CPU 抢占、内存压力和存储抖动，尾延迟可能迅速放大。DSec 因此不只是追求“塞得更多”，还要在高密度运行时维持可预测的启动和执行性能。

论文称，DSec 通过环境准备、镜像分发、内存效率和高密度超分等机制降低基础设施开销。其目标是把沙盒从笨重的预制环境，变成可以按需快速组装、在任务结束后立即释放的短生命周期资源。

3FS 把环境镜像变成全局共享底座

**3FS 是 DeepSeek 开源的高性能分布式文件系统，用于把多节点存储组织成可并行访问的共享数据层。**DSec 运行在 3FS 之上，让不同节点能够访问统一的环境镜像、数据集、依赖和任务状态。

共享文件系统对 Agent 训练的重要性高于普通在线推理。一个 SWE-bench 类任务可能需要完整代码仓库、语言运行时和数GB依赖；一个桌面 Agent 可能依赖完整操作系统镜像；如果每次创建沙盒都从远端完整下载并复制这些内容，5000 个/秒的创建速度几乎无从谈起。

DSec 要做的是避免重复搬运相同数据，并把环境启动尽可能转化为按需读取。这个思路类似给几十万台临时电脑共享同一个软件仓库：实例看到的是独立环境，底层公共数据却不必复制几十万份，只有任务真正修改的部分需要单独记录。

这种设计同时降低了镜像分发压力和存储占用，但也把问题转移到了缓存命中、元数据并发、热点文件和故障恢复上。DSec 的工程含金量不只来自沙盒数量，更来自它必须让计算调度、虚拟化和分布式存储在同一条任务链上协同工作。

轨迹日志比“录屏”更适合审计 Agent

**轨迹日志是按全局顺序记录 Agent 命令、工具调用及其执行结果的可重放事件序列。**DSec 会为沙盒维护有序的 trajectory log，用于任务恢复、细粒度溯源和确定性重放。

这项能力解决了 Agent 系统长期存在的“过程黑箱”。普通聊天模型答错时，开发者通常检查输入和输出；Agent 出错时，问题可能发生在中间第 27 次工具调用：它可能读取了错误文件、安装了不兼容依赖、被网页中的提示注入诱导，或者根据一条失败命令继续执行了错误计划。

轨迹日志让平台能够回答更具体的问题：

• Agent 执行过哪些命令，返回值和退出码是什么？
• 它读取、创建或修改过哪些文件？
• 哪次工具调用改变了后续路径？
• 环境崩溃后能否从中间状态恢复？
• 同一条训练轨迹能否被确定性重放？
• 奖励异常来自模型、工具，还是基础设施？

这套机制不仅服务训练效率，也构成了 Agent 安全审计的基础。企业如果让 Agent 直接操作代码库、浏览器、内部系统或桌面软件，只检查最终答案远远不够；真正需要留档的是中间发生的每一次动作。

DSec 公开的是论文，不等于完整系统已经开源

DeepSeek 此次公开的是 DSec 的论文与技术细节，而不是一套已经发布、可直接部署的完整开源产品。

截至 2026 年 9 月 23 日，公开信息的重点仍是系统架构、后端类型、资源规模和生产性能，不能把“论文公开”写成“DSec 代码全部开源”。DeepSeek 已经开源 3FS 等底层组件，但 DSec 的生产调度系统、控制面和完整部署工具是否会进一步开放，仍需等待官方后续动作。

从论文描述看，DSec 主要由三个 Rust 组件组成：面向任务入口的 API Gateway、运行在每台宿主机上的 per-host agent，以及负责集群状态与资源管理的 cluster monitor。各组件通过自定义 RPC 协议通信，底层接入 3FS，并统一管理四类执行后端。

这意味着 DSec 更接近一套针对 Agent 工作负载重新设计的集群操作系统，而不是给 Kubernetes 加一个创建容器的接口。它需要同时理解任务的隔离等级、镜像类型、操作系统、资源需求、生命周期和恢复方式，再决定任务应该落到哪个节点、使用哪种后端。

Agent 竞争正在从模型跑分转向环境吞吐

DSec 释放出的明确信号是，Agent 能力的上限开始受到环境供给能力约束。

一个模型能否修复代码问题，不只取决于推理能力，还取决于训练阶段能否见到足够多的真实执行反馈。如果创建环境需要几十秒，训练系统每天只能跑有限数量的轨迹；如果环境可以在高峰期每秒创建 5000 个，研究团队就能显著扩大强化学习、拒绝采样和自动评测的搜索规模。

环境吞吐也会直接影响实验迭代速度。Agent 训练常常需要对同一任务采样多条轨迹，再根据测试结果、安全规则或任务完成度计算奖励。每个任务如果生成 16 条、32 条甚至更多候选轨迹，沙盒需求会比任务数量膨胀一个数量级。

这也是 DSec 相比单纯模型跑分更值得开发者关注的原因。模型榜单展示的是最终结果，DSec 展示的则是结果背后的生产线：DeepSeek 不仅在训练模型，还在把“可执行经验”变成可以工业化供应的数据。

它真正拉开的，可能是 Agent 数据飞轮

DSec 的长期价值在于形成“生成任务—执行轨迹—验证结果—筛选数据—继续训练”的闭环。

传统预训练数据可以从网页和文档中获取，但高质量 Agent 数据必须通过执行产生。代码是否真的能编译、补丁是否通过测试、浏览器操作是否完成目标、安全攻击是否突破限制，这些结果不能只靠语言模型自评，而要由真实环境给出反馈。

当沙盒生产速度足够快，DeepSeek 就能用更低成本生成大规模可验证轨迹，并把成功和失败样本继续用于后训练。模型越强，能解决的任务越多；轨迹越多，训练数据越丰富；基础设施吞吐越高，这个循环转得越快。

DSec 因而不是一个容易被普通用户直接感知的新功能，却可能是 DeepSeek Agent 能力最关键的底层资产之一。它不会像新模型那样在发布当天制造大量演示视频，但会决定团队能以多大规模训练、评估和淘汰 Agent 策略。

判断：这是基础设施秀肌肉，也是行业门槛上移

DSec 最重要的意义不是“38 万”这个数字本身，而是 DeepSeek 已经把 Agent 环境做到了独立基础设施层。

过去一年，行业讨论 Agent 时经常聚焦模型推理、上下文长度和工具协议，但真正进入大规模训练后，瓶颈会迅速落到环境冷启动、镜像分发、状态隔离、资源超分和轨迹重放上。这些问题不够性感，却会实打实决定训练成本与实验速度。

DeepSeek 的方案也不是没有代价。160 个节点、3 万核 CPU 和 250TB 内存仍是一套庞大的基础设施，四种后端并存还会增加运维和安全复杂度。DSec 证明的是超大规模沙盒可以被统一管理，而不是 Agent 环境已经变得便宜或简单。

更现实的判断是，Agent 竞争正在复制大模型训练早期的路径：先比算法，随后比系统，最后比谁能把算法、数据和基础设施连成闭环。DSec 就是 DeepSeek 对“系统能力”这一环的正面展示。

对中小团队而言，没必要复刻一套 38 万并发的平台，但 DSec 给出的架构原则值得直接借鉴：按风险选择隔离层级、不要让所有任务都运行在同一种容器里、把环境状态和轨迹作为一等数据保存，并把沙盒供给速度纳入 Agent 训练指标。

Agent 训练拼到最后，模型需要的不只是一张更大的 GPU 集群，而是几十万个可以反复进入、破坏、恢复和重放的数字世界。DeepSeek 这次公开的，正是制造这些世界的流水线。

参考来源

• IT之家：DeepSeek 新论文公开 Agent 训练，梁文锋署名——整理了 DSec 的集群规模、沙盒吞吐量及四类执行后端。
• GitHub：DeepSeek 3FS——DeepSeek 开源的高性能分布式文件系统，也是 DSec 的底层存储基础。
• GitHub：Firecracker——DSec MicroVM 后端采用的轻量虚拟化技术，由 AWS 开源。