LFM2.5-2.6B-Base：Liquid AI 最低調的發布，正是微調者真正想要的版本

查看2026年8月5日Hugging Face的計數器，這個差距很難忽視：LFM2.5-2.6B，這是Liquid AI於8月4日推出的智能體端側模型，下載量為47,393次。LFM2.5-2.6B-Base，即所有這些權重所源自的預訓練檢查點，其下載量為151。同一組織、同一架構、同一週，314比1的差距。

基礎檢查點既未外洩，也未被隱藏。它僅在 Liquid 發布文章中的一個括號內出現——「基礎（LFM2.5-2.6B-Base）與後訓練（LFM2.5-2.6B）模型今日已可在 Hugging Face 上取得」——而這就是關於它的全部公開記述。沒有它自己的基準測試，沒有專門章節，也沒有獨立的模型卡。以下所有內容皆直接取自儲存庫——模型卡、config.json、LICENSE 檔案以及 Hugging Face API——外加我們自己進行的計算。凡是來自 Liquid 自己評估的數字，我們都會明確標明；因為對這個特定檢查點而言，最重要的事實就是實際被測量的部分少之又少。

這比腳註所暗示的更為重要。經過後續訓練的模型，你可以透過試用來判斷。基礎檢查點則是一個提議：你得先投入兩週時間和 GPU 預算，才能有所了解，因此這項提議的條件——裡面有什麼、授權用途為何、已評估過哪些面向——就是決策的全部依據。

儲存庫裡實際上有什麼？

九個檔案、一個權重分片，沒有模型程式碼。模型卡的規格清單，經與 config.json：

• 總參數 2.69B，bfloat16，位於單一 5.39 GB 的 model.safetensors。請以此數字為準規劃儲存空間與 VRAM，而非「2.6B」。

• 30 層，混合式。卡片上寫的是 22 個雙門控短卷積區塊加上 8 個 GQA 注意力層。而 layer_types 陣列位於 config.json 中，正好證實了這點：有 22 個 conv 和 8 個 full_attention，注意力層大致每隔三或四個區塊就有一個，而非集中在一起。

• 2048 隐藏宽度、10752 中间维度、32 个注意力头对应 8 个键值头 — 即 4:1 的 GQA 比例 — 并采用绑定的输入和输出嵌入以及 rope theta 值为 10,000,000。

• 128,000 詞元的詞彙表，以及與之搭配的 18 MB tokenizer。Liquid 這一代將詞彙量翻倍，對 2.6B 模型來說是筆可觀的成本：若使用 tied embeddings，光是詞彙表就佔去約 262M 的參數預算，接近整個模型的十分之一。

• 34兆個訓練token。而對這個規模等級而言，這是一段異常長的預訓練，也是我們之所以要查看這個檢查點的唯一最強理由。

• 16 種語言已宣告：英語、阿拉伯語、中文、法語、德語、印地語、印尼語、義大利語、日語、韓語、波蘭語、葡萄牙語、俄語、西班牙語、泰語和越南語。

對於任何規劃長上下文工作的人來說，有一個不一致之處：該卡片宣稱上下文長度為 131,072 個 token，而config.json將max_position_embeddings設定為128,000。Liquid 自己的部落格和文件都說是 128K。這 3,072 個 token 的差異對大多數人來說無所謂，但如果你正在編寫一個將序列打包到所宣稱的最大值的訓練腳本，請相信 config.json 而不是卡片。

架構字串是實際上的重點：model_type 是 lfm2，而類別是 Lfm2ForCausalLM——與 LFM2 隨附的類別相同。LFM2.5 是在現有架構上進行擴展預訓練與新的後訓練，並非全新的架構，因此這裡不需要任何自訂建模程式碼。這就是為什麼 llama.cpp、vLLM、MLX、ONNX Runtime、SGLang 和 LM Studio 都在第一天就支援這個系列，也是為什麼透過 Unsloth 和 TRL 的微調流程無需修補程式即可運作。你確實需要 transformers>=5.0.0。

你拿到的卡片是另一個型號的卡片

開啟基礎模型的儲存庫，第一個標題是"LFM2.5-2.6B"——這是後訓練模型的名稱，而不是你正在看的那個。這不是吹毛求疵；整個頁面讀起來就像是指令卡，只是中間拼接了一段基礎模型的段落，而那三處殘留會耗費你不少時間。

