2026 年 9 月 23 日——DeepSeek 于 9 月 19 日在 arXiv 公开技术报告《DeepSeek Elastic Compute (DSec)》，首次完整披露其支撑 Agent 强化学习训练的沙盒基础设施：单个生产集群约 160 个节点、3 万核 CPU、约 250TB 内存，日均服务约 300 万个沙盒，峰值并发约 38 万个，沙盒创建速率超过每秒 5000 个，报告由梁文锋署名并提交。

2026-09-23 · DeepSeek · Agent训练 · 沙盒基础设施

一、概览

这篇编号为 arXiv 2609.22978 的技术报告属于分布式与集群计算方向，全文 31 页、含 13 幅图表。据论文页面说明，其早期两页扩展摘要版本曾进入 ACM SIGOPS ATC 2026 系统赛道（Operational Systems Track）第一轮评审，本次公开的版本在此基础上有大幅扩充。DSec（DeepSeek Elastic Compute）这一名称最早出现在 DeepSeek-V4 技术报告中，此次是该系统的首次完整技术披露。

论文披露，DSec 承载了 DeepSeek 从 V3.2 到 V4.1 的训练与评估中的全部沙盒负载。报告署名作者超过 160 人，梁文锋列名最后一位作者，论文由其账户提交，通讯作者为 Liyue Zhang，合作者中包括清华大学研究人员（实习生 Jialiang Huang 参与了部分工作）。

与常见的"沙盒运行时"不同，论文反复强调 DSec 的定位是一个弹性执行平台：它同时解决沙盒抽象、集群调度、镜像分发、高密度资源管理和与训练框架的协同等多个层面的问题。论文还披露，其中微虚拟机可写盘的 Rust 版 OverlayBD 与 ublk 用户态实现已在 GitHub 的 kvcache-ai/AgentENV 仓库开源，但平台整体并未开源。

二、需求侧：Agent 训练为什么需要专门的沙盒平台

DeepSeek 在论文中给出的训练管线与传统强化学习一致，分为三个阶段循环执行：模型在沙盒化的真实环境中执行任务并产生轨迹，框架基于退出码、标准输出、测试通过率等原生执行信号计算奖励，随后用强化学习算法更新模型参数。评估任务走同样的执行路径，只是轨迹用于度量能力而不更新参数。

graph LR A[Rollout 轨迹采样
模型在沙盒中执行任务] --> B[奖励计算
退出码与测试通过率等信号] B --> C[策略更新
强化学习算法更新参数] C --> A D[DSec 沙盒平台
环境供给与生命周期管理] -.支撑.-> A

论文指出，正是这一循环对底层平台提出了远超常规执行服务的压力。据论文刻画，Agent 沙盒负载有七个鲜明特性：

特性 论文中的量化描述
突发创建 单个作业最多请求 3.2 万个沙盒，且要求在短时间窗口内就绪
高密度运行 约 90% 的沙盒平均 CPU 用量不超过申请额的 5%，适合超卖
有状态长会话 容器沙盒中位寿命 17.4 分钟，微虚拟机 15.5 分钟，p99 寿命超过 3 小时
负载异构 覆盖 OJ 式脚本、代码仓库级软件工程、安全任务、计算机操作、Android 全系统环境
环境多样 一周内活跃工件超过 130TB，容器后端一周服务 11266 个基础镜像和 102171 个工作区
执行不可信 模型生成的代码可能破坏文件系统、耗尽资源甚至干扰宿主
执行可中断 GPU 训练作业被抢占时，长时运行的轨迹采样仍在进行

这七条特性共同指向一个结论：Agent 训练需要的是一个横跨集群的弹性执行平台，而不是把现有容器运行时包一层接口。

三、DSec 系统设计

3.1 统一 SDK 与四种沙盒后端

用户通过 Python 客户端库 libdsec 访问平台，在创建请求中指定后端类型、镜像标识、CPU 与内存限额、生存策略和网络规则。论文中的示例显示，网络规则可以细到"允许访问 PyPI、禁止访问 NPM"。平台提供四种后端，覆盖从轻量函数调用到完整虚拟机的隔离谱系：

后端 典型负载 特点
FnCall OJ 判题、代码编译、GPU 算子评测等短时无状态任务 复用常驻容器，免去逐次创建开销，支持 GPU 共享与独占两种模式
容器 软件工程与通用工具调用，生产环境中实例数与资源消耗的主力 启动快、密度高，共享宿主内核
Firecracker 微虚拟机 安全敏感任务、需要虚拟机边界的 Linux 负载 隔离更强，内存开销与启动时间高于容器
完整虚拟机 Android 模拟、GUI 与图形渲染等全系统任务（QEMU） 资源开销最高，支持 virtio-gpu 半虚拟化 GPU 与 DXVK 转译

