[Infra-12] RL Infra：支撑大模型强化学习后训练的分布式工厂

谈到大模型强化学习，最先出现的通常是 PPO、GRPO、DAPO 等算法名词。算法告诉我们如何计算 advantage、policy loss 和 KL，但它并没有回答另一组同样关键的问题：几千个 Prompt 由谁生成回答，代码和 Agent 轨迹在哪里执行，奖励如何并行计算，训练后的几百 GB 权重怎样交给生成引擎，以及整个过程怎样在多机集群上持续运行。

这些问题共同构成了 RL Infra（Reinforcement Learning Infrastructure）：支撑大模型强化学习后训练的整套系统基础设施。

Prompt / Environment
        |
        v
Policy generates Rollout
        |
        v
Reward Model / Verifier / Environment Reward
        |
        v
Reward / Advantage / LogProb / KL
        |
        v
Train and update Policy
        |
        v
Synchronize new weights to Rollout Engine
        |
        +------------------------------> next Rollout

可以先用一个工厂类比建立直觉：

• PPO、GRPO 是工厂遵循的算法公式；
• RL Infra 是让公式能够大规模运行的分布式工厂；
• vLLM、SGLang 是其中负责生成训练样本的 rollout 车间。

因此，在推理 Infra 中，vLLM 可以是一套完整服务；在 RL Infra 中，它只是闭环中的一个子系统。RL 系统真正优化的是 rollout、奖励、训练、环境和权重同步共同决定的端到端效率。

1. RL Infra 的系统边界#

普通训练的主循环相对稳定：

Load Batch -> Forward -> Backward -> Optimizer Step

普通推理则围绕请求运行：

Receive Request -> Prefill -> Decode -> Return

RL 把训练和推理嵌进了同一个不断反馈的闭环：

Inference
   -> Environment
   -> Reward
   -> Training
   -> Weight Sync
   -> Inference again

这里的输入不再是一批固定训练数据，而是当前策略与任务环境共同产生的在线数据；模型权重也不再长期静止，而是每个或若干训练 step 就会更新。一次 rollout 的输出不是直接交付给用户，而是变成带有 reward、logprob、advantage 和策略版本的 trajectory，再回流到训练端。

所以 RL Infra 的边界通常至少覆盖六个模块：

                         +--------------------+
Prompts / Tasks -------->| Rollout Engine     |
                         +---------+----------+
                                   |
                                   v
                         +--------------------+
                         | Agent Environment  |
                         +---------+----------+
                                   |
                                   v
                         +--------------------+
                         | Reward / Verifier  |
                         +---------+----------+
                                   |
                                   v
                         +--------------------+
                         | Experience Buffer  |
                         +---------+----------+
                                   |
                                   v
                         +--------------------+
                         | Training Engine    |
                         +---------+----------+
                                   |
                                   v
                         +--------------------+
                         | Weight Sync        |
                         +---------+----------+
                                   |
                                   +-------> Rollout Engine

此外，还需要一个跨越所有模块的全局调度与控制层，负责资源 placement、任务编排、版本管理、容错、监控和 checkpoint。

2. Rollout Engine：把推理变成训练数据#

Rollout Engine 使用当前策略模型，根据 Prompt 生成回答或执行 Agent 行为：

prompt -> policy model -> response / trajectory

在 GRPO 中，一个问题通常要采样一组回答，再比较组内相对奖励：

