一、事件概述

2026 年 9 月 19 日，一篇题为 《DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale》 的论文提交至 arXiv，归类于 cs.DC（分布式、并行与集群计算）。作者署名由 Jialiang Huang 领衔，加上 130 位其他作者，共 131 人，通讯提交人为 Wenfeng Liang。论文长 31 页、含 13 张图，据摘要页说明，这一版本由更早的两页扩展摘要大幅扩充而来，该扩展摘要曾通过 ACM SIGOPS ATC 2026 操作系统实践赛道（Operational Systems Track）的首轮评审。

这篇工作讨论的不是模型结构，而是智能体（Agent）训练背后的执行环境基础设施：一个名为 DeepSeek Elastic Compute（DSec）的生产级沙箱平台。该文在 Hacker News 首页获得 147 分、41 条评论。

二、问题背景：为什么”单个沙箱运行时”不够用

论文的出发点很明确：基于大语言模型的规模化 Agentic 训练与评测，依赖隔离且有状态的执行环境——模型需要在其中检查代码仓库、调用工具、执行命令、与任务相关的服务交互。

作者指出，这类负载有四个特征，决定了它无法由一个沙箱运行时来承载：

  1. 突发式创建：沙箱以大批量”脉冲”形式产生；
  2. 异构性强：功能需求与隔离等级差异很大；
  3. 长时保状态：长交互过程中必须保留状态；
  4. 镜像复用率低：需要从庞大的镜像库中按需取用，且重复利用率有限。

因此论文的结论是：需要的是一套弹性执行平台（elastic execution platform），而非单一沙箱运行时。

三、关键技术点

根据摘要，DSec 的核心设计可以归纳为以下几个层面：

1. 统一 SDK + 多级隔离后端

DSec 通过统一 SDK 对外暴露四种沙箱后端：

  • FnCall
  • 容器（container）
  • microVM
  • 完整虚拟机（full-VM）

这种分层设计对应了前述”异构隔离需求”的问题：不同任务按需选择不同强度的隔离边界。

2. 集群级编排与分层环境组装

DSec 在集群范围内协调沙箱的放置（placement）与生命周期管理，并从**可独立版本化的层（independently versioned layers）**组合出运行环境。原文未说明这些层的具体粒度与版本控制机制细节。

3. 高密度执行的三件套

为支撑高密度执行，DSec 组合使用了：

  • 内存共享（memory sharing）
  • 内存回收（reclamation）
  • CPU 调度（CPU scheduling）

4. 基于 3FS 的按需镜像加载

镜像数据从 Fire-Flyer File System（3FS）——一个集群级分布式文件系统——按需加载。这直接对应”镜像语料庞大且复用有限”的痛点，目标是压缩镜像分发开销。

5. 与 RL 框架协同设计：解耦 rollout 与训练

这是整篇论文中对 Agentic RL 最关键的工程点：

  • DSec 与强化学习框架协同设计；
  • 将有状态的 rollout 执行与可被抢占（preemptible）的 GPU 训练解耦；
  • 让沙箱生命周期与训练过程协调——在回收空闲资源的同时，保留 rollout 状态；
  • 同时缓解智能体的不当行为，例如奖励攻击（reward hacking）。原文未说明具体采用何种机制来抑制 reward hacking。

6. 生产规模数据

论文给出的实测规模（单个生产单元）：

指标 数值
节点规模 约 160 个节点
每日沙箱数 约 300 万个
并发沙箱峰值 超过 38 万个
沙箱创建速率 超过 5,000 个/秒

论文称，评测与部署经验表明这些机制降低了环境搭建与镜像分发开销、提升了内存效率，并在高密度超配（overcommit）下保持了时延敏感型性能。具体的压测方法、对照基线与时延分位数数值，摘要中未给出。

四、对数据科学与 AI Agent 落地的意义

第一，Agent 能力的瓶颈正在从”模型”转移到”环境”。 当训练范式从单轮问答转向多轮工具调用与代码执行，采样吞吐就不再只取决于 GPU 数量，而取决于”能同时开多少个干净、可复现、带状态的沙箱”。DSec 报出的 38 万并发、5,000 次/秒创建速率，本质上是在定义一个新的训练吞吐上限——沙箱供给速率即采样速率。

第二，这为 Agent 评测的可复现性提供了基础设施级保障。 隔离、有状态、按需镜像加载，正是让”同一个 Agent 在同一个任务上跑两次能得到可比结果”的前提。对企业落地而言，这意味着评估流水线可以像 CI 一样被工程化，而不再是人工搭环境的作坊式操作。

第三，”与 RL 框架解耦 rollout 与训练”是一条重要的架构范式。 训练侧 GPU 作业可被抢占，而 rollout 沙箱保留状态，等于把”昂贵且稀缺的 GPU”与”廉价但状态敏感的 CPU 侧沙箱”分别做资源调度。任何自建 Agentic RL 流水线的团队，都值得把这条设计原则抽象出来复用。

第四，reward hacking 被放进系统设计议程。 论文把它与沙箱生命周期放在同一段讨论，说明在真实规模化训练中，Agent 钻评测环境空子已经是必须由基础设施层参与治理的问题。不过原文未说明 DSec 是依靠环境隔离、行为监控还是奖励塑形来缓解这一问题。

需要说明的是，DSec 是否开源、是否有公开的 API 或部署文档，原文未说明；其与其它公开沙箱方案（如各类 microVM 或容器编排方案）的横向对比，摘要中也没有呈现。

五、我的技术点评

这篇论文最有意思的地方，是它把一篇系统论文写在了 LLM 训练论文的坐标里。过去我们习惯把基础设施当作”没有研究价值的工程活”，但 DSec 提出的问题——突发创建、异构隔离、长时状态、低复用镜像——每一条都不是传统云原生调度器天然擅长的。尤其是”生成式负载的沙箱模式与常规微服务完全不同”这一点，我认为是全文最有分量的判断。

其次，“解耦 rollout 与训练”是我最看重的设计。它把 Agentic RL 的真实成本结构暴露出来了：GPU 是尖峰资源，沙箱是长尾资源，两者的生命周期根本不该绑定。任何做过 Agent 数据生产的人都会承认，最痛的往往不是模型不收敛，而是采样环境挂了、状态丢了、任务要重跑。

同时也要保持一点冷静。摘要给出的都是规模与工程收益，而规模数字本身不构成科学结论：300 万/天、38 万并发听起来震撼，但缺少端到端训练效率提升、单位成本下降、以及 reward hacking 缓解幅度的量化。131 位作者的署名规模，也从侧面说明这是一份典型的”大厂生产系统报告”，其价值更多在于把一套已被验证可行的工程约束公开化，而不是提出新的算法洞见。

对从业者的实际建议是：如果你的团队正在自建 Agent 训练/评测环境，不必照搬 DSec 的多级后端，但值得先回答它的三个问题——沙箱创建是突发还是平滑？隔离等级是否需要分级？rollout 状态在训练侧抢占时如何不丢？ 能答清楚这三点，基础设施的设计方向基本就定了。

六、原文链接

引用信息：arXiv:2609.22978 [cs.DC]，v1 提交于 2026 年 9 月 19 日 12:20:26 UTC。