MiniCPM5-2B-DSpark：OpenBMB 低調開放 MiniCPM5-2B 權重，附帶專為加速打造的草稿模型

六週前，MiniCPM5-2B 還只是個承諾。它於 2026-07-19 在上海 WAIC 大會上亮相，被定位為位居 Artificial Analysis Index 頂端的 sub-4B 模型，同時附帶一份路線圖說明，宣稱開放權重「很快」就會推出。而「很快」就在本週到來，而且毫無聲勢。2026-09-06，OpenBMB 將旗艦版 MiniCPM5-2B repository 以 Apache-2.0 授權推上 Hugging Face；二十一分鐘後，又推出了 MiniCPM5-2B-DSpark——一個僅有 3.238 億參數的草稿 checkpoint，其唯一任務是在 DSpark 投機解碼演算法下讓 MiniCPM5-2B 解碼得更快。隔天 2026-09-07 則出現了 GPTQ 版本。截至撰稿為止，我們找不到任何公告、發佈貼文或更新日誌；這次釋出就像是 repository 在十一天內悄然轉為公開而浮上檯面。

這是一篇彙整「截至目前已知資訊」的報導，而敘事框架至關重要。MiniCPM5-2B-DSpark 不是可獨立運作的聊天機器人，也不是新的旗艦模型——它是個加速器：一個又小又快的模型，負責搶先在 MiniCPM5-2B 之前生成 token 草案，再由 MiniCPM5-2B 進行平行驗證。少了它所服務的目標模型，它就毫無用處；真正值得關注的，正是那個目標模型。OpenBMB 於 7 月承諾推出的 MiniCPM5-2B 開放權重版本，如今確實已上架 Hugging Face；隨之一起發布的草稿模型，正是官方建議用來讓 MiniCPM5-2B 以實用速度運行的機制。以下內容若未另外標明出處，皆直接摘自這兩張模型卡片及其儲存庫。

發布了什麼，以及何時發布

The 2B family went public as a rolling, unannounced drop, newest entries first: 2B 系列以滾動式、未經事先公告的方式公開上市，最新推出的優先顯示：

• 2026-08-27 — MiniCPM5-2B-Base 與 MiniCPM5-2B-SFT 出現，即原始預訓練與監督式微調的檢查點。

• 2026-09-01 — MiniCPM5-2B-Midtrain，智能體中期訓練階段。

• 2026-09-05 — MiniCPM5-2B-MLX 與 MiniCPM5-2B-GGUF，即 Apple-Silicon 與 llama.cpp 格式。

• 2026-09-06 — 旗艦版 MiniCPM5-2B 儲存庫，二十一分鐘後是 MiniCPM5-2B-DSpark。

• 2026-09-07 — MiniCPM5-2B-GPTQ，量化部署格式。

它們全部都採用 Apache-2.0 授權條款，也就是 ModelBest 在五月時用於 MiniCPM5-1B 系列的那份授權；序列中較早的檢查點仍顯示出幾乎零社群訊號——每個都只有個位數的下載量和讚數。這代表權重發布仍在進行中，而非協調一致的發布行動：產物以依賴順序出現（基礎與 SFT 版先行，量化與草稿格式殿後），沒有任何一天被當作發布日。

MiniCPM5-2B-DSpark 實際上是什麼

推測解碼會將生成過程拆分為一個便宜的提案者與一個昂貴的驗證者。小型草稿模型先猜出接下來的幾個 token；大型模型則在單次前向傳遞中檢查所有猜測，並接受它同意的部分。當草稿校準良好時，你能以一小部分成本獲得大型模型的輸出；當草稿出錯時，也只浪費一次驗證步驟。DSpark 是這個想法的一種具體做法，出自 2026-07-06 發布的一篇論文（arXiv 2607.05147，"Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation"）。它有兩項與眾不同的設計選擇：一是將並行草稿骨幹與輕量級序列模組結合，使提議區塊內的 token 彼此相依，而非在接近區塊末端時準確度逐漸衰減；二是根據置信度估計與引擎吞吐量來為每個請求調整每次驗證的規模，而不是一律驗證固定長度的區塊。

