VLM-R1：把 GRPO 強化學習搬到視覺語言模型，reward 函數才是真正的介面

VLM-R1 想解的不是推論問題，而是後訓練階段的泛化衰減

這個專案瞄準的是一個具體現象。README 以 Referring Expression Comprehension（REC）為例，把 Qwen2.5-VL 分別用 R1 式強化學習與 SFT 訓練，然後比較兩者在 in-domain 與 out-of-domain 測試資料上的曲線。官方描述是：訓練步數在 100 到 600 步這個區間內，SFT 模型在 in-domain 資料上的表現與 R1 base model 相比變化不大；但到了 out-of-domain 資料，SFT 模型的表現會隨著步數增加而略微退化，而 RL 模型則把推理能力泛化出去。

這段敘述的價值在於它把問題定位成「後訓練方法選擇」而不是「模型架構創新」。目標讀者因此很清楚：已經在用 Qwen2.5-VL 或 InternVL 做視覺理解任務、手上有一批可自動評分的標註資料、並且正在猶豫要不要從 SFT 換到 RL 的團隊。如果你的任務無法自動算分，例如開放式視覺問答或需要人類偏好的描述生成，這個 repo 的 reward 機制就沒有現成的著力點。

需要保留態度的地方是，README 自己也附了註腳：先前的 REC SFT 實驗用錯了 pixel config，因此他們在更複雜的 out-of-domain 資料上重跑了一次。這代表原始對比曾經受設定錯誤影響。重跑後的結論是否穩固，取決於你是否接受他們在部落格 findings 中揭露的設定細節，而這部分無法從 repo 本身驗證。

GRPO 迴圈裡真正被客製化的是 reward，不是策略網路

從 repo 結構看，訓練入口是 src/open-r1-multimodal/src/open_r1/grpo_jsonl.py。這個檔案在 2025-04-16 的更新中把 REC 流程整併進來，官方說法是為了讓各任務共用同一套實作。這件事的實際意義是：不同視覺任務的差異被收斂到 reward 計算，而不是各自一份訓練腳本。

reward 的掛載方式是透過一個新參數 is_reward_customized_from_vlm_module。當它設為 true，reward 邏輯會改由模型對應的 module 處理，也就是 QwenVL2Module（src/open-r1-multimodal/src/open_r1/vlm_modules/qwen_module.py）或 InternVLModule（src/open-r1-multimodal/src/open_r1/vlm_modules/internvl_module.py）。這是一個明確的擴充點：要支援新的視覺任務，實務上就是改這兩個檔案之一，而不是改訓練主迴圈。

OVD 任務另外加了 odLength、weighted_sum、cosine 三種 reward，README 指向 2025-03-20 的部落格與 2025-03-24 的 findings 說明用法。這裡值得留意的是 reward 種類的增加速度：不同任務各自引入新的 reward 項，意味著跨任務的訓練設定難以直接搬移。你在 REC 上調好的超參數，換到 OVD 時 reward 的尺度與權重都要重新想一遍。

另外，2025-06-26 的更新對 QwenVL 加了 bounding box 的 post-resize 操作，訓練與評估兩邊都改（訓練在 qwen_module.py 第 124 至 129 行附近，評估在 src/eval/test_rec_r1.py 第 92 至 97 行附近）。官方說結果略有改善。這種座標後處理與模型輸入解析度綁定，換模型或換解析度時要記得同步檢查。

跑起來：從 run_grpo_rec.sh 到 freeze_vision_modules

README 的 Features 段落直接列出可用的腳本與設定，這是取得可執行狀態最短路徑。全量微調 GRPO 用 run_scripts/run_grpo_rec.sh，LoRA 微調用 run_scripts/run_grpo_rec_lora.sh，多節點訓練參考 run_scripts/multinode_training_demo.sh，多圖輸入的範例是 run_scripts/run_grpo_gui.sh。凍結視覺模組則是在腳本裡把 freeze_vision_modules 設為 true。

這組設計對硬體預算的意義很直接：freeze_vision_modules 與 LoRA 兩條路徑可以大幅壓低可訓練參數量，讓單機多卡有機會跑完一輪 REC 訓練；全量微調則需要多節點，multinode_training_demo.sh 就是為此準備的。README 沒有給出各腳本的具體硬體需求數字，選卡前得自己看腳本內的模型路徑與 batch 設定。

資料要換成自己的，README 指向 For your own data 段落，並說明多圖輸入的格式也在該處。從 grpo_jsonl.py 這個命名可以推斷訓練資料以 jsonl 為載體，但欄位細節必須回頭查 README 對應段落，本文不代為推測。模型支援面目前是 QwenVL 與 InternVL 兩條線，擴充方式寫在 assets/add_new_model.md。

部署端另有兩條分支：2025-08-22 的更新把模型適配到華為 Ascend Atlas 800T A2 與 Atlas 300I Duo，使用 vllm-ascend，路徑為 ascend_inference/910B/vllm_ascend/README.md 與 ascend_inference/300IDuo/README.md；2025-08-29 的更新改用 JD 開源的 xllm，路徑為 ascend_inference/910B/xllm/README.md，官方稱 TTFT 相較 vllm-ascend 降低 50%、整體吞吐提升 127%。這些數字來自官方更新說明，本文未做驗證，且僅適用於該 Ascend 推論路徑，不能外推到 GPU 環境。

