MiniCPM-V-4.7-1B-DSpark：一款在毫無公告下推出的 213M 草稿模型

MiniCPM-V-4.7-1B-DSpark 是一個擁有 213,547,777 個參數的檢查點，卻無法回答問題。它不讀取圖像，不進行對話，單獨部署時也產不出任何值得一讀的內容。它的全部職責，就是坐在一個模型——MiniCPM-V-4.7-1B——前面，猜測接下來十五個 token，好讓一個手機等級的小型視覺語言模型能在單次前向傳遞中驗證其中一整塊，而不是一次生成一個。

這個檔案大小為 0.85 GB，採 Apache-2.0 授權，於 2026 年 10 月 8 日 04:26 UTC 出現在 Hugging Face 上，與更大的 35B-A3B 兄弟模型的草稿放在同一批。四天後，上層模型卡仍只把它當成註腳：草稿僅出現一次，以權重表中的一列呈現，且藏在收合的「Speculative decoding (DSpark)」切換鈕之後。OpenBMB 沒有為它發布部落格文章，沒有技術報告，專案自己的 GitHub 文件中也沒有相關條目。

那份沉默才是有意思的地方，因為這個特定檔案讓某些事情成為可能。它是 MiniCPM-V 4.7 系列中第一個能讓 OpenBMB 以外的人驗證其核心主張的成品——該主張是 1B 視覺模型能在手機上以可接受的方式運行。以下內容會把兩堆東西分開：哪些是你可以在磁碟上開啟的檔案，哪些是廠商印在旁邊的數字。

儲存庫裡實際上有什麼？

四個檔案。這就是全部：.gitattributes、README.md、config.json，以及一個model.safetensors，其中裝載著 854,204,052 位元組的 BF16 權重。儲存庫中沒有分詞器，因為並不需要有——草稿模型借用目標模型的，而其設定中的詞彙表正是父模型的 248,094 個符元，分毫不差。若草稿模型的符元無法與目標模型的符元一一對應，它就無法提出任何目標模型會接受的內容，因此共享詞彙表是必要條件，而非便利之舉。

Hub API 將該儲存庫記錄為建立於 2026-10-08T04:26:19Z、最後修改於 2026-10-12T14:29:57Z，標記為英文與中文，採用 Apache-2.0 授權，撰寫當下有三個讚與一次下載。最後那個數字才是要記住的。四天過去，只有一次下載，而這個檔案小到可透過手機連線取得。

此架構欄位讀取為 Qwen3DSparkModel，其 model_type 為 qwen3，這是合理而非奇怪的：MiniCPM-V 4.7 的語言主幹源自 Qwen3 系列，因此從同一家族裁切出的五層短樁正是預期會看到的結果。真正不算父模型縮小版的，是這個短樁與父模型對話的方式。設定檔配置了一個 dflash_config，內容包含 projector_type: "dspark"、enable_confidence_head: true、confidence_head_alpha: 1.0、confidence_head_with_markov: true、markov_head_type: "vanilla" 以及 markov_rank: 256。那個信心頭正是取自 DSpark 方法的部分：它是用來估計一個被提出的區塊有多少值得驗證的機制，而這也正是服務設定會提供一個開關來關閉自適應驗證的根本原因。

規格，以及每個數字為何會在那裡。

草稿端，從卡片與設定來看，兩者一致：

• 草稿參數 — 213,547,777，全部為 BF16，位於 0.85 GB 的單一檔案檢查點中

• 草稿深度 — 5 層，全部為全注意力，隱藏大小 1,024，中間大小 3,584，SiLU 激活

• 注意力幾何 — 8 個查詢頭對 2 個鍵/值頭，頭維度 256，分組查詢注意力

• 每次前向傳遞的 Token 數 — 15，在設定檔中以 block_size: 15

• 位置範圍 — RoPE theta 10,000,000，搭配 256 維旋轉嵌入，且 max_position_embeddings 設為 262,144，與父模型的 256K 視窗相符

• 點選層 — [3, 7, 11, 15, 19]，在父項的 24 層之中（num_target_layers: 24）

• 詞彙量 — 248,094，與目標分詞器綁定，並在 248,076 設有專用的遮罩詞元，用於半自迴歸草擬步驟

其中有兩行值得多看一眼。第一是分接層。草稿模型不會讀取父模型的最終層；而是從散布於父模型深度中的五個層讀取隱藏狀態，並透過一個 dspark 投影器。網路中段的狀態對齊成本更低，且仍攜帶著最後一層已壓縮成下一個詞元 logits 的資訊。第二是頭維度為 256，而隱藏大小為 1,024。那是在狹窄模型上刻意採用的寬頭，而設定會切換 tie_word_embeddings: false —— 嵌入矩陣與輸出投影保持分開，而非共用，因此參數量同時包含兩者。

總而言之，它是一個草稿模型，大小約為目標模型的五分之一，但整體形狀截然不同。相較之下，35B-A3B 同系列模型的草稿模型有 389,223,169 個參數，取用層 [3, 11, 19, 27, 35]（共 40 層）。兩個草稿模型，每個目標模型各一個，因為草稿模型永遠只對其訓練時所依據的詞彙與中間表徵有效。

