引言

随着大语言模型（LLM）技术的飞速发展，强化学习与人类反馈（RLHF）已成为模型对齐的核心技术路径。从 ChatGPT 到 o1，RL 算法在提升模型推理能力、对齐人类偏好方面展现出不可替代的价值。然而，当模型规模从数十亿参数增长到数千亿甚至万亿参数时，传统强化学习框架在系统设计层面遭遇了前所未有的挑战。

传统 RL 框架诞生于小模型时代，其设计假设单个神经网络的计算可以在单进程内完成。但在 LLM 时代，每个模型节点本身就是一个复杂的分布式训练程序，模型间的数据交互演变为多对多的分片传输。这种根本性的变化导致现有框架陷入两难境地：要么采用单控制器架构牺牲计算效率，要么采用多控制器架构牺牲灵活性与代码可复用性。

由字节跳动豆包大模型团队与香港大学联合研发的 HybridFlow 架构，以及基于该架构开源的 veRL 框架，为这一困境提供了系统性解决方案。HybridFlow 创新性地将单控制器与多控制器范式混合结合，在节点间采用单控制器实现灵活编排，在节点内采用多控制器保障计算效率，实现了灵活性与高性能的兼得。实验数据显示，HybridFlow 在各类 RLHF 算法上相比业界最优基线实现了 1.53×~20.57× 的吞吐量提升。

本文将从系统设计原理、核心技术创新、代码架构实现三个维度，对 veRL 与 HybridFlow 进行深度技术拆解，帮助读者全面理解这一前沿 RLHF 训练框架的内在机制。

一、RLHF 训练的系统困境

1.1 RL 作为双层数据流问题

在深入 HybridFlow 架构之前，我们首先需要理解：为什么传统 RL 框架无法很好地适配大模型场景？答案在于 RL 训练本质上是一个双层数据流问题。

神经网络训练本身是一层数据流：每个节点代表一个算子（加减乘除、矩阵乘、激活函数等），边代表张量流动方向。而强化学习训练则是更高层的数据流：每个节点代表一次完整的神经网络计算（如模型推理、参数更新），边代表数据在不同模型角色间的传递。

工作负载类型	节点含义	边含义
神经网络训练	基础算子（matmul/softmax 等）	张量流动
强化学习训练	高层算子（rollout/update 等）	批量数据传输

在小模型深度强化学习（DRL）时代，每个高层算子内部的神经网络计算可以在单个进程内完成，因此控制流与计算流可以耦合在同一进程中。但进入 LLM 时代后，每个模型的计算都需要分布式多进程协同完成，这使得传统架构设计不再适用。

1.2 两种架构范式的局限

面对大模型 RLHF 训练，业界先后演化出两种架构范式，但各有其固有缺陷：

单控制器范式（Single-Controller）

该范式由一个中心进程统一调度所有计算，既管理模型间执行顺序，也控制模型内分布式计算。其优势是全局视图清晰、编排灵活；但致命缺陷是调度开销巨大 —— 中心控制器需要向分布式加速器下发海量算子指令，当模型达到数十亿参数规模时，调度延迟会严重拖累整体吞吐量。传统 RL 框架如 RLlib 均采用此架构，仅适用于百 MB 级以下模型。

多控制器范式（Multi-Controller）

为解决调度开销问题，现有 RLHF 系统（如 DeepSpeed-Chat、OpenRLHF）转向多控制器范式：每个设备独立管理自身计算，通过点对点通信协调数据依赖。这种方式消除了中心调度瓶颈，计算效率极高；但代价是灵活性严重受损 —— 控制逻辑与计算代码深度耦合，修改一个节点的数据依赖需要同步改动所有关联节点的实现，代码复用性极差，难以快速迭代新算法。

1.3 HybridFlow 的核心洞察

HybridFlow 的关键洞察在于：单控制器与多控制器并非非此即彼的二元选择，而是可以在不同层级上分别应用。

