VeRL框架学习

VeRL是字节跳动seed团队和香港大学开发的强化学习仓库。该框架采用混合编程模型，融合单控制器（Single-Controller）的灵活性和多控制器（Multi-Controller）的高效性，可更好实现和执行多种RL算法，显著提升训练吞吐量，降低开发和维护复杂度.

VeRL的关键创新1:实现接口与实现分离对用户暴露单一控制面（single-controller）以保证使用与调试的简单性；在每个子模块内部采用 multi-controller / SPMD 实现以利用高速互联（NVLink/InfiniBand）做点对点参数与激活传输。
VeRL 的关键创新2是 hybrid engine：把 actor model 的 training engine和 rollout engine（高效推理 engine）放在同一资源组里串行运行，通过在两个阶段之间回收 / 释放显存（offload 或析构）来共享同一组 GPU 资源，避免 rollout 与 training 在不同资源组间相互闲置导致的巨大资源浪费。与传统的 collocate（把不同子模块拼 colocate）策略不同，hybrid 明确把关注点放在 actor 的 training ↔ rollout 共享上，因而在中等规模资源下能显著提升 GPU 利用率，代价是更复杂的 reshard/parameter transfer 与更高的 OOM 风险。

VERL流程细节

Train

Trainer 是整个 RLHF/PPO 流程的总调度者，也就是 single controller。它不直接做大规模矩阵计算，而是负责组织训练步骤：先准备 prompt，再调用 actor 的 rollout 接口生成 response，再调用 critic、reward、reference 等接口补齐 values、reward、logprobs，最后再调用 actor/critic 的更新接口完成一次 PPO 迭代。single-controller 设计的重点，不是让一个进程亲自算所有东西，而是让“训练逻辑写在一个地方”，这样研究者写算法时看到的是清晰的一条主流程，而不是到处 scattered 的多控制器逻辑。veRL 文档专门说明，single_controller 模块的目标就是把复杂的多 Ray actor 调用隐藏起来，让上层以统一接口驱动分布式执行

Worker的创建

verl建立了一个ActorRolloutRefWorker，里面初始化时会先根据 role 决定自己是不是 actor、是不是 rollout、是不是 ref。

_is_actor = role in ["actor", "actor_rollout", "actor_rollout_ref"]
_is_rollout = role in ["rollout", "actor_rollout", "actor_rollout_ref"]
_is_ref = role in ["ref", "actor_rollout_ref"]

然后在 init_model() 里，如果这个 worker 同时带 actor 和 rollout，它会把两套东西都建起来：
训练侧：FSDP 包起来的 actor 模型、optimizer、lr scheduler，并进一步封装成 DataParallelPPOActor
推理侧：_build_rollout()` 构建 rollout engine，文档写明默认是 vLLMRollout。

CriticWorker 负责 value 网络；reward worker 负责 RM 打分。

Worker Group的创建

一个 WorkerGroup 本身不一定持有模型参数，但它管理一组远程 worker，并把 worker 暴露的方法绑定成 group 级别的方法。于是，上层 trainer 调的不是某一张 GPU 上某一个 worker，而是类似 actor_rollout_wg.generate_sequences()、critic_wg.compute_values() 这种 group API。调用发出去之后，WorkerGroup 决定数据怎么分发、发给哪些 worker、最后怎么把结果收回来。官方文档明确写到：WorkerGroup 的作用就是管理一组 remote workers，并提供统一接口来做多进程分布式计算。

具体流程

Trainer 先构造好各个 WorkerGroup，例如 actor-rollout-reference 一组、critic 一组、reward 一组。然后 trainer 调 init_model()，这些调用通过 WorkerGroup 下发到每个远程 worker，让每个 worker 初始化自己的底层模型。以 ActorRolloutRefWorker 为例，它暴露给 controller 的核心接口通常包括 init_model、generate_sequences、compute_log_prob、compute_ref_log_prob、save_checkpoint 等。也就是说，从 controller 的视角，它看到的是一组远程 API；从 worker 的视角，它实际内部会去构建 FSDP/Megatron 训练模型、vLLM rollout 引擎等具体对象。

然后进入一轮 RL 训练。上层 trainer 首先调用 actor/rollout 相关 WorkerGroup 的 generate_sequences()。这个调用不是 trainer 自己生成，而是发到 rollout worker 上，由底层 rollout engine 产生 response。若启用了 hybrid engine/colocate，worker 内部可能先做一次模式切换：把训练态的资源适当 offload，把 rollout 需要的权重和 cache 准备好，再真正执行生成。生成结束后，trainer 再把 prompt + response 发给 reference worker 去算 ref_log_prob，发给 actor worker 去算 old_log_prob，发给 critic worker 去算 values，发给 reward worker 去算 reward。这样，一条 response 会被不同角色补全成 PPO 所需的完整 experience。官方文档把这类接口分工写得很清楚：generate_sequences 负责生成，compute_log_prob 负责 actor 概率，compute_ref_log_prob 负责参考策略概率。

等 experience 准备好以后，trainer 再调用 update_actor() 和 update_critic() 之类的更新接口。这里 single controller 的优势就体现出来了：算法逻辑仍然是先 rollout，再评估，再更新这一条线性流程；至于每一步背后有多少 GPU、多少进程、多少通信，都是 WorkerGroup 和 Worker 去处理。换句话说，veRL 把“算法控制流”放在 controller，把“并行执行流”放在 workers。官方 API 文档对 Single Controller 的描述也是：它提供统一接口来管理分布式 workers，并执行跨 workers 的函数调用，从而简化任务分发和结果收集。