DeepSeek Elastic Compute：面向Agentic RL的大规模沙箱基础设施设计与实践

1. 为什么这个标题值得花时间深挖

第一次看到“DeepSeek Elastic Compute”这个全称的时候，我下意识以为又是一个换皮容器调度项目。直到把 DSec 这个缩写和 Sandbox、Agentic、RL 三个词摆在一起，才意识到它想解决的是一个更底层、也更烧钱的问题：当你要用强化学习去训练一个能自己动手操作环境的智能体时，成千上万个并发的隔离沙箱从哪来，怎么管，怎么在训练循环里被高频地创建和销毁而不把集群拖垮。

做过 Agentic RL 的人都知道，这类训练和传统的大模型微调完全不是一个路数。SFT 阶段你喂的是静态数据，GPU 是瓶颈；到了 RL 阶段，模型要真的去“做事情”——执行代码、调用工具、操作文件系统、跑测试用例——每一步交互都需要一个干净、隔离、可回滚的运行环境。一个训练 step 里，几千条 rollout 同时展开，就意味着几千个沙箱同时活着。这时候瓶颈从 GPU 悄悄转移到了 CPU、内存、存储和调度系统上。

DSec 就是冲着这个瓶颈去的。它把自己定位成“面向大规模智能体训练的高效沙箱基础设施”，核心关键词是Elastic（弹性）和Sandbox（沙箱）。前者说的是资源能按训练负载动态伸缩，后者说的是每个 rollout 都有独立的、可快速重置的执行环境。这套东西适合谁看？我认为有三类人：一是正在搭 Agentic RL 训练管线、被环境管理折磨的算法工程师；二是做代码智能体、需要大规模并行执行验证的平台开发者；三是对“训练基础设施”这个方向感兴趣、想理解 RL 训练为什么比 SFT 复杂一个数量级的技术人。

这篇笔记我不打算复述论文摘要，而是按我自己的理解路径，把 DSec 的设计动机、核心机制、实操层面的坑，以及它和现有方案（比如容器编排、微虚拟机）的取舍关系，一层层拆开讲。读完之后你应该能判断：自己的训练场景到底需不需要这样一套东西，以及如果要落地，哪些参数和环节是必须盯死的。

2. 先搞清楚 Agentic RL 到底在训练什么

2.1 从静态数据到动态交互的范式切换

传统的大模型训练，无论是预训练还是 SFT，本质都是“给定输入，预测输出，算 loss，反向传播”。数据是提前准备好的，训练过程是确定性的，环境是静态的。你唯一需要操心的就是数据质量和 GPU 利用率。

Agentic RL 把这套逻辑整个掀翻了。模型不再是被动地预测下一个 token，而是主动地在一个环境里采取动作。举个最典型的例子：训练一个能修 bug 的代码智能体。模型看到一段报错信息和一个代码仓库，它要决定下一步做什么——是读某个文件，还是跑一次测试，还是直接改代码。每做一个动作，环境的状态就变了，模型拿到新的观测，再决定下一步。整个过程是一棵不断分叉的决策树，而 RL 要做的就是在这棵树上找到让最终任务成功率最高的策略。

这里的关键在于：环境是有状态的，而且状态会被模型的动作改变。这就意味着你不能像 SFT 那样把数据打包成 batch 一次性喂进去，你必须为每一条 rollout 维护一个独立的、活的执行环境。这就是沙箱存在的根本原因。

2.2 沙箱在训练循环里扮演的角色

很多人第一次接触这个概念时，会误以为沙箱只是个“安全隔离”措施，防止模型执行危险代码把宿主机搞崩。这个理解只对了一半。在 Agentic RL 里，沙箱承担的是三重职责：

