MI355X 上训练 SWE 智能体：Miles 如何驯服长尾轨迹

AMD 与 Miles 团队展示了一套面向软件工程智能体的强化学习训练方案：在 AMD Instinct MI355X 上，结合 Miles、SGLang、Megatron-LM 与 Harbor，对 Qwen3-30B-A3B-Instruct 进行全异步 agentic RL 训练。最终，在 SWE-bench Verified 的 100 题分层子集上，模型 pass@1 从基础模型的 7.3% 提升到 27.5%，接近翻了四倍。

这项工作最核心的经验并不只是“堆 GPU”，而是如何处理智能体训练中特有的系统瓶颈：长尾轨迹、CPU sandbox、KV cache 爆炸以及训练与推理之间的数据移动。团队认为，这些经验同样适用于更大的模型，例如 DeepSeek-V4-Flash、GLM-5.3 和 Kimi K3。

核心结果

• SWE-bench Verified 子集 pass@1：7.3% → 27.5%。评测采用 100 个分层抽样任务，每个任务 4 次尝试，模型经过 SFT 与 agentic RL。
• rollout 吞吐接近 4 倍提升：约 860 → 3,480 trajectories/hour。在模型和 RL 配方不变的情况下，推理侧从 1 个 8-GPU MI355X 节点扩展到 3 个节点，并引入云端 sandbox 与并发修复。
• RL step 约 3 倍加速：850 秒 → 284 秒。在同一 8-GPU 推理节点上，通过限制 trajectory 长度显著压缩长尾。
• 最大规模运行达到 384 个并发 agent sandbox。该实验使用 3 个推理节点和 1 个训练节点，每个节点均配备 8 张 MI355X。

为什么 coding agentic RL 更难

在软件工程场景中，一个训练样本不是单轮问答，而是一整段多轮 episode。模型需要读取 GitHub issue，在 sandbox 中执行 20 到 100 多条 shell 命令，修改代码，最后只有当仓库测试通过时才获得奖励。这意味着训练样本的长度、耗时和资源消耗高度不均匀。

图 1：agentic RL 循环。SGLang 生成动作，CPU sandbox 执行并评分，Megatron-LM 使用得到的 trajectories 进行训练。

相比单轮 RL，这类负载带来三个新问题。第一是 long-tail stragglers：同一任务的不同尝试耗时可能相差 2.5 倍，而 GRPO group 必须等最慢的 trajectory 完成后才能打分。第二是 CPU fleet 进入关键路径：每条 trajectory 都需要一个隔离环境来构建和测试代码。第三是上下文不断增长，tool output 会不断写入上下文，进一步放大 KV cache 压力。

系统架构：训练与推理解耦

该系统将推理和训练部署在不同节点上。推理节点运行 8 个单 GPU SGLang engine，并由 Harbor 管理 sandbox；训练节点运行 Megatron-LM，并将新权重回传给推理 engine。整个训练是全异步的：rollout 与训练可以重叠执行，trainer 不必等待最慢的样本，而是在完成的 trajectories 足够时继续推进，从而减少空转。

图 2：架构示意。推理节点与训练节点各有 8 张 MI355X，通过 Miles 和 Harbor 协同。

软件栈全部基于开源组件，并以一个 ROCm container 交付。训练配方分为两步：先在约 4,000 条 Open-SWE-Traces 公共成功 agent traces 上进行 SFT，让模型掌握工具调用格式；随后在约 1,350 个 SWE-smith 任务上进行 RL，这些任务来自 47 个未出现在 SWE-bench Verified 中的仓库。

图 3：软件栈包括 Qwen3-30B-A3B、mini-swe-agent、Miles、Megatron-LM、SGLang、Harbor、ROCm 7.2 与 AMD Instinct MI355X。

实验设置

实验从 Qwen3-30B-A3B-Instruct 出发，先进行 1 个 epoch 的 SFT，再使用全异步 GRPO 做 RL。RL 阶段每个任务采样 8 次；当仓库测试通过时 reward 为 1，否则为 0；训练中不使用 KL penalty。每条 trajectory 的限制为：每轮最多生成 8,192 tokens，总计最多 65,536 tokens，最多 80 轮。

时间都花在哪里了

团队对训练流水线进行了 profiling。trainer 侧的 step breakdown 显示，在一次 384-trajectory 运行中，平均 measured step 为 208 秒：actor update 占 131 秒，约 63%；等待 rollout 占 60 秒，约 29%；log-probability recomputation 占 16 秒，约 8%。权重同步单独记录，约 23 秒。

图 4：384-trajectory 运行中的 trainer-side step breakdown。平均 step 为 208 秒，权重同步另计。

长尾 trajectory 是最大敌人

在 GRPO 中，一个 group 必须等待最慢的 trajectory 完成。问题是 agent 很容易耗尽 per-turn context 或触及 turn cap：实验中 84% 的 trajectories 运行到了 turn cap，而成功样本的中位数只需要 8 轮。进入长尾阶段后，SGLang engine 往往只剩少数序列在 decode，batch size 接近 1，GPU 利用率明显下降。团队观察到，32% 的 rollout 时间发生在 90% trajectories 已经完成之后。

