LBS-27B 與 LFM2.5 24B A2B：活躍參數之問

中最重要的數字LFM2.5 24B A2B並不是 24。它是 2.45——也就是模型在每個 token 實際讀取的參數量（以十億計）。這就是為什麼 Liquid AI 能宣稱在 Apple M5 Max 上每秒輸出 184 個 token，而模型仍持有 240 億參數的知識，也是為什麼該公司將其定位為裝置端代理，而非資料中心的主力。同樣的數字在 LBS-27B中缺席，而這個缺席正是目前無法判定這項比較的原因：沒有活躍參數數量，就無法將 inclusionAI 的模型放到 LFM2.5 所定義的效率曲線上的位置。

LFM2.5 24B A2B 自 2026 年 10 月 13 日起開放下載，附有模型卡、十六行基準測試資料，以及一份多數企業都需要仔細閱讀的授權條款。LBS-27B 是一個建立於 2026 年 10 月 26 日的儲存庫，內含一個標準的 .gitattributes 檔案，以及一份宣告 Apache-2.0 的 28 位元組 README。沒有權重、沒有設定檔、沒有模型卡、沒有公告。因此，以下內容是在比較一個規格完整的效率取向方案，與一個尚未表明自身屬於何種模型的名稱。

Liquid 最佳化的目標是什麼

LFM2.5 24B A2B 是一款混合專家（mixture-of-experts）解碼器，擁有 64 個專家、top-4 路由、40 層、2,048 的隱藏層大小，以及 128,000 個 token 的詞彙表。其啟用參數量為 24.5 億。它可接受 131,072 個 token 的上下文，較前一代的 32K 有所提升，並且以 33 兆個 token 進行預訓練，約為 LFM2 所用 17 兆的兩倍。

詞彙變更是一個值得注意的細節。從 65K 增加到 128K 個 token 所費不貲——這意味著要重新訓練嵌入層和輸出層——而這麼做的常見原因是非拉丁文字。卡片列出了十六種語言：英文、阿拉伯文、中文、法文、德文、義大利文、日文、韓文、葡萄牙文、西班牙文、越南文、泰文、印尼文、印地文、俄文和波蘭文。更大的詞彙量能降低這些語言每個詞的成本，而且通常在長尾表現上更好。

它同時也是僅供推理的模型。Liquid 的後訓練流程依序進行監督式微調、教師專業化、非代理式與代理式蒸餾，然後在 OpenClaw、Hermes Agent、Pi 和 OpenCode 等框架內進行代理式強化學習。該模型會在回答前產生思維鏈；模型卡上並未記載另有獨立的「快速、不思考」模式。

刻意設計成尖峰狀的基準測試剖面

Liquid 自己公布的數字，我們並未重現，描繪出一個模型：它擅長裝置端代理所做的事，卻不擅長知識工作者所需的事。這樣的形態並非偶然；這正是設計本意。

• 指令遵循 — IFEval 96.75、IFBench 74.69、Multi-IF 84.38。這是整張卡上最強的一組，也是對必須遵守工具結構定義的代理而言最重要的一組。

• 工具使用 — ToolSandbox 80.71、PinchBench 83.18、BFCL v4 65.01、AutomationBench 27.69。表現良好，但在不同測試框架之間並不平均。

• 代理式瀏覽與電腦操作 — LiveClaw 48.09、WebArena Verified 26.75、tau3-Bench Banking 8.04。銀行業的結果是異常值：在一套其他代理式模型處理得遠更好的任務套件上，卻只有個位數分數。這提醒我們，「代理式」並不是單一能力。

• 軟體工程 — SWE-Bench Verified 在 OpenCode 下為 51.00，SciCode 為 32.71。中等水準。

• 數學 — MATH-500 96.04。就這個規模而言，表現很強。

• 知識 — GPQA Diamond 74.42、HLE 7.40、AA-Omniscience −24.90。負值的 Omniscience 分數才是這裡誠實的訊號：在一個會懲罰自信錯誤答案的基準測試上，這個模型失分多於得分。Liquid 自身的定位也承認這一點——這個模型應與檢索搭配使用，而不能當作百科全書來信任。

綜合來看，這些列顯示該模型是個稱職的指令遵循者與工具呼叫者，但知識基礎薄弱。對於會讀取你的檔案並呼叫你的 API 的本地代理而言，這是正確的取捨。對於研究助理而言，則是錯誤的取捨。

效率主張及其附帶條件

Liquid 報告指出，在 Apple M5 Max 上使用約 15GB 記憶體可達到每秒 184 個 token，而在 Ryzen AI Max+ 395 上則為每秒 114 個 token。這些是特定硬體上的廠商數據，並非通用基準測試，且會隨量化與批次大小而變動。方向仍具意義：一個擁有 2.45B 活躍參數的 24B 模型，能在筆電上運行，而這是稠密 24B 模型做不到的。

取捨在於記憶體頻寬。稀疏模型仍必須將全部 240 億個參數保留在記憶體中——節省的是每個 token 的運算量，而非儲存空間。這就是為什麼 15GB 這個數字與吞吐量同樣重要：它大致相當於對整套權重進行 4 位元量化，並界定了硬體的下限。

LBS-27B 必須位於何處

這個對戰組合的一切，都取決於 LBS-27B 儲存庫中目前還不存在的兩個欄位：專家數量與作用中參數量。

如果 LBS-27B 是稀疏模型，激活參數約在 2B 到 4B，它就直接落入 LFM2.5 的領域——以小型模型的運算量提供 27B 等級的知識庫——而比較就變成每個激活參數品質的直接較量。如果它是稠密模型，那就是完全不同的產品：伺服器端模型，運算可預測，且記憶體佔用讓大多數筆電無法負荷。如果它是稀疏模型但激活數量很大，它就介於兩者之間，並以品質而非效率競爭。

