VibeThinker：1.5B 與 3B 兩個版本，把推理能力壓進小模型的代價與邊界

它想解決的是後訓練成本，不是模型規模

多數團隊面對推理模型時的困境很具體：想要 AIME 或競程等級的表現，就得承擔 671B 級別的推論成本與後訓練預算。README 引用 DeepSeek R1 與 MiniMax-M1 的後訓練成本分別為 294K 與 535K 美元，並稱 VibeThinker-1.5B 的路線把這個數字壓到 7,800 美元。這個對比是專案自己給出的，沒有第三方複核，但它點出了專案的定位：不是要做最強的模型，而是要把達到某一條能力線所需的算力與資料預算降下來。

目標讀者因此相當明確。手上只有一兩張 GPU、要做可自動判分的推理任務、又不想依賴 API 的團隊，是這個專案預設的使用者。反之，如果你的任務需要的是廣泛世界知識、長文件理解或開放式對話，參數量本身就是天花板，這個專案幫不上忙。

Spectrum-to-Signal：先製造多樣性，再放大正確訊號

README 把方法命名為 Spectrum-to-Signal Principle（SSP），並拆成兩個階段。SFT 階段叫 Two-Stage Diversity-Exploring Distillation，目的是產生大量彼此不同的解法，也就是所謂的 spectrum。RL 階段叫 MaxEnt-Guided Policy Optimization（MGPO），作用是在這些解法裡把正確的那條訊號放大。命名本身就說明了它的假設：小模型之所以推理弱，不是因為容量不足，而是因為後訓練階段的輸出多樣性被過早收斂掉了。

VibeThinker-3B 在此之上做了擴充。README 描述它建構於 Qwen2.5-Coder-3B，採用升級版的 pipeline，包含課程式 SFT、多領域 RL、離線自蒸餾，以及面向指令遵循的 RL，並且保留完整的長上下文推理軌跡。這幾項的組合意味著訓練流程比 1.5B 版本長得多，資料合成與品質過濾的比重也更高。

3B 版本另外引入 Claim-Level Reliability Assessment（CLR），這是一種測試時擴展策略，針對答案可驗證的推理任務。README 給出的數字是 AIME26 由 94.3 提升到 97.1，HMMT25 由 89.3 提升到 95.4。這代表 CLR 不是訓練時的方法，而是推論時多花算力換準確率。專案另外在 2026 年 8 月把 CLR 的細節獨立成論文並開源了程式碼，位置在 WeiboAI/CLR。

這裡有一個必須指出的設計限制。CLR 依賴答案可驗證這個前提，README 也明講 3B 是為「具備可靠驗證訊號的任務」而設計。一旦任務沒有自動判分器，整套測試時擴展就沒有立足點。

倉庫裡實際拿得到什麼，拿不到什麼

這個 GitHub 倉庫本身主要是文件與圖表。README 的內容集中在技術報告連結、模型下載位址、新聞時程與 benchmark 表格。權重並不在倉庫裡，而是放在 Hugging Face 與 ModelScope，兩個版本各有對應頁面：WeiboAI/VibeThinker-1.5B 與 WeiboAI/VibeThinker-3B。

倉庫的 topics 標籤列出 aime2025、livecodebench、huggingface、reasoning-language-models 等，主語言是 Python，但 README 中沒有出現任何安裝指令、依賴清單或推論範例程式碼。它也沒有發布任何 release。這意味著要跑起來，你得自己去找 Hugging Face 頁面上的使用說明，或依賴 transformers 對 Qwen2.5 系列架構的既有支援。

我在這裡不做推測。以目前提供的材料，無法確認倉庫是否附帶評測腳本、是否提供 vLLM 或 SGLang 的部署範例、或 CLR 是否已整合進推論程式。這些都需要在下載權重後自行核對。

授權方面，倉庫標示 MIT。但模型權重的授權條款是另一回事，README 沒有說明。若你的使用情境涉及再散布或商用，這是採用前必須先確認的第一項。

基準數字的讀法：三個數學競賽與一個程式競賽

README 對 1.5B 版本給出的核心數字是 AIME24 80.3、AIME25 74.4、HMMT25 50.4，並稱其超越參數大 400 倍以上的初版 DeepSeek R1。3B 版本則是 AIME26 94.3、HMMT25 89.3、LiveCodeBench v6 的 80.2 Pass@1，以及在 2026 年 4 月 25 日至 5 月 31 日間的 LeetCode 週賽與雙週賽取得 96.1% 接受率。

這些數字的共同點是全部來自可自動判分的競賽題。這個選擇不是偶然，而是 SSP 與 CLR 能夠成立的前提。也因此，把這些數字外推到一般任務是危險的。一個在 AIME 上拿到 80 分的 1.5B 模型，不代表它在需要常識推理或長篇論證的任務上有同等表現。

