Moondream 3 與 MiniCPM-V 4.7 對比：無人提及的 MoE 儲存帳單

無論是 Moondream 3 Preview還是 MiniCPM-V 4.7，兩者都是專家混合（mixture-of-experts）視覺語言模型，而且兩者的宣傳都主打很小的活躍參數數量，聽起來像是能裝在規格普通的硬體上。Moondream 3 Preview 每個 token 只啟用其 9B 參數中的 2B。MiniCPM-V 4.7 的主打變體 MiniCPM-V 4.7 35B-A3B，則啟用 35B 中的約 3B。讀完這兩句話，你會預期 Moondream 的檢查點是比較容易部署的那一個。但是否真的如此，完全取決於兩篇發布文章都沒有先提出的問題：那些休眠的專家究竟住在哪裡？

那個問題正是這兩個模型真正分歧之處，而答案就是 MiniCPM-V 4.7 以其現有形式存在的全部理由。它的發布——來自 OpenBMB 的 MiniCPM-V 4.7 35B-A3B 與 MiniCPM-V 4.7 1B，於 2026 年 10 月 6 日發布——是圍繞著在手機上順暢運行 35B MoE 而不使其效能下降來打造的。Moondream 3 Preview 於 2025 年 9 月 18 日由 Moondream 發布，並在 2026 年 10 月的收購後如今成為 Prime Intellect 的一部分，它採取了相反路線：讓 MoE 保持小巧，並用 Photon——Moondream 自家的推理引擎——在 GPU 上運行。兩種選擇都沒有錯。它們是對不同限制條件的答案，而你身處的限制條件會為你決定這項比較。

活躍參數是運算數值，不是儲存數值

這就是讓裝置端 MoE 變得棘手的算術，而 OpenBMB 在其自家模型卡中把這點說得很明白：一個 MoE 模型的總參數數量可以遠多於它為單一 token 所啟用的參數量，但它在裝置端的儲存需求並不限於那些被啟用的參數。不同的 token 會在不同層選用不同的專家，而裝置記憶體往往無法容納全部專家。

• Moondream 3 Preview — 總參數 9B，啟用參數 2B。24 層，前四層為稠密層，其餘為 MoE 前饋區塊，具 64 個專家，每個 token 啟用 8 個。隱藏維度 2048，GeGLU 內層/閘控維度 1024。

• MiniCPM-V 4.7 35B-A3B — 總參數 35B，約 3B 啟用。MiniCPM-V 系列中首個 MoE。同一版本中的 1B 變體是稠密模型，而非 MoE，這點在下面很重要。

• 這種落差——把活化參數除以總參數，Moondream 3 Preview 看起來就是輕量許多的模型。但把位元組除以位元組，MiniCPM-V 4.7 35B-A3B 才是承載四倍權重的那一個。

• 為什麼它無法解決任何問題——限制裝置的是常駐集，而常駐集比活躍計數更接近總量。無論路由器觸發什麼，9B MoE 都無法放進 2B 稠密模型所能放進的記憶體中。

所以，「2B active」是關於每個 token 計算量的陳述。它不是關於你所需記憶體的陳述，而把它當成後者，正是團隊最常錯估 MoE 部署規模的方式。

OpenBMB 直接攻克了儲存問題

MiniCPM-V 4.7 的設計，最適合理解為針對這個落差而來的三項技術。Lookahead Expert Scheduling 使用跨層路由預測來預先載入下一層可能需要的專家，並在實際路由器所選出的專家中，優先處理成功預取的那些——預測僅引導預取與排程，而運算仍遵循模型原本的 token 層級路由，且任何預測漏掉但所需的專家仍會照常載入與評估。細粒度的逐層量化可減少專家權重的儲存佔用與記憶體流量。DSpark 推測取樣已整合進裝置端路徑，以在兩者之上進一步提升解碼效率。

所述結果是在 iPhone 17 Pro Max 上每秒 13 個以上的 token，記憶體約 3 GB，OpenBMB 將其描述為首個能在裝置端順暢執行且不犧牲效能的開源 MoE 模型。它的比較明確，且值得就其本質加以留意：在 Instruct 模式下，MiniCPM-V 4.7 35B-A3B 以更少的推論時間達到比 Qwen3.6 35B-A3B 更高的整體分數。這是廠商回報的同尺寸級別宣稱，而且是較有用的一種，因為兩個模型都是在同一套測試框架上測量。

