Meta ScaleRL:40 萬 B200 GPU 小時(shí),讓 RL 擁有“可預(yù)測 Scaling Law”
一、背景
之前已經(jīng)介紹了一些了 RL 訓(xùn)練優(yōu)化的文章,它們往往針對(duì)特定場景或特定算法進(jìn)行優(yōu)化,而缺乏一些系統(tǒng)性的研究。正好看到 Meta 的 ScaleRL,其對(duì)各種策略、技術(shù)進(jìn)行了比較全面的消融實(shí)驗(yàn),并提供了最佳實(shí)踐,我們這里對(duì)其進(jìn)行簡單介紹。
對(duì)應(yīng)的論文:[2510.13786] The Art of Scaling Reinforcement Learning Compute for LLMs [1]
二、摘要
RL 已成為 LLM 的核心技術(shù),但是該領(lǐng)域還缺乏與預(yù)訓(xùn)練相媲美的可預(yù)測 Scaling Law。為此,作者進(jìn)行了大規(guī)模系統(tǒng)性研究(累積 40 萬 B200 GPU 小時(shí)),建立了 RL 的 Scaling Law。通過擬合 RL 訓(xùn)練的 S 型計(jì)算-性能曲線,以及一系列消融實(shí)驗(yàn),揭示了以下規(guī)律:
- 不同訓(xùn)練方案具有不同的性能上限。
- 損失聚合、優(yōu)勢歸一化、Off-Policy 等算法主要影響計(jì)算效率,不會(huì)顯著改善性能上限。
- 穩(wěn)定可擴(kuò)展的方案遵循可預(yù)測的擴(kuò)展軌跡,支持基于小規(guī)模實(shí)驗(yàn)的外推預(yù)測。
基于這些發(fā)現(xiàn),作者提出最佳實(shí)踐方案 ScaleRL,并通過單次 RL 訓(xùn)練擴(kuò)展到 10 萬 GPU 小時(shí)的實(shí)驗(yàn),成功實(shí)現(xiàn)驗(yàn)證下的精確預(yù)測。
三、關(guān)鍵發(fā)現(xiàn)與理論框架
通過 400,000 GPU 小時(shí)(NVIDIA GB200)的系統(tǒng)實(shí)驗(yàn),總結(jié)出 RL 訓(xùn)練性能與計(jì)算量之間呈 Sigmoid 型關(guān)系,并提供如下的擬合公式,對(duì)應(yīng)曲線如下圖 Figure 3 所示,其中:
- A:RL 訓(xùn)練的性能(效果)上限(Asymptotic Reward)。
- B:計(jì)算效率(Scaling Exponent),反映性能隨計(jì)算增長的加速程度。
- Cmid:達(dá)到一半性能所需的計(jì)算量。


上述的預(yù)測與預(yù)訓(xùn)練場景有較大不同:
- 在預(yù)訓(xùn)練的 Scaling Law 中,模型參數(shù)量、數(shù)據(jù)量、算力(FLOPs)之間遵循近似冪律關(guān)系,也就是說,增加固定倍數(shù)的計(jì)算量,性能(效果/損失)會(huì)以固定比例改善。其呈現(xiàn)單調(diào)提升(或下降)的關(guān)系,并沒有明顯飽和點(diǎn),只是會(huì)逐漸變慢。
- 在 RL 的 Scaling Law 中,RL 的收益更像是飽和曲線:初期增長慢,中期快速提升,后期趨于穩(wěn)定。當(dāng)然,在中低區(qū)間擬合出參數(shù)后,可以預(yù)測更大規(guī)模 RL 的結(jié)果。
四、三大經(jīng)驗(yàn)準(zhǔn)則(Scaling Principle)
4.1 RL 性能上限(A)并不普適
不同的算法、Loss、Batch Size 都會(huì)有各自的性能天花板。如下圖所示為幾個(gè)示例:
- a:不同的 Loss 函數(shù),分別為 CISPO、GSPO 和 DAPO。DAPO 早期可能收斂更快,但是上限可能較低,而 CISPO 收斂更慢,但是上限更高。
- b:0-Variance 過濾,藍(lán)色 batch 表示不過濾 0 梯度樣本;橙色 effec_batch 表示 [2504.13914] Seed1.5-Thinking: Advancing Superb Reasoning Models with Reinforcement Learning [2] Dynamic Sampling,而不是 DAPO([2503.14476] DAPO: An Open-Source LLM Reinforcement Learning System at Scale [3]) 的 Dynamic Sampling。
標(biāo)準(zhǔn) batch:Batch Size 為包含 Response 全對(duì)或全錯(cuò)的情況。
Seed1.5-Thinking:Batch Size 不包含 Response 全對(duì)或全錯(cuò)的情況,也就是 Batch Size 會(huì)小于 DataLoader 的設(shè)置。
DAPO:去除 Response 全對(duì)或全錯(cuò)的情況后,繼續(xù) Rollout,直到 Batch Size 滿足要求。
- c:不同的 Batch Size。Batch Size 為 2048 時(shí),雖然前期收斂較慢,但是上限 A 更高。

