LFM3-1.7B-Base 與 LFM2.5-2.6B-Base：更少參數、更少 Token、更多上下文

算術方向反了。LFM3-1.7B-Base 於 2026 年 10 月 26 日發布，比 LFM2.5-2.6B-Base 小 36%；後者是 Liquid AI 於 2026 年 8 月 4 日發布的模型——1.73 億? 等等，應該是 17.3 億個參數對上 26.9 億個參數。它訓練所用的 token 也較少：22 兆對上約 34 兆。若按業界通常用來排名預訓練模型的這兩個數字來看，較新的檢查點理應較差。Liquid 的主張正好相反，至少對建構於其上的後訓練模型而言是如此；而對任何要選擇主幹模型來微調的人來說，有趣的問題是：這些差異中哪些是真的，哪些是用基準測試套件說出來的故事。執行這項比較應該花費的是運算資源，而不是第二份合約。0% 加價 OrcaRouter 以 0% 加價原樣傳遞供應商定價。

這是同一個家族內的比較，因此顯得格外單純。相同的廠商、相同的授權家族、相同的 128,000 個 token 詞彙表、相同的 2,048 隱藏層維度，以及相同的 base-to-base 定位。這兩個檢查點在架構、資料量、上下文長度，以及主幹中已內建的後訓練程度上有所不同。其餘幾乎所有條件都保持不變。

差值，逐維度來看

• 參數 — LFM3-1.7B-Base 為 1.73B，相較之下 LFM2.5-2.6B-Base 為 2.69B。減少了 35.7%，這正是 Liquid 發布貼文中「參數少 35%」這句話的由來。

• 層數——24 對 30。較新的模型不僅更窄，也更淺。

• 層混合 — LFM3 有十三個門控短卷積、五個滑動視窗注意力區塊與六個全注意力區塊；LFM2.5 則有二十二個卷積與八個全注意力區塊，且不設滑動視窗層級。

• 注意力——LFM3 有十六個查詢頭和四個鍵值頭，LFM2.5 則有三十二個和八個。兩者都保持頭部維度 128 與隱藏大小 2,048。

• 前饋網路寬度 — LFM3 為 7,680，而 LFM2.5 為 10,752。參數縮減大多實際上就落在這裡。

• 卷積快取 — LFM3 為七個，而 LFM2.5 為三個，並新增了 256 個 token 的滑動視窗。

• 上下文 — 262,144 個 token，對比 128,000。較新的檢查點將其翻倍。

• 預訓練詞元 — 22 兆對上約 34 兆，其中較新一輪的最後 3.5 兆用於精選的中期訓練資料，包括代理軌跡與工具呼叫。

• 成品 — LFM3-1.7B-Base 僅以 BF16 safetensors 形式提供，大小為 3.46 GB。LFM2.5-2.6B-Base 提供 Safetensors 以及 GGUF、ONNX 和 MLX 版本，量化後可在低於 2.5 GB 的記憶體中執行，並支援 Transformers、vLLM、SGLang、llama.cpp 和 MLX。

參數去哪了

縮減並非平均分佈，這對任何估算微調成本的人來說都很重要。兩個模型中的嵌入都是權重綁定的，而且詞彙表完全相同，皆為 128,000 個 token，因此嵌入矩陣不變。隱藏大小維持不變，為 2,048。節省來自三個地方：少六層、注意力頭數減半，以及前饋區塊窄了約 29%。

縮窄前饋區塊是縮小 Transformer 最便宜的方法，因為該區塊佔了每一層的大部分參數。將注意力頭減半會同時減少鍵值快取與權重，這就是為什麼一個上下文長度加倍的模型，仍可被描述為在 4 位元下約 1 GB 就能容納。代價是容量：較窄的 MLP 能儲存事實關聯的空間較少，而較少的頭數也讓模型可運用的獨立注意力模式變少。Liquid 的論點是，更好的資料與更好的層組合帶來的補償遠超過這些損失。這個論點是可檢驗的，而截至發表時，公司外部還沒有人檢驗過它。

上下文來自哪裡

將上下文從 128K 加倍到 256K，同時不讓注意力成本加倍，關鍵在於不採用全域注意力。LFM3 的堆疊做法是：將二十四層中的五層改為 256 個 token 的滑動視窗、十三層改為卷積，只留下六層能看到整個序列。該配置在全域注意力層上還帶有 0.5 的部分旋轉因子，將旋轉嵌入套用到每個頭維度的一半；這些層的 rotary theta 為一百萬，而滑動層則為一萬。

Liquid 的發布文章給出了一個具體數字，說明這能帶來什麼：在 128K token 時，文字模型的 KV 快取為 1.6 GB。對 LFM2.5-2.6B-Base 而言，並未公布對應數字。因此，這項比較是方向性的，而非精確的——較新的架構旨在以更少記憶體容納更長的上下文，而廠商自家的數字是唯一可取得的測量值。

為什麼更少的 token 才是有趣的主張

從三十四兆個 token 降至二十二兆個 token，等於在資料層面將預訓練算力減少 35%，而這與大多數模型世代的方向相反。常見的說法是資料更多、參數更多、模型更好。Liquid 的說法則是兩者都更少，並採用全新架構與資料組合，加入科學論文、儲存庫層級程式碼、數學，以及更廣泛的知識來源。