• YAML frontmatter 寫著 base_mode: LiquidAI/LFM2.5-2.6B-Base。 這一行有兩個問題：這個 key 是 Hugging Face 的base_model的拼寫錯誤，而且它把基礎儲存庫指向了自身。這不會造成任何破壞，但你預期會從正確宣告的譜系中出現的模型樹連結，並不會從這裡產生。

• 該儲存庫被標記為對話式，並隨附 chat_template.jinja，因此 Hugging Face 會在從未經過指令微調的檢查點上顯示「Chat template」徽章。模板之所以存在，是因為繼承了分詞器配置，而不是因為權重知道該如何處理它。

• 快速入門片段接著使用該模板。基礎卡片上的 Python 範例呼叫 tokenizer.apply_chat_template，並傳入一個 {"role": "user"}訊息，詢問「什麼是 C. elegans？」——這是讓基礎模型看起來故障的經典做法。將原始的預訓練檢查點（checkpoint）包進聊天輪次中，就會得到漂移、重複、自我延續的文字，而且很容易將其解讀為模型不佳，而非提示格式錯誤。請將此模型作為文字補全器來提示，採用少樣本（few-shot）方式，並使用你可控制的停止序列。

• 變體表格僅列出後訓練系列——即 LFM2.5-2.6B，以及其 GGUF、ONNX 和 MLX 版本。基礎檢查點完全沒有 GGUF 或 MLX 版本，因此若不自行轉換，「今晚就在 LM Studio 中本地執行」根本不在選項之列。

Hugging Face 也指出，沒有任何推論提供者為此儲存庫提供服務。此基礎檢查點在任何地方都沒有託管端點；若想取得其 logits，就必須自行租用 GPU。

不存在的基準測試章節

LFM2.5-2.6B-Base 至今未發布任何評估數字。沒有 MMLU、沒有 MMLU-Pro、沒有 GPQA、沒有 HellaSwag、沒有 ARC、沒有困惑度數值——什麼都沒有，無論是 Liquid 的三個資訊來源（模型卡、發布文章、文件）中的哪一個。對於一個基礎檢查點而言，這種缺席格外刺眼，因為那些知識與推理分數正是你判斷 34T token 的預訓練是否留下了值得微調之物的依據。

確實存在的東西屬於後訓練的姊妹模型，由 Liquid 所報告，且尚未被獨立重現。在 Liquid 自己的評測中，LFM2.5-2.6B 在 OpenClaw 框架內獲得 AIME25 51.87 分、IFBench 59.17 分、Multi-IF 80.07 分、BFCLv4 56.88 分、ToolSandbox 77.83 分及 BrowseComp+ 26.89 分，與 gemma-4-E2B-it (5.1B)、gemma-4-E4B-it (8B)、Qwen3.5-4B (4.7B) 和 Qwen3.5-9B (9.7B) 對比。Liquid 的總結是它在每個指令遵循基準測試中領先，且幾乎在所有工具使用基準測試中領先，而其自己的圖表也坦率地指出了例外：Qwen3.5-9B 在 AIME25 以 56.07 分領先，在 BFCLv4 以 60.13 分領先。速度宣稱也遵循同樣的規則——在 M5 Max 上解碼速度為每秒 220 tokens，在 Ryzen AI Max+ 395 上為 113，在手機上約為 30，記憶體占用低於 2.5 GB，而在單張 H100 上高併發時輸出約每秒 15K tokens——全部皆為供應商自行測量，尚未有任何其他人驗證。

陷阱在於假設那些表現都能轉移。那些分數是四階段管線應用於此檢查點之上的產物：兩輪監督式微調、逐領域教師特化、多領域在策略蒸餾，然後是以 GRPO 在真實測試環境中執行的代理式強化學習。工具呼叫與指令遵循正是該管線植入的行為。取用基礎權重，你等於是從這一切之前開始。你繼承到的是預訓練——語言、世界知識、長上下文能力、高效的混合架構——但你應該假設代理式計分榜上的成績，你一項都沒有繼承。

151次下載不只是偏早——而是背離了該家族自身的模式

Liquid 定期發布基礎檢查點，因此此次發布在性質上並不特別。可衡量的是疏忽。將每個 LFM2.5 基礎儲存庫與其同一天的 instruct 姊妹版本進行比較，會得出一個明確的內部常態——以及一個明確的異常值。