Question
  |-- Response 1
  |-- Response 2
  |-- Response 3
  `-- Response N

这部分本质上仍是大模型推理，因此会复用 vLLM、SGLang、Megatron Inference 或自定义引擎中的大量能力：

• continuous batching 与动态 batching；
• Paged KV Cache、prefix cache 与 chunked prefill；
• Tensor Parallel、Pipeline Parallel 与 Expert Parallel；
• FlashAttention、fused operator、CUDA Graph 和量化；
• speculative decoding 与 prefill/decode 调度。

但 RL rollout 和线上 serving 的目标并不完全相同。线上服务通常优先保证单请求 latency、TTFT、TPOT 和 SLO；rollout 更关心单位时间生成多少有效训练 token、多少条完整 trajectory，以及这些样本能否及时被训练端消费。

这会带来不同的优化选择。例如，线上服务可能为了尾延迟限制单请求输出长度，而 reasoning RL 恰恰需要大量长 CoT；线上请求不能随意重排，但离线 rollout 可以按 Prompt 长度、采样组和环境类型重组 batch；线上推理可以使用激进量化，RL rollout 却必须额外考虑与训练端的数值一致性。

3. Environment：从单轮回答走向 Agent 轨迹#

数学题或选择题的环境很简单：

Question -> Answer -> Verifier

Agent RL 则可能包含几十轮模型生成与外部交互：

Policy produces Action
        |
        v
Search / Browser / Shell / Simulator
        |
        v
Environment returns Observation
        |
        v
Policy produces next Action
        |
        +------ until success, failure, or max steps

因此，现代 RL Infra 还可能需要管理：

• Python 或 Shell 沙箱；
• 代码编译、执行和测试环境；
• 浏览器、搜索与远程工具；
• 游戏模拟器和多智能体环境；
• 机器人仿真器、传感器和真实设备；
• 环境快照、超时、重试和隔离。

环境往往运行在 CPU、独立容器甚至外部服务上，其延迟分布也比模型推理更不稳定。一个浏览器任务可能几秒结束，另一个任务可能因为网页加载、工具失败或多轮探索运行几分钟。此时系统调度的基本单位不再只是 token 或 request，而是带状态、可暂停、可能失败的 trajectory。

AReaL、SkyRL 和 RLinf 都把长程、多轮或具身环境作为重要目标，而不是只处理单轮文本采样。

4. Reward 与 Verifier：把行为变成训练信号#

Rollout 完成后，系统要把 response 或 trajectory 转换成奖励。常见来源有三类。

4.1 规则验证器#

数学任务可以抽取最终答案后精确匹配：

reward = 1 if predicted_answer == ground_truth else 0

代码任务则可以把验证过程本身做成流水线：

Generated Code
    -> Compile
    -> Run Tests in Sandbox
    -> Aggregate pass rate
    -> Reward

规则验证器的优势是结果明确、可扩展，而且不需要再训练一个偏好模型。数学、代码和工具使用等可验证任务推动了 RLVR（Reinforcement Learning with Verifiable Rewards）的发展。

4.2 Reward Model#

无法通过确定规则判断的开放式任务，可以使用 Reward Model：

Prompt + Response -> Reward Model -> Scalar Score

Reward Model 本身也是模型 forward workload，通常需要独立 batching、显存规划和并行策略。它可能与 actor 争用 GPU，也可能被放到单独的资源池中。

4.3 环境奖励#

Agent 和具身任务的奖励来自任务结果，例如：

• 是否找到正确网页或完成一次购买；
• 是否成功修改代码并通过测试；
• 游戏得分是否提高；
• 机器人是否完成抓取、导航或操作。

无论使用哪种奖励，Infra 都必须记录版本、超时与失败语义。编译器崩溃、网页不可达和答案错误不是同一类结果；如果全部简单记为 0，环境故障会被误当成策略失败，最终污染训练信号。

5. Experience Buffer：RL 数据不只是文本#

普通 SFT 样本通常是预先准备好的 token 序列。RL 训练需要保存更完整的上下文：

{
    "prompt_ids": ...,
    "response_ids": ...,
    "old_log_probs": ...,
    "reference_log_probs": ...,
    "rewards": ...,
    "advantages": ...,
    "attention_mask": ...,
    "policy_version": ...,
}

多轮 Agent 还可能包含：

{
    "actions": ...,
    "observations": ...,
    "tool_calls": ...,
    "environment_states": ...,
    "termination_reason": ...,
}

这些数据可能由 Replay Buffer、Experience Buffer、Data Queue、Trajectory Store 或 Rollout Buffer 管理。名字不同，核心职责相近：在生成、验证和训练之间传递结构化 trajectory，同时保留足够的信息用于 mask、重算、去重、恢复和策略版本检查。

slime 的一个代表性设计，就是通过 Data Buffer 串联训练、rollout、自定义数据生成、reward、verifier 和环境交互。Buffer 在这里不只是缓存，而是解耦不同计算阶段的数据总线。

6. Training Engine：消费在线样本并更新策略#

训练引擎拿到 experience 后执行：

Forward
  -> Policy Loss / KL / Value Loss
  -> Backward
  -> AllReduce / ReduceScatter
  -> Optimizer Step

常见训练后端包括：

• PyTorch FSDP / FSDP2 / DTensor；
• DeepSpeed ZeRO；
• Megatron-LM / Megatron Core；
• 针对特定硬件的自定义训练后端。

它和预训练共享参数分片、activation checkpointing、sequence packing、混合精度、多维并行和 checkpoint 等技术，但数据语义明显不同：样本由近期策略在线生成，还要同时处理 actor、critic、reference policy 和 reward model，并正确对齐 response token、loss mask、old logprob 与 reference logprob。

这里需要区分两个容易混淆的概念：

算法层：PPO、GRPO、DAPO 如何定义目标函数和样本使用方式
系统层：这些模型和数据放在哪里、何时计算、怎样同步和恢复

框架支持某个算法，不代表它已经解决了大规模运行该算法时的 placement、权重转换、长尾和数值一致性问题。

7. Weight Synchronization：让生成引擎跟上训练#

权重同步是 RL Infra 与普通训练、普通推理差异最大的环节之一。

线上推理的权重通常长期静态：

Load Model -> Serve Requests

RL 中的策略却不断变化：

Rollout with theta_0
       -> train and obtain theta_1
       -> synchronize theta_1 to rollout workers
       -> rollout with theta_1

如果模型有数百 GB，每个 step 都保存 checkpoint、跨节点完整复制、再由推理引擎重新加载，权重同步很快就会压过有效计算。因此系统要共同解决：

• FSDP 或 Megatron shard 如何转换成 vLLM/SGLang 所需布局；
• 训练和生成采用不同 TP、PP、EP 时如何 reshard；
• 权重传输能否与 reward、训练或下一批准备工作重叠；
• 是否能够原地更新参数，避免重建整个推理进程；
• LoRA 场景是否只同步 adapter；
• MoE expert 如何按目标 rank 传输；
• rollout worker 当前服务的是哪个 policy version。

权重同步不是单向文件复制，而是一个持续运行的数据面。控制面必须明确何时发布新版本、哪些 worker 已完成切换、旧版本 trajectory 是否仍然可用，以及失败后怎样回滚到一致状态。

verl 的 HybridFlow/Hybrid Engine 重点处理 actor 在训练与生成阶段之间的状态切换和 reshard；NeMo RL 也把训练后端、生成后端和大规模权重传输作为系统设计的重要部分。

8. 为什么 RL Infra 更难：四组核心矛盾#

前面的模块单独看都不陌生，困难来自它们必须同时高效运行，并且维持正确的算法语义。

8.1 高度异构的负载共享同一集群#

一种 placement 很难同时适配所有阶段。给 rollout 最合适的 TP/EP 配置，可能不是训练的最优配置；把 GPU 全部留给 actor，会让 reward 成为瓶颈；为最大环境并发预留 CPU，又可能在普通样本上长期空闲。

因此 RL Infra 不能只最大化某一个 kernel 或单个服务的利用率，而要减少整条 critical path 上的等待。

8.2 不规则长度制造严重长尾#

reasoning rollout 的长度可能相差几个数量级：

Sample 1:    300 tokens
Sample 2:  2,000 tokens
Sample 3: 15,000 tokens
Sample 4:    800 tokens

如果训练 step 必须等待整组样本完成，少数超长回答就会让其余 worker 空转：

GPU 0: ####### done
GPU 1: ##################### straggler
GPU 2: ##### done
GPU 3: ######## done

Agent 任务还会叠加工具调用次数和环境延迟的不确定性。常见缓解手段包括 dynamic batching、continuous batching、sequence packing、dynamic sampling、超时与截断、异步 rollout，以及 trajectory-level scheduling。

但不能只通过粗暴截断消灭长尾，因为最长的轨迹也可能包含最有价值的探索。调度器需要在吞吐、样本分布和任务成功率之间做选择。

8.3 On-policy 新鲜度与硬件利用率冲突#

严格的 on-policy 训练希望用当前策略生成数据，并尽快用这些数据更新当前策略：

theta_0 rollout -> theta_0 update -> theta_1 rollout

为了让生成和训练持续并行，系统又希望在队列里准备更多 trajectory。此时训练端可能已经更新到 $\theta_3$，队列中却仍有 $\theta_0$ 生成的样本：

Rollout: theta_0 -> theta_0 -> theta_1
Train:   theta_0 -> theta_1 -> theta_2 -> theta_3

由此产生 policy staleness、off-policy drift 和更大的 importance ratio。PPO 中常见的概率比为：

当生成策略与训练策略相差过远时，ratio clipping 会丢弃更多更新，训练也可能变得不稳定。

因此，同步系统通常牺牲部分硬件重叠来保证新鲜度；异步系统则通过 policy version、队列深度、最大 staleness、importance correction 或受控更新频率限制偏移。AReaL 重点探索大规模异步 RL，正是为了在这组矛盾中寻找更高的系统效率。

8.4 训练与生成的数值一致性#

训练和推理引擎可能使用不同实现：

• 训练使用 BF16，rollout 使用 FP8；
• 两端采用不同 attention kernel 或计算顺序；
• token mask、position id 或 padding 处理不同；
• MoE router、capacity 或 expert 排序不同；
• tokenizer、chat template 和特殊 token 处理不同；
• sampling 侧记录的 logprob 与训练端重算值不同。

这些差异可能导致：

rollout_engine_logprob != training_engine_logprob

这不只是普通的数值误差。old logprob 是 importance ratio 的分母，如果系统实现让分母发生偏移，PPO/GRPO 的 clipping 和 KL 约束都会失真。结果可能表现为 ratio 在训练开始前就偏离 1、KL 异常、不同后端收敛曲线分叉，甚至 reward 上升但策略质量下降。

所以在 RL Infra 中，训练—生成一致性有时比纯 rollout 吞吐更重要。上线新 kernel、量化或推理后端前，应先在相同权重、相同 token 和相同 mask 下比较 logits、selected-token logprob、KL 与 ratio 分布，再评估性能收益。

9. 两种典型部署：Colocated 与 Disaggregated#

训练和生成如何放置，决定了权重同步方式、资源成本以及系统能否并行。

9.1 Colocated / Hybrid Engine#

生成和训练复用同一批 GPU，按阶段切换角色：

GPU 0-15
  |-- Phase 1: vLLM / SGLang Rollout
  |-- switch state / reshard / release KV cache
  |-- Phase 2: FSDP / Megatron Training
  `-- switch back to Rollout

