TwIL-LM3-Pro 與 LFM2.5 2.6B Base：一個已完成，另一個則是起點

關於已發表的 TwIL-LM3-Pro 與 LFM2.5 2.6B Base 對比，最耐人尋味的一點是：webAI 根本沒有發表任何與 2.6B 的對比。webAI 的 Track A 與 Track B 表格，是拿它那個 3.66B 的形式邏輯專門模型去對上一系列對手——自家的 Granite 基礎模型、VibeThinker-3B、Qwen3-8B、Qwen3.5-4B、Llama-3.2-3B、gpt-oss-120b——而他們所選的 Liquid AI 代表是 LFM2.5-8B-A1B，並非 2.6B。表格中確實出現的那個 2.6B 是 `LFM2-2.6B`，也就是前一代，那是另一個模型，有不同的預訓練歷程。這項遺漏並非疏忽。LFM2.5 2.6B Base 是一個未經指令微調的預訓練檢查點，而指令跟隨類基準測試，本來就不是它被打造來應考的項目。

所以這個頁面是把一個完成的成品拿來和原材料比較。Aion 式的框架——一個模型有分數，另一個沒有——很貼切，但理由更具體也更有趣：一個經過後訓練並合併，另一個刻意在後訓練前停下，而描述它們的兩份文件是在刻意回答不同的問題。

兩個參數的計數並非相同的量測

TwIL-LM3-Pro 有 36.6 億個參數，是稠密模型，每個 token 都會啟用全部參數。它源自 `ibm-granite/granite-4.2-3b`，歷經 LoRA 微調、多路徑蒸餾、檢查點融合、朝基礎模型回併的 WiSE-FT 合併，以及熵加權 GRPO 階段，而 webAI 交付的成品是合併後的政策模型，而非 LoRA 轉接器，因此可獨立運行。

LFM2.5 2.6B Base 在 30 層中共有 2.69B 個參數：22 個雙閘控短卷積區塊與 8 個分組查詢注意力層交錯排列。這種卷積／注意力混合設計是 Liquid 的裝置端架構，也正是這個系列的吞吐量數字之所以如此，而非單純取決於參數量的原因。它以 34 兆個詞元訓練，詞彙量為 128,000 個詞元，並具備 131,072 個詞元的上下文視窗。

這兩個數字相差約 36%，而且是透過完全不同的架構得出的，因此無論是「3.66B 勝過 2.69B」還是反過來，都不能當作品質宣稱來解讀。webAI 自家的模型卡在婉拒比較不同分詞器之間的語料庫困惑度時，也間接表達了這一點——TwIL-LM3-Pro 的詞彙量是 100,352，LFM2.5-2.6B 的是 128,000，而困惑度是逐 token 計算的。

「Base」移除了什麼，以及它為何會改變計分板

Liquid AI 以兩種形式發佈 LFM2.5 2.6B：後訓練檢查點，針對熱門代理框架中的代理式工作負載進行調校；以及 Base，其專屬說明卡將其描述為「純文字的預訓練檢查點，用於建立所有 LFM2.5-2.6B 變體」。Base 是微調的輸入，而非產品。它沒有指令微調，沒有名副其實的聊天範本，也沒有公開評測——因為以指令遵循任務來評測基礎模型，所衡量的根本不是該衡量的東西。

TwIL-LM3-Pro 的立場恰好相反。它的全部價值在於後訓練堆疊：webAI 報告指出，在其自家測試框架上，該流程將域內巨集閘門從其基礎模型的 0.4313 提升至 0.5539，而留出的 10 資料集巨集值則維持持平（0.7942 至 0.7901），而非崩跌。留出保留是專家化後訓練最困難的部分，而這正是 Base 無法回答的部分。

這也是 webAI 表格中的規模比較發揮價值之處。據報導，TwIL-LM3-Pro 在兩組保留集的巨集平均上都領先 LFM2.5-8B-A1B——在十資料集組上為 0.7901 對 0.7884，在十四資料集組上為 0.7425 對 0.7378——而且參數量不到那個 MoE 模型的一半。這是真正同基準的結果，而它之所以能取得，正是因為 LFM2.5-8B-A1B 是經過後訓練的模型，可以放進指令框架中運行。Base 則不行，這就是為什麼 2.6B 從未獲得一欄。

值得對齊的維度

• 參數 — TwIL-LM3-Pro 3.66B 稠密 對比 LFM2.5 2.6B Base 2.69B（30 層：22 卷積 + 8 GQA）。

• 後訓練 — LoRA SFT、蒸餾、WiSE-FT 合併，以及第 2580 步的 GRPO 對比無；Base 依設計即為預訓練輸出。

