DeepSeek DSec 弹性沙箱：Agentic RL 训练基础设施的工程实践

1. 从标题拆解：DSec 到底想解决什么问题

第一次看到 "DeepSeek Elastic Compute (DSec) A Sandbox Infrastructure for Effective Agentic Training at Scale" 这个标题，我脑子里蹦出来的第一个念头是：终于有人把 Agentic RL 训练里最脏最累的那块活儿单独拎出来讲了。标题里三个关键词——Elastic Compute、Sandbox Infrastructure、Agentic Training at Scale——每一个都踩在当前大模型后训练（post-training）最痛的神经上。

先说 Agentic Training。传统的 RLHF 或者 PPO 训练，环境基本是静态的：给一个 prompt，模型生成一个回答，reward model 打个分，完事。但 Agentic 场景完全不是这么回事。Agent 要调工具、要执行代码、要读写文件、要跟外部环境多轮交互，每一步的 action 都会改变环境状态，reward 往往是稀疏的、延迟的、甚至带随机性的。这就意味着训练框架必须能同时跑几千上万个"环境实例"，每个实例都是一个独立的、隔离的、可执行代码的沙箱。

再说 at Scale。小规模玩 Agentic RL，你开几个 Docker 容器手动管管就行了。但一旦上到千卡集群、上万并发环境，问题就爆炸了：容器生命周期管理、资源碎片、冷启动延迟、状态回收、故障隔离、安全边界……这些在传统训练框架里根本不是一等公民。DSec 这个标题里的 "Elastic Compute" 就是在说：算力要能像橡皮筋一样随训练负载伸缩，环境要能按需创建、用完即焚。

最后是 Sandbox Infrastructure。这个词是整篇论文的题眼。Sandbox 不是简单的 Docker 容器，它要满足几个硬性条件：强隔离（Agent 执行的代码不能污染宿主或其他实例）、快启动（RL 训练对 rollout 吞吐极其敏感，环境启动慢一秒，整体训练就慢一拍）、可观测（要能拿到 Agent 在沙箱里的完整轨迹用于训练）、可复现（同样的 seed 和 action 序列要能复现同样的环境状态）。这四点缺一个，Agentic RL 的训练效率就会大打折扣。

所以 DSec 的定位很清晰：它不是又一个训练框架，而是训练框架底下的环境执行层。你可以把它理解成 Agentic RL 的"操作系统"——上层是 PPO/GRPO 这类算法，下层是物理机/容器编排，DSec 夹在中间，负责把"环境"这个抽象变成可调度、可扩展、可观测的实体。适合读这篇论文的人，我建议是这几类：正在做 Agent 后训练但被环境管理拖垮的算法工程师、想搞清楚 Agentic RL 工程栈长什么样的研究者、以及需要给内部 Agent 平台做沙箱隔离的基础设施同学。

2. 核心设计思路：为什么是"弹性"而不是"固定池"

2.1 传统沙箱池方案的三个死穴

在 DSec 之前，业界做 Agentic RL 沙箱的主流做法是预分配容器池：训练开始前先起好 N 个容器，训练过程中从池子里借、用完还回去。这个方案在小规模下能用，但一上规模就暴露三个死穴。

第一个死穴是资源错配。Agentic 任务的执行时间方差极大：有的 action 就是查个表，几十毫秒返回；有的 action 要跑一段 Python 做数值计算，几秒甚至几十秒。固定池子里，慢任务会把容器占死，快任务排队等，GPU 在旁边干等着 rollout 数据，利用率直接掉到 30% 以下。我见过最夸张的案例，一个 8 卡节点跑 Agentic PPO，GPU 利用率长期在 25% 上下晃，瓶颈全在环境侧。

第二个死穴是冷启动税。容器池扩容时，新容器要拉镜像、装依赖、初始化运行时。一个带完整 Python 科学计算栈的镜像，冷启动动辄十几秒。RL 训练里 rollout 是高频操作，每个 step 都要几千次环境交互，这个冷启动税累积起来非常恐怖。更麻烦的是，Agentic 任务往往需要带状态的环境（比如一个持续运行的 REPL），不能简单地用完就杀。

