1. 三百万沙箱这个数字到底意味着什么第一次看到一天创建 300 万个沙箱这个量级我的反应和大多数人一样这数字是不是写错了后来自己动手算了一遍账才发现这个数字背后藏着的工程压力远比表面看起来要吓人。先做个简单的除法。一天 86400 秒300 万个沙箱意味着平均每秒要创建大约 35 个沙箱。注意这是平均值。真实负载从来不是均匀分布的训练任务往往是批量下发的一波 rollout 可能瞬间涌入几千个并发请求。也就是说峰值时刻的创建速率很可能是平均值的十倍甚至几十倍每秒几百个沙箱同时拉起这才是真正考验系统的地方。那为什么 Agent 训练需要这么多沙箱这得从 Agent 的训练范式说起。传统的语言模型训练输入是一段文本输出是一段文本整个交互是一问一答式的。但 Agent 不一样Agent 要跟环境交互它要执行代码、要调用工具、要读取文件、要观察执行结果然后根据结果决定下一步动作。这个执行-观察-再决策的循环就是所谓的rollout。一次完整的 rollout可能包含几十甚至上百步的工具调用。每一步调用都需要一个隔离的执行环境防止 Agent 生成的代码把宿主机搞崩也防止不同训练样本之间互相污染。这就是沙箱存在的意义。你可以把沙箱理解成给每个 Agent 单独发了一间实验舱它在里面怎么折腾都行炸了也只炸自己那一间。问题在于Agent 训练不是跑一次就完事。强化学习式的训练需要大量采样同一个任务要跑很多遍不同任务要并行跑还要做对比实验。300 万个沙箱本质上就是 300 万次独立的实验舱生命周期管理。这里面涉及创建、初始化、执行、销毁四个阶段每个阶段都有坑。我见过不少团队一开始用 Docker 起沙箱单机跑几十个没问题一上规模就崩。原因很简单Docker 的创建开销在秒级300 万个沙箱光创建就要消耗海量时间更别说容器运行时本身的内存和 CPU 开销。所以真正撑住这个量级的方案一定不是朴素地用容器而是一整套围绕沙箱生命周期重新设计的系统工程。这一篇我就围绕这个标题把 Agent 训练场景下沙箱系统的核心难点、技术选型、实操细节和踩坑经验尽量讲透。不管你是正在做 Agent 训练平台的工程师还是想理解大规模沙箱背后原理的开发者应该都能从中拿到一些能直接用的东西。2. 沙箱创建速率背后的四道工程关卡2.1 第一道关卡冷启动延迟沙箱创建最直观的瓶颈就是冷启动。一个全新的沙箱从决定创建到可以执行代码中间要经历分配资源、加载运行时、初始化文件系统、配置网络隔离等一系列动作。如果每个沙箱都要走完整流程那创建速率根本上不去。我实测过几种常见方案的冷启动时间数据大概是这样方案冷启动延迟单机并发上限隔离强度完整虚拟机10-30 秒几十个最强标准容器0.5-2 秒几百个中等轻量容器运行时50-200 毫秒上千个中等偏强微虚拟机100-300 毫秒上千个强进程级隔离10-50 毫秒数千个弱从这张表能看出来隔离强度和启动速度基本是反比关系。Agent 训练场景下隔离强度不能太弱因为 Agent 生成的代码是不可信的可能包含死循环、内存炸弹、文件系统破坏等操作。但启动速度又必须够快否则撑不住每秒几十上百的创建速率。所以主流方案基本都落在微虚拟机和轻量容器运行时这两个区间。微虚拟机的思路是用轻量级 hypervisor 给每个沙箱一个独立内核隔离强度接近虚拟机但启动速度接近容器。轻量容器运行时则是把容器的很多默认功能砍掉只保留最核心的隔离能力换取更快的启动。2.2 第二道关卡资源预分配与池化光靠优化冷启动还不够。就算单个沙箱 100 毫秒能起来每秒创建 35 个意味着系统里始终有大量沙箱在创建中状态这些中间态会占用资源、消耗调度器注意力。真正撑住高并发的关键手段是池化。思路很朴素提前创建好一批沙箱让它们处于待命状态需要的时候直接从池子里取用完归还而不是销毁。这样创建动作被摊薄到后台前台请求几乎感觉不到延迟。但池化有几个必须想清楚的问题。第一个是池子大小怎么定。太小了不够用太大了浪费资源。我的经验是按峰值并发的 1.2 到 1.5 倍来配置留出缓冲。第二个是池子里的沙箱状态怎么管理。如果上一个任务在沙箱里留了文件、改了环境变量下一个任务直接用就会出问题。所以归还时必须做状态重置把沙箱恢复到初始快照。状态重置本身也有讲究。全量重建文件系统太慢通常的做法是基于写时复制或者快照回滚。沙箱启动时挂载一个只读的基础镜像所有写操作都落到一个可写层归还时直接丢弃可写层瞬间回到初始状态。这个机制是池化方案能成立的技术基础。2.3 第三道关卡调度器的吞吐能力沙箱创建请求不是凭空产生的它来自训练框架的 rollout 调度。调度器要决定哪个任务先跑、分配到哪台机器、用池子里的还是新建、超时了怎么处理。这些决策如果做得慢就会成为整个链路的瓶颈。我见过一个典型的反模式调度器用单线程处理所有请求每个请求都要查数据库、算资源、写日志。结果沙箱创建速率卡在每秒几个完全上不去。后来改成批量调度 异步落盘吞吐直接翻了两个数量级。调度器设计的核心原则是决策路径上只做必要的事。资源计算可以预计算日志可以异步写数据库查询可以加缓存。把非关键路径的操作全部挪出主流程调度器才能跑得快。2.4 第四道关卡销毁与资源回收创建快销毁也得快。300 万个沙箱意味着同样有 300 万次销毁。如果销毁时要做大量清理工作比如删除临时文件、释放网络端口、回收内存这些操作累积起来同样是巨大的开销。销毁阶段最容易踩的坑是资源泄漏。沙箱进程被杀了但它占用的端口没释放、挂载点没卸载、临时目录没删除。跑一段时间后机器上全是僵尸资源新沙箱创建不出来。所以销毁流程必须有兜底清理机制定期扫描并回收孤儿资源。另一个坑是销毁的时机。有些实现是同步销毁请求返回前必须等销毁完成这会拖慢整体吞吐。更好的做法是异步销毁把销毁任务丢进队列后台慢慢处理。只要池子里的待命沙箱够用前台就不会感知到销毁的延迟。3. 隔离方案选型从容器到微虚拟机的取舍逻辑3.1 为什么不能直接用 Docker很多团队的第一版沙箱系统就是 Docker。写个 Dockerfile起容器执行代码删容器。单机测试跑得挺欢一上规模就各种问题。Docker 的问题不在于它不好而在于它的设计目标不是高密度、短生命周期。Docker 的默认配置里每个容器都有完整的文件系统层、独立的网络命名空间、独立的进程树。这些特性在长期运行的服务场景下是优点但在沙箱场景下就是负担。具体来说Docker 创建容器的开销主要来自几块文件系统层的挂载、网络命名空间的配置、cgroup 的创建。其中文件系统层最重因为 Docker 用的是分层镜像每次创建都要把各层叠加起来。如果镜像层数多这个叠加过程就很慢。我做过一个对比测试同一个基础镜像用 Docker 起容器平均 800 毫秒用轻量运行时起只要 80 毫秒差了十倍。这个差距在 300 万量级下就是天壤之别。3.2 微虚拟机方案的核心优势微虚拟机这两年在沙箱场景下越来越流行核心原因是它在隔离强度和启动速度之间找到了一个很好的平衡点。它的原理是用一个极简的 hypervisor 给每个沙箱启动一个独立的内核但这个内核是专门裁剪过的只保留运行代码必需的功能。因为没有完整的硬件模拟启动速度可以做到接近容器。同时因为每个沙箱有独立内核隔离强度又接近传统虚拟机。对 Agent 训练来说这个特性特别重要。Agent 生成的代码可能包含各种系统调用如果隔离不彻底一个沙箱里的恶意代码可能影响到其他沙箱甚至宿主机。微虚拟机从内核层面做了隔离安全性有保障。不过微虚拟机也不是没有代价。它的内存开销比容器大因为每个沙箱都要跑一个独立内核。通常一个微虚拟机沙箱的基础内存占用在几十 MB 级别而容器可以做到几 MB。所以在内存紧张的机器上微虚拟机的密度会低一些。3.3 选型决策表到底选哪种方案不能拍脑袋得看具体约束。我整理了一个决策参考约束条件推荐方案理由隔离要求极高代码完全不可信微虚拟机内核级隔离安全性最好追求极致密度隔离要求中等轻量容器运行时内存开销小密度高需要兼容现有容器生态标准容器 优化生态成熟改造成本低任务执行时间极短毫秒级进程级隔离 资源限制启动最快但隔离弱需要 GPU 直通微虚拟机或特权容器需要硬件访问能力我的建议是如果预算允许优先考虑微虚拟机。Agent 训练场景下代码的不可信程度很高隔离强度不够会带来很大的安全隐患。省下来的那点内存不值得用安全风险去换。3.4 网络隔离的细节沙箱的网络隔离经常被忽视但它其实是隔离方案里最容易出问题的一环。Agent 执行代码时可能需要访问网络比如调用 API也可能完全不需要网络。如果不需要最好直接禁用网络减少攻击面。如果需要就要做细粒度的控制限制能访问哪些地址、限制带宽、限制连接数。我踩过的一个坑是沙箱默认继承了宿主机的 DNS 配置结果 Agent 生成的代码通过 DNS 查询探测到了内网结构。后来改成给每个沙箱配独立的 DNS并且只允许解析白名单里的域名问题才解决。网络隔离还有一个实践细节端口管理。如果沙箱需要监听端口端口分配要避免冲突。常见做法是给每个沙箱分配一个端口段或者用网络命名空间做端口隔离。后者更干净但配置复杂度更高。4. rollout 场景下沙箱生命周期的真实管理链路4.1 一次 rollout 的完整时间线要理解沙箱管理得先理解一次 rollout 在时间线上是怎么走的。我拿一个典型的代码 Agent 任务举例训练框架下发一个任务包含任务描述和初始状态调度器收到请求从池子里取一个沙箱或者新建一个沙箱初始化挂载工作目录、注入任务上下文、配置环境Agent 开始执行生成第一段代码代码在沙箱里执行产生输出Agent 读取输出决定下一步动作重复 4-6直到任务完成或达到步数上限收集执行轨迹返回给训练框架沙箱归还到池子或者销毁这个流程里沙箱的活跃期其实只占一部分时间。步骤 3 到 8 是沙箱真正在干活的时间步骤 2 和 9 是管理开销。如果管理开销占比太高整体效率就上不去。我统计过一个真实系统的数据沙箱平均活跃时间 8 秒创建加销毁开销 1.5 秒管理开销占比接近 16%。这个比例在 300 万量级下意味着有大量算力浪费在管理上。优化空间主要就在池化和异步化这两块。4.2 状态注入的坑沙箱初始化时需要把任务上下文注入进去。这个动作看起来简单实际上坑很多。最常见的问题是注入内容太大。有些任务需要注入大量文件或者数据集如果每次都全量拷贝初始化时间会很长。解决办法是用共享存储 软链接把大文件放在共享存储上沙箱里只放一个链接。这样初始化只需要创建链接不用拷贝数据。另一个问题是注入内容的隔离。如果多个沙箱共享同一份注入内容一个沙箱修改了内容其他沙箱就会受影响。所以注入内容必须是只读的或者每个沙箱有独立的副本。前者更省资源但要求任务本身不依赖修改注入内容。还有一个隐蔽的坑是环境变量泄漏。沙箱初始化时会继承一些环境变量如果不小心把宿主机的敏感变量带进去了Agent 生成的代码可能读到不该读的信息。所以初始化时要显式清理环境变量只保留必要的几个。4.3 执行超时与中断处理Agent 生成的代码可能进入死循环或者执行时间远超预期。如果没有超时机制沙箱会被一直占用池子很快耗尽。超时处理的关键是分级。我通常设三层软超时、硬超时、强制超时。软超时到了给 Agent 发个信号让它有机会优雅退出。硬超时到了直接杀进程。强制超时到了连沙箱一起销毁不管里面在干什么。这三层超时的阈值要根据任务类型调整。代码执行类任务单步超时可能设 30 秒工具调用类任务可能设 10 秒。阈值设得太松资源浪费设得太紧正常任务被误杀。我的经验是先设宽松一点观察实际分布再逐步收紧。中断处理还有一个细节中断后的状态清理。如果沙箱被强制中断里面可能残留了半执行的状态。归还到池子前必须做完整重置否则下一个任务会拿到脏状态。这也是为什么池化方案里状态重置必须做得彻底。4.4 轨迹收集与沙箱销毁的时序rollout 结束后需要把执行轨迹收集起来返回给训练框架。这个动作和沙箱销毁之间有时序关系处理不好会丢数据。我见过的问题是沙箱销毁得太快轨迹还没收集完文件就被删了。解决办法是先收集、后销毁并且收集动作要有确认机制。收集完成后打个标记销毁流程看到标记才继续。另一个问题是轨迹数据量太大。一次 rollout 可能产生几十 MB 的日志和输出300 万次 rollout 就是 PB 级的数据。如果每次都全量传回网络和存储都扛不住。通常的做法是在沙箱侧做预处理只回传关键信息原始数据按需保留或者直接丢弃。5. 撑住高并发的几个关键工程手段5.1 预热池的动态伸缩策略池化方案的核心是预热池但池子大小不能固定。训练任务的负载是波动的有时候一波 rollout 涌进来池子瞬间见底有时候任务稀疏池子里的沙箱闲着浪费资源。动态伸缩的思路是监控池子的水位和请求速率据此调整池子大小。水位低于阈值就扩容高于阈值就缩容。扩容要快因为请求不等人缩容要慢避免刚缩完又来一波请求。具体参数上我的经验是扩容触发线设在池子使用率 70%缩容触发线设在 30%。扩容步长可以大一点比如一次扩 20%缩容步长小一点一次缩 5%。这样既能快速响应突发流量又不会频繁抖动。伸缩还有一个隐藏问题扩容本身需要时间。新建沙箱不是瞬间完成的如果扩容速度跟不上请求涌入速度池子还是会见底。所以扩容要提前触发不能等池子空了才开始扩。用请求速率的趋势做预测提前扩容效果会好很多。5.2 批量创建与并行初始化单个沙箱创建慢那就批量创建。把多个创建请求合并成一批共享一些初始化工作整体吞吐能提升不少。批量创建的关键是找到可共享的部分。比如多个沙箱用同一个基础镜像那镜像加载可以只做一次然后 fork 出多个沙箱。又比如多个沙箱需要同样的依赖包那依赖安装可以预置在镜像里不用每个沙箱都装一遍。并行初始化是另一个手段。沙箱创建涉及多个步骤分配资源、加载镜像、配置网络、注入上下文。这些步骤如果串行做总时间就是各步骤之和。如果能并行总时间就取决于最慢的那一步。实践中资源分配和镜像加载可以并行网络配置和上下文注入可以并行整体能省 30% 到 50% 的时间。5.3 资源超卖与配额管理高密度场景下资源不可能按峰值分配必须做超卖。所谓超卖就是分配的资源和实际物理资源之比大于 1。比如一台机器有 64 GB 内存但分配出去 128 GB 的配额。超卖能成立的前提是沙箱不会同时用满配额。Agent 执行代码时大部分时间在等 IO 或者等模型推理CPU 和内存的实际使用率并不高。只要超卖比例控制得当不会出问题。但超卖有风险。如果多个沙箱同时申请大量内存机器就会 OOM。所以必须有配额管理机制每个沙箱有内存上限超了就杀整机有总配额快满了就拒绝新请求。配额管理做得好超卖比例可以做到 2 倍甚至 3 倍做得不好系统会频繁崩溃。我的经验是CPU 可以超卖得多一些内存要保守一些。因为 CPU 是时间片调度超卖了只是变慢内存是硬约束超卖了直接 OOM。内存超卖比例建议控制在 1.5 倍以内。5.4 故障隔离与自愈300 万个沙箱不可能每个都正常运行。总会有沙箱卡死、崩溃、资源泄漏。关键是故障不能扩散一个沙箱出问题不能影响其他沙箱。故障隔离的第一道防线是资源限制。给每个沙箱设 CPU、内存、磁盘、网络的硬上限超了就限制或者杀掉。这样单个沙箱的异常不会拖垮整机。第二道防线是健康检查。定期检查沙箱状态发现异常就标记并回收。健康检查不能太重否则本身就成了负担。通常检查几个关键指标就够了进程是否存活、资源使用是否正常、是否响应心跳。第三道防线是自愈。发现故障沙箱后自动销毁并补充新的。这个过程要快不能让池子水位掉太多。自愈逻辑要和伸缩逻辑配合避免重复扩容。6. 踩过的坑与实测经验6.1 池子里的沙箱变质问题池化方案跑了一段时间后我发现一个诡异现象从池子里取出的沙箱有时候行为不正常执行结果和预期不符。排查了很久才发现是沙箱变质了。所谓变质就是沙箱在归还后没有完全重置。有些残留状态没清理干净比如临时文件、环境变量、后台进程。下一个任务拿到这个沙箱就继承了这些脏状态。这个问题的根因是重置逻辑不完整。我们最初的重置只做了文件系统回滚没管进程和环境变量。后来改成全量重置杀所有用户进程、清所有环境变量、回滚文件系统、重置网络配置。问题才解决。这个坑的教训是重置要做得比创建还彻底。创建时是从干净状态开始重置时是要回到干净状态后者更难因为要清理的东西更多。6.2 调度器的惊群效应调度器在高并发下出现过一个性能问题大量请求同时到达时调度器会同时唤醒多个工作线程去处理结果线程之间互相竞争整体吞吐反而下降。这就是惊群效应。解决办法是请求排队 单线程分发。所有请求先进队列一个分发线程从队列里取请求按顺序分配给工作线程。这样避免了竞争吞吐反而上去了。另一个相关问题是锁竞争。调度器里如果有共享状态多线程访问就要加锁。锁粒度太粗就成了瓶颈。后来把状态拆成多个分片每个分片独立加锁竞争就小多了。6.3 镜像加载的 IO 瓶颈沙箱创建时需要加载基础镜像。如果镜像很大加载时间就长而且多个沙箱同时加载会打满磁盘 IO。优化手段有几个。第一是镜像分层把不常变的部分和常变的部分分开常变的部分做小。第二是镜像缓存加载过的镜像缓存在本地下次直接用。第三是预加载在池子扩容时提前把镜像加载好请求来了直接用。我实测下来镜像分层 本地缓存能把加载时间从秒级降到百毫秒级。如果再配合预加载前台几乎感觉不到镜像加载的开销。6.4 监控指标的选取大规模沙箱系统监控是必须的。但监控指标不能太多否则监控本身就成了负担。我通常关注这几类创建速率每秒创建多少沙箱反映系统吞吐创建延迟从请求到沙箱可用的时间反映用户体验池子水位待命沙箱数量反映容量是否充足失败率创建失败、执行失败的比例反映系统健康度资源使用率CPU、内存、磁盘的实际使用情况反映超卖是否合理这几类指标能覆盖大部分问题。指标异常时再下钻看细节。不要一上来就监控几十个指标那样只会淹没在数据里。6.5 一个反直觉的发现最后分享一个反直觉的发现沙箱创建速率的上限往往不是沙箱系统本身决定的而是上游调度决定的。我们优化了很久沙箱创建把单机创建速率提到了很高但整体吞吐还是上不去。后来发现瓶颈在调度器调度器每秒只能处理这么多请求沙箱系统再快也没用。所以优化要看全链路不能只盯着一个环节。找到真正的瓶颈集中火力优化比到处撒网有效得多。这也是我做这类系统最大的体会系统性能取决于最慢的那一环而不是最快的那一环。7. 从 300 万这个数字回看 Agent 训练的基础设施要求300 万个沙箱这个数字表面上看是个规模问题本质上是个基础设施成熟度的问题。能撑住这个量级的系统一定不是在某个单点上做得特别好而是在创建、调度、隔离、回收、监控每个环节都做到了工程上的及格线以上。我自己的经验是做这类系统要避免两个极端。一个极端是过早优化还没跑通就开始抠性能结果架构改来改去进度全耽误了。另一个极端是忽视规模用单机思维做分布式系统等到量级上来了再重构成本高得多。比较务实的路径是先跑通再压测找到瓶颈针对性优化。每一步都有明确的验证标准不盲目追求最优解。沙箱系统这种东西没有银弹只有不断迭代。如果你正在做类似的事情我的建议是先把池化 异步销毁这两个基础做扎实它们能解决 80% 的性能问题。剩下的 20%等遇到具体瓶颈再针对性处理。至于隔离方案如果安全要求高早点上微虚拟机别等到出了安全事故再改那时候改造成本会大得多。