MiniCPM-V 4.7 的「3B 活躍參數」並不在模型卡中——我是從權重中測量出來的

關於 MiniCPM-V 4.7 35B-A3B，最常被反覆引用的那個數字，並沒有印在它自家文件的任何地方。這個說法——「只有 3B 啟用參數（！）——甚至能在 iPhone 上跑」——來自 2026 年 10 月 13 日的一篇第三方貼文，而廠商的模型卡、儲存庫 README 與發布說明，完全沒有提到任何啟用參數數字。這與其說是在批評這個說法，不如說是一個值得補上的缺口：檢查點本身就編碼了答案。所以，在這裡做任何其他事之前，我先拉取了 openbmb/MiniCPM-V-4.7-35B-A3B 的 safetensors 索引以及每一個分片標頭，並數了一遍。相較之下，同一篇貼文中的另一個模型——2026 年 8 月 13 日發布的 Qwen3.8-27B——是稠密的 27B 模型，沒有這類需要釐清的模糊地帶：每個參數在每個 token 上都會啟用。有趣的問題是，「3B 啟用」在實際接觸權重之後是否還站得住腳；答案是：站得住，但前提是你按廠商的方式定義「啟用」這個詞；而一旦把你無法避免要跑的部分算進去，誠實的數字其實更接近 4B。

帳本，從檢查點本身讀取

索引檔列出了 40 個語言層，外加一座視覺塔和一個投影器，總計 35,212,875,824 個參數，格式為 BF16——需下載 70.43 GB 的權重。這與名稱中的「35B」相符。MoE 的問題在於每個 token 會觸及其中多大比例：

• 總儲存量 — 352.1 億個參數，BF16 格式下為 70.43 GB。無論是否被使用，每個專家都存放在磁碟上。

• Router 預算 — 每個 MoE 層中，每個 token 會從 256 個專家裡選出 8 個。在 config.json 中設定為 num_experts_per_tok: 8。每個專家都很小：3.15M 個參數。

• 每層的 MoE 路徑 — 8 個專家（25.17M）+ 一個共享專家（3.15M）+ 路由器閘門（0.52M）≈ 28.83M。

• 每層的注意力路徑——此架構為混合式：40 層中有 30 層使用線性注意力（每層 33.72M），10 層使用完整注意力（每層 27.26M）。全部 40 層的注意力加上 MoE 算術運算總計約 2.44B，且每個 token 都會重複。

• 再加上你不能略過的部分——詞元嵌入 508.2M、LM 頭 508.2M、視覺塔 522.3M、投影器 30.7M。

• 兩個站得住腳的答案——僅在注意力與 MoE 路徑上就有約 2.44B 個活躍參數；若把嵌入層、輸出頭、視覺塔與投影器也算進去，則約為 4.01B，而視覺請求確實會用到這些部分。

所以「3B active」並沒有錯。它是將 2.44B 向上取整的結果，而且落在上述兩個數字之間的差距裡。只是它並不是 OpenBMB 公布的數字，也和「A3B」這個後綴不是同一回事——那個後綴是模型名稱的一部分，廠商自家的資料從未把它當成一個測量值。

為什麼後綴和數字不是同一回事？

開放權重生態系中的命名慣例暗示了活躍參數量：一個名為 30B-A3B 或 235B-A22B 的模型，是在告訴你它每個 token 大約會啟用那麼多參數。這個暗示通常可靠——但它是慣例，不是契約，而 MiniCPM-V 4.7 就是一個例子：無論是模型卡、README 或發布文章，都沒有把「A3B」轉換成一個你可以據以規劃記憶體的數字。在有人實際數過之前，這個後綴就只是個標籤。

上述的計數是算術結果，而非從那個標籤推導出來的推論。這也正是 ~2.44B 與 ~4.01B 這兩個數字會有差異的原因：是否把嵌入表和輸出頭計入，是一個實實在在的抉擇，而非吹毛求疵。在稠密模型中，嵌入只佔 27B 預算的一小部分。但在稀疏模型裡，每個 token 的計算路徑只有數十億參數，此時 508M 的嵌入表和 508M 的 LM 頭就不再是雜訊——兩者合計約占活躍路徑的五分之一，而且它們以完整位寬儲存，而專家則是被量化過的。