第三个死穴是故障域不隔离。固定池子里，一个容器被 Agent 写崩了（比如 OOM、死循环、文件系统写满），可能连带影响同节点的其他容器。Agentic RL 里 Agent 会执行任意代码，这种"自伤"概率远高于传统推理场景。池子越大，故障传播的风险越高。

2.2 DSec 的弹性思路：按需创建 + 分层复用

DSec 的核心思路我概括成一句话：把沙箱从"预分配的静态资源"变成"按需创建的弹性资源"，同时用分层缓存把冷启动成本摊薄。具体拆成三个机制。

机制一：按需创建（On-demand Provisioning）。DSec 不再维护固定大小的容器池，而是维护一个"沙箱模板 + 快速克隆"的能力。训练侧需要环境时，向 DSec 发一个创建请求，DSec 在毫秒级从模板克隆出一个新沙箱。用完即销毁，资源立刻归还。这样资源利用率不再受池子大小限制，而是跟着实际负载走。

机制二：分层镜像与写时复制。冷启动问题的解法是分层：基础层（OS + 运行时）预烘焙在节点本地，中间层（Python 依赖、常用库）做节点级缓存，最上层（任务特定代码）才在创建时注入。配合写时复制（Copy-on-Write），克隆一个沙箱只需要复制最上层的差异部分，启动时间从十几秒压到百毫秒级。这个思路其实借鉴了容器镜像分层的经典做法，但 DSec 把它用在了 RL 训练的高频创建场景里。

机制三：状态快照与恢复。Agentic 任务经常需要"回滚"——比如 Agent 走错一步，训练算法想从某个中间状态重新 rollout。DSec 支持对沙箱做轻量快照，记录文件系统差异和进程状态，需要时快速恢复。这对tree search 类 RL 算法（比如 MCTS 增强的 Agent 训练）是刚需，没有快照能力，树搜索根本没法高效实现。

2.3 为什么这个设计对 Agentic RL 特别关键

我想强调一点：DSec 的弹性设计不是"为了弹性而弹性"，而是被 Agentic RL 的训练特性逼出来的。Agentic RL 的 rollout 有两个鲜明特点：高并发（同时几千个环境在跑）和高异构（每个环境的执行时间、资源需求、状态复杂度都不一样）。固定池方案在这两个特点面前必然低效，只有弹性方案才能让环境侧跟上 GPU 侧的节奏。

从影响范围看，DSec 这类基础设施一旦成熟，会直接改变 Agentic RL 的训练经济学。现在很多团队不敢上大规模 Agentic RL，不是因为算法不会，而是因为环境成本太高——环境侧的开销经常是 GPU 开销的 2 到 3 倍。DSec 把环境成本压下来之后，Agentic RL 的规模天花板会被显著抬高。这也是为什么我觉得这篇论文值得细读：它讲的不是某个 trick，而是整个训练栈的底座。

3. 核心细节解析：沙箱隔离、调度与可观测性

3.1 隔离级别怎么选：从 namespace 到 microVM

沙箱隔离是 DSec 最底层的技术选择，也是最能体现工程权衡的地方。隔离级别从弱到强大致有这么几档：进程级隔离（namespace + cgroup）、容器级隔离（Docker/containerd）、microVM 级隔离（Firecracker/Kata）、硬件级隔离（独立物理机）。每一档的隔离强度、启动延迟、资源开销都不一样。

DSec 的选择我理解是分层策略：默认用容器级隔离，对高风险任务（比如 Agent 要执行不可信代码）升级到 microVM。为什么不全用 microVM？因为 microVM 启动虽然比虚拟机快，但相比容器还是有几十毫秒到百毫秒的额外开销，在万级并发下这个开销会被放大。而容器级隔离对大多数 Agentic 任务（Agent 执行的是训练侧自己写的工具代码）已经够用。

这里有个实操细节值得说：namespace 的粒度选择。DSec 给每个沙箱独立的 PID namespace、mount namespace、network namespace，但共享内核。共享内核意味着如果 Agent 触发了内核漏洞，理论上可以逃逸。所以 DSec 在容器层之上加了 seccomp 过滤和 capability 裁剪，把危险系统调用（比如ptrace、mount、reboot）直接禁掉。这个组合在隔离强度和性能之间取得了不错的平衡。

