LFM3-1.7B-Base：儲存庫怎麼說，以及 Liquid AI 尚未說明什麼

Liquid AI 新系列中最具關鍵影響力的檢查點，卻是可讀資訊最少的那一個。 LFM3-1.7B-Base 是一個 17.3 億參數的純文字預訓練模型，並於 2026 年 10 月 27 日成為所有後訓練 LFM3 模型建構時所依據的主幹——文字模型、視覺模型、音訊模型、全模態模型，以及兩個決策模型。系列發布文章只用一個子句提到它。沒有為它單獨發布公告，沒有基礎模型基準測試表，也沒有針對它的新聞報導。與此同時，該儲存庫對於這個檢查點是什麼、用途為何異常明確，這使得這次發布容易描述，卻難以誇大。 不會對模型供應商收取的費用額外加價。 供應商定價 供應商價格變動會在同一天反映到你的帳單。

以下內容將這兩件事區分開來。前半部分的所有內容都來自模型卡、設定檔、授權條款文字，或 Liquid 自家的發布貼文，今天即可查證。後半部分則是權重上線三天後仍真正未知的部分。

兩個儲存庫、一篇發布文章，以及十二小時的差距

這些時間戳記訴說了一場發布的故事：它先公開發生，之後才在行銷上發生。後訓練的LFM3-1.7B儲存庫建立於 2026 年 10 月 23 日。基礎儲存庫建立於 10 月 26 日 16:28 UTC，其模型卡最後修改於 10 月 27 日 04:15 UTC——不到十二小時後。部落格文章〈Introducing LFM3: Every Modality for Specialized Intelligence〉標註的日期是 10 月 27 日。等到公司外部任何人能讀到規格說明時，權重早已在 Hugging Face 上放了一天。

這個順序值得直接說明，因為它是這裡最接近「低調發布」的事情。Liquid 確實宣布了這個系列，而公告中指名 LFM3-1.7B-Base 是其他六個模型訓練所依據的檢查點。該公司沒有做的，是單獨以自己的名義宣布這個基礎檢查點——沒有獨立貼文、沒有針對基礎模型的評估，除模型卡中的一段話之外也沒有任何定位。系列獲得了正式發布。主幹得到的則是一個儲存庫，以及一個指向該系列的指引。

儲存庫裡有什麼

這張模型卡片很精簡，而且難得地在基本資訊上是完整的。一個 3.46 GB、bfloat16 格式的 model.safetensors 檔案。一個擁有 128,000 個 token 詞彙量的 tokenizer。模型程式碼以自訂 Python 形式隨權重一同提供，需以 trust_remote_code=True 載入，而非透過已合併的上游 Transformers 版本。授權條款是 LFM Open License v1.0，與 Liquid 自 LFM2 以來採用的一系列條款相同。

• 參數 — 1.73B，稠密，每個 token 都會讀取每一個參數。

• 層 — 24：十三個閘控短卷積區塊、五個滑動視窗注意力區塊、六個全注意力區塊。

• 上下文 — 262,144 個權杖，輸入加輸出。

• 注意力幾何 — 隱藏大小 2,048，十六個查詢頭，四個鍵值頭，頭維度 128。也就是四比一的分組查詢注意力，而非 LFM2.5 的八比一。

• 局部視窗 — 256 個 token，搭配大小為 7 的卷積快取。這是逐層注意力設定，而非上下文長度；當該架構在發布前一天於某個引擎的 pull request 中首次曝光時，還引發了一小波誤報。

• 詞彙與語言 — 128,000 個詞元，列出十六種語言：英文、阿拉伯文、中文、法文、德文、義大利文、日文、韓文、葡萄牙文、西班牙文、越南文、泰文、印尼文、印地文、俄文、波蘭文。

• 記憶體 — 根據 Liquid，4 位元精度下約 1 GB，出貨時採用 BF16 則為 3.46 GB。

在你引用某個尺寸之前，有一個小不一致值得知道。Hugging Face 的側邊欄會把這個模型四捨五入成「2B params」，而模型卡的表格則寫 1.73B。檔案本身說明了一切：3.46 GB 的 bfloat16 以每個參數兩個位元組計算，就是 17.3 億個參數，所以側邊欄的標籤只是四捨五入的慣例，不是第二份規格。撰寫本文時，該儲存庫顯示過去一個月有十五次下載、八個讚——這是一個已發布、曾被啟動文章連結、但尚未被任何人採用的檢查點概況。

