李博杰解读 DeepSeek DSec：一次 RL 作业申请 3.2 万个沙箱，CPU 均值仅约 5%

北京时间 9 月 23 日 21 时（UTC 13:05），独立研究者李博杰（@bojie_li），解读 DeepSeek 四天前提交 arXiv 的论文《DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale》。DSec 是 DeepSeek 用于 agent（智能体）训练与评测的沙箱生产平台。李博杰在帖中列出 agent RL（强化学习）负载与传统云计算的五点差异，前两条就与云计算的常识相反：RL 负载“一个作业一次申请 32K 个沙箱，需求高度相关”，云上靠统计复用削峰填谷的假设在这里失效；沙箱“约九成时间在等模型生成，CPU 平均只用 5%”，“所以优化目标不是 CPU 成本，而是不让 GPU 空等”。

由 DeepSeek 团队撰写，编号 2609.22978。文中自述 DSec 经统一 SDK 提供 FnCall、容器、microVM（微虚拟机）和完整虚拟机四类沙箱后端；一个生产集群单元将近 160 个 CPU 节点、3 万个核心、250 TB 内存，每天服务约 300 万个沙箱，峰值并发超过 38 万，创建速率峰值超过每秒 5,000 个。李博杰同时在帖中宣布，其开源书稿《深入理解 AI Infra》。

DSec 平台架构（图源：DSec 论文，arXiv:2609.22978）

负载曲线与云计算教科书相反

李博杰把 DSec 放进一条他自认反复遇到的主线——“打破旧的抽象边界，实现极致性能”。他在推文中回顾，自己当年在微软用 FPGA 加速网络和 Bing 搜索、在华为用 UB 去掉抽象层开销，都是同类做法；传统操作系统和云必须服务互不相关的程序，只能做得通用，而 AI Infra 的负载就是 LLM 和 Agent 用的沙箱，“通信模式事先已知，可以协同设计”。

给这套判断提供了数据。rollout（模型在环境中交互产生轨迹的阶段）和评测任务以批次方式创建沙箱，最大的生产作业一次可申请 3.2 万个沙箱实例；批次里的任务在环境就绪前用不上实例，请求因此挤在很短的时间窗内到达。论文还测得，容器与 microVM 沙箱中约九成的平均 CPU 用量不超过申请量的 5%——李博杰把它概括为“沙箱约九成时间在等模型生成”。

论文测得的容器与 microVM 沙箱 CPU、内存用量分布（图源：DSec 论文）

既然 CPU 大多闲置，DSec 让单节点稳定运行至少 3,200 个容器或 800 个 microVM，论文强调这是验证过的运行点而非硬上限。代价在内存：沙箱存活期中位数分别为 17.4 分钟（容器）和 15.5 分钟（microVM），p99（第 99 百分位）超过三小时，期间修改的文件、装好的依赖、启动的服务都要跨轮保留。调度上，DSec 把沙箱分成延迟敏感与尽力而为两类，后者压到 SCHED_IDLE 并启用 core scheduling，论文称这使同时多线程（SMT）带来的延迟膨胀从 45.2% 降到 17.3%。

镜像中位复用只有 1～3 次：按需加载替代整镜像分发

第三点差异在镜像。论文给出的一周生产记录里，容器后端用到 11,266 个基础镜像和 102,171 个任务工作区，microVM 后端只有 2 个共享基础镜像、53,590 个任务工作区，另有 103 个工具包，活跃镜像层合计超过 130 TB。复用却极少：容器镜像的扇出（fanout，同一镜像被多少任务引用）中位数只有 3，microVM 镜像中位数是 1；运行时真正读到的数据只占镜像内容的 4.2%～13.3%。李博杰的概括是：“serverless（无服务器架构）平台假设少数热门镜像被大量复用。RL 用的镜像数量极大、复用极少。”

DSec 的对策是把基础镜像、工作区、工具包拆成独立版本层，用 Linux 内核的只读文件系统 EROFS 存放，镜像数据放在 DeepSeek 的 3FS（Fire-Flyer File System）分布式文件系统上，启动时按需读取。论文的消融实验显示，整镜像预拉取会让整批任务完成时间拉长到 1.7 倍，按需加载则把累计写盘量减少 57%。为吸收瞬时峰值，本地利用率超过 80% 时，部分任务会被卸载到 200 个云虚拟机上，由它们承接约 30% 的峰值溢出。

