MiniCPM-V 4.7 對上 LFM2.5-VL 3B：一個 70 GB 的謎團，對比一款能在筆電上出貨的 3B 模型

MiniCPM-V 4.7 和 LFM2.5-VL 3B 被當成同一類產品販售——可自行執行的精簡視覺語言模型——但實際上兩者幾乎不能再更不同。LFM2.5-VL 3B 是完成品：來自 Liquid AI、附有授權條款、模型卡與已在社群流通的 GGUF 量化版本，且有完整文件說明的 31 億參數檢查點，不直接下載來試試的好理由也越來越少。MiniCPM-V 4.7 則是 OpenBMB 於 2026 年 10 月 6 日上傳至 Hugging Face 的 352 億參數稀疏混合專家檢查點，沒有模型卡、沒有授權條款，也完全沒有任何基準測試。把它們拿來比較，並不是在比較兩個模型。而是在把一個模型，跟一個很可能會成為模型的產物相比。

對決，開門見山地老實說

這一頁能讓你完整了解 LFM2.5-VL 3B，因為 Liquid AI 發布了一份完整資料。它能讓你完整了解 MiniCPM-V 4.7 的樣貌，但對其行為一無所知，因為 OpenBMB 只發布了一份config.json就停在那裡。以下關於 MiniCPM 這一側的一切，都是從那份設定檔與權重索引讀出來的；關於 Liquid 這一側的一切則來自模型卡，而模型卡本身的效能宣稱是廠商自行回報，並已如此標示。當某個數字在其中一個模型有、另一個模型卻沒有時，誠實的做法是讓這個缺口清楚可見，而不是把它粉飾過去。

每一項是什麼

LFM2.5-VL-3B 於 8 月 11 日發布。它是 LFM2.5 系列的多模態變體，專為裝置端部署打造，而且並非從零開始：它以 LFM2.5-2.5B 語言主幹為基礎，搭配 SigLIP2 NaFlex 視覺編碼器。NaFlex 正是文件處理的關鍵所在——它保留原始長寬比與解析度，而不是把每張影像硬塞進固定方形，這也解釋了為何這張模型卡的主要亮點是以自然語言查詢進行定位，以及帶版面標註的全頁 OCR。它採用 LFM Open License v1.0 授權發布，涵蓋十六種語言，包括英文、中文、日文、韓文、阿拉伯文、印地文、法文、德文、西班牙文、葡萄牙文、義大利文、波蘭文、俄文、泰文、越南文和印尼文。由於它是 3B 模型，GGUF 版本在發布後一天內就出現，而 DSpark 變體也在九月隨之推出，因此它周圍的生態系相當真實：你現在就能拉取一個量化版本，直接在筆電上執行。

MiniCPM-V 4.7 是一個擁有 35,212,875,824 個參數的 BF16 檢查點，由十六個分片組成、總計 70.4 GB，類別為 MiniCPMV4_7ForConditionalGeneration，上傳至 openbmb/MiniCPM-V-4.7-35B-A3B，於 2026 年 10 月 6 日。

其語言主幹標記為 qwen3_5_moe_text——一個衍生自 Qwen3.5 的稀疏 MoE，擁有 256 個專家，每個 token 選用其中 8 個——其 40 層採用固定的「三線性對一全注意力」模式，因此 40 層中有 30 層使用 Mamba 風格的線性路徑，而非傳統注意力。上下文長度為 256K。視覺塔是 MiniCPM-V 系列自家的，形狀大致與 MiniCPM-V 4.6 所用者相同。儲存庫中沒有 README，而在 Hugging Face 上這代表沒有授權條款。

真正可能的比較

六個面向、雙方，以及每一項都附註說明該數字帶有多少份量。

• 總參數量 — LFM2.5-VL 3B：3.12B，每個 token 皆全部啟用。MiniCPM-V 4.7：總計 35.2B，採稀疏架構，每個 token 啟用 256 個專家中的 8 個。MiniCPM 的數字無法與稠密參數量相提並論，且實際啟用參數預算並未公布；請將「A3B」視為名稱，而非量測值。

• 磁碟上的有效大小 — LFM2.5-VL 3B：BF16 格式的單一約 6 GB safetensors 檔案，或作為 GGUF 時僅佔其一小部分。MiniCPM-V 4.7：橫跨十六個分片的 70.4 GB，僅限 BF16。

• 授權條款 — LFM2.5-VL 3B：LFM Open License v1.0，已在模型卡上發布並提供連結。MiniCPM-V 4.7：未宣告任何授權。若缺少授權：標籤，預設立場為保留所有權利，因此這是個阻礙，而非註腳。

• 視覺方法 — LFM2.5-VL 3B：SigLIP2 NaFlex，原生解析度並保留長寬比，卡片宣稱具備版面標註的全頁 OCR。MiniCPM-V 4.7：自訂 minicpmv4_7_vision 塔，搭配 downsample_mode: "16x" 與 max_slice_nums: 9。

