LBS-27B 對決 Granite 4.2 30B：以設計為本的稠密模型，對上不存在的規格

IBM 做了一個刻意的選擇，採用 Granite 4.2 30B：它讓模型保持稠密。六十四層、寬度 32,768 的前饋區塊，每個 token 都要讀取每一個參數。在這一年，這個規模的大多數實驗室都轉向混合專家路由，IBM 卻推出了直通式的 30B，並據此定價。這個決定是將它與 LBS-27B 相比的正確視角，因為關於 inclusionAI 的新儲存庫，我們只知道一個名稱和一份授權條款——而這個名稱必須回答的第一個問題是：它描述的是稠密模型還是稀疏模型。

Granite 4.2 30B 有完整的公開紀錄：權重自 2026 年 8 月起公開，採用 Apache-2.0 授權，模型卡包含十九列基準測試資料，並有文件記載的工具呼叫堆疊。LBS-27B 則有一個於 2026 年 10 月 26 日建立的儲存庫，內含.gitattributes 檔案，以及一份 28 位元組、僅宣告 Apache-2.0 而別無其他內容的 README。這不是兩個模型的比較。這是將一個模型與一份尚未寫出的規格相比，而有用的產出是一份清單，列出該規格需要包含的具體項目。

IBM 實際出貨的內容

Granite 4.2 30B 是一款稠密解碼器，擁有 300 億個參數——Hugging Face 在 BF16 下列出 29B——共 64 層、隱藏維度 4,096、32 個注意力頭，並在分組查詢注意力下設有 8 個鍵值頭。詞彙表為 100,352 個 token，原生上下文長度為 131,072，而 IBM 記載其長上下文可擴展至 512K。它僅支援文字。模型卡列出十二種測試語言：英文、德文、西班牙文、法文、日文、葡萄牙文、阿拉伯文、捷克文、義大利文、韓文、荷蘭文和中文。

就 2026 年的一般意義而言，這是一個推理模型。這張卡說明了完整思考、非思考與低投入模式，並將推理內容包在 think 標籤中。它從 Granite 4.1 30B Base 微調而來，以 Apache-2.0 授權發布，IBM 將發布日期定為 2026 年 8 月 25 日。

稠密模型並非技術上的不足，而是一種取捨。稠密模型在每個 token 的運算與記憶體行為上可預測，沒有路由器會把 token 錯誤導向，也沒有專家平行分片需要設計，而且微調的表現方式符合大多數團隊的預期。作為交換，它每個 token 的服務成本高於總規模相同的稀疏模型。IBM 正把這項取捨賣給那些寧可部署無聊、也不願部署便宜的企業。

一個帶有形狀的基準設定檔

Granite 的規格卡異常完整，因此可以看出該模型在哪些方面表現強勁、哪些方面則不然。上述所有數據皆由廠商提供，尚未經獨立重現驗證。

• 數學 — AIME25 89.17 與 HMMT February 2025 89.17。這些是這張卡上最亮眼的數字，且明顯高於一年前 30B 模型的水準。

• 知識與科學 — GPQA 66.41、MMLU-Pro 77.60、MMLU-ProX lite 66.64、SciCode 38.76。表現稱職，但未達領先水準。AIME 分數接近 90，而 GPQA 分數落在 60 分中段，兩者之間的落差正勾勒出這個模型的輪廓：它更擅長逐步處理結構化問題，而非回憶或跨廣泛領域知識進行推理。

• 軟體工程 — SWE-Bench Verified 57、SWE-Bench Pro 33.29、SWE-Bench Multilingual 41.89、Terminal-Bench 2.1 29.24、LiveCodeBench v6 75.77。從 LiveCodeBench 到 Terminal-Bench 的分數落差很大，而這點很重要：競賽程式設計能力並不等同於在真實終端機中完成多步驟任務的能力。

• 長上下文 — RULER 64K 為 89.96，RULER 128K 為 81.38。這是整張表上最令人安心的一組數據，因為它衡量的是整個視窗範圍內的檢索能力，而不是假設上下文大就等於可用。從 64K 到 128K 下降七分，是一道平緩的斜坡。

• 指令遵循與對話 — IFBench 77.17、Arena-Hard-V2 67.93、tau3 平均 62.00、BFCL v4 61.39。

誠實的解讀是，Granite 4.2 30B 是個紮實但不均衡的模型：在競賽數學與長上下文檢索上表現優異，在廣泛知識上表現普通，在代理式軟體工作上則處於中段。那是一個具體的產品，而非泛用型的產品。

工具呼叫正是 IBM 所提出的論點

IBM 使用的說法是「推理增強的工具呼叫」——模型會在呼叫工具之前，先推理該呼叫哪個工具以及為什麼。實作細節偏向務實而非新奇：OpenAI 風格的函式定義、一個名為 qwen3_coder 的 vLLM 工具解析器、SGLang 自動解析至同一個解析器，以及與 OpenCode、Pi 和 OpenHands 的整合。

這是否優於其他替代方案屬於實證問題，而這張卡片自身的數字好壞參半。BFCL v4 的 61.39 與 tau3 的 62.00 算是不錯，但並不具壓倒性；在那些排行榜上領先的模型通常規模更大。Granite 提供的是有文件記載、可重現的工具呼叫路徑，加上寬鬆的授權條款與稠密模型的服務特性——這往往正是企業代理專案真正需要的，更勝於排行榜冠軍的頭銜。