优点是不用让两套完整模型长期常驻，也避免每个 step 把权重传到另一组机器，适合资源有限或希望保持严格同步的场景。

代价是训练和生成难以充分重叠，阶段切换可能需要释放 KV Cache、恢复 optimizer state、重建通信组或改变 shard 布局。训练和推理的最佳并行配置不同时，reshard 也会进入 critical path。

9.2 Disaggregated / Separate Pools#

生成和训练使用不同资源池：

Rollout GPUs                          Training GPUs
vLLM / SGLang -- trajectories -----> FSDP / Megatron
               <---- new weights ---

优点是两端可以流水并行，并分别选择最合适的 TP、EP、DP 和 batch 策略。长程 Agent rollout 不必阻塞 trainer，训练集群也不必为 decode 的不规则节奏频繁切换状态。

代价是需要更多设备和持续的权重传输，还要处理 policy staleness、背压、服务发现和跨池故障恢复。

它和推理系统的 Prefill/Decode 分离有相似之处：都把不同计算特征的 workload 放到不同资源池。但 RL 分离的是训练与生成，数据是双向流动的：trajectory 发往训练端，新权重再回到 rollout 端。

现实系统还可能使用混合形态：大部分 actor GPU colocated，独立部署 reward 或环境；或者多个 rollout pool 轮流接收版本化权重。部署形态不是框架标签，而是 workload、集群规模和算法容忍度共同决定的结果。