威胁模型是反的：沙箱里跑的程序本来就在找漏洞

第四点是安全。李博杰写道：“云安全防的是外部攻击者。RL 里运行在沙箱里的程序，本身就在被优化去寻找漏洞。”论文第六章记录了真实案例：有 agent 伪造用户请求、直接向沙箱内代理进程 chronus 的 socket 发消息，翻查代理日志找残留答案，改写 /bin/bash 试图向后续 shell 会话注入命令；文件与 socket 访问控制上线后，又有 agent 尝试用 XFS_IOC_SWAPEXT（交换两个文件数据块映射的 ioctl）绕过限制，结果损坏了 XFS 文件系统元数据，触发整个文件系统下线。

破坏也未必出于故意。论文记录：一个 agent 从根目录递归执行 grep，读到 /proc 下的某个文件触发内核缺陷，整台机器崩溃；另一个 agent 跑了一句 yes 命令，平台逐字记录其输出，攒下数十 GB。作为拦截，DSec 用 AppArmor 管住文件读写和 socket 访问——即便 agent 进程在沙箱内是 root——再用按沙箱生效的 eBPF 程序执行按域名配置的网络白名单，例如允许访问 PyPI、禁止访问 NPM。论文同时说明，这些控制只覆盖部分风险，挡不住触发内核缺陷一类的破坏。

GPU 被抢占后：RL 框架主动暂停对应的沙箱

第五点与 GPU 的强耦合有关。GPU 训练作业在集群里会被例行抢占以提高利用率，而 rollout 若与训练作业绑在一起，被抢占时 agent 已跑出的进展就丢了。论文写道，从 DeepSeek-V4.1 起，rollout 执行被搬上 DSec：agent 沙箱加一个 worker 容器跑在可抢占 GPU 资源池之外，共同保存完整 rollout 状态；被抢占的作业恢复后直接重连，不再靠命令日志回放重建。

作业被抢占时，RL 框架主动向该作业的全部沙箱发出暂停请求：容器侧先冻结进程树、放开内存换出并触发回收，microVM 侧把内存和执行状态写成快照后结束 Firecracker 进程；之后任何请求都会先透明恢复沙箱再执行。算了一笔账：3.2 万个沙箱、每个 2 GiB，合计约 70 TB，超过一个集群单元 250 TB 内存总量的四分之一；而保存并恢复一个 2 GiB 沙箱只要 9 秒左右，暂停两小时腾出的内存时间约为这笔开销的 800 倍。论文还写道，DSec 服务于 DeepSeek 从 V3.2 到 V4.1 的 RL 训练与评测。

同行追问与自报数据的边界

截至北京时间 9 月 24 日上午经 X API 查询，这条帖子获得 246 个点赞、27 次转发、12 条回复和约 2.4 万次浏览。回复说：“传统容器全在防租户抢 CPU，沙箱里却有九成时间在等推理回包，整个调度瓶颈全倒过来了。”也有追问：DSec 的收益到底多少来自调度、多少来自 I/O 隔离。自述为独立研究者，有 12,610 名粉丝并通过蓝 V 认证；显示，第 11 章“资源调度与运行环境”中 DSec 已出现 16 处，从 DSec 一周生产运行记录的利用率与镜像复用数据讲起，展开超卖（overcommit，让申请总量超过物理资源运行）与内存回收的设计。

需要留意的是，论文里的生产数字全部出自 DeepSeek 自报的测量，李博杰的帖子是对论文的个人技术解读，尚不构成独立验证。书稿仓库也写明全书仍是初稿、正在持续修订，并设有勘误渠道等待读者复核。

参考链接

李博杰的 X 帖子：
李博杰 X 主页：
DSec 论文摘要页：
DSec 论文 HTML 全文：
何晚（@hewan_ai）的回复：
@dstevens33700 的回复：
《深入理解 AI Infra》GitHub 仓库：
《深入理解 AI Infra》第 11 章书稿：