MiniCPM5-2B-DSpark 對比 Gemma 4 12B：兩種起草方式，兩個本地AI重量級別

要快速理解 MiniCPM5-2B-DSpark 與 Gemma 4 12B 為什麼值得放在一起比較，最快的方法就是暫時忽略兩者的規模，觀察它們各自如何寫出一個句子。兩者都藉由草稿模型在記憶體匯流排上取巧：由一個小型模型一次提出數個後續 token，再由真正的模型以單次傳遞驗證整個區塊，如此一來，晶片只需為每個區塊付出一次權重載入成本，而不是每個 token 各付一次。MiniCPM5-2B-DSpark 是 OpenBMB 於 2026 年 9 月 6 日低調發布到 Hugging Face 的草稿模型——一個 3.238 億參數的配套檢查點，用於加速 MiniCPM5-2B，也就是 ModelBest 於 2026 年 7 月 19 日在 WAIC 發表的 25.2 億參數密集裝置端模型。Gemma 4 12B 則是 Google 於 2026 年 6 月 3 日推出的 119.5 億參數無編碼器多模態通用模型，具備內建的草稿模型與 256K 上下文。前者將草稿模型以 Apache-2.0 的獨立檢查點形式提供，由你自行載入；後者則將類似的手法隱藏在單一大型模型中，直接執行即可。

決定本文格局的誠實聲明：MiniCPM5-2B-DSpark 不是一個可以下提示詞的模型。它沒有 tokenizer、沒有聊天模板、也沒有獨立輸出——它的模型卡上只列了 model.safetensors、一份 config 和一份 README。它是為 2B 級目標模型而存在的服務層配件；讀者真正在比較的，其實是兩種本機 AI 權重等級：一個手機大小的 2B 堆疊自行生成 token，對上一個 16GB 的 12B 通才模型自行生成 token。底下所有內容，都是這個抉擇被具體化的樣貌。

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

模型卡是整個發布的公開表面，因此這就是從中可得知的全部資訊。MiniCPM5-2B-DSpark 是一個 DSpark 草稿檢查點：五個全注意力層、323,776,001 個參數、具有 16 個查詢頭和 2 個 KV 頭的群組查詢注意力，以及區塊大小為七——它每次前向傳遞最多為 MiniCPM5-2B 目標模型提出七個候選 token 以供驗證。該配置宣告了 Qwen3DSparkModel 架構，並帶有 DSparkDraftModel 自動對應，且隨附的 DSpark 方法（arXiv 2607.05147，即 2026 年 7 月的 DeepSeek 論文）中的信心頭和馬可夫頭仍處於啟用狀態——亦即負責決定後綴是否不值得檢查的負載感知驗證器。它在大約 70.5 億個 token 的 MiniCPM5-2B 生成回應上訓練了六個 epoch，涵蓋通用、數學和程式碼提示。

上面這張 openbmb/MiniCPM5-2B-DSpark 模型卡便是此次發布的全部內容：模型卡、配置、一個 Safetensors 檔案，沒有公告、沒有部落格文章、沒有新聞稿——一次低調的權重發布，截至撰寫本文時才剛滿一天。

這張卡沒有包含的內容，與它所包含的內容一樣重要。它報告了接受長度——根據該 repo 自身的評估，在貪婪解碼下，每個驗證步驟平均接受 5.52 個 token，其中數學為 6.05、程式碼為 6.11，而七個 token 為上限——但它並未公布實際時間加速、每秒 token 數，也沒有獨立基準測試。SGLang 的 DSPARK 引擎是文件記載的服務路徑，草稿模型與 MiniCPM5-2B 目標模型並行載入。換言之：草稿的品質已被量化，但其效益尚未被量化；任何採用者都應先實測，再決定是否相信。

Gemma 4 12B 為另一方帶來了什麼

Gemma 4 12B 是 Google Gemma 4 家族中的中間成員，在本地端 AI 的曲線上完全處於不同的位置。它是一個密集的 11.95B 參數模型，可直接接收文字、影像、音訊和視訊輸入，無需獨立編碼器；開箱即可遵循工具呼叫；並將原生 256K 上下文與多 token 預測草稿器搭配使用，在內部實現同樣的記憶體匯流排技巧——但這是從 checkpoint 內部達成的，因此您無需額外下載或連接任何東西。它採用 Apache 2.0 授權，實際上可在配備 16GB 記憶體的筆記型電腦上執行，並隨附 Google 的完整配套：發布評測、基礎版與指令版的模型卡，以及涵蓋 Model Garden、LM Studio 和 Ollama 的生態系統支援。它背後已有數個月的社群部署經驗，而剛發布一天的 MiniCPM 草稿則沒有。

Google 針對 Gemma 4 12B 的模型卡，正是同一框架下的鮮明對比：一個成熟的通用多模態模型，其編寫者屬於發行版本的一部分，而非獨立的存放庫。

規格，誠實標示