• LFM2.5-230M — 58,676 次下載，相較於其基礎版本的 6,982 次：約 8 比 1。

• LFM2.5-350M — 94,526 對 9,397：約 10 比 1。

• LFM2.5-1.2B — Instruct 版本為 583,914，而基礎版本為 17,867：約 33 比 1。

• LFM2.5-8B-A1B — 171,520 對 3,996：約 43 比 1。

• LFM2.5-2.6B — 47,393 對 151：大約 314 比 1。

部分原因純粹是時間因素；基礎儲存庫於8月1日建立，而指令模型領先了四天，再加上一篇發布文章。但該系列中較舊的基礎檢查點穩定在8比1到43比1之間，因此比其中最差的還高一個數量級，確實是真正的異常，而非新儲存庫的捨入誤差。

這些按讚數透露了更微妙的訊息。基礎儲存庫有 28 個讚、151 次下載——大約每五次拉取就有一個書籤。指令模型則有 232 個讚、47,393 次下載，約每 204 次才有一次。人們標記基礎檢查點是為了日後回訪，而非實際拉取使用。其模型樹中已有兩個社群微調版本和七個量化版本，這正是大量採用湧入之前，領先採用者前緣的樣貌。

「不受限制」並非授權條款所述

Liquid 的發布頁面將此次發布描述為開放權重："可無限制下載、微調與部署。" 但儲存庫中的檔案說法更為狹隘，如果你考慮在這些權重上建構產品，這一段值得讀兩遍。

此授權是LFM Open License v1.0——不是 Apache-2.0，不是 MIT，也不是你可能正在與之比較的大多數小型開放權重模型所使用的條款。直接引用該檔案，第 5 節標題為「商業使用限制」，內容如下：「根據本授權所授予的商業使用權利，係以您或您的法律實體未超過門檻為條件，」接著「任何法律實體超過門檻而對本作品或衍生作品進行商業使用，均不受本協議授權。」第 1 節將門檻定義為「年收入達一千萬美元（$10,000,000）或以上。」

所以實際的解讀是：

• 年收入低於1000萬美元——您獲得廣泛、永久、免版稅的授權，涵蓋重製、衍生著作、散布及再授權，包括商業用途。

• 達到或超過1,000萬美元——商業使用未經本協議授權。不是「需要註明出處」，也不是「需要通知」。你需要聯繫Liquid，這大概就是卡片結尾附上他們銷售團隊連結的原因。

• 衍生作品繼承此項限制。你對此檢查點的微調構成衍生作品，因此你花費一季時間訓練的模型同樣帶有以營收為條件的授權。如果你的公司跨過門檻——或被已跨過門檻的公司收購——你的產品所依賴的條款將在底下改變。

• 符合資格的非營利組織不受此限：此門檻不適用於將作品用於非商業或研究目的的 501(c)(3) 組織或其國外對等機構。一般義務也適用 — 傳遞授權條款、保留署名聲明、標記您修改過的檔案。

這些都不會讓這次發布顯得很小氣；$10M 的門檻幾乎豁免了所有新創公司和研究人員，而且這是發布權重的合法方式。但「無限制」是與授權條款相矛盾的行銷說詞，而這個矛盾正是在這裡造成最嚴重的傷害。微調基礎檢查點是採用模型最昂貴、最難逆轉的方式。那正是最不該發現營收條款的地方。

實際上應該由誰來負責這個檢查點？

Liquid 自己的指引出奇地狹窄，而且值得遵循：其模型卡上寫道，預訓練檢查點是「僅建議用於需要大量微調的任務，例如特定語言（如日語）或特定領域（如醫療）的助理、使用專有資料進行訓練，或實驗新穎的後訓練方法。」這個「僅」字確實有其分量。如果你想要一個能呼叫工具的裝置端代理，經過後訓練的 LFM2.5-2.6B 絕對是更佳的起點，而基礎檢查點只會浪費你一個月的時間。

真正適合選擇它的情況：

• 後期訓練未能充分服務的語言。橫跨 16 種語言的 34T tokens 是扎實的多語言基礎，而 Liquid 已在內部以 1.2B 系列的日語版本驗證了這個模式。針對你的語言持續進行預訓練，再加上你自己的指令微調，就能避免與以英語為中心的後期訓練人格對抗。

