SDPO：把環境回饋蒸餾回策略本身的 RLVR 框架
Reinforcement Learning via Self-Distillation (SDPO)
秒懂
- 它是什麼？
- SDPO 針對 RLVR 只拿到純量分數的信用分配瓶頸，把執行錯誤、評審評語這類文字回饋轉成密集的自我蒸餾訊號。本文整理它的機制、安裝路徑與適用邊界。
- 適合誰用？
- SDPO 適合已經在做 RLVR、而且手上環境能吐出文字回饋的團隊，例如執行期錯誤訊息或評審輸出；若你的環境只回傳對錯，README 也給了以高獎勵 rollout 當隱式回饋的替代路徑，但那是不同的設定。不適合只想做離線微調、或沒有 NVIDIA GPU 可用的情境，因為安裝章節從頭到尾都建立在 CUDA 之上。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 77 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
SDPO 要解的是純量獎勵的信用分配瓶頸
在程式與數學這類可驗證領域，模型後訓練常採 RLVR，也就是可驗證獎勵的強化學習。README 的描述很直接：現行方法每次嘗試只從一個純量結果獎勵學習，形成嚴重的信用分配瓶頸。一次 rollout 可能跑了兩百個 token 才出錯，但訓練訊號只告訴你最後那一步失敗，中間哪個決策導致失敗完全沒有資訊。
SDPO 的觀察是，許多可驗證環境其實已經提供了豐富的文字回饋，例如執行期錯誤或評審評語，這些文字說明了嘗試為什麼失敗。作者把這個設定形式化為 Reinforcement Learning with Rich Feedback（RLRF）。目標讀者因此很明確：手上已經有這類回饋、卻只把它丟掉、只留分數的 RLVR 實作者。
這裡的關鍵詞是「已經有」。SDPO 不負責替你產生回饋，它處理的是你已經拿到的回饋。若你的環境只回傳通過或失敗，README 另有一條路：把高獎勵 rollout 當成隱式回饋重用，在沒有豐富環境回饋時提供密集監督。這兩種情境在專案裡是分開陳述的，不要混為一談。
自我教師：把回饋條件化的模型蒸餾回策略
機制上，SDPO 不使用外部教師模型，也不訓練顯式的獎勵模型。它把當前模型在回饋條件下的下一個 token 預測當成自我教師，再把這些預測蒸餾回策略本身。README 的說法是，SDPO 利用模型在上下文裡回溯辨識自身錯誤的能力。
把這句話拆開看，資料流大致是：策略先產生 rollout，環境給出回饋，回饋被 token 化後接到上下文前面，同一個模型在帶回饋的條件下重新對該軌跡做預測，這些預測成為蒸餾目標，更新回原策略。教師與學生是同一個模型的兩種條件狀態，差別只在於有沒有看到回饋。
README 提到 SDPO 把回饋轉成密集學習訊號，並在結果圖的說明中把它描述為比 GRPO 更細的信用分配層級：logit 大於 token 大於 sequence。這正是它與純量獎勵方法的結構差異。純量獎勵只在序列層級給一個數字，自我蒸餾則在每個 token 位置都給出目標分布。
值得留意的是，圖說同時指出自我教師在訓練過程中會變好，最終學生明顯超過初始教師。這句話反過來讀也成立：訓練前期的教師品質就是你的上限起點，蒸餾迴圈的收益取決於模型能否在上下文裡真的辨識出錯誤。
安裝路徑分成 GH200 容器與本機兩條
系統需求寫得很具體：Linux，實測於 SLES 15 SP5 與 Ubuntu 22.04；NVIDIA GPU；Python 3.12，實測 3.12.3；CUDA 驅動需與所安裝的 PyTorch 版本相容。
針對 NVIDIA GH200（aarch64）搭配 CUDA 13.1 的叢集，專案提供基於 NGC vLLM 容器的 Dockerfile.gh200，README 標為建議路徑。建置與匯出指令為：
podman build . -f Dockerfile.gh200 -t sdpo-gh200 enroot import -x mount -o sdpo-gh200.sqsh podman://localhost/sdpo-gh200:latest
README 的註記說明，這些映像使用 requirements-gh200.txt，內容是 requirements-full.txt 的固定版本，但排除了 NGC vLLM 容器已預裝的套件，包含 torch、vllm、flash-attn、xformers、triton。這代表容器路徑與本機路徑的依賴集合並不相同，不要拿其中一份去推斷另一份。
本機安裝先裝 PyTorch，再裝 SDPO 與依賴。Ampere 與 Hopper（RTX 30/40、H100）用：
pip install torch==2.5.1 torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124
Blackwell（RTX 50、RTX PRO 2000 Blackwell）改用：
pip install torch==2.7.0 torchvision torchaudio --index-url https://download.pytorch.org/whl/cu128
兩個版本對應不同 CUDA 索引，選錯會在驅動層直接失敗。README 在依賴安裝段落被截斷，requirements 檔案的完整用法請以倉庫內容為準。
測試時自我蒸餾不更新權重
除了訓練，SDPO 還描述了測試時自我蒸餾。做法是產生多個候選解，挑出高品質回應，再把它們當成示範重用，讓模型在推論階段迭代精進輸出。README 強調這條路徑不需要額外訓練。
這個設計的邊界值得說清楚。它本質上是在推論預算上換取解題率，而不是改變模型參數。README 的圖說指出 SDPO 能解開基礎模型與多輪互動都解不開的題目，在生成預算範圍內達到更高的解法發現率。這裡的「生成預算」是關鍵詞：候選解變多，成本就上升，收益要在預算曲線上才看得出來。
適用場景因此偏向難題的離線求解或評測，而不是低延遲的線上服務。若你的推論通道有嚴格的 token 上限或尾延遲要求，候選取樣與篩選會直接撞上這道牆。
回饋品質就是這套方法的隱含前提
SDPO 的機制把所有重量壓在回饋的資訊量上。若環境回饋是模板化的罐頭訊息，例如固定的失敗字串，條件化上下文幾乎沒有新增資訊，自我教師與原策略的預測分布會很接近，蒸餾訊號自然稀薄。README 把「豐富回饋」與「稀疏或規則式回饋」分成兩個結果段落處理，這個切分本身就說明了方法的敏感點。
第二個限制在硬體。README 的實驗設定是每個 run 使用一個 4 張 NVIDIA GH200 的節點，含初始化與驗證約 6 小時；比較表中的數字取自 1 小時與 5 小時 wall-clock 訓練時間內達到的最高 avg@16。這不是一般單卡環境能複製的規模。倉庫沒有提供輕量示範或小模型路徑的說明，想在筆電上先試水溫的人會卡在硬體前提。
第三，README 沒有檢索到任何 release。這代表沒有版本化的穩定性承諾，追蹤 main 分支就等於接受介面變動的風險。對要放進既有訓練流程的團隊，這是採用前必須自行評估的成本。
與 GRPO 的差異在訊號密度而非演算法家族
專案自己在圖說中把 GRPO 當作主要對照。README 說明，SDPO 與 on-policy GRPO 每個生成批次各做一次梯度步，而 GRPO 額外做 4 次 off-policy mini-batch 步；兩邊都依 5 小時準確率挑選最佳超參數。
這裡的差異不在於誰屬於哪個演算法家族，而在於學習訊號從哪裡來。GRPO 走的是群組相對優勢，把同批 rollout 的分數互相比較，訊號仍源自純量獎勵。SDPO 多了一條路：把回饋條件化後的模型預測當成逐 token 的目標。當環境只給分數時，README 表示 SDPO 改為重用高獎勵 rollout 作為隱式回饋，這條路徑與 GRPO 的群組比較在概念上更接近，差別在於監督的密度。
選擇上的實務判斷是：若你的環境已經產出結構化或文字回饋，直接丟掉這段資訊改用 GRPO，等於自願放棄密集訊號。反之，若回饋本身不可靠，把它蒸餾進策略只會把雜訊固化。
授權與採用前該確認的事項
專案採 Apache-2.0，倉庫層級的授權條款允許商業使用與修改，並附帶專利授權條款。這是程式碼層面的條件。README 的引用區塊指向 arXiv 論文 2601.20802 與專案首頁，模型權重、資料集或論文本身可能有各自的條款，那些不隨 Apache-2.0 自動繼承。這裡只描述檔案層級的事實，不構成法律意見，實際條款請自行核對 LICENSE 全文與你使用的模型授權。
維護成本方面，README 沒有 release，代表沒有版本標籤可鎖定。依賴被明確固定，requirements-gh200.txt 是 requirements-full.txt 的固定版本子集，容器路徑又排除 torch、vllm、flash-attn、xformers、triton 這幾個由 NGC vLLM 映像提供的套件。升級 PyTorch 或 CUDA 時，這幾層的版本對應關係需要一起檢查，不是改一行就能完成的事。
採用前建議先跑通 Dockerfile.gh200 的建置與 enroot 匯出，確認你的叢集架構與 CUDA 版本落在 README 標示的範圍內，再處理資料與回饋格式的接入。
編輯結論
SDPO 適合已經在做 RLVR、而且手上環境能吐出文字回饋的團隊，例如執行期錯誤訊息或評審輸出；若你的環境只回傳對錯，README 也給了以高獎勵 rollout 當隱式回饋的替代路徑，但那是不同的設定。不適合只想做離線微調、或沒有 NVIDIA GPU 可用的情境，因為安裝章節從頭到尾都建立在 CUDA 之上。動手前先確認三件事：你的模型與 tokenizer 是否能被訓練腳本載入、你的環境回饋格式是否符合程式預期的 token 化輸入、以及回饋品質是否穩定。回饋本身若雜訊大，蒸餾進來的就是雜訊。
社群筆記