1. 为什么值得花时间跑通 verl 这套强化学习训练框架第一次听到 verl 这个名字很多人会以为是某个新出的深度学习库其实它是一套专门为大模型强化学习后训练设计的训练框架。你如果最近在折腾 PPO、GRPO 这类算法又不想从零手写分布式采样和训练循环那 verl 基本就是绕不开的一个选择。它的定位很明确把强化学习里最烦人的那部分——rollout 生成、奖励计算、优势估计、策略更新——做成一套可配置、可扩展的流水线让你把精力放在算法和奖励设计上而不是耗在工程胶水里。我自己的使用场景很典型手头有一个 7B 级别的语言模型想用 GRPO 做一轮数学推理能力的后训练同时对比 PPO 的效果差异。如果纯手写光是处理多卡采样和训练之间的数据搬运就能耗掉一周。verl 的价值就在于它把 actor、critic、reward、reference 这几个角色拆成了独立的 worker通过一套混合并行的调度把采样和训练串起来你改算法只需要动对应的那几十行。这篇文章适合三类人看。第一类是想入门强化学习后训练但被工程复杂度劝退的算法同学第二类是有 PPO 理论基础、想找个能直接跑起来的框架做实验的研究者第三类是已经在用其他框架、想对比 verl 设计取舍的工程师。我会从整体设计思路讲到具体跑通的每一步包括我踩过的坑和参数选择的依据尽量让你照着做就能复现。需要提前说明的是verl 的迭代速度比较快不同版本之间配置项会有差异。我下面讲的内容基于我实际跑通的那套环境你在操作时如果遇到对不上的地方优先看官方仓库对应版本的示例配置不要硬套。2. 整体设计与思路拆解verl 到底把什么做成了流水线2.1 强化学习后训练的核心矛盾在哪要理解 verl 的设计得先搞清楚大模型强化学习后训练到底难在哪。传统的强化学习比如玩 Atari 或者机械臂控制环境是现成的状态转移由物理引擎或游戏模拟器给出。但大模型后训练不一样它的“环境”就是模型自己生成的文本奖励来自一个奖励模型或者规则函数。这就带来一个根本矛盾采样生成文本和训练更新参数用的是同一套权重但两者的计算特性完全不同。采样是自回归的、串行的、显存占用随序列长度线性增长训练是并行的、批量的、需要保存优化器状态和梯度。如果串行执行GPU 利用率会低得可怜——采样的时候训练卡闲着训练的时候采样卡闲着。verl 的核心思路就是把这俩阶段解耦用一套混合并行策略让采样和训练尽可能重叠同时保证权重同步的正确性。2.2 角色拆分actor、critic、reward、reference 各干什么verl 把整个训练流程拆成了几个独立的角色每个角色可以独立配置并行策略和资源。这个设计我觉得是它最值得学的地方。Actor 是策略模型负责生成 rollout 数据也是最终要被更新的模型。Critic 是价值模型只在 PPO 这类需要优势估计的算法里出现GRPO 不需要它。Reward 是奖励函数可以是一个模型也可以是一段规则代码。Reference 是参考模型用来算 KL 散度防止策略跑偏太远。为什么要拆这么细因为不同角色的计算量和显存需求差异巨大。比如 reward 模型可能只有 1B用一张卡就够actor 是 7B需要张量并行加流水并行critic 和 actor 同规模但只在训练阶段用。如果全塞在一起资源配置会非常别扭。verl 让你给每个角色单独指定并行度和资源池这就灵活多了。2.3 混合并行与权重同步的取舍verl 支持 FSDP、Megatron 等多种并行后端这是它区别于一些轻量框架的地方。FSDP 适合中小规模、快速实验Megatron 适合大规模、追求吞吐。我这次跑通用的是 FSDP因为 7B 模型在 8 卡 A100 上用 FSDP 已经够用配置也简单。权重同步是另一个关键点。采样用的 actor 和训练用的 actor 必须是同一套权重但采样完一轮后权重会更新下一轮采样前必须把新权重同步过去。verl 的做法是在每轮迭代开始时做一次权重广播把训练侧的参数同步到采样侧。这里有个细节如果采样和训练用的是不同的并行切分方式同步时需要做重切分verl 内部处理了这个逻辑但会带来一定的通信开销。我的经验是尽量让采样侧和训练侧的并行策略保持一致能省不少同步时间。注意权重同步的频率直接影响训练稳定性。同步太频繁通信开销大同步太少采样数据用的是旧策略重要性采样比会偏得厉害。一般建议每轮迭代同步一次不要跨轮累积。3. 核心细节解析与实操要点从环境到配置的每一步3.1 环境准备与依赖安装的坑verl 的依赖不算特别复杂但版本敏感度很高。我建议用 conda 建一个干净环境Python 版本选 3.10这是目前兼容性最好的。PyTorch 建议 2.1 以上因为 FSDP 的一些特性在旧版本上有 bug。安装步骤大致是这样先装 PyTorch 和 CUDA 对应版本然后装 flash-attn再装 verl 本身。flash-attn 是编译型的装的时候容易出问题我的经验是先把 CUDA 版本对齐然后设置MAX_JOBS环境变量控制编译并行度避免内存爆掉。conda create -n verl python3.10 -y conda activate verl pip install torch2.1.2 torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 pip install flash-attn --no-build-isolation cd verl pip install -e .这里有个坑pip install -e .会安装 verl 的依赖但如果你之前已经装过某些包的不同版本可能会冲突。我建议先pip install -e .让它自己解析依赖如果报错再手动补。另外如果你用的是 A100 或 H100记得确认 flash-attn 编译时用的 CUDA 架构包含你的卡不然运行时会报 kernel 不匹配。3.2 数据格式与奖励函数的设计verl 对训练数据的格式有要求一般是 JSONL每行一个样本包含 prompt 和可选的 ground truth。对于数学推理任务prompt 是题目ground truth 是答案。奖励函数需要你自己实现verl 提供了一些内置的奖励函数示例但实际用的时候基本都要改。我这次用的是规则奖励从模型输出里提取答案和 ground truth 比对对给 1 分错给 0 分格式不对给 -0.5 分。这个奖励设计看起来简单但有几个细节要注意。第一答案提取要鲁棒模型可能输出各种格式正则要写得宽容一点。第二格式惩罚的权重不能太大否则模型会学会只输出格式正确的废话。第三如果奖励全是 0 或全是 1优势估计会失效训练会停滞所以最好在数据里混一些难度适中的题。def reward_fn(prompts, responses, ground_truths): rewards [] for resp, gt in zip(responses, ground_truths): pred extract_answer(resp) if pred is None: rewards.append(-0.5) elif pred gt: rewards.append(1.0) else: rewards.append(0.0) return rewards提示奖励函数最好先在小批量数据上单独测一遍确认分数分布合理再接入训练。我见过有人奖励函数写错导致训练了半天模型在优化一个错误目标。3.3 并行策略与显存估算7B 模型用 FSDP 在 8 卡 A100 80G 上跑显存是够的但需要合理配置。Actor 训练时需要保存模型参数、梯度、优化器状态按混合精度算每卡大约需要 7B * (2 2 4) bytes ≈ 56GB加上激活值和通信缓冲80G 卡刚好够。如果显存紧张可以开梯度检查点代价是训练速度慢 20% 左右。采样阶段的显存需求和训练不同主要是 KV cache。序列长度 2048、batch size 64 的情况下KV cache 大约占 10GB 左右。verl 允许给采样和训练配置不同的 batch size我建议采样 batch 可以大一点训练 batch 小一点因为采样是吞吐瓶颈。角色并行方式每卡显存估算备注Actor 训练FSDP60-70GB开梯度检查点可降到 50GBActor 采样FSDP TP20-30GB主要开销在 KV cacheReward单卡10GB1B 模型足够ReferenceFSDP15GB只做前向显存需求低3.4 配置文件的关键参数解读verl 的配置是 YAML 格式参数很多但真正影响跑通的就那么几个。我挑几个重点说。train_batch_size和ppo_mini_batch_size的关系要搞清楚。前者是每轮迭代采样的总样本数后者是每次梯度更新用的小批量。如果train_batch_size1024ppo_mini_batch_size256那一轮迭代会做 4 次梯度更新。这个比例影响训练稳定性和速度太小会震荡太大收敛慢。rollout.n是每个 prompt 采样几条回复GRPO 一般设 4 到 8PPO 设 1 就行。这个参数直接决定采样开销设大了显存和时间都吃不消。kl_coef是 KL 惩罚系数控制策略偏离 reference 的程度。设太小模型会跑偏设太大模型学不动。我的经验是从 0.01 开始试观察 KL 散度的变化如果 KL 一直涨就调大如果 KL 接近 0 就调小。actor_rollout_ref: actor: ppo_mini_batch_size: 256 ppo_micro_batch_size: 16 rollout: n: 4 temperature: 0.7 top_p: 0.95 model: path: /path/to/your/model algorithm: kl_coef: 0.01 gamma: 1.0 lam: 0.954. 实操过程与核心环节实现从零到跑通一轮训练4.1 启动脚本与分布式配置verl 的启动一般用torchrun或者它自带的 launch 脚本。我习惯用torchrun因为配置直观。假设你有 8 张卡启动命令大概是这样torchrun --nproc_per_node8 --nnodes1 \ -m verl.trainer.main_ppo \ --config-pathconfigs \ --config-nameppo_grpo.yaml这里要注意nproc_per_node必须和你的实际卡数一致多了会报错少了浪费资源。另外如果你的机器有多张卡但想只用其中几张用CUDA_VISIBLE_DEVICES控制不要改nproc_per_node。启动后第一件事是看日志确认各个 worker 是否正常初始化。verl 会打印每个角色的并行配置和资源分配如果某个角色初始化失败日志里会有明显的报错。我遇到过 reward worker 因为模型路径写错而静默失败的情况结果训练跑起来了但奖励全是 0白白浪费了两小时。所以启动后先看奖励分布确认不是常数再继续。4.2 第一轮迭代发生了什么理解第一轮迭代的流程对排查问题很有帮助。verl 的一轮迭代大致分四个阶段。第一阶段是权重同步把训练侧的 actor 权重广播到采样侧。第二阶段是 rollout采样侧用当前策略生成回复同时 reward 模型打分。第三阶段是优势估计PPO 用 critic 算 GAEGRPO 用组内归一化。第四阶段是策略更新用算好的优势做梯度上升同时加 KL 惩罚。第一轮迭代有个特殊之处此时策略就是初始模型如果初始模型太弱采样出来的回复可能全是垃圾奖励全是 0优势估计就失效了。我的做法是在正式训练前先用初始模型跑一遍采样看看奖励分布。如果全是 0说明任务对初始模型太难要么换简单点的数据要么先做一轮 SFT 热启动。4.3 关键参数的计算与选择过程这里我详细说一下kl_coef和clip_range这两个参数怎么定。kl_coef的确定依赖观测。我的做法是先用一个较小的值跑 50 步记录每步的 KL 散度。如果 KL 散度在 0.1 到 1 之间缓慢增长说明系数合适如果 KL 迅速冲到 10 以上说明系数太小如果 KL 一直低于 0.01说明系数太大模型没学到东西。根据观测结果调整一般调两三次就能找到合适的值。clip_range是 PPO 的裁剪范围控制每次更新的幅度。默认 0.2 对大多数任务够用但如果你的奖励信号很稀疏可以适当调大到 0.3让模型更大胆地探索。反之如果训练不稳定调到 0.1 更保守。还有一个容易被忽略的参数是gamma和lam。对于语言模型后训练通常设gamma1.0因为每个 token 的奖励是累积的不需要折扣。lam控制 GAE 的偏差方差权衡0.95 是常用值如果奖励信号噪声大可以降到 0.9。4.4 训练过程中的监控指标跑起来之后你需要盯几个关键指标。第一个是奖励均值它应该随着训练缓慢上升如果一直平或者下降说明有问题。第二个是 KL 散度它应该稳定在一个合理范围突然飙升说明策略跑偏了。第三个是策略损失和价值损失它们应该震荡下降如果爆炸说明学习率太大。verl 默认用 wandb 或 tensorboard 记录我建议至少开一个。如果不想用外部工具也可以直接看 stdout 的日志verl 每步会打印这些指标。我自己的习惯是前 100 步盯着看确认趋势正常后再放手让它跑。指标正常范围异常表现可能原因奖励均值缓慢上升持平或下降奖励函数错误、学习率太小KL 散度0.1-1.0飙升到 10kl_coef 太小、学习率太大策略损失震荡下降爆炸或 NaN学习率太大、梯度裁剪失效采样长度稳定突然变短模型学会输出短回复骗奖励5. 常见问题与排查技巧实录我踩过的那些坑5.1 训练不收敛的排查思路训练不收敛是最常见的问题表现是奖励均值一直不涨。排查要按顺序来不要跳步。先查奖励函数。把 reward 的输出打出来看看分布是不是合理。如果全是同一个值那训练肯定不收敛因为优势全是 0。如果奖励有区分度但模型学不会那可能是任务太难或者学习率太小。再查数据。prompt 是不是太长导致截断ground truth 是不是有格式问题导致匹配不上我遇到过一次数据里的答案有全角半角混用导致匹配全失败奖励全是 0。这种问题只能靠仔细检查数据发现。最后查超参。学习率、kl_coef、clip_range 这三个是最常出问题的。我的建议是先用一组保守参数跑通确认流程没问题后再调优。保守参数是学习率 1e-6kl_coef 0.01clip_range 0.2。5.2 显存溢出与通信超时的处理显存溢出一般发生在两个地方采样时的 KV cache 和训练时的激活值。采样的显存溢出可以通过减小rollout.n或max_response_length解决。训练的显存溢出可以开梯度检查点或者减小ppo_micro_batch_size。通信超时在多机训练时更常见单机 8 卡一般不会。如果遇到先检查网络带宽和 NCCL 配置。一个常见的坑是NCCL_P2P_DISABLE和NCCL_IB_DISABLE这两个环境变量有些机器上需要设置才能正常通信。我的经验是先用 NCCL 自带的测试工具跑一遍确认通信正常再启动训练。注意显存溢出有时不是真的不够而是碎片化导致的。PyTorch 的缓存分配器在长时间运行后会产生碎片设置PYTORCH_CUDA_ALLOC_CONFmax_split_size_mb:128可以缓解。5.3 奖励黑客与策略坍塌的识别奖励黑客是指模型学会了骗奖励而不是真正完成任务。比如奖励函数看答案匹配模型就学会输出一堆可能答案碰运气。识别方法是看采样输出如果输出变得很奇怪但奖励很高基本就是奖励黑客了。策略坍塌是指模型输出变得单一多样性消失。表现是采样出来的回复几乎一样KL 散度很低。这通常是因为 kl_coef 太大或者训练太久。解决办法是调小 kl_coef或者在奖励里加多样性惩罚。这两个问题的根源都是奖励设计不够鲁棒。我的经验是奖励函数要尽量稠密不要只给最终答案打分中间步骤也可以给分。另外定期人工检查采样输出不要只看指标。5.4 常见问题速查表问题现象排查方向解决方法奖励全 0奖励均值恒为 0奖励函数、数据格式打印奖励分布检查匹配逻辑KL 飙升KL 散度突然增大kl_coef、学习率调大 kl_coef调小学习率显存溢出OOM 报错batch size、序列长度减小 batch开梯度检查点通信超时NCCL timeout网络配置、环境变量检查 NCCL 设置测试带宽输出单一采样回复雷同kl_coef、训练轮数调小 kl_coef加多样性惩罚训练太慢每步耗时过长并行策略、batch 配置调整并行度优化 batch 比例6. 从跑通到跑好一些进阶的调优经验6.1 学习率调度与 warmup 的配合verl 默认的学习率是常数但实际用的时候加 warmup 和衰减会稳很多。warmup 的作用是让模型在训练初期不要更新太猛避免一开始就跑偏。我的配置是 warmup 50 步然后余弦衰减到初始值的 0.1。这个配置不是拍脑袋定的。warmup 步数一般取总步数的 5% 到 10%太少起不到稳定作用太多浪费训练时间。衰减策略里余弦衰减比线性衰减更平滑适合大多数场景。如果你发现训练后期奖励还在涨可以不用衰减保持常数学习率。6.2 参考模型的更新策略Reference 模型一般是冻结的初始模型但有些场景下需要更新。比如做多轮迭代训练时如果 reference 一直不变KL 惩罚会越来越强模型学不动。这时候可以定期把 actor 的权重同步给 reference相当于让 reference 跟着走。这个操作要谨慎因为 reference 一变KL 惩罚的基准就变了训练动态会突变。我的建议是只在必要时做而且同步后要观察一段时间确认训练稳定再继续。同步频率不要太高一般每几百步一次就够了。6.3 多任务与多奖励的平衡实际项目中经常需要同时优化多个目标比如既要答案对又要格式好还要输出简洁。这时候奖励函数就是多个分量的加权和。权重的确定是个技术活我的做法是先单独跑每个分量看模型能学到什么程度然后再组合。组合的时候要注意量纲。如果答案奖励是 0 到 1格式奖励是 0 到 10那格式会主导训练。解决办法是归一化让每个分量都在相近的范围。另外权重不要设得太极端一般主目标权重 1.0辅助目标 0.1 到 0.3 就够了。6.4 实验记录与可复现性强化学习实验的随机性很大同样的配置跑两次结果可能差很多。所以实验记录特别重要。我建议每次实验都记录完整的配置文件、启动命令、环境版本、随机种子、以及训练曲线。verl 支持设置随机种子但要注意即使设了种子多卡训练的随机性也无法完全消除因为通信顺序会影响浮点运算结果。所以不要指望完全复现能复现趋势就不错了。我的做法是每个配置跑三次取平均这样结论更可靠。最后分享一个我自己的小习惯每次改配置只改一个参数其他保持不变。这样出了问题能快速定位是哪个参数导致的。一次改多个参数虽然可能碰巧跑通但出了问题根本不知道是哪个引起的反而浪费时间。强化学习调参本来就是个体力活稳扎稳打比激进试错效率更高。
verl强化学习训练框架实战：从PPO到GRPO的7B模型后训练指南
1. 为什么值得花时间跑通 verl 这套强化学习训练框架第一次听到 verl 这个名字很多人会以为是某个新出的深度学习库其实它是一套专门为大模型强化学习后训练设计的训练框架。你如果最近在折腾 PPO、GRPO 这类算法又不想从零手写分布式采样和训练循环那 verl 基本就是绕不开的一个选择。它的定位很明确把强化学习里最烦人的那部分——rollout 生成、奖励计算、优势估计、策略更新——做成一套可配置、可扩展的流水线让你把精力放在算法和奖励设计上而不是耗在工程胶水里。我自己的使用场景很典型手头有一个 7B 级别的语言模型想用 GRPO 做一轮数学推理能力的后训练同时对比 PPO 的效果差异。如果纯手写光是处理多卡采样和训练之间的数据搬运就能耗掉一周。verl 的价值就在于它把 actor、critic、reward、reference 这几个角色拆成了独立的 worker通过一套混合并行的调度把采样和训练串起来你改算法只需要动对应的那几十行。这篇文章适合三类人看。第一类是想入门强化学习后训练但被工程复杂度劝退的算法同学第二类是有 PPO 理论基础、想找个能直接跑起来的框架做实验的研究者第三类是已经在用其他框架、想对比 verl 设计取舍的工程师。我会从整体设计思路讲到具体跑通的每一步包括我踩过的坑和参数选择的依据尽量让你照着做就能复现。需要提前说明的是verl 的迭代速度比较快不同版本之间配置项会有差异。我下面讲的内容基于我实际跑通的那套环境你在操作时如果遇到对不上的地方优先看官方仓库对应版本的示例配置不要硬套。2. 整体设计与思路拆解verl 到底把什么做成了流水线2.1 强化学习后训练的核心矛盾在哪要理解 verl 的设计得先搞清楚大模型强化学习后训练到底难在哪。传统的强化学习比如玩 Atari 或者机械臂控制环境是现成的状态转移由物理引擎或游戏模拟器给出。但大模型后训练不一样它的“环境”就是模型自己生成的文本奖励来自一个奖励模型或者规则函数。这就带来一个根本矛盾采样生成文本和训练更新参数用的是同一套权重但两者的计算特性完全不同。采样是自回归的、串行的、显存占用随序列长度线性增长训练是并行的、批量的、需要保存优化器状态和梯度。如果串行执行GPU 利用率会低得可怜——采样的时候训练卡闲着训练的时候采样卡闲着。verl 的核心思路就是把这俩阶段解耦用一套混合并行策略让采样和训练尽可能重叠同时保证权重同步的正确性。2.2 角色拆分actor、critic、reward、reference 各干什么verl 把整个训练流程拆成了几个独立的角色每个角色可以独立配置并行策略和资源。这个设计我觉得是它最值得学的地方。Actor 是策略模型负责生成 rollout 数据也是最终要被更新的模型。Critic 是价值模型只在 PPO 这类需要优势估计的算法里出现GRPO 不需要它。Reward 是奖励函数可以是一个模型也可以是一段规则代码。Reference 是参考模型用来算 KL 散度防止策略跑偏太远。为什么要拆这么细因为不同角色的计算量和显存需求差异巨大。比如 reward 模型可能只有 1B用一张卡就够actor 是 7B需要张量并行加流水并行critic 和 actor 同规模但只在训练阶段用。如果全塞在一起资源配置会非常别扭。verl 让你给每个角色单独指定并行度和资源池这就灵活多了。2.3 混合并行与权重同步的取舍verl 支持 FSDP、Megatron 等多种并行后端这是它区别于一些轻量框架的地方。FSDP 适合中小规模、快速实验Megatron 适合大规模、追求吞吐。我这次跑通用的是 FSDP因为 7B 模型在 8 卡 A100 上用 FSDP 已经够用配置也简单。权重同步是另一个关键点。采样用的 actor 和训练用的 actor 必须是同一套权重但采样完一轮后权重会更新下一轮采样前必须把新权重同步过去。verl 的做法是在每轮迭代开始时做一次权重广播把训练侧的参数同步到采样侧。这里有个细节如果采样和训练用的是不同的并行切分方式同步时需要做重切分verl 内部处理了这个逻辑但会带来一定的通信开销。我的经验是尽量让采样侧和训练侧的并行策略保持一致能省不少同步时间。注意权重同步的频率直接影响训练稳定性。同步太频繁通信开销大同步太少采样数据用的是旧策略重要性采样比会偏得厉害。一般建议每轮迭代同步一次不要跨轮累积。3. 核心细节解析与实操要点从环境到配置的每一步3.1 环境准备与依赖安装的坑verl 的依赖不算特别复杂但版本敏感度很高。我建议用 conda 建一个干净环境Python 版本选 3.10这是目前兼容性最好的。PyTorch 建议 2.1 以上因为 FSDP 的一些特性在旧版本上有 bug。安装步骤大致是这样先装 PyTorch 和 CUDA 对应版本然后装 flash-attn再装 verl 本身。flash-attn 是编译型的装的时候容易出问题我的经验是先把 CUDA 版本对齐然后设置MAX_JOBS环境变量控制编译并行度避免内存爆掉。conda create -n verl python3.10 -y conda activate verl pip install torch2.1.2 torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 pip install flash-attn --no-build-isolation cd verl pip install -e .这里有个坑pip install -e .会安装 verl 的依赖但如果你之前已经装过某些包的不同版本可能会冲突。我建议先pip install -e .让它自己解析依赖如果报错再手动补。另外如果你用的是 A100 或 H100记得确认 flash-attn 编译时用的 CUDA 架构包含你的卡不然运行时会报 kernel 不匹配。3.2 数据格式与奖励函数的设计verl 对训练数据的格式有要求一般是 JSONL每行一个样本包含 prompt 和可选的 ground truth。对于数学推理任务prompt 是题目ground truth 是答案。奖励函数需要你自己实现verl 提供了一些内置的奖励函数示例但实际用的时候基本都要改。我这次用的是规则奖励从模型输出里提取答案和 ground truth 比对对给 1 分错给 0 分格式不对给 -0.5 分。这个奖励设计看起来简单但有几个细节要注意。第一答案提取要鲁棒模型可能输出各种格式正则要写得宽容一点。第二格式惩罚的权重不能太大否则模型会学会只输出格式正确的废话。第三如果奖励全是 0 或全是 1优势估计会失效训练会停滞所以最好在数据里混一些难度适中的题。def reward_fn(prompts, responses, ground_truths): rewards [] for resp, gt in zip(responses, ground_truths): pred extract_answer(resp) if pred is None: rewards.append(-0.5) elif pred gt: rewards.append(1.0) else: rewards.append(0.0) return rewards提示奖励函数最好先在小批量数据上单独测一遍确认分数分布合理再接入训练。我见过有人奖励函数写错导致训练了半天模型在优化一个错误目标。3.3 并行策略与显存估算7B 模型用 FSDP 在 8 卡 A100 80G 上跑显存是够的但需要合理配置。Actor 训练时需要保存模型参数、梯度、优化器状态按混合精度算每卡大约需要 7B * (2 2 4) bytes ≈ 56GB加上激活值和通信缓冲80G 卡刚好够。如果显存紧张可以开梯度检查点代价是训练速度慢 20% 左右。采样阶段的显存需求和训练不同主要是 KV cache。序列长度 2048、batch size 64 的情况下KV cache 大约占 10GB 左右。verl 允许给采样和训练配置不同的 batch size我建议采样 batch 可以大一点训练 batch 小一点因为采样是吞吐瓶颈。角色并行方式每卡显存估算备注Actor 训练FSDP60-70GB开梯度检查点可降到 50GBActor 采样FSDP TP20-30GB主要开销在 KV cacheReward单卡10GB1B 模型足够ReferenceFSDP15GB只做前向显存需求低3.4 配置文件的关键参数解读verl 的配置是 YAML 格式参数很多但真正影响跑通的就那么几个。我挑几个重点说。train_batch_size和ppo_mini_batch_size的关系要搞清楚。前者是每轮迭代采样的总样本数后者是每次梯度更新用的小批量。如果train_batch_size1024ppo_mini_batch_size256那一轮迭代会做 4 次梯度更新。这个比例影响训练稳定性和速度太小会震荡太大收敛慢。rollout.n是每个 prompt 采样几条回复GRPO 一般设 4 到 8PPO 设 1 就行。这个参数直接决定采样开销设大了显存和时间都吃不消。kl_coef是 KL 惩罚系数控制策略偏离 reference 的程度。设太小模型会跑偏设太大模型学不动。我的经验是从 0.01 开始试观察 KL 散度的变化如果 KL 一直涨就调大如果 KL 接近 0 就调小。actor_rollout_ref: actor: ppo_mini_batch_size: 256 ppo_micro_batch_size: 16 rollout: n: 4 temperature: 0.7 top_p: 0.95 model: path: /path/to/your/model algorithm: kl_coef: 0.01 gamma: 1.0 lam: 0.954. 实操过程与核心环节实现从零到跑通一轮训练4.1 启动脚本与分布式配置verl 的启动一般用torchrun或者它自带的 launch 脚本。我习惯用torchrun因为配置直观。假设你有 8 张卡启动命令大概是这样torchrun --nproc_per_node8 --nnodes1 \ -m verl.trainer.main_ppo \ --config-pathconfigs \ --config-nameppo_grpo.yaml这里要注意nproc_per_node必须和你的实际卡数一致多了会报错少了浪费资源。另外如果你的机器有多张卡但想只用其中几张用CUDA_VISIBLE_DEVICES控制不要改nproc_per_node。启动后第一件事是看日志确认各个 worker 是否正常初始化。verl 会打印每个角色的并行配置和资源分配如果某个角色初始化失败日志里会有明显的报错。我遇到过 reward worker 因为模型路径写错而静默失败的情况结果训练跑起来了但奖励全是 0白白浪费了两小时。所以启动后先看奖励分布确认不是常数再继续。4.2 第一轮迭代发生了什么理解第一轮迭代的流程对排查问题很有帮助。verl 的一轮迭代大致分四个阶段。第一阶段是权重同步把训练侧的 actor 权重广播到采样侧。第二阶段是 rollout采样侧用当前策略生成回复同时 reward 模型打分。第三阶段是优势估计PPO 用 critic 算 GAEGRPO 用组内归一化。第四阶段是策略更新用算好的优势做梯度上升同时加 KL 惩罚。第一轮迭代有个特殊之处此时策略就是初始模型如果初始模型太弱采样出来的回复可能全是垃圾奖励全是 0优势估计就失效了。我的做法是在正式训练前先用初始模型跑一遍采样看看奖励分布。如果全是 0说明任务对初始模型太难要么换简单点的数据要么先做一轮 SFT 热启动。4.3 关键参数的计算与选择过程这里我详细说一下kl_coef和clip_range这两个参数怎么定。kl_coef的确定依赖观测。我的做法是先用一个较小的值跑 50 步记录每步的 KL 散度。如果 KL 散度在 0.1 到 1 之间缓慢增长说明系数合适如果 KL 迅速冲到 10 以上说明系数太小如果 KL 一直低于 0.01说明系数太大模型没学到东西。根据观测结果调整一般调两三次就能找到合适的值。clip_range是 PPO 的裁剪范围控制每次更新的幅度。默认 0.2 对大多数任务够用但如果你的奖励信号很稀疏可以适当调大到 0.3让模型更大胆地探索。反之如果训练不稳定调到 0.1 更保守。还有一个容易被忽略的参数是gamma和lam。对于语言模型后训练通常设gamma1.0因为每个 token 的奖励是累积的不需要折扣。lam控制 GAE 的偏差方差权衡0.95 是常用值如果奖励信号噪声大可以降到 0.9。4.4 训练过程中的监控指标跑起来之后你需要盯几个关键指标。第一个是奖励均值它应该随着训练缓慢上升如果一直平或者下降说明有问题。第二个是 KL 散度它应该稳定在一个合理范围突然飙升说明策略跑偏了。第三个是策略损失和价值损失它们应该震荡下降如果爆炸说明学习率太大。verl 默认用 wandb 或 tensorboard 记录我建议至少开一个。如果不想用外部工具也可以直接看 stdout 的日志verl 每步会打印这些指标。我自己的习惯是前 100 步盯着看确认趋势正常后再放手让它跑。指标正常范围异常表现可能原因奖励均值缓慢上升持平或下降奖励函数错误、学习率太小KL 散度0.1-1.0飙升到 10kl_coef 太小、学习率太大策略损失震荡下降爆炸或 NaN学习率太大、梯度裁剪失效采样长度稳定突然变短模型学会输出短回复骗奖励5. 常见问题与排查技巧实录我踩过的那些坑5.1 训练不收敛的排查思路训练不收敛是最常见的问题表现是奖励均值一直不涨。排查要按顺序来不要跳步。先查奖励函数。把 reward 的输出打出来看看分布是不是合理。如果全是同一个值那训练肯定不收敛因为优势全是 0。如果奖励有区分度但模型学不会那可能是任务太难或者学习率太小。再查数据。prompt 是不是太长导致截断ground truth 是不是有格式问题导致匹配不上我遇到过一次数据里的答案有全角半角混用导致匹配全失败奖励全是 0。这种问题只能靠仔细检查数据发现。最后查超参。学习率、kl_coef、clip_range 这三个是最常出问题的。我的建议是先用一组保守参数跑通确认流程没问题后再调优。保守参数是学习率 1e-6kl_coef 0.01clip_range 0.2。5.2 显存溢出与通信超时的处理显存溢出一般发生在两个地方采样时的 KV cache 和训练时的激活值。采样的显存溢出可以通过减小rollout.n或max_response_length解决。训练的显存溢出可以开梯度检查点或者减小ppo_micro_batch_size。通信超时在多机训练时更常见单机 8 卡一般不会。如果遇到先检查网络带宽和 NCCL 配置。一个常见的坑是NCCL_P2P_DISABLE和NCCL_IB_DISABLE这两个环境变量有些机器上需要设置才能正常通信。我的经验是先用 NCCL 自带的测试工具跑一遍确认通信正常再启动训练。注意显存溢出有时不是真的不够而是碎片化导致的。PyTorch 的缓存分配器在长时间运行后会产生碎片设置PYTORCH_CUDA_ALLOC_CONFmax_split_size_mb:128可以缓解。5.3 奖励黑客与策略坍塌的识别奖励黑客是指模型学会了骗奖励而不是真正完成任务。比如奖励函数看答案匹配模型就学会输出一堆可能答案碰运气。识别方法是看采样输出如果输出变得很奇怪但奖励很高基本就是奖励黑客了。策略坍塌是指模型输出变得单一多样性消失。表现是采样出来的回复几乎一样KL 散度很低。这通常是因为 kl_coef 太大或者训练太久。解决办法是调小 kl_coef或者在奖励里加多样性惩罚。这两个问题的根源都是奖励设计不够鲁棒。我的经验是奖励函数要尽量稠密不要只给最终答案打分中间步骤也可以给分。另外定期人工检查采样输出不要只看指标。5.4 常见问题速查表问题现象排查方向解决方法奖励全 0奖励均值恒为 0奖励函数、数据格式打印奖励分布检查匹配逻辑KL 飙升KL 散度突然增大kl_coef、学习率调大 kl_coef调小学习率显存溢出OOM 报错batch size、序列长度减小 batch开梯度检查点通信超时NCCL timeout网络配置、环境变量检查 NCCL 设置测试带宽输出单一采样回复雷同kl_coef、训练轮数调小 kl_coef加多样性惩罚训练太慢每步耗时过长并行策略、batch 配置调整并行度优化 batch 比例6. 从跑通到跑好一些进阶的调优经验6.1 学习率调度与 warmup 的配合verl 默认的学习率是常数但实际用的时候加 warmup 和衰减会稳很多。warmup 的作用是让模型在训练初期不要更新太猛避免一开始就跑偏。我的配置是 warmup 50 步然后余弦衰减到初始值的 0.1。这个配置不是拍脑袋定的。warmup 步数一般取总步数的 5% 到 10%太少起不到稳定作用太多浪费训练时间。衰减策略里余弦衰减比线性衰减更平滑适合大多数场景。如果你发现训练后期奖励还在涨可以不用衰减保持常数学习率。6.2 参考模型的更新策略Reference 模型一般是冻结的初始模型但有些场景下需要更新。比如做多轮迭代训练时如果 reference 一直不变KL 惩罚会越来越强模型学不动。这时候可以定期把 actor 的权重同步给 reference相当于让 reference 跟着走。这个操作要谨慎因为 reference 一变KL 惩罚的基准就变了训练动态会突变。我的建议是只在必要时做而且同步后要观察一段时间确认训练稳定再继续。同步频率不要太高一般每几百步一次就够了。6.3 多任务与多奖励的平衡实际项目中经常需要同时优化多个目标比如既要答案对又要格式好还要输出简洁。这时候奖励函数就是多个分量的加权和。权重的确定是个技术活我的做法是先单独跑每个分量看模型能学到什么程度然后再组合。组合的时候要注意量纲。如果答案奖励是 0 到 1格式奖励是 0 到 10那格式会主导训练。解决办法是归一化让每个分量都在相近的范围。另外权重不要设得太极端一般主目标权重 1.0辅助目标 0.1 到 0.3 就够了。6.4 实验记录与可复现性强化学习实验的随机性很大同样的配置跑两次结果可能差很多。所以实验记录特别重要。我建议每次实验都记录完整的配置文件、启动命令、环境版本、随机种子、以及训练曲线。verl 支持设置随机种子但要注意即使设了种子多卡训练的随机性也无法完全消除因为通信顺序会影响浮点运算结果。所以不要指望完全复现能复现趋势就不错了。我的做法是每个配置跑三次取平均这样结论更可靠。最后分享一个我自己的小习惯每次改配置只改一个参数其他保持不变。这样出了问题能快速定位是哪个参数导致的。一次改多个参数虽然可能碰巧跑通但出了问题根本不知道是哪个引起的反而浪费时间。强化学习调参本来就是个体力活稳扎稳打比激进试错效率更高。