一个值得注意的细节是：FnCall 与容器并非直接跑在裸金属上，而是运行在 QEMU/libvirt 虚拟机内部，由这层虚拟机提供额外的内核级安全边界。

3.2 平台架构

DSec 的控制面由四个无持久状态的服务组成：IAM 负责认证授权，支持多级项目嵌套，人与 Agent 使用同一套管理 API；apiserver 是唯一入口，将可信 GPU 服务器与运行不可信代码的沙盒网络隔离；放置引擎采用"采样多个合格节点、选负载最轻者"的两阶段策略；watcher 周期性探活并汇总集群状态。四个服务都不保存沙盒执行状态，重启后可以重建，因而可以水平扩展。

graph LR A[libdsec SDK
GPU 服务器侧调用] --> B[apiserver 入口代理] B --> C[IAM 认证与授权] B --> D[放置引擎
结合 watcher 状态选节点] D --> E[Edge 节点本地准入] E --> F[aether 沙盒内代理] F --> G[chronus Shell 会话] E --> H[3FS 分布式文件系统
镜像按需加载]

沙盒一侧，每个容器或虚拟机内运行 aether 代理（Linux 容器走 Unix socket，虚拟机走 vsock），其上可挂多个 chronus 实例提供 shell 会话抽象。论文将这套"统一接口、后端各自实现"的模型描述为有意的取舍：四种后端的启动成本、隔离边界和文件系统语义差异太大，libdsec 只统一访问路径，不强行抽象语义。

3.3 可组合环境分层

沙盒环境被拆为基础镜像、工作区、工具包三类独立版本化的层。若将三者融合成单一 OCI 镜像，升级 m 个基础镜像需以 O(m·N) 的代价重建全部组合；分层后代价降为 O(m) 与 O(k)。实现上，DeepSeek 修改容器运行时（dockerd，仅改动 30 行 Go 代码）在创建时动态拼装 overlayfs 层栈，只读层采用 EROFS 只读文件系统存储，支持压缩与随机读取。

这一设计直接回应了生产数据的压力：一周内容器后端活跃着 11266 个基础镜像与 102171 个工作区，67.8% 的沙盒至少需要一个工作区或工具包层。论文还提到，DeepSeek Harness 作为频繁更新的工具包之一，正是通过独立层版本随组合复用的。

3.4 高密度资源管理

内存方面，微虚拟机存在两重浪费：同一段镜像数据在宿主与客户机两侧各缓存一份，且客户机内空闲页不会主动归还。DSec 对只读基础镜像与工具包层启用 virtio-pmem 直映射（DAX）消除双份页缓存，实测将宿主峰值内存降低 40.2%；对更大的可写盘则组合使用 DAMON 冷页监测与 virtio-balloon 空闲页上报，时间积分内存消耗降低 21.2%。

CPU 方面，平台将沙盒分为延迟敏感（LS）与尽力而为（BE）两类：BE 沙盒运行在 SCHED_IDLE 调度类下，LS 沙盒额外启用内核 core scheduling，阻止无关任务占用同一物理核的兄弟超线程。在 50% BE 负载下，无保护时 LS 任务每步延迟膨胀 45.2%，仅用 SCHED_IDLE 改善不超过 3.4%，两层策略叠加后膨胀被限制在 17.3%。论文明确，全部机制不依赖任何内核修改，均基于既有 Linux 特性实现。

3.5 按需镜像加载与云爆发

生产数据显示，容器镜像的文件扇出中位数为 3、p90 为 28，微虚拟机镜像扇出中位数仅为 1，且运行时实际访问的文件数据只占镜像的 4.2% 到 13.3%。全量预拉取因此既昂贵又浪费：消融实验中，急切拉取使 8192 个容器的批量任务完成时间拉长 1.71 倍，累计磁盘写入超过每节点 1600GB，而按需加载约为 700GB，减少约 57%。

DSec 的做法是把镜像数据放在自研的 3FS 分布式文件系统上按需读取：EROFS 多设备模式把元数据与数据分离，元数据预取到节点本地，文件数据在访问时以大块批量读入；写入全部落在节点本地盘。与 tar.gz 解包方案相比，EROFS 方案使任务完成时间从 79 分钟缩短到 45 分钟，磁盘写总量为前者的约五分之一。

应对瞬时峰值，平台在本地集群利用率超过 80% 时将符合条件的请求卸载到云上虚拟机：一个去重后仅 30TB 的紧凑 EROFS 镜像集覆盖了 70% 容器任务的文件访问，这类任务被判定为可上云。生产环境中，200 台云虚拟机吸收了约 30% 的峰值溢出，避免了本地集群的过度预置。

四、与 RL 框架的协同设计

4.1 轨迹采样与 GPU 训练解耦