• 隔离性：每条 rollout 的环境必须互不干扰。A rollout 改了/tmp/test.py，不能影响 B rollout 的同一个文件。这是正确性的底线。
• 可重置性：一条 rollout 结束后，环境要能被快速清理并复用给下一条 rollout。如果每次都要重新拉一个完整容器镜像，训练速度会被拖到无法接受。
• 可观测性：训练系统需要能拿到环境里的执行结果——退出码、stdout、文件变更——这些是计算 reward 的原始信号。

这三重职责叠加起来，对基础设施提出的要求就非常苛刻了。你既要隔离（意味着不能共享进程空间），又要快（意味着不能每次都冷启动），还要能高频读写（意味着存储层不能是瓶颈）。DSec 的整个设计，基本就是在回答“如何同时满足这三点”。

2.3 为什么传统容器方案会在这里撞墙

我见过不少团队的第一版方案，就是直接用 Docker 或 Kubernetes 起容器当沙箱。跑小规模实验没问题，一旦 rollout 数量上到几千并发，问题就全冒出来了。

第一个撞墙点是启动延迟。一个标准容器从docker run到进程可执行，冷启动通常在几百毫秒到几秒之间。听起来不多，但如果你一个训练 step 要创建上万个沙箱，光启动开销就是几十分钟。RL 训练动辄几十万 step，这个成本会被放大到不可接受。

第二个撞墙点是资源开销。每个容器都有完整的文件系统层、网络命名空间、进程管理。即使里面只跑一个 Python 脚本，这些固定开销也跑不掉。几千个容器同时活着，光内存就被吃掉一大块，留给真正计算的资源反而少了。

第三个撞墙点是调度粒度。K8s 的调度单位是 Pod，粒度太粗，而且它的设计目标是长期稳定的服务，不是这种“创建-用完-销毁”的高频短生命周期负载。用它来管沙箱，就像用重型卡车送外卖，能送，但效率极低。

DSec 要解决的，正是这三个撞墙点。

3. DSec 的核心设计思路拆解

3.1 Elastic 这个词到底指什么

标题里的 Elastic 不是营销词，它对应的是一个非常具体的工程需求：沙箱池的规模要能跟着训练负载实时伸缩。

RL 训练的负载是波动的。一个 batch 里，有的 rollout 可能几步就结束了（模型很快给出了错误答案），有的 rollout 可能要跑几百步（模型在反复尝试）。这意味着同一时刻活跃的沙箱数量是动态变化的。如果沙箱池是固定大小的，要么高峰期不够用导致排队，要么低谷期大量资源闲置。

DSec 的弹性体现在两个层面。一是池化预热：维护一个预先创建好的沙箱池，需要时直接取，用完归还而不是销毁。这消除了冷启动延迟。二是按需扩缩：当池子里的空闲沙箱低于阈值时，后台异步补充；当长期闲置时，回收资源。这个逻辑和数据库连接池、线程池是同一个思路，只不过管理的是更重的资源。

这里有个容易踩的坑：池化预热听起来简单，但“归还”这一步必须保证环境被彻底重置。如果上一条 rollout 留下的文件没清干净，下一条 rollout 就会读到脏状态，训练信号直接被污染。DSec 在重置环节做了专门优化，这也是它区别于“裸容器池”的关键。

3.2 沙箱的隔离级别选择

隔离级别是个典型的取舍问题。隔离越强，开销越大；隔离越弱，越快但越不安全。业界常见的选择有这么几档：

DSec 面向的是“模型生成的、可能任意甚至恶意”的代码，所以进程级隔离肯定不够。但纯微虚拟机又太慢，扛不住高频创建。从它的定位看，它走的是一条轻量级强隔离的路线——在保证内核级隔离的前提下，把启动和重置开销压到最低。具体实现上，通常会借助轻量虚拟化技术配合快照恢复，让沙箱能从一个预热的“干净快照”瞬间恢复，而不是从头走一遍完整的启动流程。

这个选择的逻辑很清晰：Agentic RL 的沙箱生命周期极短（秒级到分钟级），但数量极大，所以单位时间的创建吞吐比单个沙箱的绝对性能更重要。快照恢复恰好能把“创建”这个动作从“启动一个系统”降级为“恢复一个内存状态”，量级上的差异就出来了。