OpenBMB 發布的 DSpark 草稿模型是一個五層 Transformer，擁有 323.8M 個以 BF16 格式儲存的參數（約 648MB）。它隸屬於 Qwen3 架構家族，但帶有 DSpark 特有新增組件：一個投影器，負責從 MiniCPM5-2B 的五個層（1、10、20、30 和 39）讀取隱藏狀態；一個置信度頭；以及一個小型馬可夫頭，用於建模下一個 token 的分佈。其配置建議每次前向傳播處理七個 token 的區塊。以約為 MiniCPM5-2B 25 億參數八分之一的參數量而言，它是目前為主流開放檢查點發布的最小草稿模型之一——而這正是邊緣導向模型的關鍵所在：草稿模型必須足夠輕量，讓單一裝置上同時運行兩個模型仍然勝過只運行一個模型。

上述儲存庫是此草稿模型對外公開的全部內容：一個 README、一個設定檔、一個 safetensors 檔案，以及一張模型卡；其訓練描述顯示，共有 1,959,525 個序列（7.05B tokens），由 MiniCPM5-2B 基於通用、數學與程式碼提示詞生成，並以交叉熵、L1 與置信度的聯合目標訓練了六個 epoch。此 checkpoint 本身並未作為生成式模型單獨使用。

OpenBMB 發布的數字，如實標註

草稿模型的卡片報告了一項關鍵指標——接受長度，即目標模型在每個七 token 區塊中所接受的平均提議 token 數。該評估在三個領域中對 MiniCPM5-2B 的輸出進行，最多生成 4,096 個 token：

• 數學 — 貪婪解碼 (T=0) 下平均接受 6.05 個 token；在 T=1.0 採樣下則為 4.61。

• 程式碼 — 6.11 貪婪；4.44 取樣。

• 一般 — 4.16 貪婪；3.10 取樣。

• 總計 — 貪婪：5.52；採樣：4.05（滿分七分）

這些數字是廠商從模型卡回報的數據，未經獨立重現。它們描述的也只是草稿命中率，而非實際時間（wall-clock）加速：速度是服務端的衡量指標，取決於目標模型驗證一次的成本相對草稿模型提案一次的成本、取決於批次佔用率，也取決於 DSpark 信心排程器對驗證長度的縮減。OpenBMB 未公布這組搭配的每秒 token 數。若要了解此方法的上限所在，DSpark 論文指出，在 DeepSeek 的實際服務系統中，以相同吞吐量為基準，每位用戶的生成速度比 MTP-1 基準快 60–85%——這是該演算法在其他環境表現的良好參考點，而非對 MiniCPM5-2B 在你硬體上效能的宣稱。

上方的計分板是該版本自身的規格表。請將驗收數值視為初步命中率；實際吞吐量的倍數，仍有待獨立的 SGLang 執行來測量。

草案加速的模型

MiniCPM5-2B 是一個稠密型 25 億參數 Transformer——總參數 2,516,756,480——具有 42 層、16 個查詢頭和 2 個 KV 頭、130,560 個 token 的詞彙量，以及 131,072 個 token 的上下文視窗，以 BF16 格式約佔 5GB。在架構上，它刻意地平凡無奇：一個標準的 LlamaForCausalLM，沒有自訂 kernel，也沒有分叉的模型程式碼，這正是它能移植到如此多運行時和晶片目標的原因。在 OpenBMB 自家內部基準套件中，規格卡顯示它在推理、指令跟隨、知識、長上下文、工具使用、編碼和搜尋代理等任務上平均為 53.9——領先同一表格中 Qwen3.5-4B 的 51.1 和 granite-4.2-3B 的 42.7；其中幾個格子（GPQA-Diamond 70.2、HLE 8.9，以及多個長上下文和代理型任務列）標示為來自 Artificial Analysis，而非內部複現。主要的單項任務數據包括：MATH-500 94.6、AIME 2025 和 2026 86.5、IFEval 86.7、MMLU-Pro 70.8，以及 SWE-bench Verified 46.4。這些是供應商在自己的套件上給出的數字，而且規格卡明確說明某些資料列來自第三方；請依此看待這組混合數據。

在七月發表會上，ModelBest 的發布材料引用了 Artificial Analysis 指數 17——{{1}}在低於 4B 參數的模型中位居第一{{/1}}——而七月的報導提及 512K token 的上下文視窗。實際出貨的檢查點配置了 131,072 個 token 的上下文。當發布日的行銷數字與出貨配置不一致時，配置才是決定你能執行什麼的數字，{{2}}而在你依據行銷數字規劃長上下文工作負載之前，這個落差值得了解{{/2}}。