無法從這個儲存庫推斷出是哪一種。名稱寫著 27B，README 寫著 Apache-2.0，而檔案樹則沒有提供其他線索。就我們所能找到的，inclusionAI 並未發布任何模型卡、部落格文章或論文。

在可進行比較的範圍內所作的比較

• 總參數量——LFM2.5 24B A2B 為 24.0B；LBS-27B 則為未經證實的 27B。

• 活躍參數 — LFM2.5 為 2.45B；LBS-27B 則未知，而這是決定性的未知數。

• 架構 — LFM2.5 採用 64 個專家、top-4 路由與 40 層；LBS-27B 則未知。

• 上下文 — LFM2.5 為 131,072 個 token；LBS-27B 則未知。

• 模態 — LFM2.5 僅支援文字；LBS-27B 未知。

• 語言 — LFM2.5 列出十六種；LBS-27B 則未知。

• 推理 — LFM2.5 預設採用思維鏈，且沒有文件記載的無思考模式；LBS-27B 則未知。

• 授權 — LFM 1.0 授權條款，年營收超過 1,000 萬美元即須取得商業授權，適用於 LFM2.5；LBS-27B 則宣告採用 Apache-2.0。

• 已發表的評估 — LFM2.5 有十六列由廠商提報的資料；LBS-27B 則無。

授權是採購問題，而非註腳。

這是唯一一個空儲存庫已讓 LBS-27B 佔優勢的層面。LFM 1.0 授權並非 OSI 意義上的開源授權：年營收超過 1,000 萬美元的公司必須先取得单独的商業授權，才能部署。對個人開發者或未達門檻的新創公司而言，這不成問題。對中型企業來說，這則是一次法律審查、一場協商，以及一筆預算項目。

LBS-27B 在其 README 中宣告採用 Apache-2.0。這是一種寬鬆授權，附有明確的專利授權，且沒有營收門檻；如果這項授權能延續到權重發布，就能省去一整個採購步驟。這是 LBS-27B 目前在這項比較中唯一具體的優勢，值得清楚說明，因為它是真實存在的——在建立儲存庫時所作的授權宣告是薄弱證據，但並非毫無意義。

裝置端與 API：兩種不同的產品

LFM2.5 24B A2B 的設計目標是直接在資料所在之處運行。其賣點是隱私與延遲：一個在筆記型電腦或工作站上運行、永遠不會向第三方送出請求的模型，且工具呼叫能力足以驅動本機自動化。4 位元記憶體佔用量與 131K 上下文正是為這項任務量身打造。

LBS-27B 尚未說明其用途。若 inclusionAI 推出的是專為伺服器端服務設計的模型，那麼裝置端的論點便不適用，這兩款模型屬於互補而非替代關係。若它推出的是具備本地部署方案的小型活化參數 MoE，比較就會很直接，而 Liquid 在裝置端工具鏈上領先兩代的優勢——支援 llama.cpp、MLX、ONNX 與 vLLM，外加有完整文件的代理框架——便成為決勝關鍵。

框架支援是這件事裡常被低估的一環。一個在推出首日沒進到 llama.cpp 或 MLX 的模型，實務上就不算是在地端模型，不管它的活躍參數量有多少。

測試一個未經證實的模型，而不對它下注

LBS-27B 與 LFM2.5 24B A2B 目前都不在 OrcaRouter 上，因此兩者都沒有託管端點，我們也不會暗示相反的情況。這裡提到這個平台，原因是隨之而來的評估問題：如果你想知道一個新的小活化模型能否取代你目前使用的模型，你必須讓兩者在自己的流量上運行，而不是在排行榜上比較。

OrcaRouter 的路由 DSL讓你能將一定比例的請求傳送給候選模型，同時把現行模型保留為預設；自動容錯移轉意味著逾時或出錯的候選模型會降級至已知模型，而不是讓請求失敗。對於單一模型不足以處理的棘手情況，模型融合可讓一組模型共同回答並傳回合併結果——當任務知識密集，而便宜模型的弱點正是你正在測試的重點時，這特別有用。在這裡，超過 200 款模型的目錄與 0% 加價不如能在自己的輸入上進行比較、且無需額外整合的能力來得重要。

這是一種產生本頁面所缺證據的方法。它不能取代模型本身的存在。

三位讀者，三種答案

如果你正在打造一個裝置端代理，而且需要一個今天就能在筆記型電腦上跑起來的東西，LFM2.5 24B A2B 是個值得認真考慮的候選：指令遵循能力強、在數個測試框架上工具呼叫表現良好、131K 上下文，還有進入常見本地執行環境的完整說明文件。先確認授權門檻，也別指望它在沒有檢索的情況下就知道事實。

如果你正在挑選伺服器端的 27B，而且需要寬鬆授權，LBS-27B 值得關注，正是因為它已宣告採用 Apache-2.0。但目前沒有任何東西可供評估，而授權宣告並不等于模型。

若貴企業年營收超過 1,000 萬美元，且採購流程嚴格，授權差異可能比本文任何一列基準測試結果都更重要。LFM2.5 的客製授權是實質成本；LBS-27B 的 Apache-2.0 則是實質優勢，但前提是它能否撐到正式發布。

能改變這三個答案的數字，就是活躍參數量。在這個數字出現之前，誠實的立場是：其中一個模型有的是一套效率敘事，另一個有的則是一個儲存庫。