Granite Switch 4.1 8B 對比 LFM2.5 2.6B Base：這裡真的有選擇的餘地嗎？

這是本組合中最不像是一場公平對決的一組，所以我們就立刻處理它，而不是假裝情況並非如此。Granite Switch 4.1 8B是 IBM 於 2026 年 10 月 14 日發布的 87.8 億參數組合式檢查點：一個凍結的 Granite 4.1 8B，加上兩個可切換的轉接器和一個語音編碼器，可從單一端點執行聊天、決策評分和轉錄。LFM2.5 2.6B Base是 Liquid AI 於 2026 年 8 月 1 日發布的 26.9 億參數預訓練文字模型，專為裝置端部署而打造——而且重要的是，它自己的模型卡上寫明它是基礎檢查點，「僅建議用於需要大量微調的任務」。把兩者拿來比較，彷彿其中一個可以取代另一個，是範疇錯誤。比較兩者能告訴你更有用的事：它們各自的邊界究竟落在哪裡，以及為什麼幾乎不會有人在這兩者之間做選擇。

所以這不是一場模型大比拼。這是一張你實際上會做出的決策地圖——也就是當你有一個邊緣端目標和一個伺服器端目標，並試圖弄清楚哪個模型該放在哪裡時的那個決策。

每個的用途是什麼

LFM2.5 2.6B Base 是混合架構，而混合正是重點。三十層中，有 22 層是雙閘控短卷積區塊，8 層是分組查詢注意力——因此堆疊多數是卷積而非注意力，這正是在小型硬體上壓低記憶體佔用量與每 token 成本的原因。隱藏大小 2,048，32 個查詢頭對上 8 個 KV 頭，131,072 token 上下文，128,000 token 詞彙表，以及 34 兆 token 的預訓練預算。列出十六種語言：英文、阿拉伯文、中文、法文、德文、義大利文、日文、韓文、葡萄牙文、西班牙文、越南文、泰文、印尼文、印地文、俄文和波蘭文。Liquid 將此系列描述為專為裝置端部署打造，並隨原生檢查點一併提供同系列指令模型，格式包括 GGUF、ONNX 和 MLX。

Granite Switch 4.1 8B 是把相反的直覺套用到相反的問題上。它不縮小模型，而是保留相當大的文字主幹，並從側面增添能力。其基礎是 Granite 4.1 8B：40 層、隱藏大小 4,096、32 個查詢頭對上 8 個 KV 頭、131,072 個 token 的視窗、100,352 個 token 的詞彙表。在此之上是 guardian-core，一個 rank-16 的 activated-LoRA 轉接器，覆蓋注意力投影，用於偵測傷害、越獄、褻瀆、暴力、性內容、社會偏見與不道德行為；decision，一個 rank-64 的轉接器，覆蓋全部七個投影，在單次前向傳遞中對已標註的選項 token 回傳經過校準的 softmax；以及 Granite Speech 5.0 TurboCTC，一個 470M 參數的非自迴歸 conformer 編碼器，用於轉錄。組成的總計為 8,776,400,896 個參數，相較於基礎的 8,380,551,168 個參數——增加了 4.72%。

決定性的維度：instruct 對比 base

這兩個檢查點之間最大的差異，不在於規模或架構，而在於一個是成品模型，另一個則是原料。

Granite Switch 4.1 8B 已可直接呼叫。轉接器已組合進去，控制符元已透過聊天範本串接完成，決策轉接器的叫用方式已附上可運作的程式碼記錄，模型卡也列出它所需的確切 Transformers 與 vLLM 版本。你下載、執行它，它就會完成這三項工作。

LFM2.5 2.6B Base 刻意不做這些事。Liquid 自家的指引指出，這個檢查點是用於「語言特定（例如日語）或領域特定（例如醫療）的助理、以專有資料進行訓練，或實驗新穎的後訓練方法」——而如果你想要的是能開箱即用回答問題的模型，這張模型卡會指向經過後訓練的同系列模型。基礎檢查點沒有可供比較的指令遵循行為、沒有對齊，也沒有聊天範本紀律。把兩者放上同一份評估，Granite 模型會看起來好得多，但原因與哪個模型更好毫無關係：一個經過後訓練，另一個則沒有。

• 參數量 — 組合後 8.78B 對比 2.69B。

• 層 — 40 個稠密 Transformer 區塊 vs 30 個混合式（22 個雙閘控短卷積 + 8 個 GQA）。

• 上下文——131,072 個 token 對上 131,072 個 token。完全打成平手，這很不尋常，值得注意。

• 詞彙量 — 100,355（為適配器保留三個 id）vs 128,000。

• 模態——輸入文字與音訊、輸出文字，相對於僅限文字。

• 檢查點類型 — 已組合、經後訓練、可直接呼叫，對比可供微調的預訓練基礎模型。

• 授權 — Apache-2.0 與 LFM 1.0 授權條款，而後者並非 Apache。這項區別在商業上很重要，而且很容易被忽略。

• 已發表的證據——僅有一份由供應商自行執行的 Decision Index，總分 42.9，並無獨立評估；相較之下，基礎檢查點也沒有可比的公開基準。

2.69B能給你什麼，而8.78B卻做不到