• 节点间（Inter-node）：采用单控制器范式。RL 算法的控制逻辑（如 PPO 的 rollout→优势计算→更新循环）由单一进程统一编排，利用全局视图实现灵活的数据流表达，且由于调度粒度是 "模型级" 而非 "算子级"，调度开销可忽略不计。
• 节点内（Intra-node）：采用多控制器范式。每个模型内部的分布式计算（前向 / 反向、优化器更新）由各设备独立控制，充分利用现有 LLM 训练框架的成熟优化，保障计算效率。

这种 "上层单控、下层多控" 的混合架构，正是 HybridFlow 名称的由来，也是其同时具备灵活性与高性能的根本原因。

二、HybridFlow 核心架构设计

2.1 整体架构概览

HybridFlow 整体架构由三大核心组件构成：

1. 混合编程模型（Hybrid Programming Model）：提供分层 API 体系，解耦控制流与计算流，支持灵活表达各类 RLHF 数据流
2. 3D-HybridEngine：专为 Actor 模型设计，实现训练与生成阶段不同并行策略间的零冗余高效切换
3. 自动映射算法（Auto-Mapping）：根据集群资源与模型配置，自动优化模型部署方案与并行策略选择

三者协同工作，形成从算法表达到底层执行的完整技术栈。用户只需定义 RLHF 数据流图、模型配置与设备配置，框架即可自动完成资源分配、模型部署与执行调度。

2.2 控制流与计算流的解耦

veRL 采用 "控制流单进程、计算流多进程" 的分离设计。这一设计决策是理解整个框架的钥匙。

控制流（Control Flow）：运行在单一控制器进程中，描述 RL 算法的核心逻辑 —— 例如 PPO 中先执行 rollout 生成数据，再计算优势函数，最后更新 Actor 和 Critic 网络。开发者以类似编写单进程程序的方式编写算法逻辑，无需关心底层分布式细节。

计算流（Computation Flow）：运行在多进程 Worker 集群中，执行具体的神经网络计算 —— 模型前向、反向传播、优化器步进等。每个模型角色（Actor/Critic/RM/Ref）对应一个或多个 Worker 进程组，内部可采用 FSDP、Megatron-LM 等任意分布式策略。

这种解耦带来了显著的工程价值：

• 算法代码可复用：切换计算后端（如从 FSDP 改为 Megatron）时，控制流代码完全不变
• 新算法易实现：开发新 RL 算法只需在单进程中修改控制逻辑，无需触碰分布式代码
• 部署灵活：通过配置即可调整模型共置 / 分离部署，无需改动算法代码

当然，分离设计也带来了额外的数据通信开销 —— 控制器与计算进程间需要来回传输数据。但实践证明，由于通信粒度是整批次数据而非单个算子，这一开销在大模型场景下占比极低，完全可以被灵活性收益所覆盖。

2.3 分层 API 设计

HybridFlow 的编程模型采用分层 API 设计，自上而下逐层封装分布式复杂度。

第一层：3DParallelWorker 基类

这是计算层的抽象基类，负责封装单个模型的分布式计算细节。给定一组设备，它自动完成：

• 分布式模型权重初始化
• 建立 3D 并行组（PP/TP/DP）
• 提供统一的前向、反向、生成、更新接口

在此基础上衍生出 ActorWorker、CriticWorker、RewardWorker、RefPolicyWorker 等具体模型类，分别封装对应角色的计算逻辑。用户还可以基于 FSDP、ZeRO 等不同并行策略派生出对应版本的 Worker。

第二层：传输协议（Transfer Protocol）

不同模型可能运行在不同设备上、采用不同并行策略，它们之间的数据传输涉及复杂的多对多分片重组。HybridFlow 通过传输协议统一封装了这一过程。

每个 Worker 方法通过 @register 装饰器绑定一个传输协议。协议包含两个函数：

• collect 函数：将分布式计算的输出数据从各分片收集汇总
• distribute 函数：将输入数据分发到各计算分片

系统内置了 8 种传输协议，覆盖绝大多数场景：

协议名称	适用场景
3D_PROTO	3D 并行训练的典型场景，输出仅存在于最后流水线阶段且在 DP 组间复制
DP_PROTO	纯数据并行模式
ONE_TO_ALL	广播式数据分发，如模型初始化
3D_ALL_MICRO_DP	HybridEngine 专用，处理训练与推理切换时的微 DP 组
3D_PP_ONLY	仅流水线并行维度检查
ALL_TO_ALL	全交换模式，多用于调试

