什麼是 MathForm-8B？OpenBMB 低調發布的自動形式化，將數學轉化為 Lean 4

openbmb/MathForm-8B 是 OpenBMB 推出的全新自動形式化模型，可將自然語言的數學敘述轉譯為 Lean 4；而它的發布幾乎沒有公告：權重、資料集與論文於同一天（2026-08-14）出現在 Hugging Face 與 arXiv 上，總標題為「MathForm: Scaling Mathematical Autoformalization with Knowledge Retrieval and Verification-Guided Refinement」。這低調的發布背後藏著一項不尋常的結果——一個 8B 參數模型，在六個基準上報告平均 Pass@8 分數：語法檢查為 88.06%，更嚴格的一致性檢查為 72.37%；論文聲稱這擊敗了數個專門的 32B 自動形式化模型。這是一篇「目前所知」的報導：以下所有標示「from the repo」的內容皆直接來自模型卡、資料集卡與論文，而任何尚未經獨立確認的部分也都會如此標明。

關鍵要點

• MathForm-8B 是一個 8B 參數、Apache-2.0 授權的自動形式化模型：它讀取非正式的數學問題，並撰寫帶有命名標頭的 Lean 4 定理陳述，以便之後進行證明。

• 它從 Qwen3-8B 微調而來，基於 FormalVerse——這是一個由 OpenBMB 建構、包含約 367,000 個已驗證範例的 Lean 4 資料集，其建構過程運用了知識檢索與編譯器檢查的精煉方法，隨後並使用強化學習進行訓練，利用 Lean 編譯與語意一致性回饋。

• 報告的數字（供應商報告、未經重現）：在語法檢查下平均 Pass@8 為 88.06%，在一致性檢查下為 72.37%，在論文自身的表格中擊敗了 7B 到 32B 的專業自動形式化器。

• 它尚未對外公布、推出時未登上主要的付費 API，也尚未經過獨立基準測試 — 這三個缺口對生產環境的採用至關重要。

• 服務是自託管的：Transformers、vLLM 或 SGLang，全部都提供與 OpenAI 相容的端點。

發行版實際包含的內容

{{1}}三個工件在2026-08-14的幾分鐘內相繼上線，這正是協同但未經宣布的發布所呈現的樣貌：{{/1}}

• 模型倉庫 openbmb/MathForm-8B — 一個採用 BF16 的 8B 因果語言模型，帶有聊天模板、四個 safetensors 分片，採用 Apache 2.0 許可證。

• 資料集倉庫 openbmb/FormalVerse — 一個 Lean 4 自動形式化資料集，包含約 367,000 個已驗證的範例，同樣採用 Apache 2.0 授權。

• 論文 arXiv 2608.14221 — 共 25 頁，描述資料建構管線、訓練配方，以及六項基準評測。

README 中的 GitHub 程式碼連結在撰寫本文時仍是佔位符，因此評估管線和 Pass@k 腳本雖有承諾但尚未公開。README 確實提到編譯檢查需要執行中的 Kimina Lean Server，且實驗使用 Lean 4.21.0。

上述儲存庫頁面是目前這個版本對外的全部公開內容：一張模型卡、四個 safetensors 分片、一個聊天模板，以及一份同時作為唯一文件的 README。截至撰寫本文時，並不存在任何發布公告的部落格文章。

MathForm-8B 的作用 — 以及為何它是項狹窄的工作

自動形式化是定理證明之前的一步：給定一個用平實英文表述的數學問題（例如「證明對每個實數 x，x² 皆為非負」），模型必須產出一個在 Lean 4 中形式正確的陳述——包括匯入（imports）、型別和定理標頭——讓人類或證明器接下來可以處理。這與實際做數學是一項截然不同的技能，因為模型必須將自然語言概念對應到 Mathlib 的精確定義與型別階層上。一個通過型別檢查但暗中削弱原題的陳述（例如用「(2^5) ∣ (13^4 − 11^4)」取代完整的整除性主張）是典型的失敗模式，也正是論文區分「語法檢查」（是否編譯通過）與「一致性檢查」（語意上是否為同一陳述）的原因。

模型卡展示了預期的使用模式：你提供一個包含非正式問題和期望定理名稱的提示詞，它會返回一個 Lean 4 陳述，形式為 code>theorem my_favorite_theorem : ... := by sorry/code> — 其中 code>sorry/code> 讓證明義務保持開放。這種分工很重要：MathForm-8B 是形式化器，而非證明器。建構 Lean 工具的團隊使用它將題庫轉換為機器可驗證的形式。

它是如何訓練的

論文的做法分為兩個階段。首先，OpenBMB 使用一套流程建構 FormalVerse，該流程（1）在生成前從 Mathlib 檢索相關定義與既有形式化內容；（2）生成候選命題；（3）利用 Lean 編譯器診斷與語意一致性回饋來精煉候選命題；（4）僅保留通過兩項檢查的樣本。接著，這個經驗證的語料庫被用於監督式微調，隨後再以 Lean 編譯與語意一致性所產生的獎勵訊號進行強化學習。

資料集卡片具體呈現了資料的風貌：每一筆條目都將一個非正式陳述與一個經驗證的形式化陳述配對，並以來源（例如 AceReason-Math）和主題標籤（如數論等）標記。由於每個範例在進入訓練前都通過了真實編譯器的檢查，模型學習的是已知良好的陳述，而非模型原始輸出的內容。

