Accelerating agentic RL and evaluation research velocity with 45x faster GKE Agent Sandbox

TL;DR · AI 摘要
Accelerate agentic RL with GKE Agent Sandbox Google Cloud Blog Containers & Kubernetes Accelerating agentic RL and evalu...
核心要点
- 主题聚焦:Accelerating agentic RL and evaluation research
- 来源:Google Cloud Blog,建议结合原文判断细节。
- AI 分析暂不可用,本条为保底评分与摘要。
使用 GKE Agent Sandbox 加速智能体强化学习 | Google Cloud 博客
容器与 Kubernetes
通过 45 倍更快的 GKE Agent Sandbox 加速智能体强化学习与评估研究速度
2026 年 9 月 30 日
##### Shi Tinsley
产品经理
##### Tomer Glottmann
高级软件工程师、技术负责人
##### 立即体验 Gemini Enterprise
职场人工智能的入口
立即体验
当在大规模并行 rollout 中扩展智能体强化学习(RL)和评估时,前沿 AI 实验室不可避免地会遇到瓶颈:昂贵的 GPU 集群处于空闲状态,等待数分钟的 CPU 沙盒冷启动,以及数千个类似 SWE-bench 的多千兆字节镜像拉取和调度积压。这是一个静默减缓研究进度并消耗训练预算的沙盒基础设施问题。
为了解决这个根本性的基础设施瓶颈,今天我们将推出专为 RL 优化的 GKE Agent Sandbox,以及 Agent Sandbox RL 编排 SDK,同时提供对主流 RL 实验室和工具链的原生集成,现已正式发布。
作为现代人工智能的操作系统,Kubernetes 已经发展到支持大规模 GPU/TPU 训练集群和分布式推理。现在 Kubernetes 正在扩展到驱动下一个 AI 计算前沿:智能体。但与静态工作负载不同,智能体工作负载演变迅速,因此基础设施必须同样快速进化。我们没有猜测 RL 研究人员的需求,而是将 Kubernetes 本身置于由性能基准和评估驱动的自动研究和验证循环中。我们使用 SWE-bench 等重型智能体基准测试有意对集群进行压力测试并暴露问题。从 etcd 超时到 GPU 空闲峰值等每个瓶颈都会反馈到我们的开发周期中,以完善 GKE 的核心原语。
这产生了专为智能体 RL 和评估工作负载打造的沙盒层,具备以下特性:
- 首条指令响应时间提升 10 倍至 45 倍:GKE 可在 1-9 秒内启动沙盒环境,而非原来的 45-85 秒,使昂贵的 GPU 保持持续使用。
- 尾部延迟显著降低:最坏情况下的沙盒等待时间从 7.5 分钟降至 10 秒以内。
- 控制平面资源消耗减少 3 倍:每个 RL 训练步骤会触发一次 rollout 爆发,此时数千个沙盒会同时被请求。SDK 采用原地复用策略,通过跨 rollout 重用 Pod 而非删除重建,这意味着创建的 Pod 数量减少 3 倍,从而在高负载下保持 Kubernetes API 服务器的稳定性。
借助这一新原语,AI 实验室和原生智能体初创公司现在可以可靠地同时运行大规模智能体 RL 轨迹和评估,最大限度减少加速器空闲时间,并显著加快研究进度。
智能体 RL 基础设施的现实挑战
在讨论解决方案之前,让我们明确智能体 RL 本身为何对基础设施提出如此严苛的要求。在标准的智能体 RL 循环中,LLM 策略在 GPU 上生成代码片段等动作,并在隔离的 CPU 沙盒中执行以观察奖励信号。然而,当将这一循环扩展到支持数万个并行 rollout 时,三个关键基础设施瓶颈会浮现:
- 加速器空闲成本,即首次指令延迟(TTFC)和尾部延迟陷阱:智能体强化学习是一种批量工作负载,在同步强化学习步骤中,必须等待批次中最慢的沙箱就绪后才能继续训练。如果启动CPU沙箱需要数分钟来分配资源、拉取镜像并执行初始启动脚本,那么昂贵的加速器资源将被浪费。
- 巨大的图像基数:标准容器缓存假设只有少量静态基础镜像。然而在智能体强化学习中,每个任务(例如SWE-bench或R2E-Gym中的数千个GitHub仓库)通常需要完全不同的OCI容器镜像。每次运行需要管理数千个独特且体积庞大的镜像,可能导致严重的镜像拉取瓶颈和存储摩擦。
- 控制平面饱和:作为突发性批量工作负载,智能体强化学习通常执行批量大小的镜像任务,并且每个任务需要多次rollouts(例如每个任务4、8、16次rollouts),这将本已庞大的镜像数量推向极限。例如,我们测试的一个公开数据集包含4,578个R2E镜像。假设每个镜像需要4次rollouts,这意味着需要同时处理18,312个任务,需要18,312个沙箱。标准Kubernetes控制平面在这些突发负载下会显著降级。每分钟创建数万个临时Pod会导致API服务器队列瓶颈、Pod状态错误并触发虚假的节点健康驱逐。
这些问题并非假设性难题,而是前沿AI实验室训练尖端智能体时每天面临的现实。
为强化学习优化的GKE Agent Sandbox
为了扩展代码执行沙箱,我们搭建了一个规模相对适中的集群——包含10个节点的gVisor沙箱池,启用了GKE镜像流功能,部署了Agent Sandbox控制器,并在集群内安装了SDK驱动程序以声明预热Pod。我们测试了多种策略和配置,包括大量镜像和高基数场景。
#### 基础设施层
GKE Agent Sandbox是用于安全执行智能体的开源Kubernetes原语,内置SandboxWarmPool功能,通过维护预初始化的健康环境来消除冷启动开销。通过将SandboxWarmPool与GKE镜像流集成,我们有效支持了需要高镜像基数的强化学习和评估工作负载——即使处理数千个大体积镜像(>1.2GB),也能实现智能体训练所需的极低首次指令延迟(TTFC)。其快照、挂起和恢复功能支持错误恢复的检查点机制,沙箱分叉功能支持并行智能体分支逻辑以探索多条路径。
这个GKE原语目前已在前沿AI实验室Mistral AI的智能体强化学习训练基础设施中投入使用:
“要突破强化学习的边界,需要能够即时扩展以应对不可预测需求的基础设施。通过利用GKE高性能的Agent Sandbox强化学习方案,我们能够跨集群无缝编排数十万个安全环境,并在单个集群中处理超过30,000个沙箱的突发流量。它为我们加速模型训练和迭代周期提供了可靠的底层支撑。” —— Mistral AI研究工程师Jean-Malo Delignon
#### 编排SDK与强化学习工具集成
为了帮助研究人员在不编写 Kubernetes YAML 或将自定义守护进程嵌入容器镜像的情况下利用这种能力,我们开发了 Agent Sandbox RL 编排 SDK。它提供了一个简洁的异步 Python API,并支持可插拔的预热池策略,这些策略针对您的特定评估或 RL 训练模式进行了定制。我们还为 Gymnasium、NVIDIA NeMo Gym 和 OpenHands 等 RL 工具构建了原生集成,未来还将支持更多工具。
基准测试:减少空闲加速器浪费
我们在 10 节点的 gVisor 沙箱池上运行了两个工作负载:一个包含 500 张图像的 SWE-bench 环境,以及一个更严苛的 4,578 张图像的 R2E 语料库,该语料库无法装入本地磁盘。
- TTFC 和尾部延迟:快 10 倍至 45 倍
核心指标
为什么重要
原始 Kubernetes 容器基线
GKE Agent Sandbox SDK
基准提升
TTFC(平均)
决定 GPU 空闲时间
44 秒 – 85 秒(平均)
1.1 秒 – 8.8 秒(平均)
快 10 倍
尾部延迟 — 最大 TTFC(最坏情况)
批量处理的瓶颈
7.5 分钟(450 秒)
严格低于 10 秒
快 45 倍
并发量从 500 个同时任务和沙箱扩展到 18,312 个(4,578 个 R2E 图像 × 4 次 rollout)。所有配置下的性能提升保持一致。
我们如何实现这一点。我们对控制器、SDK 和 RL 队列进行了监控,然后在固定的 10 节点预算下运行了数百次对比测试。两个关键改进带来了几乎所有的性能提升:
- 镜像水合操作从关键路径中移除。对于远超本地磁盘容量的高基数语料库,在训练过程中拉取冷镜像会导致 I/O 竞争和多分钟级的尾部延迟。SDK 在节点间规划镜像分布,GKE 镜像流加前置预热池处理其余部分 —— 水合操作在 rollout 要求之前就已完成。
- 控制平面进行了速率控制。高并发 rollout 会触发 API 服务器的惊群效应。Agent Sandbox Controller v1.0.0 添加了速率控制机制,限制预热池的填充速度,使 etcd 和 API 服务器在突发流量下保持稳定。
这些调优参数、基准测试框架和负载测试都包含在 agent-sandbox-rl 示例中,该示例会生成可读性良好的文本和 JSON 报告,方便您在自己的集群上复现对比测试。
- 多轨迹 rollout 期间控制平面和 Pod 生命周期的变更减少 3 倍
控制平面变更(4,578 张图像 × 4 次 rollout 运行)
控制平面饱和度
18,312
5,869
减少 3.1 倍变更
原始 Kubernetes 会在每个轨迹步骤中重新创建 Pod。在 18,312 个任务中,这会增加调度开销、浪费磁盘 I/O —— 在我们的大规模测试中还触发了无限制的垃圾回收循环。SDK 的原地重用策略则保持 Pod 持续运行,在 rollout 集之间执行 Pod 内的 git 重置和仓库检出。Pod 创建次数减少 3.1 倍,控制平面在突发流量下保持平稳。
权衡
提前预热环境会消耗廉价的 CPU 和后台集群资源,使镜像流和就绪检查永远不会成为关键路径。对于 RL 队列来说这是一个直接的权衡:加速器空闲时间是昂贵的资源,而这种方法可以完全消除它。
在训练规模上需要注意的一个细节:SDK 会将每个失败的沙箱计数并以可重试的方式呈现,而不是静默丢弃。未追踪的丢弃不仅仅是损失 rollout —— 这会导致奖励偏差。
入门
- 今日构建:探索 Agent Sandbox 仓库或 Agent Sandbox RL 仓库,获取 Python SDK 及与 Gymnasium、NVIDIA NeMo Gym 和 OpenHands 等强化学习工具的原生集成。
- 进一步提升加速器利用率:查阅 llm-d 协作式时间切片仓库及其快照代理指南,通过动态交错方式将独立的强化学习任务部署到共享物理硬件上。
- 了解更多:阅读官方文档,了解如何通过 GKE Agent Sandbox 部署安全执行环境。
发布分类
- Containers & Kubernetes
- GKE
- AI infrastructure