LFM3-VL-2B 對比 MiniCPM-V 4.7 35B-A3B：不是模型的那一欄

打開基準測試表，看看LFM3-VL-2B，你會看到一個 MiniCPM 欄位。它標示為 MiniCPM-V 4.7 1B。那是較小的兄弟版本。大多數人所說的 MiniCPM-V 4.7——OpenBMB 的 MiniCPM-V 4.7 35B-A3B，也就是 MiniCPM-V 系列首個混合專家檢查點——根本不在 Liquid AI 的表中，而且在兩家實驗室都有公布的基準測試上，它與 1B 相差甚遠。因此，人們真正在權衡的對決——LFM3-VL-2B 對上 MiniCPM-V 4.7 35B-A3B——必須從兩張廠商表格手動拼湊而成，而這兩張表共享基準名稱，卻不共享評測框架。接下來就是這番拼湊，並讓接縫保持可見。

尺寸上的落差是第二個令人意外之處。一個模型有 19.2 億個稠密參數，只需幾 GB 就能容納。另一個模型儲存了 352.1 億個參數，而每個 token 大約只會用到其中 30 億個。若當成規格表來讀，這根本算不上同一量級的對決。若看成對同一個問題的兩種答案——你能在無法掌控的裝置上跑什麼——那會是一場關於如何達到目標、真正有意思的分歧。

兩個模型，一個名稱

命名衝突正實質損害這項比較被解讀的方式。Liquid AI 的模型卡對此相當嚴謹：欄位標示的是 1B，而這個 1B 確實是 1.92B 模型的合理同級對手。但搜尋結果、聚合網站和日常引用全都把「MiniCPM-V 4.7」混為同一款，而 35B-A3B 才是真正擁有受眾的變體——截至 2026 年 10 月 28 日，它在 Hugging Face 上有 289,535 次下載和 1,095 個讚，相較之下，1B 版本則有 155,428 次下載和數百個讚。

日期能解釋其中一部分差距，但無法解釋其餘部分。OpenBMB 的 35B-A3B 儲存庫建立於 2026 年 10 月 7 日，而專案自身資料標示的發布日期為 10 月 12 日。Liquid AI 的 LFM3-VL-2B 儲存庫於 10 月 19 日上線，LFM3 系列則於 10 月 27 日發布。LFM3-VL-2B 公開至今僅九天，因此其 255 次下載是日曆上的事實，而非定論。按讚比例這一行更有意思：LFM3-VL-2B 為 45，MiniCPM 則為 1,095。下載後者的人喜歡到願意表達出來。

每一個實際上是什麼

• 參數 — LFM3-VL-2B 是 1.92B 稠密模型：1.73B 語言主幹、164M 自研視覺編碼器與 25M 投影器。MiniCPM-V 4.7 35B-A3B 將 35.21B 參數分散儲存於 256 個專家，並為每個 token 路由其中 8 個，約 3B 啟用。

• 主幹 — 24 層 LFM3，拆分為 13 層閘控短卷積、5 層滑動視窗注意力層和 6 層全域注意力層，相較於隱藏維度為 2,048 的 40 層 Transformer。

• 視覺路徑 — 一個 14 層編碼器，由 8 個閘控深度分離式 2D 卷積與 6 個雙向注意力層組成，作用於 16×16 圖塊並搭配 2D 旋轉嵌入；相較之下，文字堆疊第 6 層插入了一個 27 層、隱藏大小為 1,152 的塔，並在編碼器內部進行早期 token 壓縮，以及可切換的 4× 或 16× 視覺降採樣。

• 上下文 — LFM3-VL-2B 為 128K tokens，MiniCPM 為 256K，兩者皆包含輸入與輸出。

• 輸入 — Liquid 模型可接受文字、圖像，以及每秒 2 幀的影片；OpenBMB 的模型則可接受文字、圖像與影片。兩者無論輸入或輸出方向都不處理音訊。

• 磁碟上的權重 — BF16 時約 3.8 GB，對比 BF16 時約 65.6 GiB。