架構，不含圖示

這套設計最適合從成本預算的角度來理解。在長上下文中，完整注意力是 transformer 最耗費成本的部分：每個 token 都會與其他所有 token 進行比較，而成本會隨序列長度的平方成長。Liquid 的三混合堆疊中，二十四層只有六層用於這項運算。十三層是閘控短卷積，以每個 token 固定成本在局部混合資訊；五層是滑動視窗注意力區塊，一次只看 256 個 token。網路中有三分之二完全不會執行全域注意力運算。

這是 Liquid 自 LFM2 以來一直押注的同一種賭注，而且推得更遠。LFM2.5-2.6B-Base 採用三十層，拆分為二十二個卷積層與八個完整注意力區塊，且沒有滑動視窗層級。LFM3 在堆疊中的五個位置以一個滑動注意力區塊取代一對卷積層，將卷積快取從三提高到七，並加入設定中出現的三明治正規化與部分旋轉設定。那個特定的取捨是否提升品質，只有評估能回答，而截至發表時，尚無基座模型評估能回答這個問題。設定所確立的是，256K 上下文並非透過將注意力擴展到 256K 來達成；而是透過讓堆疊的大部分保持局部來達成。

基礎模型隨附一個聊天範本

這是最可能讓任何下載該檢查點、期待原始文字補全的人感到困惑的細節。LFM3-1.7B-Base 包含完整的聊天範本，而模型卡指出，中期訓練包含了帶有與不帶有思考軌跡的聊天資料，且皆使用與後訓練模型相同的範本格式化。呼叫 apply_chat_template 時，推理預設為啟用：回應會從思考區塊內開始，除非你傳入 enable_thinking=False；這會預先填入空的軌跡，並要求直接回答。

所以它的行為有點像指令模型，卻被記錄成完全不同的東西。模型卡本身的建議毫不含糊：LFM3-1.7B-Base「僅建議用於需要大量微調的任務，例如語言特定或領域特定的助理、以專有資料進行訓練，或實驗新穎的後訓練方法。」至於聊天、工具呼叫與代理，它指向 LFM3-1.7B。模板之所以存在，是因為中期訓練資料就是那樣格式化的，而且微調會繼承它——不是因為該檢查點曾針對對話進行調校。任何把模板當成就緒訊號的人，都會對輸出感到失望，而模型卡在他們開始之前就已經這麼說了。

人們會引用的數字並不是這個模型的數字

發布貼文附有一張內容相當可觀的基準測試表，但其中幾乎沒有一項適用於本文所討論的檢查點。49.37 的標題平均分屬於經後訓練的模型 LFM3-1.7B，是在 Liquid 自家測試套件上測得。比較列——LFM2.5-2.6B 為 31.55、MiniCPM5-2B 為 39.19、Gemma 4 E4B 為 31.74、Qwen3.5-4B 為 39.27、Qwen3.5-9B 為 47.24——是後訓練模型對後訓練模型的比較。SWE-bench Verified 上的 43.40 與 LiveCodeBench v6 上的 73.46，同樣是經調校模型的分數。

有兩項說法在一般閱讀時會被附會到基礎檢查點上，但不應該如此。第一是「參數少 35%」——那是 LFM3-1.7B 勝過 LFM2.5-2.6B，是關於後訓練配對的說法，不是基礎對基礎的結果。第二是 LFM3「媲美 Gemma 4 12B」的說法。那句話講的是視覺模型 LFM3-VL-2B，涵蓋 62 項視覺基準測試。它完全沒談到文字基礎檢查點，而該檢查點根本沒有已發表的評估。沒有基準測試表的基礎模型並不罕見——Liquid 也刻意未發表 LFM2.5-2.6B-Base 的基準測試——但這樣的缺席意味著，目前關於這個檢查點的所有品質主張，都是關於它所產出模型的主張。

訓練，以及真正獨具特色的部分

Liquid 表示，該檢查點在兩個階段中共處理了 22 兆個 token。主要預訓練階段相較於 LFM2 調整了資料混合比例，加入更多科學論文、儲存庫層級的程式碼、數學，以及更廣泛的知識來源。最後 3.5 兆個 token 屬於中期訓練階段，使用經過篩選、品質更高的資料，其中代理軌跡與工具呼叫所占比例更大，而上下文視窗也是在該階段擴展至 256K。

