LFM3-Omni-2B 對決 MiniCPM-V 4.7 35B-A3B：新秀與現任霸主

兩個數字，兩者都為真，但若把它們當成定論來解讀，兩者都會誤導人：MiniCPM-V 4.7 35B-A3B已被下載約 289,000 次，而LFM3-Omni-2B已被下載 83 次。這個差距看起來像是一場碾壓。實際上，這是時間表的問題。OpenBMB 的權重於 2026 年 10 月 6 日上線；Liquid AI 的權重於 10 月 21 日上線，並於 10 月 27 日公布，也就是在讀取這些數字的前一天。一個只存在一週的模型不可能有下載紀錄，而一個擁有六週先發優勢、且已有 MiniCPM 追隨者基礎的模型，無論是否值得，都會有下載紀錄。

所以有意思的比較不在於受歡迎程度，而在於一支為裝置挑選小型多模態模型的團隊真正該權衡的事：它是否需要聽覺能力、是否需要以六種方式量化，以及哪一種授權在產品開始有營收時仍然令人安心。

每個模型是什麼

MiniCPM-V 4.7 35B-A3B 是 OpenBMB 首個混合專家視覺語言模型：儲存參數達 352 億，每個 token 從 256 個專家中路由 8 個，約有 30 億活躍參數；文字堆疊共 40 層，前面有一個隱藏大小為 1,152 的 27 層視覺塔，該視覺塔會在第 6 層插入文字堆疊。它能讀取圖像、多圖集合、影片與文字，並以文字回答。在 70.4 GB 的權重中，完全沒有音訊路徑。這張模型卡的主打宣稱不是準確率，而是可行性：在 iPhone 17 Pro Max 上使用約 3 GB 記憶體，就能達到每秒超過 13 個 token；這歸功於 Lookahead Expert Scheduling 技巧，它能預測下一層的專家，並在當前層運算時預取這些專家。

LFM3-Omni-2B 是 Liquid AI 在 LFM3 系列中的全模態入門型號：以 LFM3-1.7B 為主幹，具備 21.7 億個稠密參數，並由 LFM3 視覺編碼器與 LFM3 因果音訊編碼器饋入同一個 128,000 詞元的詞彙表。它能讀取文字、圖像、有聲或無聲影片，以及 16 kHz 音訊，並輸出文字或 24 kHz 語音，包括在單一回應中交錯呈現文字與語音。它在設計上屬於非推理模型——模型卡指出不支援 enable_thinking=True——並定位於手機、筆記型電腦與邊緣硬體。

兩者都能在手機上使用。只有一款是專為此而設計的。

很容易把這兩者都歸入「裝置上的小型模型」然後就此打住。但底層的工程恰恰相反。

OpenBMB 的問題在於手機上的記憶體頻寬，因此模型採用稀疏設計，以減少每個 token 需要讀取的資料量：儲存 35.2B，實際只觸及 3B。Lookahead Expert Scheduling 正是關鍵線索——唯有瓶頸在於搬移權重、而非權重相乘時，才會打造專家預取。LFM3-Omni-2B 則靠真正的小來解決同一個問題：2.17B 稠密模型，完全沒有路由，全部以 16 位元表示，仍只佔幾 GB。

這項取捨會在量化上顯現。MiniCPM-V 4.7 提供 GGUF、AWQ、GPTQ、FP8、INT4 與 BitsAndBytes 版本，另有供推測性解碼使用的 DSpark 草稿檢查點——無論你最終落在哪種加速器上，都有完整選項。LFM3-Omni-2B 在 Hugging Face 上有 BF16 權重，且已有流通中的 Ollama 版本，而該 Ollama 條目標示 125K 上下文，對比模型卡中的 32K。這是封裝錯誤還是未記載的能力，截至撰寫時仍未釐清。若你需要跑在 Rockchip NPU 或 Intel 筆電上，具備六種量化格式的廠商在第一天是較穩妥的選擇。

決定大多數部署的那一行

MiniCPM-V 4.7 35B-A3B 聽不見。沒有音訊塔、沒有 ASR 路徑、沒有語音頭。LFM3-Omni-2B 能聽見，也能開口回答，支援 19 種語音語系與 16 種文字語言。

對於文件、圖表、截圖或影片影格的工作負載，那個差異無關緊要，而 MiniCPM 在幾乎其他每個面向都是更強的選擇——規模更大、經過更廣泛測試、工具更完善。對於任何涉及麥克風的環節，這立刻結束了比較。你無法在不加入獨立 ASR 模型、再接入 TTS 模型的情況下，直接把聽覺能力加到 MiniCPM-V 4.7 上；到了那個地步，你是在執行三個模型，來做一個 2.17B 檢查點原生就能完成的事。

