1. 一場每小時燒掉 20 萬的 RL 實驗到底在燒什么第一次看到“小米直播訓(xùn)練大模型每小時燒掉 20 萬”這個說法我腦子里冒出來的第一個念頭不是“真有錢”而是“這錢到底花在哪了”。因為但凡自己動手跑過強(qiáng)化學(xué)習(xí)訓(xùn)練的人都知道RL 這東西的燒錢方式和預(yù)訓(xùn)練完全不是一個量級。預(yù)訓(xùn)練是“一次性投入大、但過程相對穩(wěn)定”而 RL 是“每一步都在試錯每一次試錯都要真金白銀地跑一遍推理”。先把概念說清楚。這里說的 RL指的是 Reinforcement Learning強(qiáng)化學(xué)習(xí)。在大模型語境下它通常出現(xiàn)在后訓(xùn)練階段也就是模型已經(jīng)通過監(jiān)督微調(diào)具備了基本能力之后再用強(qiáng)化學(xué)習(xí)去對齊人類偏好、提升推理能力、優(yōu)化 Agent 行為。小米的 MiMo 系列模型在公開信息里一直強(qiáng)調(diào)推理和 Agent 能力而這兩塊恰恰是 RL 最能發(fā)揮價值的地方。那 20 萬每小時是怎么來的我按自己的經(jīng)驗拆一下。RL 訓(xùn)練的成本主要壓在三個地方推理采樣、獎勵計算、梯度更新。其中推理采樣是大頭因為 RL 不像監(jiān)督學(xué)習(xí)那樣每個樣本只用一次它需要模型對同一個 prompt 生成多個候選回答然后由獎勵模型或規(guī)則打分再根據(jù)分?jǐn)?shù)去調(diào)整策略。這個“生成多個候選”的過程本質(zhì)上是把推理成本乘以了一個系數(shù)通常是 4 到 16 倍。舉個具體的賬。假設(shè)一個 30B 級別的模型用 8 卡 H 系列做推理單卡吞吐按每秒 2000 token 算8 卡就是 16000 token/s。一個 RL step 如果要做 512 條 prompt、每條采樣 8 個回答、每個回答平均 512 token那單 step 的 token 量就是 512 × 8 × 512 ≈ 210 萬 token。按 16000 token/s 算光采樣就要 131 秒。這還只是一個 step而一個完整的 RL 訓(xùn)練動輒幾千到幾萬 step。再疊加獎勵模型的前向計算和策略網(wǎng)絡(luò)的梯度更新整體算力占用會翻倍甚至更多。如果用的是按小時計費的算力集群幾百張卡同時跑每小時 20 萬這個數(shù)字其實并不夸張。我自己的經(jīng)驗是一個中等規(guī)模的 RL 實驗單次跑通就要幾萬到幾十萬不等所以看到這個數(shù)字我第一反應(yīng)是“合理甚至可能還偏保守”。這篇文章我想聊的不是“小米多有錢”而是一個 RL 實驗從設(shè)計到跑通中間到底有哪些坑、哪些關(guān)鍵決策、哪些錢是必須花的、哪些錢是可以省的。適合正在做大模型后訓(xùn)練、Agent 訓(xùn)練、或者單純想搞清楚 RL 訓(xùn)練成本結(jié)構(gòu)的同學(xué)。不管你是剛?cè)腴T還是已經(jīng)跑過幾輪實驗下面這些內(nèi)容應(yīng)該都能對上你的某些經(jīng)歷。2. 整體設(shè)計與思路拆解為什么 RL 訓(xùn)練這么貴2.1 RL 和 SFT 的成本結(jié)構(gòu)差異很多人第一次接觸 RL 訓(xùn)練時會有一個誤解覺得“不就是換個 loss 函數(shù)嗎能貴到哪去”。這個誤解的根源是把 RL 和 SFT 混為一談了。SFT 是監(jiān)督微調(diào)數(shù)據(jù)是固定的每個樣本前向一次、反向一次成本是可預(yù)測的。而 RL 的核心是“采樣-評估-更新”的循環(huán)每一輪都要重新生成數(shù)據(jù)而且生成的數(shù)據(jù)質(zhì)量直接決定訓(xùn)練效果。我用一個生活化的類比來解釋。SFT 像是老師給學(xué)生一套標(biāo)準(zhǔn)答案學(xué)生照著改改完交作業(yè)成本就是“改作業(yè)”的時間。RL 像是老師不給答案只給一個評分標(biāo)準(zhǔn)讓學(xué)生自己寫十遍然后老師挑出最好的那遍告訴學(xué)生“往這個方向靠”。學(xué)生寫十遍的成本就是 RL 的采樣成本。寫十遍當(dāng)然比改一遍貴而且寫得越多、越接近正確答案成本越高。具體到數(shù)字上SFT 的算力利用率通常在 40% 到 60%因為前向和反向可以流水線化。而 RL 的算力利用率往往只有 20% 到 35%因為采樣階段是純推理GPU 利用率上不去而且采樣和訓(xùn)練之間還有等待和同步的開銷。這個利用率差異直接導(dǎo)致 RL 的“有效算力成本”是 SFT 的兩到三倍。2.2 為什么選擇在線 RL 而不是離線 RLRL 訓(xùn)練有兩條路線在線 RL 和離線 RL。在線 RL 是模型自己生成數(shù)據(jù)、自己評估、自己更新數(shù)據(jù)分布隨著策略變化而變化。離線 RL 是用一個固定的數(shù)據(jù)集去訓(xùn)練不依賴實時采樣。小米這種級別的實驗幾乎可以確定是在線 RL。原因很簡單離線 RL 雖然便宜但它有一個致命問題——分布偏移。模型在訓(xùn)練過程中會不斷進(jìn)化如果用的是舊策略生成的數(shù)據(jù)新策略就會在舊數(shù)據(jù)上過擬合導(dǎo)致訓(xùn)練不穩(wěn)定甚至崩潰。在線 RL 雖然貴但它保證了數(shù)據(jù)分布和當(dāng)前策略一致訓(xùn)練更穩(wěn)、上限更高。我自己的經(jīng)驗是如果你的任務(wù)對推理能力要求高比如數(shù)學(xué)、代碼、Agent 工具調(diào)用在線 RL 幾乎是唯一選擇。離線 RL 更適合那些“策略變化不大”的場景比如簡單的格式對齊、風(fēng)格遷移。小米的 MiMo 強(qiáng)調(diào)推理和 Agent這兩個方向都要求模型在訓(xùn)練中不斷探索新的解題路徑所以在線 RL 是必然選擇。2.3 獎勵設(shè)計RL 訓(xùn)練的靈魂RL 訓(xùn)練貴不貴很大程度上取決于獎勵怎么設(shè)計。獎勵設(shè)計得好模型收斂快采樣效率高錢花得值。獎勵設(shè)計得差模型在錯誤的方向上狂奔采樣再多也是浪費。獎勵設(shè)計通常分三類規(guī)則獎勵、模型獎勵、混合獎勵。規(guī)則獎勵是用代碼判斷答案對不對比如數(shù)學(xué)題看最終結(jié)果、代碼題看單元測試是否通過。模型獎勵是訓(xùn)練一個獎勵模型Reward Model去打分適合那些難以用規(guī)則判斷的任務(wù)比如寫作質(zhì)量、對話流暢度?；旌溪剟钍莾烧呓Y(jié)合用規(guī)則做硬約束用模型做軟引導(dǎo)。我踩過的一個坑是一開始全用模型獎勵結(jié)果獎勵模型本身有偏差模型學(xué)會了“討好獎勵模型”而不是“真正解決問題”。后來改成“規(guī)則獎勵為主、模型獎勵為輔”訓(xùn)練穩(wěn)定性明顯提升。這個經(jīng)驗對做 Agent 訓(xùn)練的人尤其重要因為 Agent 的任務(wù)往往有明確的成功/失敗信號規(guī)則獎勵的性價比遠(yuǎn)高于模型獎勵。2.4 算力選型為什么不用消費級顯卡熱詞里出現(xiàn)了“rx6750gre訓(xùn)練大模型”我猜有不少人想用消費級顯卡跑 RL。我的建議是小規(guī)模實驗可以正式訓(xùn)練別想。原因有三個。第一是顯存。RL 訓(xùn)練需要同時加載策略模型、參考模型、獎勵模型有時候還要加載價值網(wǎng)絡(luò)。一個 30B 模型用 FP16 存儲就要 60GB三個模型就是 180GB消費級顯卡的 24GB 顯存根本裝不下。第二是通信。RL 訓(xùn)練涉及大量的 all-reduce 和 all-gather消費級顯卡之間的互聯(lián)帶寬遠(yuǎn)低于數(shù)據(jù)中心卡通信會成為瓶頸。第三是穩(wěn)定性。RL 訓(xùn)練動輒跑幾天消費級顯卡的散熱和供電在長時間高負(fù)載下容易出問題。我自己的做法是用小模型驗證算法用大集群跑正式訓(xùn)練。比如用 1B 到 3B 的模型在單機(jī)上把整個 RL pipeline 跑通確認(rèn)獎勵設(shè)計、超參、數(shù)據(jù)格式都沒問題再遷移到大規(guī)模集群。這樣能把試錯成本壓到最低。3. 核心細(xì)節(jié)解析與實操要點3.1 采樣策略溫度、top-p 和采樣數(shù)量的取舍RL 訓(xùn)練的采樣階段有幾個參數(shù)直接決定成本和效果。溫度temperature控制生成的隨機(jī)性溫度越高模型探索的路徑越多但生成質(zhì)量越不穩(wěn)定。top-p控制候選詞的累積概率閾值top-p 越小生成越保守。采樣數(shù)量num_samples決定每個 prompt 生成多少個候選回答。我的經(jīng)驗配置是這樣的訓(xùn)練初期用溫度 1.0、top-p 0.95、采樣數(shù) 8讓模型充分探索。訓(xùn)練中期降到溫度 0.8、top-p 0.9、采樣數(shù) 4開始收斂。訓(xùn)練后期用溫度 0.6、top-p 0.85、采樣數(shù) 2做精細(xì)調(diào)整。這個“從探索到收斂”的節(jié)奏比固定參數(shù)的效果好很多。采樣數(shù)量對成本的影響是線性的。采樣數(shù)從 8 降到 4采樣成本直接減半。但采樣數(shù)太少會導(dǎo)致優(yōu)勢估計advantage estimation的方差太大訓(xùn)練不穩(wěn)定。我試過采樣數(shù) 2結(jié)果訓(xùn)練曲線抖得沒法看。所以我的建議是采樣數(shù)不要低于 4除非你的任務(wù)獎勵信號非常密集。3.2 優(yōu)勢估計GAE 的參數(shù)怎么調(diào)優(yōu)勢估計是 RL 訓(xùn)練里最容易被忽視、但影響最大的環(huán)節(jié)。常用的方法是 GAEGeneralized Advantage Estimation它有兩個參數(shù)λ 和 γ。γ 是折扣因子控制未來獎勵的權(quán)重。λ 控制偏差和方差的權(quán)衡。γ 通常設(shè) 0.99 或 0.995這個沒什么爭議。λ 就比較講究了。λ 接近 1優(yōu)勢估計的方差大但偏差小λ 接近 0方差小但偏差大。我的經(jīng)驗是任務(wù)越復(fù)雜、獎勵越稀疏λ 越應(yīng)該接近 1。比如數(shù)學(xué)推理任務(wù)獎勵只在最后一步給出λ 設(shè) 0.95 到 0.98 比較合適。如果是 Agent 的多步工具調(diào)用每一步都有中間獎勵λ 可以降到 0.9 左右。這里有個實操細(xì)節(jié)GAE 的計算需要保存每個 token 的 value 估計這會占用大量顯存。如果顯存緊張可以考慮用 token-level 的近似方法或者把序列截斷到固定長度。我試過把序列從 4096 截到 2048顯存占用降了將近一半效果損失在可接受范圍內(nèi)。3.3 KL 散度約束防止模型跑偏的韁繩RL 訓(xùn)練最怕的事情是模型“跑偏”——為了拿高獎勵生成一些語法混亂、邏輯不通但恰好能騙過獎勵模型的回答。KL 散度約束就是防止這種情況的韁繩。它衡量的是當(dāng)前策略和參考策略之間的差異差異越大懲罰越重。KL 系數(shù)β的設(shè)置很關(guān)鍵。β 太大模型不敢探索訓(xùn)練停滯β 太小模型放飛自我輸出質(zhì)量崩壞。我的經(jīng)驗是β 從 0.04 開始根據(jù) KL 散度的實際值動態(tài)調(diào)整。如果 KL 散度持續(xù)低于 0.5說明約束太松可以適當(dāng)調(diào)大 β如果 KL 散度超過 10說明約束太緊要調(diào)小 β。這里有個坑KL 散度的計算方式有兩種一種是 token-level 的一種是 sequence-level 的。token-level 更精細(xì)但計算量大sequence-level 更粗糙但便宜。我一般用 token-level因為 RL 訓(xùn)練本來就很貴了不差這點計算量精細(xì)控制更重要。3.4 梯度累積與批量大小顯存和穩(wěn)定性的平衡RL 訓(xùn)練的批量大小batch size不能太小否則梯度估計的方差太大訓(xùn)練不穩(wěn)定。但批量大小受顯存限制不能無限增大。這時候就要用梯度累積gradient accumulation。我的配置是micro batch size 設(shè)為 1 到 2梯度累積步數(shù)設(shè)為 8 到 16等效批量大小控制在 16 到 32。這個配置在 8 卡 A100 上跑 30B 模型比較穩(wěn)。如果顯存更緊張可以把 micro batch 降到 1梯度累積加到 32但訓(xùn)練速度會明顯變慢。還有一個細(xì)節(jié)RL 訓(xùn)練的批量大小和采樣數(shù)量是耦合的。如果批量大小是 32采樣數(shù)量是 8那每個 step 實際處理的 prompt 數(shù)量是 4。這個比例要控制好prompt 太少會導(dǎo)致每個 step 的梯度噪聲太大。我的經(jīng)驗是每個 step 至少處理 8 到 16 個不同的 prompt低于這個數(shù)訓(xùn)練會很不穩(wěn)。4. 實操過程與核心環(huán)節(jié)實現(xiàn)4.1 環(huán)境搭建從零到跑通第一個 step假設(shè)你現(xiàn)在要從零搭一個 RL 訓(xùn)練環(huán)境我按自己的實操順序給你捋一遍。第一步是確定框架。目前主流的 RL 訓(xùn)練框架有 TRL、OpenRLHF、verl 等。TRL 上手快適合小規(guī)模實驗OpenRLHF 和 verl 更適合大規(guī)模分布式訓(xùn)練。如果目標(biāo)是復(fù)現(xiàn)小米這種級別的實驗verl 的性價比更高因為它對 vLLM 的集成更好采樣效率高。第二步是準(zhǔn)備模型和數(shù)據(jù)。策略模型和參考模型通常是同一個基座模型參考模型凍結(jié)策略模型更新。獎勵模型可以單獨訓(xùn)練也可以用規(guī)則代替。數(shù)據(jù)方面RL 訓(xùn)練需要的是 prompt 集合不需要標(biāo)注答案但 prompt 的質(zhì)量直接影響訓(xùn)練效果。我的做法是從 SFT 數(shù)據(jù)里篩出那些“有明確對錯”的 prompt比如數(shù)學(xué)題、代碼題、邏輯題。第三步是配置采樣引擎。vLLM 是目前最常用的采樣引擎它的 PagedAttention 機(jī)制能顯著提升吞吐。配置的時候要注意tensor parallel size 要和模型大小匹配30B 模型一般用 4 卡 TPgpu memory utilization 設(shè) 0.85 到 0.9留一點余量給梯度更新max model len 要和訓(xùn)練數(shù)據(jù)的最大長度一致避免截斷。第四步是跑通一個 step。先不要管訓(xùn)練效果就讓它跑起來看看采樣、獎勵計算、梯度更新這三個環(huán)節(jié)能不能串起來。我見過太多人一上來就調(diào)參結(jié)果跑了幾小時發(fā)現(xiàn)是數(shù)據(jù)格式錯了。先跑通再調(diào)優(yōu)這個順序不能反。4.2 獎勵函數(shù)實現(xiàn)規(guī)則獎勵的代碼細(xì)節(jié)規(guī)則獎勵是 RL 訓(xùn)練里最實用的獎勵形式。我以數(shù)學(xué)題為例給你看一個簡化版的實現(xiàn)思路。核心邏輯是從模型輸出里提取最終答案和標(biāo)準(zhǔn)答案比對對給 1 分錯給 0 分格式不對給 -0.5 分。import re def extract_answer(text): # 提取 \boxed{} 里的內(nèi)容 match re.search(r\\boxed\{([^}])\}, text) if match: return match.group(1).strip() return None def rule_reward(response, ground_truth): answer extract_answer(response) if answer is None: return -0.5 # 格式錯誤 if answer ground_truth: return 1.0 # 正確 return 0.0 # 錯誤這個實現(xiàn)看起來簡單但有幾個細(xì)節(jié)要注意。第一答案提取要魯棒模型可能用不同的格式輸出答案正則要覆蓋多種情況。第二格式懲罰要適度-0.5 是我試過比較合適的值太大會讓模型只關(guān)注格式不關(guān)注內(nèi)容。第三獎勵要歸一化把獎勵縮放到 -1 到 1 之間避免梯度爆炸。對于 Agent 任務(wù)規(guī)則獎勵會更復(fù)雜一些。比如工具調(diào)用任務(wù)獎勵可以拆成三部分工具選擇是否正確、參數(shù)是否合法、最終結(jié)果是否達(dá)成目標(biāo)。我的做法是給每個部分分配權(quán)重比如 0.3、0.3、0.4然后加權(quán)求和。這個權(quán)重需要根據(jù)任務(wù)特點調(diào)整沒有萬能公式。4.3 訓(xùn)練循環(huán)采樣、評估、更新的完整流程RL 訓(xùn)練的主循環(huán)可以概括為四步采樣、評估、計算優(yōu)勢、更新策略。我用偽代碼給你展示一下完整流程。for step in range(total_steps): # 1. 采樣 prompts sample_prompts(batch_size) responses policy_model.generate(prompts, num_samples8) # 2. 評估 rewards [reward_fn(r, gt) for r, gt in zip(responses, ground_truths)] # 3. 計算優(yōu)勢 values value_model(prompts, responses) advantages compute_gae(rewards, values, gamma0.99, lam0.95) # 4. 更新策略 for epoch in range(ppo_epochs): loss ppo_loss(policy_model, ref_model, prompts, responses, advantages) loss.backward() optimizer.step()這個流程里采樣和更新是串行的這是 RL 訓(xùn)練效率低的主要原因。因為采樣用的是推理模式更新用的是訓(xùn)練模式兩者不能同時進(jìn)行。有些框架嘗試用異步采樣來重疊這兩個階段但實現(xiàn)復(fù)雜度高而且容易引入數(shù)據(jù)不一致的問題。我的建議是先把同步版本跑穩(wěn)再考慮異步優(yōu)化。還有一個細(xì)節(jié)是 PPO 的 epoch 數(shù)。PPO 通常會對同一批數(shù)據(jù)做多次更新但 epoch 太多會導(dǎo)致策略偏離采樣時的策略太遠(yuǎn)訓(xùn)練不穩(wěn)定。我的經(jīng)驗是PPO epoch 設(shè) 2 到 4超過 4 就容易出問題。4.4 成本控制哪些錢可以省哪些不能省回到 20 萬每小時這個話題。我按自己的經(jīng)驗把 RL 訓(xùn)練的成本拆成“必須花”和“可以省”兩類。必須花的錢包括采樣算力、梯度更新算力、獎勵計算算力。這三塊是 RL 訓(xùn)練的核心省了就沒法訓(xùn)練?？梢允〉腻X包括調(diào)試階段的算力、失敗實驗的算力、過度采樣的算力。我的省錢策略有三條。第一用小模型做算法驗證。1B 模型跑通整個 pipeline 的成本可能只有 30B 模型的百分之一。第二用規(guī)則獎勵替代模型獎勵。規(guī)則獎勵幾乎不消耗算力模型獎勵需要額外的前向計算。第三動態(tài)調(diào)整采樣數(shù)量。訓(xùn)練初期用大采樣數(shù)探索訓(xùn)練后期用小采樣數(shù)收斂能省下不少采樣成本。還有一個容易被忽視的點數(shù)據(jù)質(zhì)量比數(shù)據(jù)數(shù)量重要。我試過用 10 萬條低質(zhì)量 prompt 訓(xùn)練效果遠(yuǎn)不如 1 萬條高質(zhì)量 prompt。RL 訓(xùn)練里每條 prompt 都要被采樣多次低質(zhì)量 prompt 的浪費是成倍的。所以寧可花時間篩數(shù)據(jù)也不要盲目堆數(shù)據(jù)量。5. 常見問題與排查技巧實錄5.1 訓(xùn)練不收斂從獎勵曲線找線索RL 訓(xùn)練不收斂是最常見的問題。我的排查順序是先看獎勵曲線再看 KL 散度最后看梯度范數(shù)。獎勵曲線如果一直平說明模型沒有學(xué)到東西?？赡艿脑蛴腥齻€獎勵信號太稀疏、學(xué)習(xí)率太小、KL 約束太緊。我的做法是先檢查獎勵分布如果大部分樣本的獎勵都是 0說明獎勵太稀疏需要調(diào)整獎勵設(shè)計。如果獎勵有區(qū)分度但模型不學(xué)就調(diào)大學(xué)習(xí)率或者放松 KL 約束。獎勵曲線如果震蕩劇烈說明訓(xùn)練不穩(wěn)定。可能的原因是批量太小、優(yōu)勢估計方差太大、或者獎勵尺度不一致。我的做法是增大批量、調(diào)小 GAE 的 λ、對獎勵做歸一化。KL 散度如果持續(xù)上升說明模型在跑偏。這時候要調(diào)大 KL 系數(shù)或者檢查獎勵函數(shù)是不是有漏洞。我遇到過一次模型發(fā)現(xiàn)只要輸出特定格式就能拿高分結(jié)果所有回答都變成那個格式。后來在獎勵里加了多樣性懲罰才解決。5.2 顯存溢出分層排查法顯存溢出是 RL 訓(xùn)練的另一大痛點。因為 RL 要同時加載多個模型顯存壓力比 SFT 大得多。我的排查方法是分層的先看模型加載占了多少再看采樣占了多少最后看梯度更新占了多少。模型加載方面30B 模型用 FP16 要 60GB用 8-bit 量化能降到 30GB用 4-bit 量化能降到 15GB。如果顯存實在緊張可以考慮用 LoRA 只訓(xùn)練部分參數(shù)參考模型用 4-bit 量化。采樣方面vLLM 的 KV cache 會占用大量顯存可以通過調(diào)小 max model len 或者降低 gpu memory utilization 來緩解。梯度更新方面梯度累積和 gradient checkpointing 是標(biāo)配能省不少顯存。我自己的配置是策略模型 FP16、參考模型 4-bit、獎勵模型 4-bit、vLLM 的 gpu memory utilization 設(shè) 0.85。這個配置在 8 卡 A100 80GB 上跑 30B 模型比較穩(wěn)。5.3 采樣速度慢吞吐優(yōu)化的幾個方向采樣速度直接決定訓(xùn)練成本。如果采樣慢GPU 利用率上不去錢就白花了。我的優(yōu)化方向有四個。第一用 vLLM 或 TensorRT-LLM 替代 HuggingFace 的 generate。HuggingFace 的 generate 實現(xiàn)比較通用但吞吐遠(yuǎn)不如專門的推理引擎。我實測下來vLLM 的吞吐是 HuggingFace 的 3 到 5 倍。第二調(diào)大 batch size。采樣階段是純推理batch size 越大GPU 利用率越高。但 batch size 受顯存限制需要權(quán)衡。我的做法是先用小 batch 跑通再逐步調(diào)大找到顯存的上限。第三用連續(xù)批處理continuous batching。vLLM 默認(rèn)開啟連續(xù)批處理它能讓不同長度的序列共享計算顯著提升吞吐。如果用的是其他引擎要確認(rèn)這個功能是否開啟。第四減少不必要的同步。采樣和訓(xùn)練之間的數(shù)據(jù)傳遞、獎勵計算和策略更新之間的同步都會造成 GPU 空轉(zhuǎn)。我的做法是把獎勵計算放到 CPU 上異步執(zhí)行讓 GPU 盡量不等待。5.4 常見問題速查表問題現(xiàn)象可能原因排查方法解決方案獎勵曲線平坦獎勵太稀疏、學(xué)習(xí)率太小檢查獎勵分布調(diào)整獎勵設(shè)計、調(diào)大學(xué)習(xí)率獎勵曲線震蕩批量太小、優(yōu)勢方差大檢查批量大小和 GAE 參數(shù)增大批量、調(diào)小 λKL 散度持續(xù)上升獎勵有漏洞、KL 約束太松檢查獎勵函數(shù)調(diào)大 KL 系數(shù)、加多樣性懲罰顯存溢出模型太多、序列太長分層排查顯存占用量化、LoRA、梯度累積采樣速度慢引擎效率低、batch 太小檢查 GPU 利用率換 vLLM、調(diào)大 batch訓(xùn)練后期崩壞過擬合、策略跑偏檢查驗證集表現(xiàn)早停、調(diào)大 KL 系數(shù)這張表是我自己踩坑總結(jié)出來的基本上覆蓋了 RL 訓(xùn)練 80% 的問題。剩下的 20% 往往是數(shù)據(jù)問題或者框架 bug需要具體問題具體分析。5.5 幾個反直覺的實操心得最后分享幾個我在實操中總結(jié)的、和常規(guī)認(rèn)知不太一樣的心得。第一個是學(xué)習(xí)率不是越小越穩(wěn)。RL 訓(xùn)練的學(xué)習(xí)率通常比 SFT 小一個數(shù)量級但太小會導(dǎo)致訓(xùn)練停滯。我的經(jīng)驗是 1e-6 到 5e-6 之間比較合適具體要看模型大小和任務(wù)難度。第二個是參考模型不一定要和策略模型完全一致。有時候用一個稍弱的模型做參考反而能防止策略跑偏。我試過用 SFT 之前的基座模型做參考KL 約束的效果比用 SFT 之后的模型更好。第三個是訓(xùn)練步數(shù)不是越多越好。RL 訓(xùn)練很容易過擬合尤其是當(dāng)獎勵函數(shù)不夠魯棒的時候。我的做法是每隔一定步數(shù)在驗證集上評估一次如果驗證集獎勵開始下降就停止訓(xùn)練。早停能省下不少算力。第四個是Agent 任務(wù)的 RL 訓(xùn)練獎勵設(shè)計比算法選擇重要十倍。我見過太多人在 PPO、GRPO、DPO 之間糾結(jié)但真正決定效果的是獎勵函數(shù)能不能準(zhǔn)確反映任務(wù)目標(biāo)。把獎勵設(shè)計好用最簡單的 PPO 也能出效果獎勵設(shè)計不好用最先進(jìn)的算法也是白搭。這些心得沒有什么理論支撐都是從一次次失敗實驗里攢出來的。RL 訓(xùn)練這件事理論能幫你理解原理但真正讓你跑通的是這些細(xì)節(jié)經(jīng)驗。希望這些內(nèi)容能幫你少燒一點錢多出一點結(jié)果。