‹ 返回博客本页内容

我们使用 Miles、SGLang、Megatron-LM 和 Harbor，在 AMD Instinct MI355X 上以全异步智能体强化学习训练了 Qwen3-30B-A3B-Instruct，使其在 SWE-bench Verified 的 100 任务分层子集上的 pass@1 分数几乎翻了两番，从 7.3% 提升到 27.5%。最大的瓶颈是长尾轨迹、CPU 沙箱和数据移动。我们分享了如何应对这些挑战以提升吞吐量并加速学习，其中的经验也适用于 DeepSeek-V4-Flash、GLM-5.3 和 Kimi K3 等更大的模型。

摘要

  • SWE-bench Verified 子集 pass@1：7.3% → 27.5%。 Qwen3-30B-A3B-Instruct，在 SFT 和智能体强化学习之后，于 100 个分层任务上评估，每个任务尝试 4 次。
  • rollout 吞吐量约提升 4 倍：约 860 → 约 3,480 条轨迹/小时。 模型和 RL 配方保持不变；推理从 1 个扩展到 3 个 8 卡 MI355X 节点，并配合云沙箱和并发修复。
  • RL 单步速度约提升 3 倍：850 秒 → 284 秒。 在同一 8 卡推理节点上限制轨迹长度可减少长尾。
  • 384 个并发智能体沙箱。 最大规模的运行使用三个推理节点和一个训练节点，每个节点配备 8 块 MI355X。

背景

为什么智能体强化学习与众不同

在编码智能体强化学习中，一个训练样本就是一整个回合。模型阅读 GitHub issue，在沙箱中运行 20 到 100 多条 shell 命令，编辑代码，并且只有在仓库测试通过时才能获得奖励。

Agentic RL loop: SGLang generates actions, a CPU sandbox executes and grades them, and Megatron-LM trains on the resulting trajectories.

图 1： 智能体强化学习循环。一个训练样本就是一整个多轮回合。

与单轮强化学习相比，这种工作负载带来了新的问题：

  • 长尾拖后腿者。 同一任务的两次尝试长度可能相差 2.5 倍，而 GRPO 组必须等到最慢的尝试完成才能评分，因此少数拖后腿者就可能拖住训练。

  • 处于关键路径上的 CPU 集群。 每条轨迹都需要自己的沙箱来构建和测试代码。

架构

推理和训练运行在独立的节点上。推理节点运行八个单 GPU 的 SGLang 引擎和 Harbor，后者负责管理沙箱。训练节点运行 Megatron-LM，并将新权重推回给各引擎。训练是完全异步的，使 rollout 和训练可以重叠。训练器在获得足够多的已完成轨迹后即继续推进，而不是等待最慢的那些，从而减少空闲时间并提高整体吞吐量。

Separate inference and training nodes, each with eight MI355X GPUs, connected through Miles and Harbor.

图 2： 架构。Harbor 在沙箱中运行每个智能体并调用 SGLang 引擎；Miles 将已完成的轨迹分批交给 Megatron，后者再将新权重发回。

技术栈

每一层都是开源的，整个系统以一个 ROCm 容器交付。

Qwen3-30B-A3B and mini-swe-agent on Miles, Megatron-LM, SGLang, Harbor, ROCm 7.2, and AMD Instinct MI355X.

图 3： 软件栈。配方：先在约 4,000 条公开智能体轨迹（Open-SWE-Traces）上做 SFT，再在来自 47 个仓库、未出现在 SWE-bench Verified 中的约 1,350 个 SWE-smith 任务上做 RL。

实验设置

我们从 Qwen3-30B-A3B-Instruct 出发，分两个阶段训练。SFT 在 Open-SWE-Traces 中约 4,000 条成功的智能体轨迹上微调一个 epoch，教会模型工具格式。随后 RL 在约 1,350 个 SWE-smith 任务上运行全异步 GRPO：每个任务尝试 8 次，仓库测试通过时奖励为 1，不使用 KL 惩罚。每条轨迹限制为每轮生成 8,192 个 token、总计 65,536 个 token、最多 80 轮。

