LFM3-1.7B-Base 與 MiniCPM5 2B：兩家廠商、兩張計分板、一個誠實的答案

Liquid AI 建立了LFM3-1.7B-Base 儲存庫；該儲存庫於 2026 年 10 月 26 日在 Hugging Face 建立，並於隔天發布 LFM3 系列公告——而該公告的基準測試表做了一件異常有用的事：它把經過後訓練的LFM3-1.7B直接與MiniCPM5-2B對比，後者是 OpenBMB 自其權重於 9 月釋出以來一直稱為 2B 級開源最先進的 2.5B 模型。在 Liquid 自家的 27 項測試套件中，LFM3-1.7B 贏了 23 列，MiniCPM5-2B 贏了四列。不過，本文標題中的檢查點並不是該表中的那一個，而且它完全沒有附帶任何基準測試數字。這個落差就是故事所在。

每一項小型模型比較都會模糊三件事，因此值得事先把它們分清楚：Liquid 測量了什麼、OpenBMB 測量了什麼，以及兩家廠商都尚未公布、關於人們實際微調的基礎檢查點是什麼。只有第三類才描述本頁這兩個名稱之間的一場公平對決。

Liquid 發布的表格，以及它所描述的模型

LFM3-1.7B 模型卡共有 27 列，橫跨七個類別——代理、工具使用、代理式編碼、編碼、指令遵循、知識與長上下文——並包含 LFM2.5-2.6B、MiniCPM5 2B、Gemma 4 E4B、Qwen3.5 4B 與 Qwen3.5 9B 的欄位。Liquid 自家模型在其中除四項外全數勝出，且代理相關各列的差距並不接近：LiveClaw 45.60 對 30.37、WebArena-Verified 38.42 對 9.11、AutomationBench 41.29 對 4.71、BrowseComp-Plus 37.00 對 16.83。同樣的模式也出現在工具使用（BFCL V4 71.39 對 62.65、ToolSandbox 80.36 對 68.16）與長上下文，其中 RULER 128K 為 65.56，對比 MiniCPM5-2B 的 37.96。

MiniCPM5-2B 的四項勝出全都屬於知識或多輪穩健性：τ³-bench 以 69.44 對 68.01，GPQA Diamond 以 65.15 對 63.37，Humanity's Last Exam 在無工具情況下以 8.20 對 7.17，以及 AA-Omniscience 準確率以 9.13 對 7.07。這些都是在基準測試上的些微領先，而其中零點幾分往往只是雜訊。代理能力的差距則並非如此。

那段文字裡的每個數字都是廠商自行回報的。Liquid 跑的是自家的測試框架、自行挑選比較組，而且沒有在說明卡上公布逐項測試方法。截至 2026 年 10 月 28 日，我們在 Artificial Analysis 上找不到任何 LFM3 條目，因此沒有獨立重現的結果可以與之權衡。請把 23–4 的分布視為 Liquid 的論點，而不是業界結果。

基礎檢查點實際上是什麼

剝除後訓練後，你會得到一個 1.73B 的純文字模型，具有 24 層：13 層閘控短卷積、五層滑動視窗注意力層（視窗為 256 個 token），以及六層全域注意力層。256K 上下文這個數字是真的——已公布設定中的 max_position_embeddings 顯示為 262,144——而不是早期報導混淆的 256-token 視窗。詞彙表為 128,000 個 token，模型卡列出 16 種語言，授權為 LFM Open License v1.0，其商業授權對年營收達 1,000 萬美元或以上的法律實體不再適用。

訓練配方的記錄比大多數基礎版本發布更詳細：總計 22 兆個 token，其中最後 3.5 兆用於精選的中期訓練資料，包含代理軌跡與工具呼叫，並加上 128K 與 256K 上下文擴展。以 4 位元精度而言，該檢查點被描述為約佔 1 GB；若目標是手機或筆電而非伺服器，這才是關鍵數字。

這張模型卡沒有提供的，是對基礎模型本身的任何評估。Liquid 公布的成績屬於經過 SFT、混合 RL、多領域 on-policy 蒸餾與 agentic RL 之後的 LFM3-1.7B。從公開資料中，無法區分那個 49.37 平均分中有多少來自 22 兆預訓練 token，又有多少來自後訓練堆疊。這並不是針對 Liquid 的批評——幾乎沒有人會公布基礎模型評估——但這確實意味著本文標題中的那個名稱，並沒有屬於自己的計分板。

OpenBMB 的計數器計分板

MiniCPM5-2B 的模型卡在不同的一組軸度上提出了不同的主張。其能力雷達圖涵蓋九個維度並給出評分，回報的平均為 53.9，相較之下 Qwen3.5-4B 為 51.1、granite-4.2-3B 為 42.7、LFM2.5-2.6B 為 33.2。在那張榜單上，該模型是 2B 級別的最先進水準，並可與 4B 級別模型競爭。它並未納入 LFM3-1.7B，因為該模型在模型卡撰寫時尚不存在。