請在考量來源的情況下閱讀這些：MiniCPM5-2B 的數據是 ModelBest 模型卡片的宣稱，未經複現；Gemma 4 12B 的數據是 Google 自己的，長期開放給社群使用。

• 你執行的模型 — MiniCPM5-2B-DSpark：一個僅供 MiniCPM5-2B（2.52B 密集參數、42 層）搭配使用的 324M 草稿模型。Gemma 4 12B：一個獨立的 11.95B 密集參數模型。

• 上下文 — MiniCPM5-2B 目標：原生 128K。Gemma 4 12B：原生 256K。

• 模態 — MiniCPM5-2B 堆疊：僅文字。Gemma 4 12B：文字、影像、音訊及視訊輸入，無編碼器。

• 草稿生成 — MiniCPM5-2B-DSpark：外部 DSpark 草稿，每次傳遞七個 token，SGLang DSPARK 引擎。Gemma 4 12B：內部多 token 預測草稿器，無需安裝。

• 記憶體佔用 — MiniCPM5-2B 在 BF16 下目標約 5GB，另加約 650MB 的 draft 檔案；Gemma 4 12B 在 BF16 下約需 18GB，量化後可在 16GB 等級的硬體上實際使用。

• 證據 — MiniCPM5-2B-DSpark：只有 repo 的接受長度數據，且僅一天前發布。Gemma 4 12B：發布評測加上數個月的社群部署。

上方的計分板是同一幅圖像，以六列排列：兩欄幾乎在所有事情上意見相左，除了兩者都用來快速寫作的策略。

哪個重量等級適合您實際擁有的矽膠？

由於 MiniCPM5-2B-DSpark 不是一個模型，真正有意義的分野在於目標模型的參數量級與 Gemma 4 12B 的參數量級之間——而這道分野基本上是個硬體問題。手機、智慧座艙板卡，或只有幾 GB DRAM 的小型邊緣運算盒，都無法以實用速度運行一個 11.95B 的模型；記憶體匯流排正是會令它窒礙難行的瓶頸。這正是 MiniCPM5-2B 技術棧為之而生的世界：一個權重足以放進裝置端記憶體的稠密 2B 模型，再外掛一個草稿模型（draft model），把小型稠密模型所犧牲掉的每秒 token 數（tokens-per-second）補回一些。推測解碼（speculative decoding）恰恰在這種稠密、受記憶體頻寬限制的模式下最為有效，因此草稿模型才是這次發佈中最有意思的部分，而不是噱頭。

Gemma 4 12B 正是高一個重量級的答案。如果你的設備有 16GB 或以上記憶體——無論是筆電、工作站，還是效能強勁的邊緣伺服器——都能運行這個多模態通用模型，並獲得 2B 架構無法提供的三項優勢：不需編碼器或第二條管線即可處理影像、音訊與視訊輸入；256K 的上下文窗口足以應付儲存庫級或文件級的工作；以及誕生僅一天的草稿檢查點所沒有的成熟度。代價是必須放棄在最小型裝置上執行的能力，並付出約三倍的記憶體佔用。

兩者的路由現實

這場對決的雙方現今都不在任何託管目錄中，OrcaRouter 也不例外。MiniCPM5-2B-DSpark 本質上就是一個自架的服務配件——你必須自行運行 SGLang 技術棧，而 draft（草稿模型）只存在於你的本地部署中。Gemma 4 12B 是開放權重模型，所以你可以自行架設服務，或在你本來就能取得它的地方使用。這正是路由層以安全網、而非傳遞機制的角色體現其價值的情境：當你用一個全新的 draft 建置，針對你已在服務的工作負載進行試運行時，讓測試路徑經由單一 API 並具備自動容錯切換，代表一個未經驗證的技術棧即使停頓，也不會拖垮正式環境；而圍繞於此的供應商列表價格以 0% 加成轉傳，因此任何你拿來對照的託管模型若調整價格，當天就會反映出來。不過就比較本身而言，這兩個模型最誠實的做法都一樣：你既然是自架，那麼真正重要的基準測試，就是你在自己硬體上跑出來的那個。

裁決

MiniCPM5-2B-DSpark 和 Gemma 4 12B 並非狹義上的競爭對手——它們是本地 AI 的兩個重量級別，只是恰好共享一個技巧。當你的裝置無法承載 12B 模型，而你想要一個支援文字、採用 Apache-2.0、以代理為導向且能放入裝置記憶體的模型時，請選擇搭配 DSpark draft 的 MiniCPM5-2B 堆疊；這個 draft 是一個有前景的免費加速方案，但在信任它之前，請在你自己的 SGLang 建置上進行測量，因為它的效益仍未量化。當你的硬體有足夠餘裕，而你想要一個具備 256K 視窗且有生態系統支援的多模態模型時，請選擇 Gemma 4 12B。問題不在於哪個模型更聰明——而在於你的晶片實際上能餵養哪一個。