TRL v1.0：當領域不斷推翻自身假設時仍屹立不搖的後訓練函式庫

TRL 現在實作了超過 75 種後訓練（post-training）方法。但涵蓋範圍本身並非目標，真正重要的是讓這些方法易於嘗試、比較，並能實際應用於實務中。

該函式庫的設計並非預先決定，而是多年迭代的結果——第一次提交可追溯到六年前——並且是由該領域所面臨的一切挑戰所塑造的：新演算法、新模型、不斷轉移的範式。隨著時間推移，這種壓力迫使程式碼庫朝向一個非常特定的設計發展。其中某些部分起初看起來可能很不尋常，但就像許多演化中的程式碼庫一樣，它們的存在自有其道理。

TRL 是為一個不會停滯不前的領域而建構的。因此，問題不在於如何設計完美的抽象，而是在一個不斷推翻自身假設的領域中，如何製作穩定的軟體。這就是我們在 TRL v1.0 中試圖解決的問題，本文將解釋我們是如何做到的。

1. 移動的目標：作為不斷變動領域的後訓練

後訓練的演進並非單一配方的平滑改進。它經歷了連續的重心轉移，每一次轉移不僅改變了目標，也改變了技術棧（stack）的形態。

PPO [Schulman et al., (2017); Ziegler et al., (2019)] 使一種架構看起來成為標準：策略（policy）、參考模型、學習到的獎勵模型、採樣展開（sampled rollouts）以及 RL 迴圈。

接著，像原始 DPO [Rafailov et al., (2023)]、ORPO [Hong et al., (2024)] 和 KTO [Ethayarajh et al., (2024)] 等 DPO 風格的方法簡化了該技術棧：偏好優化可以在沒有獨立獎勵模型、價值模型或任何在線 RL 的情況下運作。曾經看起來至關重要的組件突然變得可有可無。

RLVR 風格的方法如 GRPO [Shao et al., (2024)] 再次轉移了重心。在數學、程式碼和工具使用等任務上，獎勵通常來自驗證器（verifiers）或確定性檢查，而非學習到的獎勵模型。採樣和展開再次變得重要，但迴圈中的對象已不再是當初為 PPO 函式庫所設計的那些。

這給我們的教訓不僅是方法會變，核心的定義也隨之不斷改變。這裡的強假設半衰期很短。這可能就是為什麼目前還沒有任何後訓練函式庫是真正穩定的原因。

2. 從專案到函式庫：TRL 具有適應混亂的設計

那麼，為一個不會停滯不前的領域建構函式庫意味著什麼？答案是反直覺的：不要試圖捕捉當前穩定的本質，而是圍繞著可能發生的變化進行設計。獎勵模型說明了原因：它們在 PPO 中看似必不可少，在 DPO 中變為可選，並在 RLVR 方法中以驗證器的形式回歸——這些結構可能是確定性函數而非學習模型。任何圍繞其原始形式構建的抽象到現在都已經過時兩次了。該函式庫之所以能生存，是因為它意識到強假設的壽命很短，並將這種多變性作為程式碼庫組織的核心。

這就是 TRL 每月被下載 300 萬次的環境，也是主要下游專案將其視為穩定基礎設施的背景。該領域不斷變動，與此同時，這些使用者需要系統不崩潰。

本質的轉變：從程式碼到契約

TRL 並非刻意決定要成為一個函式庫，而是發現自己已經是一個函式庫了。像 Unsloth 和 Axolotl 這樣擁有數千名使用者的專案，直接構建在 TRL 的訓練器和 API 之上。TRL 中的一個破壞性變更會立即傳導到它們的技術棧中。重新命名的參數、變動的預設值、重構的輸出——任何一項都會變成別人的事故。這種轉變已經發生，v1.0 是 TRL 正式承認這一點的時刻。

穩定與實驗性，共處一室

TRL 穩定性模型的不尋常之處不在於它保證了什麼，而在於它在這些保證之外容忍了什麼。穩定版和實驗版共存於同一個套件中，具有明確不同的契約。穩定核心遵循語義化版本控制（semantic versioning）。實驗層則不作此類承諾——它是新方法在評估階段的落腳點，API 可以快速變動以跟上領域發展。

