AesCode-8B vs MathForm-8B：兩者都是 8B 微調模型，其輸出可由機器檢查

AesCode-8B與MathForm-8B相隔八週問世，兩者都來自程式碼倉庫，而非新聞稿，而這個巧合比乍看之下更有意思。兩者都從 Qwen3 系列檢查點出發。兩者都把全部訓練預算花在一種狹窄的輸出形態上。而且兩者都是圍繞著一個檢查器打造：MathForm-8B 是對照 Lean 4 編譯器的判定來訓練，AesCode-8B 則是透過在沙箱瀏覽器中渲染每個候選頁面，並讀回 DOM、計算後樣式與螢幕截圖來評分。兩者都不是聊天機器人，也都不想變成聊天機器人。區別兩者的是機器能驗證什麼、不能驗證什麼——而就兩者中較新的那一個而言，則是當一半分數來自一位無人指名的評審時，會發生什麼事。

這些發布紀錄並不對稱。MathForm-8B 出自 OpenBMB，其模型卡標示的發布日期為 2026-08-14；它建構於 Qwen3-8B 之上，並以 FormalVerse 訓練，該語料庫約有 367,000 個經驗證的 Lean 4 範例，訓練方式為先進行監督式微調，接著以強化學習進行訓練，並以 Lean 編譯與語意一致性檢查作為獎勵訊號。AesCode-8B 的檔案中從頭到尾都沒有標示任何發布日期。微軟於 2026-09-29 建立了 Hugging Face 儲存庫，於 2026-10-07 03:35 UTC 以「Release AesCode-8B」的訊息提交權重，並於 2026-10-08 在 GitHub 上發布訓練程式碼。這兩起事件都沒有任何公告，模型卡的引用資訊寫著「Under review, 2027」，而截至本文撰寫時，該儲存庫顯示有兩次下載。它是從 Qwen3-VL-8B-Instruct 微調而來，這一點值得注意，正因為它與 MathForm-8B 的祖先並非同一個。

血統解釋了大部分的分裂。

Qwen3-8B 與 Qwen3-VL-8B-Instruct 共享同一個世代與家族名稱，但工作並不相同。Qwen3-8B 是純文字通才：總參數量約 82 億，其中約 70 億為非嵌入參數，採用分組查詢注意力，原生上下文為 32K 詞元，可透過 YaRN 擴展至 131K，且訓練涵蓋 119 種語言與方言。Qwen3-VL-8B-Instruct 則是視覺語言手足模型，也是 AesCode-8B 的起始檢查點——已發布的 AesCode 設定就是直接套用 Qwen3-VL 配方，具備 36 個隱藏層、隱藏層大小 4,096、32 個注意力頭搭配 8 個鍵值頭，以及 151,936 詞元的詞彙表。

那個分支在兩個專家模型中任何一個接受訓練之前，就已決定了它們的輸入端。MathForm-8B 接收文字，並以形式語法輸出文字。AesCode-8B 接收文字以及可選的參考圖片，並輸出文件。

• 基礎 — MathForm-8B：Qwen3-8B，純文字。AesCode-8B：Qwen3-VL-8B-Instruct，可輸入圖像與文字。

• 參數量 — MathForm-8B：約 8.2B。AesCode-8B：以 bf16 格式分為四個分片，約 8.8B，Hugging Face 將其四捨五入為 9B。

• 訓練資料 — MathForm-8B：FormalVerse，約 367K 個已驗證的 Lean 4 範例。AesCode-8B：3,000 個冷啟動示範，接著對 7,408 個提示進行 GDPO 強化學習，共 400 步。

• 輸出由什麼檢查 — MathForm-8B：一套 Lean 4 編譯器，外加針對原始問題的語意一致性檢查。AesCode-8B：在沙箱中執行的 Playwright 渲染，搭配六個確定性驗證器與一份由模型評分的評分規準。

• 授權 — 兩者皆採用 Apache 2.0，皆無使用限制，且皆承襲 Qwen3 系列主幹。

• 託管於任何地方——就我們所能找到的，兩者皆非。

「verifiable」的兩種不同含義

這個區別值得慢慢釐清，因為「機器可檢核」這個說法兩者都會用到，但它的意思並不一樣。

