DeepSeek 新论文公开 Agent 训练，梁文锋署名

来源摘要

大模型训练拼的是算力，Agent 训练拼的是环境。环境怎么造？梁文锋署名的 DeepSeek 最新论文，把技术细节公开了。 DeepSeek 做的这个系统叫 DSec（DeepSeek Elastic Compute），干的事情就是给 Agent 训练批量制造沙盒。 它每秒能产生 5000+ 个沙盒，一天能达到 300 万个，峰值同时运行 38 万个。支撑这个规模的单集群也非常庞大，大约有 160 个节点、3 万核 CPU 和 250TB 内存。 为啥训个 Agent 会这么费劲？ 因为大模型训练的环境就是 GPU 集群，喂数据算梯度，但 Agent 完全不同。它得在沙盒里写代码、跑编译、开浏览器，甚至装操作系统…… 每执行一步都改变环境状态，随时可能把环境搞崩。所以每轮训练都得给它一个全新的、干净的沙盒，而且随用随抛、训完就扔。 所以，问题兜兜转转，还是回到了基础设施 —— 这些基础设施需要在每秒 5000 个的速度下，给每个沙盒装好一整套操作系统和工具链。同时，还不能让几十万个并发沙盒把集群的内存和 CPU 挤爆。 具体怎么办，论文把这整套工程的全貌摊开了。 Agent 训练需要「一个世界」 DSec 要解决的第一个核心问题是，不同类型的 Agent 任务对沙盒环境的要求差异极大，而且这些环境必须在同一个平台上统一调度。 一个刷 OJ 题的 Agent，只需要一个无状态的函数调用环境，跑完拿到输出就行，连文件系统都不需要持久化。 但一个做 SWE-bench 的 Agent，就需要完整的 Linux 用户态，得在里面装依赖、改代码、跑 pytest，任务做到一半还可能要往环境里加新包。 到了安全攻防和 computer-use 场景，容器级别的隔离就不够了，Agent 要操作浏览器甚至桌面，一个有漏洞的 Agent 可能顺手把宿主机搞挂，必须上虚拟机。 最极端的情况是训练操作商业软件的 Agent，它需要一个完整的 Windows 或 macOS，带图形界面、带驱动，跟真实电脑几乎没区别。 DSec 为这四类场景分别准备了四种后端，FnCall 处理无状态函数调用，Container 跑 Docker 容器，MicroVM 用 Firecracker 做轻量级虚拟机，Full VM 用 QEMU 跑完整操作系统。 四种后端的隔离强度和资源开销逐级递增，但训练框架那边看到的是统一的 Python SDK libdsec。 不管底层是容器还是虚拟机，都采用相同的接口，创建沙盒、执行命令、拿结果，各个步骤的调用方式完全相同。 要让四种后端在同一套集群上跑起来，平台的调度层也得跟上。 DSec 把整个链路拆成了六层。 这条链路从训练框架的一个创建请求出发，先经过 IAM 认证鉴权，进入 API Server，再由调度引擎（Placement Engine）根据资源余量从集群中选出一台目标节点，节点上的 Edge 组件负责实际拉起对应类型的沙盒。 沙盒的网络出口和包管理镜像由 Aether 统一代理，Agent 在里面执行的每条命令和产生的每行输出，都通过一个叫 Chronus 的沙盒内通信组件中转回训练框架，让框架知道 Agent 做到了哪一步、该给什么反馈。 靠资源超分和高密度部署，单个节点可以同时承载 3200 个容器或 800 个 MicroVM。 每天 300 万个沙盒怎么带动？ 然而，DSec 在规模上最狠的挑战还不是调度，是环境的构建。 每个沙盒启动时，都需要一整套操作系统镜像加工具链，相当于每秒给 5000 台「电脑」装系统。 传统 Docker 的思路是把基础镜像、工作区和工具包打成一个完整镜像。这个方案在小规模下没问题，但 DSec 的容器后端累计使用了 11266 个基础镜像和 102171 个工作区，67.8% 的沙盒需要在基础镜像之上叠加至少一层工作区或工具包。 在这种多样性下，一旦某个工具包更新，所有包含它的组合镜像全部要重新构建，成本是 O (m·N)。 DSec 的做法是把环境拆成基础镜像、工作区、工具包三层独立的 EROFS 只读镜像，各自独立版本化，通过 overlayfs 在沙盒启动时按需组合。更新工具包只碰工具包那一层，成本降到 O (m)+O (k)。 镜像造好之后，怎么送到节点上同样关键。直觉上应