其餘的部署面向也異常廣泛。支援 iOS、Android 與 HarmonyOS，並對 Rockchip、Houmo、Intel、AMD 與 Arm 的晶片平台提供 day-0 支援。推論可執行於 SGLang、vLLM、llama.cpp 與 Ollama；微調則支援 SWIFT 與 LLaMA-Factory。隨附 GGUF、BNB、AWQ 與 GPTQ 量化，另加上 FP8。1B 版本又是另一回事——它是稠密模型，而非 MoE，OpenBMB 將其定位為在 MiniCPM-V 4.6 的基礎上持續精進，同時在整體分數與推論效率上大幅超越 Qwen3.5 0.8B，而這才是對 sub-1B 模型而言誠實的比較。

Moondream 的答案是移動硬體，而非權重

Moondream 並沒有試圖讓 9B MoE 塞進手機。它保留了架構，並改變了執行位置：其推論引擎 Photon 會將每個模型編譯成帶有自訂核心的單一 GPU 程式，並在從 Ampere 世代起的 NVIDIA GPU 以及 Apple Silicon Mac 上本機執行，且提供與 Moondream Cloud 相同的 API。

這是個站得住腳的策略，而 Prime Intellect 的收購公告說明了它為何具吸引力：Moondream 團隊打造了 Photon 以及其背後的 megakernel 編譯器，而 Prime 收購該公司的理由在於，決定模型實用性的是服務，而非架構。那篇文章中的吞吐量數據——單顆 H100 上每秒超過 60 次 Moondream 推論、數十毫秒內給出答案、Moondream 3.1 每秒 34 次請求——都是 Prime 自家提出的，如今已成為銷售素材，因此應據此標示。但方向無疑是明確的：Moondream 押注的是，你寧可要一個由 GPU 支援的快速模型，也不要一個手機大小的模型。

還有第二個差異，而且它根本不在模型卡裡。Moondream 3 Preview 的託管端點 Moondream Cloud 將在收購後於 2026 年 11 月 13 日關閉，未使用的已購買點數將予以退還。MiniCPM-V 4.7 沒有這種依賴性，因為它從來就不是以託管產品為主要定位——它是一組權重，並附帶廣泛的裝置端部署方案。如果你的評估包含呼叫端點的便利性，那麼在這項比較的其中一方，這種便利性即將到期。

任務能力：這兩張卡片各自誠實地說明了不同的事情。

Moondream 3 Preview 的四項原生技能分別是 query、caption、point 與 detect，全都會回傳結構化輸出，而發布文章的重點放在偵測與指向。query 技能預設以推理模式執行，並提供文件記載的 reasoning=False 旗標供簡單問題使用，而且推理軌跡是有依據的——它們會參照影像中的特定部分，這就是為什麼 Moondream 稱之為帶有依據的視覺推理，而非一般所說的推理。上下文長度為 32K token，相較於前一代的約 2K 大幅提升，並採用自訂的 SuperBPE 分詞器；發布文章坦率指出，後訓練並未完全善用這個長視窗，完整的 32K 主要是為了微調而存在。

MiniCPM-V 4.7 的模型卡則主打效率與廣度：單圖、多圖與影片理解，搭配混合 4x/16x 視覺 token 壓縮，讓你能針對每項任務在視覺細節與推論成本之間取捨，以及來自 LLaVA-UHD v4 的 ViT 內部早期壓縮，可減少後段編碼器層的運算量。它也隨附一種微調方法——Self-Replay Fine-Tuning，目標是以低成本擴展模型能力，同時減少對其已知內容的遺忘。

• 具依據的偵測與指向——Moondream 3 Preview：架構中的原生技能、結構化座標、具依據的推理軌跡。MiniCPM-V 4.7：多圖像與影片理解是其宣稱的強項；該模型卡並未主打開放詞彙偵測。

• 影片 — MiniCPM-V 4.7 支援影片輸入，並有一份使用 128 個影格的範例文件。Moondream 3 Preview 的說明文件記載了影像技能，並針對同一張影像的重複查詢提供影像編碼快取。

• 可控的細節 — MiniCPM-V 4.7：一個 downsample_mode 參數，預設為 16x，4x 則可呈現更細緻的細節，於每次呼叫時選擇。Moondream 3 Preview：視覺編碼器中的多重裁切通道串接，發布貼文指出該編碼器可能因極小的字體而失準。

• 授權 — MiniCPM-V 4.7：Apache 2.0，兩個版本皆同。Moondream 3 Preview：Business Source License 1.1 並附帶額外使用授權，允許商業及生產用途，但禁止提供通用型的託管 Moondream 服務。Moondream 3.1 則改採 Moondream Model License 1.0，核心限制相同，但表述更為簡潔明瞭。