4.2 “苦澀的教訓(xùn)(the Bitter Lesson)”仍然適用
在有限計(jì)算資源下表現(xiàn)好的算法,在大規(guī)模計(jì)算場景中可能反而表現(xiàn)更差;因此應(yīng)基于早期 scaling 曲線的參數(shù)(A, B)預(yù)測長期表現(xiàn)。如下圖 Figure 2 所示,Magistral 在早期收斂比較快,優(yōu)于 MiniMax,但是隨著計(jì)算規(guī)模增加,MiniMax 的性能上限(A)更高。

4.3 常見技巧主要影響效率(B)而不是性能上限(A)
普遍任務(wù)能提升峰值性能(A)的手段(比如 loss aggregation, data curriculum, length penalty, advantage normalization)主要影響計(jì)算效率(B),而不會(huì)顯著改善性能上限(A)。如下圖 Figure 14 所示:
- a(Loss Aggregation):如下圖 Figure 14a 所示,Prompt Avg 和 Token Avg 性能上限差不多,略優(yōu)于 Sample Avg。本文的 ScaleRL?選擇了性能最優(yōu)的 Prompt Avg。
Prompt Avg:每個(gè) Prompt 等權(quán)重貢獻(xiàn)。不管每個(gè) Prompt 生成多少 Response,從 Prompt 維度是等權(quán)重的。
Sample Avg:每個(gè)軌跡(Prompt 生成 Response)等權(quán)重貢獻(xiàn)。
Token Avg:直接對(duì) Batch 中所有 Token 損失求平均值,無需中間分組。
- b(Advantage Normalization):如下圖 Figure 14b 所示,no-norm、batch-lvl-norm、prompt-lvl-norm 的性能上限差距不大。本文的 ScaleRL 選擇了性能最優(yōu)的 Batch-level normalization。
non-norm:不做歸一化。參考 Dr.GRPO,直接以 Prompt 生成結(jié)果的 Reward 均值對(duì)原始 Reward 進(jìn)行中心化處理,不進(jìn)行方差縮放。
batch-lvl-norm:參考 [2501.03262] REINFORCE++: An Efficient RLHF Algorithm with Robustness to Both Prompt and Reward Models [4] 等,通過 Batch 內(nèi)所有生成結(jié)果的標(biāo)準(zhǔn)差進(jìn)行歸一化。
prompt-lvl-norm:參考 GRPO,根據(jù)同一 Prompt 生成結(jié)果中 Reward 的標(biāo)準(zhǔn)差進(jìn)行 Advantage 歸一化。

五、ScaleRL 最佳實(shí)踐組合
5.1 異步訓(xùn)練策略
異步 Off-Policy 對(duì) RL 訓(xùn)練的效率和穩(wěn)定性至關(guān)重要,并且通常與其他設(shè)計(jì)決策正交,因此作者首先對(duì)其影響進(jìn)行了評(píng)估。主要評(píng)估了:
- PPO-Off-Policy-k:在 Qwen3 和 ProRL 采用,舊 Policy πθold 為 B 個(gè) Prompt 生成 Response 軌跡,然后將其分成 k 個(gè) mini-batch,每次使用一個(gè) mini-batch 進(jìn)行 Training(Policy 更新)。作者實(shí)驗(yàn)中,mini-batch 為 48,k 為 [1, 8] 區(qū)間。
- PipelineRL-k:來自 PipelineRL [7],并被 Magistral 采用。其中,Rollout Engine 以流式持續(xù)生成 Response 軌跡。每當(dāng) Training 完成 Policy 更新,立即更新 Rollout Engine。但是 Rollout Engine 中已生成的 Response 會(huì)保留并且繼續(xù)使用其對(duì)應(yīng)的 KV Cache,但是當(dāng) Rollout Engine 落后 Training Policy k 個(gè) Step 后,會(huì)進(jìn)入阻塞狀態(tài)。也就是 Rollout Engine 使用的 Policy 模型最多落后 k 個(gè) Step,并且 Response 的生成可能來自多個(gè) Policy 版本。
如下圖 Figure 4a 所示,PipelineRL 與 PPO-off-policy 都達(dá)到相近的性能上限(A),但是 PipelineRL 顯著提升了計(jì)算效率(B)。主要是因?yàn)?PipelineRL 顯著減少了訓(xùn)練中的 Bubble。如下圖 Figure 4b 所示,作者同時(shí)測試了 PipelineRL-k 中 k 的選擇,可以看出,k=8 時(shí)最優(yōu)。