• 授權條款 — LFM Open License v1.0，Liquid 將其描述為年營收低於 1,000 萬美元時可免費商用，對比 Apache 2.0 則無營收條件。

架構上的分歧就是整件事的重點。Liquid 押注：小型稠密模型加上專用視覺編碼器，在每張影像的運算量上勝過 SigLIP 風格的塔狀架構，並公布類別表來證明。OpenBMB 押注：可以保留 35B 模型的能力，還能讓它在手機上運行，做法是讓昂貴的部分以串流方式處理，而不是常駐。兩者都是關於記憶體的押注，只是方向相反。

落差確實存在，而且比這種論述所呈現的還要窄。

以下是兩家廠商表格在把正確的資料列並排放置後所顯示的內容。這些全都是實驗室自行回報的，而測試框架的注意事項則在後面。

• MMMU — LFM3-VL-2B 開啟思考模式時為 55.7，關閉時為 48.6；MiniCPM-V 4.7 35B-A3B 在 4× 視覺壓縮下為 80.22，在 16× 下為 80.00。

• MMStar — 74.4，相較於 4× 的 80.67、16× 的 80.13。

• OCRBench v1 — 86.3，相較於 4× 時的 91.20、16× 時的 90.40。

• MathVista — 啟用思考時為 84.2，未啟用時為 68.5，相較於 4× 時的 88.00 與 16× 時的 87.30。

• CharXiv 推理 — 4× 時為 70.2，相較於 75.60；16× 時為 69.20。

MMMU 正是 35B 展現其規模價值之處：相較於思考設定高出 24.5 分，相較於非思考設定高出 31.6 分。這是大學程度的多模態推理基準，而這樣的差距足以承受任何關於測試框架差異的合理質疑。

其他項目的差距都比這個說法框架所暗示的更接近。OCRBench 的差距是 4.9 分。當 LFM3-VL-2B 進行思考時，MathVista 的差距是 3.8 分。在 CharXiv 推理上，Liquid 模型在思考模式下輸了 5.4 分——但比 35B 的 16× 數字高出一分。一個 2B 模型在文件 OCR 和圖表上與 35B 的差距在五分以內，這項發現應比 MMMU 的頭條標題獲得更多關注。

現在來說注意事項，因為它們很重要。Liquid 的數據來自於在 vLLM 0.27.1 上對 62 項基準測試所進行的一次單次執行，並正規化至 0–100，且除了標示為例外的配置外，每個模型都啟用了推理模式。OpenBMB 的五個數字是以圖表影像而非數值表格的形式公布，此處是根據第三方彙整方對那些圖表的判讀轉錄而來，因此請將小數視為近似值。這兩家實驗室在視覺 token 預算、提示或解碼設定上並不一致，而 OpenBMB 這邊的 4× 與 16× 差異本身就會使其分數變動多達六分。這是兩組並列陳述的主張，而不是受控實驗。

小型模型有數據、而大型模型未公布的地方

Liquid 發表了 62 行。OpenBMB 發表了五行。這種不對稱是這項比較中最鮮少被如實報導的事實，而且其影響方向對較小的模型有利。

• 視覺定位 — LFM3-VL-2B 在 RefCOCO-avg 達 90.5、RefCOCO-M 達 95.2、Point-Bench 達 73.8、RefSpatial-Bench 達 49.8。MiniCPM-V 4.7 35B-A3B 已發表的評測中並無對應的項目。

• GUI 理解 — ScreenSpot-Pro 55.5，ScreenSpot-v2 在桌面端 94.6、行動端 92.2、網頁端 89.9。同樣地，OpenBMB 方面並未發布任何內容。

• 具身推理 — EmbSpatial-Bench 82.9、RoboSpatial-Home 63.4、Where2Place 44.9。同樣缺席。

• 影片 — 無字幕情況下 Video-MME 62.8、MVBench 69.4、MLVU 71.3、ActivityNet-QA 71.2。MiniCPM-V 4.7 支援影片，模型卡也對此詳加討論，但數值表中並未列出可供我們查證的影片列。

