9 月 26 日，DeepSeek 在 arXiv 上放出 31 页的系统报告《DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale》（2609.22978），并迅速冲上 Hacker News 首页（315 分）。当大家都在讨论 DeepSeek 的模型时，这份论文披露的是更不常被外界看到的那一层：支撑 agentic 强化学习跑起来的生产级沙箱基建。单一生产单元约 160 个节点，每天创建约 300 万个沙箱，稳态并发超过 38 万，峰值每秒新建 5000 个——这组数字本身就值得系统工程师逐行读一遍。
一、问题：agent 训练负载为什么特殊
LLM 的 agentic 训练要求模型在隔离环境里检查仓库、调用工具、执行命令、与任务服务交互，每个 rollout 都要一个有状态的执行环境。这类负载有四个反常特征，论文引言部分概括得很准确。
第一，沙箱以「大突发」方式创建：RL 采样是批量的，一个训练步可能同时要几万个新环境，瞬间创建压力远超稳态。第二，异构性极强：有的任务只需要一次函数调用，有的需要完整操作系统，隔离等级和资源形态跨度巨大。第三，状态保留时间长：一个多轮 agent 任务可能持续几十分钟，中途环境不能丢。第四，镜像语料庞大而复用率低：成千上万个任务环境各不相同，传统镜像缓存的命中率假设在这里失效。
这四条加起来，结论是通用容器平台做不了这件事，需要一个弹性执行平台（elastic execution platform），而不是一个更好的单机沙箱运行时。
二、架构：四种后端，一个 SDK
DSec 的第一层设计是后端分级。统一 SDK 之下暴露四种沙箱后端：FnCall（函数调用级）、容器（container）、microVM、完整 VM。隔离强度递增，运行开销也递增。平台层负责跨集群的放置与生命周期管理，按任务的隔离需求与资源需求做匹配——这个抽象让上层的 RL 框架完全不用关心任务跑在哪种后端上。
环境组装走独立版本化层的组合，类似 Nix 思路的镜像分层：不同任务环境共享底层依赖层，差异只在顶层。镜像数据不预分发，而是按需从集群级分布式文件系统 3FS（Fire-Flyer File System）加载。这两条配合，把「环境准备」和「镜像分发」两大开销源同时压了下来。
密度是另一个重点。DSec 组合了内存共享、内存回收和 CPU 调度三招实现高密度超卖。论文的评测部分显示，这些机制在高密度超卖下仍能保住延迟敏感任务的性能——对 RL 来说，环境响应慢直接拖慢训练步，这是硬约束。
三、与 RL 框架的协同设计
DSec 最有意思的部分是它和 RL 框架的关系。训练侧的 GPU 是可抢占的：参数更新、梯度同步随时要独占整机资源；而 rollout 侧的沙箱是有状态的，中间不能丢。DSec 把「有状态的 rollout 执行」与「可抢占的 GPU 训练」解耦，协调沙箱生命周期与训练进度——训练侧要资源时，空闲沙箱被回收；rollout 未完成时，其状态被保留，等资源归还后续跑。
这套协同同时服务于安全侧：环境版本化与生命周期协调让 agent 的异常行为（论文里点名 reward hacking）可复现、可审计、可干预。论文把「缓解 agent 不当行为」列为平台职责之一，这在基建论文里是个值得注意的立场——环境层的安全能力正在成为训练平台的标准配置。
四、数字与验证
生产规模与性能数据汇总如下：
单一生产单元节点数 约 160
日创建沙箱数 约 3,000,000
稳态并发沙箱 380,000+
沙箱创建速率 5,000+/秒
论文规模 31 页 / 13 图 / cs.DC这组数字值得换算一下体感：按每天 300 万次创建计算，平均每 28.8 毫秒就要新建一个沙箱；38 万稳态并发的意思是，任何一个瞬间都有相当于一座中型互联网公司全部容器规模的环境同时活着、各自运行着一段可能长达几十分钟的 agent 任务。在这么高的创建频率下还能保持创建延迟可控，靠的是前面说的分层镜像加 3FS 按需加载——如果每次创建都要完整拉取镜像，这个量级的磁盘 IO 与网络流量根本不可行。
评测部分报告了三类结果：环境设置与镜像分发开销显著下降；内存效率提升；高密度超卖下延迟敏感任务性能保持。对系统会议的审稿标准来说，这些是在真实生产负载上跑出来的数据，比纯合成 benchmark 有说服力得多。另外值得注意的是论文的版本沿革：两页扩展摘要通过 ATC 2026 运营系统赛道的一轮评审后，团队把内容扩充成完整的 31 页报告，把生产部署经验一并写入——这种「摘要先行、全量随后」的发布节奏本身也反映了工业界系统工作的成熟做法。
五、值得对照阅读的三个细节
细读论文，有三个容易被略过但很有信息量的设计决策。其一，FnCall 后端的存在说明 DeepSeek 把「工具调用」也当成需要隔离的执行环境来管理，而不是在推理服务里顺手执行——这意味着工具执行的审计、限流、重试全部收口到平台层，与上周末热议的 agent 边界安全问题正好呼应。其二，镜像层的独立版本化让「环境本身可被测试与回滚」，环境从一次性产物变成了有版本的资产，这是环境可信的前提。其三，论文明确把「缓解 reward hacking」写进平台职责，说明在 DeepSeek 的工程实践里，安全能力（环境可复现、行为可审计）与性能能力（密度、延迟）是一体两面，不分开建设。
五、工程启示
对大多数读者来说，DSec 的直接价值不是「照着搭一个」，而是四个可迁移的模式。其一，隔离分级：不要所有任务都上容器或 VM，按威胁模型分后端，成本能差一个量级。其二，镜像按需加载：把镜像当数据而非静态资产，从共享文件系统流式取，别复制。其三，状态与算力解耦：凡是「会话有状态、算力可抢占」的系统（不只是 RL，在线推理服务同理），这个模式都成立。其四，密度靠调度：内存共享加精细 CPU 调度的收益，往往超过单纯加机器。
更宏观地看，这篇论文和过去一年各家披露的训练基建报告一起，勾勒出一个趋势：agentic 能力的竞争正在从模型层下沉到环境层。谁能低成本、高密度、可信地生成和销毁一百万个环境，谁就能跑更多轮 RL。模型论文讲方法，环境论文讲产能——DeepSeek 把产能账本摊开给行业看，这份透明度本身就是稀缺品。