核心观点 - 强化学习在LLM开发中占比增大，训练效率成为关键变量，Batch Size是影响效率的核心参数 [2][3][4] - 腾讯混元团队提出通过先建立Batch Size Invariance（样本效率）再优化吞吐（系统效率）的两步法，可缩短训练时间29% [60][62] 强化学习规模化与效率 - 预训练将大模型带到新起点，强化学习通过持续探索与反馈决定模型能走多远 [2] - RL在模型开发中占比越大，训练效率对算力预算影响越直接 [3] - 以1万张GPU连续运行30天为例，每卡每小时3美元，总费用2160万美元，缩短10%训练时间可节省72万GPU小时约216万美元 [3] Batch Size的两类决策 - 适度增大Batch并同步调整学习率可提高吞吐，但Batch过大时额外样本代价会压过吞吐收益 [5] - 腾讯混元团队将Batch Size放回训练动力学与硬件执行共同约束中，从第一性原理重新审视规模化规律 [8] - Batch Size Tuning：模型变大或GPU卡型变化时，需找到稳定学习且高效使用硬件的Batch与配套超参数 [9] - Batch Size Scaling：更多GPU时同步扩大Batch，或利用闲置能力通过更大Batch提高利用率 [9] 经典Batch Scaling到LLM强化学习 - 2017年Facebook团队通过线性放大学习率和gradual warmup，将ResNet-50训练从8张GPU Batch 256约29小时扩展到256张GPU Batch 8192时1小时 [11] - 2018年OpenAI团队研究扩大Batch收益递减转折点，与梯度噪声尺度联系起来 [12] - LLM强化学习特殊之处：模型既是生产训练数据的推理系统，也是消费数据的学习系统 [13][14] - 生成阶段是自回归推理，训练阶段在整批token上执行前向反向传播，扩大Batch对两者影响不同 [15] 衡量标准：Time-to-target - 最终目标不是把Batch开到最大，而是让模型尽早达到要求能力水平，用Time-to-target衡量 [17] - 达标速度由样本效率（每条回答带来多少学习进展）和系统效率（每秒生成并处理多少回答）共同决定 [18][26] - 公式：达标时间 = 达标所需回答数 / 端到端吞吐 [19] - 只有当吞吐收益超过达标样本数增幅时，更大Batch才会缩短训练时间 [27] 发现一：GRPO在16倍prompt batch范围内近似不变 - 在Qwen3-30B-A3B-Instruct-2507上，G=8时，P=64至P=1024呈现相似样本级学习曲线，P=2048和P=4096偏离 [29] - 近似不变范围内actor梯度范数大致按特定规律下降，偏离时下降变缓 [30] 发现二：PPO中actor和critic尺度不同 - PPO实验采用内部混元策略模型和价值模型，均为3B激活参数 [33] - Batch 256-2048样本级学习曲线近似对齐，Batch 4096偏离 [33] - actor梯度范数随Batch增大持续下降，critic梯度范数相对平坦波动更大，两者有效Batch尺度可能不同 [33] 发现三：GRPO的Batch更应看总回答数 - 总回答数相同的配置呈现大致相似学习轨迹，如(P,G)=(128,8)与(64,16)都使用1024条回答 [36] - 总回答Batch相同时actor梯度范数相近，2048条回答的gradient norm始终比1024条更小 [36] - 支持用总回答数作为GRPO的Batch单位，但不能认为prompt数和group size在任意设定下可互换 [36] 发现四：保持学习率不变会破坏近似不变性 - 以P=128为参考，P=256调整学习率后大Batch跟随参考曲线，固定学习率运行明显落后 [40] - 累计约12万条回答时，固定学习率配置约74%，参考和调整后约77% [40] - 学习率调整后达标更新数为参考的0.50-0.67倍，固定学习率需0.75-0.83倍更新，对应1.50-1.67倍样本消耗 [40] - 训练稳定不代表Batch Size Invariance成立 [38][41] 发现五：固定硬件上生成耗时呈次线性增长 - PPO中训练Batch从256增加到1024，回答数增长4倍，收集时间从39秒增加到68秒，生成吞吐提高2.29倍 [47] - GRPO中P从128增加到256时生成吞吐提高1.31倍，增加到512时提高1.36倍，收益趋于饱和 [47] - 生成阶段受权重读取和内存带宽限制，更大Batch让更多token分摊权重读取开销 [50][51] - 训练阶段耗时近似随Batch线性增长，如GRPO中prompt batch从128翻倍到256，actor更新时间从101.3秒增长到208.6秒 [50] 两个Critical Batch - Critical generation batch：生成吞吐接近平台的位置，标记系统效率边界 [49] - Critical training batch：近似Batch Size Invariance的上界，标记样本效率边界 [52] - 两个边界回答不同问题：生成侧还有多少硬件吞吐可挖掘，训练侧还能否保持每条回答学习效果 [53] - 最终目标是最小化time-to-target，不是机械选择某一个critical batch [54] 实测结果 - 学习率调整后，P从128增加到512和1024，归一化time-to-target分别降至0.74倍和0.71倍 [60] - P=1024时，模型用122.88K条保留回答达到目标，端到端吞吐提高41%，训练时间从11.90小时下降到8.42小时，缩短29% [60] - P=2048和P=4096时，达标回答数增加约60%，超过30%和36%的吞吐收益，训练时间升至1.23倍和1.18倍 [61] - P=256保持学习率不变，吞吐只提高17%，达标回答数增加67%，训练时间变为1.42倍 [61] 调优框架 - 先调整学习率并估计达标样本代价，再寻找生成并发带来的端到端吞吐收益，最后按达标时间选择配置 [63] - 对每个候选训练Batch调整学习率，比较相同累计回答数下的学习曲线 [68] - 在显存允许范围内调整生成Batch或解码并发，测量端到端吞吐 [68] - 最终按达标时间选择配置，确认它能更早达到目标 [68] 意义和边界 - 理论认识：把Batch能变大和不能一直变大的问题拆开，学习率Scaling可在一定范围内维持近似不变性但最终失效 [65] - 训练实践：先确认学得好再想办法跑得快，换模型任务或硬件后复用调优顺序但不能照搬Batch数值 [66] - 系统设计：生成Batch与训练Batch不一定要同步扩大，解耦并合理安排GPU分工可能进一步释放吞吐 [67] - 评估方式：不同Batch必须放在同一起跑线上比较，先对齐学习效果再比较系统收益 [68][69] - 当模型、奖励、任务分布、训练阶段、推理引擎或执行策略变化时，已测有效Batch范围不能直接照搬 [69] - PPO实验提示actor和critic可能需要不同Batch尺度 [69]