核心内容摘要
综述不会写？10个AI论文软件测评：本科生毕业论文写作神器推荐
一文搞懂verl核心机制batch size不再令人纠结在大型语言模型LLM的强化学习后训练中batch size从来不是简单的“一次喂多少数据”——它是一张纵横交错的调度网络牵动着GPU资源分配、序列生成数量、梯度更新粒度、通信开销与内存占用。
当你看到data.train_batch_size
rollout.n
ppo_mini_batch_size
log_prob_micro_batch_size_per_gpu8这些参数并列出现时困惑是合理的它们到底谁管谁谁先被计算谁最终决定显存是否爆掉本文不堆砌公式不复述论文而是带你穿透 verl 源码逻辑从ray_trainer.py的fit()入口出发经由ActorRolloutRefWorker的初始化与generate_sequences流程最终落到每一张 GPU 上真实处理的数据量。
你会清晰看到所有 batch 相关参数如何被动态归一化normalizerollout 阶段为何从 60 条 prompt 变成 720 条 completionactor、rollout、ref 三类 worker 如何按不同规则切分 batchFSDP tensor parallelism 如何协同决定每个 GPU 的实际负载读完这篇你将彻底告别“改一个参数就报错”“调完 batch 显存还是炸”的被动调试状态真正掌握 verl 的 batch 调度心法。
先说结论verl 中的 batch 不是单一概念而是四层嵌套结构在 verl 中batch size 不是一个标量而是一个由训练目标驱动、受硬件约束、经多级归一化后落地到 GPU 的四层结构。
我们用一句话概括其本质data.train_batch_size是用户视角的“每步处理多少条原始 prompt”而最终落在每张 GPU 上的micro_batch_size是由rollout.n、tensor_model_parallel_size、world_size和ulysses_sequence_parallel_size共同解耦、缩放、再分配的结果。
这四层结构如下由外到内层级名称决定者典型值示例物理含义L1data.train_batch_size用户配置60每个训练 step 从 dataloader 加载的 prompt 数量即“原始批次大小”L2rollout.n×data.train_batch_size算法设计GRPO/PPO60 × 12 720经 rollout 后生成的 total sequence 数量含重复采样是后续所有计算的输入基数L3ppo_mini_batch_size归一化后FSDP 分片逻辑720 ÷ 6 120每个 FSDP shard通常 ≈ 每张 GPU需参与梯度更新的 sequence 数L4log_prob_micro_batch_size_per_gpu推理/打分阶段内存控制8每张 GPU 在 compute_log_prob 阶段一次最多处理多少条 sequence用于防 OOM这四层不是并列关系而是因果链L1 → L2算法展开→ L3FSDP 归一化→ L4推理微批控制。
下面我们将逐层拆解全部基于 verl 主干代码ray_trainer.py、fsdp_workers.py的真实逻辑。
第一层data.train_batch_size—— 你的起点但不是终点这是你在ppo_trainer.yaml里最先看到的参数data.train_batch_size: 60 trainer.n_gpus_per_node: 6 trainer.nnodes: 1它代表每个训练 step从训练数据集中取出 60 条 prompt送入整个 RL 流水线。
注意两个硬约束data.train_batch_size必须能被trainer.n_gpus_per_node整除此处60 ÷ 6 10合法它只是“输入起点”不等于任何模型实际处理的数据量——actor 不会用它直接生成文本ref 不会用它直接打分critic 更不会用它计算 value。
它的真正作用是作为 rollout 阶段的种子基数。
接下来rollout.n将把它放大。
第二层rollout.n—— 算法展开的关键乘数从 60 到 720 的跃迁在 GRPO或 PPO中“rollout”指用当前 actor 模型对每个 prompt 进行多次采样生成多个 completion用于后续 reward 计算与优势估计。
这个“多次”就是rollout.n配置项为actor_rollout_ref.rollout.n: 12这意味着对每一条 promptactor 会生成 12 个不同的 completion。
所以60 条 prompt × 12 次采样 720 条完整的 (prompt, completion) 序列。
这个 720是 verl 整个训练循环中最关键的中间 batch size。
它出现在ray_trainer.py的generate_sequences调用后# gen_batch shape: torch.Size([60, 8192]) ← L1: 60 条 prompt gen_batch_output self.actor_rollout_wg.generate_sequences(gen_batch) # gen_batch_output.batch[prompt_token_ids].shape: torch.Size([720, 8192]) ← L2: 720 条 completion这 720 条数据将作为后续所有计算的输入old_log_prob计算 actor 对这 720 条 completion 的 token-level log probabilityref_log_prob计算 reference policy 对这 720 条 completion 的 log probabilityreward_fn对这 720 条 completion 执行规则打分GRPO或调用 RMPPOcompute_advantage基于 reward 计算这 720 条序列的 advantage。
但请注意720 是全局总量不是单卡负载。
下一步FSDP 会把它切分。
第三层ppo_mini_batch_size的归一化 —— FSDP 如何把 720 分给 6 张 GPUppo_mini_batch_size出现在 actor 配置中actor_rollout_ref.actor.ppo_mini_batch_size: 60初看容易误解为“每次更新用 60 条数据”但 verl 的设计哲学是这个值必须经过归一化normalization才能成为真正的 per-GPU mini-batch size。
归一化逻辑在fsdp_workers.py的ActorRolloutRefWorker.__init__()中if self._is_actor: # Step 1: 先乘 rollout.n → 60 × 12 720 self.config.actor.ppo_mini_batch_size * self.config.rollout.n # Step 2: 再除以有效分片数 → 720 ÷ (world_size // ulysses_sequence_parallel_size) shard self.device_mesh.size() // self.ulysses_sequence_parallel_size # 6 // 1 6 self.config.actor.ppo_mini_batch_size // shard # 720 // 6 120结果ppo_mini_batch_size从配置的60变成运行时的120。
这个120的含义是每张 GPU 在 actor 梯度更新阶段负责处理 120 条 sequence 的 forward/backward。
为什么是 120因为总共 720 条 sequenceL2 结果全局有 6 张 GPUworld_size 6当前未启用 sequence parallelismulysses_sequence_parallel_size 1所以每张 GPU 是一个独立 FSDP shard因此720 ÷ 6 120 条/卡。
这个120就是 FSDP 实际执行optimizer.step()时的 batch size。
它决定了梯度累积步数若gradient_accumulation_steps 1则120是累积后的总 batch显存中激活值activations的峰值占用通信量all-reduce 梯度的大小。
关键洞察ppo_mini_batch_size的配置值本身不重要重要的是它乘rollout.n后能否被world_size整除。
如果60 × 12 720不能被 6 整除比如rollout.n13verl 会在assert中直接报错强制你调整配置。
第四层log_prob_micro_batch_size_per_gpu—— 推理阶段的“安全阀”前三层都关乎训练吞吐与梯度更新但还有一个关键阶段计算 log probability即compute_log_prob。
无论是 actor 的old_log_prob还是 ref 的ref_log_prob都需要对 720 条 completion 做一次前向传播输出每个 token 的 log prob。
这个过程不更新参数但显存压力极大——因为要缓存所有中间激活用于后续 KL 计算或 reward 构建。
为此verl 引入了log_prob_micro_batch_size_per_gpu配置项为actor_rollout_ref.rollout.log_prob_micro_batch_size_per_gpu: 8 actor_rollout_ref.ref.log_prob_micro_batch_size_per_gpu: 8它的作用非常直白每张 GPU 每次只处理 8 条 sequence算完一批再加载下一批。
这个值在fsdp_workers.py中被归一化虽然本例中8 ÷ 6 ≈
33向下取整为1但更重要的是它被硬编码进compute_log_prob的循环逻辑中作为 micro-batch 的上限。
你可以把它理解为 verl 的“内存安全阀”如果设为8则 720 条数据会被切成720 ÷ 8 90个 micro-batch每卡处理90 ÷ 6 15个 micro-batch如果设为1则变成 720 个 micro-batch通信开销增大但单次显存最低如果设为720理论上则单卡一次性加载全部 720 条大概率 OOM。
所以log_prob_micro_batch_size_per_gpu是唯一一个你可以在不改模型、不调 world_size 的前提下快速缓解显存 OOM 的参数。
它不改变训练数学只改变内存使用节奏。
rollout worker 的并行策略为什么需要tensor_model_parallel_size2前面我们假设world_size 6全部用于 FSDP 数据并行DP但 verl 支持更细粒度的并行——尤其是在 rollout 阶段。
看这个配置actor_rollout_ref.rollout.tensor_model_parallel_size: 2它意味着每 2 张 GPU 组成一个 tensor parallelismTP组共同完成一个 vLLM inference engine 的推理任务。
在ActorRolloutRefWorker._build_rollout()中verl 构建了一个二维 device meshdp self.world_size // infer_tp # 6 // 2 3 rollout_device_mesh init_device_mesh(cuda, mesh_shape(dp, infer_tp), ...) # DeviceMesh(cuda, [[0, 1], [2, 3], [4, 5]], mesh_dim_names(dp, infer_tp))这表示全局 6 张 GPU 被划分为 3 个 DP groupdp3每组 2 张卡infer_tp2每个 DP group 内部2 张卡通过 TP 协同运行一个 vLLM enginedata.train_batch_size60条 prompt被均分到 3 个 DP group即每个 group 处理 20 条 prompt每个 group 内2 张卡 TP 合作对这 20 条 prompt 同时做n12次 rollout → 输出20 × 12 240条 completion最终3 个 group 汇总 →3 × 240 720条。
这种设计的好处是vLLM 的 TP 优化得以复用大模型推理在 TP 下更高效rollout 阶段通信最小化TP 组内通信高速 NVLinkDP 组间只需汇
总结果低频 all-gather负载均衡60 条 prompt 被严格均分避免某张卡空转。
提示tensor_model_parallel_size与ulysses_sequence_parallel_size是正交的。
前者用于 rollout 推理vLLM后者用于 actor 训练FSDP Ulysses SP。
不要混淆。
实战验证从配置到每张卡的实际负载我们用一个完整配置收束全文验证所有层级# yaml 配置 data.train_batch_size: 60 trainer.n_gpus_per_node: 6 trainer.nnodes: 1 actor_rollout_ref.rollout.n: 12 actor_rollout_ref.rollout.tensor_model_parallel_size: 2 actor_rollout_ref.actor.ppo_mini_batch_size: 60 actor_rollout_ref.rollout.log_prob_micro_batch_size_per_gpu: 8 actor_rollout_ref.ref.log_prob_micro_batch_size_per_gpu: 8 actor_rollout_ref.actor.ulysses_sequence_parallel_size: 1推导每张 GPU 的实际负载阶段计算逻辑每卡数量说明Input promptdata.train_batch_size ÷ (n_gpus_per_node × nnodes) × tensor_model_parallel_size60 ÷ 6 × 2 20每个 TP group 处理 20 条 prompt因 TP2需 2 卡协作Rollout output20 × rollout.n 20 × 12240每个 TP group 输出 240 条 completionGlobal rollout total240 × dp_groups 240 × 3720全局汇总Actor update batch720 ÷ world_size 720 ÷ 6120每卡在 FSDP 更新中处理 120 条 sequenceLog prob micro-batchlog_prob_micro_batch_size_per_gpu8每卡每次只加载 8 条 sequence 计算 log prob这就是 verl 的 batch 调度全景图从用户配置的60到最终每卡120的更新 batch 和8的推理 micro-batch所有数字都有迹可循、有码可查。
8.
常见问题速查你遇到的报错根源在这里现象根本原因解决方案ppo_mini_batch_size should be larger than 0 after normalizationdata.train_batch_size × rollout.n无法被world_size整除调整rollout.n或data.train_batch_size确保乘积可被 GPU 数整除CUDA out of memoryincompute_log_problog_prob_micro_batch_size_per_gpu设得太大优先调小此值如从8→4→2这是最快速的 OOM 缓解手段rollout 阶段 GPU 利用率不均衡tensor_model_parallel_size与world_size不匹配如world_size5,tp2确保world_size % tensor_model_parallel_size 0否则 DP group 数非整数gen_batch_outputshape 不符预期如不是 720rollout.n未生效可能被更高优先级配置覆盖检查启动脚本是否传入--config.actor_rollout_ref.rollout.n12yaml 中的值可能被覆盖记住verl 的 batch 体系是强约束、可验证、有日志的。
所有归一化步骤都在fsdp_workers.py的__init__中打印assert和print运行时加-v参数即可看到每一步的数值变化。
9.
总结掌握 batch就是掌握 verl 的调度主权verl 不是一个“黑盒框架”它的 batch 设计是透明、分层、可推导的。
本文带你走完了从配置到源码、从宏观到微观的完整链条data.train_batch_size是你的指挥棒但它只指挥 rollout 的起点rollout.n是算法杠杆把 60 条 prompt 放大为 720 条数据奠定训练基础ppo_mini_batch_size的归一化是 FSDP 的智慧让 720 条数据公平、高效地分给每张 GPUlog_prob_micro_batch_size_per_gpu是内存守门员在不牺牲数学的前提下保障稳定性tensor_model_parallel_size是 rollout 的加速器用 vLLM 的 TP 优势榨干 GPU 算力。
你不需要死记硬背所有参数只需要记住这个心法看 batch先问“这是哪一层的 batch”——是输入层L
算法层L
FSDP 层L3还是内存层L4然后顺藤摸瓜找到它在fsdp_workers.py中被归一化、被使用的那一行代码。
从此batch size 不再令人纠结而是你手中可预测、可调试、可优化的确定性工具。