這是缺乏證據，不是預設的勝利。若你正在建立機器人或螢幕代理管線，誠實的立場是：35B 在那些任務上的能力屬於未知，而非薄弱。但「未知」本身就是採購問題：你無法圍繞一個沒有人公布的數字來規劃部署，而 LFM3-VL-2B 是兩者中唯一能在下載前讀到其視覺定位與 GUI 效能的模型。

記憶論點是雙面刃

選擇 2B 而非 35B 的常見理由是，2B 放得下。LFM3-VL-2B 確實放得下，完全且可預期：BF16 下約 3.8 GB，常駐記憶體，不進行分頁，裝置在高負載時也不會出現意外。對於要交付到您無法控制的硬體上的產品而言，這確實是一項非常強悍的特性。

MiniCPM-V 4.7 35B-A3B 高達 65.6 GiB，根本不可能放進手機，而 OpenBMB 的整體設計正是為此而生。Lookahead Expert Scheduling 會預測下一層的路由，並預先提取它預期會用到的專家；細粒度的逐層量化會縮小這些專家，讓它們移動得更快；DSpark 推測性取樣則補上解碼停滯的空檔。廠商宣稱，在 iPhone 17 Pro Max 上使用約 3 GB 記憶體可達到每秒 13 個以上 token，而在配備 16 GB 的 iPad Pro M4 上則可達到每秒 17 個以上。

所以，裝置端的主張並不是「35B 很小」，而是「35B 以串流方式運作，而且串流順暢到足以使用」。這是兩種不同的押注，失敗模式也各不相同。常駐的 3.8 GB 模型會優雅降級——它要嘛已載入，要嘛沒有。串流的 65.6 GiB 模型則會因快閃記憶體頻寬、熱節流與冷啟動延遲而降級，而這些因素會因裝置而異，這是單一 iPhone 上的基準測試所無法捕捉的。

實務上的分界在於：如果你既掌控不了儲存速度，也掌控不了散熱餘裕，那麼常駐記憶體是風險較低的路徑。如果你要出貨到近期的旗艦硬體，而且想要那份準確度，OpenBMB 的做法已不再是理論——它是一個已發佈的模型，背後還有一個可用的分支。

首日工具並非平局

LFM3-VL-2B 隨附 BF16 權重，需使用 transformers 5.21 或更新版本，另外還提供 GGUF（包含一個量化感知蒸餾的 Q4_0 檢查點）、MLX 4 位元版本與 ONNX 匯出檔。伺服器支援尚未完成：vLLM 被描述為進行中，SGLang 正在 pull request 46858 中接受審查，而 llama.cpp 則在 pull request 31252 中接受審查，並明確註明尚不支援影片輸入。模型卡也建議 vLLM 與 SGLang 使用 qwen3 推理剖析器與 qwen3_coder 工具呼叫剖析器，這個細節說明了這項支援是多近期才接上的。

MiniCPM-V 4.7 35B-A3B 支援 SGLang、vLLM、llama.cpp 與 Ollama，並可透過 SWIFT 與 LLaMA-Factory 進行微調，提供 GGUF、BitsAndBytes、AWQ、GPTQ、FP8 與 int4 版本，且於 Rockchip、Houmo、Intel、AMD 與 Arm 的晶片平台上提供首日支援，涵蓋 iOS、Android 與 HarmonyOS。裝置端路徑採用 OpenBMB 自家的 llama.cpp-omni 分支，而非上游 llama.cpp。

對本月就要上線的生產部署來說，這根本不是難以取捨的選擇。至於研究探索、筆電展示，或你打算自己維護的微調，LFM3-VL-2B 透過 transformers 現在就能運作，而且不必花上一週處理建置旗標。

更多團隊會誤踩的授權紅線

Apache 2.0 相較於 LFM Open License v1.0，是比 MMMU 差距更大的實務差異，因為它適用於每一次部署，而不是只適用於困難案例。Apache 2.0 不附帶營收條件、沒有限制用途領域，對於量化或蒸餾的衍生作品是否繼承條款也沒有模糊空間。依 Liquid 自己的說法，LFM Open License v1.0 在年營收低於 1,000 萬美元時可免費商用，這意味著營收超過這條線的公司，是在出貨前就得先談授權，而不是出貨後才談。