提示：如果你自己在搭 Agent 沙箱，别一上来就追求最强隔离。先问清楚 Agent 执行的代码来源——如果是训练侧可控的代码，容器级隔离 + seccomp 足够；如果是用户提交的不可信代码，才需要上 microVM。隔离强度和性能是直接 trade-off 的，过度隔离会让 rollout 吞吐掉一大截。

3.2 调度器设计：怎么让环境侧不拖 GPU 后腿

DSec 的调度器要解决的核心问题是：让环境创建/销毁的延迟对训练循环透明。理想情况下，训练侧发一个"我要 N 个环境"的请求，DSec 应该在训练侧还没意识到等待的时候就把环境准备好了。这需要调度器做几件事。

第一是预测性预热。RL 训练的 rollout 请求有很强的周期性——每个 training step 开始时集中爆发一批环境需求。DSec 的调度器会根据历史负载预测下一个 step 的环境需求，提前把模板预热到节点本地。这样真正创建时只需要做最上层的克隆，延迟极低。

第二是亲和性调度。沙箱创建请求会尽量调度到已经缓存了对应镜像层的节点上，避免跨节点拉镜像。这个思路跟 K8s 的 image locality 调度类似，但 DSec 做得更激进：它会把"镜像层缓存"作为调度的第一优先级，甚至高于 CPU/内存的负载均衡。因为对 RL 训练来说，环境启动延迟比节点负载均衡重要得多。

第三是批量创建与批量销毁。单个创建请求的开销（网络往返、调度决策）在万级并发下不可忽略。DSec 支持批量 API，一次请求创建几百个沙箱，调度器内部并行处理。销毁同理，训练 step 结束后批量回收，避免逐个销毁的 overhead。

3.3 可观测性：Agent 轨迹怎么完整落盘

Agentic RL 训练离不开轨迹数据——Agent 在沙箱里做了什么、看到了什么、reward 是多少，这些都要完整记录用于训练。DSec 在可观测性上做了两层设计。

第一层是系统级指标：每个沙箱的 CPU/内存/IO 使用、生命周期事件、创建销毁延迟。这些指标用于监控和调度决策。第二层是应用级轨迹：Agent 的每一步 action、环境返回的 observation、执行的命令和输出。这一层是训练数据的来源，必须完整、有序、可关联。

这里有个容易踩的坑：轨迹落盘的 IO 开销。如果每个 action 都同步写盘，在高并发下 IO 会成为瓶颈。DSec 的做法是异步批量落盘 + 内存缓冲，同时保证崩溃时最多丢失一个 batch 的轨迹。这个取舍在训练场景下是合理的——丢一个 batch 的轨迹对训练影响很小，但同步写盘会拖垮整个 rollout 吞吐。

注意：轨迹的顺序性比完整性更重要。Agentic RL 训练时，如果轨迹的 action 顺序错乱，reward 分配就会错位，训练直接崩。DSec 给每个沙箱的轨迹打了单调递增的序号，落盘时按序号排序，确保训练侧拿到的轨迹是有序的。

4. 实操视角：如果我要复现一套类似的沙箱设施

4.1 技术选型对照表

假设你现在要从零搭一套 Agentic RL 的沙箱设施，我整理了一张选型对照表，把关键维度和常见方案列出来，方便你按自己的场景取舍。

我的建议是：从中等方案起步。containerd + seccomp 的组合能覆盖 80% 的 Agentic RL 场景，启动延迟和隔离强度都够用。等真的遇到不可信代码或者多租户需求，再局部升级到 microVM。一上来就上 Firecracker，运维成本会让你怀疑人生。

4.2 关键参数计算：并发数怎么定

沙箱并发数不是拍脑袋定的，要跟 GPU 侧的 rollout 吞吐匹配。给一个粗略的计算框架。

假设你有 8 张 GPU 做训练，每个 training step 需要 rollout 出 B 条轨迹，每条轨迹平均需要 E 次环境交互，每次交互平均耗时 T 秒。那么单个 step 的环境侧总工作量是B × E × T秒。如果希望环境侧不成为瓶颈，环境侧的总并发能力 C 应该满足：C ≥ B × E × T / S，其中 S 是单个 step 的期望墙钟时间。

举个例子：B=1024，E=10，T=0.5 秒，S=30 秒。那么C ≥ 1024 × 10 × 0.5 / 30 ≈ 171。也就是说，你至少需要能同时跑 171 个沙箱。考虑到任务执行时间的方差，实际并发数建议留 1.5 到 2 倍余量，也就是 250 到 350 个沙箱。