5.2 Loss 類型
如上述 4.1 所示,MiniMax 的 CISPO([2506.13585] MiniMax-M1: Scaling Test-Time Compute Efficiently with Lightning Attention [5])能提升穩(wěn)定性和長期性能。

如下圖 Figure 19 所示,GRPO/DAPO 類損失對(duì) clip 比例超參 ?max 很敏感,相比之下,GSPO 和 CISPO 展現(xiàn)出更強(qiáng)的魯棒性,只要確定正確的數(shù)量級(jí),模型性能便能保持穩(wěn)定。

5.3 精度修復(fù)
Rollout 和 Training 通常使用不同的框架(計(jì)算 Kernel)等,導(dǎo)致兩者的 Token 概率上會(huì)產(chǎn)生微小數(shù)值偏差。RL 訓(xùn)練對(duì)此類差異異常敏感。MiniMax 等工作發(fā)現(xiàn)這些偏差在 LLM head 尤為顯著,通過在 Rollout 和 Training 的 LM_head 保持 FP32 精度可以有效緩解該問題。如下圖所示,精度修正方案將性能上限(A)從 0.52 顯著提升到 0.61。因此,作者在 ScaleRL 中會(huì)采用此方案將 LM_head 精度設(shè)置為 FP32。

5.4 Loss 聚合方式(loss aggregation)
在 4.3 小節(jié)已經(jīng)討論,這里不再贅述,ScaleRL 會(huì)選擇性能最優(yōu)的 Prompt Avg。
5.5 Advantage 歸一化(Advantage Normalization)
在 4.3 小節(jié)已經(jīng)討論,這里不再贅述,ScaleRL 會(huì)選擇性能最優(yōu)的Batch-level Normalization。
5.6 Zero-Variance 過濾
在 4.1 小節(jié)已經(jīng)討論,這里不再贅述,ScaleRL 會(huì)選擇性能最優(yōu)的 Seed1.5-Thinking 的過濾方案。
5.7 數(shù)據(jù)策略
為了提高 RL 訓(xùn)練中樣本效率,很多工作探索了數(shù)據(jù)策略來優(yōu)化。比如 GitHub - ChenxinAn-fdu/POLARIS: Scaling RL on advanced reasoning models [6] 中發(fā)現(xiàn):當(dāng)某個(gè) Prompt 對(duì) Policy 來說變得過于簡單后,通常后續(xù)會(huì)持續(xù)保持這種簡單狀態(tài)。由于這類 Prompt 會(huì)消耗計(jì)算資源而無法提供有效的梯度信號(hào),將其從后續(xù)訓(xùn)練之中排除更加合理。作者實(shí)現(xiàn)一個(gè)簡單變體方案:No-Positive-Resampling —— 維護(hù)一個(gè)歷史通過率記錄,將通過率 >= 0.9 的 Prompt 永久移出后續(xù)訓(xùn)練周期。
如下圖所示,No-Positive-Resampling 提供了更高的性能上限(A):