另一個需要留意的地方是版本命名與時間軸。README 的新聞區顯示 1.5B 於 2025 年 11 月開源，3B 於 2026 年 6 月釋出，而 3B 的評測涵蓋 AIME26 與 2026 年的 LeetCode 賽事。這是一份持續更新的專案，不同版本的基準不可直接互相比較，因為題目集與時間點都不同。

它不適合的場合：沒有驗證器就沒有優勢

這個專案最明確的失敗模式，是把 SSP 訓練出來的模型用在無法自動判分的任務上。整套方法論從 SFT 的多樣性蒸餾到 RL 的訊號放大，再到 CLR 的測試時擴展，全都建立在「正確答案可以被機器判定」這個條件上。數學題有標準答案，競程題有測試案例，這兩類任務成立。產品文案、法律摘要、多輪客服對話不成立。

第二個限制是規模本身。1.5B 與 3B 的稠密模型在知識密集型任務上沒有辦法與數十億到數千億參數的模型競爭，README 也沒有聲稱它們可以。專案選擇的是窄而深的策略：在少數可驗證領域做到極致，放棄廣度。

第三個限制與部署有關。README 提到 CLR 會提升分數，但沒有說明它增加多少推論延遲或需要多少次採樣。測試時擴展本質上是用算力換準確率，對延遲敏感的線上服務而言，這個交換未必划算。要判斷是否採用 CLR，得先量測它在你硬體上的實際開銷。

與大型推理模型的路線差異

最直接的替代方案是直接使用 DeepSeek R1 這類大型推理模型，或透過 API 呼叫前沿模型。兩者的差異不在分數高低，而在資源曲線的形狀。大型模型靠參數量承載能力，推論時每一個 token 都要動用完整的權重；VibeThinker 這條路線靠後訓練把能力壓縮進小模型，推論成本隨參數量線性下降，但能力上限被訓練資料的領域範圍鎖住。

另一個替代方向是對現有的小模型做一般的 SFT 或 DPO。差別在於 SSP 明確把「輸出多樣性」當作要被保護的資源，先刻意維持多樣性再篩選訊號，而標準 SFT 往往在早期就把分佈收窄到單一解法模式。README 把這稱為 Two-Stage Diversity-Exploring Distillation，這是它與一般微調流程最實質的分歧點。

如果你的團隊已經有一套成熟的 RLHF 流程，並且任務涵蓋多個領域，那麼自建流程可能比套用 VibeThinker 更合適，因為後者的訓練資料與評測都集中在數學與競程。選擇的關鍵不是哪個模型更強，而是你的任務是否落在它的驗證訊號範圍內。

維護成本與採用前該查證的事項

從倉庫的更新節奏看，這是一個活躍專案：2025 年 11 月釋出 1.5B，2026 年 6 月釋出 3B，2026 年 8 月釋出 CLR 的獨立論文與程式碼，最後一次 push 是 2026 年 8 月 14 日。活躍意味著能力會持續更新，也意味著版本之間的基準與介面可能變動，採用時要鎖定具體版本而非依賴 main 分支的狀態。

維護成本主要落在三處。第一是權重下載與部署，你需要自行確認 Hugging Face 頁面上的推論方式。第二是 CLR 的整合，它是否已進入官方推論程式碼，目前無法從 README 確認。第三是授權，倉庫是 MIT，但權重條款未在 README 說明，商用或再散布前必須另行查證。

具體的下一步很單純：先下載 WeiboAI/VibeThinker-1.5B 的權重，在你自己的硬體上跑一次 AIME24 或 AIME25 的題目，比對 README 給出的 80.3 與 74.4。如果重現不出來，後續的 3B 與 CLR 評估就不必進行。

編輯結論

如果你要的是在單張消費級或工作站 GPU 上跑數學與競程推理，而且能接受答案可被自動驗證這個前提，VibeThinker-1.5B 值得先下載權重做一次 AIME 或 LiveCodeBench 的實測；VibeThinker-3B 則適合已經有 1.5B 基線、想比較 CLR 測試時擴展是否划算的團隊。不要把它用在開放式寫作、多輪工具調用或需要長篇事實一致性的場景，README 描述的驗證訊號在那些任務上並不存在。動手前先確認三件事：倉庫本身是否提供可重現的評測腳本、權重是否以 Apache 2.0 或同等寬鬆條款釋出（README 只寫了倉庫層級的 MIT）、以及 CLR 的實作是否已隨權重一併開放。這三項若有一項落空，採用計畫就應該先擱置。

官方來源

1. Issues
2. License: MIT
3. README
4. WeiboAI/VibeThinker on GitHub