这个计算的关键洞察是：环境并发数跟 GPU 数量没有直接关系，而是跟 rollout 的工作量和时间预算有关。很多团队按"每卡配 10 个沙箱"这种经验值来配，结果要么不够要么浪费。按工作量算才是靠谱的。

4.3 一个最小可跑的沙箱创建流程

下面给一个基于 containerd 的最小沙箱创建流程，伪代码级别，帮你理解 DSec 这类系统在做什么。

# 沙箱创建的核心步骤（伪代码） def create_sandbox(template_id, task_code): # 1. 从模板克隆基础层（节点本地缓存，毫秒级） base = local_cache.get(template_id) # 2. 写时复制出可写层 writable_layer = cow_clone(base) # 3. 注入任务特定代码 inject_code(writable_layer, task_code) # 4. 配置隔离参数 config = { "namespaces": ["pid", "mount", "network", "ipc"], "seccomp_profile": "agent_default", "capabilities": ["CAP_NET_BIND_SERVICE"], # 最小权限 "memory_limit": "2G", "cpu_quota": "200000", # 2 核 } # 5. 启动沙箱 sandbox = runtime.start(writable_layer, config) # 6. 注册到轨迹采集器 tracer.register(sandbox.id) return sandbox

这个流程里，第 1、2 步是性能关键路径，必须做到毫秒级。第 4 步的隔离配置是安全关键路径，capability 一定要按最小权限原则给，别图省事给CAP_SYS_ADMIN，那等于没隔离。

4.4 实操心得：三个我踩过的坑

坑一：别用 Docker daemon 做高频创建。Docker daemon 在高频创建销毁场景下会成为单点瓶颈，而且它的 API 有全局锁。DSec 这类系统都是直接对接 containerd 或者更底层的 runtime，绕开 daemon。我早期用 Docker SDK 做沙箱池，QPS 上到几百就开始抖，换成 containerd 直连后稳如老狗。

坑二：文件系统用 overlayfs 要小心 inode 耗尽。overlayfs 的写时复制会产生大量小文件，高频创建销毁场景下 inode 消耗极快。我遇到过一次节点 inode 打满，所有沙箱创建全部失败。解法是给 overlayfs 的 upperdir 单独挂一块盘，并且定期清理僵尸沙箱的残留目录。

坑三：网络隔离别用默认 bridge。Docker 默认的 bridge 网络在几千个容器下会有 ARP 表爆炸和 iptables 规则膨胀的问题。DSec 这类系统一般用独立的 network namespace + 轻量 CNI，或者干脆让沙箱共享宿主网络但用 seccomp 限制网络系统调用。具体选哪种取决于你的 Agent 是否需要真实网络访问。

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

5.1 沙箱创建慢：从请求到就绪的全链路排查

沙箱创建慢是最常见的问题，排查要按链路走。我整理了一张速查表。

排查的核心思路是分段计时：把创建过程拆成"调度决策、镜像准备、运行时启动、代码注入"四段，每段打点，看时间花在哪。我见过最多的瓶颈是镜像准备段，尤其是跨节点拉取。解法就是前面说的预热 + 亲和性调度。

5.2 轨迹丢失或错乱：数据侧的排查

轨迹问题比创建问题更隐蔽，因为它不一定报错，但会悄悄毁掉训练。典型症状是训练 loss 异常波动、reward 曲线不收敛。排查要点：

• 检查轨迹序号连续性：每个沙箱的轨迹序号应该是 1、2、3……连续的。如果有跳号，说明落盘丢了数据。
• 检查 action-observation 配对：每个 action 后面应该跟一个 observation。如果配对错位，说明落盘顺序乱了。
• 检查沙箱 ID 关联：轨迹要能正确关联回沙箱和 training step。如果关联错了，reward 会分配到错误的轨迹上。

提示：轨迹采集器一定要做端到端校验——训练侧拿到的轨迹条数，应该等于环境侧产生的轨迹条数。这个校验看起来笨，但能第一时间发现数据丢失。我在一个项目里就是靠这个校验发现落盘器在高负载下会静默丢数据，查了三天才定位到是异步队列满了没做背压。