MathForm-8B 的檢查器是一個證明助理。Lean 4 要麼接受一個陳述，要麼不接受，而這個判定不是意見、評分標準或評審口味的問題。訓練迴圈指向那個訊號：在 FormalVerse 上的 SFT 階段教導從非正式問題到形式定理陳述的對應，該陳述帶有 imports 標頭與具名定理；而 RL 階段則利用編譯加上一致性檢查來精煉它，該檢查會問形式化是否仍表達了原始問題所說的內容。編譯是二元的，且任何使用相同 Lean 版本的人都能重現。一致性檢查是較軟的那一半，而正是在這一半，所報告的數字會變得薄弱——這正是已發表結果所顯示的。

AesCode-8B 的檢查器是一個渲染器。候選項目會在沙箱化的 Playwright 瀏覽器中渲染，並封鎖外部請求，而測試框架會讀回 DOM、計算樣式、邊界框、主控台狀態以及螢幕擷取畫面。六個確定性通道會為可解析的項目評分——執行、精確文字、邊界行為、表格與圖表資料、語意版面、空白——而第七個通道 Visual Graph Rubric 則透過圖形綁定的是／否問題來評分幾何與配置。表格必須是真正的 HTML 表格，圖表必須是 ECharts 規格，這是一項真正發揮作用的限制：它迫使輸出成為驗證器可解析的形式。確定性的一半確實可重現。視覺的那一半則由一個文件未具名的視覺語言模型評判，這意味著實驗室之外沒有人能重現它。

所以，誠實的比較並不是「一個經過驗證，一個沒有」。而是 MathForm-8B 的主要訊號是編譯器，次要訊號是一致性檢查；而 AesCode-8B 的主要訊號是一組確定性的 DOM 斷言，次要訊號則是模型的意見，兩者卻被包裝在同一個總分之中。

每一項所報告的內容，以及那有什麼價值

MathForm-8B 在六項基準測試中回報，語法檢查下的平均 Pass@8 為 88.06%，一致性檢查下則為 72.37%。各基準測試之間的落差才是有趣的部分：FormalIMATH 上的一致性為 95.06%，ProverBench 上為 94.83%，接著 FATE-H 上是 63%，FATE-X 上則是 37%。最後這兩項是困難且貼近現實的陳述，而從九十幾% 掉到三十幾%，正是這項能力真實的樣貌。所有這些數字都是廠商報告且未經重現的，而基準測試的組合也偏重於較容易的資料集。

AesCode-8B 在 Microsoft 的 300 個樣本資訊圖表評分標準上回報總分 82.94——文字 94.06、邊界 88.36、圖表 87.79、規則 90.07、內容 86.41、版面 87.80、風格 53.21、視覺 75.80——每個提示三次生成，且不做選擇。Microsoft 也回報，在同一套評分標準上，它勝過以參考為條件的 GPT-5.5 的 81.28，以及 Claude Opus 4.8 的 80.39；嚴重的畫布溢出失敗在 300 個樣本中有 4.3% 會重複出現；以及 32B 伴生模型與其自身主幹模型之間相差 22.4 個視覺分。每一個數字都是供應商自己的，是在供應商自己的任務上，並依供應商設計的評分通道來評分。

這兩組數字根本完全無法互相比較。它們沒有共同的任務、共同的指標，也沒有共同的評判者。把 88.06% 放在 82.94 旁邊，就等於是把 Lean 形式化的通過率拿來跟資訊圖表的整體分數相比，而且這兩個模型從來沒有針對對方所做的事情接受過評估。

有一項不對稱值得特別點名，因為它對較新的模型不利。MathForm-8B 的頭條指標內建了外部裁判：任何人都可以安裝 Lean、載入相同的基準，並檢查那些陳述是否能編譯。AesCode-8B 的頭條指標則沒有——確定性的驗證器或許能由有心的外部人士重新執行，但分數中視覺的那一半，取決於論文並未指明的評審。未經重現的編譯器通過率，是比基準表更弱的主張，但仍比一份未經重現、且內含匿名評分者的評分規準分數更強。

執行它們與任一得分是兩回事

