DeepSeek论文上新：首次公开V4.1 Agent训练“大本营”，梁文锋署名
DeepSeek联合清华大学发布最新技术报告《DeepSeek 弹性计算（DSec）：面向大规模智能体训练的高效沙箱基础设施（DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale）》，首次对外公开了支撑 DeepSeek从 V3.2 到 V4.1 训练的“工业底座”——DSec。
该论文作者团队超过 130 人，梁文锋排在名单最后一位。由此可见，智能体训练的基础设施，已经被DeepSeek当成核心工程来对待。
DSec 是 DeepSeek 自研的生产级弹性计算沙箱平台，内部专属基础设施，曾在DeepSeek-V4的报告有所介绍。职责是为大模型智能体的大规模训练和评测，提供安全稳定的沙箱运行环境。
论文提到，一个生产单元大约由160个CPU节点、3万个CPU核心和250TB内存构成，托管着PB级镜像。能力方面，DSec单日可以服务约300万个沙盒，峰值并发超过38万个，创建速度超过每秒5000个。单个训练任务最多一次能拉起3.2万个沙盒。
这篇论文不仅给出了系统级架构解法，更记录了大量模型在沙箱内部“试图越狱、偷窥答案、搞崩系统”的戏剧性博弈。
如果说过去的大模型 Scaling，是往 GPU 集群里塞更多参数、数据和 Token，那么 DSec 暴露出的，是Agent 时代被眼中低估的扩张：模型进入真实环境，反复执行任务和试错学习的次数也正在被Scaling。
模型生成代码不是终点，真正的瓶颈在于承载这些代码安全、高速、并发运行的物理基础设施。
传统云架构失效
理解 DSec，首先要看清智能体强化学习（Agentic RL）与传统大模型训练在底层逻辑上的本质分歧。
过去训练语言模型，交互逻辑更接近“答题”：给模型输入提示词或数学题，模型生成一段推导或答案，系统依据规则计算奖励并反向传播更新参数。
但面向真实软件工程（SWE）或系统操作（Computer-Use）的智能体完全不同。智能体接到任务后，需要检索代码仓库、阅读上下文、配置依赖环境、修改代码逻辑，并在终端中执行测试、根据报错反馈继续调试。在这个过程中，模型不是在静态地输出文本，而是在真正操作一台计算机。
单任务沙箱创建量的累积分布（CDF），展示生产中单任务并发请求数千乃至数万沙箱的瞬态脉冲特征
在强化学习的单次探索（Rollout）中，如果让成千上万个智能体同时探索，系统就必须瞬间交付数万台彼此隔离的执行环境。更关键的是，这些环境必须是有状态且高度连贯的。 智能体在第十步执行的命令，必须严格建立在前九步修改过的文件、编译好的二进制和启动的服务进程之上。
然而，以 Kubernetes 为代表的传统容器编排和无状态 Serverless，其底层假设建立在平滑扩缩容与无状态微服务之上，面对这种高频脉冲、长程驻留且极度异构的计算负载，直接遭遇了三重结构性错配：
沙箱生命周期分布曲线，直观呈现长尾沙箱存活时间超过 3 小时的长程驻留现象
瞬态脉冲并发：单任务可在数秒内申请数万个沙箱（峰值达 3.2 万），全量拉取解压会瞬间引发严重的写 I/O 拥塞，大幅拉长启动延迟并迫使 GPU 集群空转；
海量异构与极低复用：面对超 130 TB 的环境数据，镜像复用扇出中位数仅为 1 到 3，常规本地缓存机制彻底失效；
长程驻留与算力潮汐：沙箱存活数十分钟甚至数小时，但 90% 的时间内 CPU 利用率不足 5%，独占资源极度浪费，而粗暴超卖又极易引发内存溢出与超线程争抢。
传统云计算方案无法同时兼顾高并发、强状态与低成本，DSec 正是 DeepSeek 为解决这些矛盾构建的“专用数字演练场”。
四类后端的取舍
既然无法直接套用通用的容器集群，最直观的想法或许是做一个“性能最好、功能最全的终极沙箱”。但 DeepSeek 的工程实践证明，单一的虚拟化运行时无法同时兼顾安全隔离与资源开销。
不同任务对环境的要求有着天然鸿沟：跑一段算子脚本只需要几毫秒，做系统攻防需要严格的硬件级虚拟化，而跑Android 模拟器则依赖完整的操作系统与图形驱动。如果全部采用重型虚拟机，硬件成本会迅速失控；如果全用轻量容器，安全与环境兼容性又无法过关。
因此，DSec 放弃了万能沙箱的幻想，将环境切分为四类梯次布局：
DSec 整体架构拓扑图，展示 libdsec、集群管控层（IAM、Placement Engine）、单机运行时（Edge、Aether、Chronus）与 3FS 的分层交互
FnCall（函数调用）：面向短时无状态任务（如算法判题或 GPU 算子基准测试），基于常驻预热池运行，抹平冷启动时延，支持独占或共享 GPU；
Container（标准容器）：主力承载软件工程与工具交互，单机可高密度部署 3,200 个实例，兼顾轻量与基础 Linux 工具链兼容；
MicroVM（轻量虚拟机）：基于 Firecracker 构建独立内核，为安全攻防与对抗性任务提供硬件级隔离，杜绝跨租户逃逸；
Full VM（全功能虚拟机）：基于 QEMU 并接入虚拟化 GPU 驱动，专供需要完整商业操作系统、图形界面、Android 模拟器或游戏渲染的高阶环境。
四类沙箱后端（FnCall、Container、MicroVM、Full VM）在性能、开销、隔离级别与场景适配上的对比
这套设计的精髓在于：环境不追求统一，统一的是接入环境的控制接口。 平台通过统一的 Python SDK（libdsec）对上层屏蔽环境差异，算法研发人员只需在请求中声明任务所需的计算类型与资源上限，调度系统便会自动将任务路由至合适的计算载体。
算力潮汐超卖
确立了四类沙箱后端，仅仅是搭好了承载任务的“房间”。真正把系统逼向极限的难题接踵而至：如果按照常规资源配额，160 台物理机根本无法同时容纳 38 万个并发沙箱。
要让单个计算节点稳定承载多达 3,200 个容器或 800 个 MicroVM，核心在于把握住了智能体计算的特殊生理规律：沙箱并非一刻不停地消耗 CPU。
在实际交互中，模型思考时，沙箱静默等待；模型下发指令后，CPU 瞬时飙高；执行完毕，算力又迅速跌回低谷。数据表明，90% 的沙箱在其生命周期内，平均 CPU 利用率不足申请额度的 5%。既然算力是高度脉冲化与潮汐化的，系统就具备了实施极限资源超卖（Overcommit）的客观基础。
沙箱生命周期内 CPU 脉冲与内存常驻的曲线图
CPU/内存实际使用率极其稀疏的分布特征
但高倍率超卖极易引发系统性踩踏，DSec 在内核层完成了三项关键收口：
- 只读内存穿透共享：在 MicroVM 中启用 Virtio-pmem 配合 DAX 技术，将只读磁盘内容直接映射为宿主机内存，绕过客户机自身的页面缓存，使单机上百个虚拟机完全共享同一份宿主机物理内存，宿主机峰值内存暴降 40.2%；
内存优化组合拳对比曲线
冷内存动态驱逐：针对可写磁盘，利用 Linux 内核 DAMON 机制定期采样内存活跃度，主动淘汰长期闲置的冷页面，并由虚拟气球设备将物理页归还宿主机，让长程内存消耗再降 21.2%；
超线程硬隔离：为防止背景负载干扰具有严格响应时延的任务（如步频受限的对弈智能体），系统在赋予关键任务调度优先权的同时，启用了内核核心调度（Core Scheduling），严禁低优先级任务占用同一物理核心的孪生超线程，将高负载下的长尾延迟涨幅从 45.2% 严格压制在 17.3%。
正是通过对内存重复占用的剔除与计算争抢的抑制，高密度超卖才从纸面构想变成了具备生产可用性的现实。
存储与训练双解耦
此外，系统还须在数据传输与协同架构上完成彻底的松绑。
首先是告别全量搬运镜像，实现流式按需加载。面对超 130 TB 的海量异构环境，监控显示沙箱实际访问的镜像数据仅占总量的 4.2% 到 13.3%。
DSec 将镜像拆分为基础系统、任务代码区与工具链三层不可变层，结合 EROFS 压缩文件系统与自研的 3FS 分布式存储，做到“智能体执行涉及哪块，后台才并发调取哪块”，运行期写入则严格落在本地磁盘。
该设计直接消除了并发启动时的 I/O 拥塞，减少了 57% 的磁盘写入，任务耗时缩短超 40%。
EROFS 按需流式拉取与传统 Docker 全量拉取在并发容器数与磁盘写入量上的性能对比
其次是将智能体探索循环与易失性 GPU 训练集群解耦。在 DeepSeek-V4.1 的架构演进中，团队将驱动多轮交互的 Agent Loop 彻底迁出 GPU 集群，交由 DSec 的独立容器托管。
大规模训练中 GPU 作业高频遭遇调度抢占，若两者绑定，中断后依赖日志重放恢复状态的代价极其沉重。解耦后，GPU 发生抢占时沙箱只需就地休眠、释放内存；算力恢复后原位透明唤醒，继续推进长程任务。
DSec 核心机制全貌图，展示三层环境解耦、按需流式读取与底层运行时的协同流转
在数据层面“按需抓取”，在任务层面“思考与执行剥离”，这一套组合拳真正移除了阻碍智能体长程探索的系统瓶颈。
结语
随着模型逐步走向能够调用工具、与现实系统交织的智能体阶段，AI 的竞争维度正在悄然迁移。决定上限的不再仅仅是模型本身的参数规模，还有底层工程能否以极低的时延与成本，稳定托举起数十万个数字生命在真实世界里反复碰壁、犯错与成长的过程。
当算法前沿迈入深水区，那些看似远离聚光灯的底层操作系统原语与分布式存储设计，正在成为新的核心护城河。
本文来自微信公众号“AI前线”（ID：ai-front），作者：青和，编辑：四月，36氪经授权发布。