LFM3-Omni-2B vs MiniCPM-V 4.7 1B：當較小模型讀得更好時

從紙面上看，這不是一場公平的較量。LFM3-Omni-2B擁有 21.7 億個參數；MiniCPM-V 4.7 1B則以 1B 模型的名義行銷。理論上，較大的模型應該在視覺基準測試中勝出。但事實並非如此。MiniCPM 在 OCRBench 上拿下 86.1，對手為 80.6；在 MMStar 上為 69.5，對手為 55.67；在 MMMU 上為 56.9，對手為 42.44；在 MathVista 上為 74.3，對手為 62.5。兩張規格卡共有的每一項視覺基準測試，都由名稱較小的模型勝出，而且通常差距懸殊；此外，MiniCPM 的上下文視窗還是對手的八倍。每次呼叫的融合成本都高於路由至單一模型。其計費依供應商定價計算，不額外加價。

有三件事可以解釋這點，而它們都不是任一模型的缺陷。MiniCPM-V 4.7 1B 是專才，把全部參數預算都花在視覺上。LFM3-Omni-2B 是通才，把預算花在視覺、聽覺和說話上。而最重要的 MiniCPM 數字——OCRBench 上的 86.1——是在其 4× 視覺 token 設定下測得的；這種設定以運算換取細節，是每張圖片 2,048 個 token 上限所做不到的。理解這項取捨就是整個決策。

為什麼較小的模型讀起來更好

MiniCPM-V 4.7 1B 圍繞著一個核心概念打造：提早壓縮視覺 token，並讓使用者自行選擇壓縮的激進程度。模型在視覺編碼器內部就套用 4× 或 16× 的 token 壓縮，在語言模型看到任何內容之前便已完成。在 16× 下，它成本低、速度快，適合圖說生成與場景描述。在 4× 下，它保留四倍之多的 token，而這正是文件 OCR 與密集圖表判讀所需要的。OpenBMB 公布的主要數據皆以 4× 設定呈現。

LFM3-Omni-2B 採取相反的做法。它以原生解析度處理影像，但將每張影像的視覺預算上限設為 2,048 個 token，而這個上限與 2.17B 稠密網路內的音訊編碼器、視訊路徑和語音解碼器共用。對於必須與另外三種模態一起塞進手機的模型來說，2,048 個 token 的上限是合理的選擇。這也對能有多少頁面細節傳到語言模型設下硬性上限，而 DocVQA 92.47 顯示該模型從中榨出很多效能——但 OCRBench 80.6 表示，這仍不足以擊敗能在同一頁面上花費 4 倍 token 的專門模型。

還有第二個、較不顯眼的因素。MiniCPM 的上下文視窗是 262,144 個 token。LFM3-Omni-2B 則是 32,768 個。對單一截圖而言，兩者都無關緊要。但對於一份 40 頁的 PDF、一段長影片，或多輪文件對話來說，差異不在於基準測試表上的某一列——而在於這項任務究竟是否可能完成。

規格，不帶行銷修飾

在做任何比較之前，有一個數字需要更正。MiniCPM-V 4.7 1B 被稱為 1B 模型，而其稠密參數量約為 13 億到 15.5 億，取決於你怎麼計算視覺塔。Hugging Face 的側邊欄將其四捨五入為「2B params」，這就是為什麼一個 1B 模型會在目錄裡看起來像 2B 模型。檔案大小才是誠實的指標：BF16 下約 3.1 GB，而 LFM3-Omni-2B 為 4.3 GB。

• 參數量 — LFM3-Omni-2B 為 2.17B 稠密參數，而 MiniCPM-V 4.7 1B 則約為 1.3B 至 1.55B 稠密參數。

• 輸入 — 文字、圖像、含音訊的影片、16 kHz 音訊與文字、圖像、多圖像及影片的比較。

• 輸出 — 文字與 24 kHz 語音，對比僅文字。

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

• 視覺 Token — 每張圖片上限為 2,048 個，而編碼器內部可切換 4× 或 16× 壓縮。

• 授權條款 — LFM 開放授權條款 v1.0 與 Apache-2.0 的比較。

• 發佈 — 2026年10月27日 對比 2026年10月12日。

• 記憶體佔用 — BF16 約 4.3 GB，相較於 BF16 約 3.1 GB；提供服務時約需 5 GB VRAM。

兩張卡片共有的每一列

這份跨實驗室的比較表格外乾淨，因為兩家廠商報告的是同樣四個視覺資料集，而且兩者都是在指令模式下評估的非推理模型。這仍然只是兩份廠商評估，且兩者都尚未被獨立重現。

• OCRBench — LFM3-Omni-2B 為 80.6（1,000 題中 806 題），相較 MiniCPM-V 4.7 1B 的 86.1。在文件文字辨識上相差 5.5 分。

• MMStar — 55.67 對 69.5。13.8 分的差距，是整組中最大的。

• MMMU 驗證 — 42.44 對 56.9。在大學程度的多模態推理上相差 14.5 個百分點。

• MathVista mini — 62.50 對 74.3。在視覺數學上相差 11.8 分。