可攜性，而且這不是可有可無的優勢。一個 2.69B 模型，其 30 層中有 22 層由短卷積構成，就是為了在裝置上運行而設計——筆電、手機級 SoC、嵌入式主機——而 Liquid 正是為此提供量化版 GGUF、ONNX 與 MLX 變體。一個 8.78B 的組合式檢查點，搭配 470M 語音編碼器，是伺服器端產物。它是在 GPU 上、容器中、端點後方運行的。

那意味著部署形態並不重疊：一種是針對請求無法離開裝置的情況，另一種則是針對請求可以離開裝置的情況。如果限制條件是「沒有網路」，那麼比較還未開始就已結束，再多的組合也改變不了這點。再加上授權這一項——是 LFM 1.0 而非 Apache-2.0——當你打算用自己的資料微調自己的模型，並將它出貨到產品中時，2.6B 檢查點就是你會挑選的；而當你想要在寬鬆授權下今天就取得三項能力時，Granite Switch 則是你会挑選的。

組合能為你帶來什麼，而 2.69B 做不到？

一個端點完成三項工作，並以機率取代答案。

決策適配器是在另一側沒有對等物的部分。給定一個狀態和一個帶有標籤選項的問題，它會在一次前向傳遞中回傳對這些標籤的校準 softmax——文件中記載的呼叫會透過 logprob_token_ids 向 vLLM 要求正好是標籤 token id 的 logprobs，並將其取指數，產生形如 A: 0.982、B: 0.0035、C: 0.014 的輸出。提示給你一個 token；這給你一個可以設閾值、取平均和取對數的數字。還有一個文件中記載的細節，值得在以此為基礎建構之前知道：vLLM 將 logprob_token_ids 上限設為每個請求 128 個 id，因此選項超過 128 個的問題需要將其標籤 id 分塊成每組 128 個，每個分塊發出一個提示完全相同的請求，將結果串接起來，並對完整標籤集套用單一 softmax。由於回傳的 logprobs 涵蓋完整詞彙表，每個標籤的值與是哪個分塊要求它無關，因此分塊後的結果在數學上與未設上限的呼叫完全相同。

同一個端點上的語音是第二項。在一般聊天補全請求中送出一個 input_audio 內容部分，470M 編碼器便會先將其轉錄，再把轉錄文字串接進上下文。IBM 提出的注意事項很具體，值得重述：僅限英文、輸出為小寫且不含標點，而且編碼器與語言模型並非聯合訓練——兩者之間沒有任何經過訓練的投影加以耦合，因此轉錄失誤可能會在不知不覺中改變模型所回應的內容。完全沒有音訊路徑的邊緣模型，面對的是另一種問題，而不是沒有問題。

而安全適配器則是第三個：一個有害內容與越獄分類器，搭載在同一個檢查點上，當你傳入 adapter_name 時，由聊天模板插入的控制符元所啟動，而不是還得部署並付費的第二個模型。

當答案是「兩者皆是」時，路由器該置於何處

這個比較的務實版本，最後是兩個模型都落在同一個產品裡。LFM2.5 2.6B Base 經過微調、運行在裝置端，處理那些不能離開裝置的事；Granite Switch 4.1 8B 自我託管，在伺服器端處理決策與轉錄。這是一種雙層架構，而它帶來的維運問題是：接縫處會發生什麼——裝置端模型失效、伺服器滿載、某個請求需要轉落到其他東西上。這兩個檢查點目前都不在 OrcaRouter 的目錄中，所以我們不是取得任何一個的途徑；我們真正派上用場的地方，是它們背後的遞補鏈。一組 API 金鑰涵蓋 200 多個託管模型，並具備自動容錯移轉，路由 DSL 讓你將多個模型組合成單一次呼叫，而不必自己手工打造扇出，而且供應商的定價以 0% 加成原樣傳遞，因此廠商降價當天就生效。img src="4.png" alt="OrcaRouter 模型目錄的截圖，標題為「210 個模型、16 家供應商、一組 API 金鑰、一份帳單」，模態分類顯示 173 個文字、12 個圖像、5 個嵌入、10 個影片與 10 個 TTS 模型，側邊篩選列可依輸入模態、上下文長度、輸入價格、狀態、存取層級、系列與支援參數篩選，以及一份由新到舊排列的模型卡片清單，開頭是 OrcaCyber Zero 1.5、OpenAI GPT-6.1 Sol 與 Anthropic Claude Sonnet 5.5，並列出它們每百萬詞元的輸入與輸出費率。" /> 正是這一層讓雙層設計得以存活，而不是一碰就碎；在邊緣層開始在現場出錯之前，就先把這一層準備好，是值得的。

判決，不過如此

如果你要進行微調、推論必須在裝置端執行，或者 2.69B 的占用空間是硬性限制，就選擇 LFM2.5 2.6B Base。如果你需要經過校準的決策分布、內嵌的安全分類器，或從與對話相同的端點進行轉錄，而且可以接受由 GPU 支援的容器，就選擇 Granite Switch 4.1 8B。這兩個使用情境之間的重疊幾乎為零，這就是為什麼對「哪一個勝出」的誠實答案是：這個問題本身就有問題——也是為什麼更值得帶走的一點是，2.69B 的基礎檢查點與 8.78B 的組合式指令模型，並不是同一條品質線上的兩個點。它們是兩個不同的產品，只是參數數量恰好相近。