项目设置
模型Qwen3-30B-A3B-Instruct
硬件AMD Instinct MI355X，每块 GPU 288 GB HBM3E；一个推理节点和一个训练节点，各 8 块 GPU（最大的 E2B 运行最多使用 4 个节点）
软件Miles（全异步 GRPO）、SGLang、Megatron-LM、Harbor、ROCm 7.2，全部在一个容器中
智能体mini-swe-agent，每条轨迹一个沙箱（本地 Docker 或 E2B microVM）
SFT 数据约 4,000 条公开智能体轨迹（Open-SWE-Traces）
RL 数据来自 47 个仓库、未出现在 SWE-bench Verified 中的约 1,350 个 SWE-smith 任务
评估SWE-bench Verified，100 任务分层样本，每个任务尝试 4 次，pass@1

时间花在哪里

单步时间分解

我们对训练流水线进行了性能分析。图 4 展示了训练器侧的单步分解：actor 更新占所测单步的 63%，等待 rollout 占 29%，对数概率重算占 8%。权重同步单独记录。我们还调查了 rollout 时间，其中 LLM 调用和等待 CPU 沙箱启动是主要瓶颈。

A 208-second average training step: actor update 131 seconds, waiting for rollouts 60 seconds, and log-probability recomputation 16 seconds. Weight sync is logged separately at 23 seconds.

图 4： 我们 384 条轨迹运行中训练器侧的单步分解（16 步的平均值）。所测单步平均为 208 秒；权重同步单独记录。限制：每轮生成 8K token，每条轨迹 64K token，80 轮。

长尾问题

在 GRPO 中，每个组都要等待其最慢的轨迹，而智能体经常耗尽每轮上下文：84% 的轨迹跑到了轮数上限，而成功的运行中位数只需要 8 轮。在长尾期间，引擎以接近 1 的批大小解码少量序列，因此 GPU 大部分时间处于空闲状态。32% 的 rollout 时间发生在 90% 的轨迹已经完成之后。

Eight attempts on each of two tasks show uneven rollout durations; the slowest AnyIO attempt takes 28.8 minutes.

图 5： 长尾：两个任务各尝试 8 次，相同模型，相同批次。最慢的 AnyIO 尝试耗时 28.8 分钟。

我们尝试了多种策略来缓解这个问题。全异步训练加上更严格的长度上限带来了大部分加速：单步速度提升 3 倍，且对成功的运行没有影响。

上下文增长与 KV 缓存

每一轮都会把工具输出加入上下文。按每 token 96 KB 计算，一条 64K token 的轨迹会占用 6.3 GB 的 KV 缓存。在一次运行中，引擎没有上下文上限：有几代生成增长到了 113K–186K token，其中约 10 条就填满了引擎的 1.5M token KV 缓存。该引擎上排队的其他 99 个请求直到超时都没有得到任何 token。在引擎中把上下文限制为 64K 解决了这个问题。凭借 288 GB 的 HBM，一台 MI355X 引擎可以同时容纳数十条 64K token 的轨迹。

CPU 侧：沙箱

沙箱生命周期

每条轨迹都需要自己干净的环境，包含代码仓库、其依赖项和测试。当有数百条轨迹同时运行时，沙箱就成了关键路径上的一支 CPU 集群：当智能体等待一个沙箱时，它的 GPU 槽位就处于空闲状态。

Sandbox lifecycle and scaling limits for local Docker and E2B microVMs.

图 6： 每条轨迹都在 CPU 上运行这个沙箱生命周期。当我们同时运行数百条轨迹时，每个阶段都以某种方式失败过；底行显示了每种沙箱方案的可扩展程度。

384 条并发轨迹下的云沙箱

