LFM3-1.7B 對上 Granite 4.2 30B：兩個評價隨軸向分歧的代理模型

把 LFM3-1.7B 與 Granite 4.2 30B放在同一頁面上，匯總平均值會依你讀的是哪一列而指向相反方向。在 Berkeley Function Calling Leaderboard V4 上，Liquid AI 的 17.3 億參數模型得分 71.39，對手是 IBM 的 61.39——一個約小十七倍的模型領先十分。在 SWE-bench Verified 上，Granite 得分 57.00，對手是 LFM3-1.7B 的 43.40，反方向領先 13.6 分。路由不會在供應商的標價上增加利潤。供應商標價會以 0% 加成 原樣傳遞。

兩款模型都是為代理式應用打造，且都在 2026 年相隔不到兩個月推出；兩家廠商公布的基準測試重疊度也足夠，因此能進行真正的比較，而非拼貼式對照。這使得這場對決相當罕見：有趣的問題不是哪個模型更好，而是你的工作負載實際落在哪個軸線上。很少有任務同時需要 71 分的 BFCL 成績與 57 分的 SWE-bench 成績，而真正需要的任務，也無法只靠任一模型妥善處理。

交叉的那兩個數字

Granite 4.2 30B 於 2026 年 8 月 25 日以 Apache 2.0 授權發布；這是一款稠密式、約 300 億參數的模型，以 Granite 4.1 30B 為基礎建構，訓練資料量約達 15 兆個 token。IBM 將其定位為企業級產品：三種可設定的思考模式、依 OpenAI schema 提供的原生工具呼叫、十二種經過測試的語言，以及最終以多階段 GRPO 強化學習收尾的三階段訓練流程。

LFM3-1.7B 於兩個月後推出，於 2026 年 10 月 27 日發布，專門在代理式執行框架（agentic harnesses）上進行後訓練——Liquid 在模型卡中點名 Hermes Agent、PI 與 OpenClaw。它是擁有 256K 上下文的 1.73B 稠密模型，並明確定位於本地代理與工具呼叫，而非通用推理。

這道基準測試的交叉點，並不是某個單一疲弱數字造成的偶然。LFM3-1.7B 整份公開表格明顯偏向代理型任務：BFCL V4 為 71.39、ToolSandbox 為 80.36、τ³-bench 為 68.01、LiveClaw 為 45.60、WebArena-Verified 為 38.42。Granite 的表格則偏向工程型任務：SWE-bench Verified 為 57.00、SWE-bench Pro 為 33.29、SWE-bench Multilingual 為 41.89、SciCode 為 38.76、TerminalBench 2.1 為 29.24。每家廠商各自針對不同的「代理」定義進行最佳化，而這些基準測試表格也誠實地反映出各自偏向哪一種定義。

τ³ 在 68.01 對 68.05 才是真正的頭條

在兩道顯著落差之下，其實是一場難分軒輊的拉鋸。在 τ³-bench 這項以使用者模擬器與領域政策衡量多輪任務完成度的工具使用評測中，LFM3-1.7B 得分 68.01，Granite 4.2 30B 得分 68.05——相差零點零四分，與雜訊無異。

這比那兩個巨大差距都更有趣，因為 τ³ 是最接近大多數代理部署實際所做之事的基準：維持對話、遵循策略、呼叫正確的函式、從錯誤中復原。如果一個 1.73B 模型在那裡與一個 30B 稠密模型打平，那麼參數數量所換來的，就不是勝任的多輪工具使用能力。

這換來的成果會反映在 BFCL 與 SWE-bench 上，而兩者衡量的是不同能力。BFCL V4 測試的是依結構定義進行單輪函式呼叫的正確性——LFM3-1.7B 的 71.39 顯示，Liquid 在真實 agent harness 上進行的後訓練直接奏效。SWE-bench Verified 測試的是端到端修復真實的 GitHub issue，這需要將儲存庫保持在上下文中、跨檔案規劃，並產出能通過測試的修補程式——Granite 的 57.00 反映出這是一個具備此能力、且訓練集正是為此打造的模型。

所以分野很清楚。小型模型在工具結構描述上訓練有素：贏得函式呼叫測試。大型模型受過程式碼修復訓練：贏得儲存庫測試。在兩者都受過特定訓練的多輪中間地帶則打成平手。

上下文正是規格分歧最劇烈的地方。

• 上下文 — LFM3-1.7B 為 262,144 個 token；Granite 4.2 30B 原生 128K，可擴充至 512K。擴充並非免費，且 IBM 坦承這是擴充而非原生視窗。

• 長上下文保留 — LFM3-1.7B 在 128K 的 RULER 上得分 65.56，而 Granite 4.2 30B 在同一基準系列上得分 81.4。較大的模型能保留較多長文件內容，這與標題上下文數字所暗示的相反。

• 記憶體佔用 — 在 4 位元下約 1 GB，相較於約 30B 的 BF16 權重，並提供官方 FP8、NVFP4 與 MXFP4 版本。這是單一 GPU 模型，不是筆電模型。

• 語言——LFM3-1.7B 測試了十六種語言，Granite 則測試了十二種，兩者的重疊情況不同。Granite 的十二種包含捷克語與荷蘭語；Liquid 的十二種則包含泰語、越南語與印尼語。