5.3 资源泄漏：沙箱销毁不干净怎么办

沙箱销毁不干净会导致资源缓慢泄漏，跑几个小时节点就满了。常见泄漏点：僵尸进程、残留的 mount point、未释放的 network namespace、overlayfs 的 upperdir 残留。

排查方法是定期对账：节点上实际存在的沙箱资源，应该等于 DSec 记录的活跃沙箱数。如果实际多于记录，说明有泄漏。解法是加一个兜底清理器，定期扫描孤儿资源并强制回收。这个清理器一定要有，因为再严谨的销毁逻辑也可能因为进程崩溃、网络分区等原因漏掉。

5.4 隔离逃逸：安全侧的底线检查

隔离逃逸是低频但高危的问题。Agentic RL 里 Agent 执行的是代码，理论上存在逃逸可能。底线检查清单：

• seccomp 是否禁掉了ptrace、mount、unshare等危险调用
• capability 是否按最小权限给，有没有多余的CAP_SYS_ADMIN
• 是否禁用了 privileged 模式
• 内核版本是否及时打了安全补丁
• 是否有沙箱间的网络隔离，防止横向移动

这几条是底线，任何一条不满足，隔离就形同虚设。我个人的经验是，安全配置要做成模板强制项，不允许任务侧覆盖。否则总有人图方便把隔离关掉，最后出事。

6. 这套设施对 Agentic RL 生态的影响

6.1 训练经济学的改变

DSec 这类沙箱设施最直接的影响是把 Agentic RL 的环境成本从"不可控"变成"可控"。在弹性沙箱成熟之前，环境侧的成本模型是：预分配 N 个容器，无论用不用都占着资源，成本是固定的、跟负载脱钩的。弹性沙箱之后，成本跟实际负载挂钩，闲时资源归还，忙时按需扩展。这个改变让 Agentic RL 的规模天花板显著抬高。

更深远的影响是训练迭代速度。环境创建从十几秒压到百毫秒，意味着研究者可以更快地试错——改一版 reward 函数，几分钟就能看到 rollout 结果，而不是等半小时。这种迭代速度的提升，对 Agentic RL 这种高度依赖实验的领域，价值可能比单纯的成本节省更大。

6.2 对算法设计的反向影响

基础设施的能力会反向塑造算法设计。DSec 支持状态快照和快速恢复之后，一些之前因为工程成本太高而没人做的算法变得可行了。比如基于树搜索的 Agent 训练——MCTS 需要频繁地"前进到某状态、探索、回滚"，没有快照能力根本做不了。再比如多轮交互的 credit assignment——需要精确记录每一步的环境状态，才能把最终 reward 合理分配到中间步骤。

我甚至觉得，未来 Agentic RL 的算法创新会越来越多地依赖基础设施能力。算法研究者和基础设施研究者的边界会变模糊——你不懂沙箱怎么工作，就没法设计出高效的 Agentic 训练算法。这个趋势在 DSec 这类工作出现之后会越来越明显。

6.3 落地时的组织建议

最后说点落地的组织层面建议。搭这类设施，别让算法团队和基础设施团队各干各的。我见过太多案例：算法团队抱怨环境慢，基础设施团队抱怨需求变来变去。正确的做法是让两边一起定义接口——环境创建/销毁的 API、轨迹数据的格式、状态快照的语义，这些接口一旦定下来，两边就能并行推进。

另外，先做最小可用版本，再逐步加隔离和弹性。一上来就追求 DSec 论文里的完整能力，大概率会陷入过度工程的泥潭。我的建议是：先用 containerd 把"按需创建 + 轨迹采集"跑通，验证训练侧能用起来，再逐步加预热、快照、microVM 隔离。基础设施的价值在于被用起来，而不是在于功能全。

我个人在实际搭这类系统时的体会是，最难的不是某个技术点，而是让环境侧和训练侧的节奏对齐。环境侧追求稳定和隔离，训练侧追求吞吐和低延迟，这两个目标天然有张力。DSec 的价值就在于它把这组张力处理得比较优雅——用弹性调度吸收负载波动，用分层缓存压低延迟，用分层隔离平衡安全和性能。这套思路，我觉得不只适用于 Agentic RL，任何需要大规模、短生命周期、强隔离执行环境的场景都能借鉴。