MiniCPM-V 4.7 與 LFM3-VL-2B：基準分數較好，卻是錯誤的感測器

Liquid AI 把 MiniCPM-V 4.7 1B 放進自家的比較表，然後擊敗了它。在 Liquid 執行的 62 項基準測試套件中，LFM3-VL-2B 在啟用推理時平均為 71.4，未啟用時為 62.1；MiniCPM-V 4.7 1B 平均為 57.5。這在小模型層級是 13.9 分的差距，也是大多數比較文章會停在的數字。但這卻也是決策中最沒用的數字，因為這兩個模型並不是在爭奪同一個位置。一個是 19.2 億參數的稠密模型，設計目的是成為完整解答。另一個則是雙模型系統中便宜的那一半，而昂貴的那一半是 350 億參數的專家混合模型。

The version of this matchup that matters depends on which MiniCPM-V 4.7 you mean. The 1B is a 1.55-billion-parameter dense model that fits in a 672 MB Q4_K_M file — 641 MiB, which is where the 641 MB on the cards comes from. The 35B-A3B is 35.2 billion stored parameters with roughly 3 billion active per token, and it is not in Liquid's table at all. LFM3-VL-2B sits between them and is, on Liquid's own numbers, a better general vision model than the small MiniCPM and a much weaker one than the large MiniCPM. Everything below is about which of those facts should decide your architecture.

三個層級假裝成兩個模型

LFM3-VL-2B 是一項產物。它擁有 19.2 億個參數，由 17.3 億參數的語言主幹、1.64 億參數的自家視覺編碼器與 2500 萬參數的投影器組成，具備 128K token 上下文，影片以每秒兩幀取樣，且僅用單一組權重即可執行偵測、OCR、圖表與描述。Liquid 於 2026 年 10 月 27 日宣布 LFM3 系列；LFM3-VL-2B 儲存庫則於 10 月 19 日上線。

MiniCPM-V 4.7 是兩個共用視覺塔的產物。1B 是稠密的 qwen3_5_text 主幹，具有 24 層、262,144 個 token 的上下文，且每個全注意力層搭配三層線性注意力。35B-A3B 是 256 個專家的稀疏模型，每個 token 路由至八個專家，維持相同的 262,144 個 token 上下文；其誕生是因為 OpenBMB 想要一個能從儲存裝置串流專家、而非將專家常駐於記憶體的大型模型。兩者皆為 Apache-2.0。權重於 2026 年 10 月 6 日與 7 日出現，模型卡隨後於 10 月 12 日發布，ModelBest 則於 10 月 15 日發布英文新聞稿。

所以誠實的說法不是「2B 對上 1B」，而是「一個什麼都得做的模型」對上「一個讓你按每個問題值得多少模型來選擇的家族」。如果你的 pipeline 每張影像只問一個問題，LFM3-VL-2B 這種形態更簡單，而且在小型端更強。如果你的 pipeline 要問一萬個便宜問題、再問一個昂貴問題，MiniCPM 這種形態從設計上就更便宜。

Liquid 自己的表格怎麼說，以及讀它要付出多少代價

這套 62 項基準測試套件是 Liquid 的，於 vLLM 0.27.1 上執行，已標準化至 0–100 量表；除標示為例外的列之外，每個模型都啟用推理模式。廠商對競爭對手進行基準測試很正常，也值得一讀，但測試框架是廠商的、提示集是廠商的、彙總結果也是廠商的。請把這些列視為主張。

• MMMU — LFM3-VL-2B 55.7 with thinking and 48.6 without, against 51.0 for MiniCPM-V 4.7 1B in the same column set. OpenBMB's own page reports no MMMU for the 1B, so this row exists only in Liquid's run.

• OCRBench v1 — LFM3-VL-2B 86.3 against 82.1 for MiniCPM-V 4.7 1B inside Liquid's table. OpenBMB reports 86.1 for its own 1B, which is a 4-point spread on the same named benchmark and a fair illustration of what a different harness does to a number.

• MathVista (mini) — 84.2 with thinking and 68.5 without for LFM3-VL-2B, against 71.2 for MiniCPM-V 4.7 1B in the same table. OpenBMB's page says 74.3 for that model.

• CharXiv reasoning — 70.2 for LFM3-VL-2B against 44.5 for MiniCPM-V 4.7 1B. OpenBMB's page claims 48.8 for the same model, so even the direction of the gap is harness-dependent.

• LongVideoBench — 53.4 for MiniCPM-V 4.7 1B on OpenBMB's page. Liquid's table carries no LongVideoBench row at all, so there is nothing to compare it with.

這個模式很一致：開啟推理時，2B dense 模型在多步視覺推理與圖表解讀上表現更好，在一般 OCR 上則大致持平。關閉推理時，差距縮小到約 4.6 分，這告訴你大部分優勢是靠測試時 token 換來的，而不是靠參數。這對延遲的影響比對品質的影響更大，而延遲正是這類比較通常忽略的軸線。

逆轉排名的獨立測試