3.3 和训练框架的耦合方式

DSec 不是一个孤立的沙箱系统，它必须和 RL 训练框架紧密配合。这里的设计要点在于接口的抽象层次。

如果沙箱接口设计得太底层（比如直接暴露“创建虚拟机”），训练框架就得自己管理生命周期，耦合太深，换个沙箱实现就要改一堆代码。如果设计得太高层（比如只暴露“执行一个任务”），又失去了灵活性，没法支持复杂的多步交互。

合理的做法是提供一个会话式接口：训练框架向 DSec 申请一个沙箱句柄，然后通过这个句柄执行一系列动作（执行命令、读写文件、查询状态），最后显式释放。DSec 在背后负责句柄到实际沙箱的映射、池化管理、重置和回收。这样训练框架只关心“我要一个环境，做这些事，然后还回去”，不关心环境是怎么来的。

这种抽象还有一个好处：它天然支持异步。训练框架可以一次性申请一批沙箱，并行下发动作，然后异步收集结果。这对提升 rollout 吞吐至关重要，因为沙箱操作大部分时间花在等待 IO 和进程执行上，同步等待会浪费大量时间。

4. 核心机制与实操要点

4.1 沙箱生命周期管理

理解 DSec 的关键，是把沙箱的生命周期拆成几个明确的阶段，每个阶段都有优化空间：

1. 创建（Create）：从池中取出一个预热好的沙箱，或触发新建。优化目标是消除冷启动。
2. 初始化（Init）：把任务需要的初始状态注入沙箱——代码仓库、依赖、环境变量。这一步往往是隐藏的性能杀手。
3. 执行（Execute）：模型与环境交互，执行一系列动作。这是沙箱真正“干活”的阶段。
4. 重置（Reset）：清理执行痕迹，恢复到干净状态。优化目标是增量重置而非全量重建。
5. 回收（Recycle）：归还到池中或销毁。

我特别想强调初始化这一步。很多团队在优化时只盯着创建和重置，却忽略了初始化。实际上，如果每个沙箱都要重新 clone 一个代码仓库、重新装一遍依赖，那前面的池化优化全白费了。正确的做法是把“基础环境”和“任务数据”分离：基础环境（操作系统、运行时、常用工具）在池化阶段就准备好，任务数据（具体的代码、测试用例）通过轻量级的挂载或增量拷贝注入。DSec 的设计里应该体现了这种分层思想。

实操心得：初始化阶段最容易被忽视的是依赖预热。如果任务需要 Python 环境，而每个沙箱都要现装包，那 pip 的网络 IO 会成为巨大瓶颈。解决办法是在基础镜像里预装高频依赖，或者用一个本地包缓存层。我见过一个团队因为没做这件事，训练吞吐只有理论值的十分之一。

4.2 快照与增量重置的实现逻辑

重置是沙箱复用里最微妙的一环。全量重建（销毁再创建）最干净但最慢；增量重置（只删掉改动）最快但容易漏。

DSec 这类系统通常采用写时复制（Copy-on-Write）加快照回滚的组合。基础环境是一个只读的共享层，所有沙箱都基于它启动。当沙箱内发生写操作时，改动被记录在一个独立的可写层里。重置时，只需要丢弃这个可写层，沙箱就回到了初始状态。这个过程不需要重新加载操作系统，也不需要重新初始化运行时，所以极快。

这个机制的关键参数是可写层的存储介质。如果用磁盘，回滚虽然快但写入慢；如果用内存，写入快但容量受限。实际部署时通常需要根据任务的内存占用特征来调优。对于大部分代码执行任务，可写层用内存加临时磁盘的混合方案比较稳妥。

还有一个细节是快照的粒度。如果快照点设在“操作系统启动完成”，那重置后还要重新启动应用运行时；如果设在“运行时初始化完成、任务数据已注入”，那重置后可以直接执行。后者更快，但快照点越靠后，快照本身占用的资源越多，池化成本越高。这个平衡点需要根据任务特征实测确定。