以 Actor 生成数据传递给 Critic 为例，数据流向如下：

1. 控制器调用 Actor 的 generate_sequences 方法
2. Actor 各 DP 分片并行执行生成
3. 通过 3D_PROTO 的 collect 函数汇总生成结果
4. 控制器将数据 futures 传递给 Critic
5. Critic 通过自身 3D_PROTO 的 distribute 函数将数据分发到对应分片
6. Critic 各分片按需拉取自身所需的本地批次数据

值得注意的是，实际数据传输直接发生在 GPU 之间，控制器仅传递元数据与引用，避免了中心瓶颈。

第三层：ResourcePool 资源抽象

ResourcePool 是对一组 GPU 设备的虚拟化抽象。将同一个 ResourcePool 实例传递给不同 Worker，意味着这些模型将共置在同一组 GPU 上；使用不同 ResourcePool 则表示分离部署。

这一设计使得模型部署策略完全配置化：用户只需修改资源池分配，即可在全共置、全分离、部分共置等多种部署模式间灵活切换，而算法代码保持不变。

第四层：单控制器数据流

最上层是运行在单进程中的控制器，它通过 WorkerGroup 代理调用各个模型的方法，编写方式与普通单进程程序几乎无异。开发者只需关注算法逻辑本身，分布式细节全部被下层封装。

三、3D-HybridEngine：训练与生成的高效切换

3.1 问题背景：Actor 的双重身份

在 RLHF 训练中，Actor 模型扮演着双重角色：

• 生成阶段（Rollout）：自回归生成回答，属于推理工作负载
• 训练阶段（Update）：计算损失并更新参数，属于训练工作负载

这两个阶段对并行策略的偏好截然不同：

• 生成阶段：通常需要较小的 TP（张量并行）和 PP（流水线并行）尺寸，更大的 DP（数据并行）尺寸，以提升并发生成吞吐量
• 训练阶段：通常需要更大的 TP/PP 来分摊单卡显存压力，DP 尺寸相对较小

传统方案要么在两个阶段使用相同并行策略（顾此失彼），要么维护两份独立的模型权重（显存冗余严重）。而 RLHF 训练需要在两个阶段间频繁切换，这一问题尤为突出。

3.2 三维并行分组设计

3D-HybridEngine 的核心思想是：在同一组 GPU 上，为训练和生成分别构建独立的并行组，通过高效的重分片机制实现阶段切换。

训练阶段采用标准的 p-t-d 三维并行配置：

• p：流水线并行（PP）大小
• t：张量并行（TP）大小
• d：数据并行（DP）大小

生成阶段采用 pg-tg-dg-d 四维配置：

• pg：生成阶段 PP 大小
• tg：生成阶段 TP 大小
• dg：微数据并行（Micro DP）大小，即训练时的每个 DP 副本在生成时分裂为 dg 个微副本
• d：与训练阶段保持一致的 DP 维度

总 GPU 数量满足恒等式：p × t × d = pg × tg × dg × d，因此 dg = (p×t) / (pg×tg)。

引入 Micro DP 的目的是：在生成阶段通过更高的并发度提升吞吐量，同时确保训练阶段仍能使用充足的模型并行度来容纳大模型。

3.3 零冗余参数重分片

传统的并行分组方法在切换阶段时会产生严重的内存冗余。以 1-4-2（训练）切换到 1-2-2-2（生成）为例，部分 GPU 上训练分片与生成分片没有重叠，需要同时保存两份权重 —— 这就是所谓的 "Vanilla" 方案。

3D-HybridEngine 通过重新设计并行分组方式，实现了零冗余切换：

其核心优化在于调整生成阶段的并行分组排列方式，使得训练分片与生成分片的重叠度最大化，从而避免冗余存储。配合精心设计的通信模式，参数重分片仅需在 Micro DP 组内执行 all-gather 操作即可完成，通信量大幅降低。

3.4 双缓冲区执行机制

实际实现中，3D-HybridEngine 采用双缓冲区机制管理权重：

