一座體素寶塔、Token 數減少 10%，以及 OpenBMB 真正背書的那一句話

本週關於 MiniCPM-V 4.7 35B-A3B 最常被引用的句子並不在其模型卡中。它是一則推文，發佈於 2026 年 10 月 13 日，寫道：「MiniCPM-V 4.7 35B-A3B 不僅使用了更少的 token，還產生了比 Qwen 3.6 35B-A3 更好的體素寶塔。」它所指向的演示是一段影片，顯示兩個語言模型各自編寫 3D 體素日本寶塔的程式碼，並排渲染。這是一個真正有趣的產物——它展示了一個視覺語言模型從圖像提示中以三維方式重現一個已建成的結構，這比為其生成說明文字更困難。但值得將那則推文是什麼與不是什麼區分開來，因為三種不同的說法被融合成了一句話，而且它們有三種不同的支持程度。MiniCPM-V 4.7 35B-A3B 是來自 OpenBMB 的真實檢查點，大約一週前發布；Qwen3.6-35B-A3B 是九個月大的開源權重競爭對手，同樣是 Apache-2.0，同樣是相同標稱規模的稀疏專家混合模型。以下所有內容都是關於它們周圍的效率聲明中哪些是可驗證的，哪些只是一張圖表的 JPEG 檔。

三個主張共用一句話

這則推文把三件可以分開的事綁在一起，而它們值得分開來看，因為其中只有一件是有明確記載的。

• 「使用了較少 token」——這是針對單一任務 token 消耗量的可量測陳述。與該示範一同流傳的數字，是比 Qwen3.6 35B-A3B 少 10% 的 token。那個數字來自執行這項比較的第三方創作者，而非 OpenBMB 的評估；而且它只是單一的提示詞配對，不是基準測試。

•「產出了更好的體素寶塔」——這是透過觀察兩座渲染出來的寶塔所作出的判斷。這裡沒有評分規準、沒有評分工具，也沒有獨立第三方。這種主張，人類三秒鐘就能提出，基準測試卻根本無法提出，因為「更好的寶塔」沒有基準真相。

• 「效率加上品質才是真正的戰場」——這部分是一個論點，而且恰好就是 OpenBMB 在模型卡中確實以書面形式、附上數字所論證的那個論點。只不過，真正流傳開來的並不是這句話。

這件事很重要，因為前兩項主張令人印象深刻，而第三項才是站得住腳的。如果你正在決定要不要花 70 GB 的下載量在某個檢查點上，你要的是第三項。

OpenBMB 實際寫了什麼，以及是在什麼時候

先說時間軸，因為它在轉述過程中被壓縮了。權重是悄悄上架的：openbmb/MiniCPM-V-4.7-1B於 2026 年 10 月 6 日 17:40 UTC 建立，openbmb/MiniCPM-V-4.7-35B-A3B則在 10 月 7 日 07:07 UTC 建立。當時兩者都沒有附上模型卡、授權標籤或基準測試結果——這點本站當時已有報導，而對一個 350 億參數的上傳來說，這種情況相當反常。六天後，也就是 2026 年 10 月 12 日，OpenBMB 一口氣提交了所有文件：模型卡、Apache-2.0 授權、評估圖表、以新系列為開頭改寫的儲存庫 README，以及一則公告。那天參數並沒有改變，改變的是說法。

所以誠實的說法不是「MiniCPM-V 4.7 35B-A3B 本週發布」。而是「MiniCPM-V 4.7 35B-A3B 本週變得可解讀」。關於它如今可被引用的一切，要不是在 6 日和 7 日上傳但沒有文件記錄，就是在 12 日寫成，而且屬於廠商說法。

模型卡確實提出的主張

以下是卡片上逐字照錄的句子，它比推文所說的範圍更窄：在 Instruct 模式下，35B-A3B 變體「在比 Qwen3.6 35B-A3B 更少的推論時間內達到更高的整體分數」。就這樣。沒有 token 數量，沒有差距幅度，也沒有以文字敘述的逐項基準細分。其背後的證據是一張散佈圖——縱軸是平均評估分數，橫軸則是以對數刻度表示的推論時間（秒）——圖中 MiniCPM-V 4.7 35B-A3B 位於 Qwen3.6-35B-A3B 的左上方。圖表本身的註腳將該平均值定義為五項基準的平均：MMStar、MMMU-Pro、CharXiv reasoning、BLINK 與 MathVista。圓圈代表 Instruct 模式，菱形代表 Thinking 模式。