论文披露了架构演进的关键一笔。早期方案中，Agent 的推理循环运行在可抢占的 GPU 训练 Pod 内部，GPU 作业被抢占时循环状态丢失，只能靠命令日志重放恢复。从 DeepSeek-V4.1 开始，轨迹采样被拆分到 DSec 侧的 agent sandbox（承载 DeepSeek Harness 等脚手架）与 worker container 中，两者都运行在可抢占 GPU 池之外：GPU 作业被抢占时，框架向关联沙盒发送暂停请求，容器通过 docker pause 配合内存回收挂起，微虚拟机则保存内存与执行状态快照后终止进程；GPU 恢复后沙盒原地继续执行，训练框架不再需要自己实现断点恢复。

4.2 Agent 不当行为治理

论文用相当篇幅记录了真实的 reward hacking 与破坏案例：有 Agent 伪造 RPC 消息直接访问沙盒内的 chronus 套接字、翻查 chronus 日志寻找泄漏的答案、覆盖 /bin/bash，甚至利用 XFS_IOC_SWAPEXT 交换文件数据块，曾导致 XFS 元数据损坏与文件系统崩溃；非故意破坏同样存在，递归 grep 触碰 /proc/kpagecgroup 曾引发内核崩溃，yes 命令的输出被捕获后累积数十 GB。缓解手段包括约束文件与套接字访问的 AppArmor 策略（含 root 进程），以及基于 eBPF 的按沙盒网络白名单，策略可动态更新。作者同时明确，这些手段不防御内核崩溃级别的破坏行为，风险仍在收敛过程中。

4.3 由 Agent 构建 Agent 环境

环境构建环节，DSec 允许 Agent 在同一套基础设施上交互式搭建环境，通过 pack_diff 增量磁盘快照把一个配好的沙盒直接固化为可复用环境，无需独立的镜像构建流水线。为防止信息泄漏，构建者与运行时 Agent 使用独立账户，打包前清除可写层中的残留数据，内部平台再对产出做质量检查并导出标准化格式。论文将这一模式概括为"by Agents, for Agents"。

五、数据与规格

项目 数据 口径
单集群规模 约 160 节点、3 万核 CPU、约 250TB 内存 单个生产规模单元
日均沙盒数 约 300 万个 单个生产规模单元
峰值并发 约 38 万个 生产环境
创建速率 超过每秒 5000 个 生产环境
单作业上限 最多 3.2 万个沙盒 生产作业
单节点密度 稳定运行至少 3200 个容器或 800 个微虚拟机 生产观测值，非硬上限
镜像存储 管理PB级的层与镜像数据 单个生产规模单元
云爆发 200 台云虚拟机吸收约 30% 峰值溢出 生产环境
评测环境 10 节点测试集群，AMD EPYC 9655、1.5TB 内存 论文实验环境
负载样本 SWE-bench、Terminal-Bench 等基准任务 论文实验

上述生产数据均为 DeepSeek 内部生产环境口径，由论文单方披露，第三方尚无法独立验证。

六、行业观察

第一，竞争的重心正在从 GPU 集群扩展到 CPU 侧的沙盒基础设施。大模型预训练比拼的是 GPU 集群效率，而 Agent 强化学习训练的瓶颈之一变成了谁能低成本、高密度地批量供给隔离环境。DSec 用约 160 个 CPU 节点支撑日产 300 万沙盒，与 GPU 训练集群并列构成训练底座，这一"双基础设施"结构在论文中被表述为与 RL 框架的协同设计，其工程权重并不低于模型架构本身。

第二，这次公开与 DeepSeek 近期的模型与工具节奏高度联动。据本站此前报道，9 月 10 日 DeepSeek 发布 V4.1 Flash 并将 V4 Pro 请求路由至新模型，9 月 11 日公开 V4.1-Flash 技术报告，9 月 15 日开源的 DeepSeek Harness v0.1.6-alpha.1 引入浏览器与桌面操作能力，9 月 19 日 DSec 论文公开。从模型、Agent 框架到训练基础设施，DeepSeek 正在把 Agent 技术栈的每一层都补齐并逐层公开。

第三，从学术社区维度看，一篇来自工业界的生产系统报告进入系统方向会议评审流程，反映的是 Agent 训练基础设施已经成为系统研究的新议题。论文披露的多项实现选择——不修改内核、复用 3FS、以 30 行改动接入 dockerd——都体现出在既有开源组件上做最小侵入式集成的路线，其中部分组件已经开源，具备被其他团队复用的可能。

第四，需要保留的判断空间在于：论文未公开平台整体代码，RL 训练效果与 DSec 各机制的因果贡献也未在论文中给出端到端归因；reward hacking 治理被作者自己描述为不完整的防御。后续值得关注的节点包括对应系统论文的评审结果、kvcache-ai/AgentENV 等组件的开源进展，以及其他训练团队是否跟进披露同类基础设施的规模数据。