1. 训练缓冲区（buffer_train）：常驻 GPU 显存，保存训练阶段的参数分片
2. 生成缓冲区（buffer_gen）：可在 GPU/CPU 间换入换出

完整的单次迭代流程如下：

1. 训练结束后，通过 NCCL 集合通信在 Micro DP 组内聚合参数，构建生成阶段权重
2. 生成阶段使用 buffer_gen 执行自回归生成，同时 buffer_train 仍保留在 GPU 中
3. 生成结束后，将生成权重与 KV Cache 卸载到 CPU 内存
4. 下一训练阶段直接使用 buffer_train 中的参数进行训练

这种设计既保障了训练阶段的显存效率，又通过 CPU 卸载避免了生成权重占用宝贵的 GPU 显存。对于多轮对话场景，KV Cache 的卸载与重载机制也得到了相应支持。

四、Auto-Mapping：自动设备映射算法

4.1 问题的复杂性

RLHF 训练涉及多个模型角色，如何将它们部署到 GPU 集群上是一个复杂的组合优化问题。以经典 PPO 为例，涉及 Actor、Critic、Reference、Reward 四个模型，可能的部署方案多达 15 种（集合划分问题）—— 从全部共置到完全分离，各种组合各有利弊。

• 共置部署：共享 GPU 资源，节省设备，但模型串行执行，且对单卡显存要求高
• 分离部署：模型可并行执行，延迟低，但资源利用率低、设备需求大

此外，每个模型在不同阶段还可以选择不同的并行策略。人工试错寻找最优配置不仅耗时，而且往往难以找到全局最优解。

4.2 算法设计思路

Auto-Mapping 算法的目标是：给定 RLHF 数据流图、模型配置与集群规模，自动找出最优的设备部署方案与并行策略组合，最小化单轮迭代的端到端延迟。

算法采用枚举 + 仿真的两阶段思路：

1. 枚举部署方案：遍历所有可能的模型共置 / 分离组合（即集合划分）
2. 计算最小显存需求：对每种部署方案，计算每个共置组所需的最少 GPU 数量以容纳所有模型
3. 枚举设备分配：从最小分配开始，逐步增加 GPU 数量，探索所有可行分配
4. 自动并行策略搜索：对给定的设备数与模型，通过性能仿真器寻找最优并行配置
5. 端到端延迟估算：基于数据流图计算整轮迭代的总延迟
6. 选择全局最优：在所有方案中选出延迟最小的映射方案

算法内置了训练、推理、生成三类性能仿真器，能够基于模型架构、并行策略、硬件规格较为准确地预估执行延迟。虽然枚举方案数量随模型数指数增长，但 RLHF 场景下模型数量通常在 4-6 个，计算量完全在可接受范围内。

4.3 实际价值

自动映射算法带来的价值体现在三个层面：

易用性：用户无需成为分布式系统专家，只需输入模型规格与集群规模，即可获得优化的部署方案。

性能最优：算法能够发现人工容易忽略的组合方案。论文实验显示，自动映射得到的混合部署方案相比传统全共置或全分离方案，吞吐量可提升 30% 以上。

弹性适配：集群规模变化时，重新运行算法即可获得新的最优配置，无需人工重新调优。

五、veRL 代码架构深度解析

5.1 代码库整体结构

veRL 是 HybridFlow 论文思想的工业级开源实现，代码组织清晰，模块化程度高。核心目录结构如下：

verl/
├── trainer/                    # 训练器层（控制流）
│   ├── main_ppo.py            # PPO 训练入口
│   ├── main_fastrl.py         # FastRL 统一入口
│   └── ppo/
│       └── ray_trainer.py     # Ray PPO 训练器核心
├── workers/                    # 计算工作层（计算流）
│   ├── protocol.py            # DataProto 数据协议
│   ├── fsdp_workers.py        # FSDP 后端 Worker
│   ├── megatron_workers.py    # Megatron 后端 Worker
│   ├── actor/                 # Actor 模型实现
│   ├── critic/                # Critic 模型实现
│   ├── reward_model/          # 奖励模型实现
│   ├── rollout/               # Rollout 引擎
│   │   ├── vllm/              # vLLM 后端
│   │   └── hf_rollout.py      # HuggingFace 后端
│   └── sharding_manager/      # 分片管理器
├── config/                     # 配置模板
├── utils/                      # 工具集
│   ├── dataset/               # 数据集处理
│   └── reward_score/          # 奖励函数
├── models/                     # 模型实现
│   ├── llama/
│   └── transformers/
└── third_party/                # 第三方适配
    └── vllm/                   # vLLM 集成适配

