强化学习｜训练框架verl介绍

强化学习训练过程涉及模型多，数据流转复杂，经典的“串行”训练框架，存在资源闲置，训练效率低的情况。 verl 通过自动映射算法进行计算资源的智能规划，通过混合编程模型提供灵活API接口，并结合3D混合引擎实现了核心计算的高效执行，从而构建了一个高性能、可扩展的强化学习训练系统。本节围绕verl主要介绍：

1）传统强化学习训练框架的资源瓶颈问题。 2）verl如何通过混合范式实现“分时复用”的调度性训练。 3）介绍verl基础架构以及训练流程。

关注“AI老马” —【获取资源】&【进群交流】

1，RL训练流程及问题

1.1，RL训练三阶段

强化学习RLHF训练过程中，一般由四个模型（Actor、Critic、Reward和Reference）分三个阶段（生成，准备和训练）进行。

图1，RLHF训练阶段

生成阶段： Actor 会进行 auto-regressive decoding，强化学习中将 Actor的推理称为Rollout，即模型根据当前的策略“生成”文本的过程。

准备阶段： Critic，Reward 和 Reference 则只会进行 prefill，不会 decoding，强化学习中称为 inference。因为是对已知序列的推理，而不是预测未知 token，在这个过程中，比如 Reference 模型会为序列中的每一个位置计算一个logits概率分布。

训练阶段： 根据生成的样本和对应的奖励信号，反向传播更新模型参数的过程。

下面为进行一次模型训练的具体流程：

• • 在训练数据集中准备一个batch的 prompts；
• • 将batch 内的 prompts 输入给 Actor，进行自回归生成对应回复responses；
• • 将 prompt + responses 输入给 Critic/Reward/Reference模型，进行推理 inference，分别计算得到 values/Reward /log probs，将这些统一称为经验 experiences；
• • 根据experiences 多轮计算 Actor Ioss 和 Critic Ioss 并更新 Actor 和 Critic；

1.2，训练流程中的瓶颈

在RLHF中采用的优化算法一般为近端策略优化，而PPO是On-Policy 算法，意味着“边学边卖”。模型用来学习的经验，必须是“当前最新版本”的模型刚刚生成的。不能用昨天那个旧模型生成的文本来训练今天的模型。这样的后果导致一个死结，Rollout 和 Training 必须严格串行，即：

• • 先用当前模型生成数据（Rollout）；
• • 立刻用这批数据训练更新模型 （Training）；
• • 更新完后，模型变了，必须停下来，用新模型重新生成数据，再次Rollout；

传统分离部署，通常会把 Rollout 任务部署在一组卡上（比如 GroupA，2张卡），把Training 任务部署在另一组卡上 （比如 Group B，4张卡）。

资源浪费问题 (Resource Idle):

当Group A 在疯狂生成数据时，Group B必须干等着，因为没有数据可练。

当Group A生成完把数据给 Group B 训练时，Group A又必须干等着（因为模型正在变，还没更新完，不能生成）。

小结： 无论怎么调度，系统里总有一部分昂贵的GPU在“摸鱼”，利用率极低。

2，混合引擎 Hybrid Engine

2.1，Single-Controller & Multi-Controller

Single-Controller 由一个中央控制器统一管理数据流图中各节点的进程分配与执行顺序。每个节点进程可进一步派生子工作器执行计算，但仍遵循单控制器逻辑。

• • 优势：全局视角便于优化资源映射与任务调度，适合构建核心功能集中的数据流。
• • 局限性：控制器需向所有工作器发送协调指令，在大型集群上执行庞大计算图时会产生显著调度开销。尤其对于RLHF场景（每个节点对应包含数十亿算子的LLM)，单控制器分派算子的效率低下。

Multi-Controller 每个设备独立拥有控制器，通过点对点通信协调节点间数据依赖。

• • 优势：调度开销极低（控制消息通过高速PCle链路在CPU和GPU间传输），被主流分布式LLM训练/服务系统采用。
• • 局限性：缺乏中心控制逻辑，实现复杂RLHF数据流时灵活性不足。修改单个节点需同步调整所有依赖节点的代码，导致开发维护困难。

2.2，HybridFlow混合范式

为了解决上述“因为串行导致的资源闲置”问题，verl 引入了 Hybrid Engine。核心思想：复用资源，而不是拆分资源。即 Hybrid Engine 不再把GPU分成 ”生成组“ 和 ”训练组”，而是让同一组GPU 既干生成，也干训练。它的工作流程中只有一个统一的资源组 （比如一共8张卡），两个阶段串行执行与显存复用：

• • 阶段一：Rollout 模式

系统加载高效的推理引擎（如VLLM)，此时，训练引擎(Training Engine) 不需要工作，它的相关显存占用纯属浪费。

操作：把训练引擎占用的显存清理掉，即Offload 到 CPU 内存里暂存，或者如果数据不重要直接删掉。

结果：所有的GPU 显存和算力全副武装，全力做生成，速度极快。

• • 阶段二：Training 模式

生成完毕，拿到数据，准备训练。此时，推理引擎不再需要工作。

操作：释放掉推理引擎占用的显存，重新把训练引擎的状态从 CPU 加载回来。

结果：所有的GPU 显存和算力全副武装，全力做梯度计算。

简而言之，Hybrid Engine 就像是一个“分时复用”的调度器。它的核心价值在于：最大化GPU利用率，无论是在生成还是训练，GPU都在满负荷工作，没有闲置。解决了显存焦虑，通过 Offload 卸载机制，让推理和训练互不抢占显存，可以在有限的显存里跑更大的模型。

