Miles 训练 SWE 智能体：MI355X 上跑通全异步 RL
AMD 与 Miles 团队在 AMD Instinct MI355X 上，用 Miles、SGLang、Megatron-LM 和 Harbor 对 Qwen3-30B-A3B-Instruct 进行全异步 agentic RL 训练，将 SWE-bench Verified 子集 pass@1 从 7.3% 提升至
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，sandbox 交给 Harbor 管；训练节点跑 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 轮。
| 项目 | 设置 |
|---|---|
| 模型 | Qwen3-30B-A3B-Instruct |
| 硬件 | AMD Instinct MI355X，每张 GPU 288 GB HBM3E；常规配置为 1 个推理节点和 1 个训练节点，每个节点 8 张 GPU；最大 E2B 实验扩展到 4 个节点 |
| 软件 | Miles、SGLang、Megatron-LM、Harbor、ROCm 7.2，打包在同一 container 中 |
| Agent | mini-swe-agent，每条 trajectory 使用一个 sandbox，可选 local Docker 或 E2B microVMs |
| SFT 数据 | 约 4,000 条 Open-SWE-Traces 公共 agent traces |
| RL 数据 | 约 1,350 个 SWE-smith 任务，来自 47 个不在 SWE-bench Verified 中的仓库 |
| 评测 | SWE-bench Verified，100 题分层样本，每题 4 次尝试，指标为 pass@1 |
时间都花在哪里了
团队给训练流水线做了 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 已经完成之后。
团队观察到，两个任务各 8 次尝试的耗时分布极不均匀，最慢的那次 AnyIO 尝试用了 28.8 分钟，见图 5。
针对长尾，团队试过多种缓解办法，最后发现收益最大的就两条：全异步训练，加上更紧的长度上限。在同一个 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 对应这组数字：基础模型 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 与数据移动这几方面的经验，或许比单纯扩算力更管用。
