來自 Sea AI Lab 和新加坡國立大學最新研究認為在強化學習微調中普遍存在的訓練不穩定和性能瓶頸,其根源并非像先前研究所認為的那樣,是復雜的算法設計缺陷,而是一個更基礎的因素——數值精度
![]()
論文矛頭直指當前業界的標準配置 BF16。這個因其在預訓練階段表現穩定而備受青睞的格式,在精細的 RL 對齊過程中卻成了一個“累贅”。研究團隊通過詳實的實驗證明,BF16 的低精度會在模型的訓練過程和實際的推理(或采樣)過程之間制造出一條關鍵的鴻溝。正是這個被稱為“訓練-推理不匹配”(training-inference mismatch)的現象,導致了大量訓練任務的失敗和崩潰。
而他們提出的解決方案,并非一個全新的復雜算法,而是回歸到一個更早的標準:簡單地將計算精度切換回具有更高精度的 FP16 格式。他們斷言,這一個微小的改動,幾乎可以從根本上消除不匹配問題,從而帶來更穩定、更高效、性能更強的模型。
以下是論文詳細解讀:
RL 微調中的幽靈:訓練-推理不匹配問題
強化學習已經成為提升大型語言模型(LLMs)推理等高級能力的關鍵技術。然而,通往高性能模型的 RL 微調之路卻充滿了不確定性。訓練過程常常極其敏感和不穩定,容易出現性能突然下降甚至完全崩潰的情況,這使得穩定地提升模型表現成為一項重大挑戰
論文指出,這種不穩定性的一個關鍵來源,是現代 RL 框架中一個根本性的矛盾:訓練-推理不匹配(training-inference mismatch)。
問題的成因
為了最大化效率,RL 框架通常會為兩個不同的階段配備不同的計算引擎
推理引擎:用于生成響應(即 rollout 或稱“采樣”),這個過程需要極高的速度,因此會使用高度優化的計算核心(kernels)
訓練引擎:用于計算梯度并更新模型參數,這個過程則側重于支持反向傳播等復雜運算
盡管從數學原理上看,這兩個引擎在給定相同模型權重時應該產生完全相同的輸出,但由于硬件層面的具體實現、并行策略和數值精度上的細微差異,它們實際的計算結果會存在微小的數值偏差。這種看似微不足道的差異,卻給優化過程帶來了兩個嚴重的問題。
兩大核心困境
1.有偏梯度(Biased Gradient):在 RL 中,我們使用從推理策略 μ(由推理引擎執行)采樣的數據來優化訓練策略 π(在訓練引擎中定義)。當 π 和 μ 之間存在數值偏差時(即 π ≠ μ),如果我們直接使用這些樣本來計算梯度,而忽略了這個偏差,那么得到的梯度就是有偏的,它無法準確地指向真正能提升模型性能的方向。這會誤導優化過程,導致訓練不穩定。
2.部署差距(Deployment Gap):這是一個更隱蔽但同樣致命的問題。我們的模型參數是在訓練引擎 π 的環境下進行優化的,目標是最大化 π 的預期回報。然而,在模型最終部署應用或進行評估時,我們使用的是推理引擎 μ。這意味著,即使我們找到了對 π 而言的最優參數,這組參數對于實際使用的 μ 來說卻不一定是最優的。這種差距會導致模型在真實場景中的表現低于訓練時的預期。
現有解決方案的局限性
為了解決梯度偏差問題,先前的研究工作主要依賴于算法層面的“補丁”,其核心思想是重要性采樣(Importance Sampling, IS)。通過計算一個概率比率 π(y|x) / μ(y|x) 來重新加權梯度,可以在理論上得到一個無偏的梯度估計。然而,這些方法自身也帶來了新的挑戰。
高方差與慢收斂:對于長序列的生成任務,序列級別的重要性采樣比率方差極大,這會導致訓練過程雖然穩定,但收斂速度異常緩慢。為了緩解方差,研究者們提出了諸如截斷重要性采樣(Truncated Importance Sampling, TIS)和掩碼重要性采樣(Masked Importance Sampling, MIS)等變體。這些方法通過引入少量偏差來換取方-差的大幅降低,但它們并沒有完全解決問題。
計算效率低下:幾乎所有基于重要性采樣的修正方案,都需要額外進行一次前向傳播來計算訓練策略 π 的概率,以便得到重要性權重。假設一次反向傳播的計算成本是前向傳播的兩倍,這個額外的步驟會直接導致約 25% 的訓練成本增加,對于大規模 RL 訓練而言是難以接受的。
無法彌合部署差距:更重要的是,這些算法補丁的設計初衷只是為了修正訓練過程中的梯度,它們本質上仍然是在訓練引擎 π 的框架下進行優化。因此,它們無法從根本上解決模型最終部署在推理引擎 μ 上時的性能損失問題。
綜上所述,現有的算法修正方案要么代價高昂,要么治標不治本。這促使論文作者深入探究不匹配問題的根源,并最終將目光鎖定在了一個被長期忽視的基礎層面——浮點數精度。
問題的根源:浮點數精度
論文的核心觀點在于,訓練-推理不匹配的根本原因并非復雜的算法或工程實現差異,而是源于我們選擇的數值表示本身——即浮點數的精度。通過對比目前主流的兩種 16 位浮點格式 BF16 和 FP16,論文揭示了問題的本質。
BF16 與 FP16 的對決
兩者都使用 16 個比特位來表示一個數字,但其內部結構分配截然不同,這導致了它們在特性上的巨大差異
BF16 :由 Google 推出,它分配了 8 位給指數部分(exponent),7 位給尾數部分(mantissa)
優勢:擁有和 32 位浮點數(FP32)相同的動態范圍,這意味著它能表示極大和極小的數值,極不容易發生上溢(overflow)或下溢(underflow)。這使得模型訓練過程非常穩定,不易因數值問題中斷
劣勢:尾數位非常少,導致其精度極低。在兩個相近的數之間,BF16 無法進行精細的區分。
FP16 (半精度浮點數):遵循 IEEE 754 標準,它分配了 5 位給指數部分,10 位給尾數部分
優勢:擁有 10 位尾數,其精度遠高于 BF16(可表示的離散值數量是 BF16 的 2^3=8 倍)。這使得它能更準確地表示數值,減少舍入誤差。
劣勢:指數位只有 5 位,動態范圍非常有限,在訓練中容易出現梯度過小而下溢(變成零)的問題。
BF16 為何成為主流?
盡管 FP16 出現得更早,但 BF16 憑借其巨大的動態范圍優勢,迅速成為現代大模型訓練(尤其是預訓練階段)的 de-facto 標準。使用 BF16,開發者幾乎無需擔心數值溢出問題,可以像使用 FP32 一樣進行“即插即用”的混合精度訓練。相比之下,使用 FP16 則必須配合一種稱為損失縮放的技術:在反向傳播前,將損失函數乘以一個巨大的縮放因子 S,從而將原本微小的梯度值放大到 FP16 的可表示范圍內;在更新權重前,再將梯度除以 S 恢復原值。雖然這個技術很成熟,但在分布式訓練中會增加通信和同步的復雜性。因此,為了簡潔和穩定,業界普遍選擇了 BF16
BF16 如何導致 RL 微調失敗?
論文指出,BF16 在預訓練中的優勢,恰恰成了 RL 微調中的致命弱點
舍入誤差的累積:RL 微調中的響應生成是一個自回歸(autoregressive)過程,即逐個 token 生成。在 BF16 的低精度下,訓練引擎和推理引擎中那些因實現不同而產生的微小舍入誤差,會在長序列的生成過程中被不斷累積和放大
策略分布的偏離:經過幾十上百個 token 的生成后,這些累積的誤差足以讓訓練策略 π 和推理策略 μ 的概率分布產生顯著的分歧。這正是“訓練-推理不匹配”現象的直接來源
離線分析證據:論文通過離線實驗直觀地展示了這一點。
在 token 級別的概率對比散點圖中,FP16 的點緊密地聚集在對角線(π = μ)周圍,而 BF16 的點則分散得多。
在序列級別的對數概率比(log-probability ratio)分析中,隨著生成序列長度的增加,BF16 引入的 mismatch 呈指數級增長,而 FP16 的 mismatch 則基本保持在一個非常低的水平(比 BF16 小約 24 倍)。
對于 RL 微調階段而言,模型的權重和激活值范圍已經在預訓練中被穩定下來,BF16 的超大動態范圍不再是必需品。相反,它所犧牲的精度,卻成了導致訓練不穩定的關鍵。因此,論文提出的解決方案非常直接:放棄 BF16 不必要的動態范圍,換回 FP16 急需的數值精度。FP16 的高精度就像一個“緩沖墊”,能夠吸收掉不同計算引擎間的微小實現差異,阻止舍入誤差的累積,從而從根源上保持了訓練與推理策略的一致性。
實證研究:FP16 如何完勝現有算法
為了驗證 FP16 在解決訓練-推理不匹配問題上的有效性,論文設計了一套嚴謹的實驗,并與現有的基于 BF16 的算法修正方案進行了直接對比。
創新的實驗設計:Sanity Test
為了排除數據集本身難度分布帶來的干擾,研究者們構建了一個“完美可解”的數據集(perfectible dataset)。他們首先從 MATH 數據集中篩選出初始模型準確率在 20% 到 80% 之間的問題,排除了那些過于簡單或過于困難的題目。在這個特制的數據集上,一個設計良好、運行穩定的 RL 算法理論上應該能夠達到接近 100% 的訓練準確率。如果一個算法無法在此數據集上取得成功,就表明其本身存在根本性缺陷。這個“理智測試”(Sanity Test)為評估算法的可靠性提供了一個清晰、高效的基準。
實驗結果:FP16 的壓倒性優勢
實驗在 VeRL 和 Oat 兩個獨立的 RL 框架上進行,以確保結果的普適性。對比結果非常清晰:
BF16 算法陣營的集體困境:
* **基礎 GRPO 算法**:在訓練初期就迅速崩潰。
* **GRPO + Token-TIS** (token 級別的截斷重要性采樣修正):雖然能延長一些訓練時間,但最終仍然無法避免崩潰的命運。
* **GRPO + Seq-MIS** (序列級別的掩碼重要性采樣修正):這是 BF16 陣營中唯一能保持穩定不崩潰的算法。然而,由于其重要性權重的方差極大,它的收斂速度異常緩慢,性能遠未達到飽和就已耗費大量計算資源,并且最終的性能上限也明顯低于 FP16。
* **GSPO 算法**:表現出乎意料地比 Token-TIS 更穩定,但同樣無法與 FP16 的表現相提并論。FP16 的輕松取勝:
研究者們使用了一個最基礎、最簡單的重要性采樣策略梯度算法(PG-Seq-IS),沒有添加任何復雜的方差削減或修正技巧。僅僅因為運行在 FP16 精度下,該算法就展現出了極高的訓練穩定性,不僅從未崩潰,而且收斂速度飛快,輕松達到了近乎完美的訓練獎勵,性能全面超越了所有精心設計的 BF16 算法。
深入洞察訓練動態
Mismatch 作為崩潰的預警信號:實驗發現,所有最終崩潰的 BF16 算法,在崩潰前都表現出一個共同的特征:訓練策略 π 和推理策略 μ 之間的差異(mismatch)持續增大。這表明 mismatch 是一個有效的訓練健康狀況監測指標和崩潰預警信號
FP16 從根本上解決了問題:切換到 FP16 后,不同 RL 算法之間的性能差異變得微乎其微。無論是簡單的策略梯度還是復雜的 GRPO 變體,在 FP16 環境下都能穩定地達到很高的性能。這雄辯地證明,FP16 已經從根源上解決了不匹配問題,使得那些為解決此問題而設計的復雜算法補丁變得多余。
精度組合的消融實驗
為了進一步厘清訓練和推理精度各自的影響,論文進行了消融研究,測試了不同精度組合的效果。
BF16 訓練 + FP32 推理:雖然能實現完全穩定的訓練,但 FP32 推理的速度比 FP16 或 BF16 慢了近三倍,付出的代價過于高昂,不具備實用性
FP16 訓練 + FP16 推理:這個組合不僅實現了最低的訓練-推理不匹配,獲得了最穩定的訓練動態和最高的性能,同時還保持了極高的計算效率。
綜合所有實驗,結論是明確的:簡單地將訓練和推理精度統一為 FP16,是解決 RL 微調不穩定性問題最高效、最直接、最經濟的方案。
普適性驗證:跨模型、跨場景的廣泛優勢
為了證明“切換到 FP16”這一解決方案并非偶然,而是一種具有廣泛適用性的普適性原則,論文在一系列更多樣化的模型、數據和訓練范式上進行了驗證。結果表明,FP16 在所有測試場景中都展現出了一致的優勢。
混合專家(MoE)模型的 RL 微調
MoE 模型因其獨特的結構(如 top-k 專家選擇等精度敏感操作),在 RL 訓練中是出了名的不穩定,通常需要復雜的穩定化策略。實驗結果(見原文圖 1 (i), (j), (k))顯示:
在對 MoE 模型進行 RL 微調時,無論是使用 GRPO-Seq-MIS、GRPO-Token-TIS 還是 PG-Seq-TIS 算法,FP16 精度下的訓練都比 BF16 更加穩定,并且能夠持續獲得更高的訓練獎勵和驗證集性能。這證明 FP16 能有效緩解 MoE 模型中更為嚴重的訓練-推理不匹配問題。
低秩適應(LoRA)的 RL 微調
LoRA 是一種參數高效的微調技術,因其高效和接近全量微調的性能而備受青睞。實驗中,研究者們使用 LoRA 進行了 RL 微調:
結果顯示,基于 BF16 的 LoRA 訓練在大約 600 步后就崩潰了。
相比之下,基于 FP16 的 LoRA 訓練則從頭到尾都保持了完全的穩定。這說明 FP16 對于提升參數高效微調方法的穩定性同樣至關重要
大型稠密模型的 RL 微調
為了驗證該發現在更大規模模型上的有效性,實驗在一個 140 億(14B)參數的稠密模型(Dense-14B)上進行。
結果再次證實了結論:使用 FP16 進行訓練,模型的獎勵增長速度遠快于 BF16,并且在 AIME 2024 驗證集上取得了更高的準確率。這表明 FP16 能夠有效釋放大模型在 RL 訓練中的潛力
其他模型家族的適用性
為了排除結論可能僅限于特定模型架構(如 Qwen)的可能性,研究者們還在一個基于 Llama 架構的 OctoThinker-3B 模型上進行了實驗
結果與之前完全一致:BF16 訓練在約 150 步后便因數值不匹配問題而變得不穩定,最終崩潰;而 FP16 訓練則一路平穩,沒有任何不穩定的跡象。
通過在 MoE 模型、LoRA 微調、大型稠密模型以及不同模型架構上的全面驗證,論文有力地證明了,將浮點數精度從 BF16 切換到 FP16 是一種能夠系統性提升 RL 微調穩定性和性能的根本性解決方案。其效果超越了特定的算法、模型尺寸或架構,具有極高的普適價值。這一發現不僅解決了當前 RL 微調領域的一個核心痛點,也促使我們重新思考在 LLM 訓練流程中關于數值精度的權衡與選擇
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.