PS：通过以上的内容，传统的训练流程是三个（Rollout、Inference和Training）而verl中的训练没有将 Inference 单独的拎出来。verl 的两个阶段是基于GPU工作模式（推理 vs 训练）的物理切换，而不是基于逻辑任务的划分。它将计算特性相同的 “传统Rollout" 和 “传统inference” 逻辑任务合并到了同一个 “Rollout模式“ 物理阶段中执行。

3，verl代码架构介绍

图2，verl架构图。

3.1，混合编程模型

混合编程模型的目标是，提供一套灵活且高效的编程接口，让用户能够轻松地定义和表达复杂的RLHF数据流，即Actor、Critic、Reference、Reward 等之间的交互关系，并管理这些模型的高效计算。

具体工作方式：

分层API： 提供了一组 “分层” 的API。高级API能允许用户以简洁的方式直接描述整个RLHF流程，例如，先让Actor模型生成回答，然后用Critic模型评分等，而无需关心底层的并行细节。低级API也提供更底层的控制接口，让专家用户能够精细地调整计算过程，例如指定特定的计算图优化或内存管理策略。

表达数据流：用户通过这些API，可以像搭积木一样将RLHF涉及的各个模型和计算步骤连接起来，形成一个完整的、有向的数据流图。

高效计算：该模型底层会优化这个数据流图的执行，确保各个模型的计算能够尽可能并发执行，减少设备空闲时间，从而提高整体吞吐量。

3.2，3D混合引擎

混合引擎主要为RLHF流程中最核心且最耗资源的 Actor模型而设计，它解决了两个关键问题：

问题1：允许Actor在“训练”和“生成（推理）“两个阶段使用不同的3D并行配置。因为训练需要存储梯度等中间变量，而生成则对延迟更敏感，最优的并行策略可能不同。

问题2：在训练和生成两个阶段切换时，实现零内存冗余并最小化通信开销。

具体工作方式：

动态3D并行：传统系统通常为一个模型固定一种并行策略。3D混合引擎允许Actor模型在生成阶段和训练阶段采用两套独立的配置。例如，生成时可能用更小的PP和TP来降低延迟，训练时则用更大的DP来加速。

无缝切换与数据重分片：当Actor从生成阶段切换到训练阶段时，由于并行配置改变，模型参数、优化器状态、以及生成的回答数据在GPU集群中的分布也需要改变。3D混合引擎负责高效地完成这种数据重分片操作。通过精心设计的通信协议，直接在设备间交换数据，避免了将整个模型状态先汇集到一台机器再重新分发的低效做法，从而实现了“零内存冗余”和“最小化通信开销”。

3.3，自动映射算法

自动映射算法是一个离线规划工具，在训练开始前，根据用户提供的模型规格和GPU集群配置（节点数、GPU 数、网络带宽)，自动为RLHF数据流中的每一个模型计算出一个最优的设备放置方案。

具体工作方式：

建模与搜索：将设备集群和模型计算抽象为一个复杂的优化问题。考虑每个模型的计算量、内存占用、以及模型之间数据传输的通信成本。例如，Actor生成的回答需要传递给Critic模型，它们放在通信带宽高的设备上会更高效。

最大化吞吐量：优化目标是最大化整个RLHF流程的系统吞吐量。算法会搜索所有可能的设备放置组合，评估每种方案的总计算时间和通信时间，最终选择一个预计能带来最高训练效率的方案。这个方案的结果就是告诉系统，“将Actor模型放在GPU 0-7上，Critic模型放在GPU 8-15上“等等。

4，VERL 训练流程

整个工作流程可以分为准备阶段和执行阶段。

4.1，准备阶段

用户需要准备以下三个输入来启动系统：

模型规格：定义RLHF数据流中所有模型（Actor/Critic/Reference/Reward）的架构（如LLaMA、GPT）和参数量。

设备放置方案：运行自动映射算法，根据第1步的模型规格和现有的GPU集群配置，得到每个模型应该被放置在哪些具体的GPU上。

并行策略：为每个模型在每一个阶段指定其3D并行配置。例如，对于Actor模型，你需要分别指定它在生成阶段和训练阶段的(PP，TP, DP) 大小。

4.2，执行阶段

初始化：

单控制器程序接收上述三个输入。并根据模型规格，在内存中初始化所有模型的参数。然后根据自动映射算法得到的设备放置方案，将这些模型参数分发到对应的GPU上，形成一个“虚拟化资源池”。

分布式计算执行：

第一步：单控制器程序将具体的计算任务（如“运行Actor生成”）分派给相应的设备。

第二步：在每个设备上，有一个多控制器程序在运行。

多控制器程序的作用是：

• • 根据为每个模型设定的并行策略，在分配到的设备上构建相应的并行组（如TP组、PP流水线）。
• • 对于Actor模型，调用3D混合引擎来执行高效的生成和训练。
• • 对于其他模型（Critic等），它可以无缝集成现有的LLM训练/推理引擎(如Megatron-LM、DeepSpeed等)来执行计算。

数据流协调与重新分片：

单控制器程序还负责协调整个RLHF数据流。当数据需要从一个模型传递到另一个使用不同并行策略的模型时（例如，Actor生成的回答需要传递给Critic进行评分），单控制器会启动传输协议来对数据进行重分片，以确保数据格式符合下一个模型的输入要求。

特别地，Actor模型自身在训练和生成阶段之间的数据重分片，由3D混合引擎内部高效处理，这是其核心优势之一。

总结：

VERL (HybridFlow) 通过 “自动映射算法” 进行智能规划，通过 “混合编程模型“ 提供灵活接口，再通过 “3D混合引擎“ 实现核心计算的高效执行，三者环环相扣，共同构建了一个高性能、可扩展的RLHF训练系统。