MiniCPM-V 4.7 1B 對決 LFM2.5-VL 3B：OpenBMB 宣稱其 1B 模型勝過 3B 模型。這項說法掩蓋了什麼

MiniCPM-V 4.7 1B 與 LFM2.5-VL 3B 都是為手機和小型電腦打造的開放權重視覺語言模型，兩者在時間上相隔不到三週。MiniCPM-V 4.7 1B 由 OpenBMB 於 2026 年 10 月 6 日上傳，並在廠商發布說明中標註為 10 月 12 日。LFM2.5-VL 3B 由 Liquid AI 於 2026 年 8 月 11 日發布。一款是 15.5 億參數，採 Apache 2.0。另一款是 31.2 億參數，依 LFM Open License v1.0 授權。而 OpenBMB 自家產品頁面提出一項主張，應該讓任何只憑規模選購的人停下腳步：其 1B 模型超越 LFM2.5-VL 3B。像這類發布背後有紀錄的 AI 失效與 AI 代理事件，都彙集在 OrcaRouter AI Incident Archive其中每筆紀錄都附有自己的來源、嚴重程度、信心等級與爭議標記。

那句話承擔了很重的分量。而且，就任何人所能查證的範圍而言，數字也並未與之相牴觸——這反倒比它真被推翻來得更有意思。本文逐一檢視各家廠商實際公布了什麼、哪些地方的比較是真材實料，以及這項說法在兩處悄悄轉移了焦點的地方。

這項主張，以廠商自己的話來說

OpenBMB 的 1B 頁面寫道，該模型「是對 MiniCPM-V 4.6-1.3B 的全面升級，並超越 Qwen3.5-0.8B 與 LFM2.5-VL-3B，在 OCR、圖表推理與影片理解方面領先同尺寸級別」。關鍵在於「領先同尺寸級別」這個子句。與 LFM2.5-VL 3B 的比較被拿來當作能力密度的證據；但緊隨其後的句子，卻把這項主張限制在 LFM 並不屬於的尺寸級別。

Liquid AI 的模型卡並沒有投桃報李。它完全沒有提到 MiniCPM，並將其模型與 G​emma4 E2B 與 E4B、InternVL 3.5 2B 與 4B，以及 Qwen3.5-2B 與 4B 進行基準比較。因此，這是一場單方面的比較：一方廠商拿自己與另一方對比，而另一方從未承認這場對壘。在閱讀任何正面交鋒的比較（包括本文）之前，首先要知道的就是這種不對稱。

各供應商記錄在案的內容

Liquid AI 發布了一張數值表。LFM2.5-VL-3B 回報 MathVista 68.5、MMMU Pro 30.5、ChartQA 81.3 與 OCRBenchv2 47.5（僅英文子集），並列出同系列另一個模型在同一列上的分數。那些是廠商數據，由廠商自行執行，沒有獨立第三方必須認同它們——但它們是可證偽的，而這正是它們有用的原因。如果你在 MathVista 上重現出 55，你就知道你的設定中有某個地方不同。

OpenBMB 以文字段落發布數值摘要，並在其下方提供完整圖表。針對 1B，頁面標示 OCRBench 86.1、MathVista 74.3、CharXiv Reasoning 48.8、LongVideoBench 53.4 與 MotionBench 54.55，並將其餘比較以含有 4× 與 16× 欄位的圖片呈現。模型卡本身完全沒有基準測試表格。

比較兩者在雙方都提及的那一項基準測試。MathVista：MiniCPM-V 4.7 1B 為 74.3，LFM2.5-VL 3B 為 68.5。根據廠商自己的報告，1B 領先 5.8 分。在 OCR 方面，兩者使用不同的工具——OCRBench 對上 OCRBenchv2 的英文子集——數字無法直接比較，而這正是「超越」這類說法會略過的細節。

在進行對等比較的情況下

• 參數 — 1.55B 稠密、BF16、磁碟上 3.1 GB，對比 3.12B 稠密、BF16；LFM 大約是該模型的兩倍

• 視覺編碼器 — SigLIP2 風格主幹，27 層、1152 隱藏維度、980 像素圖塊，對比 SigLIP2 NaFlex 400M、512×512 不重疊區塊加上調整尺寸後的縮圖

• 文字主幹 — 衍生自 Qwen3.5 的設定，具備 24 層、1024 隱藏維度，相較於 LFM2.5-2.6B 採用 3:1 的線性對全注意力模式，以及由 Liquid AI 自行設計的混合架構