授權條款不是這場比較的附註。如果你打算為其他人代管這個模型，Apache 2.0 和 Moondream 的 source-available 條款完全不是同樣的起始條件，而無論哪一個在你的任務上基準測試表現更好，這一點都成立。

微調是兩張卡都指向的地方，但理由相反

兩家廠商都告訴你，入門款並非真正的產品，這既令人耳目一新，也暗示了價值究竟落在何處。

Moondream 的發布文章將可訓練性列為四大目標之一，理由是真正的視覺任務需要專業化——判讀 X 光片、在人群中辨識出陷入困境的人——而且就連人類也需要為這些任務接受訓練。該公司為此推出了 Lens，而 Moondream 3.1 的發布則更進一步：已公布的 3.1 基準測試分數，是透過 Lens 在每個基準測試各自的訓練分割上微調各任務專屬的 LoRA，然後再透過同策略蒸餾（on-policy distillation）把它們學到的內容融回基礎權重，因此可下載的檢查點無需任何微調就能獲得好成績。這值得讀兩次。這是正當的工作流程，也是一種異常透明的揭露，而這也意味著那些數字並非冷啟動的開箱即用數據——這些任務的訓練分割已被餵給模型。

OpenBMB 的對應方案是 Self-Replay Fine-Tuning，針對的是不同的問題：以低成本增添能力，同時不遺忘既有能力。它的主要賣點在於能力保留，而非峰值分數。

若你打算微調這兩個模型中的任何一個，實務上的差異與貫穿這整份比較的差異如出一轍。Moondream 的路線假設需要 GPU 與託管服務。MiniCPM-V 4.7 的路線則假設你能在你既有使用的框架上微調，接著部署到你既有的目標裝置，並有一套已發布的裝置端量化方案將它帶到那裡。

路由層在什麼情況下能證明其價值

這裡的兩個模型都不是透過 OrcaRouter 提供服務——兩者都是你自己託管的開放權重檢查點，而其中一個下個月將失去它的託管端點。這使得真正有趣的問題，正是兩張模型卡都避而不談的那個：你選擇的模型處理得不好的那些請求，會發生什麼事？

標準答案就是第二個模型，而第二個模型的標準成本在於整合：另一個 SDK、另一套驗證機制、另一種重試策略。這類工作會悄悄吃掉一個衝刺週期，然後變成永久的維護負擔。OrcaRouter 的模型融合正是為了處理該問題中較狹隘的那一種——由一組模型在單一模型的回答不夠值得信賴的呼叫上共同回答——而路由 DSL 則針對較廣泛的那一種，讓你能將數個模型組合進單一呼叫，以便由便宜的本地模型處理簡單的多數，並由更大的模型接手剩餘部分。

一組金鑰背後有超過 200 個模型，全數採用供應商定價，不額外加價，這代表供應商降價當天就會反映到你身上，而不是等到下一個帳單週期；而當上游服務品質下降時，跨供應商的容錯移轉會自動進行。對自行架設的 VLM 而言，路由層位於模型之上，而不是取代模型。這是在這項比較中對其定位最誠實的描述；而對於裝置上執行 MiniCPM-V 4.7 35B-A3B、並由託管模型補足未命中案例的系統來說，它正是避免這兩者變成兩套系統的關鍵。

哪一個，由你實際擁有的限制條件來決定

如果模型必須在裝置端執行，MiniCPM-V 4.7 35B-A3B就是答案，而且毫無懸念。OpenBMB 的整個發布都圍繞著那個阻礙 35B MoE 在手機上執行的儲存問題來打造——專家排程、逐層量化、推測解碼——並公布了由此得出的數字：在約 3 GB 下每秒 13 個以上 token。Moondream 3 Preview 裡沒有任何東西在應對那個問題，因為 Moondream 選擇不讓自己碰上它。

如果情況涉及 GPU，而任務是 grounded detection（有依據的偵測），Moondream 3 Preview就是更專門的儀器。原生 detect 與 point 功能，搭配結構化座標與可檢視的 grounded reasoning 軌跡，這與同時能讀取影像中文字的通用多模態模型是截然不同的產品；而且如果需要人工審查輸出，這些軌跡正是關鍵特色。

如果你正猶豫於兩者之間，別根據基準測試表來決定。用你自己的提示詞，把你自己的圖像跑過兩者，並為輸出評分，因為在這項比較中，唯一能經得起你的工作負載考驗的數字，就是你自己產出的那個。而且要先確認授權，再看模型，因為 Apache 2.0 與帶有託管服務限制的原始碼可見授權，是完全不同的決定——其中一個可能在準確率數字變得重要之前，就讓評估提前結束。