這兩個計分板不能彼此相減。它們採用不同的測試、不同的正規化方式和不同的比較集合——而唯一重疊的基準測試 τ³-bench，正是 OpenBMB 的模型在 Liquid 的表格中略微領先的地方。如果你把 53.9 放在 49.37 旁邊，就得出 MiniCPM5-2B 是更強模型的結論，那你等於是把一個九軸的廠商平均值拿來跟一個 27 項測試的廠商平均值相比，什麼也沒學到。

硬體規格方面的事實較不模稜兩可。MiniCPM5-2B 是標準的 LlamaForCausalLM，總參數量為 2,516,756,480，其中 1,981,982,720 為非嵌入參數，共 42 層，採用分組查詢注意力，具備 16 個查詢頭與 2 個 KV 頭，且在出貨配置中支援 131,072 個 token 的上下文。它採用 Apache 2.0 授權，隨附 GGUF、MLX、GPTQ 與 LiteRT 版本，以及用於推測解碼的草稿模型，且 {{1}}OpenBMB{{/1}} 一併釋出了訓練語料。這是一個連工廠都一併附上的完成品。

基準對基準，才是唯一乾淨的比較。

兩個系列都釋出預訓練檢查點，這使得首次可以進行同規格的對等比較。MiniCPM5-2B-Base 建立於 2026 年 8 月 27 日，採用 Apache 2.0 授權，其存在原因與 LFM3-1.7B-Base 相同：要被後訓練成其他東西。兩個基礎模型卡都沒有公布評估表。因此，決定必須依據規格、授權與生態系，而不是依據分數。

這種重新界定很重要，因為這組比較最常見的錯誤，就是下載 Liquid 的 base 模型、像對聊天模型那樣下提示詞，然後得出它比 MiniCPM5-2B 還差的結論。它確實會比較差。LFM3-1.7B-Base 是中期訓練的產物，附有聊天模板與思考模式，並非助理模型；Liquid 自家的模型說明卡就建議，聊天、工具呼叫與代理任務應改用 LFM3-1.7B。該拿來與 LFM3-1.7B 對比的，是 OpenBMB 完成訓練的檢查點，而這個對比已經列在 Liquid 的表格裡。base 對 base 的比較，則是給打算自行進行訓練的人參考的。

規格表，逐項檢視

• 參數 — LFM3-1.7B-Base：24 層共 1.73B。MiniCPM5-2B：總計 2.52B，非嵌入部分 1.98B，共 42 層。

• 上下文 — LFM3-1.7B-Base：256K 個 token，輸入加輸出。MiniCPM5-2B：出貨設定中為 131,072 個 token。

• 架構 — LFM3-1.7B-Base：採用閘控短卷積，結合滑動視窗注意力與全域注意力的三混合架構，並以 trust_remote_code 載入。MiniCPM5-2B：標準的 Llama 解碼器，可在未經修改的工具上運作。

• 授權 — LFM3-1.7B-Base：LFM 開放授權 v1.0，商業使用以年營收低於 1,000 萬美元為條件。MiniCPM5-2B：Apache 2.0，無營收條件。

• 已發布格式 — LFM3-1.7B-Base：基礎版模型卡上僅提供 BF16 權重；後訓練的同系列模型則有 GGUF、MLX、ONNX、FP8 與 NVFP4 版本。MiniCPM5-2B：BF16、GGUF、MLX、GPTQ 與 LiteRT，另有 SFT 與中期訓練檢查點，以及 DSpark 草稿模型。

• 佔用空間 — 依 Liquid 所述，LFM3-1.7B-Base：4 位元量化下約 1 GB。MiniCPM5-2B：一個 2.5B 稠密模型，其模型卡上並未公布 4 位元的佔用空間；預期會是一般 2.5B 等級的記憶體成本，而非 1 GB。

• 語言 — LFM3-1.7B-Base：16 種具名語言，包括阿拉伯語、印地語、泰語和越南語。MiniCPM5-2B：一張以英語和中文為中心的卡片，背後有已釋出的資料。

• 訓練資料 — LFM3-1.7B-Base：22T 個 token，配方有描述但資料未釋出。MiniCPM5-2B：UltraData 語料庫隨權重一同釋出。

儲存庫能告訴你哪些關於部署的事

MiniCPM5-2B 是目前更容易部署到裝置上的模型。其架構是標準的，因此 llama.cpp、Ollama 和 LM Studio 的支援只要使用已發布的 GGUF 即可，而不必等待 kernel。Apple Silicon 有 MLX 版本，Android 有 LiteRT 途徑，而 DSpark 草稿模型的存在，正是為了在資源受限的硬體上加快解碼速度。