从架构上看，trainer/ 目录对应控制流层，workers/ 目录对应计算流层，两者通过 WorkerGroup 与传输协议进行交互，完美体现了 HybridFlow 的分层设计思想。

5.2 核心入口：RayPPOTrainer

verl/trainer/ppo/ray_trainer.py 中的 RayPPOTrainer 是整个 PPO 训练的控制中枢，也是单控制器范式的具体体现。

它的核心职责包括：

• 构建各个角色的 WorkerGroup
• 管理训练主循环
• 协调各阶段执行顺序
• 处理数据在不同 Worker 间的流转

其 fit() 方法就是 PPO 算法主循环，代码结构清晰得令人惊讶：

def fit(self):
    # 初始化数据加载器
    train_dataloader = self._build_train_dataloader()
    
    for epoch in range(self.total_epochs):
        for batch in train_dataloader:
            # ===== 阶段1：生成响应 =====
            output = self.actor_rollout_ref_wg.generate_sequences(batch)
            
            # ===== 阶段2：计算经验数据 =====
            old_log_prob = self.actor_rollout_ref_wg.compute_log_prob(output)
            ref_log_prob = self.actor_rollout_ref_wg.compute_ref_log_prob(output)
            values = self.critic_wg.compute_values(output)
            rewards = self.reward_wg.compute_scores(output)
            
            # 优势函数计算（直接在控制器进程执行）
            advantages = compute_advantages(values, rewards, old_log_prob, ref_log_prob)
            
            # 合并所有数据
            batch = output.union(old_log_prob)
            batch = batch.union(ref_log_prob)
            batch = batch.union(values)
            batch = batch.union(rewards)
            batch = batch.union(advantages)
            
            # ===== 阶段3：更新模型 =====
            actor_metrics = self.actor_rollout_ref_wg.update_actor(batch)
            critic_metrics = self.critic_wg.update_critic(batch)
            
            # 记录日志
            self._log_metrics(actor_metrics, critic_metrics)

5.3 WorkerGroup 与注册机制

WorkerGroup 是连接控制流与计算流的桥梁。它本质上是一组远程 Worker 进程的代理，对外暴露统一的方法接口，内部自动处理数据分发与收集。

每个 Worker 方法通过 @register 装饰器声明其分发模式：

@register(dispatch_mode=Dispatch.DP_COMPUTE_PROTO)
def generate_sequences(self, data: DataProto) -> DataProto:
    # 具体的生成逻辑
    # 此代码运行在每个 Worker 进程上
    ...

Dispatch.DP_COMPUTE_PROTO 表示：

• 调用时，控制器将数据按 DP 维度切分，分发到各个 Worker
• 执行完成后，控制器收集各 Worker 的输出并拼接返回

系统支持多种分发模式，对应不同的传输协议。这套机制使得控制器调用 WorkerGroup 方法就像调用本地函数一样简单，但实际执行发生在分布式 GPU 集群上。

5.4 DataProto：统一数据协议

所有在 Worker 间传递的数据都封装为 DataProto 对象。这是一个基于字典的数据结构，统一管理输入 ids、attention mask、log probs、rewards 等各类张量。

DataProto 的设计解决了两个关键问题：

1. 统一接口：所有 Worker 方法输入输出格式一致，便于组合与复用
2. 分片友好：内置按 batch 维度拆分与拼接的方法，适配数据并行分发

在 v0.7 版本中，veRL 正逐步用 PyTorch 的 TensorDict 替代 DataProto，以获得更好的性能与生态兼容性。

5.5 ActorRolloutRefWorker：高度复用的设计

一个特别能体现 veRL 设计巧思的地方是 ActorRolloutRefWorker。这个单一 Worker 类通过配置可以扮演多种角色：