不尋常之處不在於 token 數量，而在於代理式資料進入了基礎模型，而不只是進入後訓練階段。多數廠商會把工具呼叫軌跡保留給指令微調階段。Liquid 則把它們放進主幹，接著在其上以 SFT、混合式強化學習、多領域同策略蒸餾與代理式強化學習，後訓練了六個不同的模型。對於一個旨在跨模態共用單一主幹的模型家族而言，這是連貫的策略，這也是為什麼基礎檢查點帶有聊天模板。這是一項無法從外部查核的訓練方法主張，而且不存在獨立重現。

你今天可以用它做什麼

這張卡片連結了兩個 TRL notebook，一個用於監督式微調，從雜亂文件中擷取結構化 JSON；另一個用於在新語言上進行持續預訓練，並以原始文字中的土耳其語為例。兩者都是針對 LFM3-1.7B 撰寫，且只需變更單一 model_id 以指向基礎檢查點。文件頁面涵蓋微調流程的其餘部分。指令模型具備完整的執行階段變體組合——適用於 vLLM、SGLang 和 Transformers 的 BF16；適用於 SGLang 的 FP8 和 NVFP4；適用於 llama.cpp、Ollama 和 LM Studio 的 GGUF；適用於 Apple silicon 的 MLX；以及 ONNX Runtime。基礎檢查點只有一個產物：BF16 safetensors 檔案。沒有 GGUF、沒有 MLX 組建、也沒有量化版本。如果你想在手機上執行，轉換得由你自己進行。

如果你以提供模型服務為生，這適合放在哪裡

預訓練檢查點並不是聊天端點，而這一點值得具體說明。撰寫本文時，LFM3-1.7B-Base 並未出現在 OrcaRouter 的目錄中，而且基礎模型會是個奇怪的路由對象：它沒有可供路由的指令遵循能力。對路由器而言，有用的起點要晚一步，也就是在微調版本存在之後。OrcaRouter 將超過 200 個模型置於同一個 API 之後，對供應商定價維持 0% 加價，並提供自動容錯移轉與路由 DSL，因此領域微調的 LFM3 檢查點可以與更大的通用模型並列，進行比較或容錯移轉，而無需第二次整合。模型融合——由一組模型共同回答——是另一種選項，當一個 1.73B 的專家模型擅長某件事，而你需要第二意見時。這些都不需要基礎檢查點本身被託管在任何地方。

還有什麼仍未確認

• 基礎品質。沒有基準測試表，沒有評估工具輸出，也沒有在任何任務上與 LFM2.5-2.6B-Base 進行比較。

• 獨立驗證。 尚無第三方實驗室公布基礎模型或微調模型的執行結果。發布文章中的每個數字都是 Liquid 自己的。

• 上游 Transformers 支援。該儲存庫使用自訂建模程式碼與 trust_remote_code。這在推出時很正常，日後卻會成為維護成本。

• 基礎模型如何提供服務。 發布文章指出，基礎模型與後訓練模型可在 Hugging Face、Liquid Playground 和 Liquid API 上取得。API 如何處理未微調的基礎檢查點並未說明，且未公布其定價。

• 授權邊界情況。LFM Open License v1.0 在年營收低於 1,000 萬美元時可免費商業使用；超過該門檻則適用商業授權。授權文本是公開的，但它如何處理以基礎模型訓練而成、隨後投入商業服務的衍生模型，這是律師的問題，而非模型卡能回答的。

看什麼

下一個有意義的訊號不是另一則公告——而是對後訓練模型的第一份獨立評估，以及第一個公開微調、並說明以基礎檢查點訓練起來是什麼樣子的案例。Liquid 自己的說法正好邀來這項檢驗：一個 1.73B 主幹產出了六個模型，並宣稱勝過 2.69B 的前代，這要嘛是真正高效的架構，要嘛是一套精心挑選的基準測試；只有外部實測才能把兩者分開。在那之前，整個故事就是這個儲存庫：一個 3.46 GB 的檔案、一份清楚的規格、一個並非邀請的聊天範本，以及一份在營收數字逼近之前值得一讀的授權條款。