• 受監管的垂直領域，具有專有資料。推論時低於 2.5 GB、無需依賴雲端，且在營收門檻以下採用足夠寬鬆的授權，對於資料不能離開裝置的醫療、法律或工業部署而言，是罕見的組合。

• 後訓練研究。Liquid 發布了其配方 — SFT、教師特化、MOPD、agentic RL — 然後將該配方的確切輸入與輸出一併交出。能夠在相同的初始權重上運行自己的方法，並與強大的參考實作進行比對，是罕見且有價值的。

• 蒸餾目標。在筆電上以每秒 220 個 token 的速度解碼的 2.6B 混合模型，是將規模大得多的教師模型壓縮成可出貨成品的理想學生模型。

那最後兩項才是成本真正落下的地方，而且不是 GPU 時數——而是資料。Liquid 的管線依賴教師特化與同策略蒸餾，這表示要重現類似成果的真正先決條件，是從更強的模型產生大量資料，再加上偏好對與可驗證獎勵的 rollout。這在成為一個訓練工作之前，首先是一個多模型工作：你需要在你的領域中比較候選教師，然後從勝出者那裡大量生成。這就是我們自家產品所瞄準的工作部分——OrcaRouter 以 0% 加價將 200 多個模型放在一個 API key 後面，所以你為合成 SFT 集付出的就是供應商的牌價，而不是路由溢價（當供應商降價時，同一天就會反映在我們這邊）；自動故障轉移讓一個二十小時的生成任務不會因為單一供應商的一個糟糕時段而中斷；而且路由 DSL 讓你能把單一提示詞分散給多位教師，並保留最佳答案。要說清楚我們不提供的東西：LFM2.5-2.6B-Base 不在 OrcaRouter 上，也沒有任何推論供應商託管它——你必須自己運行這些權重。我們對教師有用，而非對學生。

{{1}}無論你推出什麼產品，這個區分都值得銘記在心。{{/1}} {{2}}Liquid 的文章主張，本機端代理讓推論變得免費，並把逐 token 成本從限制條件中移除；但這僅對邊際 token 成立，對總帳單並非如此——你已經在硬體上預付了這筆費用，而且 2.6B 模型仍有其上限。{{/2}} {{3}}Liquid 自己也這麼說，建議不要將這一系列用於程式碼繁重或知識密集的代理型工作。{{/3}} {{4}}長久可行的模式是：以微調過的本機模型在裝置端處理高流量的常見路徑，並將少數困難案例轉交到經由 API 存取的尖端模型；如此既能保有隱私與延遲上的優勢，又不會假裝 2.6B 參數什麼都能做。{{/4}}

從這些權重到可用成果的途徑

這篇發布文章對這一點隻字未提，但基礎卡默默承載了整個儲存庫中最實用的東西：七個可直接執行的 Colab 筆記本，涵蓋了基礎檢查點所需的完整流程階段。{{1}}其中兩個是繼續預訓練——一個用於文字補全，一個用於翻譯——{{/1}}{{2}}這一步只有從基礎權重出發才有意義，也是沒有人會寫教學的步驟。{{/2}}{{3}}其餘的涵蓋了透過 Unsloth 和 TRL 進行的監督式微調、{{/3}}{{4}}透過 TRL 進行的 DPO，{{/4}}{{5}}以及同時透過兩者進行的 GRPO。{{/5}}{{6}}如果你不想自己組裝訓練堆疊，Liquid 也提供 LEAP Finetune 作為獨立的訓練架構。{{/6}}

對照此模型的形狀閱讀 Liquid 的微調文件，實際的順序看起來是這樣的：

• 在訓練任何東西之前，先把它當作補全器來提示。忽略卡片上的聊天模板。使用少樣本（few-shot）、原始文字，以及你自己的停止序列。這就是你判斷預訓練是否已涵蓋你的領域和語言的方法，這決定了你是需要繼續預訓練，還是可以直接跳到 SFT。

• 唯有在新增知識或語言時，才繼續進行預訓練。這是成本高昂的做法——屬於語料庫規模，而非範例規模——也是經過後續訓練的姊妹模型確實無法提供給你的唯一一件事。

• 然後使用 LoRA 進行 SFT，使用 500 到 5,000 個範例。Liquid 自己的指引是品質與分佈優於數量，且範例應與生產輸入匹配。在 2.6B 規模下，LoRA 執行時間很短：文件指出在單張現代 GPU 上，1.2B 的運行只需數分鐘到數十分鐘，因此這個規模仍然是當天下午即可完成的迭代循環。