驗收表是一張模型卡，不是一項量測。

以下是 OpenBMB 所公布關於這對組合表現的所有數值資料，以每個驗證步驟所接受的 token 數表示；測量時採用自然 EOS 終止與max_new_tokens=8192：

• 視覺、MMMU — 每步接受 3.452 個 token

• 視覺、MathVista — 4.333

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

• 視覺，OCRBench — 4.752

• 文字、數學 — 5.891

• 文字、程式碼 — 5.347

• 文字，一般 — 3.370

這個差距從 5.891 一路降到 3.370，最簡單類別與最困難類別之間相差約 1.75 倍。這種排序並不令人意外，而它某種程度上也揭示了這些數字的意義：數學是語言模型產出最規律的表層，一般文本則最不規律，而草擬器的成功率取決於目標輸出的可預測性，而非其品質。

那張表格上應該要有三項注意事項，而這張卡片並未主動提供其中任何一項。

這是自行報告的，而且該儲存庫的下載次數正好只有一次。OpenBMB 以外沒有人為這個檢查點產出過任何其他人能查看的驗收數字。這些數字是廠商的，是在廠商的測試框架中、針對廠商的任務集測量出來的。

接受長度是配對的性質，而非模型的性質。一個會自我重複的目標會讓它的草稿模型輕鬆取勝，因此這裡較高的數值並不證明 MiniCPM-V 4.7-1B 擅長任何事。它證明的是其輸出有多可預測，而那是一個不同的問題，有著不同的答案。

而且這並不是加速。一個草稿模型提出 15 個 token，其中 3.4 個通過驗證，這仍然意味著每次目標模型前向傳遞都能推進數個 token，但驗證一個 15-token 區塊的成本高於生成單一 token，而且每一個被拒絕的提案都得付出代價後遭丟棄。要把接受長度換算成實際耗時數字，需要驗證成本、批次大小和硬體條件，而這些資訊這張卡全都沒有提供。它唯一提供的服務配方設定為--max-num-seqs 1，這是一個為了能運作而調整的配置，而不是為了求快而調整的配置。

對照同系列模型來讀，這張表會更有用。35B-A3B 草稿模型在程式碼上拿到 7.387，在 MMMU 上拿到 5.098；這個 1B 草稿模型則拿到 5.347 和 3.452。較小的目標模型搭配較小的草稿模型時，每步接受的 token 數明顯較少，而這正是單張卡片無法呈現、兩張卡片才能呈現的那種跨家族細節。

訓練，以及那個解釋整體設計的細節

這份配方共有四行：兩百萬個訓練序列、六個 epoch、AdamW，以及由交叉熵、一個 L1 項和一個信心損失組成的組合目標。真正重要的是關於訓練資料來源的那一行——回應是由 MiniCPM-V-4.7-1B 自己生成的，來源混合了視覺與文字提示。

那是一種自我蒸餾，而這也決定了像這樣的草稿模型建置成本的下限。你必須先大規模執行目標模型，且涵蓋兩種模態，才能訓練出一個草稿模型；這意味著你能下載的 0.85 GB 產物，只是昂貴流程留下的廉價殘留物。這也說明了為什麼草稿模型是一對一配對，而非共用：它模仿的行為是這個模型的行為，而不同目標模型的輸出會訓練出不同的草稿模型。

該方法本身的論文，arXiv 2607.05147，並非 OpenBMB 的。它是一篇於 2026 年 7 月 6 日提交、由 33 位作者合寫的論文，將 DSpark 描述為一種推測性解碼框架：將平行主幹與輕量級序列模組配對，並根據估計的前綴存活機率來排定驗證長度。文中報告其部署於 DeepSeek-V4 服務系統內，採用名為 MTP-1 的生產環境基線，並宣稱在吞吐量相符的情況下，每位使用者的生成速度快 60% 到 85%。那些宣稱屬於該論文，也屬於該部署。沒有任何已發表的內容將它們連結到一個以 1B 視覺模型為基礎的五層、213M 草稿模型，而上述的接受率表是任何人所提出的唯一橋樑。

為什麼這個檔案的重要性遠超過它的大小所暗示

MiniCPM-V 4.7 系列最受矚目的主打賣點在於裝置端表現。1B 這張卡的內容包括：效能對比推論時間的圖表、1B instruct 版本的整體效能圖表、一段在 iPhone 17 Pro Max 上錄製且未經剪輯的螢幕錄影，以及一句質性描述，指出 1B 版本在整體評分與推論效率上均大幅超越 Qwen3.5 0.8B。它也列出量化系列——int4、AWQ、GPTQ、GGUF，外加 FP8 支援——以及涵蓋 iOS、Android、HarmonyOS、Rockchip、Houmo、Intel、AMD 與 Arm 的首日硬體目標。