這不是一種妥協，而是對特定約束的反應：該領域產生新方法的速度超過了任何方法贏得穩定性的速度。拒絕加入不成熟的方法會使 TRL 在幾個月內變得無關緊要；將它們全部加入穩定版則會在每次演算法效果不如預期時破壞所有下游專案。

從實驗性晉升到穩定並非自動的。重要的是維護成本與實際使用量之間的比例。有些方法因為社群大量使用而贏得地位；有些則是因為我們可以將其維護成本降得足夠低而變得可行——而程式碼庫的設計正是實現這一點的關鍵。

在實務中，穩定版面包括 SFT、DPO、獎勵建模、RLOO 和 GRPO 的訓練器及其相近變體。實驗版面則更廣泛且變動更快；如需最新資訊，最佳參考是 TRL 文件。

達成 v1.0 所需的破壞性變更已刻意分散在 0.x 版本中。從最後一個 0.x 版本遷移的工作量極小——請參閱遷移指南。

刻意限制抽象

在一個模式不斷變化的領域中，人們很容易傾向於構建能容納一切的靈活抽象。我們的答案恰恰相反：將抽象限制在最低限度——同時意識到這個「最低限度」幾乎總是會被高估。

在實務中，這轉化為一種非常在地化的程式碼處理方式：

目標並非完全消除結構——共享工具仍然存在——而是避免在領域本身尚未穩定之處強加抽象。例如，與其為離線訓練器定義一個共同的基類，我們更傾向於在未來演進尚不明確時採用獨立的實作。

另一個例子：

「評審員」（Judges）是我們不遵循此原則時會發生什麼的好例子。早期，我們引入了 Judge 抽象來統一評估模型輸出的各種方式。當時看起來很合理，但在實務中，它從未被真正使用過——該抽象與人們實際進行評估的方式不符，且在沒有增加價值的狀況下增加了間接性。它仍然存在於倉庫中，主要是作為遺留程式碼。事後看來，直接提供具體實作而不使用統一抽象會對使用者更有利。

更顯式，但更具適應性

這種方法傾向於顯式且可修改的使用方式，而非僵化的框架：減少魔術，增加控制。這伴隨著明顯的代價：程式碼重複。雖然這通常被視為反模式，但在這種背景下，它已被證明不僅可以接受，而且非常有效。與直覺相反，只要保持微小但一致的紀律，它在實務中仍然是可控的：保持實作之間的差異最小化，並避免不必要的發散。就像 Transformers 的設計哲學一樣，我們在設計上接受重複和局部顯式性。動機大致相同，但在重點上略有細微差別。

這與其說是描述，不如說是觀察。比較 RLOO 和 GRPO：它們實作的大部分內容幾乎是逐行重複的。這並非偶然，也不是冗餘。這些方法足夠接近，保持它們的程式碼路徑一致使它們更易於閱讀、演進，且維護成本更低。

3. TRL 的定位

此比較的目標並非爭論 TRL 在每個維度上都是最佳的。它並非如此。有些系統是為了最大吞吐量而建構的（如 PipelineRL），有些針對問題的較窄切片進行了優化（如 LLaMA-Factory），有些則在特定環境中提供更具主見的開發體驗（如 Tinker）。TRL 在生態系統中佔據了不同的位置：它是一個通用後訓練函式庫，試圖在領域允許的範圍內保持 API 和程式碼盡可能簡單，同時結合了廣泛的方法涵蓋、深度的 Hugging Face 整合、相對較低的基礎設施負擔以及明確的穩定性契約。

Unsloth 和 Axolotl 等函式庫未包含在此處，因為它們是構建在 TRL 之上，而非與其並列比較；從這個意義上說，它們的許多使用者間接也是 TRL 的使用者。

生態系統

訓練方法

專案健康度

某些行是事實陳述（GitHub 星數、最後發布、最後提交），其他則是定性判斷（語義化版本穩定性）。