• 在訓練之前，先凍結一個留出集（held-out set）。 這說法很直接，但對於這個檢查點（checkpoint）尤其值得重複強調，因為沒有已發表的基準可以對照——你的評估集是唯一能拿出的數字。

• 偏好或強化學習階段應放在最後，且僅當行為本身是問題時才進行。 DPO 和 GRPO 配方存在於該系列中，但它們是對已能回答問題的模型進行微調；在 SFT 尚未落地前就急著使用它們，正是基礎檢查點專案停滯不前的常見原因。

請注意這份清單上沒有的東西：這裡不需要自訂核心、修補過的訓練器或建模檔案。因為 LFM2.5 重用了 LFM2 的架構，基礎檢查點可以直接放進標準技術堆疊，而這個專案的全部成本，就在於你為它所建立的語料庫和評估集。

什麼會改變局面

有三件事值得關注，對 Liquid 來說，解決這些事情的代價都很低，但今天沒有一件獲得解決。

第一是基礎評測。在預訓練檢查點上的一個 MMLU-Pro 或 GPQA 分數，能告訴微調者的資訊，比發布貼文中所有代理型基準加起來還多；而投入了 34T tokens 的事實，只會讓它的缺席更啟人疑竇，而非減輕。第二是模型卡本身——一個基礎倉庫，其標題寫的是另一個模型，其快速入門指南對非聊天模型套用了聊天模板，而且其 frontmatter 拼錯了 base_model——這是十分鐘就能修好的問題，能避免人們在說明文件有誤時，得出權重損壞的結論。第三是 LFM2.5 技術報告。引用區塊指向 arXiv 2511.23404，那是 LFM2 技術報告（2025 年 11 月）；2.5 世代自己的論文還沒發表，所以那 34T tokens 背後的預訓練資料混合比例仍未公開。

在那之前，誠實的總結是：這是一個規格明確、訓練充分、架構高效的2.6B基礎模型，目標受眾異常清晰，然而發布時未附任何評測數據，且採用設有營收上限的授權條款；到目前為止，幾乎沒有人把它從盒子裡拿出來實際使用過。如果你正好屬於這張模型卡所描述的受眾，那麼它值得你花費GPU時間——而且你將成為全球最早知道它實際表現如何的少數人之一。

值得回答的問題

這個 checkpoint 是 LFM2.5-2.6B 後續訓練所用的同一個，還是獨立的預訓練運行？

該卡說明 LFM2.5-2.6B-Base「是預先訓練的純文字檢查點，用於建立所有 LFM2.5-2.6B 變體」，因此它是已發布管線的實際輸入，而非平行或精簡版釋出。這正是它對後續訓練研究有價值的原因：你的方法與 Liquid 的四個階段從完全相同的權重出發，因此兩者之間的比較具有意義。值得注意的是，基礎儲存庫於 8 月 1 日建立，最後修改時間為 8 月 4 日，即發布當天——在假設你早期下載的檔案就是最終發布的檔案之前，請先檢查提交歷史。

我可以微調它並出售結果嗎？

如果你的法律實體的年度收入低於1,000萬美元，是的——LFM1.0 授權涵蓋衍生作品的商業使用，但須保留授權與歸屬聲明的完整性，並標記已變更的檔案。達到或超過該門檻時，對模型本身或其任何衍生內容的商業使用將不在授權範圍內，需要與 Liquid 另行安排。該門檻是基於你的實體收入，而非模型本身或其產生的收入，因此同一個微調模型可以授權給一家公司，卻不授權給另一家；而一家公司若跨越該門檻，原先享有的授權也不得繼續保有。

為什麼不直接微調後訓練的 LFM2.5-2.6B 呢？

對大多數專案來說你應該這麼做，Liquid 的模型卡實際上也是這樣說的。從基礎檢查點開始的理由在於，當後期訓練對你而言是阻力而非助力時：針對新語言或專業語料庫進行大量持續預訓練，本來就容易損害指令微調的行為，而且由 SFT 和 RL 深植的拒絕模式、工具呼叫慣例與回應風格，既難以移除，也容易與之衝突。如果你要新增知識或語言，就從基礎模型開始；如果你只是要在邊際調整行為，就從後期訓練模型開始，保留別人已經付費完成的四個階段工作。