LFM3-1.7B 對決 MiniCPM5-2B：實測 Liquid 的 23 比 4 計分板

2026 年 10 月 27 日，Liquid AI 發布了一張有 27 行的基準測試表，讓 LFM3-1.7B 對上 MiniCPM5-2B。Liquid 的模型在其中的 23 行勝出，MiniCPM5 贏了四行。這個數字很快流傳開來，而這是個問題，因為在一張由單一廠商挑選基準、撰寫測試工具並執行兩個模型的表格中，勝場數是你所能從中得出的最不具資訊價值的東西。本文要檢驗的是，那個 23–4 到底能告訴你什麼——而這要從一項坦白說起：Liquid 正默默回應的那篇比較，早一天發表於本部落格，而該文並未提出這個確切論點。那篇文章比較了兩個基礎檢查點，並斷定兩者都沒有可用的評估。以下是雙方都採用後訓練權重的版本。

{{1}}MiniCPM5-2B{{/1}} 是 OpenBMB 的 2.52B 稠密推理模型，於 2026 年 9 月初以 Apache 2.0 授權發布。{{2}}LFM3-1.7B{{/2}} 是 Liquid AI 的 1.73B 文字與代理模型，於 2026 年 10 月 27 日以 LFM Open License v1.0 釋出。兩者屬於同一重量級別，競逐同樣的裝置端位置，卻是為明顯不同的任務而打造。

兩家廠商，兩套測試框架，一張表

23–4 這個計數之所以存在，只是因為 Liquid 重新跑了它的競爭對手。對一場產品發布而言，這是正當且異常嚴謹的做法——大多數廠商只拿公開排行榜上的數字來比較，卻不說明背後的評測框架。但在自家測試框架上重跑競爭對手，並不會產生中立的結果；而破綻就在兩家廠商卡上都出現同一項基準測試的那幾行。

以 BFCL V4 為例。Liquid 測得 MiniCPM5-2B 為 62.65。OpenBMB 自家的模型卡則回報 66.6。以 Humanity's Last Exam 為例：Liquid 讓 MiniCPM5 得到 8.20，OpenBMB 則宣稱 8.9。這些差距很小——在 0–100 的量表上都在四分以內——這表示在標準化基準上，測試框架的差異不大。現在看 SWE-bench Verified：OpenBMB 回報 MiniCPM5-2B 為 46.4，Liquid 回報 LFM3-1.7B 為 43.40。把這兩個數字並排一看，MiniCPM5 勝出。把 Liquid 自家的 MiniCPM5 那一列放在 Liquid 自家的 LFM3 那一列旁邊，LFM3 勝出。同一個基準、同樣兩個模型，答案卻相反，因為這些數字來自不同的測試框架。

這一個例子就道盡了整個問題。兩家廠商都沒有公布測試框架設定、重試策略或提示詞支架。除非有人讓這兩個模型跑在同一個他們無法控制的測試框架裡，否則這份比較中的每一列跨廠商數據，都只是把擲硬幣包裝成量測結果。

當差距過大，不可能是線束雜訊所致時

有些資料列無法用解釋帶過。代理式網頁導覽是最清楚的例子：

• WebArena-Verified — 在 Liquid 的測試框架上，LFM3-1.7B 為 38.42，對比 MiniCPM5-2B 的 9.11。

• AutomationBench — 41.29 對 4.71。

• RULER 128K — 65.56 對 37.96。

• BFCL V4 — 71.39 對 62.65。

四分差距只是輔助支架。WebArena-Verified 上的二十九分差距，或 AutomationBench 上的三十七分差距，則不是。這些差異在於模型究竟能不能把多步驟計畫整合維持住，而這也與各家廠商對自身的說法相符：Liquid 圍繞帶有工具呼叫軌跡的代理式中期訓練打造 LFM3，而 OpenBMB 自家文件則指出 MiniCPM5 在長多步驟任務上較弱，且容易重複。兩份對同一弱點的獨立描述，從相反方向得出，是這整份比較中最強的證據。