5.8 長度控制
5.8.1 長度截?cái)?/h4>
作者在系列實(shí)驗(yàn)中同樣發(fā)現(xiàn),訓(xùn)練不穩(wěn)定性與長度截?cái)啵↖nterruption)相關(guān),隨著生成文本長度的增加,多數(shù) RL 過程呈現(xiàn)波動(dòng)的截?cái)嗦剩以摫壤谟?xùn)練過程中有時(shí)還會(huì)持續(xù)上升。
- 作者的實(shí)驗(yàn)中,Batch Size 為 768 時(shí),觀察到 10%-15% 的截?cái)嗦示蜁?huì)破壞訓(xùn)練穩(wěn)定性,導(dǎo)致性能下降且需要人工干預(yù)才能恢復(fù)。
- ScaleRL 訓(xùn)練更加穩(wěn)定,在 8B 模型訓(xùn)練中,超過 90% 的訓(xùn)練時(shí)段截?cái)嗦时3衷?5% 以下。當(dāng) Batch Size 增加至 2048 時(shí),截?cái)嗦事杂刑嵘紶柦咏?7%。但由于排除截?cái)鄻颖竞蟮挠行?Batch 規(guī)模仍然較大,訓(xùn)練穩(wěn)定性依然能夠保持。
- 增大長度預(yù)算有助于降低截?cái)嗦剩?34K 生成長度預(yù)算下(Batch Size 768)—— 截?cái)嗦识虝号噬?4% 后迅速回落到 2% 以下。
- 更大規(guī)模模型展現(xiàn)出更強(qiáng)的魯棒性。在 Scout 模型訓(xùn)練中,截?cái)嗦适冀K低于 2%,且超過 90% 訓(xùn)練步驟中保持在 1% 以下。
總體而言,作者建議密切監(jiān)控截?cái)嗦省Q芯拷Y(jié)果表明,高截?cái)嗦适窍到y(tǒng)不穩(wěn)定的可靠預(yù)警信號(hào)。
5.8.2 長度控制
在 RL 訓(xùn)練中,對(duì)于生成長度爆炸的問題,除了截?cái)啵↖nterruption,在 GLM-4.1V、Qwen3 中使用)的方案,也有工作采用長度懲罰(Length Penalties,在 DAPO、Kimi、Magistral、Minimax-M1 等采用)的方案,如下圖公式所示,通過對(duì)過長的生成結(jié)果施加懲罰來控制生成長度:

在作者的 ScaleRL 實(shí)驗(yàn)中,將截?cái)嗵鎿Q為長度懲罰并未提升性能。
六、ScaleRL 實(shí)驗(yàn)
作者將上述的最優(yōu)策略進(jìn)行整合,并組合為本文的方案 ScaleRL,具體來說其包括:
- PipelineRL-8,8-Step 的 Off-Policy 訓(xùn)練。
- 基于截?cái)?/span>的生成長度控制。
- FP32 精度計(jì)算 Logits(LM_head)。
- CISPO 損失函數(shù)。
- Prompt 級(jí)別損失聚合(Prompt Avg Loss Aggregation)。
- Batch 級(jí)別優(yōu)勢函數(shù)歸一化(Advantage Normalization)。
- Zero-Variance 過濾。
- No-Positive Resampling。
公式如下所示,其中 sg 是 stop-gradient 操作,Astd 表示一個(gè) Batch 中所有優(yōu)勢函數(shù)的標(biāo)準(zhǔn)差,pass_rate(x) 表示該 Prompt 的歷史通過率。對(duì)于強(qiáng)制截?cái)嗟那闆r,使用 end-of-thinking 短語:“Okay, time is up. Let me stop thinking and formulate a final answer now. </think>”。

為了驗(yàn)證這些策略在組合后能保持最優(yōu)性,作者進(jìn)行了 LOO 實(shí)驗(yàn)(Leave-One-Out):將 ScaleRL 作為 Baseline,每次將某個(gè)維度還原為基線方案。比如,LOO-length-penalty 表示將截?cái)鄵Q成長度懲罰。如下圖 Figure 7 所示,每個(gè)實(shí)驗(yàn)均按照 16,000 GPU 小時(shí)進(jìn)行標(biāo)準(zhǔn)化。在所有維度上,ScaleRL 始終保持最優(yōu)配置的能效。

七、相關(guān)鏈接
- ??https://arxiv.org/abs/2510.13786??
- ??https://arxiv.org/abs/2504.13914??
- ??https://arxiv.org/abs/2503.14476??
- ??https://arxiv.org/abs/2501.03262??
- ??https://arxiv.org/abs/2506.13585??
- ??https://github.com/ChenxinAn-fdu/POLARIS??
- ??https://huggingface.co/blog/ServiceNow/pipelinerl???
本文轉(zhuǎn)載自??AI閑談??,作者:AI閑談

