4.3 并发调度与资源配额

当几千个沙箱同时运行时，调度器面临的核心问题是：如何在不超卖资源的前提下，最大化并发。

这里有个反直觉的点：沙箱的 CPU 和内存配额不能按“峰值需求”来分配，否则资源利用率会低得可怕。因为大部分沙箱在大部分时间里是空闲的——它们在等模型推理、等网络、等 IO。正确的做法是超卖加限流：按统计规律分配资源，同时用 cgroup 之类的机制做硬限制，防止个别沙箱失控拖垮整机。

DSec 的弹性调度应该包含这么几层控制：

• 全局配额：整个集群能承载的最大沙箱数，由物理资源决定。
• 单机配额：每台宿主机上的沙箱密度，需要根据任务的平均资源占用实测。
• 单沙箱限制：每个沙箱的 CPU、内存、磁盘、进程数上限，防止单点失控。

注意：单沙箱的进程数限制特别容易被忽略。模型生成的代码可能 fork 出一堆子进程，如果不限制，一个沙箱就能把宿主机的进程表打满，导致整台机器上的所有沙箱一起挂掉。这个坑我在早期实验里踩过，排查了半天才发现是 fork 炸弹。

4.4 与 RL 训练循环的对接细节

把 DSec 接进训练循环，有几个工程细节决定了成败。

第一是批量申请与释放。不要一条 rollout 申请一个沙箱、用完立刻释放，这样调度器会被高频请求打爆。更好的做法是按 batch 申请，一个 batch 的 rollout 共享一批沙箱，batch 结束后统一释放。这样调度开销被摊薄。

第二是超时与容错。模型可能生成死循环代码，沙箱可能因为各种原因卡住。必须有硬超时机制，到点强制终止并回收沙箱，同时给这条 rollout 一个明确的失败信号，让 RL 的 reward 计算能正确处理。没有超时保护的训练管线，迟早会被一条卡死的 rollout 拖垮整个 step。

第三是结果的结构化返回。沙箱执行完一个动作后，返回给训练框架的不应该只是原始 stdout，而应该是结构化的结果：退出码、标准输出、标准错误、文件系统变更摘要、资源消耗统计。这些信息既用于计算 reward，也用于监控和调试。返回格式设计得好，后续排查问题会轻松很多。

5. 实操过程与关键环节复现

5.1 环境准备与基础镜像构建

假设我们要基于 DSec 的思路搭一套自己的沙箱训练环境，第一步是构建基础镜像。这一步的目标是：把所有不随任务变化的东西都固化进去。

基础镜像里应该包含：

• 精简的操作系统（越小越好，减少快照体积）
• 任务需要的运行时（Python、Node、编译器等）
• 高频依赖包（预装，避免运行时下载）
• 监控和日志代理（用于采集沙箱内部状态）

构建时有个技巧：分层构建，把变化频率低的层放下面。操作系统在最底层，运行时在中间，任务相关的东西在最上层。这样池化时只需要共享底层，上层按需注入，快照体积和恢复时间都能压下来。

# 基础镜像构建的示意流程（以容器化方案为例） # 1. 拉取精简基础镜像 FROM ubuntu:22.04 # 2. 安装运行时和常用工具，合并为一层减少层数 RUN apt-get update && apt-get install -y \ python3 python3-pip git curl \ && rm -rf /var/lib/apt/lists/* # 3. 预装高频 Python 依赖 RUN pip3 install --no-cache-dir numpy pandas pytest # 4. 设置工作目录和默认用户 WORKDIR /workspace

镜像构建完成后，要实测它的冷启动时间和快照恢复时间。这两个数字直接决定了池化策略的参数。如果冷启动要 5 秒，那池子的预热数量就得足够大，否则高峰期会排队。

5.2 沙箱池的参数计算