10. RL Infra 与推理 Infra：复用什么，又改变什么#

Rollout 本质是推理，所以两类系统共享大量基础能力：

• FlashAttention、GEMM、MoE kernel 与 fused operator；
• TP、PP、EP、DP、SP/CP 等并行方式；
• AllReduce、AllGather、ReduceScatter 和 All-to-All；
• continuous batching、Paged KV Cache 和 chunked prefill；
• prefix caching、speculative decoding 与显存管理；
• tokens/s、显存利用率和通信效率优化。

但它们服务的对象不同：

最本质的区别可以概括为：

推理 Infra 服务的是请求；RL Infra 服务的是不断变化的策略。

因此，不能只用 output tokens/s 判断 rollout 优化是否成功。更完整的指标至少包括：

rollout tokens/s
samples or trajectories/s
reward / verifier throughput
weight sync time and bandwidth
policy staleness distribution
time per RL step
end-to-end training throughput
reward or evaluation gain per GPU-hour

某项优化即使让 decode 快了 20%，如果增加了 logprob mismatch、让权重同步更慢，或者生成了更多最终被丢弃的 stale trajectory，就未必改善 RL 系统的真实效率。

11. 主流开源框架如何选#

截至 2026 年 7 月，开源 RL Infra 更适合按系统定位分类，而不是简单排一个总榜。