那是一項關於二維取捨的真實且具體的主張，也是這次發布中最有力的內容。同樣值得留意的是，這張圖表無法告訴你的事：圖上的資料點沒有數值標籤，因此你無法讀出分數或時間，只能看出一個方向。如圖所繪，這個方向同時在兩個軸上都對 MiniCPM 有利。

而且它是由廠商量測的。這張模型卡的評估數據附有這句話：「結果來自公開報告，以及我們使用官方檢查點所做的本地評估。」所謂本地評估，指的是 OpenBMB 的硬體、OpenBMB 的評測框架、OpenBMB 的模式選擇。對模型卡來說，這是正常做法；但把它洗成事實，就不正常了。沒有獨立第三方在共用的評測框架上跑過這兩個檢查點。也沒有任何排行榜收錄過這兩項結果中的任何一項。截至本文撰寫時，這個說法恰好只有一個來源，而這個來源正是販售該模型的一方。

Token 效率應該是從哪裡來的

效率論點並不建立在基準測試圖表上。它建立在三項工程選擇上，而這些選擇值得理解，因為它們決定了這項優勢是否能轉移到你的硬體上。

• 前瞻專家排程（LES）—— 主打技術。稀疏混合專家模型儲存的參數量遠多於每個 token 實際啟用的參數量，而在無法將所有專家都保留在記憶體中的裝置上，權重會不斷分頁載入與移出，導致解碼停滯。LES 使用跨層路由預測，預先載入下一層可能需要的專家，並優先計算真實路由器實際選中、且恰好已載入的專家。OpenBMB 特別說明，該預測僅用於驅動預取與排程；模型的 token 層級路由維持不變，而預測器漏掉的專家仍會被載入並評估。該卡聲稱，藉此可在真實裝置上達到 5 倍加速，且沒有能力損失。

• 細粒度逐層量化 — 縮小專家權重佔用量與記憶體流量，這是讓裝置端載入模式得以契合的另一半。

• DSpark 推測取樣 — 一條配對的草稿模型路徑，另外以 openbmb/MiniCPM-V-4.7-35B-A3B-DSpark 個別發布，並與排程及量化工作整合。

這些層層疊加後，會產生該發行版本最亮眼的數字：在 iPhone 17 Pro Max 上使用約 3 GB 記憶體，每秒可處理超過 13 個 token。這是廠商的數據，跑在廠商硬體上、搭配廠商軟體——一款由 OpenBMB 撰寫的應用程式。這種宣稱，要嘛就代表整個產品，要嘛就什麼都不是；而目前公司外部的人無從查核，因為要重現它，必須要有手機展示所運行的裝置端堆疊。

Token 效率確實存在，但在這裡它是矩陣，不是純量。

這次發布中有個細節，在每一份關於它的摘要裡都被抹平了，而它正是真正主導代幣經濟的那個細節。

MiniCPM-V 4.7 35B-A3B 支援混合的 4x 與 16x 視覺 token 壓縮，可依每次請求選擇。16x 設定會合併視覺 token 以換取速度；4x 則保留四倍數量，以維持細節。此卡的預設值為 16x，且該參數必須同時傳遞至聊天範本與 generate 呼叫，否則佔位符數量與視覺編碼器會不一致。

• 廠商自家的視覺語言比較表記錄了每個模型列所使用的壓縮設定。在該表中，MiniCPM-V 4.7 35B-A3B 那一列是 4x——也就是保留細節的設定，亦即代價較高的那個——而 Qwen3.6 35B-A3B 那一列則是 16x。31B Gemma 4 那一列列為 9x；兩個 27B Qwen 列則為 4x。

• 註腳明確指出 MiniCPM-V 4.7 支援任一設定，而表格中的其他模型僅支援固定壓縮率。

把這些放在一起讀，情況就不一樣了。如果 MiniCPM 那一列是在耗費大量 token 的設定下取得它的視覺語言分數，而 Qwen 那一列是在節省 token 的設定下取得分數，那麼這兩欄比較的其實是不同份量的視覺細節，而效率的故事就不是「相同輸入、更少 token」——而是「可調整的輸入，而這一欄在品質上勝出」。這比那則推文的說法更有意思，也更誠實，而 OpenBMB 是把它放在註腳裡發表，而不是拿它來當開頭重點。

這也意味著你真正在乎的那個數字——每單位視覺細節所對應的 token 數——根本無法從這張表上讀出來。那需要讓兩個模型在相同設定下運行，而這點沒有人發表過。

該表格，連同附帶的注意事項