有一項後果值得直說：若採狹義解讀，這裡的儲存參數與活躍參數比例約為 8.8 比 1。這正是 35B 模型能被宣傳成手機模型的原因，也正是它之所以不像 3B 稠密模型那樣算是手機模型的原因。當路由器忽略某個專家時，儲存空間並不會縮小。

iPhone 的主張是獨立的主張，並有獨立的證據基礎。

這個版本中所有關於裝置端效能的具體內容，都是廠商自行報告且未經重現的。具體數字是在 iPhone 17 Pro Max 上、約 3 GB 記憶體下達到每秒 13+ 個 token，同樣的檢查點也在 iPad M4 上展示過。OpenBMB 將其歸因於三項技術共同作用——Lookahead Expert Scheduling（可預測跨層路由並預取專家）、細粒度逐層量化，以及 DSpark 推測取樣——並將此成果描述為首個能在裝置端順暢執行且不損失能力的開源 MoE 模型。公開紀錄中沒有對該吞吐量的獨立量測，沒有第三方重現，也沒有公布 3 GB 這個數字所假設的是何種量化。

這件事之所以重要，有一個很具體的理由：3 GB 這個數字，決定了這項說法對你而言是否有趣，而這偏偏又是我們了解得最少的數字。一個 35B 的 MoE，若其專家權重大多放在快閃儲存上，那它就不是一個 3 GB 的模型，而是一個只有在路由預測、預取與量化專家快取全都各司其職之後，常駐工作集才恰好塞得進 3 GB 的模型。而這正是基準測試吞吐量與真實世界吞吐量出現落差的條件——第一個提示會把快取預熱，而讓你在示範中跑出每秒 13 個 token 的那種行為，是一套排程，而不是權重本身的性質。

把每秒 13 個 token 視為關於一項技術的說法，而非關於該檢查點的主張。檢查點才是你今天能夠驗證的東西：儲存 35.21B、每個 token 路由 256 個專家中的 8 個、依你的計算方式約 2.44B 至約 4.01B 為活躍參數、Apache-2.0、在 GGUF、AWQ、GPTQ、int4 與 FP8 中的首日量化，以及包含 Rockchip、Houmo、Intel、AMD 與 Arm 的支援晶片廠商清單。

作用中計數會決定什麼、不會決定什麼

活躍參數量是一種運算量的代理指標。它告訴你每個 token 會執行多少矩陣乘法，而這對應到受 GPU 限制的解碼執行速度有多快。它不會告訴你需要多少記憶體來容納模型，這取決於總量——70.43 GB 的 BF16 權重，或在 4 位元下大約是其中的四分之一，而這還未計入 KV 快取。在 256K 上下文的模型上，那個快取也絕非可以忽略不計的小數目。

• 解碼速度——由作用中的參數決定（此處約為 2.44B–4.01B）。這就是 13 tokens/s 這項說法的依據。

• 常駐記憶體——由總參數量（儲存 35.21B）決定，接著再因量化以及任何保持常駐的專家集合而縮減。

• 儲存與載入 — 由 BF16 下完整的 70.43 GB 決定。稀疏路由不會減少下載量。

• 頻寬，而非 FLOPS——在手機上，真正的限制在於讓專家通過記憶體匯流排，這正是排程技術存在的原因，也是為什麼單看活躍數量完全無法預測行動裝置延遲。

實際結論是：如果你的 GPU 有足夠記憶體容納量化後的權重，決定吞吐量的就是活躍參數數量，而「3B active」是件好事。如果你是貼文裡出現「能在 iPhone 上跑」這句話的原因，那麼決定可行性的是總參數量，而廠商的排程工作則是讓總參數量變得可承受的關鍵。同一則標題的兩種解讀都正確，但它們並不是同一種解讀。

那則貼文中的比較需要兩個標籤，而不是一個。

讓這次討論得以成局的框架，是「本地端對上昂貴硬體」：MiniCPM-V 4.7 35B-A3B 是讓你在沒有那套機台的情況下也能取得同等能力的模型，而 Qwen3.8-27B 則是更聰明、但需要那套機台的模型。其中「能力」的那一半來自 Qwen 自家的 model card，而且就像本頁其他所有內容一樣，這屬於廠商自行回報的數據。Qwen 為 Qwen3.8-27B 公布的數字包括 LiveCodeBench v6 的 90.3、GPQA Diamond 的 89.2、OSWorld-Verified 的 84.3，以及 QwenSWEBench 的 79.0，而我們自家目錄中該模型的條目也指出，對一個 27B 稠密模型來說，這些是異常強勁的 agentic 與程式碼相關結果。至於它是否「比 Opus 4.6 更聰明」，那是社群貼文中的說法，我手上並沒有任何能為此定論的獨立評測——所以我不打算把它當成事實來重述。