reward 寫不出來，這條路就走不通

最現實的限制是 reward 的可計算性。GRPO 需要對同一輸入採樣多個輸出並比較其分數，這要求任務有自動評分方式。REC 的評分可以靠預測框與標註框的 IoU，OVD 可以靠 odLength 這類結構化指標，數學推理可以靠答案比對。一旦任務變成「描述這張圖好在哪裡」，就沒有現成 reward 可用，你得先自己造一個，而 reward 的品質直接決定策略會學到什麼。

第二個限制是模型支援面窄。README 明說目前支援 QwenVL 與 InternVL，新增模型需要照 assets/add_new_model.md 走一遍。這不是改個 config 就能完成的事，因為 reward 邏輯綁在 vlm_modules 下的模型專屬 module 裡，換模型等於要重新確認該模型的座標格式、輸入解析度與輸出解析方式。

第三個限制與專案狀態有關。README 的更新紀錄相當密集，從 2025-03 到 2025-08 之間多次調整 reward、整併訓練流程、修正 bounding box 後處理。這種節奏代表 API 與檔案結構仍在變動，把 repo 當成穩定依賴來 pin 版本，需要預期升級時會遇到介面位移。

最後，README 首頁的排行榜與 SOTA 敘述集中在官方自己訓練出的 checkpoint 上。這些 checkpoint 在 Hugging Face 與 ModelScope 有發布，可以直接取用推論，但「用官方 checkpoint 推論」與「用這個 repo 訓練自己的模型」是兩件不同的事，後者的成本遠高於前者。

與純 SFT 流程的差別：多了一個會出錯的評分環節

最直接的替代方案就是繼續用 SFT。兩者的差別不在模型，而在訓練訊號的來源。SFT 直接拿標註答案當目標，損失函數固定，除錯時你只需要檢查資料與超參數。VLM-R1 走的路徑是：模型生成多個候選輸出，reward 函數為每個候選打分，GRPO 再用這些分數調整策略。多出來的這一層意味著錯誤來源多一處，reward 寫錯或尺度失衡時，訓練曲線可能看起來正常但實際學到的是 reward 的漏洞。

README 提供的對比正好落在這個差異上。官方觀察是 SFT 在 in-domain 資料上與 R1 base model 差距不大，但在 out-of-domain 資料上隨步數增加而退化，RL 則能泛化。如果這個觀察在你的資料上成立，那麼多花在 reward 設計與訓練基礎設施上的成本就有對應回報。如果不成立，例如你的測試資料與訓練資料同分布，SFT 是更省事的選擇。

另一類替代是直接使用現成的物件偵測模型處理 REC 與 OVD。README 在 2025-03-20 的更新中提到，RL 模型在 OVDEval 上勝過 SFT baseline 與專門的物件偵測模型。這是官方主張，本文無法獨立驗證，但至少指出比較基準是存在的：你要決定的是用一個通用 VLM 加上 RL 後訓練，還是接一個針對偵測任務設計的專用模型。前者的好處是同一套模型可以覆蓋多種視覺理解任務，後者的好處是推論成本與調校複雜度通常更低。

授權與維護成本：Apache-2.0 涵蓋的是這個 repo，不是 checkpoint

repo 採 Apache-2.0，這是寬鬆授權，允許修改與再散布，也包含專利授權條款。但要注意授權範圍：Apache-2.0 覆蓋的是 om-ai-lab/VLM-R1 這個程式碼庫。README 指向的 Hugging Face 與 ModelScope checkpoint 是另外發布的產物，其授權條款要個別確認，不能預設與 repo 相同。模型權重、訓練資料集（omlab/VLM-R1）與程式碼是三份不同的授權文件。本文不提供法律意見，實際商用前請自行核對各檔案內的 LICENSE 與模型卡。

維護成本主要來自兩處。一是上游依賴的移動速度：Qwen2.5-VL、InternVL、GRPO 實作、以及 Ascend 推論路徑上的 vllm-ascend 與 xllm，任何一環改版都可能需要同步調整。二是本專案自身的更新頻率，2025-04-16 的更新就同時動了訓練主流程、reward 掛載參數與日誌輸出，這種幅度的變更在升級時需要重新驗證訓練結果。

如果你的用法是取官方 checkpoint 做推論，維護成本相對低，只要鎖定推論框架版本即可。如果用法是持續訓練自己的模型，那麼 reward 函數、資料格式與 vlm_modules 下的模型專屬程式碼會是你長期要自己維護的部分。

編輯結論

若你手上已有標註好的 REC 或 OVD 資料，且團隊有能力自己寫 reward 函數並讀懂 grpo_jsonl.py 的計算流程，VLM-R1 值得在單機多卡上先跑一輪 run_grpo_rec_lora.sh 驗證流程；若你期待的是拿現成 checkpoint 直接推論、或需要一份穩定的 API 介面，這個 repo 的訓練腳本與資料格式耦合會是負擔。採用前先確認三件事：你的資料能否轉成 repo 要求的 jsonl 欄位、你的 reward 能否在 is_reward_customized_from_vlm_module 開啟後正確回傳、以及你使用的模型是否落在 QwenVL 或 InternVL 這兩條已支援路徑內。

官方來源

1. Issues
2. License: Apache-2.0
3. om-ai-lab/VLM-R1 on GitHub
4. README
5. Releases