反之亦然。{{1}}LFM3-Omni-2B 能讀取影像，但它是個 2.17B 模型在讀取這些影像：其模型卡報告 OCRBench 806、DocVQA 92.47 與 MMMU 42.44，而 MMMU-Pro 則低至 27.28。{{/1}}以這個規模來說，這些數字還算體面，但在困難的文件版面配置上，無法與 35B 模型競爭。如果任務是密集表格與掃描表單，較大的模型在這項任務上就會勝出，甚至在考慮到讓它執行起來成本低廉的 8-of-256 路由之前就已如此。

數字耗盡之處

令人不安的部分在這裡：目前沒有誠實的正面對決表格可用，因為 OpenBMB 是以圖表圖片而非數值表格來公布 MiniCPM-V 4.7 的結果。35B-A3B 的資料卡上沒有 MMStar、MMMU 或 OCRBench 的數字可引用。任何在該欄位填入數字的內容，不是來自 1B 的同系列模型——那是架構不同的另一款模型——就是憑空捏造。

相較之下，LFM3-Omni-2B 的模型卡則是一張完整表格：MMStar 55.67、MMMU 42.44、MMMU-Pro 27.28、MMBench 73.68、SEEDBench 75.07、RealWorldQA 66.54、MathVista 62.50、POPE 89.34、DocVQA 92.47、InfoVQA 64.08、OCRBench 806、MVBench 58.03、Video-MME 57.70，另有一欄語音數據，從英文 ASR 的 6.36 詞錯誤率到 TTS 的 UTMOSv2 3.80。以上全部由 Liquid AI 測量，每個受比較的模型都採用其自身的聊天模板與貪婪解碼，且沒有任何一項經過重現。

廠商提供的表格比廠商提供的圖表好，但這和獨立評測不是同一回事。兩個模型都沒有獨立評測。這就是目前整個 small-omni 類別的現況，也正是為什麼部署限制最後會比 MMMU 的一分更重要。

授權條款，原型出貨前請先閱讀

MiniCPM-V 4.7 採用 Apache 2.0。沒有營收門檻、沒有使用領域條款、無需協商。LFM3-Omni-2B 採用 LFM Open License v1.0，這是 Liquid 套用於整個 LFM3 的營收門檻型授權。對興趣專案或早期新創公司而言，兩者在實務上等價。對已超過門檻的公司而言，其中一個需要與律師討論，另一個則不需要——而現在進行那場討論，遠比模型已進入產品後才談便宜得多。

這是這項比較中最不光彩的一個軸線，也是最有可能在實際公司裡決定勝負的一項。

這兩者如何融入同一個架構

對大多數團隊來說，實際可行的答案並不是「只選一個」。而是常見情況用裝置端模型，裝置模型處理失誤的請求則交給託管模型。讓後半部保持可攜，才是裝置模型更換後仍能存續的部分：OrcaRouter 以供應商定價 0% 加價，提供橫跨 200+ 個託管模型的單一 API、供應商中斷時的自動容錯移轉，以及無須改程式碼就能把請求轉到不同模型的路由 DSL。LFM3-Omni-2B 和 MiniCPM-V 4.7 都不在該目錄中——兩者都是權重下載，本文也不是在暗示相反。重點是備援層不應每次裝置層改變就重建，而裝置層每隔幾週仍在變動，它勢必會改變。

哪一個要放到裝置上

如果你需要視覺品質、真正可部署的量化格式、Apache 2.0，以及背後已有六週實地報告的生態系，就選擇 MiniCPM-V 4.7 35B-A3B。它的下載次數不是品質訊號，但伴隨 289,000 次下載而來的錯誤回報，是 LFM3-Omni-2B 目前還沒有的某種測試。

如果產品需要語音功能、裝置記憶體受限到連 3 GB 的活躍權重都仍嫌太多，或你想要單一檢查點而不是 ASR-plus-LLM-plus-TTS 堆疊，就選擇 LFM3-Omni-2B。接受較小模型的視覺評分、營收門檻授權條款，以及你是在模型發布僅一天後就成為早期採用者這件事。

能定案的做法是一次獨立測試——相同的測試框架、兩個模型、OCRBench 與 MMMU，以及一項語音任務。還沒有人做過。在有人做到之前，誠實的排名是：MiniCPM 擅長視覺，LFM3-Omni 擅長語音，其餘一切則交給試算表。