十月底，WebBrain 發表了一項涵蓋 100 個案例的瀏覽器截圖基準測試，完全離線以 Q4_K_M GGUF 執行於兩張 RTX 5060 Ti 顯示卡上，採用凍結的截圖集、單一生產提示詞與確定性評分規則。MiniCPM-V 4.7 1B 在 100 個案例中取得 37 項嚴格通過，平均評分規則得分為 68.2%，每張截圖耗時 1.30 秒。LFM3-VLD-2B——Liquid 模型的同系變體，並非確切的 LFM3-VL-2B 檢查點——取得 4 項嚴格通過與 44.7% 的成績，每張截圖耗時 2.20 秒。

這個但書很重要，而且兩面都成立。在嚴格的編號標題正規表達式下，MiniCPM 的得分是零次通過，因為它把章節標題寫成文字標籤，而不是數字。37 次通過的數字，是依章節名稱重新評分同一批輸出所得的結果。這是真實的格式失敗；如果你的下游解析器預期編號標題，這就是不合格的。但內容分數則差得很遠：68.2 對 44.7，延遲為 60%，而且在一個任務上——讀取密集的瀏覽器視窗——這比圖表基準更接近實際生產環境。

這是這兩個模型在這一層級中唯一的一項獨立評估；它是在一對 GPU 上的一套測試框架，而它所測試的 Liquid 模型是 VLD 變體。它仍然比 62 項基準的彙總結果更有資訊價值，因為它衡量的是你實際使用小型視覺模型時會做的事：查看螢幕並快速回答一個固定問題。

許可證是無聲的決定者

MiniCPM-V 4.7 以 Apache-2.0 授權釋出，且沒有營收條件。LFM3-VL-2B 以 LFM Open License v1.0 授權釋出，Liquid 將其描述為年營收低於一千萬美元即可免費商用。超過此門檻後，條款就會改變，你需要自行詳閱。

對個人興趣專案來說，這個差異只是理論上的。對商業產品而言，這卻是律師首先會追問的事，也是任何比較表中唯一沒有任何基準測試能推翻的一列。一個在圖表推理上好上四點、卻附帶營收觸發條款的模型，不會自動成為更好的依賴項。這也是為什麼在 MiniCPM-V 4.7 的兩個尺寸版本上都選擇 Apache-2.0，會比基準測試數字發揮更大的作用：它省去了一場交涉。

Cadence：兩張表都未報告的數字

esp32-eye 貓咪監視器是 MiniCPM 1B 實際如何被使用的最清楚公開範例。它以 Q4_K_M GGUF 的形式在 MacBook 上透過 llama-server 執行，最多每 1.5 秒被呼叫一次，並由背景差異檢查把關，因此大多數影格根本不會送到它那裡。同一個版本發現 1B 無法可靠地區分四隻相似的貓，於是將身分辨識移到 35B，而不是推出猜測結果。

這正是基準測試表未能反映的部署設定。若模型每 1.5 秒就被呼叫一次，它必須小到能常駐、快到答案能在下一個影格前送達，且授權寬鬆到讓你能夠發布。1B 三者皆符合。LFM3-VL-2B 在 Q4 下為 1.25 GB，獨立測試中每張截圖耗時 2.2 秒；這對逐張影像的處理流程沒問題，但在同一硬體上作為 1.5 秒的閘門就太慢了。

如果你想要的是託管端點，而不是本機檔案，那麼目前 OrcaRouter 的目錄中兩款模型都沒有，所以老實說，1B 會跑在你部署它的地方，而 35B 則跑在 OpenBMB 自家的 API 上。路由器確實能提供的是周邊架構：一組金鑰通用於超過 200 款模型，對供應商牌價 0% 加成，以及自動容錯移轉；當昂貴的那一段是單一外部端點時，這就是讓雙模型管線保持運作的方法。它不會讓未託管的模型變成託管模型，而這點值得直說。

該選哪一個

如果你要建立單一模型的影像處理管線，並且想在兩家實驗室公布的基準測試中取得最強的 2B 級通用模型，LFM3-VL-2B 是站得住腳的選擇，但要把授權條款的注意事項寫下來。如果你要建立會在迴圈中持續檢視螢幕的代理程式，獨立瀏覽器測試顯示 MiniCPM 1B 在分數與延遲上都領先，而它的格式規範是你該在解析器裡修正、而不是在模型裡修正的地方。

如果你需要一個能讀取 262,144 個 token 的文件、觀看影片，並在 MMMU 上不落下風的模型，那麼這兩款小模型都不是答案：那屬於 35B-A3B 級別，OpenBMB 回報其在 MMMU 上為 80.2、在 OCRBench 上為 91.2、在 LongVideoBench 上為 68.9，全部都是廠商自行回報，且無一經過獨立重現。真正的決策不是哪個 2B 勝出，而是你的流程能否負擔得起經常以低成本問小問題、極少問難題——如果可以，雙模型設計會比任何試圖同時擅長兩者的單一模型更便宜。

最後一次校正。Liquid 公布的 13.9 分差距在 Liquid 的測試套件上確實存在，WebBrain 公布的 23.5 分差距在 WebBrain 的測試套件上也確實存在；兩者指向相反方向，因為它們衡量的是不同的任務。任何只引用其中一個而不提另一個的人，都是在向你推銷一個結論。有用的問題不是哪個模型更好；而是你一天需要問多少次，以及你願意為答案付多少錢。