基準測試表，如實標註

本節中的所有數字均由供應商根據論文（arXiv 2608.14221）回報，尚未經獨立重現。Pass@8 意指模型每個問題有八次嘗試機會，只要任何一次通過即算成功；這是比 pass@1 更友善的指標，應理解為「在給定預算下，模型能產生正確陳述的頻率」。

• MathForm-8B 平均 — 語法檢查 88.06%，一致性檢查 72.37%。

• 根據基準測試，SC 接著 CC：FormalIMATH 100.00 / 95.06，ProverBench 100.00 / 94.83，CombiBench 93.00 / 47.00，FATE-M 99.33 / 97.33，FATE-H 82.00 / 63.00，FATE-X 54.00 / 37.00。

• 困難的集合才是誠實的指標：FATE-H CC 63% 和 FATE-X CC 37% 顯示模型在最困難子集上的上限，而在較簡單的 FormalIMATH 與 ProverBench 上則有 95% 以上的 CC。

• 論文列出的最佳8B基線——ReForm-8B 81.76 / 66.21、Goedel-Formalizer-V2-8B 78.24 / 60.08——以及最佳32B基線——ReForm-32B 81.61 / 68.41、Goedel-Formalizer-V2-32B 78.28 / 63.74、StepFun-Formalizer-32B 63.65 / 44.47——全都落後於MathForm-8B的88.06 / 72.37。

• 僅 SFT 的檢查點（RL 階段之前）分數落在 84.38 / 66.53，因此強化學習階段平均約可再增加 +3.7 SC 與 +5.8 CC，其中在困難集上的提升最為顯著。

最值得存疑的強力宣稱包括：FormalIMATH 與 ProverBench 上 100.00 的 SC 分數（簡單題組 100% 編譯通過是這些題組已趨於收斂的危險訊號），以及與未在完全相同的條件下重新執行之 32B 模型的比較。FATE-H 與 FATE-X 上的一致性檢查（Consistency Check）數值，才是最有可能在獨立測試中存活下來的數據。

什麼尚未被確認

• 目前不存在獨立的評測。截至撰寫本文時，尚無第三方透過公開的測試框架執行 MathForm-8B，且評測程式碼尚未發布。

• 沒有服務上線公告。OpenBMB 尚未發布上線部落格、定價頁面或 API 端點。「低調發布」的說法完全是字面意義。

• RL 獎勵權重、訓練預算和硬體不在模型卡中；它們僅存在於論文裡。

• 8B 模型能否泛化到 Lean 4.21.1+ 或非 Mathlib 導入，尚未測試。

如何執行它

自行架設是目前唯一的途徑。README 記載了三種方式，全部都具有 OpenAI 相容的聊天端點，位於 code>localhost:8000/v1/chat/completions/code>：

• Transformers — code>AutoModelForCausalLM.from_pretrained("openbmb/MathForm-8B", torch_dtype=torch.bfloat16)/code>，然後使用聊天模板生成。

• vLLM — code>vllm serve openbmb/MathForm-8B --served-model-name MathForm-8B --dtype bfloat16 --max-model-len 16384/code>。

• SGLang — code>python -m sglang.launch_server --model-path openbmb/MathForm-8B --served-model-name MathForm-8B --dtype bfloat16 --context-length 16384/code>.

「README 建議將 temperature 設為 0.6、top_p 設為 0.95，並最多生成 16384 個新 token——正式陳述往往篇幅冗長，因此這個寬裕的生成視窗才是實際需要為之編列預算的系統需求。」

為什麼「8B 勝過 32B」這部分很重要

如果這些數字經得起考驗，MathForm-8B 就是迄今為止最有力的論據，證明自動形式化的瓶頸在於資料品質與驗證，而不是原始參數數量。論文自身的表格顯示，多個 32B 專門模型（ReForm-32B、Goedel-Formalizer-V2-32B、StepFun-Formalizer-32B）的表現落在一個基於編譯器檢查過的語料庫所訓練的 8B 模型之下。對於目前運行 32B 形式化模型的團隊來說，這是一項實質的成本改變——BF16 的 8B 模型能放進大多數 32B 模型無法放進的單張 GPU，且每個 token 的服務速度更快。

這也構成了模型生態持續呈現的一個誠實抉擇：狹窄的專用模型能出色完成一項經驗證的任務，相對於通用模型能嘗試許多任務卻沒有驗證保證。具體到形式化驗證，專用模型有編譯器檢查其輸出——正是這個特性，讓具備自動故障轉移的路由器放在它前面時令人安心。像 OrcaRouter 這樣的路由層橫跨 200 多個模型，按服務商列表價格原價傳遞，讓你可以將測試路徑指向像這樣剛發布幾天的開放權重模型，並在它一停滯就回退到經實證的模型——你可以採用一次低調的發布，而不必把生產路徑押注在它身上；如果某家服務商日後將其列入，Token 價格也不會有任何加價。

接下來要看什麼

能讓這個專案從「有趣的 repo」變成「值得信賴的工具」的三件事：GitHub 評測程式碼真正出現；首次以 pass@1 而非 pass@8 對 FATE-H 和 FATE-X 進行獨立評測；以及任何 OpenBMB 公告——無論是新增託管途徑，還是附帶消融數據的論文 v2。在至少其中一項落地之前，應將頭條分數視為方向性參考——架構和訓練資料的想法才是具有持久價值的新聞，而非確切的百分比。