• 上下文 — 262,144 個 token 對比 32,768 個 token

• 視覺 token 預算 — 每次請求可切換 4× 或 16× 壓縮，相較於依解析度設定的固定 NaFlex patch 預算

• 授權條款 — Apache 2.0 與 LFM Open License v1.0，後者帶有商業條款，而非單純的寬鬆授權

• 指明的語言——卡片範例中的英文與中文，對比明確列出的 16 種語言（從阿拉伯文到越南文）

• 已發表評估——五個以文字敘述的數字，加上僅以圖表呈現的比較，對照數值表格，涵蓋四項基準測試與六個同系列模型

• 獨立評估 — 截至本文撰寫時，兩者皆無 Artificial Analysis 條目 vs 兩者也都沒有 Artificial Analysis 條目

• 廠商公布的速度 — 1B 在任何裝置上皆未提供每秒 token 數，對比 Apple M5 Max 的 228 tok/s、AMD Ryzen AI Max+ 395 的 116 tok/s、Galaxy S26 Ultra 的 20 tok/s

• 記憶體 — BF16 約 3.1 GB；Q4 GGUF 為 0.67 GB，外加 0.90–1.11 GB 的視覺投影器，相較於官方公布的 3.3 GB 以下，並提供 GGUF、ONNX 與 MLX 版本

• 具名的服務路徑 — Transformers、SGLang、vLLM、llama.cpp、Ollama、OpenVINO、DSpark 推測解碼 對比 Transformers、vLLM、SGLang、llama.cpp，以及 GGUF、ONNX 與 MLX 匯出

• 裝置端故事 — iOS、Android、HarmonyOS 應用程式，以及 Rockchip、Houmo、Intel、AMD 與 Arm 的首日支援，並以 iPhone 17 Pro Max 對比 Galaxy S26 Ultra 的解碼數據，以及為 Apple Silicon 打造的 MLX 版本加以展示

有兩列值得再細看。上下文視窗是 MiniCPM 佔優的八倍差距，而這種數字看似決定性，直到你想起：一個持有 262k 個 token 的 1B 模型，其 KV 快取比自身權重還大。實務上，在手機上，這兩個模型都不會跑到接近各自上限的地方。而授權條款那一列，比任何基準測試更常決定商業採用：Apache 2.0 不需要跟律師談，LFM Open License 則需要。

該主張轉移話題所針對的部分

OpenBMB 拿自家模型與規模是其兩倍的競爭對手比較，用的是它自己挑選的基準測試，並以文字敘述結果。這並非不誠實——數字已公開，比較方式也講明了。但它回答的是一個實際部署模型的人根本不會問的問題。沒有人會在 1B 和 3B 之間做選擇，是因為希望較小那個更好。他們會選，是因為其中一個能裝進他們的裝置而另一個不行，或因為其中一個具備他們所需的語言涵蓋範圍，或因為其中一個的許可證能通過法務審查。

針對其中第一點，誠實的解讀是兩者都適合。LFM2.5-VL-3B 的模型卡宣稱低於 3.3 GB，並展示在 Galaxy S26 Ultra 上每秒 20 個 token。MiniCPM-V 4.7 1B 在 Q4 搭配其投影器時約落在 1.8 GB。因此，1B 的真正優勢不是「它能在手機上執行，而另一款不行」——而是餘裕：少了約 1.5 GB 記憶體，這在中階 Android 裝置上，就是應用程式能存活下來、還是被系統殺掉的差別。

在第二點上，比較結果正好相反。LFM2.5-VL-3B 在其模型卡中列出 16 種語言，並且除了 GGUF 之外，還提供 ONNX 與 MLX 版本。MiniCPM-V 4.7 1B 的文件以英文和中文範例為主，而其裝置端方案著重於 iOS、Android 和 HarmonyOS 的晶片支援，而非語言涵蓋範圍。如果你的產品以土耳其語、波蘭語或越南語推出，那麼較大、授權條款較嚴格的模型，才是公開宣稱支援你的那一個。

第三點上，Apache 2.0 直接勝出，沒有太多可討論的。

各自真正更擅長的地方

