做沙箱服务的同行应该都有过这种体验智能体训练跑到一半环境没了整个样本作废或者刚拉起一个容器等了两分钟镜像才拉完训练进度卡在冷启动上。我们做 DSec 的时候一开始也是被这种问题按在地上摩擦后来才想明白训练场景要的根本不是“能开容器的工具”而是一个能扛住大规模并发、有状态、能恢复、能治理的集群级服务。目前它日均服务 300 万次沙箱这篇文章把我们从选型到落地过程中最值得说的部分拆开讲一遍。适合正在做智能体平台、Agent 评测基础设施、或者准备把沙箱能力产品化的团队参考。1. 看懂 300 万的前置条件训练沙箱和 CI 沙箱根本不是一个物种1.1 训练任务的时间量级分钟级到小时级状态必须连续很多人第一次听见“沙箱”两个字直觉反应是 CI/CD 里那种跑测试的环境拉镜像、跑用例、出报告、销毁整套流程分钟级搞定状态无所谓失败了重跑一次就行。但智能体训练沙箱完全不是这个逻辑。一个 Agent 在执行任务时可能需要连续调用代码解释器、浏览器、Shell 工具每一步的结果都会影响下一步决策。典型的一轮训练样本时长可能从几分钟延伸到一两个小时。这意味着它不是一个“执行一次就结束”的瞬时任务而是一个有状态的长会话文件系统里有中间产物进程树里有常驻进程内存里还有 Agent 自身的上下文。这种差异最直接的影响就是你不能简单地在训练中途把环境杀掉重来。一次中断损失的不只是计算资源而是整条训练轨迹的连续性。我们之前统计过训练任务因为环境中断导致的失败率每增加 1%整体样本有效率就掉得肉眼可见。所以 DSec 在设计第一天就定了一个死标准——环境必须能随会话保存和恢复而不是随实例销毁而消失。1.2 真要“开个容器就跑”会先踩在哪几个坑如果只是自己实验直接在宿主上起容器、用完删掉问题不大。但一旦把规模放到平台上让几十个团队一起用立刻会撞上三道墙。第一道墙是冷启动。容器镜像动辄几个 GB每次训练开始都要重新拉取网络差一点就是几十秒的等待。Agent 训练的调用频率很高冷启动时间会被直接放大成 GPU 资源的空转浪费和用户等待。第二道墙是状态恢复。“开个容器就跑”意味着所有状态都依赖容器本身容器一停Agent 的进度全丢。要做到断点续跑你得自己处理文件系统快照、内存转储、进程上下文恢复这一套逻辑写在业务代码里几乎等于重新发明一套虚拟机管理半成品。第三道墙是资源失控。训练 Agent 比测试脚本更容易把资源吃满某些模型为了探索边界会让沙箱疯狂 fork 进程、写临时文件、占内存。没有集群级配额和限额单个跑飞的沙箱就能拖垮一台宿主机连累其他正常任务。1.3 集群级服务的边界什么时候必须切换架构我们内部的判断标准其实很简单当你发现补丁永远打在机制之外就该换架构了。比如你开始写“定期清理僵尸沙箱”的守护脚本写“防止某个用户创建太多实例”的白名单写“把失败任务手动迁移到另一台机器”的运维工具——这些都是在给临时方案打补丁。真正该做的是把沙箱抽成服务让调度、恢复、限额这些能力变成平台的默认属性。DSec 的转折点发生在一个周五晚上一个大模型团队跑批任务因为一个测试用例死循环几百个沙箱同时把宿主机内存打爆连带把我们的内部镜像仓库也拖崩了。当时如果只是加脚本清理后面大概会一直陷在救火循环里。我们的选择是停下来用集群的思路重构整个沙箱体系。2. DSec 落地时的三个核心抽象快照、会话、实例2.1 为什么先把抽象定死再动代码做基础设施最忌讳一上来就写代码。DSec 前期我们花了两周时间只做一件事把名词定义清楚。因为名词一旦含糊后面调度器、API、存储设计都会跟着歪。最终定下来的三个核心抽象是这样分工的快照Snapshot一个时间点下沙箱文件系统和其他运行时数据的不可变拷贝。它代表“状态”。会话Session一次训练任务的逻辑身份有自己的生命周期、配额和归属关系。它代表“身份”。实例Instance运行中的沙箱包括独立的网络命名空间、进程、挂载点。它代表“计算”。三者之间是“一个会话可以对应多个快照也可以在不同时间绑定不同实例”的关系。想清楚这一点后面很多设计就顺了实例可以随时销毁重建快照保证状态还在会话保证用户不用感知底层变化。2.2 实例池与写时复制把“创建沙箱”变成“取出沙箱”确定抽象之后最关键的机制就是实例池。对比一下传统做法和 DSec 做法的差异传统做法是用户请求到了临时创建容器DSec 的做法是预先在集群里备好一组已启动、已联网、已挂好基础镜像的实例用户请求到了调度器直接分配一个空闲实例再根据会话的快照做恢复。这个差异带来的收益非常直接冷启动时间从几十秒降到秒级以下。因为分配实例的本质是“取出一个热备的实例”而不是“从零创建”。配套的还有两个底层技术一是写时复制Copy-on-Write。基础镜像不是每个实例完整复制一份而是多个实例共享同一份只读层只有当实例写入时才产生属于自己的差异层。这能让内存和磁盘的占用率成倍下降。我们实测下来一个 5GB 的基础镜像跑到稳定状态后绝大多数实例额外占用的根文件系统空间不到 200MB。二是快照继承。当系统拿到一个新会话请求时如果发现有相似基准的旧快照可以直接从旧快照 fork 出新的差异层而不是重新加载完整基础快照。这个操作和文件系统层的 COW 复用共同决定了平台能扛住的并发上限。2.3 会话与实例解耦就算底层滚训练还能接着跑训练平台最容易踩的坑是把会话直接绑死在实例上。一旦实例被回收会话跟着消失用户就要从头再来。DSec 把两者解耦之后我们得到了一个额外的好处实例调度可以“不负责任”。实例不够用时系统可以把某一些实例上的会话先落成快照实例回收到池里等新请求再恢复。这对用户是透明的但对平台来说意味着资源池获得了完全独立的伸缩能力。回收入池时会话的快照会写到一个分布式存储层恢复时调度器挑一个空闲实例加载快照把网络和进程环境恢复好再把实例和控制通道建立连接。用户感知到的只是“任务暂停了一下”而不是“环境没了”。这也让底层宿主机维护变得非常从容。机器要升级内核、调整网络参数我们只需要先把这台机器上的实例置为“不可调度”等它上面所有会话都落成快照再安全停机。整个过程不影响平台整体服务。3. 按日均 300 万反推容量核心并发数据与资源预算3.1 从 QPS 到并发实例数的推算过程日服务 300 万次听起来是个抽象的数字工程上必须先把它换算成并发实例数。这里分享我们的推算思路你的均值参数如果不同按公式替换即可。基础数据一天 86400 秒300 万次请求平均下来是每秒约 34.7 次新建会话请求。这个 QPS 其实不高但沙箱是长生命周期资源真正决定容量的是并发实例数 每秒请求数 × 平均会话时长。假设一次训练会话的平均时长是 10 分钟600 秒那么并发实例数就是34.7 次/秒 × 600 秒 ≈ 20800 个实例这意味着集群任何时刻都要能同时维持两万个左右的运行态沙箱这还没有计算突发流量。我们把峰值并发按平均并发的 22.5 倍预留也就是按 4 万到 5 万实例的容量做规划。资源预算也跟着换算如果每个实例平均分配 0.5 vCPU 和 512MiB 内存并发 2 万实例时需要的总量大约是 1 万 vCPU 和 10TiB 内存。注意这只是平均估算真实规划里必须留出突发 buffer 和 system overhead。3.2 预热池与冷启动优化池子该留多大在实例池设计里最需要拿捏的是池的大小。池太小峰值时不够分池太大空闲实例白占内存。我们的做法是预热池大小按峰值并发的 10%15% 配置。以 4 万峰值实例算预热池约 40006000 个。这些实例保持网络、进程、基础根文件系统就绪随时可以分配出去。为什么不是 100% 就绪因为并不是每个请求都需要全新实例一部分请求可以直接继承现有空闲实例另一部分请求会加载已有快照真正需要“冷启动”的比例不高。我们压测时发现15% 预热池加上 COW 机制足以把 95% 以上的会话请求控制在 1 秒内完成“取出实例 恢复快照”的完整流程。3.3 网络、DNS 与调度时延真正卡脖子的地方300 万的体量跑起来之后真正开始卡脖子的不是 CPU 也不是内存而是几个边缘瓶颈。第一是网络命名空间的创建。在 Linux 里创建新网络命名空间是一个系统调用较重的操作并发高时内核锁会成为瓶颈。我们后来改用“网络命名空间池化”的方式在宿主机启动时预创建一批 netns实例分配时绑定回收时归还效果立竿见影。第二是 DNS。智能体会话会频繁做域名解析访问的外部数据源、模型服务地址五花八门如果不做本地 DNS 缓存每次解析都要穿透到上游时延高而且容易触发限流。我们在每个实例里内置了一个本地 DNS 缓存代理热点域名直接命中整体会话时延下降不少。第三是调度决策本身。DSec 调度器不能简单按“CPU 空闲”来选节点还必须看内存水位、镜像缓存命中率、快照存储亲和性、实例池余量。排序维度一多调度器就必须做到异步化和批量决策不能每个请求同步算一遍全集群状态否则调度器自己就成了瓶颈。4. 跑量之后最重要的其实是治理隔离、配额与回收4.1 单沙箱的配额设计与“允许挤一下”的调度哲学沙箱跑到量级以后治理就是平台的生命线。一个跑飞的沙箱能拖垮一台宿主机一个无上限的租户配额能拖垮整个集群。我们的货币单位是“实时使用量 峰谷系数”每个会话创建时可以指定配额上限但调度执行时不会机械地卡死峰值。因为智能体训练经常出现短时间内存飙升比如处理一个大文件如果把配额写死任务直接 OOM谁都不好受。DSec 的做法是允许沙箱在短时间内“挤”到配额上限的 1.5 倍但如果持续超过配额阈值并影响同节点其他沙箱就会被降级甚至回收。这里的关键是判断“短暂合理”和“持续异常”。我们结合了 cgroup v2 的 pressure 指标来判断节点是否因为某个实例受影响过大一旦超过阈值就触发主动干预。4.2 进程树、磁盘与内存的回收闭环内存回收相对容易cgroup 限制住就能保证不拖垮宿主。真正麻烦的是进程树和磁盘。训练 Agent 喜欢 fork有时候跑一圈下来能拉出上百个子进程。实例回收时如果只是杀掉主进程子进程会变成孤儿进程继续跑蚕食 CPU 和内存。DSec 回收每个实例时会把整个进程组全部 kill并且用 PID namespace 隔离保证不会误杀其他实例的进程。磁盘回收是另一个隐蔽的坑。Agent 写临时文件很凶猛如果不给实例挂独立的磁盘配额一个沙箱就能把节点磁盘写爆。我们的经验是按实例挂 quota超出即清理临时目录空闲实例超过一定时长自动触发“快照落盘 实例回收”快照层要定期做合并压缩否则差异层越积越多恢复成本越来越高。4.3 多租户配额与额度成本平台开放给多个团队使用之后配额治理就变成了政治问题。我们这里不搞“平均主义”每个租户有明确的每日会话数上限和资源额度而且额度是按“累计资源占用 × 时长”计费的而不是按“创建次数”计费。这种计费方式的优势在于它逼着使用方优化自己的会话时长。以前有人把沙箱当常驻虚拟机一个会话丢在那里几天不关资源白白烧掉。改成按时长计费后这类浪费自动消失了因为没人愿意为一个空闲会话持续付钱。与之配套的还有告警和熔断。单个租户在短时间内创建会话的速率如果超过阈值系统会先告警再自动限流连续触发多次直接熔断该租户的创建接口。这些策略配在一起才让“日服务 300 万”成为可持续的数字而不是某一天的尖峰。5. 从自用脚本变成平台给同行的四条经验5.1 别把“临时 Pod”模式搬进训练平台我们在第一步时差点犯一个典型错误直接用 Pod 模式做每次会话对应一个 Pod用完删掉。这样做的好处是 Kubernetes 管好了生命周期但坏处非常致命——Kubernetes 默认不关心训练会话的状态恢复Pod 一删状态全丢。后来我们强制自己接受了一个观念训练平台的核心不是“调度容器”而是“管理状态”。容器只是状态的载体。架构上要把状态管理放在更外层让底层 PaaS 可以随时替换而不是把业务绑定到某个具体计算单元上。如果你们团队也在从零搭这类平台我的建议是先用最小原型验证“快照恢复”这条路走不走得通再考虑扩容和性能优化。状态恢复搞不定后面全是白搭。5.2 会话可观测性和成本可视化要当功能做做平台最大的隐性成本是“看不见”。用户不知道自己的会话跑在哪台机器上、快照占了多少空间、为什么会话被回收。DSec 上线一段时间后我们把“会话全景图”做成了平台内一等公民功能每个会话都能看到观测项说明会话状态运行中、已暂停、已结束、已回收实例节点当前所在宿主机与实例 ID快照大小基础层 差异层的磁盘占用资源消耗历史 CPU、内存、网络流量曲线配额余量当前租户当日剩余创建数和资源额度这个功能上线之后用户投诉量直线下降。因为绝大多数“为什么我的任务挂了”的问题用户自己打开面板看一眼就明白了。5.3 预留故障注入与降级演练平台量级越大越要敢于“主动破坏”。我们在每次大版本发布前都会做一轮故障演练随机杀掉宿主机、随机断掉快照存储的访问、随机把调度器切到降级模式。演练的目标不是证明系统不出故障而是证明故障发生后系统能在可接受时间内恢复。降级模式是我们专门设计的调度器不可用时不新建会话但存量会话继续运行快照存储不可用时暂停恢复和落盘存量实例保持不受影响。这套“可用性优先”的设计让我们在几次真实故障中做到了用户无感。5.4 快启动的最小可行组合优先级最高的三件事如果想快速跑通一个沙箱服务原型我的建议是抓住三个优先级最高的事情第一把镜像预热和实例池机制建立起来。没有热池一切都是空谈实测数据表明热池对用户体验的提升幅度最大。第二把快照的“保存—恢复”链路打磨到自动化。手工快照没意义必须让平台在实例释放和重新分配时自动完成。第三做好进程组隔离。这一步决定了你的多租户安全性和稳定性底线值得在最早期投入。至于精细的配额计费、复杂调度策略、多集群联邦这些可以等业务跑起来之后再迭代。先把主干走通旁支细节不会致命。我在 DSec 上最大的一条体会是当你能用“平台的能力”覆盖掉沙箱的故障、恢复、配额这些琐碎问题团队才能真正把注意力放到智能体本身的训练效果上。日服务 300 万不是一个值得炫耀的数字真正值得炫耀的是这 300 万次背后每一次环境提供都能让用户觉得“理所当然”。