{{1}}長上下文那一列{{/1}}值得特別關注，因為它正是人們會誤讀的一項。MiniCPM5 在 RULER 128K 的 37.96 是 128K 長度下的檢索分數，並不表示該模型的上限只到 128K——MiniCPM5-2B 官方支援 131,072 個 token。它的意思是，在那個長度下，MiniCPM5 能找到你要它找的內容較少。LFM3 在相同長度下得分為 65.56。如果你的工作負載是「搜尋長文件並回答」，那麼這個差距就是整個決策的關鍵。

MiniCPM5 勝出的四列——以及它們為何重要

Liquid 的表格讓 MiniCPM5-2B 拿下四項勝利：τ³-bench 以 69.44 勝過 68.01、GPQA Diamond 以 65.15 勝過 63.37、HLE 以 8.20 勝過 7.17，以及 AA-Omniscience 以 9.13 勝過 7.07。四項中有三項是知識基準測試。差距為一到兩分，落在大多數評測套件的雜訊底噪之內。

但這個模式與 MiniCPM5 的設計一致。OpenBMB 將它訓練成具備明確思考模式的推理模型，訓練流程是先對 4,000 億個 token 進行深度思考 SFT，接著由專家教師進行強化學習，最後再透過同策略蒸餾（on-policy distillation）整合成單一稠密檢查點。這套配方旨在讓每個參數從已儲存的知識中榨出更多價值。LFM3 的訓練則著眼於工具呼叫與指令遵循。GPQA Diamond 上 MiniCPM5 以 1.8 分勝出，並不令人意外；這正是兩種訓練哲學在預期之處展現出來。

真正更有意思的比較，是 Liquid 的表格無法做出的那一種。MiniCPM5-2B 的 Artificial Analysis 智慧指數為 12。截至 2026 年 10 月 28 日，LFM3-1.7B 完全沒有 Artificial Analysis 條目——沒有指數、沒有獨立測得的速度，也沒有中立的延遲數據。因此，在 27 列中輸掉 23 列的模型，才是擁有獨立資料點的那一個；而贏得這些列的模型，卻是要求人們憑信任接受的那一個。這種不對稱的重要性，應該高於勝出列數。

真正能清楚比較的規格

在兩家供應商都沒有執行對方基準測試的情況下，這些數字既乏味又可靠：

• 參數 — LFM3-1.7B 1.73B 稠密模型 對比 MiniCPM5-2B 總計 2.52B，非嵌入參數 1.98B。

• 層 — 24 層混合式（13 層卷積、5 層滑動視窗、6 層全域）對比 42 層標準 Transformer 層，採用分組查詢注意力，具有 16 個查詢頭與 2 個 KV 頭。

• 上下文 — 256K 對 131,072。

• 128K 下的 KV 快取 — 1.6 GB 對 5.6 GB，依據 Liquid 對兩者的實測。

• 4 位元下的佔用空間——實測報告中約 1 GB，相較之下約 1.1 GB。

• 詞彙量 — 128K 對 130,560。

• 授權 — LFM Open License v1.0，營收低於 1,000 萬美元時免費；Apache 2.0 則無門檻限制。

KV 快取那一列，正是決定硬體選擇的關鍵。在相同上下文長度下，3.5 倍的差距，就是一個能塞進手機的長上下文代理，與一個塞不進去的代理之間的差別。這也解釋了為什麼 LFM3 能提供 256K，而 MiniCPM5 只提供 131K：三混合層結構在每個上下文 token 上的成本更低，而這正是打造它的全部重點。