如果 LBS-27B 鎖定的是同一個買家，這就是它最先會被評判的領域。一個無法可靠呼叫工具的模型，無論其 MMLU 分數多高，都不是代理式工作的候選者；而工具呼叫評測正是那種在模型完成之前不會出現在儲存庫裡的東西。

頁面的 LBS-27B 那一側

可說的很少，重要的是要精確地說出來，而不是用推測來填滿空白。

• 該儲存庫存在。它建立於 2026 年 10 月 26 日 05:36 UTC，且自那時起未曾修改。

• 它包含兩個檔案：一個 1,519 位元組的 .gitattributes 和一個 28 位元組的 README。README 僅包含授權條款前置資料：license: apache-2.0。

• 沒有權重、沒有設定、沒有分詞器、沒有模型卡，也沒有評估資料。下載次數未被追蹤，按讚數為零。我們未發現任何公告、論文或公開討論。

• "27B" 是儲存庫名稱的一部分。儲存庫中沒有任何內容證實它是參數數量，也沒有任何內容指出該模型是稠密還是稀疏。

最後一點並非小缺漏。稠密與稀疏的 27B 是不同產品，具有不同的服務經濟性、不同的微調行為和不同的失效模式。在設定檔出現之前，Granite 比較中有一方已完整定義，另一方則空白。

這項比較，逐個維度來看

• 參數 — Granite 4.2 30B 是 30B 稠密模型（BF16 中列為 29B）；LBS-27B 則是未經驗證的 27B，且未揭露架構。

• 層數與寬度 — Granite 為 64 層、隱藏大小 4,096；LBS 則未知。

• 上下文 — Granite 原生為 131,072，並有文件記載的 512K 擴充；LBS 則未知。

• 模態 — Granite 僅限文字；LBS 則未知，並以僅文字作為合理的基準情況。

• 語言 — Granite 測試了十二種語言；LBS 則未知。

• 推理模式 — Granite 為完整、非思考與低耗力；LBS 未知。

• 工具呼叫 — 已文件化的函式呼叫途徑，Granite 在 BFCL v4 為 61.39、tau3 為 62.00；LBS 則尚無公開資料。

• 授權 — Granite 採用 Apache-2.0；LBS 宣告採用 Apache-2.0，可在權重發布前變更。

• 可用性 — Granite 權重目前可下載且可自行託管；LBS 則沒有任何可下載的內容。

上下文長度是兩者最可能出現分歧的地方

Granite 的 128K 原生視窗搭配 512K 擴充，是一項刻意為企業設計的功能，而 RULER 分數顯示這不只是行銷話術：在 128K 下達到 81.38 是可用的結果。對於合約審閱、日誌分析、程式碼庫檢索與長時間稽核軌跡而言，這種組合——有文件記載的擴充途徑，加上在視窗接近上限處的檢索實證——比背後沒有證據支撐的更大數字更有價值。

如果 LBS-27B 出貨時搭載 256K 或 512K 視窗，有趣的問題不會是那個數字，而是 inclusionAI 是否會公布在其最遠端的檢索評估結果。視窗是一種容量宣稱；RULER 風格的結果則是能力宣稱，而兩者在實務上往往出現明顯落差。

部署、授權，以及路由器的適用定位

兩個模型皆宣告採用 Apache-2.0，這是商業用途上最寬鬆的結果，也是 Granite 深受無法接受自訂授權的團隊歡迎的原因。Granite 4.2 30B 不在 OrcaRouter 上，LBS-27B 也不在；如果你想用 Granite，就得自行下載並提供服務，或使用託管平台。

這種自架式部署正是混合架構派得上用場的地方。在自家硬體上執行 Granite 來處理日常流量——也就是分類、擷取與工具呼叫的流量，對這些而言，密集的 30B 模型已經綽綽有餘——並把真正棘手的案例導向託管的前沿模型。OrcaRouter 對後半段很有用：一組 API 金鑰通行 200 多個模型、供應商效能下降時自動容錯切換，以及一套路由 DSL，讓你把這個分流表達成政策，而不是散落在三個服務裡的程式碼。我們以 0% 加價轉嫁供應商的定價，所以帳單中託管那一側是供應商的數字，而不是我們再加上利潤的價格。

我們不會聲稱這項比較中的任何一個模型能透過我們取得。事實並非如此，而一個暗示相反的比較頁面，比毫無用處還糟糕。

什麼能讓這項比較有定論？

三項產物將讓這個頁面從規格演練變成真正的對決。

首先是config.json，其中包含 expert 欄位，可判定是稠密還是稀疏，並給出啟用參數數量。如果 LBS-27B 是稀疏模型且啟用參數數量少，它在服務成本上將低於 Granite，比較就變成價格與品質的取捨。如果它是稠密模型，那就是直接替代的問題，而 IBM 的工具鏈成熟度將成為決勝關鍵。

第二項是在具名測試框架版本上進行的工具呼叫評估。Granite 的 BFCL v4 與 tau3 分數並不特別出色，這表示新模型不需要特別出色就能勝過它們——它需要的是在相同的測試框架上接受衡量。

第三項是 128K 或以上長上下文中的檢索證據。Granite 的 RULER 數據是它與企業相關性最有力的主張，而這正是挑戰者應被要求匹配的數字。

對今天就要做出決定的企業買家而言，Granite 4.2 30B 是一個已知量，具備寬鬆的授權條款、有文件記載的工具堆疊，以及許多基礎架構團隊偏好的密集服務配置。LBS-27B 則只是一個附帶授權條款說明的名字。兩者之間的差距，並不是對 inclusionAI 工程實力的評斷。這單純是已發布模型與被保留模型之間的差別。