项目背景与定位

1.1 一句话定位

verl（Volcano Engine Reinforcement Learning）是字节跳动火山引擎团队 2024 年开源、2026 年迁移到独立 verl-project 组织维护的、面向大模型的高性能、灵活、可扩展的强化学习训练框架。它的核心理论支撑是字节同时发布的 HybridFlow 论文（NeurIPS 2024）：通过把 "单线程的 controller" 和 "多进程的 worker" 解耦，把 RLHF 的算法逻辑写成"看起来像单进程脚本，但跑起来是分布式"的样子。

verl 已经被字节内部用于 Doubao、Skylark 等模型的 RLHF 训练，也是开源社区里和 OpenRLHF 并列的"大规模 RLHF"事实选项。R1 风格的"长思考链 GRPO"训练有不少团队就是基于 verl 做的。

1.2 为什么会有 verl

字节做 RLHF 遇到的问题和 OpenRLHF 类似，但他们的回答方式有差异：

• OpenRLHF 的方案："用 Ray 编排 vLLM + DeepSpeed + reward 模型"——好处是直观，缺点是用户要懂 Ray Actor 模型才能改算法；
• verl/HybridFlow 的方案：把 RL 算法的"控制流"从分布式里抽出来。控制流跑在单进程上（看起来是普通 Python 代码），数据流通过一组高性能 worker 自动并行。

论文里给的例子大致是：

output  = actor.generate(prompts)
rewards = reward_model.compute(output)
actor.train(output, rewards)

看起来就是顺序执行，但 verl 在背后自动把这些调用调度到不同的 worker group 上、自动做数据并行、自动管理通信。这种抽象在大规模 RL 训练里非常有价值——算法工程师和系统工程师可以解耦，互不打扰。

1.3 它的"三个核心抽象"

调度逻辑：ResourcePool 提供 GPU；WorkerGroup 在 ResourcePool 上跑；Controller 调用 WorkerGroup 上的方法，背后是 Ray 远程调用。可以做"actor 用 8 卡 ZeRO-3、reward 用 2 卡、rollout 用 4 卡 vLLM"的精细调度。

1.4 它和 OpenRLHF / TRL 的对比

1.5 设计哲学：算法 / 系统解耦 + Megatron 友好

• 算法工程师看到的是"顺序代码"：在 verl/trainer/ppo/ray_trainer.py 里能看到 PPO 主循环几乎就像单机版本；
• 系统工程师维护的是 worker 实现：在 verl/workers/actor/ 等目录下，每种角色都是一个 worker 实现；
• Megatron 后端是 first-class：verl 是少有的开源 RLHF 框架里 Megatron 是真的能用、性能优化做了不少功夫的；
• 配置是 Hydra：所有参数走 YAML + override，结构化、易复现。

代价：抽象层多，初学者难以一眼看清调用栈；对 Hydra / Ray 不熟悉时调试复杂度高；版本迭代快，0.1 / 0.2 之间 API 变化不少。

1.6 它适合用来做什么、不适合做什么

1.7 本书将怎么带你走完这趟旅程

• 第 2-3 章装环境、跑通单机 GRPO；
• 第 4 章讲透 Controller / WorkerGroup / ResourcePool 三大抽象；
• 第 5 章完整剖析 HybridFlow 架构，给一张端到端时序图；
• 第 6-7 章训练后端（FSDP / Megatron）+ 采样后端（vLLM / SGLang）的接入；
• 第 8 章Hydra 配置怎么写；
• 第 9 章算法对比 PPO / GRPO / DAPO 等；
• 第 10 章怎么自定义算法 / reward；
• 第 11-12 章性能调优 + 长思考链 GRPO 案例；
• 第 13 章源码导读。

1.8 verl 在 2025–2026 引入了什么

verl 的演进速度比 DeepSpeed / Megatron-LM 都更激进。下表按时间倒序，列出本书基线 commit 9c38b8bb1876（2026-05-26）当时已经在 master 的关键节点——每个都有源码可查、本书有对应小节：

结论：verl 的版本基线每隔 3-6 个月会带来一次能力跃迁。读这本书时，重点把 ch04–ch09 这条主线吃透，新特性都建立在那套抽象上。