這張卡隨附兩份廠商表格，一份是視覺語言，一份是語言，兩者都採 Instruct 模式，且都是與一組包含兩個 35B-A3B 等級 Qwen 模型、一個 31B Gemma 和兩個 27B Qwen 的陣容相比。下方數字是從廠商自家的 PNG 圖表讀取而來，而這個但書是結構性的：這些數字在該圖表中只以像素形式存在，並非表格，因此以下內容是透過機器讀取擷取，可能會有小幅轉錄錯誤。

• OCRBench — MiniCPM-V 4.7 35B-A3B 以 91.20 對上 Qwen3.6 35B-A3B 的 90.40。0.8 分的差距，而且還是在廠商自家跑出的結果上。

• OmniDocBench v1.6 — MiniCPM 約 98.2，而 Qwen 模型約 93.3；這是表中最大的單一差距，也是若真能重現時最關鍵的一項，因為文件解析通常是 token 預算花費最多的地方。

• MMMU — 約 80.2 對上 80.0，以圖表影像的解析度來看，可謂難分高下。

• MMMU-Pro — 約 69.7 對 67.7，而在某一行中，27B Qwen 比這兩者都高。

• 語言表 —— 形狀相同，但在指令遵循與程式碼方面有更醒目的儲存格。IFBench 列為約 47.7 對上 35.3，而 LiveCodeBench-v6 約為 97.0 對上 54.3。這兩者差距大到，在其他人重跑之前，應被視為本次發布中最不可信的儲存格：兩個規模相近的開放 MoE 模型之間，在一項程式碼基準上出現 43 分的差距，而且是由兩方之一所測量，這種主張需要第二個量測工具。

廠商回報、廠商自行測試、未經重現。這就是全部。如果這些數字在獨立測試框架下站得住腳，帕雷托前沿的主張就正確，而寶塔影片只是註腳。如果站不住腳，那就只剩下寶塔影片了。

採用數字所說的，其實與品質無關

在這項比較中，有一個數字沒有任何人有異議，而且它不是基準測試。根據 2026 年 10 月 13 日讀取的 Hugging Face 下載計數器，顯示 630 次下載，對象為 openbmb/MiniCPM-V-4.7-35B-A3B相較之下約有 360 萬次，而Qwen/Qwen3.6-35B-A3B——該儲存庫建立於 2026 年 4 月 15 日，因此在採用曲線上大約領先了九個月。這個差距衡量的是時間，而不是優劣，而這正是為什麼效率問題會以這個方向被提出來的原因：新進者之所以必須以每個 token 為基準來論證，正是因為它還沒有九個月的時間成為預設選擇。

這份清單裡還有一個值得指出的小型內部矛盾。該儲存庫帶有從同一系列其他成員繼承而來的「On-Device Model」標籤，而一個擁有 352 億參數、以 70.4 GB BF16 權重呈現的稀疏 MoE，無論從下載者能理解的哪種意義來看，都算不上是裝置端。裝置端這件事確實存在，但它是靠檢查點之上的量化與專家串流來實現，而不是靠檢查點本身。請以量化版本和應用程式為基準來規劃預算，而不是以那個標籤為基準。

本週該如何應對這件事

實務上的立場狹窄而明確。如果你想驗證效率方面的宣稱，目前還沒有任何東西可驗證——那只是某家廠商的一張圖表，而唯一附有逐項任務數據的數字（少 10% token、一座寶塔）來自第三方的一次單一示範。如果你想跑這個模型，權重是 Apache-2.0，架構已有文件說明，而降採樣設定則由你選擇，這是一個真實且未被充分重視的槓桿：吞吐量重要時用 16x，當圖表向你展示的是一份文件時用 4x。

這個比較中，有一半目前可透過託管 API 取得，另一半則否，而精確說明哪邊是哪邊是值得的。qwen/qwen3.6-35b-a3b是 OrcaRouter 上的託管模型——它位於目錄中，只需一把金鑰即可存取，價格為 Qwen 自家定價，沒有任何額外加價，並會派送到健康狀況良好的供應商，而不是您鎖定的那一家。MiniCPM-V 4.7 並非由我們託管；它是您自行部署的開放權重檢查點。這種不對稱性正是這裡有用的地方。您今天下午就能把這個比較中的 Qwen 那一邊放進基準測試，針對它用您自己的資料執行 OpenBMB 的測試框架，並讓廠商的圖表成為假設，而非答案。

而這——有鑑於整場爭論談的都是你硬體上的效率——本來就是唯一能一錘定音的測量。