引言随着大语言模型LLM技术的飞速发展强化学习与人类反馈RLHF已成为模型对齐的核心技术路径。从 ChatGPT 到 o1RL 算法在提升模型推理能力、对齐人类偏好方面展现出不可替代的价值。然而当模型规模从数十亿参数增长到数千亿甚至万亿参数时传统强化学习框架在系统设计层面遭遇了前所未有的挑战。传统 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 整体架构由三大核心组件构成混合编程模型Hybrid Programming Model提供分层 API 体系解耦控制流与计算流支持灵活表达各类 RLHF 数据流3D-HybridEngine专为 Actor 模型设计实现训练与生成阶段不同并行策略间的零冗余高效切换自动映射算法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_PROTO3D 并行训练的典型场景输出仅存在于最后流水线阶段且在 DP 组间复制DP_PROTO纯数据并行模式ONE_TO_ALL广播式数据分发如模型初始化3D_ALL_MICRO_DPHybridEngine 专用处理训练与推理切换时的微 DP 组3D_PP_ONLY仅流水线并行维度检查ALL_TO_ALL全交换模式多用于调试以 Actor 生成数据传递给 Critic 为例数据流向如下控制器调用 Actor 的generate_sequences方法Actor 各 DP 分片并行执行生成通过 3D_PROTO 的 collect 函数汇总生成结果控制器将数据 futures 传递给 CriticCritic 通过自身 3D_PROTO 的 distribute 函数将数据分发到对应分片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 采用双缓冲区机制管理权重训练缓冲区buffer_train常驻 GPU 显存保存训练阶段的参数分片生成缓冲区buffer_gen可在 GPU/CPU 间换入换出完整的单次迭代流程如下训练结束后通过 NCCL 集合通信在 Micro DP 组内聚合参数构建生成阶段权重生成阶段使用 buffer_gen 执行自回归生成同时 buffer_train 仍保留在 GPU 中生成结束后将生成权重与 KV Cache 卸载到 CPU 内存下一训练阶段直接使用 buffer_train 中的参数进行训练这种设计既保障了训练阶段的显存效率又通过 CPU 卸载避免了生成权重占用宝贵的 GPU 显存。对于多轮对话场景KV Cache 的卸载与重载机制也得到了相应支持。四、Auto-Mapping自动设备映射算法4.1 问题的复杂性RLHF 训练涉及多个模型角色如何将它们部署到 GPU 集群上是一个复杂的组合优化问题。以经典 PPO 为例涉及 Actor、Critic、Reference、Reward 四个模型可能的部署方案多达 15 种集合划分问题—— 从全部共置到完全分离各种组合各有利弊。共置部署共享 GPU 资源节省设备但模型串行执行且对单卡显存要求高分离部署模型可并行执行延迟低但资源利用率低、设备需求大此外每个模型在不同阶段还可以选择不同的并行策略。人工试错寻找最优配置不仅耗时而且往往难以找到全局最优解。4.2 算法设计思路Auto-Mapping 算法的目标是给定 RLHF 数据流图、模型配置与集群规模自动找出最优的设备部署方案与并行策略组合最小化单轮迭代的端到端延迟。算法采用枚举 仿真的两阶段思路枚举部署方案遍历所有可能的模型共置 / 分离组合即集合划分计算最小显存需求对每种部署方案计算每个共置组所需的最少 GPU 数量以容纳所有模型枚举设备分配从最小分配开始逐步增加 GPU 数量探索所有可行分配自动并行策略搜索对给定的设备数与模型通过性能仿真器寻找最优并行配置端到端延迟估算基于数据流图计算整轮迭代的总延迟选择全局最优在所有方案中选出延迟最小的映射方案算法内置了训练、推理、生成三类性能仿真器能够基于模型架构、并行策略、硬件规格较为准确地预估执行延迟。虽然枚举方案数量随模型数指数增长但 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 核心入口RayPPOTrainerverl/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_modeDispatch.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 的设计解决了两个关键问题统一接口所有 Worker 方法输入输出格式一致便于组合与复用分片友好内置按 batch 维度拆分与拼接的方法适配数据并行分发在 v0.7 版本中veRL 正逐步用 PyTorch 的 TensorDict 替代 DataProto以获得更好的性能与生态兼容性。5.5 ActorRolloutRefWorker高度复用的设计一个特别能体现 veRL 设计巧思的地方是ActorRolloutRefWorker。这个单一 Worker 类通过配置可以扮演多种角色配置方式角色仅启用 actor纯 Actor 训练 Worker仅启用 rollout纯 Rollout 推理 Worker同时启用 actorrolloutHybridEngine训练生成一体化同时启用 actorrolloutref三者共置LoRA 场景下效率最高六、算法生态从 PPO 到 GRPO6.1 PPO经典算法的工程化实现PPOProximal Policy Optimization是 RLHF 的基石算法也是 veRL 支持最完善的算法。veRL 的 PPO 实现遵循标准算法流程Rollout 阶段Actor 根据 prompt 生成 response评估阶段计算旧策略 log_prob、参考策略 log_prob、价值估计、奖励值优势估计默认使用 GAE广义优势估计更新阶段Actor 和 Critic 分别使用 PPO Clip 损失更新在工程层面veRL 做了大量优化支持 micro batch 梯度累积适配大 batch 训练支持多 epoch 训练同一批数据序列长度均衡seqlen balancing减少 padding 浪费支持 token-level 与 sequence-level 两种损失聚合模式6.2 GRPO无需 Critic 的简化方案GRPOGroup 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 # 损失聚合方式由于去除了 CriticGRPO 的显存需求显著降低训练也更稳定。在数学推理等任务上GRPO 往往能以更少的资源达到媲美甚至超越 PPO 的效果。6.3 更多算法支持除了 PPO 和 GRPOveRL 还在持续扩展算法生态DAPO动态优势策略优化改进优势估计方式CISPO裁剪重要性采样策略优化SAPO软自适应策略优化ReMax基于奖励的简单高效 RL 方法Safe-RLHF带安全约束的 RLHF得益于 HybridFlow 的灵活架构新增算法通常只需在控制器层面修改数据流向与损失计算无需改动底层计算引擎代码。这使得 veRL 的算法迭代速度远超传统框架。七、veRL 0.7新一代架构演进7.1 verl-core四大核心组件2026 年初发布的 veRL 0.7 版本标志着架构的重大升级。新版本将核心能力抽象为 verl-core 层提供四大可插拔组件Model Engine模型引擎统一的训练引擎抽象支持 FSDP、Megatron-Core、VeOmni 等多种后端Rollout Engine生成引擎统一的推理生成抽象默认采用 Server 模式支持 vLLM、SGLang、TensorRT-LLMCheckpoint Engine检查点引擎跨后端权重同步抽象支持 NCCL、NIXL 等传输后端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 提供了三种训练范式选择同步 On-policyRollout 与 Training 串行执行严格遵循算法定义适合基线实验单步离策略One-step-off-policy当前步训练与下一步 Rollout 重叠执行吞吐量提升 20%-40%算法行为接近严格 on-policy全异步Fully asyncTrainer 与 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×性能提升来自多个维度的优化叠加3D-HybridEngine 消除了训练 - 生成切换的冗余自动映射算法找到了更优的资源分配方案高效的数据重分片协议减少了通信开销异步执行模式更好地利用了计算资源8.2 核心技术优势总结灵活性优势算法与计算解耦新算法开发周期从 周 级缩短到 天 级多后端支持FSDP、Megatron、vLLM 等无缝切换部署模式灵活共置 / 分离 / 混合部署自由配置性能优势3D-HybridEngine 零冗余参数切换自动映射优化资源利用率异步流水线隐藏计算延迟TransferQueue 消除数据传输瓶颈工程优势代码复用率高维护成本低单进程控制器易于调试基于 Ray 的分布式底座天然支持容错与弹性完善的检查点与日志系统九、快速搭建 RL 训练9.1 环境准备veRL 的安装相对简单核心依赖包括 PyTorch、Ray、vLLM 等。以下是生产环境验证过的安装流程# 1. 安装 PyTorch匹配 CUDA 版本 pip3 install torch2.4.0cu124 torchvision0.19.0cu124 torchaudio2.4.0cu124 \ --index-url https://download.pytorch.org/whl/cu124 # 2. 安装核心依赖 pip3 install flash-attn2.5.9.post1 numpy1.26.4 pandas2.2.3 \ peft0.14.0 ray2.42.1 transformers4.47.1 vllm0.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_filesdata/gsm8k/train.parquet \ data.val_filesdata/gsm8k/test.parquet \ data.train_batch_size256 \ data.max_prompt_length512 \ data.max_response_length256 \ actor_rollout_ref.model.pathQwen/Qwen2.5-0.5B-Instruct \ actor_rollout_ref.actor.optim.lr1e-6 \ actor_rollout_ref.actor.ppo_mini_batch_size64 \ actor_rollout_ref.actor.ppo_micro_batch_size_per_gpu4 \ actor_rollout_ref.rollout.tensor_model_parallel_size1 \ actor_rollout_ref.rollout.gpu_memory_utilization0.4 \ critic.model.pathQwen/Qwen2.5-0.5B-Instruct \ critic.optim.lr1e-5 \ algorithm.kl_ctrl.kl_coef0.001 \ trainer.n_gpus_per_node8 \ trainer.total_epochs509.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, dtypetorch.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 所代表的 分层解耦、混合控制 的设计哲学相信会在未来的大模型训练系统中得到更广泛的印证与应用。