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 PPOGPU 利用率长期在 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 的沙箱设施我整理了一张选型对照表把关键维度和常见方案列出来方便你按自己的场景取舍。维度轻量方案中等方案重量方案隔离技术namespace cgroupcontainerd seccompFirecracker microVM启动延迟毫秒级百毫秒级百毫秒到秒级隔离强度弱中强适用场景可信代码、快速迭代大多数 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 的期望墙钟时间。举个例子B1024E10T0.5 秒S30 秒。那么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 沙箱创建慢从请求到就绪的全链路排查沙箱创建慢是最常见的问题排查要按链路走。我整理了一张速查表。现象可能原因排查方法解决方向创建延迟 1s镜像层未缓存跨节点拉取看节点本地缓存命中率预热模板、亲和性调度创建延迟波动大节点负载不均看各节点 CPU/IO 水位调度器加负载感知批量创建时部分超时调度器单点瓶颈看调度器 QPS 和延迟调度器水平扩展创建成功但 Agent 起不来依赖缺失或权限不足看沙箱内 stderr检查镜像层和 capability创建后立即被 OOM kill内存 limit 太小看 cgroup 内存事件调大 limit 或优化任务排查的核心思路是分段计时把创建过程拆成调度决策、镜像准备、运行时启动、代码注入四段每段打点看时间花在哪。我见过最多的瓶颈是镜像准备段尤其是跨节点拉取。解法就是前面说的预热 亲和性调度。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任何需要大规模、短生命周期、强隔离执行环境的场景都能借鉴。 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 PPOGPU 利用率长期在 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 的沙箱设施我整理了一张选型对照表把关键维度和常见方案列出来方便你按自己的场景取舍。维度轻量方案中等方案重量方案隔离技术namespace cgroupcontainerd seccompFirecracker microVM启动延迟毫秒级百毫秒级百毫秒到秒级隔离强度弱中强适用场景可信代码、快速迭代大多数 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 的期望墙钟时间。举个例子B1024E10T0.5 秒S30 秒。那么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 沙箱创建慢从请求到就绪的全链路排查沙箱创建慢是最常见的问题排查要按链路走。我整理了一张速查表。现象可能原因排查方法解决方向创建延迟 1s镜像层未缓存跨节点拉取看节点本地缓存命中率预热模板、亲和性调度创建延迟波动大节点负载不均看各节点 CPU/IO 水位调度器加负载感知批量创建时部分超时调度器单点瓶颈看调度器 QPS 和延迟调度器水平扩展创建成功但 Agent 起不来依赖缺失或权限不足看沙箱内 stderr检查镜像层和 capability创建后立即被 OOM kill内存 limit 太小看 cgroup 内存事件调大 limit 或优化任务排查的核心思路是分段计时把创建过程拆成调度决策、镜像准备、运行时启动、代码注入四段每段打点看时间花在哪。我见过最多的瓶颈是镜像准备段尤其是跨节点拉取。解法就是前面说的预热 亲和性调度。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任何需要大规模、短生命周期、强隔离执行环境的场景都能借鉴。