3.5 兆個 token 的中期訓練階段，是讓這個檢查點有別於單純預訓練的地方。它使用精選、品質更高的資料，其中代理軌跡與工具呼叫所占比例更高，也是在這個階段擴展上下文視窗。這個階段也是基礎模型帶有聊天模板的原因：中期訓練資料被格式化為對話，包含帶有思考軌跡與不帶思考軌跡的版本。

這些都無法從外部驗證。詞元數量是自行回報的，資料組成並未公開，也沒有任何消融實驗顯示哪一項改動帶來了哪一項增益。這個說法看似合理——過去兩年來，資料品質屢屢勝過單純的資料量——但看似合理並不等於經過實測。

逐項對照比較能釐清什麼

本頁可以確定規格、成本和相容性，但無法確定品質，因為這兩個檢查點都沒有公開的基準測試結果。Liquid 未發布 LFM2.5-2.6B-Base 的評估，也未發布 LFM3-1.7B-Base 的評估。兩份模型卡都建議將該檢查點用於大量微調，並引導讀者另尋聊天用途的資源。

這個系列中唯一的品質證據，是那對經過後訓練的模型。Liquid 回報 LFM3-1.7B 在其自家測試套件上平均得分 49.37，相較之下 LFM2.5-2.6B 為 31.55，而較新的模型使用的參數少了 35%。這是很大的差距，而且這是廠商數據、測於廠商自選的測試套件，比較的是兩個不只在主幹上不同、在後訓練上也不同的模型。這能證明 LFM3 的配方能產出更好的 instruct 模型。這不能證明其基礎檢查點是更好的起點，因為其上疊加的後訓練可能就足以解釋全部差距。

給所有 LFM2.5 使用者的遷移說明

這兩個檢查點共用詞彙表大小、隱藏層大小與分詞器家族，這讓遷移看起來比實際上更容易。它們並不共用模型程式碼：LFM2.5 會以 Lfm2ForCausalLM 載入，LFM3 則以 Lfm3ForCausalLM 載入，兩者都透過自訂程式碼並搭配 trust_remote_code=True。為其中一個撰寫的訓練腳本若未變更模型類別，就無法載入另一個；而兩者的聊天範本在處理思考軌跡的方式上也不同。

更大的實務差異在於封裝形式。LFM2.5-2.6B-Base 提供 GGUF、ONNX 與 MLX 版本，並可在 llama.cpp、vLLM、SGLang、Transformers 與 MLX 下執行。LFM3-1.7B-Base 則以單一 BF16 safetensors 檔案形式發布；量化版與跨平台版本是為後訓練的 LFM3-1.7B 提供，而非針對基礎檢查點。若你的流程依賴 GGUF 產物，你就得自行轉換並驗證結果。

微調支援則是另一端的平衡力量。LFM3-1.7B-Base 連結了用於監督式微調與持續預訓練的 TRL notebook，而文件則說明了從那裡接續往下的路徑。較小的檢查點、256K 上下文，以及代理式中期訓練，全都正好瞄準那些 notebook 所展示的領域調適類型。

要從哪個主幹開始？

若符合以下情況，就從 LFM3-1.7B-Base 開始：你正在開始新的微調、你的任務能受益於長上下文，而且你可以使用 Transformers 以 BF16 作業，或自行轉換權重。35% 的參數量減少在單一 GPU 訓練執行上是實實在在的節省，加倍的上下文是真正的能力提升，而聊天範本則縮短了監督階段。

如果你已經有一套可運作的流程，就繼續留在 LFM2.5-2.6B-Base，前提是你依賴 GGUF 或 ONNX 產物，或需要一個背後有一年社群工具鏈支援的檢查點。較新的模型才推出三天。它的 instruct 版本已有量化版本，並在 vLLM、SGLang、llama.cpp、Ollama、LM Studio、MLX 和 ONNX Runtime 中於第一天就獲得支援，但 base 檢查點並沒有，而這個落差就是搶先採用的實際成本。

如果不確定，就實際執行實驗，而不是只閱讀行銷文案。 從你自己的資料中取一小部分，對兩個主幹分別執行相同的持續預訓練配方，並在開始前建立的留出集上進行評估，步數要相同。這只需要幾小時的 GPU 時間，卻能回答任何供應商表格都無法回答的問題。當兩個微調模型都存在時，將兩者放在同一個端點之後：OrcaRouter 的 路由 DSL 可以在它們之間分流流量，而自動容錯移轉意味著一次失敗的實驗不會變成糟糕的生產日。該平台以 0% 加價傳遞供應商的列表價格，因此執行測試的成本就是運算成本，而不是另一份合約。

值得關注的數字

能讓這件事定論的說法，不是再一個平均值，而是一項基礎模型評估——任何基礎模型評估——由 Liquid 或第三方發表，並在相同的微調配方後比較 LFM3-1.7B-Base 與 LFM2.5-2.6B-Base。在這樣的評估出現之前，世代差異在架構與設定中有記錄，在 token 數量上看似合理，但在真正關鍵之處仍未獲證實。較新的檢查點更小、上下文更長，也更適合打包用於訓練。它是否更好，是該儲存庫沒有回答的問題。