配置方式	角色
仅启用 actor	纯 Actor 训练 Worker
仅启用 rollout	纯 Rollout 推理 Worker
同时启用 actor+rollout	HybridEngine，训练生成一体化
同时启用 actor+rollout+ref	三者共置，LoRA 场景下效率最高

六、算法生态：从 PPO 到 GRPO

6.1 PPO：经典算法的工程化实现

PPO（Proximal Policy Optimization）是 RLHF 的基石算法，也是 veRL 支持最完善的算法。

veRL 的 PPO 实现遵循标准算法流程：

1. Rollout 阶段：Actor 根据 prompt 生成 response
2. 评估阶段：计算旧策略 log_prob、参考策略 log_prob、价值估计、奖励值
3. 优势估计：默认使用 GAE（广义优势估计）
4. 更新阶段：Actor 和 Critic 分别使用 PPO Clip 损失更新

在工程层面，veRL 做了大量优化：

• 支持 micro batch 梯度累积，适配大 batch 训练
• 支持多 epoch 训练同一批数据
• 序列长度均衡（seqlen balancing），减少 padding 浪费
• 支持 token-level 与 sequence-level 两种损失聚合模式

6.2 GRPO：无需 Critic 的简化方案

GRPO（Group Relative Policy Optimization）是近年来兴起的轻量级 RL 算法，最大特点是完全去除 Critic 网络，改用组内相对优势估计。

GRPO 的核心思想很巧妙：对同一个 prompt 生成多个回答，以组内奖励的均值和方差作为 baseline 计算归一化优势。这样既省去了训练 Critic 的麻烦，又避免了价值估计偏差带来的问题。同时，KL 散度作为正则项直接加入损失函数。

在 veRL 中启用 GRPO 只需修改几个配置项：

algorithm:
  adv_estimator: grpo              # 切换优势估计器
  kl_ctrl:
    type: fixed
    kl_coef: 0.001

actor_rollout_ref:
  actor:
    use_kl_loss: True              # 在损失中加入 KL 正则
    kl_loss_coef: 0.001
    kl_loss_type: kl
    loss_agg_mode: token-mean      # 损失聚合方式

由于去除了 Critic，GRPO 的显存需求显著降低，训练也更稳定。在数学推理等任务上，GRPO 往往能以更少的资源达到媲美甚至超越 PPO 的效果。

6.3 更多算法支持

除了 PPO 和 GRPO，veRL 还在持续扩展算法生态：

• DAPO：动态优势策略优化，改进优势估计方式
• CISPO：裁剪重要性采样策略优化
• SAPO：软自适应策略优化
• ReMax：基于奖励的简单高效 RL 方法
• Safe-RLHF：带安全约束的 RLHF

得益于 HybridFlow 的灵活架构，新增算法通常只需在控制器层面修改数据流向与损失计算，无需改动底层计算引擎代码。这使得 veRL 的算法迭代速度远超传统框架。

七、veRL 0.7：新一代架构演进

7.1 verl-core：四大核心组件

2026 年初发布的 veRL 0.7 版本标志着架构的重大升级。新版本将核心能力抽象为 verl-core 层，提供四大可插拔组件：

1. Model Engine（模型引擎）：统一的训练引擎抽象，支持 FSDP、Megatron-Core、VeOmni 等多种后端
2. Rollout Engine（生成引擎）：统一的推理生成抽象，默认采用 Server 模式，支持 vLLM、SGLang、TensorRT-LLM
3. Checkpoint Engine（检查点引擎）：跨后端权重同步抽象，支持 NCCL、NIXL 等传输后端
4. TransferQueue（传输队列）：高性能数据传输层，解耦控制流与数据流

这一演进使得各组件可以独立迭代、灵活替换，框架的可扩展性迈上了新台阶。

7.2 Rollout Server 模式

v0.7 的一个重要变化是全面转向 Rollout Server 模式，淘汰了原有的 SPMD Rollout 模式。

在 Server 模式下：

• LLM 推理引擎以在线服务的形式运行，支持动态批处理（dynamic batching）
• 训练器作为客户端发送请求，支持单轮与多轮 Agent 循环
• 推理引擎与训练引擎彻底解耦，可以独立升级、独立扩缩容