池子大小不是拍脑袋定的，需要根据训练负载算。核心公式是：

所需沙箱数 = 峰值并发 rollout 数 × 安全系数

峰值并发 rollout 数由 batch size 和 rollout 的平均步数决定。假设 batch size 是 512，每条 rollout 平均 20 步，每步平均耗时 2 秒，那么一条 rollout 平均存活 40 秒。如果训练框架希望一个 step 在 60 秒内完成，那需要的并发沙箱数大约是：

并发数 = batch_size × 平均存活时间 / step 目标时间 = 512 × 40 / 60 ≈ 341

再乘一个 1.5 到 2 的安全系数，池子大小定在 500 到 700 之间比较稳妥。安全系数是为了应对 rollout 步数分布的长尾——总有那么几条 rollout 会跑得特别久。

实操心得：这个计算里的“平均步数”和“平均步耗时”必须用真实数据统计，不能估。我建议先跑一个小规模实验，采集 rollout 的步数和耗时分布，再据此定池子大小。用 P95 而不是平均值来估算长尾，能避免高峰期频繁触发扩容。

5.3 训练循环的对接代码结构

把沙箱接进训练循环，代码结构大致是这样的：

# 训练循环中沙箱使用的示意结构 def rollout_worker(task, sandbox_pool): # 1. 从池中申请沙箱 sandbox = sandbox_pool.acquire(timeout=30) try: # 2. 注入任务数据 sandbox.inject(task.repo, task.test_cases) # 3. 多步交互循环 for step in range(MAX_STEPS): action = model.predict(sandbox.observe()) result = sandbox.execute(action, timeout=STEP_TIMEOUT) if result.done: break # 4. 计算 reward reward = compute_reward(result) return reward finally: # 5. 无论成功失败都归还沙箱 sandbox_pool.release(sandbox)

这段结构里有几个关键点。acquire带超时，防止池子耗尽时无限等待；inject是轻量级的，只注入任务相关数据；execute带单步超时，防止死循环；finally保证沙箱一定被归还，即使中间抛异常。最后一点特别重要，漏归还沙箱会导致池子逐渐枯竭，训练跑着跑着就卡住了。

5.4 监控指标与调优方向

上线之后，需要盯几个核心指标来判断系统是否健康：

调优的顺序建议是：先保证正确性（重置干净、无脏状态），再优化吞吐（池子大小、重置速度），最后压成本（提高密度、降低空闲率）。顺序反了会很难受，因为在不干净的基础上优化性能，等于在流沙上盖楼。

6. 常见问题与排查技巧实录

6.1 沙箱状态污染

现象：训练 reward 出现莫名其妙的波动，同一批任务有时成功有时失败，且失败没有规律。

排查思路：这大概率是沙箱重置不彻底导致的。上一条 rollout 留下的文件、环境变量、后台进程，污染了下一条 rollout。排查方法是给每个沙箱加一个“指纹”——在重置后检查关键路径是否为空、关键环境变量是否为默认值、是否有残留进程。

解决：重置逻辑要覆盖文件系统、进程表、环境变量、网络连接四个维度。文件系统用可写层丢弃最干净；进程表要确保所有子进程被杀掉（注意进程组）；环境变量要恢复到快照状态；网络连接要确保没有残留的监听端口。

6.2 池子耗尽导致训练卡死

现象：训练跑一段时间后，所有 worker 都卡在 acquire 上，GPU 利用率掉到零。

排查思路：要么是池子太小，要么是有沙箱泄漏（借了没还）。先看池子的空闲数曲线，如果持续下降不回升，就是泄漏。泄漏的常见原因是异常路径下没有释放沙箱，或者释放时重置卡住导致沙箱无法回到池中。

解决：给 acquire 加超时和告警；给沙箱加“租约”，超时未归还强制回收；在 release 路径上加监控，重置超过阈值就告警。

6.3 单沙箱拖垮整机