图 5：两个任务各 8 次尝试的耗时分布非常不均匀，其中最慢的 AnyIO 尝试耗时 28.8 分钟。

团队尝试了多种缓解方法，最终发现收益最大的是两点：全异步训练，以及更紧的长度上限。在同一 8-GPU 推理节点上，仅通过限制 trajectory 长度，就能将 RL step 从 850 秒压缩到 284 秒，约 3 倍加速，而且不会影响成功样本。

上下文增长与 KV cache

每一轮工具输出都会追加到上下文中。按每 token 约 96 KB 计算，一条 64K-token trajectory 需要约 6.3 GB KV cache。在一次未设置 context cap 的运行中，少数生成增长到 113K–186K tokens，约 10 个请求就填满了 engine 的 1.5M-token KV cache，导致同一 engine 上其他 99 个请求无法获得 token，直到超时。团队随后在 engine 侧将 context cap 设为 64K，解决了这一问题。得益于 MI355X 每卡 288 GB HBM，一台 MI355X engine 可以同时容纳数十条 64K-token trajectories。

CPU 侧瓶颈：sandbox

每条 trajectory 都需要一个干净环境：拉取仓库、安装依赖、运行测试。随着并发数上升，sandbox 不再是外围组件，而是进入训练关键路径的 CPU fleet。agent 等待 sandbox 时，对应 GPU slot 也会闲置。

图 6：sandbox 生命周期与扩展限制。并发达到数百时，每个阶段都可能成为瓶颈。

将 sandbox 迁移到 E2B microVMs

为了把 sandbox 压力从推理节点上移走，团队使用 E2B cloud microVMs，每个 microVM 配置 2 vCPUs 与 4 GB 内存。最大实验在 4 个节点上同时运行 384 条 trajectories：24 个单 GPU SGLang engines，每个 engine 处理 16 条 trajectories。经历一次中途重启后，rollout 吞吐达到约 3,480 trajectories/hour，约为 local Docker baseline 的 4 倍。

图 7：云端 trajectory 的时间构成，以及 local Docker 与 E2B 在启动、安装和测试阶段的中位耗时对比。

• sandbox 启动不再是主要成本。E2B cloud sandbox 的 ready 中位时间为 1.9 秒，p99 为 3.7 秒，并且在 384 并发下保持稳定；local Docker 在高负载下则约为 11.7 秒。
• 涉及拉取或计算的步骤会变慢。在 2-vCPU microVM 中，安装 agent 多花约 7.5 秒，运行测试多花约 8.5 秒；每次 LLM call 还要穿过 tunnel，约增加 0.26 秒。因此单条 trajectory 会增加 15–40 秒，约占总时长的 4%–11%。
• sandbox 侧约占 trajectory 的五分之一。在云端运行中，LLM calls 占 trajectory 时间的 77%；测试、工具调用、agent 安装等 sandbox 侧操作合计约占剩余部分。

模型效果：SFT 有帮助，agentic RL 才是关键跃升

最终评测显示，基础模型在 SWE-bench Verified 100 题分层子集上的 pass@1 为 7.3%；经过 SFT 后提升至 12.8%；再经过 agentic RL 后达到 27.5%。这说明 SFT 主要帮助模型学会工具格式与基本流程，而真正让模型在软件工程任务中显著进步的，是多轮交互环境下的强化学习。

图 8：SWE-bench Verified 子集 pass@1 从基础模型的 7.3% 提升到 SFT 后的 12.8%，并在 agentic RL 后达到 27.5%。

训练过程中，团队持续追踪 reward、response length、gradient norm，以及 trainer 与 SGLang 之间的 log-probability gap。145 个 RL steps 和 3 次 restart 的曲线显示，系统虽然需要应对异步训练、权重同步和 rollout 长尾带来的复杂性，但整体学习趋势仍然能够推进。

图 9：145 个 RL steps 与 3 次 restart 中的 reward、response length、gradient norm 及 log-probability gap。

结论：agentic RL 的瓶颈是系统工程

这项实验表明，训练软件工程智能体并不只是扩大模型或增加 GPU。真正决定吞吐和学习速度的，是一整套系统协同：如何让 trainer 不被最慢 trajectory 拖住，如何让 SGLang engine 避免 KV cache 被少数异常请求占满，如何把 sandbox 从 GPU 节点的关键路径中拆出去，以及如何在 Miles、Harbor、SGLang 与 Megatron-LM 之间保持高效的数据与权重流动。

在 MI355X 上，团队通过全异步 GRPO、trajectory length cap、cloud sandbox 扩展和多节点推理，将 Qwen3-30B-A3B-Instruct 的 SWE-bench Verified 子集 pass@1 提升到 27.5%。对于未来更大规模的代码智能体训练，这些关于长尾、sandbox 与数据移动的经验，可能比单纯的算力扩展更重要。