運行 MiniCPM5-2B 搭配其草稿模型

預期路徑是 SGLang，其自 v0.5.16 起已在上游支援 DSpark 演算法——也就是模型卡所要求的最低版本。模型卡中的完整伺服指令如下：

python -m sglang.launch_server --model-path openbmb/MiniCPM5-2B --speculative-algorithm DSPARK --speculative-draft-model-path openbmb/MiniCPM5-2B-DSpark --speculative-dspark-block-size 7

在貪婪解碼（T=0）下，DSpark 驗證是無損的：其輸出與單獨伺服 MiniCPM5-2B 完全相同，因此草稿模型純粹只是為了降低延遲。啟用採樣後，SGLang 的 DSpark 預設為僅對目標模型採樣，並可選擇拒絕採樣。OpenBMB 也記載了可透過一般 Transformers 載入方式（transformers ≥ 5.6）以及 vLLM ≥ 0.21 單獨伺服目標模型，另外提供 minicpm5 工具呼叫解析器以應對代理型工作負載；其中 DSPARK 推測路徑特指 SGLang 的實作。

硬體算力才是這類邊緣級配對的關鍵所在：MiniCPM5-2B 以 BF16 格式約需 5GB，再加上草稿模型約 0.65GB。只要原本單獨運行 2B 模型就已可行的環境，草稿加目標模型的組合都能輕鬆容納，這正是選擇搭載如此小的草稿模型、而非第二個更大模型的原因所在。

什麼尚未被確認

• 我們找不到任何公告——無論是 OpenBMB 或 ModelBest 的部落格，還是英文或中文的社群貼文。「悄悄推出」這種說法是字面上的意思，而唯一公開曝光的管道就是 Hugging Face 上的集合。

• 無獨立評估。草稿中的接受長度，以及 MiniCPM5-2B 的 53.9 套件平均值，皆為廠商回報且未經重現的數據；標記為 AA 的儲存格雖來自第三方，但僅為快照數值，並非以這些確切權重實際執行的結果。

• 我們找不到任何託管的 API，因此如今要採用它，意味著得自己運行檢查點。在七月發布報導中承諾的 ModelScope 鏡像，截至撰寫本文時並未出現。

• DSPARK 配對沒有給出實際耗時（wall-clock）加速數據。5.52 的接受長度代表相當高的命中率，但在特定 GPU 上「快了多少倍」正是 OpenBMB 未公布的數字。

• 上述的上下文窗口歧義：行銷資料宣稱 512K，出貨配置卻顯示 131,072，而儲存庫中沒有任何內容能將兩者銜接起來。

低調的開放權重發布在技術堆疊中的定位

對 MiniCPM5-2B 如今最誠實的解讀是：它是一場賭注——亮眼的官方數字、零次獨立運行、沒有服務歷史，加上一個真實加速效果未經測量的草稿模型。這正是路由層存在的目的。一個團隊如果想測試某個小型開放模型的輸出能否取代它已經在呼叫的託管模型，可以透過一個 API 進行比較——OrcaRouter 作為前端，對接 200+ 個託管模型，按供應商定價收費，無任何加成；因此成立一週評測不需任何成本，而自動故障轉移則表示，一個只有數日歷史的檢查點在證明自己期間，永遠不必把生產路徑挾持為人質。上述一切都不要求將 MiniCPM5-2B 託管到任何地方；當你決定自行託管的 2B 是否值得使用 GPU 時，它就是圍繞既有模型的安全網。

請依重要性順序觀察：一個獨立的 SGLang DSPARK 執行結果，回報該配對的實際每秒 token 數，因為接受長度只是代理指標，而非基準；一則正式公告或 ModelScope 鏡像，確認該版本已是最終版；以及是否有主機服務商採用 MiniCPM5-2B——若有，你在我們這邊支付的價格就是該服務商自己的掛牌價，當日即時反映，因為那就是 pass-through 的意義。與此同時，兩者之中，draft model 才是更有趣的產物。一個五層的 proposer 能讓目標模型在七個 token 中接受五個半，這正是「小型邊緣模型讓人覺得很小」與「感覺像是同一台裝置上跑著一個更大的模型」之間的差別。