这一架构对于 Agentic RL（智能体强化学习）尤为重要。随着 RL 从单轮问答向多轮工具调用、环境交互演进，Rollout 过程变得越来越复杂、越来越异构，Server 模式是必然的技术方向。

7.3 TransferQueue：数据传输的再优化

单控制器架构下，控制器进程曾经是数据传输的中转站。在多模态、大 batch 场景下，这可能成为瓶颈。

TransferQueue 的设计目标就是将控制流与数据流彻底分离：

• 控制器只传递指令与元数据
• 实际张量数据通过 TransferQueue 直接在计算节点间传输

TransferQueue 针对 PyTorch 张量做了深度优化，支持零拷贝、RDMA 等高性能传输技术，并可扩展 ZeroMQ、NIXL 等多种后端。

7.4 异步训练范式

基于新架构，veRL 0.7 提供了三种训练范式选择：

1. 同步 On-policy：Rollout 与 Training 串行执行，严格遵循算法定义，适合基线实验
2. 单步离策略（One-step-off-policy）：当前步训练与下一步 Rollout 重叠执行，吞吐量提升 20%-40%，算法行为接近严格 on-policy
3. 全异步（Fully async）：Trainer 与 Roller 完全解耦到不同节点，通过队列流式传输数据，支持弹性扩缩容与故障容错，适合超大规模训练

不同范式对应不同的规模与需求，用户可根据场景灵活选择。

八、性能表现与技术优势

8.1 吞吐量提升

HybridFlow 论文在 EuroSys '25 上发表的实验数据展示了显著的性能优势。在同等硬件条件下，对比 DeepSpeed-Chat、OpenRLHF、NeMo-Aligner 等主流框架：

• PPO 算法：吞吐量提升 1.53× ~ 3.72×
• ReMax 算法：吞吐量提升 3.06× ~ 7.47×
• Safe-RLHF 算法：吞吐量提升最高达 20.57×

性能提升来自多个维度的优化叠加：

1. 3D-HybridEngine 消除了训练 - 生成切换的冗余
2. 自动映射算法找到了更优的资源分配方案
3. 高效的数据重分片协议减少了通信开销
4. 异步执行模式更好地利用了计算资源

8.2 核心技术优势总结

灵活性优势

• 算法与计算解耦，新算法开发周期从 "周" 级缩短到 "天" 级
• 多后端支持：FSDP、Megatron、vLLM 等无缝切换
• 部署模式灵活：共置 / 分离 / 混合部署自由配置

性能优势

• 3D-HybridEngine 零冗余参数切换
• 自动映射优化资源利用率
• 异步流水线隐藏计算延迟
• TransferQueue 消除数据传输瓶颈

工程优势

• 代码复用率高，维护成本低
• 单进程控制器易于调试
• 基于 Ray 的分布式底座，天然支持容错与弹性
• 完善的检查点与日志系统

九、快速搭建 RL 训练

9.1 环境准备

veRL 的安装相对简单，核心依赖包括 PyTorch、Ray、vLLM 等。以下是生产环境验证过的安装流程：

# 1. 安装 PyTorch（匹配 CUDA 版本）
pip3 install torch==2.4.0+cu124 torchvision==0.19.0+cu124 torchaudio==2.4.0+cu124 \
  --index-url https://download.pytorch.org/whl/cu124

# 2. 安装核心依赖
pip3 install flash-attn==2.5.9.post1 numpy==1.26.4 pandas==2.2.3 \
  peft==0.14.0 ray==2.42.1 transformers==4.47.1 vllm==0.5.4

# 3. 克隆并安装 verl
git clone https://github.com/volcengine/verl && cd verl
pip3 install -e .

9.2 启动 PPO 训练

使用官方提供的入口脚本，只需一条命令即可启动完整的 PPO 训练：