LFM2.5-VL-3B 是圍繞一組特定工作打造，其模型卡也如此說明：單輪、高吞吐量、低延遲的工作，例如汽車場景中的近即時物件偵測、掃描文件含版面標註的批次 OCR，以及菜單與路標的裝置端翻譯。模型卡也說明了模型不適合哪些用途——長上下文與推理密集型任務、視覺網頁設計、關於藍圖的技術問題。這種負面指引很罕見，而且比正面宣稱更值得信任。

MiniCPM-V 4.7 1B 的核心，是在尺寸範圍底端實現能力密度。混合式 4×/16× token 壓縮是最清楚的體現：同一個檢查點既能服務於詳細的文件閱讀，也能用於低成本的縮圖處理，並可按每次請求選擇。切片控制（影像 36 個切片、影片 1 個）、影片的影格取樣參數，以及各自獨立的 PDF 解析與 grounding 食譜條目，全都指向文件與螢幕工作負載，而非偵測工作負載。它還以獨立的 213M 參數成品形式提供 DSpark 推測解碼頭；若你的執行環境支援，這就是實實在在的吞吐量槓桿，若不支援，則是完全無用的負擔。

實際的分野在於：如果你要在攝影機串流中偵測物件，或是以每秒 20 幀的速度翻譯招牌文字，那麼 LFM 的延遲數據與語言覆蓋範圍就是理由。如果你要把螢幕截圖、收據和頁面影像轉成結構化文字，而且 token 預算由你掌控，那麼 MiniCPM 的壓縮開關就是理由。

買方應計入價格的落差

LFM2.5-VL-3B 自 2026 年 8 月 11 日推出至今——撰寫本文時已過了十週——就開放權重而言，這時間已足夠讓量化生態系穩定下來。GGUF、ONNX 與 MLX 版本皆由廠商本身提供。你可能會用到的任何執行環境都有可運作的路徑。

MiniCPM-V 4.7 1B 問世才三週，而其模型卡一開頭就提醒：CUDA 版本不相容會導致透過 torchcodec 進行的影片解碼失效，並記載了兩種因應做法。其架構是新的——一個月前還不存在的 model_type——且最低 Transformers 版本為 5.18.0。這些都不是缺陷。這是採用首月模型所須支付的標準代價，也是為什麼一個低調發布、以圖表進行評估的版本，適合做並排比較測試，卻會讓人質疑是否適合在第一週就作為正式生產路徑。

執行那項測試的便宜做法，是在評估新進模型時讓現任模型繼續提供服務；這是路由問題，而不是建模問題。OrcaRouter 運行超過 200 個託管模型，將它們置於單一 OpenAI 相容端點之後，且加成 0%，將各供應商的標價原樣傳遞，因此供應商降價會在同一天反映在你的帳單上，而不是等到重新定價週期之後。其路由 DSL 可在單次呼叫中容納主要模型與備援模型，而自動容錯移轉可在供應商狀況不佳時讓路徑保持運作——當試用中的模型是 1B 本機檢查點，而生產中的模型是你付費使用的模型時，這正是你想要的。本文中的兩個模型都不在該目錄中：兩者都是你自己執行的檢查點，而路由器圍繞著它們運作，而不是提供呼叫它們的方式。

索賠已了結

MiniCPM-V 4.7 1B 是否勝過 LFM2.5-VL 3B？在 MathVista 上，依兩家廠商各自回報的結果，領先 5.8 分。在 OCR 上，兩者公布了不同的評測工具，因此無法進行比較。在圖表推理與影片理解上，OpenBMB 宣稱獲勝並以圖表形式公布，而 Liquid AI 從未回應。唯一完全可查證的比較支持這項說法；其餘則是廠商以不利於引用的格式替自己的作業打分。

這套說法一旦被解讀成「較小的模型就是比較好」，便站不住腳。LFM2.5-VL-3B 提供十六種語言、匯出的 ONNX 與 MLX 版本、在實際出貨的 Android 手機上經记录的實測速度數據，以及一張告訴你哪些場合不該使用它的說明卡。MiniCPM-V 4.7 1B 則提供可切換的 token 預算、262k 的上下文視窗、Apache 2.0 授權，以及約 1.8 GB 的量化記憶體佔用。這些是截然不同的產品，卻被塞進同一列 benchmark 數據裡；正確答案取決於上述哪一份清單符合你的部署需求——而不是哪個數字比較大。

用你自己的影像、以你自己的量化設定，把兩者都測試一遍。權重免費，唯一成本就是一個下午。