让 Token 持续流动：来自 16 个开源 RL 库的经验教训
TL;DR – Hugging Face 调查了 16 个开源强化学习（RL）库，发现所有成功的异步 RL 系统都将推理和训练分离到不同的 GPU 池，使用 rollout 缓冲区，并以异步方式推送模型权重；Ray 是主导的编排框架，NCCL 广播是常用的权重同步方式，而对 LoRA 和 Mixture‑of‑Experts（MoE）训练的支持仍然稀缺。
1. 为什么异步 RL 很重要
异步 RL 消除了同步训练大语言模型（LLM）时产生的生成瓶颈，这种瓶颈会导致高达 60 % 的实际时间 GPU 处于空闲状态。 在同步流水线中，对 32‑B 参数模型进行一次 32 K‑token rollout 的批次可能需要数小时，而用于梯度更新的 GPU 则闲置。通过将推理和训练拆分到不同的 GPU 池，并用 rollout 缓冲区连接，两者可以并行进行：生成继续进行，而训练器消费之前生成的数据，从而显著提升 GPU 利用率。
2. 调查概览
Hugging Face 检视了 十六 个开源异步 RL 库（AReaL、ART、Atropos、MILES、NeMo‑RL、OAT、open‑instruct、PipelineRL、PRIME‑RL、ROLL、SkyRL、SLIME、TorchForge、Tunix、verl、verifiers‑rl）。每个库在 七个正交维度 上进行评估：
- 编排与并发原语 – 分布式组件如何协同。
- Rollout 缓冲区设计 – 将生成样本从推理传递到训练的数据结构。
- 权重同步协议 – 更新后的参数如何推送到推理池。
- 陈旧度管理 – 处理离策略 rollout 的策略。
- 部分 rollout 处理 – 当权重变化时，正在进行的生成会怎样。
- LoRA 训练支持 – 训练仅适配器参数并高效同步的能力。
- 分布式训练后端与并行方式 – 并行策略（FSDP、Megatron、DeepSpeed、JAX 等）以及对 Mixture‑of‑Experts 的支持。
完整的对比表见原博客；以下章节概述每个维度的关键发现。
3. 编排与并发原语
| 编排类型 | 含义 | 使用该方式的库 |
|---|---|---|
| 分布式 Actor 模型（Ray） | 带异步 RPC、对象存储和内置容错的有状态 Actor。 | AReaL、verl、SkyRL、NeMo‑RL、SLIME、MILES、ROLL、OAT、open‑instruct 等 |
| 原生 Python 并发 | 线程、asyncio、multiprocessing；无外部运行时。 |
verifiers‑rl、PipelineRL（池内）、ART、AReaL（基于 asyncio） |
| Pub/Sub 消息总线 | 通过 Redis 流或追加文件实现的解耦生产者/消费者。 | PipelineRL（池间）、SLIME（异步模式） |
| HTTP 微服务 | 通过 REST 进行通信的独立服务。 | Atropos |
发现：Ray 在生态中占据主导，出现在 8/16 库中。其 Actor 模型契合 RL 中推理服务器、训练器、奖励模型、环境池等异构组件，提供自动调度、容错以及通过 Ray 对象存储实现的零拷贝数据传输。但 Ray 引入了较重的运行时，这促使在小规模部署时考虑更轻量的方案（原生 Python、Pub/Sub）。
4. Rollout 缓冲区设计
| 缓冲区模式 | 深度（最大在飞批次数） | 库 | 备注 |
|---|---|---|---|
| 无缓冲区（同步） | 0 | TRL（当前），ART（收集完再训练） | 生成与训练交替进行；陈旧度最大但无重叠。 |
| 双缓冲区 | 1 | verifiers‑rl、SLIME（异步模式）、MILES、OAT | 正好一个生成批次与一个训练步骤重叠；陈旧度最小。 |
| 有界异步队列 | 2–K | SkyRL、verl、NeMo‑RL、ROLL、PRIME‑RL、TorchForge、Tunix、open‑instruct、AReaL | 多个批次在飞；陈旧度受队列容量限制。 |
| 无界 / 流式 | 无限 | PipelineRL（Redis 流），SLIME（全异步），Atropos | 持续生成；必须通过版本标签或重要性采样控制陈旧度。 |
更深的队列提升吞吐量，但需要显式的陈旧度管理（见第 4 维度）。
5. 权重同步协议（第 3 维度）
协议决定 延迟 与 中断粒度，即从训练器向推理池推送新权重时的行为。
5.1 传输机制
| 机制 | 典型延迟 | 库 |
|---|---|---|
| NCCL 广播 | 100–500 ms | 大多数库（PipelineRL、SkyRL、SLIME、MILES、ROLL、OAT、NeMo‑RL、PRIME‑RL、open‑instruct、AReaL） |
| NCCL + 分桶 | ~20 ms | verl |
| 共享内存 / CUDA IPC | 极低 | NeMo‑RL、MILES |
| 文件系统 + HTTP | 中等（秒级） | PRIME‑RL、AReaL、ART |
| HTTP PUT | 高（秒级） | verifiers‑rl |
| JAX cross‑mesh | 低 | Tunix |
5.2 中断粒度
| 粒度 | 行为 | 库 |
|---|---|---|
| 永不停止（逐 token 替换） | 在前向传播之间交换权重，生成过程永不中止。 | PipelineRL、open‑instruct（可选） |
| 按 HTTP 请求中止 | 正在进行的 HTTP 调用被取消并使用前缀重试。 | SkyRL、SLIME |
| 软暂停（排空在飞） | 新请求被阻塞，已有生成完成后才同步。 | PRIME‑RL、AReaL、open‑instruct（默认）、verl（异步） |
| 按批次/阻塞 | 生成与训练交替进行；同步会阻塞双方。 | NeMo‑RL、ROLL、OAT、TorchForge、Tunix、verifiers‑rl、Atropos |
发现：只有 PipelineRL 实现了真正的 永不停止 权重更新，在 token 级前向之间切换参数。其他库均在更粗的边界暂停，导致短暂的推理使用陈旧权重。
6. 陈旧度管理（第 4 维度）
当生成与训练重叠时，rollout 会变为离策略。库采用三种正交策略：
- 按样本版本拒绝 – 丢弃
model_version超过可配置滞后阈值的样本。 - 深度限制 – 限制在飞批次数，从结构上保证最大版本差。
- 重要性采样（IS）校正 – 用比例 (\frac{\pi_{\theta}(a|s)}{\pi_{\text{old}}(a|s)}) 对陈旧样本重新加权，通常会裁剪。
| 库 | 版本拒绝 | 深度限制 | IS 校正 |
|---|---|---|---|
| AReaL | ❌ | ✅ | ⚠️（可选） |
| ART | —（同步） | — | — |
| Atropos | ❌ | ✅ | ❌ |
| MILES | ❌ | ❌ | ✅ |
| NeMo‑RL | ✅ | ❌ | ❌ |
| OAT | ❌ | ❌ | ✅ |
| open‑instruct | ❌ | ✅ | ⚠️（可选） |
| PipelineRL | ✅ | ❌ | ❌ |
| PRIME‑RL | ✅ | ✅ | ✅ |
| ROLL | ❌ | ❌ | ✅ |
| SkyRL | ❌ | ✅ | ❌ |
| SLIME | ❌ | ❌ | ✅ |
| TorchForge | ✅ | ❌ | ❌ |
| Tunix | ❌ | ✅ | ❌ |
| verl | ❌ | ❌ | ✅ |
| verifiers‑rl | ❌ | ✅ | ❌ |
混合方案（如 PRIME‑RL、open‑instruct）将深度限制与可选 IS 加权结合，保持流水线简洁的同时提升鲁棒性。
7. 部分 Rollout 处理（第 5 维度）
长上下文 rollout（数万 token）在权重更新到来时可能仍在生成中。常见策略包括：
| 策略 | 库 | 描述 |
|---|---|---|
| 隐式继续 | PipelineRL | 不中断；权重在 token 前向之间交换。 |
| 中止并使用前缀重试 | SkyRL、SLIME | 在飞生成被取消，保留的前缀在新策略下重新提交。 |
| 显式保存/恢复 | verl（全异步） | 保存部分 token ID 与 KV 缓存，同步后从保存状态继续生成。 |
| 批次取消 | PRIME‑RL | 丢弃陈旧 rollout 组；新权重同步在 HTTP 请求之间进行。 |
| 软暂停（排空） | AReaL | 新任务停止，已有任务完成后才同步。 |
| 不支持 | verifiers‑rl、OAT、Atropos、Tunix | 仅在所有在飞生成结束后才同步。 |
只有 PipelineRL 与 verl 提供了真正的 永不停止 行为；其余库依赖中止或排空机制。
8. LoRA 训练支持（第 6 维度）
LoRA 大幅减少可训练参数，使得 仅适配器权重同步 成为可能，只广播小的适配器增量即可，将 7 B+ 模型的 NCCL 传输时间从数百毫秒降至亚毫秒。
| 库 | 支持 LoRA? | 后端 | 仅适配器同步 |
|---|---|---|---|
| AReaL | ✅ | HF peft（FSDP2/Megatron） |
✅ |
| ART | ✅ | Unsloth / Megatron | ✅ |
| Atropos | ✅ | HF peft |
✅ |
| MILES | ✅ | Megatron‑Bridge | ✅ |
| NeMo‑RL | ✅（自定义） | DTensor / Megatron | ❌（暂无证据） |
| OAT | ✅ | HF peft |
✅ |
| open‑instruct | ❌（代码存在但未接通） | — | ❌ |
| PipelineRL | ✅ | HF peft |
❌（全量广播） |
| PRIME‑RL | ✅ | Custom MultiLoRA | ✅ |
| ROLL | ✅（仅 DeepSpeed） | DeepSpeed | ❌ |
| SkyRL | ✅ | HF peft / Megatron‑Bridge |
✅ |
| SLIME | ❌ | — | ❌ |
| TorchForge | ❌ | — | ❌ |
| Tunix | ✅ | qwix（JAX） | ✅ |
| verl | ✅ | HF peft / Megatron‑Bridge |
✅ |
| verifiers‑rl | ✅ | HF peft + FSDP2 |
✅ |
LoRA‑仅同步显著放宽了中断模型：即使库在请求层面中止，也能因数据传输极小而实现频繁权重更新。
9. 分布式训练后端与并行方式（第 7 维度）
训练后端决定模型规模上限、集合通信模式以及对 MoE 的兼容性。
| 库 | 后端 | 并行方式（DP/TP/PP/EP） | MoE 支持 |
|---|---|---|---|
| AReaL | FSDP2、Megatron、Archon | DP、SP、TP、PP、CP、EP | ✅ |
| ART | Unsloth、Megatron | DP、TP、EP | ✅ |
| Atropos | PyTorch native、TRL | DP | ❌ |
| MILES | Megatron、FSDP2 | DP、TP、PP | ✅ |
| NeMo‑RL | DTensor、Megatron | DP、SP、TP、PP、CP、EP | ✅ |
| OAT | DeepSpeed | DP、TP | ❌ |
| open‑instruct | DeepSpeed | DP、SP | ❌ |
| PipelineRL | DeepSpeed | DP、SP | ❌ |
| PRIME‑RL | FSDP2 | DP、TP、CP、EP | ✅ |
| ROLL | DeepSpeed、Megatron、FSDP2 | DP、SP、TP、PP、CP、EP | ✅ |
| SkyRL | FSDP、Megatron‑Bridge | DP、SP、TP、PP、EP | ✅ |
| SLIME | Megatron | DP、TP、PP、SP | ✅ |
| TorchForge | FSDP2（Monarch） | DP、TP、CP | ❌ |
| Tunix | JAX/XLA | DP、TP | ❌ |
| verl | FSDP、Megatron | DP、SP、TP、PP、CP、EP | ✅ |
| verifiers‑rl | DeepSpeed | DP | ❌ |
关键含义：MoE 训练（专家并行）仅在基于 Megatron 或 FSDP2 并显式处理 EP 的库中得到支持（AReaL、verl、PRIME‑RL、SkyRL、ROLL、NeMo‑RL）。仅使用 ZeRO（DeepSpeed、纯 FSDP） 的库虽能加载 MoE 检查点，但因所有专家都被切分到每个 rank，失去了稀疏优势。
10. 新兴设计压力
10.1 无评估器算法
去除价值网络（如 GRPO、REINFORCE++）可释放显存，允许更大的 rollout 批次，但也会提升权重更新频率。陈旧度管理变得更关键，因为在更大的组规模（G = 8‑32）下策略漂移加速。因而需要每样本版本标记和 IS 校正来保证训练稳定。
10.2 过程奖励
对中间推理步骤进行打分（过程奖励模型）在生成与训练之间加入了非平凡的计算阶段。异步流水线必须加入 reward‑actor 与训练器并行运行，正如 PRIME‑RL 与 NeMo‑RL 所做的那样。否则奖励计算会成为新的瓶颈。
10.3 多智能体协同进化
多智能体自我对弈会放大拖尾问题：有效 rollout 长度等于每个智能体长度的乘积，导致方差急剧上升。缓冲区设计必须把整个多智能体回合视为单一原子单元，陈旧度策略也需基于每回合版本追踪，而非单样本。
10.4 MoE 的训练‑推理不匹配
在 DeepSeek‑v3.2 中发现两类结构性不匹配：
- 专家路由不一致 – 推理与训练可能因浮点差异为同一 token 选取不同专家。解决方案（“Keep Routing”）要求推理服务器返回路由决策，训练端强制使用相同路由。
- 采样掩码不匹配 – 生成时的 top‑p/top‑k 截断导致动作空间与完整词表的训练前向不同。 “Keep Sampling Mask” 记录截断掩码并在训练时重新应用。 目前调研的库均未实现上述功能，凸显了未来异步 RL 系统的潜在空白。
10.5 蒸馏作为异步 RL
On‑policy 蒸馏（学生生成，教师打分）遵循与 RL 完全相同的异步模式：生成 → 打分 → 梯度更新 → 权重同步。因此所有设计维度保持不变。一个通用的异步训练器应将打分步骤抽象为可插拔组件，而非硬编码的 verifier，从而同时支持 RL 与蒸馏工作负载。
11. TRL 异步训练器的设计选择
基于本次调研，TRL 团队计划在即将推出的异步训练器中作出以下具体决策：
- 轻量编排 – 在可能的情况下避免使用重量级运行时；采用原生 Python
asyncio配合最小化的 Actor 抽象。 - 有界队列 + 每 token
model_version– 每个 token 附带生成时的策略版本，实现细粒度 IS 校正，免去后期补丁。 - 带分桶的 NCCL 权重同步 – 利用 vLLM 的
NCCLWeightTransferEngine进行打包广播，约 20 ms 即可完成一次同步，大幅降低延迟。 - 部分 rollout 支持 – 实现前缀恢复机制，针对具备代理特性的工作负载，在权重更新后让在飞生成在新策略下继续。
这些选择旨在融合生态最佳实践，同时保持实现对更广泛的 TRL 社区友好。
结论：异步 RL 训练已成为大规模 LLM 后训练的事实标准。调研显示，业界已在推理‑训练分离、使用 rollout 缓冲区以及异步权重推送上形成共识，Ray 是最常见的编排层，NCCL 广播是默认的同步方式。未来工作需进一步解决 LoRA‑仅同步、MoE 路由一致性以及多智能体回合处理，以跟上下一代前沿模型的步伐。
Sources
相关
- Dispatch
- 项目
- Dispatch
- 项目