DeepSeek 公开 DSec 沙盒平台，Agent 训练日造三百万环境

2026 年 9 月 19 日，DeepSeek 在预印本平台 arXiv 上传了一篇技术报告，标题是《DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale》，提交人署名 Wenfeng Liang（梁文锋），作者名单超过 130 人。论文在 9 月 23 日前后被中文科技媒体大量转述，知乎相关讨论热度一度冲到 186 万。

这件事的主角不是新模型，而是一套叫 DSec 的沙盒基础设施。用一句话说：它把「给 Agent 批量制造可运行环境」这件事，从各家自建的手工作坊，做成了一个可以按秒调度的生产系统。论文给出的量级是——单个生产规模单元每天服务约 300 万个沙盒，生产环境中同时运行超过 38 万个，每秒创建超过 5000 个。

对普通读者，这条新闻本身没有可直接下载的产品；对做 Agent 的开发者，它透露的是 DeepSeek 下一步的训练方式，以及一个被长期忽略的成本项：环境，而不只是算力。

论文把 DSec 定义为一个生产级沙盒平台：它通过一套统一的 SDK，同时对外暴露四种后端——FnCall（函数调用）、容器（container）、microVM 和完整虚拟机（full-VM）。同一套接口覆盖从轻量函数到强隔离整机，团队不必为每种任务各搭一套系统。

为什么需要「平台」而不是「一个沙盒运行时」？论文对 Agent 训练负载的描述很具体：沙盒是成批突发创建的，隔离与功能需求高度异构，长交互必须保留状态，而镜像语料库很大、复用率有限。这四条特征叠加，决定了瓶颈往往不在单次启动快不快，而在成千上万个环境能否被统一放置、回收和复用。

DSec 的做法是跨集群统一做放置与生命周期管理，把运行环境拆成可独立版本化的层来组合；再把内存共享、内存回收和 CPU 调度合起来做高密度执行；镜像数据则按需从 3FS（Fire-Flyer File System）这个集群级分布式文件系统加载，而不是一次性全量分发。

论文给出的数字是理解这套系统的关键：一个生产规模单元约 160 个节点，日服务约 300 万个沙盒，生产环境并发超过 38 万个，创建速率每秒超过 5000 个。评测与部署经验显示，这些机制降低了环境准备和镜像分发的开销，提升了内存效率，并在高密度超卖下保住了对延迟敏感的性能。

更值得关注的是它和强化学习框架的协同设计。DSec 把「有状态的 rollout 执行」与「可被抢占的 GPU 训练」解耦：训练任务可以随时抢占资源，而沙盒的生命周期跟着训练节奏协调，既保住 rollout 中途的状态，又回收空闲资源。论文还提到，这套协同能缓解 reward hacking 这类 Agent 异常行为。

这篇报告共 31 页、13 张图，完整原文可在 arXiv:2609.22978 查看，其中包含架构、调度与评测章节，适合 Infra 与训练工程师逐节核对。

过去两年，做 Agent 强化学习的团队普遍把预算算在 GPU 上，环境层则靠工程堆人：写镜像、做分发、处理并发上限、为长任务保状态、在训练抢占时抢救 rollout。DSec 的披露说明，头部团队已经把这些当成一等公民的基础设施问题来解决。

对谁有影响，可以分三层看。做 Agent RL 训练的团队：最该读的是它与 RL 框架协同、以及抢占时保住状态的部分，这直接决定有效训练吞吐。做评测与数据合成的团队：关注突发创建和镜像按需加载，因为它们决定了你能跑多大规模的并行评测。平台与 Infra 团队：关注分层镜像、内存共享与回收，这些是可迁移的设计思路。

怎么验证，也要说清楚：目前 DSec 只是论文层面的技术报告，没有公开的开源仓库或对外 API。所以现在能做的验证，是拿论文里的量级和方法，对照自己系统的瓶颈做一次体检——你的环境准备耗时占比多少？镜像分发是不是瓶颈？训练抢占时丢了多少 rollout？这几个问题比「要不要换方案」更实际。

常见做法大致几类：以 Firecracker、gVisor 为代表的隔离运行时，Kubernetes 加 Kata 的编排方案，以及 E2B、Daytona 这类面向代码执行的云沙盒服务。它们大多解决「安全地跑起来一段不可信代码」，隔离粒度与启动速度是主战场。

DSec 的差异点在两处。一是多后端统一：函数调用、容器、microVM、整机四类后端共用一套 SDK，任务按隔离需求切换，而不是全站押注一种运行时。二是为训练而生：把沙盒生命周期与 RL 训练、GPU 抢占绑在一起调度，并用 3FS 按需加载镜像，这是通用云沙盒通常不涉及的部分。

但要说清楚边界：论文没有说明 DSec 是否开源、是否对外提供接口，因此它现在不是能直接替换 Firecracker 或 E2B 的选项。它更像是 DeepSeek 内部训练体系的公开切片，其他团队能借鉴的是设计取舍，而不是现成的替代品。

论文没有给出对外定价，也没有说明商业化计划，因此「成本」目前只能按资源口径理解：160 节点支撑日 300 万沙盒，意味着单位环境的资源开销被压得很低，而高密度超卖与内存回收是达成这一数字的前提。自建方案若达不到同等密度，成本会明显更高。

风险同样要讲。把沙盒生命周期与训练调度深度耦合，是一把双刃剑：耦合带来效率，也意味着实现复杂度高、出错面大，论文里对 reward hacking 的缓解也依赖具体实现，外部团队难以直接照搬。此外，四类后端并存对运维和安全隔离提出了更高要求，隔离策略一旦配错，风险会被高并发放大。

编辑判断：这条新闻的价值不在「今天就能用上」，而在它标出了 Agent 竞争的下一段赛道——谁能在同等算力下跑更多、更真的训练环境。如果你的团队在做 Agent，现在最值得做的一件事，是把你自己的环境层数据补齐，再对照论文里的协同思路找差距。

接下来有三个观察点。第一，DSec 是否会开源或开放 SDK，如果开放，通用 Agent 训练的环境成本会整体下移。第二，它是否会出现在 DeepSeek 官方文档或后续模型公告中，那意味着这套设施已经进入常规训练流程。第三，其他厂商会不会跟进类似的「沙盒 + RL 协同」设计，一旦形成共识，环境层就会从各家私活变成标准组件。

对读者来说，判断标准很简单：如果你只需要调用现成模型，这条新闻可以只看结论；如果你在做 Agent 训练、评测或平台建设，建议花一小时读一遍 31 页原文，重点看调度、内存回收和与 RL 框架协同的部分。

本文由 AI 潮汐编辑部基于官方公告与公开资料整理，补充了行业影响、适用场景和行动建议，帮助你在阅读原文前先理解这条信息为什么重要。

原始来源：https://arxiv.org/abs/2609.22978

如发现事实、价格或链接有误，可通过 联系我们 提交更正。