結構性差異才是真正可檢驗的那一項：Qwen3.8-27B 是稠密模型，因此其 27B 參數全數啟用，記憶體佔用量與運算成本是同一個數字。MiniCPM-V 4.7 35B-A3B 則把這兩個數字拉開約九倍。這就是整個架構論點，而且它確實成立。只是它並不等同於基準測試比較，而讓它聲名大噪的那篇貼文把兩者混為一談。

路由器在哪些情況下會改變決策，以及在哪些情況下不會

這裡有兩件事都是真的，值得分開來看，因為它們指向相反的方向。

第一點是，我們不提供 MiniCPM-V 4.7。它不在我們的目錄中。如果你想要它，途徑就是使用你自己的硬體——這正是該版本發布所鎖定的用途，權重、量化版本與裝置端部署指南都隨之發布。託管 API 對你在手機上執行模型毫無幫助，若暗示並非如此，將會造成誤導。

第二點是，被拿來與它比較的那個模型並不在那個位置上。Qwen3.8-27B 可透過我們的 API 取得，並託管在我們自家的基礎架構上，每百萬輸入 token 為 0.33 美元，每百萬輸出 token 為 2.40 美元。如果你真正要問的問題是「我該不該用本機部署的 MiniCPM-V 4.7 來取代我託管的 Qwen3.8-27B 呼叫」，那麼誠實的答案是：在投入之前你應該先跑過實驗——裝置端的吞吐量數字尚未被重現，而能力比較用的是對方自家的模型卡。這正是容錯移轉存在的理由——把一小部分流量導向新路徑，讓已驗證的路徑留在後面，讓糟糕的一週只讓你損失一小部分工作負載，而不是整個工作負載。0% 加價的模式也讓這筆帳保持誠實：當供應商調整價格，你付的數字當天就跟著變動，因為在他們的標價與你的帳單之間沒有利潤加成層。

路由器無法做到的，是讓「本地還是託管」這個問題消失。這個問題取決於你的硬體、你的隱私限制，以及 70 GB 的下載量是否可接受——而無論你怎麼取整，活躍參數數量都不會改變這三者中的任何一項。

什麼能讓它塵埃落定

三件事，按用處由高到低排列。由 OpenBMB 公布的活躍參數量數字，讓大家不斷複述的那個數字不再是第三方的計算結果——包括我自己的在內，而如果你不同意我的數字，它可以從分片標頭重現。對手機上每秒 13 個 token 的獨立量測，並註明量化設定，因為排程相依的數字若未附上設定，就不是規格。以及一項真正的評估，在相同任務上比較 MiniCPM-V 4.7 35B-A3B 與 Qwen3.8-27B，因為讓這個模型受到注意的那項比較，目前只是一家廠商的圖表對上另一家廠商的規格卡。

在那之前，保守的總結比這篇文章更狹隘：權重是真的，稀疏性是真的，下載量是 70.43 GB，而且每個 token，模型所做的工作量介於 24 億到 40 億個參數之間，這取決於你如何計算那些無法繞過的部分。這是一個真正的工程成果。它還不是一個經過實測的手機基準測試，也不是一個勝過稠密 27B 模型的基準測試勝利。

來源：參數、專家數量、層類型、上下文長度與下載大小，是於 2026 年 10 月 13 日直接從 openbmb/MiniCPM-V-4.7-35B-A3B 的 config.json 與 safetensors 分片標頭讀取而來。裝置端速度、記憶體數據、基準測試結果，以及 Qwen3.8-27B 的評估數字，均為廠商自行報告且未經重現。至於「3B 活躍參數」與「比 Opus 4.6 更聰明」的說法，源自第三方社群貼文，並非出自這兩家廠商。

這些絕非假設：像這樣一個數字所援引的、有文獻記載的 AI 失效與代理事故，全都收錄在OrcaRouter AI 事故檔案庫中，其中每一筆紀錄都附有自己的出處、嚴重程度、可信度等級與爭議標記。