這兩者目前都是自架與否的決策。MathForm-8B 明顯便宜得多：它大約是 8.2B 的純文字檢查點，生成預算約為 16K 個 token 的 Lean 輸出，可量化到單張中階顯卡上。AesCode-8B 則是 8.8B 的視覺語言模型，其服務路徑同時要處理圖像與文字；針對這張卡的指令是 vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576，而 17.5 GB 的 bf16 權重，加上 24,576 個 token 與兩張圖像的 KV 快取，意味著 24 GB 顯卡很吃緊，40–48 GB 才是現實中的下限。如果你想為自己的輸出評分，還得把一套渲染堆疊編入預算，因為關於這個模型的每一項品質宣稱，都是這樣得出來的。

更大的隱藏成本在於，這兩個模型都是你將永久採用的專才模型。一個現在需要形式化與文件生成的團隊，得同時維護兩條 8B 推論服務路徑、兩套提示格式、兩種故障樣態，而且兩個模型都無法吸收對方的工作。這正是路由層存在的理由：把專才模型留在經濟效益與資料處理都足以支撐自持 GPU 的地方，並把一般流量送到托管於同一端點之後的服務。具體來說，這兩個基礎模型的通才手足是可以呼叫的——Qwen3-VL-8B-Instruct，每百萬輸入權杖 $0.18、每百萬輸出權杖 $0.70，上下文長度 131,072 個權杖，以及 Qwen 3.8 系列和其他開放檢查點——全都透過OrcaRouter 的單一 API，涵蓋 200 多個模型，供應商定價以 0% 加價原樣傳遞，並在供應商之間自動容錯移轉。這兩個專才模型都無法在這裡、也無法在我們能找到的任何其他地方進行路由；能被路由的是當狹窄工作完成後你所退回使用的通才模型，而這正是「試用一個研究檢查點」與「讓它成為承載關鍵的依賴」之間的差別。

如果你真的非選不可，就在它們之間做選擇

當成品必須能編譯時，就選 MathForm-8B。題庫轉換、供證明器使用的形式化語料庫、為以 Lean 為基礎的工具鏈預先格式化陳述——這就是它完整的工作內容，而它是兩者中唯一為此受過訓練的。在界定範圍時，請認真看待 FATE 的數字：在最難的真實陳述上，大約三分之一會輸出一致的結果，而且無論如何你都會建立人工審查步驟。

當成品必須要能渲染時，就選 AesCode-8B。投入一份需求說明，產出一份可編輯的 HTML 文件，表格就是表格，圖表則是圖表規格，而且整份東西都能在 Git 裡 diff。請接受 Style 上限——53.21，這個維度定義為交付前無需再進行任何視覺修訂——作為還剩多少編輯工作的誠實衡量標準，並接受 24,576 權杖的上下文只在單一資訊圖表頁面上驗證過，而不是人們真正想要的多投影片簡報。

大多數團隊實際上會面臨的選擇，其實既不是前者也不是後者。而是：這些狹窄的專門模型之一，究竟是否值得部署，或者它背後的通用模型，透過 API 呼叫，是否已足夠接近你現有的用量。那只需花一個下午做提示測試，而不是買一張 GPU，而且兩張卡本身的數字就給了你運行它的理由：MathForm-8B 的硬集一致性為 37%，AesCode-8B 的風格分數為 53%，所以兩者都不是你會未經監督就放進管線的模型。

這兩次發布告訴你，模型如今是如何推出的

兩個 8B 微調模型，相隔八週，出自兩個不同實驗室，在沒有公告、沒有產品頁面、也沒有獨立評估的情況下發布，兩者都圍繞著驗證迴圈打造，都採 Apache 2.0，卻都沒有任何人提供服務。這個模式本身比任何一個模型都更像是故事所在。研究方法已經移入獎勵函數——OpenBMB 的編譯器訊號、Microsoft 的解耦跨模態通道——而公開發表的成品已變成訓練配方加上權重，論文則晚些才出現，甚至根本不會出現。

對任何讀到像這樣一份比較的人來說，這意味著：在一段時間內，你所能得到的就只有廠商自己提供的數字，而真正有用的問題不是那些數字有多高，而是它們有多可檢驗。AesCode-8B 的溢出率與其 Style 上限，都是被包裝成失敗的可檢驗說法。MathForm-8B 的 FATE-X 一致性數字也是同一回事。那些才是該讀的數字，也是當檢查器能夠端到端重現時，你該立刻回頭親自重新跑一遍的數字。