那單一條款讓許多買家的比較局面重新洗牌。低於門檻的新創公司不花一毛錢，就能拿到一個更小、更快、在 grounding 方面文件更完善的模型。超過門檻的公司則會拿到一個需要簽名的模型——到那時，35B 的 Apache 2.0 就成了一個你會留意的功能。

兩家供應商都不會告訴你的事

沒有獨立的正面對決。沒有任何第三方實驗室在同一個評測框架上跑過這兩個模型，而最接近中立排行榜的東西——Liquid 自家的表格——比較的是 LFM3-VL-2B 與 1B，而不是 35B。本文中的每一個數字，都來自打造其所描述模型的那間實驗室。

還有兩個缺口值得說明。兩個模型都沒有我們能查證的逐 token 價格，因此在這裡做成本比較只會是憑空編造。而且截至 2026 年 10 月 28 日，兩者都不在 OrcaRouter 目錄 中——搜尋 minicpm 找不到相符的模型，LFM3-VL-2B 也同樣未列出。這使得時至今日，這是個自架或供應商 API 的決定，而非路由的決定。

該選哪一個

• 文件、圖表、密集文字與高難度多模態推理，搭配你自行掌控的服務堆疊——MiniCPM-V 4.7 35B-A3B。MMMU 的領先幅度是唯一大到足以經受測試框架種種告警的結果，而 Apache 2.0 則徹底消除了授權方面的疑慮。

• 一台你無法控制的裝置，記憶體預算固定，且無法容忍串流延遲——LFM3-VL-2B。常駐佔用 3.8 GB，而且是兩者中唯一有已發布的 grounding、GUI 與具身數據可供規劃參考的型號。

• 螢幕代理、機器人技術與空間任務——預設使用 LFM3-VL-2B，因為它是唯一有已發表證據的一方。在這些領域，應將 35B 視為尚未證實，而非能力薄弱。

• 本月只需最少的整合工作即可投入正式環境——MiniCPM-V 4.7 35B-A3B。SGLang、vLLM、llama.cpp 與 Ollama 的支援，對應三則「審核中」或「進行中」的註記。

• 年營收超過 1,000 萬美元的公司 — MiniCPM-V 4.7 35B-A3B，除非裝置端限制嚴格到足以需要進行授權洽談。

說實話，OrcaRouter 如何契合

它還不合適，而說不是這樣，正是那種會讓一篇部落格文章被忽略的說法。目前這兩個模型都不在 OrcaRouter 的目錄中，所以沒有金鑰可以交給你，也沒有價格可以報。

真正重要的是視覺模型實際落地時會發生什麼事：一個與 OpenAI 相容的端點橫跨 200 多個模型，供應商定價以 0% 加成原樣傳遞，因此廠商調價當天就能同步生效；再加上自動容錯切換，單一供應商故障也不會讓你的路由中斷。像這樣的比較——兩個模型對記憶體的看法不一致，又沒有獨立基準測試可以定論——有用的做法是把兩者都放在同一個端點後面跑，用自己的圖片實測，而不是爭論誰的圖表才對。

看什麼

有四件事會改變這篇文章。拉取請求 31252 帶著影片支援合併，這會把 LFM3-VL-2B 的影片路徑放上標準 llama.cpp。vLLM 支援脫離「進行中」狀態，這會讓它成為可正式投入服務的選項，而不只是示範。一項獨立評估在同一個測試框架上跑這兩個模型——這是這次比較中最有價值卻仍缺席的產物。以及 Liquid AI 把 35B 加入自家的比較表，這會告訴你該實驗室認為它是真正的同級模型。

在任何一項落實之前，站得住腳的總結比兩家廠商各自的說法都更狹窄：35B 贏得真正重要的推理基準，且在 OCR 上毫無損失；2B 在佐證證據與可預測性上勝出；而授權條款決定的部署數量比基準更多。