• 背景 —— LFM2.5-VL 3B：該模型的卡片所提供的 serving 範例，相較於長上下文設計顯得較為保守，而該系列主打裝置端記憶體預算。MiniCPM-V 4.7：max_position_embeddings: 262144，其 tokenizer model_max_length與之一致，同為 256K。

• 品質佐證 — LFM2.5-VL 3B：已發布的模型卡，內含廠商宣稱相較於 LFM2-VL-3B 的改進、第三方量化版本，以及 Hugging Face 上約 25,900 次下載的紀錄。MiniCPM-V 4.7：零下載、三個讚、沒有模型卡、沒有基準測試、沒有獨立評估。無可引用。

• 工具 — LFM2.5-VL 3B：第三方提供的 GGUF 與 MLX 建置，外加一個 DSpark 變體。MiniCPM-V 4.7：無。目前尚未有任何形式的量化。

這個頁面缺失的三分之二

這個領域的每一篇比較文章都會附上一段基準測試段落。這一篇沒辦法。MiniCPM-V 4.7 沒有 MMMU、沒有 OCRBench、沒有 DocVQA、沒有 grounding 數字、沒有延遲量測，也沒有 VRAM 數據——不是因為這些資料查起來不方便，而是因為儲存庫裡沒有任何東西包含它們，也沒有第三方產出過這些數據。一個上傳時沒有 model card 的模型，從評估角度來看，就是未經量測的。任何告訴你相反說法的人，都是在從家族名稱或參數數量推斷，而這兩者都是多模態品質的糟糕預測指標。

更細微的問題也是如此：稀疏 MoE 是否真的有所幫助。35B-A3B 設計以總記憶體換取每個 token 的運算量，而稀疏模型的指令遵循品質完全取決於路由器的訓練成效。配置顯示路由輔助損失係數為 0.001，並且在 256 個路由專家之外還有一個共享專家，這是常規配置——但常規配置並不代表路由良好。

在 Liquid 方面，缺失的部分則不同：這張卡的品質宣稱是廠商自己的。

OCR 與 grounding 的改進，是由訓練該模型的人所描述的；而雖然第三方量化版本與下載量顯示，社群認為它已足夠有用而願意轉換，但那只是採用證據，而非品質證據。沒有人發表過獨立的正面對決比較。

你真正會選用的是哪一個？

這裡的決策樹格外清晰，因為這兩個模型並不是在爭奪同一項任務。

如果你需要在筆電、手機、Jetson 或單張中等規格的 GPU 上執行視覺語言模型，LFM2.5-VL 3B 是兩者中唯一能滿足這個需求的選擇。它小到足以量化，授權條款也允許這麼做，而且已經有人替你完成了轉換工作。對於文件版面、螢幕截圖解析，以及在符合邊緣運算預算的尺寸與語言足跡下進行有視覺依據的物件描述，模型卡上所列的強項與部署目標相符。

MiniCPM-V 4.7 在 BF16 下以 70 GB 而言，並不是那項任務的候選者。它是相反任務的候選者：在伺服器硬體上運行的長上下文、高吞吐量多模態模型，適用於 256K 視窗與線性注意力 KV 快取節省正是重點的工作負載。它是否能勝任那項任務仍是未知數，而且在它於任何商業用途中實際執行那項任務之前，必須先解決授權問題。

還有第三個選項值得提出來談，那就是你或許根本不需要做出選擇。如果架構是「由小型本機模型處理大部分流量，並把棘手案例交給託管服務」，那麼其中本機那一半是你今天就能做的決定，而託管那一半則是路由決策。OrcaRouter 以單一金鑰涵蓋數百個託管模型，價格就是各家供應商的定價，完全不額外加價，並在供應商效能下降時自動容錯移轉 —— 但要把話講清楚，它並不是什麼：LFM2.5-VL 3B 和 MiniCPM-V 4.7 都不是該路由器上的託管模型。兩者都是你自己部署服務的權重。路由器才是位於它們後面的東西。

這件事目前的狀況，以及需要更新的內容

Liquid AI 推出了一個已完成的小型模型。OpenBMB 則推出了一個尚未完成的大型模型。讀者想要的那種比較——準確度對上延遲、OCR 對上 OCR——在 MiniCPM 這邊目前還無法寫成，而不誠實的做法，就是用參數量算術來填補篇幅。請留意該儲存庫的 README。它出現的那一天，將會載明授權條款與第一批真實數據；到了那天，這就會變成真正的正面對決，而不是產品旁邊的一張規格表。

那個模式中代管的那一半，是一項路由決策，而不是第二份合約。各家供應商的定價，我們不額外加價LFM2.5-VL 3B 和 MiniCPM-V 4.7 都不是 OrcaRouter 上的代管模型——兩者都是你自己部署的權重。