• 上下文視窗 — 兩者皆為 131,072 個 token，分別繼承自各自的基礎模型。

• 詞彙量 — 100,352 個詞元 對比 128,000，這就是它們的困惑度無法互相比較的原因。

• 語言——僅限英文對比十七種，包括阿拉伯語、中文、日語、韓語、西班牙語和泰語。

• 思考格式 — TwIL-LM3-Pro 預設會發出 `<think>` 區塊並進行冗長推理（網域內平均 1,902 個 token，24.2% 的生成結果觸及長度上限），相較於完全沒有指令格式的基礎檢查點。

• 授權條款 — webAI 非商業授權條款 1.0 版 vs Liquid 的 LFM 開放授權條款 v1.0。

• 它的用途——形式邏輯推論端點，對比微調起始點。

這些上下文長度值得加上一個兩款模型都提供的註腳：兩者都從預訓練階段帶入 131,072 個 token，而兩家廠商都沒有驗證長上下文行為——TwIL-LM3-Pro 的說明卡上寫著，每一項公布的成績都是在 8,192 個 token 的視窗內測得的。這裡彼此吻合的數字是繼承來的，並非實測所得。

許可證，以及每一種在法律上的用途

TwIL-LM3-Pro 的 webAI Non-Commercial License 允許研究與個人使用，若要用於產生收益的部署，則需與 webAI 另行簽訂協議。LFM2.5 2.6B Base 依 Liquid 自家的 LFM Open License v1.0 發布，Hugging Face API 將其回報為 `license: other`，而非標準的 SPDX 識別碼——在據此規劃之前，請先閱讀授權檔案，因為這些條款是 Liquid 自訂的，而非公認的範本。

這兩份授權條款都不是 Apache 2.0，而把「開放權重」當成「商業上寬鬆」的同義詞是錯誤的。兩者之間的實際差異在於這些授權條款所保護的是什麼：非商業研究者兩者都能使用，打造產品的公司則兩者都需要確認，而 Base 的整體目的——被微調進他人的產品中——使其確切條款比表面上看起來更事關重大。

每一個在堆疊中應該放在哪裡

當你打算進行訓練時，Base 就是正確的選擇。如果你的問題是範圍狹窄的標註任務、領域特定的分類頭，或是在幾千個有標籤範例上進行微調，那麼從一個具備廣泛多語言詞彙、且採用為吞吐量而設計的混合卷積架構的 2.69B 預訓練檢查點開始，是一項穩妥的工程決策；而你會略過的後訓練成本，正是你刻意選擇改為付出的代價。

TwIL-LM3-Pro 是正確的選擇，前提是你並不打算進行訓練，而且任務本身已經屬於形式邏輯。蘊含標籤、Lean 陳述形式化、語意剖析與證明評析，正是其整條管線所鎖定的任務；而從一個已經歷合併與強化階段的檢查點出發，能替你省去這其中最難以重現的部分——在提升域內表現的同時，維持留出測試套件的水準。

錯誤在於把「3.66B 後訓練專家」理解為絕對優於「2.69B 基礎檢查點」。它們是同一條生產線上不同階段的產物。

服務他們，還是繞過他們服務

目前這兩款模型都不是 OrcaRouter 目錄中的路由，而且原因各自不同。TwIL-LM3-Pro 採用非商業授權，且沒有託管端點；LFM2.5 2.6B Base 則是微調產物，沒有人會刻意將其作為推論端點來提供服務。路由器真正能發揮價值的地方，是在更高一層，也就是圍繞專門模型的工作：產生並篩選你將用來微調 Base 的訓練資料、擴充你將餵給形式邏輯模型的提示，以及為輸出評分。這些都是文字呼叫，而且它們是透過一個與 OpenAI 相容的端點，以供應商定價對接 200 多個模型，且加價 0%，因此供應商降價當天就會生效，而從一個資料生成模型換到另一個，只需修改設定，而不必再建立第二段供應商關係。

在微調管線中，自動容錯移轉比平常更為重要，因為批次作業在完成 80% 時失敗，會浪費整次執行。在生成模型之間使用單一金鑰，並搭配在供應商發生錯誤時重新發出的備援機制，是比三個 API 整合更小的基礎架構元件。

哪一個，取決於你的意圖

如果你正在訓練，就用 Base。如果你正在對形式邏輯進行推論，而且授權條款允許你使用，就用 TwIL-LM3-Pro。如果你今天就需要一個可遵循指令的小型模型，而這兩項限制都不適用，那就使用 LFM2.5 2.6B 的後訓練同系列模型——也就是 Liquid 實際上為此目的所發布的模型——並把 Base 留給你原本就打算進行的微調。