11.1 通用大模型 RL 系统#

verl 的重点是把算法数据流与底层执行解耦，并组合不同训练后端、生成后端和 GPU placement。它适合研究 worker 编排、Hybrid Engine、reshard 和定制 RL 流程。

OpenRLHF 的架构更接近一套组装好的工程方案：Ray 管理 actor、critic、reward、reference 和 vLLM worker，DeepSpeed 负责训练。它适合从传统 RLHF 快速进入完整的 PPO/GRPO 或 Agentic RL 流程。

slime 可以粗略理解为 Megatron Training、SGLang Rollout 与 Data Buffer 的组合。它把数据生成、verifier、reward、环境和训练纳入统一数据流，对研究 Megatron、SGLang、MoE、TP/EP 和超大模型扩展尤其有价值。

NeMo RL 提供 DTensor/FSDP2、Megatron Core 等训练路径，以及 vLLM、SGLang 和 Megatron 相关生成能力。若集群已经深度使用 NVIDIA 与 Megatron 生态，减少权重格式转换和复用现有多维并行能力会很有吸引力。

11.2 异步与 Agent RL#

AReaL 聚焦大规模异步 RL，将 training、inference、agent 和 weight update 作为可独立演进的系统组件，适合研究如何让长程 Agent rollout 与训练持续并行。

SkyRL 是模块化 full-stack RL 框架，重点覆盖长程、多轮、异步调度和工具调用，适合软件工程、终端和搜索 Agent 等场景。

异步系统的吞吐潜力更大，但需要把 policy version、队列背压和 staleness 监控当成一等公民，而不能只看生成 worker 是否一直繁忙。

11.3 具身与 VLA RL#

RLinf 将范围扩展到 LLM reasoning、Agent、VLA、机器人仿真、真实机器人在线 RL 和多智能体。此时系统瓶颈不只是 LLM rollout，而是：

Model Compute
  + Simulator
  + Sensors
  + Environment Step
  + Distributed Training

如果目标是具身智能或 VLA，环境吞吐、仿真并行、传感器数据和真实设备调度会比传统 RLHF 框架中的文本生成更重要。

11.4 入门与算法实验#

Hugging Face TRL 提供 SFT、DPO、GRPO、KTO、PEFT/LoRA，以及 Accelerate、DDP、DeepSpeed 等集成。它适合单机或小集群入门、快速验证 reward function 和算法原型。

TRL 更接近高级训练库，而不是完整的分布式 RL Infra。需要精细控制 rollout 集群、异构 placement、复杂权重同步和异步数据流时，通常还要转向 verl、OpenRLHF、slime、NeMo RL 或专门的 Agent RL 系统。

12. 从 vLLM、MoE 和 MLU 推理走向 RL Infra#

如果已经在做 vLLM、MoE、TP/EP 或 MLU 推理优化，现有经验并不需要推倒重来。它们主要落在 RL 系统的 Rollout Engine，并会继续向权重同步与全局调度延伸：

RL Infra
|-- Rollout Engine
|   |-- vLLM / SGLang
|   |-- KV Cache
|   |-- Chunked Prefill
|   |-- TP / EP
|   |-- Continuous Batching
|   `-- Decode Kernel
|-- Reward / Verifier
|-- Environment
|-- Experience Buffer
|-- Training Engine
|-- Weight Sync
`-- Global Scheduler

12.1 Rollout 性能#

长 CoT 会产生大量 decode token，TPOT、decode throughput、KV Cache 容量和调度长尾仍然是直接瓶颈。不同的是，优化目标要从“单请求更快”扩展为“单位时间产出更多可训练 trajectory”。

12.2 MoE rollout#

MoE 模型在 RL rollout 中仍要处理 Expert Parallel、All-to-All、token dispatch/combine 和负载不均衡。训练端还会增加梯度与 optimizer 通信，因此需要同时观察训练与生成采用的 Expert 布局，以及同步时 expert shard 的目标位置。

12.3 Prefix 共享与 chunked prefill#