四列、四次落敗，差距介於五到十五分之間。沒有任何一列是全模態模型獲勝，這比 LFM3 對 LFM2.5 的比較所產生的結果更乾淨，也更難自圓其說。最站得住腳的解讀是：一個具備 256K 上下文與 4× token 預算的 1.4B 專才模型，就是比一個具備 32K 上下文與 2,048-token 圖像上限的 2.17B 通才模型是更好的讀取者。在這個規模下，把容量投入單一模態，勝過把容量分散到四種模態。

有兩點但書必須一併說明，因為兩張模型卡都沒有主動提及。MiniCPM 的 86.1 是在 4× 壓縮下測得，而同一個模型在預設 16× 設定下分數會較低、執行成本也更低——模型卡並未公布那個數字。而 OpenBMB 的模型卡完全沒有基準測試表；這些數字以文字敘述和圖表圖片的形式出現在產品頁面上，這比附有方法說明註記的表格是更弱的公布形式。兩組數字都是廠商說法。差距的方向足夠一致，因此大概能經得起獨立測試；但確切幅度大概不能。

Context 是決定實際工作負載的那一列

32K 上下文對單一圖像來說很寬裕，但對文件而言則顯得侷促。以每張圖像約 2,048 個視覺 token 計算，LFM3-Omni-2B 的視窗大約能容納十幾張完整圖像，之後對話歷史才會開始爭奪空間。MiniCPM-V 4.7 1B 的 262,144 個 token 並非小幅提升；而是截然不同量級的工作負載。長篇 PDF、多頁表單、長達一小時的影片摘要，以及會在工作上下文中保留螢幕截圖的代理迴圈，在 256K 下全都可行，在 32K 下則全都受限。

這是兩個模型之間最少被討論、卻影響最深遠的差異。基準測試的分數表獎勵的是單張影像的準確度；但正式環境的文件處理流程，卻往往在第十四頁出錯。如果你的使用情境是每次對話要處理超過少數幾張影像，那麼 32K 視窗會是比上述四項基準差距更難跨越的限制。

MiniCPM 無法做到的事

它聽不見。它沒有音訊輸入路徑、沒有語音輸出，也沒有影片音軌處理能力。如果應用情境是一個人對著裝置談論相機所見的內容，MiniCPM-V 4.7 1B 只是整條管線中的一個元件，至少還需要另外兩個模型——ASR 系統與 TTS 系統——再加上在它們之間傳遞文字的黏合層。

LFM3-Omni-2B 將那條管線壓縮成單一 4.3 GB 檢查點。與專用語音模型相比，它的音訊分數並不突出——英語 ASR 字錯誤率 6.36、VoiceBench 64.73——但它們存在於與視覺路徑相同的前向傳遞中，這表示模型能回答關於影像的口頭提問，而無需先寫出任何轉錄稿。對免持的現場工具或自助服務機台而言，這就是關鍵特色。對文件管線而言，它則是參數預算裡的無用負擔。

OrcaRouter 的 模型融合是取得這兩種行為的另一種方式：一個面板，讓文件專家與全能模型回答同一個提示，並由兩者的回應組合而成。這是一項產品能力，而不是對這兩個檢查點的說法——目前兩者都不在我們的目錄中——但它是對這種對決的架構性解答：每個模型明顯更擅長工作的不同一半。融合每次呼叫的成本高於路由至單一模型，而唯有當錯誤答案的代價高於 token 成本時，它才值得。

決定

如果工作內容是讀取——OCR、發票、表單、圖表、螢幕截圖、長篇 PDF、密集的 UI——MiniCPM-V 4.7 1B 在所有已公布的衡量指標上都是更好的模型，它的上下文長度是八倍，授權是 Apache-2.0，而非附有營收門檻的客製授權，而且它在磁碟上的占用更小。這不是差距很小的抉擇，而它被稱為 1B 模型這件事不應掩蓋這一點。

如果這項工作是與一台配備相機和麥克風的裝置進行對話，那麼在兩者之中，只有 LFM3-Omni-2B 能夠參與。它的閱讀能力較差、能容納的上下文較少，而且以更嚴格的條款發布，但如果替代方案需要三個模型和一條管線，這些都無關緊要。

值得命名的第三種情況是：產品同時需要兩者，而文件路徑與語音路徑是各自獨立的功能。那麼正確的架構不是一個模型，而是兩個，並依請求類型路由——文件用 reader，語音用 omni 模型——而唯一的問題是你想同時運行兩者，還是讓單一端點來決定。這正是這批比較不斷回到的問題，而它是對的問題。這些模型在資源佔用上足夠接近，同時運行兩者是切實可行的選項；它們在能力上差距夠大，因此無論你選哪一個，只運行一個都是一種妥協。

真正可能改變結論的，是對這兩個模型之一的獨立評測，尤其是針對 MiniCPM 在其預設 16× 壓縮下進行的測試，而非其頭條數據所採用的 4× 設定。單是這一個數字，就可能彌合大部分的差距——也可能讓差距進一步擴大。在有人發表這樣的結果之前，我們手上只有廠商提供的表格，而它們全都指向同一個方向。