为了把沙箱从推理节点上移走，我们将其迁移到 E2B 云 microVM（每个 2 vCPU 和 4 GB），并在 4 个节点上同时运行 384 条轨迹（24 个单 GPU 的 SGLang 引擎，每个 16 条轨迹）。在一次运行中途重启后，rollout 吞吐量达到约 3,480 条轨迹/小时，约为本地 Docker 基线的 4 倍。

Cloud trajectory timing and median local Docker versus E2B sandbox startup, installation, and test times.

图 7： 上：在 384 条并发轨迹下，一条 E2B 轨迹的时间去向（对稳态下正常完成的 4,211 条轨迹取均值）。下：沙箱侧各步骤的中位时间，本地 Docker 对比 E2B。本地 Docker 的数据来自同一 RL 配方的一个 278 条轨迹窗口。

  • 沙箱启动不再是成本所在。 云沙箱在 1.9 秒内就绪（中位数，p99 为 3.7 秒），并且在 384 条并发时保持平稳，而本地 Docker 在负载下需要 11.7 秒。

  • 获取或计算的步骤变慢了。 在 2 vCPU 的 microVM 中，安装智能体多花 7.5 秒，运行测试多花 8.5 秒，每次 LLM 调用都要经过一条隧道（约 0.26 秒）。一条轨迹多花 15–40 秒，占其时间的 4–11%。

  • 沙箱侧占轨迹时间的五分之一。 LLM 调用占云轨迹的 77%；测试、工具调用、智能体安装和启动合计占 22%。

  • GPU 还有余量。 在 384 条轨迹时，引擎队列为空，KV 缓存使用率最高为 23%。限制因素是沙箱并发度，而不是 GPU。

  • 可靠性在规模下保持稳定。 在稳态下，2.6% 的轨迹失败，300,500 次经隧道的 LLM 调用中有 0.09% 返回错误。

我们学到了什么

  • 启动成本取决于平台。 在同时启动 3 个沙箱的自托管 E2B 上，等待启动占用了 20% 的轨迹时间；E2B 的云服务在 1.9 秒内启动一个沙箱。在微基准测试中，全新沙箱中的首次调用也比重复调用慢 15 倍，因此热池和快照比额外的核心更重要。

  • 基础设施故障会变成错误的奖励。 3.1% 的轨迹以基础设施错误结束，这种错误和错误的修复一样得 0 分。策略因基础设施而受到惩罚，因此这些故障必须被记录并过滤掉。

  • 最先出问题的是隐藏的上限，而不是网络。 随着我们增加智能体，每一次故障都来自某个固定上限：每台机器最多 31 个 Docker 网络、整个集群每小时 100 次镜像下载、Miles 中 100 个智能体连接，以及一个 CPU 核心处理所有智能体请求。让我们得以扩展的是移除这些上限，而不是增加带宽。

关键修复

起初几乎每个问题看起来都像是 GPU 问题。但几乎都不是。

修复问题效果
限制轨迹长度在长度上限之前，失败的智能体可能循环 200 多轮并拖住整个步骤步骤速度提升 3 倍
移除隐藏的并发上限一个 HTTP 连接池把智能体限制在 100 个；一个代理进程串行化了所有 LLM 调用与推理扩容和云沙箱一起，促成了约 4 倍的 rollout 提升
共享一个沙箱网络Docker 每个节点只允许约 31 个沙箱网络每个节点数百个沙箱
在引擎中限制上下文失控的生成填满了 KV 缓存不再有 KV 抖动
固定 NCCL 接口跨节点权重同步选中了重复的 Docker IP 并挂起可靠的同步
保持 HIP 图开启，并添加看门狗罕见的 GPU 故障；禁用图会使吞吐量减半全速运行，自动恢复

结果

解决率

图 8 追踪了该配方每个阶段在 SWE-bench Verified 上的 pass@1，使用的是 500 个 Verified 任务中 100 个任务的分层子集，每个任务尝试 4 次。基础模型解决了 7.3% 的任务，在约 4,000 条公开智能体轨迹上做 SFT 将其提升到 12.8%。随后智能体 RL 又增加了 14.7 个百分点，达到 27.5%：它使 SFT 分数翻了一倍多，并贡献了总增益的近四分之三。所有 RL 任务都来自未出现在 SWE-bench Verified 中的 SWE-smith 仓库，因此这一增益是在策略在 RL 期间从未见过的代码库上测得的。