• 思考模式 — Granite 4.2 30B 提供完整、低投入與不思考模式。LFM3-1.7B 沒有這類介面，而其說明卡也指出，它本來就不適用於複雜的多步推理。

• 授權 — Granite 採用 Apache 2.0，對比 LFM 開放授權條款 v1.0：年營收低於 1,000 萬美元時可免費使用，超過此門檻則需取得商業授權。

30B 稠密模型有哪些成本是 1.73B 所沒有的？

Granite 4.2 30B 是稠密模型，這意味著全部三百億個參數在每個 token 上都會執行。這裡沒有活躍參數折扣：每個 token 的計算成本約為小型模型的十七倍，記憶體成本則是完整的權重檔案。IBM 提供量化版本讓這件事變得可行，但沒有任何組態能讓它在手機上執行。

LFM3-1.7B 的優勢主要不在於速度，而在於該模型能與應用程式的其餘部分共用相同的記憶體預算。1 GB 的模型可為文件儲存、快取，以及同一裝置上的第二個模型留出空間——這正是讓本機代理得以實現，而不只是理論上在本機運行的原因。Liquid 表示，在受測硬體上，其解碼速度比前代快 1.8 到 2.8 倍，且在 128K 下 KV 快取為 1.6 GB；這兩點對於要進行長對話的裝置端代理都很重要。

反面的考量是，Granite 的 30B 容量在 SWE-bench 數據中確實在發揮實際作用。如果你的 agent 的工作是跨整個儲存庫修改程式碼，那麼 13.6 分的差距並不是較小的模型靠提示詞就能補回來的，而省下的算力換來的只是更差的結果。

授權、簽署與採購問題

Apache 2.0 是大型組織能夠在無需法律審查的情況下採用 Granite 4.2 30B 的原因。沒有營收門檻、沒有商業觸發條件，也沒有談判空間。IBM 自 2026 年 4 月起也一直以密碼學方式簽署已發布的 Granite 模型，這聽起來像是細節，直到你成為那個必須證明生產環境中的權重就是經過審查的權重的人。

Liquid 的 LFM Open License v1.0 在新創規模下確實相當寬鬆——年營收低於 1,000 萬美元可免費商用——但超過這條門檻後，就需要付費商業授權。對個人開發者或小型團隊而言，這不成問題。對大型企業內的業務單位來說，這是一場在首次部署前就開始、且可能無法迅速結束的對話。這種不對稱並未反映在任何基準測試中，卻往往單獨決定了問題的答案。

兩者同時運行，但不押注於任何一方

團隊在評估這兩者時，實用的做法並不是先挑一個。兩者都是開放權重，且都尚未經獨立評估者驗證，這意味著唯一重要的基準就是你自己的基準。把候選模型導向同一個端點，讓兩者跑同一批代理軌跡，並依據你自己的任務來比較，而不是依據 BFCL 或 SWE-bench。

在這裡，OrcaRouter 與其說是主機，不如說是控制層：一組金鑰、一張帳單，涵蓋超過 200 個模型，供應商牌價以 0% 加價原樣傳遞，並具備自動容錯切換，讓評測執行不會因為某個供應商出狀況一小時就中斷。LFM3-1.7B 和 Granite 4.2 30B 目前都不在我們的目錄中——兩者都是開放權重下載，且各自都適合走自架路線。路由真正發揮價值的地方在周邊堆疊：你的代理升級所使用的前沿模型，或當本地模型的修補程式未通過測試時，你用來比對的第二意見。

誰應該拿哪一個？

採用 LFM3-1.7B，如果代理程式是在使用者裝置上執行、如果工作內容是針對 API 進行工具呼叫與結構化擷取，而且如果 256K 上下文搭配 1 GB 記憶體佔用正是讓這項產品得以成立的關鍵。請接受廠商自身的警告：它並不適合代理式程式開發，並在其後保留一個更大的模型，以因應需要的情況。

選擇 Granite 4.2 30B如果代理會接觸程式碼庫、如果你需要 Apache 2.0 與供採購使用的已簽署權重、如果工作負載能受益於可設定的思考強度，而且如果你有 GPU 可從中提供服務。BFCL 的落差確實存在但範圍狹窄：它衡量的是單次呼叫中的結構描述正確性，而具備精心設計工具結構描述的 30B 模型，實務上能彌補其中大部分差距。

採用這種分工如果你正在打造兩家廠商都瞄準的東西——一個能在 1GB 記憶體內處理例行工具呼叫，並把儲存庫規模的工作交給伺服器的本機代理。這種架構會讓每個模型在自己基準測試表所說的強項上發揮，而且這是唯一能讓交叉軸線不再成為問題的安排。

值得觀察的問題是，Liquid 的代理式後訓練配方是否能移轉到更大的檢查點。如果未來的 LFM 模型能維持 71.39 等級的 BFCL 行為，並增加處理儲存庫工作的能力，那麼軸線分工就會瓦解，這項比較也會變成單純的規模決策。在那之前，這兩個模型並不是在爭奪同一份工作——它們是同一個整體的兩半。