綜合來看，這些比較指向了 TRL 的明確角色：一個旨在將廣度、簡單性、整合性和穩定性保持在一起的通用函式庫。其完整的下游足跡難以衡量，因為大多數部署是私有的，且反向依賴關係在很大程度上是不可見的，但現有的信號已經顯示 TRL 在一個截然不同的規模上運作。

4. 未來展望

到目前為止，v1.0 的邏輯應該很清楚了：這並非聲稱後訓練已經穩定。相反，這是承認該領域將繼續變動，而我們有信心該函式庫具備合適的形態來吸收接下來發生的一切。問題不在於 v1.0 之後會發生什麼，而是 v1.0 的下一步是什麼。

非同步 GRPO

今天，TRL 中的 GRPO 主要透過同步迴圈使用：生成展開、評分，然後執行優化器步驟。這種形式簡單且可靠，但它將吞吐量與最慢的階段綁定，並在規模化時損失了效能。

解決方案在概念上很簡單：生成和訓練不需要同步進行。我們已經有了早期的非同步 GRPO 設計，下一步是將其強化。核心思想是將生成與訓練解耦，讓生成在專用的推理資源上持續運行，而訓練則消耗穩定的評分軌跡流，並具備緩衝、背壓（backpressure）和清晰的策略版本核算。這提高了利用率，並可跨 GPU 和節點擴展。其他函式庫已經提供了某種形式的非同步 RL，但將其引入 TRL 將使這種訓練風格透過更廣泛的整合、更簡單的 API 和更低的採用門檻變得可用。

將方法晉升至穩定版

下一批候選對象包括 KTO 和較新的蒸餾訓練器，如 SDFT、SDPO，以及可能的 GOLD 或 GKD。如第 2 節所述，在將它們移至穩定版之前，目標是最小化實作間的程式碼差異，並監控相對於維護成本的持續社群興趣。

擴展性

TRL 支援大規模訓練，包括多節點運行和更大的模型；下一步是使這條路徑在生產環境中顯著更加穩健且易於操作。這包括圍繞分散式穩定性提供更強的保證、更清晰的擴展預設值，以及對混合專家模型（MoE）的深度支援，特別是專家並行（expert parallelism），其中路由、負載平衡和記憶體行為變得至關重要。

讓訓練對代理程式（Agents）可讀

訓練目前仍太常依賴「感覺」（vibes）。損失曲線下降，獎勵曲線上升，一些樣本看起來比以前好，人們就說服自己運行是有效的。當失敗時，他們滾動查看日誌，用肉眼比較運行結果，然後猜測。這對人類來說已經是一個薄弱的介面，對於代理程式來說更糟：它幾乎稱不上是一個介面。

TRL 最重要的方向之一是讓訓練對軟體可讀，而不僅僅是對人。這意味著要超越儀表板和原始指標，產生明確的信號：策略是在改進、崩潰、對驗證器過度優化、偏離分佈還是陷入平台期？目標是讓 TRL 自動呈現這些模式，清晰地解釋它們，並將其轉化為行動。

計劃是將啟發式方法直接嵌入訓練迴圈中，並發出結構化、可操作的警告——那種初學者可以立即採取行動，且代理程式可以解析的警告：

不僅僅是記錄發生了什麼——而是推理其含義以及下一步該做什麼。這對需要護欄的初學者，以及需要一個可以實際自動化訓練技術棧的代理程式來說都非常有用。

5. 結論

後訓練不會趨於一致。它在變動，而下一次變動已經到來。

v1.0 並非聲稱一切已塵埃落定。它是承認現狀尚未穩定，並承諾該函式庫無論如何都是值得信賴的。六年來與該領域共同演進——以及與數百名使其成為可能的貢獻者並肩作戰——塑造了一個我們有信心能應對未來挑戰的設計。社群和下游專案早已假設了這種穩定性——v1.0 讓它成真。

從最後一個 0.x 版本遷移的工作量極小，遷移指南涵蓋了一切。如果你是新使用者，現在是開始的好時機。

提及論文

更多來自我們部落格的文章

OpenEnv 實務：在現實環境中評估工具使用代理程式

Transformers v5：驅動 AI 生態系統的簡單模型定義

社群

· 註冊或登入以發表評論

提及論文