MiniCPM-V 4.7-35B-A3B-DSpark：OpenBMB 的 389M 草稿模型登場，還附上其基礎模型從未擁有的模型卡

MiniCPM-V-4.7-35B-A3B-DSpark 是一個擁有 389,223,169 個參數的草稿模型。它不會回答問題，也看不見影像，單獨存在時毫無用處。它的全部工作就是猜測接下來十五個 token，好讓 MiniCPM-V-4.7-35B-A3B 能在一次前向傳遞中驗證一整個區塊，而不是一次只生成一個 token。這就是推測解碼，而 OpenBMB 十一天前為其全新的 35B 視覺語言模型發布了一款草稿模型，卻對外隻字未提。

真正讓它值得寫成一頁的，不是那份草稿，而是隨之而來的文件資料。DSpark 檢查點有一張模型卡：一份授權條款、一張規格表、一份訓練配方，以及涵蓋七個任務類別的接受長度表。它的 350 億參數母模型問世時，這些一概沒有。因此，MiniCPM-V 4.7 的發布首次附上了實際數字——而這些數字是關於母模型的，由一個 0.78 GB 的檔案間接測量而得，而該檔案明言的用途正是讓它跑得更快。

以下內容將模型卡上所列的資訊，與模型卡尚未證實的部分區分開來。這些驗收數據是 OpenBMB 自家的，實驗室以外無人重現過。基礎模型的基準測試表至今仍不存在。

DSpark 檢查點究竟是什麼

這個儲存庫openbmb/MiniCPM-V-4.7-35B-A3B-DSpark可追溯至 2026 年 10 月 8 日。它是單一檔案檢查點——model.safetensors，外加一個config.json和一份 README——採用 Apache-2.0 授權，標記為英文與中文。第二個草稿openbmb/MiniCPM-V-4.7-1B-DSpark早了一秒建立，因此兩者是同一批次推送到 hub，而非逐一被發現。

每個草稿模型都只置於一個目標模型之前，且僅限於該目標。說明卡寫得很明白：這個檢查點「是為了與 MiniCPM-V-4.7-35B-A3B 及其分詞器精確配對而訓練的」。詞彙表沿用母模型的，全部 248,144 個詞元一個不少，這是必要條件而非最佳化——草稿模型的詞元若無法與目標模型的詞元一一對應，就無法提出任何目標模型可能接受的候選。同樣的約束也正是為什麼同系列的草稿模型要各自獨立存在，而不是由單一草稿模型服務整個家族。

這個架構並非父模型的縮小複製品。它是一個五層的注意力堆疊，隱藏寬度 2,048，8 個查詢頭對上 2 個鍵/值頭，中間大小 6,144，以及 theta 為 10,000,000 的 RoPE。architectures 欄位顯示Qwen3DSparkModel——與父模型語言堆疊所源自的 Qwen3 系列主幹相同，只是被削減成了一個骨架。

有趣的部分在於 stub 如何與目標模型溝通。它不會讀取目標模型的最終層。它會從五個中間層汲取隱藏狀態——[3, 11, 19, 27, 35]，這些是父模型 40 層中的一部分——並透過一個 dspark 類型的投影器將它們投影。從堆疊中段而非末端提取是刻意為之：網路中段的狀態對齊成本更低，且攜帶最終層已壓縮進下一詞元 logits 的資訊。該配置也配備了一個置信度頭，其中帶有秩為 256 的 Markov 成分，這正是 DSpark 論文中用來決定提案區塊有多少值得驗證的機制。

驗收表是一張卡片，不是一種量測。

以下是 OpenBMB 所發布關於這對組合運作效果的所有數值資料，以每個驗證步驟所接受的 token 數量表示，並以自然 EOS 終止以及 max_new_tokens=8192：

• Vision、MMMU — 每步接受 5.098 個 token。

• Vision、MathVista — 6.126。

• 視覺、CharXiv 推理（驗證）— 5.479。

• 視覺，OCRBench — 5.407。

• 文字、數學 — 6.687.

• 文字、程式碼 — 7.387.

• 文字，一般 — 3.501。

關於那張表，有三件事值得公開指出。第一，它是自我報告的。OpenBMB 以外沒有人跑過這個檢查點並公布數字，而且在該儲存庫上只記錄到一次下載，因此 OpenBMB 以外根本沒有人跑過它。第二，接受長度是配對的屬性，不是模型的屬性——它衡量的是 MiniCPM-V-4.7-35B-A3B 的輸出有多可預測，而不是該輸出有多好。一個會自我重複的目標模型，等於讓草稿模型輕鬆得勝。第三，差距才是重點：程式碼上的 7.387 對上一般文字上的 3.501，代表最佳與最差類別之間相差兩倍，而程式碼最容易，反映的是程式碼低熵、高度重複的表面特性，更勝於這些模型本身的任何長處。

還有一種這張卡片未明說的純算術解讀。一個提出 15 個 token、其中 5 到 7 個被接受的草擬器，每次目標前向傳遞仍然能推進數個 token，因此這裡的上限是大幅的吞吐量增益——但這並不是天真的「快 5 倍」說法，因為驗證一個 15-token 區塊的成本高於生成單一 token，而且被拒絕的提案仍要付出成本卻被丟棄。這個落差正是 DSpark 論文所探討的重點，也是為什麼設定檔提供一個開關來關閉自適應驗證。

這份草稿意外透露出關於基礎模型的哪些訊息