python3 -m verl.trainer.main_ppo \
  data.train_files=data/gsm8k/train.parquet \
  data.val_files=data/gsm8k/test.parquet \
  data.train_batch_size=256 \
  data.max_prompt_length=512 \
  data.max_response_length=256 \
  actor_rollout_ref.model.path=Qwen/Qwen2.5-0.5B-Instruct \
  actor_rollout_ref.actor.optim.lr=1e-6 \
  actor_rollout_ref.actor.ppo_mini_batch_size=64 \
  actor_rollout_ref.actor.ppo_micro_batch_size_per_gpu=4 \
  actor_rollout_ref.rollout.tensor_model_parallel_size=1 \
  actor_rollout_ref.rollout.gpu_memory_utilization=0.4 \
  critic.model.path=Qwen/Qwen2.5-0.5B-Instruct \
  critic.optim.lr=1e-5 \
  algorithm.kl_ctrl.kl_coef=0.001 \
  trainer.n_gpus_per_node=8 \
  trainer.total_epochs=50

9.3 自定义奖励函数

奖励函数是 RL 训练的核心。veRL 支持多种奖励形式：模型奖励、规则奖励、混合奖励。

以数学题为例，定义一个基于答案正确性的规则奖励函数：

def math_reward_fn(batch: DataProto) -> DataProto:
    """
    计算 GSM8K 数学题奖励
    正确答案得 1 分，错误得 0 分
    """
    responses = batch.batch["response"]
    answers = batch.batch["answer"]
    rewards = []
    
    for resp, ans in zip(responses, answers):
        # 从生成结果中提取数值答案
        pred = extract_number_from_response(resp)
        # 与正确答案比较
        correct = abs(pred - float(ans)) < 1e-3
        rewards.append(1.0 if correct else 0.0)
    
    # 返回 token-level 奖励（最后一个 token 位置给全量奖励）
    seq_len = responses.shape[1]
    reward_tensor = torch.zeros_like(responses, dtype=torch.float)
    for i, r in enumerate(rewards):
        reward_tensor[i, -1] = r
    
    batch.batch["reward"] = reward_tensor
    return batch

将奖励函数注册到 RewardManager 中即可参与训练。这种 "奖励即函数" 的设计大大降低了自定义奖励的门槛。

十、展望

根据官方路线图，veRL 的演进方向清晰且务实：

v0.8 版本将重点推进：

• 全面切换到新一代 Model Engine，淘汰旧版 Worker 实现
• TransferQueue 正式成为默认数据传输方式
• TensorRT-LLM 作为新的 Rollout 后端
• 支持 MTP（多轮对话）RL 训练
• 长上下文显存优化：细粒度激活重计算与卸载

v0.9 版本规划包括：

• 全异步训练架构合入主干
• 全模态模型 RL 训练支持（VLA、多模态）
• 更丰富的 Agentic RL 训练配方（SWEAgent、GUIAgent）
• 进一步完善的工具链与调试体验

从技术路线来看，veRL 正在从 "RLHF 训练框架" 向 "通用大模型强化学习平台" 演进，覆盖从单轮对齐到多轮智能体的完整谱系。

十一、总结

HybridFlow 架构的出现，为大模型强化学习训练的系统设计提供了全新的思路范式。它没有在 "单控" 与 "多控" 之间做非此即彼的选择，而是通过分层设计将两者的优势结合起来 —— 用单控制器保障算法编排的灵活性，用多控制器保障底层计算的高效率。

veRL 作为这一思想的工业级实现，通过精心设计的分层 API、3D-HybridEngine、自动映射等核心技术，成功解决了 RLHF 训练中的灵活性与性能矛盾。而 0.7 版本引入的 verl-core 四大组件、Server 模式 Rollout、TransferQueue 等演进，则进一步将框架推向了更通用、更高效、更可扩展的方向。

对于从事大模型对齐研究与工程的从业者而言，veRL 不仅是一个可用的工具，更是一份值得深入研读的系统设计范本。理解 HybridFlow 的架构思想，有助于我们在面对日益复杂的大模型训练场景时，做出更合理的技术选型与系统设计。

随着 RL 技术从简单的偏好对齐向复杂推理、智能体交互等更深层次发展，训练框架的系统重要性还将持续提升。veRL 所代表的 "分层解耦、混合控制" 的设计哲学，相信会在未来的大模型训练系统中得到更广泛的印证与应用。