SWE-bench Verified subset pass@1 rises from 7.3 percent for the base model to 12.8 percent after SFT and 27.5 percent after agentic RL.

图 8： SWE-bench Verified 解决率（pass@1，100 任务分层样本，每个任务尝试 4 次）：基础模型 7.3%，SFT 后 12.8%，智能体 RL 后 27.5%。

吞吐量

指标之前之后
训练步时间850 秒284 秒
Rollout 吞吐量约 860 条轨迹/小时约 3,480 条轨迹/小时
并发轨迹数~100384
负载下的 LLM 调用延迟12.6 秒4.4 秒

这些测量来自在两到四个 MI355X 节点上的运行，模型和 RL 配方保持不变。约 4 倍的 rollout 吞吐量提升综合了推理从 1 个节点扩展到 3 个 8 卡节点、云沙箱以及移除并发限制。约 3 倍的步时间提升来自在同一个 8 卡推理节点上限制轨迹长度。这些是分别进行的比较，而不是在固定硬件上的一次前后对比运行。

训练稳定性

该运行训练了 145 步，并从检查点经历了三次重启而存活下来。曲线中没有任何漂移或爆炸。

Reward, response length, gradient norm, and trainer versus SGLang log-probability gap across 145 RL steps and three restarts.

图 9： 27.5% 结果背后 RL 运行的训练曲线。红色是在 rollout 上测得的，紫色是在训练器上测得的。灰点表示每批奖励（8 个任务 × 8 次尝试），线是 10 步均值。虚线标记从检查点恢复的位置。梯度范数轴已缩放到其正常范围，因此单个超出量程的步被绘制为标记。

  • 奖励缓慢而稳定地攀升。 10 步均值在训练任务上从 0.13 升至 0.17。单批在 0 到 0.47 之间波动，因为每批都会抽取新任务。

  • 更新幅度保持很小。 梯度范数中位数为 0.07。有一步（第 140 步）达到 0.77，仍低于 1.0 的裁剪阈值，且训练器与推理之间的差距或有效样本量没有变化。下一步又回到 0.09。有八批的梯度为零，因为其中没有任何任务同时包含通过和失败的尝试。

  • 训练器与推理引擎一致。 每 token 对数概率差的均值保持在 0.011 附近，并在整个运行过程中略有下降。重要性权重的有效样本量平均为 93%，因此离策略校正很少需要介入。

  • 无长度漂移。 响应保持在每条轨迹约 30K token，既没有向短答案坍缩，也没有向上下文上限膨胀。

结论

智能体 RL 在 AMD Instinct MI355X 上端到端运行：Qwen3-30B-A3B-Instruct 在 SWE-bench Verified 的 100 任务分层子集上，以稳定的训练将 pass@1 从 7.3% 提升到 27.5%。在模型和 RL 配方保持不变的情况下，将推理从 1 个节点扩展到 3 个节点、使用云沙箱并移除并发限制，带来了约 4 倍的 rollout 吞吐量提升。另外，在同一个 8 卡推理节点上限制轨迹长度，使训练步时间缩短了约 3 倍。

下一步：前沿规模的智能体 RL

  • 更大的前沿模型： 在 DeepSeek-V4-Flash、GLM-5.3 以及其他已在 MI350 系列 GPU 上用 Miles 测试过的模型上运行同一配方。

  • 规模： 超过 384 个并发沙箱，并将推理分散到更多节点。

  • 停止浪费的 rollout： 教会智能体提交，而不是循环到轮次上限。

  • 附加功能： 研究粘性会话和分层 KV 缓存带来的收益。

  • 更多应用： 将研究扩展到其他智能体工作负载。

参考文献