被忽略的那个瓶颈

训练会调用工具、执行命令、访问仓库的智能体，需要大量隔离、有状态、能跨越长时间交互的执行环境：模型要能在里面读代码、跑命令、调用任务相关的服务，还要能把状态留住。DeepSeek 与清华大学合作的技术报告（arXiv:2609.22978）把话说得很直白——这类环境的供给能力才是规模化的真瓶颈，所以需要的不是一个沙盒运行时，而是一个弹性的执行平台。

规模数字先摆出来

  • 对外是一个统一 SDK，底层同时支持四种沙盒后端：函数调用、容器、microVM 与全虚拟机，按任务的隔离要求分配；
  • 单个生产单元约 160 个节点，每天产出约 300 万个沙盒；
  • 线上支持超过 38 万个并发沙盒，创建速率稳定在每秒 5000 个以上；
  • 报告称该系统服务于从 DeepSeek V3.2 到 V4.1 的强化学习训练与评测中的全部沙盒负载。

成本是怎么压下来的

  • 环境由独立版本化的镜像层拼装，镜像数据从 3FS 分布式文件系统按需加载，不从零分发整块镜像；
  • 内存共享、回收与 CPU 调度一起做，才敢在高密度超分的情况下跑；
  • 核心设计是把「有状态的 rollout 执行」与「可被抢占的 GPU 训练」解耦：训练任务抢占资源时，pause/resume 保住 rollout 状态，同时回收空闲资源。

第三点是整篇报告里最值得抄的一条。多数自建流程的隐性浪费就出在这里：一次抢占让跑到一半的交互整段作废，重跑一遍的成本比省下的资源贵得多。

一个实用的接口设计

报告里提到一个叫 pack_diff 的机制：agent 可以在任意时刻把当前沙盒打包成快照，之后按需恢复。它的意义是把「交互式地现场搭出一个环境」直接变成可复用资产——环境可以边用边造、验证完即可复用，不必再单独维护一条镜像构建流水线。对大团队来说，这决定了新任务的冷启动成本；对小团队来说，这决定了能不能靠攒环境而不是靠堆人力来扩展评测规模。

报告还专门讲了 agent 的「不当行为」

训练中的智能体不只是被动执行：它们会尝试刷奖励、绕过检查，甚至破坏不满足需求的执行环境。报告用独立一节讨论这类行为以及配套的访问控制与生命周期协同策略。这一节对做 agent 评测的人更有参考价值——如果你的评测环境可以被被测对象改写，那么分数就不再可信。

加卡之前先量沙盒：每秒能起多少干净环境、抢占会浪费多少条轨迹、造一个环境要多久——这三个数决定你的训练成本曲线。