LFM3-1.7B-Base 對執行環境的要求更高。它需要自訂建模程式碼，而且基礎檢查點僅以 BF16 發布。同系列其他模型則獲得較好的支援：Liquid 列出 vLLM、SGLang 與 Transformers 支援 BF16，SGLang 支援 FP8 與 NVFP4，llama.cpp 與 Ollama 支援 GGUF，MLX 支援 Apple Silicon，ONNX Runtime 則支援跨平台工作。問題在於，那些建置版本屬於 LFM3-1.7B，而不是基礎檢查點。新增 LFM3 支援的 SGLang pull request #46858 在撰寫本文時仍處於開啟狀態；配套的 cookbook pull request 則已合併。

如果問題是這週要在端點後面放哪個模型，請注意，無論是 MiniCPM5-2B 還是 LFM3-1.7B-Base，目前都尚未收錄在 OrcaRouter 的型錄中。目前兩者都是得下載並自行託管的方案。這正是路由層要等到日後、而非當下，才顯出其價值的情況：用一個相容 OpenAI 的金鑰就能存取 200+ 個模型、0% 加價並直接沿用供應商定價，且當自行託管的機器或單一上游服務故障時可自動容錯切換。在筆電上執行 1 GB 模型並不需要這些；當小型模型成為正式生產路徑的一環、且需要有機制接住故障時，你才需要它。

尚未可知的事物

這份誠實的清單簡短而具體。我們找不到任何 LFM3 模型的獨立基準測試，因此關於這個系列的所有能力主張都出自 Liquid 自己。LFM3-1.7B-Base 沒有已發布的評估，所以沒有人能說這個原始檢查點在後訓練之前有多好。LFM3 在託管 API 上沒有按權杖計價的價格，這使得與 MiniCPM5-2B（在大多數部署中同樣是自架）的成本比較，成為一場硬體與電力方面的推算，而不是費率表上的比較。而且，目前還沒有證據——無論獨立與否——能說明 256 權杖滑動視窗是否會在檢索密集的長上下文工作上讓模型付出代價；Liquid 自己公布的 RULER 128K 分數為 65.56，遠低於其為 Qwen3.5 9B 報告的 87.11，這是一個值得留意的訊號，而不是定論。

在下載其中任何一個之前，值得先回答的三個問題

你想要一個範本，還是一個起點？

如果你想得到某個能回答問題、呼叫工具，還能在週一通過 demo 的東西，MiniCPM5-2B 是完成品，而 LFM3-1.7B-Base 不是。如果你有領域語料、後訓練管線，而且有理由說明現成模型不夠用，那麼 base checkpoint 才是正確的採購選擇——而 Liquid 針對 SFT、DPO、GRPO 與持續預訓練提供的 TRL notebooks，比大多數廠商提供的指引都還多。

貴組織的年營收是否終將突破 1,000 萬美元？

LFM Open License v1.0 僅在該門檻以下授予商業權利。超過該門檻，該作品完全不受此協議授權，您需要與 Liquid 另行安排。Apache 2.0 沒有這種斷崖式限制。對於個人嗜好專案或早期新創公司，這項差異只是理論上的；對於成熟企業，這項差異會在進行任何基準測試之前就決定候選名單。

256K 上下文值得採用自訂架構嗎？

LFM3-1.7B-Base 以更少的參數量，提供 MiniCPM5-2B 兩倍的上下文，這是對它最強而有力的技術論據。代價是它是一個非標準模型，需要遠端程式碼（remote code）、基礎檢查點上現成的建置版本較少，而且執行階段整合仍在推進中。如果你的工作負載能容納在 131K 之內，你就是在為自己用不到的餘裕付出這筆代價。

該選哪一個

對多數比較這兩個名稱的團隊而言，答案是 MiniCPM5-2B——不是因為它在基準測試競賽中勝出，而是因為它是已完成的 Apache-2.0 產品，具備量化版本、已釋出的訓練資料，且沒有授權上限。這是將一個能力出色的 2.5B 模型部署到裝置上風險較低的方式。

LFM3-1.7B-Base 對較窄的受眾而言是更有趣的押注：這些團隊想要一個具備 256K 上下文、16 種語言與非標準架構的 1.73B 檢查點，能在單一 GPU 上繼續訓練，並且能接受 LFM 授權與較薄弱的基礎模型生態系。Liquid 已為那群受眾提供真正的起點與異常詳盡的訓練配方。它尚未給任何人理由相信該基礎檢查點優於 OpenBMB 的成品版本，而廠商自己的表格也未試圖如此宣稱。

值得關注的數字不是 23–4 這個差距，而是任何 LFM3 模型的首度獨立評估——也就是 Liquid 的計分板不再是唯一計分板的那一刻。