1. 从智能体训练为什么需要沙箱说起如果你最近在折腾智能体Agent相关的项目大概率会遇到一个绕不开的问题怎么让模型安全地执行它自己生成的代码。不管是让智能体写个 Python 脚本处理数据还是让它调用系统命令完成某个任务只要涉及执行这两个字风险就来了——它可能删错文件、跑飞内存、甚至陷入死循环把整台机器拖垮。我最早做智能体项目的时候图省事直接在本地机器上跑模型生成的代码。结果有一次模型写了个递归函数没设终止条件直接把我的开发机内存吃满风扇狂转最后只能强制重启。那次之后我就明白了智能体训练和推理必须有一个隔离的执行环境也就是我们常说的沙箱。DeepSeek 这次公开的DSecDeepSeek Elastic Compute就是冲着这个痛点来的。从名字拆开看Elastic 说明它是弹性的、可伸缩的Compute 说明它提供的是计算能力合起来就是一套面向大规模智能体训练场景的弹性沙箱基础设施。关键词里还出现了deepseek harness、代码沙箱、SDK这些词基本可以判断 DSec 不是单纯的一个隔离容器而是一整套配套了 SDK、能支撑海量并发智能体任务的底层设施。这篇文章我不打算复述官方文档而是站在一个实际做过智能体训练系统的人的角度把 DSec 这类沙箱基础设施为什么这么设计、核心难点在哪、怎么落地、踩坑点在哪讲透。适合正在做智能体平台、代码执行服务、或者单纯想搞清楚沙箱到底怎么撑起大规模训练的读者。2. 智能体训练对沙箱提出的四个硬性要求在讲 DSec 之前得先搞清楚一个前提智能体训练用的沙箱和普通的代码沙箱比如在线判题系统那种完全不是一回事。在线判题是提交一次、跑一次、出结果而智能体训练是成千上万个智能体同时跑、每个都在反复执行代码、还要和环境持续交互。这个差异直接决定了沙箱的设计取向。2.1 并发规模从几十到几万的数量级跃迁普通代码沙箱可能同时服务几百个用户就顶天了但智能体训练不一样。一个训练任务里可能有几千个并行的 rollout采样轨迹每个 rollout 里的智能体都在不停地生成代码、执行代码、根据结果调整策略。这意味着沙箱的并发需求是动态且爆发式的。我实测过一个中等规模的智能体训练任务峰值时同时需要大约 2000 个隔离执行环境。如果用传统的一个容器一个环境的方式光是容器调度和启动的开销就够呛。DSec 里 Elastic 这个词核心要解决的就是这个问题——环境要能按需快速拉起、用完快速回收而不是常驻一堆闲置资源。2.2 隔离强度既要防误操作也要防恶意行为隔离这件事很多人第一反应是用 Docker 不就行了。但 Docker 的隔离是基于 namespace 和 cgroup 的本质上还是共享内核。对于智能体训练来说这有两个隐患误操作隔离模型生成的代码可能误删文件、写满磁盘、占用大量 CPU这些 Docker 能挡一部分但资源限制需要精细配置。安全隔离如果训练数据里混入了不可信的代码共享内核意味着存在逃逸风险。所以真正严肃的智能体沙箱往往会在容器之上再加一层比如 gVisor、Kata Containers 这类用户态内核或轻量虚拟机方案。DSec 作为面向大规模训练的设施隔离强度必然是设计的第一优先级。2.3 启动速度冷启动时间直接决定训练效率这一点特别容易被忽略。假设每个沙箱冷启动需要 2 秒一个训练任务要执行 10 万次代码那就是 20 万秒的纯等待时间训练效率直接崩掉。所以沙箱基础设施必须做到毫秒级的环境就绪。常见的做法是预热池warm pool提前把一批环境初始化好任务来了直接从池子里取用完归还并重置。DSec 的弹性能力很大程度上就体现在这个池子的动态伸缩上——任务多的时候扩容任务少的时候缩容既不浪费资源也不让任务排队。2.4 状态管理智能体需要有记忆的环境这是智能体沙箱和普通沙箱最大的区别。普通沙箱执行完就销毁但智能体往往需要多轮交互第一步写文件第二步读文件第三步基于文件内容再操作。这就要求沙箱在执行多次代码之间保持文件系统和进程状态。但状态保持又和环境复用矛盾——如果环境要回收给下一个任务就得清理干净。DSec 这类设施通常的做法是会话级隔离一个智能体的整个生命周期绑定一个沙箱实例会话结束才回收回收时做快照或彻底重置。下面这张表把四类要求对比一下方便你判断自己的场景需要什么级别的沙箱要求维度普通代码沙箱智能体训练沙箱DSec 类设施的关注点并发规模百级千到万级弹性伸缩、预热池隔离强度容器级容器用户态内核/轻量 VM防逃逸、防误操作启动速度秒级可接受毫秒级刚需快照恢复、池化状态管理无状态会话级有状态会话绑定、快照重置3. DSec 的架构思路弹性计算池是怎么搭起来的理解了需求再看 DSec 的设计就顺理成章了。虽然官方没有把内部架构全盘托出但从Elastic Compute这个命名和智能体训练的通用工程实践可以推断出它的核心分层。我结合自己做过的类似系统把这类设施的典型架构拆成四层来讲。3.1 调度层决定哪个任务去哪个沙箱调度层是整个设施的大脑。它要回答三个问题有没有空闲沙箱可用没有的话要不要新建新建的话放在哪台物理机上这里的关键是装箱问题bin packing。每台物理机的 CPU、内存、磁盘都是有限的调度器要在满足隔离要求的前提下尽可能把沙箱塞满机器提高资源利用率。但塞太满又会导致单机负载过高、影响执行延迟。所以实际系统里通常会有个水位线比如 CPU 利用率控制在 70% 左右留出余量应对突发。我踩过的一个坑是早期调度器只看 CPU 和内存忽略了磁盘 IO。结果有些任务疯狂读写磁盘把同一台机器上其他沙箱的执行速度拖慢了好几倍。后来加了 IO 权重才缓解。DSec 这种规模的设施调度维度肯定不止 CPU/内存两项。3.2 执行层沙箱实例本身怎么跑执行层就是真正跑代码的地方。前面提到隔离强度这里展开说下几种主流方案的取舍纯容器Docker/runc启动最快隔离最弱适合完全可信的代码。gVisor用户态实现系统调用隔离强于容器性能损耗中等兼容性偶有问题某些系统调用不支持。Kata Containers每个沙箱一个轻量 VM隔离最强启动稍慢资源开销略高。FirecrackerAWS 开源的轻量 VM启动能到毫秒级是很多大规模沙箱设施的首选。对于智能体训练我个人的经验是如果代码来源可控gVisor 是性价比最高的选择如果代码完全不可信Firecracker 这类 microVM 更稳妥。DSec 作为 DeepSeek 的设施大概率在这两者之间做了权衡甚至可能做了混合调度——简单任务用轻隔离高风险任务用重隔离。3.3 存储层文件系统怎么做到既隔离又高效存储是沙箱里最容易被低估的部分。智能体执行代码时往往需要读写文件这些文件既要隔离不同沙箱不能互相看到又要高效不能每次读写都走网络。常见的方案是分层文件系统底层是一个只读的基础镜像比如装了 Python、常用库上层是每个沙箱的可写层。这样基础镜像可以共享节省大量磁盘和内存。DSec 的弹性能力很可能也体现在存储层的按需挂载上——任务需要什么环境就挂载对应的镜像层。提示如果你自己搭沙箱千万别让每个沙箱都拷贝一份完整镜像。用 overlayfs 或类似的分层方案能把磁盘占用降一个数量级。3.4 接口层SDK 是怎么把沙箱能力暴露给训练框架的关键词里反复出现SDK说明 DSec 是以 SDK 形式对外提供能力的。这很合理——训练框架比如各种 RL 框架不可能自己去管理沙箱生命周期它需要一个简洁的接口创建沙箱、执行代码、拿结果、销毁沙箱。一个设计良好的沙箱 SDK接口通常长这样伪代码示意from dsec import Sandbox # 创建沙箱指定环境和资源 sb Sandbox.create(imagepython:3.11, cpu2, memory4G) # 执行代码拿回结果 result sb.execute(print(sum(range(100)))) print(result.stdout) # 输出 4950 # 会话保持可以继续执行 sb.execute(x 42) result sb.execute(print(x)) # 输出 42 # 用完销毁 sb.destroy()这个接口看起来简单但背后要处理的事情很多连接池、超时控制、错误重试、资源回收。SDK 的价值就在于把这些复杂性藏起来让训练框架只关心执行代码这一件事。4. 把 DSec 跑起来从环境准备到第一个智能体任务光讲架构容易飘这一节我带你走一遍实际落地的流程。需要说明的是DSec 目前公开的细节有限下面这套流程是基于同类沙箱设施的通用实践整理的具体命令和参数你需要对照官方 SDK 文档调整。4.1 环境准备别在依赖上栽跟头搭沙箱环境第一步永远是依赖。我见过太多人卡在 SDK 安装上尤其是涉及底层虚拟化的组件。以常见的沙箱设施为例宿主机通常需要Linux 内核 5.x 以上支持 cgroup v2 和必要的 namespace开启 KVM 支持如果用 microVM 方案足够的磁盘空间存放镜像建议单独挂一块盘容器运行时containerd 或 Docker检查 KVM 是否可用# 检查 CPU 是否支持虚拟化 grep -E vmx|svm /proc/cpuinfo # 检查 KVM 模块是否加载 lsmod | grep kvm # 检查设备节点 ls -l /dev/kvm如果/dev/kvm不存在说明虚拟化没开microVM 方案就跑不起来只能退而求其次用 gVisor。这个检查一定要在部署前做别等跑起来才发现。4.2 安装 SDK 与初始化配置SDK 安装本身通常不复杂麻烦的是配置。沙箱设施一般需要配置几个关键项配置项作用常见取值调度器地址SDK 连接哪个调度服务内网地址或本地 socket默认镜像沙箱启动用哪个基础镜像python:3.11 / ubuntu:22.04资源上限单沙箱最大 CPU/内存按任务需求设定超时时间单次执行最长多久30s ~ 300s预热池大小常驻空闲沙箱数量按并发峰值设定配置里最容易出问题的是超时时间。设太短正常任务被误杀设太长卡死的任务占着资源不放。我的经验是先设一个宽松值比如 300 秒跑一段时间统计实际执行时间分布再根据 P99 值收紧。4.3 第一个任务让智能体执行一段代码环境就绪后跑一个最小可用的例子。假设我们要让智能体执行一段数据处理代码from dsec import Sandbox def run_agent_code(code: str): sb Sandbox.create( imagepython:3.11, cpu1, memory2G, timeout60 ) try: result sb.execute(code) if result.exit_code 0: return {status: ok, output: result.stdout} else: return {status: error, stderr: result.stderr} finally: sb.destroy() # 测试 code import json data {numbers: [1, 2, 3, 4, 5]} print(json.dumps({sum: sum(data[numbers])})) print(run_agent_code(code))这段代码的关键点是finally里必须销毁沙箱。我见过有人忘了销毁结果沙箱泄漏跑一晚上把资源池耗光。SDK 一般会提供上下文管理器with语句来避免这个问题能用就用。4.4 接入训练框架让 rollout 自动调用沙箱单次执行跑通后就要接入训练框架了。智能体训练里沙箱调用通常发生在rollout 阶段智能体生成动作代码环境执行动作返回观测执行结果智能体据此生成下一步。这里有个性能关键点沙箱创建和销毁的开销不能落在每个 step 上。正确做法是一个 rollout 绑定一个沙箱会话整个轨迹复用同一个沙箱只在轨迹结束时销毁。这样既保持了状态又摊薄了创建开销。class AgentEnv: def __init__(self): self.sandbox None def reset(self): # 每个轨迹开始时创建沙箱 self.sandbox Sandbox.create(imagepython:3.11, cpu1, memory2G) return 环境已就绪 def step(self, action_code: str): # 复用同一个沙箱执行 result self.sandbox.execute(action_code) return result.stdout, result.exit_code def close(self): # 轨迹结束时销毁 if self.sandbox: self.sandbox.destroy() self.sandbox None这个模式我在实际项目里用了很久稳定且高效。唯一要注意的是异常处理——如果 step 里抛异常close 必须被调用否则沙箱泄漏。5. 大规模训练下的性能调优与资源控制小规模跑通不难难的是在几千并发下还能保持稳定和高效。这一节讲几个我在实际调优中总结的关键点也是 DSec 这类设施必须解决的核心工程问题。5.1 预热池的容量怎么定预热池太小任务来了要等冷启动太大闲置资源浪费。怎么找平衡点我的方法是看并发曲线。统计一天内并发沙箱数量的变化找到峰值和均值。预热池的常驻大小设为均值附近峰值靠动态扩容顶上去。动态扩容的速度取决于冷启动时间——如果冷启动 500ms那扩容就能跟上大部分突发如果冷启动 5 秒就得把常驻池设大一些。一个实用的经验公式常驻池大小 日均并发 × 1.2 最大池大小 峰值并发 × 1.51.2 和 1.5 这两个系数是留的缓冲具体根据你的并发波动程度调整。波动越大系数越高。5.2 资源限制别让一个沙箱拖垮一台机器资源限制是沙箱的生命线。CPU、内存、磁盘、进程数、文件描述符每一项都要设上限。我踩过最惨的坑是没限制进程数结果模型写了个 fork 炸弹虽然是误写的瞬间把宿主机进程表打满整台机器上的所有沙箱全挂了。必设的限制项CPU用 cgroup 的 cpu quota限制到具体核数内存硬限制超了直接 OOM kill别让它拖累别人进程数pids limit防止 fork 炸弹磁盘配额限制防止写满执行时间wall clock 超时防止死循环网络默认关闭需要时白名单放行注意内存限制要留一点余量。比如你想限制 2G实际设 2.2G因为进程启动本身有开销卡太死会导致正常任务被误杀。5.3 冷启动优化从秒级到毫秒级冷启动时间是沙箱设施的命脉。优化手段主要有三招第一招镜像预热。把常用镜像提前拉取到宿主机别等创建沙箱时才拉。这一步能把启动时间从几十秒降到几秒。第二招快照恢复。把初始化好的沙箱状态做成快照内存文件系统新沙箱直接从快照恢复跳过初始化过程。Firecracker 的 snapshot 功能就是干这个的能把启动压到毫秒级。第三招池化复用。前面说的预热池本质就是用空间换时间。沙箱用完不销毁重置后放回池子。这三招组合起来冷启动能从秒级降到几十毫秒。DSec 的 Elastic 能力核心就是把这套机制做扎实。5.4 监控与可观测性出问题时你能看到什么大规模系统没有监控就是裸奔。沙箱设施至少要监控这几类指标指标类别具体指标用途资源CPU/内存/磁盘使用率判断是否需要扩容性能创建延迟、执行延迟定位性能瓶颈健康沙箱失败率、超时率发现异常任务池化池命中率、池等待时间优化池大小我特别想强调池命中率这个指标。它直接告诉你预热池设得合不合理命中率低说明池太小任务总在等命中率高但资源利用率低说明池太大浪费。理想状态是命中率 90% 以上同时资源利用率 60% 到 70%。6. 那些文档里不会写的踩坑记录这一节是我最想写的部分。前面讲的都是应该怎么做这里讲实际做的时候会怎么翻车。这些坑官方文档基本不会提但每一个都能让你调半天。6.1 沙箱泄漏最隐蔽也最致命沙箱泄漏是指沙箱创建了但没被销毁慢慢把资源池耗光。它的隐蔽性在于短期内看不出问题可能跑几个小时才暴露那时候你已经去干别的了。泄漏的常见原因有三个异常路径没清理代码在execute时抛异常跳过了destroy。训练任务被中断任务被 kill但沙箱没被回收。SDK 连接断开网络抖动导致 SDK 和调度器失联沙箱成了孤儿。应对方法给沙箱加 TTL生存时间。每个沙箱创建时打上时间戳超过 TTL 还没被主动销毁的由后台清理任务强制回收。TTL 设长一点比如 1 小时正常任务不会受影响泄漏的沙箱也能被兜底清理。6.2 状态污染上一个任务的残留影响了下一个如果沙箱是复用的重置不彻底就会导致状态污染。我遇到过最诡异的一次某个任务在/tmp下写了个配置文件重置时没清掉下一个任务读到了这个文件行为完全错乱排查了整整一天。重置要清的东西比你想的多文件系统/tmp、工作目录、用户目录进程残留的后台进程环境变量任务里export的变量网络连接任务建立的连接共享内存/dev/shm里的内容最稳妥的重置方式是从快照恢复而不是清理。快照恢复能保证环境回到一个确定的初始状态不依赖清理逻辑的完备性。6.3 资源竞争邻居太吵怎么办同一台宿主机上的多个沙箱会竞争资源。如果隔离做得不好一个沙箱疯狂读写磁盘其他沙箱的执行延迟就会飙升。这就是所谓的吵闹邻居问题。缓解手段IO 限速用 cgroup 的 blkio 限制每个沙箱的磁盘带宽CPU 绑核把关键沙箱绑定到特定 CPU 核避免被抢占NUMA 感知多路 CPU 的机器上让沙箱的内存和 CPU 在同一 NUMA 节点这些优化在单机测试时看不出效果一到大规模就体现价值。DSec 这种规模的设施NUMA 感知几乎是标配。6.4 超时设置的两难超时设短了误杀设长了卡死。这个矛盾在智能体训练里尤其突出因为智能体生成的代码执行时间方差极大——简单的几毫秒复杂的可能几分钟。我的解法是分级超时快速任务如简单计算10 秒普通任务如数据处理60 秒长任务如模型推理300 秒任务提交时指定级别SDK 按级别设置超时。这样既不会误杀长任务也不会让短任务卡太久。更进一步可以动态超时先给一个初始超时如果任务在超时前有输出说明还活着就自动延长。7. 从 DSec 看智能体沙箱的未来形态写到这里我想跳出 DSec 本身聊聊这类设施的发展方向。因为智能体训练这个领域变化太快今天的方案可能半年后就过时了。7.1 沙箱正在从执行环境变成交互环境早期的沙箱只负责执行代码返回结果就完事。但现在的智能体越来越复杂它需要的不只是执行还有交互调用工具、访问数据库、操作浏览器、和其他智能体通信。沙箱的边界在扩大从代码执行器变成完整的交互环境。这对沙箱设施提出了新要求要能挂载各种工具和服务。DSec 的 SDK 设计很可能已经考虑了这种扩展性——通过插件或适配器的方式让沙箱能接入不同的工具。7.2 弹性不只是伸缩更是异构Elastic这个词传统理解是数量上的伸缩。但在智能体训练场景下它还有一层含义异构资源的弹性调度。有的任务需要 GPU有的只需要 CPU有的需要大内存有的需要快磁盘。沙箱设施要能根据任务需求调度到合适的资源上。这意味着调度器要维护一个多维资源视图而不只是 CPU 和内存。这也是为什么大规模沙箱设施的调度层往往是最复杂的部分。7.3 安全隔离的军备竞赛随着智能体能力增强它能生成的代码也越来越危险。沙箱的隔离强度必须跟上。从容器到 gVisor 到 microVM隔离在不断加强但性能开销也在增加。未来的方向可能是硬件辅助隔离比如 Intel 的 TDX、AMD 的 SEV在硬件层面提供隔离保证性能损耗更小。对于做智能体训练的人来说这意味着沙箱选型要留有余地——别把架构绑死在一种隔离方案上要能根据任务风险等级动态切换。7.4 标准化接口的缺失目前沙箱设施最大的问题是没有标准接口。每个平台都有自己的 SDK训练框架要适配不同的沙箱成本很高。如果未来能出现类似沙箱界的 POSIX这样的标准整个生态会健康很多。DSec 公开 SDK某种程度上也是在推动这个方向。当足够多的人用同一套接口标准就自然形成了。8. 给正在搭沙箱的人几句实在话最后这部分不讲技术讲讲心态和经验。因为搭沙箱这件事技术只是一半另一半是工程判断。第一别追求一步到位。我见过太多人一上来就想搭个支持万级并发的沙箱系统结果卡在第一个 bug 上就放弃了。正确的路径是先用最简单的方案比如 Docker跑通单任务再逐步加隔离、加池化、加调度。每一步都验证过再走下一步。第二把可观测性放在第一位。沙箱系统出问题时最难的不是修是定位。没有监控你连问题出在哪一层都不知道。所以从第一天起就要把日志、指标、追踪做起来哪怕简陋一点。第三重视异常路径。正常流程谁都能跑通真正体现功力的是异常处理超时怎么办、崩溃怎么办、网络断了怎么办。这些路径平时不触发一触发就是大事故。第四资源限制宁紧勿松。刚开始可能觉得限制太紧影响任务但比起一个任务拖垮整个集群紧一点是值得的。等摸清了任务的实际资源画像再逐步放宽。第五多看看别人怎么踩坑。沙箱这个领域很多坑是共通的。多读读同行的经验分享能省下大量试错时间。我写这篇文章也是希望能帮你少走点弯路。智能体训练还在快速演进沙箱基础设施也会跟着变。但有些底层原则是不变的隔离、弹性、可观测、异常处理。把这些做扎实不管上层怎么变你都能接得住。
DeepSeek DSec 弹性沙箱：大规模智能体训练基础设施设计与落地
1. 从智能体训练为什么需要沙箱说起如果你最近在折腾智能体Agent相关的项目大概率会遇到一个绕不开的问题怎么让模型安全地执行它自己生成的代码。不管是让智能体写个 Python 脚本处理数据还是让它调用系统命令完成某个任务只要涉及执行这两个字风险就来了——它可能删错文件、跑飞内存、甚至陷入死循环把整台机器拖垮。我最早做智能体项目的时候图省事直接在本地机器上跑模型生成的代码。结果有一次模型写了个递归函数没设终止条件直接把我的开发机内存吃满风扇狂转最后只能强制重启。那次之后我就明白了智能体训练和推理必须有一个隔离的执行环境也就是我们常说的沙箱。DeepSeek 这次公开的DSecDeepSeek Elastic Compute就是冲着这个痛点来的。从名字拆开看Elastic 说明它是弹性的、可伸缩的Compute 说明它提供的是计算能力合起来就是一套面向大规模智能体训练场景的弹性沙箱基础设施。关键词里还出现了deepseek harness、代码沙箱、SDK这些词基本可以判断 DSec 不是单纯的一个隔离容器而是一整套配套了 SDK、能支撑海量并发智能体任务的底层设施。这篇文章我不打算复述官方文档而是站在一个实际做过智能体训练系统的人的角度把 DSec 这类沙箱基础设施为什么这么设计、核心难点在哪、怎么落地、踩坑点在哪讲透。适合正在做智能体平台、代码执行服务、或者单纯想搞清楚沙箱到底怎么撑起大规模训练的读者。2. 智能体训练对沙箱提出的四个硬性要求在讲 DSec 之前得先搞清楚一个前提智能体训练用的沙箱和普通的代码沙箱比如在线判题系统那种完全不是一回事。在线判题是提交一次、跑一次、出结果而智能体训练是成千上万个智能体同时跑、每个都在反复执行代码、还要和环境持续交互。这个差异直接决定了沙箱的设计取向。2.1 并发规模从几十到几万的数量级跃迁普通代码沙箱可能同时服务几百个用户就顶天了但智能体训练不一样。一个训练任务里可能有几千个并行的 rollout采样轨迹每个 rollout 里的智能体都在不停地生成代码、执行代码、根据结果调整策略。这意味着沙箱的并发需求是动态且爆发式的。我实测过一个中等规模的智能体训练任务峰值时同时需要大约 2000 个隔离执行环境。如果用传统的一个容器一个环境的方式光是容器调度和启动的开销就够呛。DSec 里 Elastic 这个词核心要解决的就是这个问题——环境要能按需快速拉起、用完快速回收而不是常驻一堆闲置资源。2.2 隔离强度既要防误操作也要防恶意行为隔离这件事很多人第一反应是用 Docker 不就行了。但 Docker 的隔离是基于 namespace 和 cgroup 的本质上还是共享内核。对于智能体训练来说这有两个隐患误操作隔离模型生成的代码可能误删文件、写满磁盘、占用大量 CPU这些 Docker 能挡一部分但资源限制需要精细配置。安全隔离如果训练数据里混入了不可信的代码共享内核意味着存在逃逸风险。所以真正严肃的智能体沙箱往往会在容器之上再加一层比如 gVisor、Kata Containers 这类用户态内核或轻量虚拟机方案。DSec 作为面向大规模训练的设施隔离强度必然是设计的第一优先级。2.3 启动速度冷启动时间直接决定训练效率这一点特别容易被忽略。假设每个沙箱冷启动需要 2 秒一个训练任务要执行 10 万次代码那就是 20 万秒的纯等待时间训练效率直接崩掉。所以沙箱基础设施必须做到毫秒级的环境就绪。常见的做法是预热池warm pool提前把一批环境初始化好任务来了直接从池子里取用完归还并重置。DSec 的弹性能力很大程度上就体现在这个池子的动态伸缩上——任务多的时候扩容任务少的时候缩容既不浪费资源也不让任务排队。2.4 状态管理智能体需要有记忆的环境这是智能体沙箱和普通沙箱最大的区别。普通沙箱执行完就销毁但智能体往往需要多轮交互第一步写文件第二步读文件第三步基于文件内容再操作。这就要求沙箱在执行多次代码之间保持文件系统和进程状态。但状态保持又和环境复用矛盾——如果环境要回收给下一个任务就得清理干净。DSec 这类设施通常的做法是会话级隔离一个智能体的整个生命周期绑定一个沙箱实例会话结束才回收回收时做快照或彻底重置。下面这张表把四类要求对比一下方便你判断自己的场景需要什么级别的沙箱要求维度普通代码沙箱智能体训练沙箱DSec 类设施的关注点并发规模百级千到万级弹性伸缩、预热池隔离强度容器级容器用户态内核/轻量 VM防逃逸、防误操作启动速度秒级可接受毫秒级刚需快照恢复、池化状态管理无状态会话级有状态会话绑定、快照重置3. DSec 的架构思路弹性计算池是怎么搭起来的理解了需求再看 DSec 的设计就顺理成章了。虽然官方没有把内部架构全盘托出但从Elastic Compute这个命名和智能体训练的通用工程实践可以推断出它的核心分层。我结合自己做过的类似系统把这类设施的典型架构拆成四层来讲。3.1 调度层决定哪个任务去哪个沙箱调度层是整个设施的大脑。它要回答三个问题有没有空闲沙箱可用没有的话要不要新建新建的话放在哪台物理机上这里的关键是装箱问题bin packing。每台物理机的 CPU、内存、磁盘都是有限的调度器要在满足隔离要求的前提下尽可能把沙箱塞满机器提高资源利用率。但塞太满又会导致单机负载过高、影响执行延迟。所以实际系统里通常会有个水位线比如 CPU 利用率控制在 70% 左右留出余量应对突发。我踩过的一个坑是早期调度器只看 CPU 和内存忽略了磁盘 IO。结果有些任务疯狂读写磁盘把同一台机器上其他沙箱的执行速度拖慢了好几倍。后来加了 IO 权重才缓解。DSec 这种规模的设施调度维度肯定不止 CPU/内存两项。3.2 执行层沙箱实例本身怎么跑执行层就是真正跑代码的地方。前面提到隔离强度这里展开说下几种主流方案的取舍纯容器Docker/runc启动最快隔离最弱适合完全可信的代码。gVisor用户态实现系统调用隔离强于容器性能损耗中等兼容性偶有问题某些系统调用不支持。Kata Containers每个沙箱一个轻量 VM隔离最强启动稍慢资源开销略高。FirecrackerAWS 开源的轻量 VM启动能到毫秒级是很多大规模沙箱设施的首选。对于智能体训练我个人的经验是如果代码来源可控gVisor 是性价比最高的选择如果代码完全不可信Firecracker 这类 microVM 更稳妥。DSec 作为 DeepSeek 的设施大概率在这两者之间做了权衡甚至可能做了混合调度——简单任务用轻隔离高风险任务用重隔离。3.3 存储层文件系统怎么做到既隔离又高效存储是沙箱里最容易被低估的部分。智能体执行代码时往往需要读写文件这些文件既要隔离不同沙箱不能互相看到又要高效不能每次读写都走网络。常见的方案是分层文件系统底层是一个只读的基础镜像比如装了 Python、常用库上层是每个沙箱的可写层。这样基础镜像可以共享节省大量磁盘和内存。DSec 的弹性能力很可能也体现在存储层的按需挂载上——任务需要什么环境就挂载对应的镜像层。提示如果你自己搭沙箱千万别让每个沙箱都拷贝一份完整镜像。用 overlayfs 或类似的分层方案能把磁盘占用降一个数量级。3.4 接口层SDK 是怎么把沙箱能力暴露给训练框架的关键词里反复出现SDK说明 DSec 是以 SDK 形式对外提供能力的。这很合理——训练框架比如各种 RL 框架不可能自己去管理沙箱生命周期它需要一个简洁的接口创建沙箱、执行代码、拿结果、销毁沙箱。一个设计良好的沙箱 SDK接口通常长这样伪代码示意from dsec import Sandbox # 创建沙箱指定环境和资源 sb Sandbox.create(imagepython:3.11, cpu2, memory4G) # 执行代码拿回结果 result sb.execute(print(sum(range(100)))) print(result.stdout) # 输出 4950 # 会话保持可以继续执行 sb.execute(x 42) result sb.execute(print(x)) # 输出 42 # 用完销毁 sb.destroy()这个接口看起来简单但背后要处理的事情很多连接池、超时控制、错误重试、资源回收。SDK 的价值就在于把这些复杂性藏起来让训练框架只关心执行代码这一件事。4. 把 DSec 跑起来从环境准备到第一个智能体任务光讲架构容易飘这一节我带你走一遍实际落地的流程。需要说明的是DSec 目前公开的细节有限下面这套流程是基于同类沙箱设施的通用实践整理的具体命令和参数你需要对照官方 SDK 文档调整。4.1 环境准备别在依赖上栽跟头搭沙箱环境第一步永远是依赖。我见过太多人卡在 SDK 安装上尤其是涉及底层虚拟化的组件。以常见的沙箱设施为例宿主机通常需要Linux 内核 5.x 以上支持 cgroup v2 和必要的 namespace开启 KVM 支持如果用 microVM 方案足够的磁盘空间存放镜像建议单独挂一块盘容器运行时containerd 或 Docker检查 KVM 是否可用# 检查 CPU 是否支持虚拟化 grep -E vmx|svm /proc/cpuinfo # 检查 KVM 模块是否加载 lsmod | grep kvm # 检查设备节点 ls -l /dev/kvm如果/dev/kvm不存在说明虚拟化没开microVM 方案就跑不起来只能退而求其次用 gVisor。这个检查一定要在部署前做别等跑起来才发现。4.2 安装 SDK 与初始化配置SDK 安装本身通常不复杂麻烦的是配置。沙箱设施一般需要配置几个关键项配置项作用常见取值调度器地址SDK 连接哪个调度服务内网地址或本地 socket默认镜像沙箱启动用哪个基础镜像python:3.11 / ubuntu:22.04资源上限单沙箱最大 CPU/内存按任务需求设定超时时间单次执行最长多久30s ~ 300s预热池大小常驻空闲沙箱数量按并发峰值设定配置里最容易出问题的是超时时间。设太短正常任务被误杀设太长卡死的任务占着资源不放。我的经验是先设一个宽松值比如 300 秒跑一段时间统计实际执行时间分布再根据 P99 值收紧。4.3 第一个任务让智能体执行一段代码环境就绪后跑一个最小可用的例子。假设我们要让智能体执行一段数据处理代码from dsec import Sandbox def run_agent_code(code: str): sb Sandbox.create( imagepython:3.11, cpu1, memory2G, timeout60 ) try: result sb.execute(code) if result.exit_code 0: return {status: ok, output: result.stdout} else: return {status: error, stderr: result.stderr} finally: sb.destroy() # 测试 code import json data {numbers: [1, 2, 3, 4, 5]} print(json.dumps({sum: sum(data[numbers])})) print(run_agent_code(code))这段代码的关键点是finally里必须销毁沙箱。我见过有人忘了销毁结果沙箱泄漏跑一晚上把资源池耗光。SDK 一般会提供上下文管理器with语句来避免这个问题能用就用。4.4 接入训练框架让 rollout 自动调用沙箱单次执行跑通后就要接入训练框架了。智能体训练里沙箱调用通常发生在rollout 阶段智能体生成动作代码环境执行动作返回观测执行结果智能体据此生成下一步。这里有个性能关键点沙箱创建和销毁的开销不能落在每个 step 上。正确做法是一个 rollout 绑定一个沙箱会话整个轨迹复用同一个沙箱只在轨迹结束时销毁。这样既保持了状态又摊薄了创建开销。class AgentEnv: def __init__(self): self.sandbox None def reset(self): # 每个轨迹开始时创建沙箱 self.sandbox Sandbox.create(imagepython:3.11, cpu1, memory2G) return 环境已就绪 def step(self, action_code: str): # 复用同一个沙箱执行 result self.sandbox.execute(action_code) return result.stdout, result.exit_code def close(self): # 轨迹结束时销毁 if self.sandbox: self.sandbox.destroy() self.sandbox None这个模式我在实际项目里用了很久稳定且高效。唯一要注意的是异常处理——如果 step 里抛异常close 必须被调用否则沙箱泄漏。5. 大规模训练下的性能调优与资源控制小规模跑通不难难的是在几千并发下还能保持稳定和高效。这一节讲几个我在实际调优中总结的关键点也是 DSec 这类设施必须解决的核心工程问题。5.1 预热池的容量怎么定预热池太小任务来了要等冷启动太大闲置资源浪费。怎么找平衡点我的方法是看并发曲线。统计一天内并发沙箱数量的变化找到峰值和均值。预热池的常驻大小设为均值附近峰值靠动态扩容顶上去。动态扩容的速度取决于冷启动时间——如果冷启动 500ms那扩容就能跟上大部分突发如果冷启动 5 秒就得把常驻池设大一些。一个实用的经验公式常驻池大小 日均并发 × 1.2 最大池大小 峰值并发 × 1.51.2 和 1.5 这两个系数是留的缓冲具体根据你的并发波动程度调整。波动越大系数越高。5.2 资源限制别让一个沙箱拖垮一台机器资源限制是沙箱的生命线。CPU、内存、磁盘、进程数、文件描述符每一项都要设上限。我踩过最惨的坑是没限制进程数结果模型写了个 fork 炸弹虽然是误写的瞬间把宿主机进程表打满整台机器上的所有沙箱全挂了。必设的限制项CPU用 cgroup 的 cpu quota限制到具体核数内存硬限制超了直接 OOM kill别让它拖累别人进程数pids limit防止 fork 炸弹磁盘配额限制防止写满执行时间wall clock 超时防止死循环网络默认关闭需要时白名单放行注意内存限制要留一点余量。比如你想限制 2G实际设 2.2G因为进程启动本身有开销卡太死会导致正常任务被误杀。5.3 冷启动优化从秒级到毫秒级冷启动时间是沙箱设施的命脉。优化手段主要有三招第一招镜像预热。把常用镜像提前拉取到宿主机别等创建沙箱时才拉。这一步能把启动时间从几十秒降到几秒。第二招快照恢复。把初始化好的沙箱状态做成快照内存文件系统新沙箱直接从快照恢复跳过初始化过程。Firecracker 的 snapshot 功能就是干这个的能把启动压到毫秒级。第三招池化复用。前面说的预热池本质就是用空间换时间。沙箱用完不销毁重置后放回池子。这三招组合起来冷启动能从秒级降到几十毫秒。DSec 的 Elastic 能力核心就是把这套机制做扎实。5.4 监控与可观测性出问题时你能看到什么大规模系统没有监控就是裸奔。沙箱设施至少要监控这几类指标指标类别具体指标用途资源CPU/内存/磁盘使用率判断是否需要扩容性能创建延迟、执行延迟定位性能瓶颈健康沙箱失败率、超时率发现异常任务池化池命中率、池等待时间优化池大小我特别想强调池命中率这个指标。它直接告诉你预热池设得合不合理命中率低说明池太小任务总在等命中率高但资源利用率低说明池太大浪费。理想状态是命中率 90% 以上同时资源利用率 60% 到 70%。6. 那些文档里不会写的踩坑记录这一节是我最想写的部分。前面讲的都是应该怎么做这里讲实际做的时候会怎么翻车。这些坑官方文档基本不会提但每一个都能让你调半天。6.1 沙箱泄漏最隐蔽也最致命沙箱泄漏是指沙箱创建了但没被销毁慢慢把资源池耗光。它的隐蔽性在于短期内看不出问题可能跑几个小时才暴露那时候你已经去干别的了。泄漏的常见原因有三个异常路径没清理代码在execute时抛异常跳过了destroy。训练任务被中断任务被 kill但沙箱没被回收。SDK 连接断开网络抖动导致 SDK 和调度器失联沙箱成了孤儿。应对方法给沙箱加 TTL生存时间。每个沙箱创建时打上时间戳超过 TTL 还没被主动销毁的由后台清理任务强制回收。TTL 设长一点比如 1 小时正常任务不会受影响泄漏的沙箱也能被兜底清理。6.2 状态污染上一个任务的残留影响了下一个如果沙箱是复用的重置不彻底就会导致状态污染。我遇到过最诡异的一次某个任务在/tmp下写了个配置文件重置时没清掉下一个任务读到了这个文件行为完全错乱排查了整整一天。重置要清的东西比你想的多文件系统/tmp、工作目录、用户目录进程残留的后台进程环境变量任务里export的变量网络连接任务建立的连接共享内存/dev/shm里的内容最稳妥的重置方式是从快照恢复而不是清理。快照恢复能保证环境回到一个确定的初始状态不依赖清理逻辑的完备性。6.3 资源竞争邻居太吵怎么办同一台宿主机上的多个沙箱会竞争资源。如果隔离做得不好一个沙箱疯狂读写磁盘其他沙箱的执行延迟就会飙升。这就是所谓的吵闹邻居问题。缓解手段IO 限速用 cgroup 的 blkio 限制每个沙箱的磁盘带宽CPU 绑核把关键沙箱绑定到特定 CPU 核避免被抢占NUMA 感知多路 CPU 的机器上让沙箱的内存和 CPU 在同一 NUMA 节点这些优化在单机测试时看不出效果一到大规模就体现价值。DSec 这种规模的设施NUMA 感知几乎是标配。6.4 超时设置的两难超时设短了误杀设长了卡死。这个矛盾在智能体训练里尤其突出因为智能体生成的代码执行时间方差极大——简单的几毫秒复杂的可能几分钟。我的解法是分级超时快速任务如简单计算10 秒普通任务如数据处理60 秒长任务如模型推理300 秒任务提交时指定级别SDK 按级别设置超时。这样既不会误杀长任务也不会让短任务卡太久。更进一步可以动态超时先给一个初始超时如果任务在超时前有输出说明还活着就自动延长。7. 从 DSec 看智能体沙箱的未来形态写到这里我想跳出 DSec 本身聊聊这类设施的发展方向。因为智能体训练这个领域变化太快今天的方案可能半年后就过时了。7.1 沙箱正在从执行环境变成交互环境早期的沙箱只负责执行代码返回结果就完事。但现在的智能体越来越复杂它需要的不只是执行还有交互调用工具、访问数据库、操作浏览器、和其他智能体通信。沙箱的边界在扩大从代码执行器变成完整的交互环境。这对沙箱设施提出了新要求要能挂载各种工具和服务。DSec 的 SDK 设计很可能已经考虑了这种扩展性——通过插件或适配器的方式让沙箱能接入不同的工具。7.2 弹性不只是伸缩更是异构Elastic这个词传统理解是数量上的伸缩。但在智能体训练场景下它还有一层含义异构资源的弹性调度。有的任务需要 GPU有的只需要 CPU有的需要大内存有的需要快磁盘。沙箱设施要能根据任务需求调度到合适的资源上。这意味着调度器要维护一个多维资源视图而不只是 CPU 和内存。这也是为什么大规模沙箱设施的调度层往往是最复杂的部分。7.3 安全隔离的军备竞赛随着智能体能力增强它能生成的代码也越来越危险。沙箱的隔离强度必须跟上。从容器到 gVisor 到 microVM隔离在不断加强但性能开销也在增加。未来的方向可能是硬件辅助隔离比如 Intel 的 TDX、AMD 的 SEV在硬件层面提供隔离保证性能损耗更小。对于做智能体训练的人来说这意味着沙箱选型要留有余地——别把架构绑死在一种隔离方案上要能根据任务风险等级动态切换。7.4 标准化接口的缺失目前沙箱设施最大的问题是没有标准接口。每个平台都有自己的 SDK训练框架要适配不同的沙箱成本很高。如果未来能出现类似沙箱界的 POSIX这样的标准整个生态会健康很多。DSec 公开 SDK某种程度上也是在推动这个方向。当足够多的人用同一套接口标准就自然形成了。8. 给正在搭沙箱的人几句实在话最后这部分不讲技术讲讲心态和经验。因为搭沙箱这件事技术只是一半另一半是工程判断。第一别追求一步到位。我见过太多人一上来就想搭个支持万级并发的沙箱系统结果卡在第一个 bug 上就放弃了。正确的路径是先用最简单的方案比如 Docker跑通单任务再逐步加隔离、加池化、加调度。每一步都验证过再走下一步。第二把可观测性放在第一位。沙箱系统出问题时最难的不是修是定位。没有监控你连问题出在哪一层都不知道。所以从第一天起就要把日志、指标、追踪做起来哪怕简陋一点。第三重视异常路径。正常流程谁都能跑通真正体现功力的是异常处理超时怎么办、崩溃怎么办、网络断了怎么办。这些路径平时不触发一触发就是大事故。第四资源限制宁紧勿松。刚开始可能觉得限制太紧影响任务但比起一个任务拖垮整个集群紧一点是值得的。等摸清了任务的实际资源画像再逐步放宽。第五多看看别人怎么踩坑。沙箱这个领域很多坑是共通的。多读读同行的经验分享能省下大量试错时间。我写这篇文章也是希望能帮你少走点弯路。智能体训练还在快速演进沙箱基础设施也会跟着变。但有些底层原则是不变的隔离、弹性、可观测、异常处理。把这些做扎实不管上层怎么变你都能接得住。