GRPO 对同一个 Prompt 生成多个 response，天然存在共享前缀。prefix cache、KV 复用和组内调度有机会减少重复 prefill；但采样分支之后的 KV 生命周期、显存占用和 worker placement 需要统一设计。

12.4 训练—推理权重转换#

如果 MLU 训练栈和 vLLM-MLU 使用不同权重布局，就需要实现可靠的 reshard、设备内更新或增量同步路径。模型越大、TP/EP 差异越大，这部分越可能成为每个 RL step 的固定成本。

12.5 算子与 logprob 一致性#

训练端与 rollout 端的 attention、RoPE、MoE router、采样 logprob、mask 和 tokenizer 必须建立一致性测试。性能回归测试之外，还应固定权重和 token，比较 selected-token logprob、KL、ratio 与最终 loss。

12.6 Ray 与异构资源编排#

系统需要在 actor、critic、reward、rollout、verifier 和环境之间分配 MLU、GPU 与 CPU，并处理 placement group、进程生命周期、背压和故障恢复。这里的难点从“怎样启动一组 worker”升级为“怎样让不同速度的阶段形成稳定流水线”。

13. 一条更实用的学习路线#

对有推理 Infra 背景的工程师，可以按下面的顺序进入 RL Infra：

TRL single-device GRPO
        |
        v
Understand reward / advantage / old logprob / KL
        |
        v
Run an end-to-end GRPO job with verl + vLLM
        |
        v
Trace rollout worker, trainer worker, and trajectory schema
        |
        v
Compare colocated and disaggregated placement
        |
        v
Study weight reshard and weight synchronization
        |
        v
Read slime's Megatron + SGLang + Data Buffer design
        |
        v
Study asynchronous Agent RL with AReaL or SkyRL

如果重点是 vLLM、MoE、TP/EP 与 MLU 推理优化，可以优先学习：

1. verl：先建立完整 RL 数据流、worker 和 Hybrid Engine 认知；
2. slime：继续深入 Megatron、SGLang、Data Buffer 与 MoE scaling；
3. OpenRLHF：理解更直观的 Ray + vLLM + DeepSpeed 工程组合；
4. AReaL / SkyRL：补充异步和长程 Agent 调度；
5. TRL：用最小实验验证算法、reward 与数据语义。

阅读框架时，不要只看它支持多少算法名称。更值得追踪的是一次 trajectory 如何穿过系统：由哪个 worker 生成，reward 在哪里计算，old logprob 来自哪里，policy version 如何记录，训练后哪些参数被传到哪一组 rollout worker，以及失败后如何恢复。

14. 总结#

RL Infra 不是“在训练框架旁边接一个 vLLM”，而是一套围绕动态策略运行的闭环系统：

Rollout
  -> Environment
  -> Reward / Verifier
  -> Experience
  -> Training
  -> Weight Sync
  -> Rollout again

它最核心的系统问题可以归纳为五点：

1. 如何调度 rollout、训练、reward 和环境等异构负载；
2. 如何控制长回答和长程 Agent trajectory 带来的尾部延迟；
3. 如何在 on-policy 新鲜度与硬件利用率之间取得平衡；
4. 如何低成本完成训练权重到生成引擎的持续 reshard 与同步；
5. 如何保证训练端和生成端的 token、mask、logprob 与模型算子一致。

对于推理 Infra 工程师，最重要的认知转变是：

在推理 Infra 中，vLLM 是完整系统；在 RL Infra 中，vLLM 是 rollout 子系统。真正决定 RL 效率的，是 rollout、环境、奖励、训练和权重同步能否形成正确而高效的流水线。

最终应该优化的也不只是某个推理引擎的 tokens/s，而是：

time per RL step
fresh trajectories per second
end-to-end training throughput
model improvement per GPU-hour

只有这些端到端指标真正改善，Infra 优化才最终转化为更快、更稳定的策略学习。

延伸阅读#

1. verl: A Flexible and Efficient RL Post-Training Framework
2. OpenRLHF: Scalable RLHF and Agentic RL with Ray, vLLM, and DeepSpeed
3. slime: An LLM Post-Training Framework for RL Scaling
4. NeMo RL: A Scalable and Efficient Post-Training Library
5. AReaL: A Large-Scale Asynchronous Reinforcement Learning System
6. SkyRL: A Modular Full-Stack RL Library for LLMs
7. RLinf: Reinforcement Learning Infrastructure for Embodied and Agentic AI
8. TRL: Transformers Reinforcement Learning