现象：某台宿主机上的所有沙箱突然全部变慢或失败。

排查思路：典型的资源失控。某个沙箱跑了内存泄漏的代码，或者 fork 了一堆进程，把整机的资源吃光。因为沙箱之间共享宿主机内核，一个失控会波及全部。

解决：给每个沙箱加硬性资源限制——内存上限、进程数上限、CPU 时间上限。用 cgroup 做强制隔离，超限直接 OOM kill 或拒绝 fork，而不是让整个机器陪葬。

6.4 快照恢复后行为不一致

现象：从快照恢复的沙箱，执行结果和全新启动的沙箱不一致。

排查思路：快照可能捕获了不该捕获的状态，比如随机数种子、时间戳、临时文件。或者快照点选得不对，捕获了一个中间状态。

解决：快照点要选在“干净且确定”的状态。恢复后要重新初始化所有非确定性因素（随机种子、时钟）。这个问题的隐蔽性很强，建议在池化上线前做一轮“快照 vs 全新”的一致性对比测试。

6.5 常见问题速查表

7. 这套方案适合谁，以及落地时的取舍

7.1 什么规模才值得上 DSec 这类方案

不是所有 Agentic RL 都需要这么重的基础设施。我的判断标准是并发沙箱数和训练迭代频率。

如果你只是做小规模实验，几十个并发沙箱，用现成的容器方案完全够用，没必要自己搭一套池化系统，维护成本反而更高。当并发数上到几百、训练要跑几十万 step 的时候，沙箱管理的开销才会成为真正的瓶颈，这时候 DSec 这类方案的价值才体现出来。

另一个判断维度是任务的环境复杂度。如果任务只是执行一段纯计算代码，环境很轻，那优化空间有限。如果任务涉及完整的代码仓库、多文件操作、依赖安装，那环境初始化和重置的成本会很高，池化和快照的收益就非常明显。

7.2 自建还是复用现有方案

DSec 的思路是可以借鉴的，但不一定要照搬实现。落地时有几个选择：

• 直接用容器加自建池化层：实现简单，但容器本身的启动和重置开销摆在那，优化天花板有限。
• 用轻量虚拟化加快照：性能好，但技术门槛高，需要熟悉底层虚拟化。
• 用现成的沙箱服务：省事，但灵活性和成本控制受限，且可能不适合大规模并发。

我的建议是：先用容器方案跑通训练流程，验证算法和 reward 设计没问题；等确认瓶颈确实在沙箱管理上，再考虑往轻量虚拟化迁移。不要一上来就追求极致性能，把算法问题掩盖在基础设施问题里，最后两头都调不明白。

7.3 我个人踩过的几个坑

最后分享几个我在类似系统里踩过的坑，都是文档里不会写的。

第一个是日志爆炸。每个沙箱都往宿主机写日志，几千个沙箱同时写，磁盘 IO 直接被打满。解决办法是沙箱内日志先写本地缓冲，批量异步上报，或者干脆只在需要时按需拉取。

第二个是时间同步。沙箱里的时钟如果和宿主机不同步，涉及超时判断的逻辑会出诡异问题。快照恢复的沙箱尤其容易时钟漂移，恢复后要强制同步一次。

第三个是镜像版本管理。基础镜像更新后，池子里的旧沙箱和新沙箱行为不一致，导致训练结果不可复现。解决办法是给镜像打版本号，池子按版本隔离，训练任务绑定固定版本。

第四个是网络隔离的副作用。为了安全，沙箱通常禁网。但有些任务需要下载依赖，禁网后直接失败。折中方案是提供一个受控的包缓存代理，只允许访问白名单资源，既保证安全又不影响功能。

这套东西说到底，核心矛盾永远是隔离性、性能、成本三者之间的平衡。DSec 给出的答案是在保证内核级隔离的前提下，用池化和快照把性能拉满，用弹性调度把成本压住。理解了这个主线，具体实现怎么选，就看你自己的场景更偏向哪一端了。