MiniCPM-V 4.7 將其發布標記為悄然推出——只有權重，沒有發布貼文。如今這已有改變，雖然幅度不大卻真實存在。父儲存庫位於 openbmb/MiniCPM-V-4.7-35B-A3B，於 2026 年 10 月 7 日建立。到了 10 月 12 日，它已包含完整的模型卡，附有 README、Hugging Face 風格的發布頁面、宣稱列表、裝置端區段，以及權重表。該儲存庫自此增加了一個量化系列——FP8、int4、AWQ、GPTQ 和 GGUF 版本，各自位於自己的儲存庫，全都在 10 月 12 日有所更新——並獲得 27 個讚，對比 166 次下載。

所以準確的情況是兩階段發布，而不是無聲發布。權重於10月6日和7日上線。草稿檢查點接著在10月8日發布。文件、量化版本，以及裝置端應用方案在10月12日前陸續到位。OpenBMB仍未為該系列發布部落格文章或技術報告，而且母卡片上仍然沒有基準測試表——效能宣稱置於連結的圖表圖片中，而不是讀者可以直接引用的文字。

文本中確實出現的那項主張，正是標題性的那一個：在 Lookahead Expert Scheduling、逐層量化，以及「DSpark 推測性取樣整合」的加持下，35B-A3B 模型被描述為首個能在裝置端順暢運行的開源 MoE 模型，在 iPhone 17 Pro Max 上達到每秒 13 個以上的 token。該數字由廠商自行報告、未經重現，且毫無限定條件——沒有量化格式、沒有建置版本、沒有提示詞、沒有量測方法。DSpark 檢查點是該主張所依據的三項技術之一，這使它成為三者之中唯一能讓你下載並檢視的一項。它同時也是唯一一項，其證據僅是每項任務一行未經細看的基準測試紀錄。

如果你想的話，就執行它。

這張卡附帶的是一份配方，而且它是一道 vLLM 指令，不是含糊帶過的說法。它會以張量平行度 2 來服務目標模型，最大模型長度為 40,960，語言與多模態編碼器注意力後端都啟用 FLASH_ATTN，視覺降採樣模式為 4x，enable_thinking 設為 false，而推測解碼設定指向 DSpark 檢查點，搭配 15 個推測 token，並關閉自適應驗證。那行指令裡有兩個細節本身就值得注意：--max-num-seqs 1 意味著這套公開的設定一次只服務一個序列，而 --disable-custom-all-reduce 連同 all-reduce 融合傳遞也被關掉，意味著這是一份為了能跑而調校出來的設定，而不是為了追求極致速度。請把這份配方當成 OpenBMB 讓它跑得起來的起點，而不是吞吐量的宣稱。

硬體規格上限才是真正的障礙。目標是在 KV 快取之前大約 70 GB 的 BF16 權重，而草稿模型還要在上面額外加上約 0.78 GB。兩顆加速器是官方所述的最低需求，這讓它遠遠超出該系列行銷所主打的手機範疇——針對 35B-A3B 模型進行裝置端部署，意味著得採取激進的量化與卸載，而這正是 LES 與逐層量化工作存在的目的，但這兩者都不在上面的 vLLM 配方裡。

這種不對稱是多數團隊的實際決策依據。自己部署 MiniCPM-V 4.7 要付出兩張自有 GPU 的成本；而呼叫一個可相比擬的託管多模態 MoE，前期則不需任何花費。Qwen3.6 35B A3B 是最接近的直接對照組——同樣是 35B 總參數、3B 啟動參數的形態，同樣具備 262K 上下文，支援圖像與影片輸入——而且它可透過 OrcaRouter 提供服務，依供應商路由不同，每百萬輸入 token 從 $0.248 起、每百萬輸出 token 為 $1.485，若其中某條路由效能退化，還會自動容錯切換。MiniCPM-V 4.7 並不是 OrcaRouter 上的託管模型，本文也不會假裝它是；誠實的說法是，兩者是在某個決策點上的替代方案，而那個託管方案，是你今天下午就能實際測量的那一個。

什麼會讓這件事變得可檢查？

DSpark 檢查點採用 Apache-2.0 授權，大小不到 1 GB，還附上一道服務指令，讓擁有兩張 GPU 的人今天就能貼進終端機執行。這樣的組合，使它成為在 MiniCPM-V 4.7 上取得獨立數據的最便宜途徑——不是基準測試分數，而是幾乎同樣有用的東西：可重現的接受長度。如果外部第三方在 MMMU 上重現 5.1、在一般文字上重現 3.5，這份規格卡就具有可信度，而這個家族的效率敘事也將獲得第一個外部資料點。如果接受長度明顯偏低，那就代表公開的表格是在該配方無法重現的條件下測得的，而每秒 13 個 token 的說法也會連帶受到質疑。

仍然缺少的是模型卡通常要提供的東西。沒有 MMMU 分數、沒有 OCRBench 分數、沒有文件理解結果、沒有定位分數，也沒有 MiniCPM-V 4.7 本身的延遲數據——沒有任何能回答這個模型好不好的內容。草稿模型的表格無法取代這些，而把高接受長度解讀為品質訊號，正是這些數字會招致的錯誤。對草稿模型來說，做出 ChatGPT 式的預測很容易，但這完全無法說明該預測是否正確。

所以：一個真實的產物、一份真實的授權、一項真正嶄新且已發表的證據——關於一個原本毫無證據的模型——以及一個評估缺口，其寬度與 10 月 7 日當天完全相同。下一個要更新的檔案，仍然是父模型的模型卡。