那些全都是廠商宣稱，沒有附上任何外部數字，而且其中一項在內部就不一致：模型卡文字稱它是 1B 模型，Hub 側邊欄卻回報模型規模為 2B 參數。DSpark 檢查點則與這一切性質不同。它是 0.85 GB、Apache-2.0，並附帶一道服務指令——這意味著外部人士只要有一張消費級 GPU，就能在本週跑起它，並產出這個家族第一個由外部量測的數字。不是基準測試分數，而是幾乎同樣有用的東西：一個可重現的接受長度。

如果有人在 MMMU 上達到 3.45、在一般文字上達到 3.37，這張卡就可信，裝置端故事也有了第一個外部資料點。如果接受度明顯偏低，那張表就是在已發布配方無法重現的條件下測得的，而效能對推論時間圖也會承襲那份疑慮。無論是哪一種結果，都比再一張廠商圖表更有價值，而這是整個系列中唯一能便宜取得一個資料點的地方。

運行它，以及嘗試的代價

這張卡隨附一個配方，而它是一個 vllm serve 呼叫，而不是含糊帶過。它會載入目標 openbmb/MiniCPM-V-4.7-1B，並以名稱 MiniCPM-V-4.7-1B 提供服務，設定 --max-model-len 40960 和 --max-num-batched-tokens 40960，固定 --attention-backend FLASH_ATTN 和 --mm-encoder-attn-backend FLASH_ATTN，傳入多模態處理器的關鍵字參數 {"downsample_mode": "4x"}，信任每個請求的多模態關鍵字參數，並將推測設定指向 DSpark 檢查點，搭配 "method": "dspark"、"num_speculative_tokens": 15，並關閉自適應驗證。預設的聊天範本關鍵字參數會讓思考功能保持停用。

那行裡有兩個細節值得細讀兩遍。--max-num-seqs 1意味著已發布的設定一次只服務一個序列，因此這份配方描述的是一種單串流延遲配置，而非吞吐量配置。而 4x 視覺降採樣模式是母卡所宣稱的兩種模式中較便宜的一種——同一張卡還提供混合的 4x/16x 方案，以細節換取速度，而這份配方選擇了這場取捨中偏向速度的那一邊。

硬體需求範圍與該系列的行銷說法正好相反。1B 目標模型在 BF16 下約為 2 GB，再加上 KV 快取，而草稿模型又額外增加 0.85 GB，因此這是單一 GPU 的工作——消費級顯示卡，或具備足夠統一記憶體的工作站——而非手機端的工作。父模型文件中的裝置端路徑，是透過量化版本與本配方未包含的框架來執行，而目前發布的 DSpark 檢查點則是 BF16 的伺服器端產物。

這留下了一個多數團隊都會碰到的落差：MiniCPM-V 4.7-1B 最有趣的版本是裝置端的那一個，而今天就能跑、又不必擁有手機工具鏈的版本，則是伺服器端的那一個。如果你現在真正需要的是小型多模態推論，最接近的託管等效方案是另一個模型——Qwen3 VL 8B Instruct 在 OrcaRouter 上，每百萬輸入 token 收費 0.18 美元、每百萬輸出 token 收費 0.70 美元，具備 128K 上下文視窗，以及文字、圖像與影片輸入，沒有本機權重，也沒有需要持續維護的服務配方。MiniCPM-V 4.7 在 OrcaRouter 上並不是託管模型，本文也不會假裝它是；誠實的說法是，這兩者只是完成同一件事的兩種方式，而今天下午只有其中一種能從目錄中衡量。

像 DSpark 這類東西真正發揮價值的地方，在於尚未經過驗證的模型情境，而那是路由問題，不是模型問題。一個沒有人重現過的草稿模型，正是你會想放在可回退端點後方的那種元件。以單一金鑰運行 200 多個模型，供應商定價以 0% 加價原樣傳遞，並在路由品質下降時自動容錯移轉，這意味著出錯的服務實驗代價只是一次重試，而不是一次服務中斷——而且因為完全沒有加價，目錄中任何模型的供應商價格變動都會當天生效，而不是等到下一個計費週期。

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

有三樣東西缺失了，而其中只有一項需要 OpenBMB。

廠商尚未宣布任何消息。該儲存庫有模型卡、授權條款和訓練配方，但沒有部落格文章、沒有技術報告，專案 GitHub 文件中也沒有任何一行提及——截至該系列的第一週，該文件仍將前一代描述為現行版本。檢查點上線四天後，父系 1B 模型卡僅以表格中的一列連結它，如此而已。

沒有人重現過那些接受數據，而下載次數為一。那是最容易彌補的落差，也是最要緊的一個，因為那是唯一能讓外部量測有意義地推動這個家族故事的地方。

而品質這個問題完全沒有被觸及。整份發布資料裡，MiniCPM-V 4.7-1B 沒有任何 MMMU 分數、沒有 OCRBench 結果、沒有文件理解數字，也沒有定位數據——那張接受表是一張關於解碼的表，而把高接受長度讀成品質訊號，正是那些數字所招致的錯誤。

所以：一件真實的產物、一份寬鬆的授權條款、一個能用的服務指令，以及一項關於某個原本毫無這類證據的模型、真正全新的證據。下一個值得更新的檔案，仍然是父模型的模型卡。