對某些團隊來說，授權條款的差異比記憶體容量的差異更重要。Apache 2.0 沒有營收門檻、沒有需要協商的商業協議，重新散布也沒有任何模糊地帶。LFM 開放授權在年營收低於 1,000 萬美元時免費，超過這條線則需要談一談。營收在這條線以下的初創公司兩者都能免費取得。超過這條線的公司則是其中一個免費、另一個得打一通電話才能取得，而無論哪個模型評分更高，這都是實實在在的採購成本。

生態系統支援是 MiniCPM5 依然領先之處

兩個系列都在首日就提供廣泛的執行環境支援，因此這個差距比一年前更小。LFM3 列出 vLLM、SGLang、Transformers、llama.cpp、MLX、ONNX、Ollama 與 LM Studio，並提供 BF16、FP8、NVFP4、GGUF、MLX 與 ONNX 版本。MiniCPM5-2B 列出相同的執行環境，另加 GPTQ 與 DSpark；DSpark 是一種推測解碼的草稿模型，可與主檢查點搭配。

實際差異在於成熟度，而非可得性。MiniCPM5-2B 自九月初起即可下載，這代表它已有七週的社群錯誤回報、量化實驗與框架修補，而 LFM3 還沒有。昨天才發布的模型，在其 GGUF 轉換與 Ollama 封裝上仍會有粗糙之處。這不是對 Liquid 的批評；這就是第一天發布的樣子。如果你這週就需要把模型上線到生產環境，別人先踩過七週的雷是有價值的。

如何決定，以及路由器在哪裡值得佔有一席之地

這兩個模型都不在 OrcaRouter 的目錄中——兩者都是你自己執行的開放權重模型，而我們寧願直接明說，也不願暗示相反的情況。路由器在邊界上很重要。進行這項評估的誠實做法，是把兩個模型放在同一個端點後面，並向它們發送真實流量；而在生產環境中執行任何一個模型的誠實做法，則是不讓一個 2B 模型成為唯一能回答的東西。

這就是自動容錯移轉的用途。將請求路由到 LFM3-1.7B，讓它處理工具呼叫或它受訓過的擷取工作，並在任務需要超過 2B 模型所能承載的步驟時，改由託管模型接手。由於 OrcaRouter 以 0% 加成轉嫁供應商定價，昂貴路徑只有在實際使用時才需支付供應商收取的費用——路由到小型本機模型所省下的成本不會被路由器吃掉。路由 DSL讓你能將這件事表達為規則，而不是改寫：先交由專用模型，失敗或低於信心閾值時再交給通用模型。

模型融合在這裡是未被充分利用的選項。當兩個 2B 模型對某個分類意見不一致時，讓兩者都回答並進行調和，通常比升級到 27B 模型更便宜，而不一致率本身就是一個有用的訊號，可指出哪些輸入較困難。當你的流程中有一側是未經驗證的模型時，這種交叉檢查比信任廠商表格更便宜。

什麼能讓它塵埃落定

從現在起三十天內，應該有人透過同一套 harness 發布 LFM3-1.7B 與 MiniCPM5-2B，並把設定與結果一併提交。如果 LFM3 在 WebArena-Verified 上維持接近 38、在 RULER 128K 上維持 65 左右，那麼 23–4 這個計數就會是「理由錯了，但大致正確」，而且代理能力差距確實存在。如果它跌向 MiniCPM5 的數字，那麼發布表格量測到的就是腳手架（scaffolding）。

在那之前，站得住腳的立場比任一家廠商的行銷話術都要來得窄。如果你的工作負載是多步驟、工具呼叫或長文件，LFM3-1.7B 是較好的押注，而記憶體優勢讓它成為兩者之中唯一能在資源受限的硬體上仍留有餘裕的模型。如果你的工作負載是知識檢索、單輪推理，或需要明確無疑的授權條款，以及一個附有獨立評分的模型，MiniCPM5-2B 是較穩妥的選擇，而它勝出的那四列正指向這個方向。23–4 這個比數與其說是錯的，不如說是未經應得的——而發布表格中的模型數量，和實際結果並不是同一回事。