介紹 LFM3：六個 2B 模型、一個骨幹，以及一個並非上下文的 256 Token 視窗

Liquid AI 的 LFM3 系列於 2026 年 10 月 27 日問世，推出的是六個 2B 等級的檢查點，而非單一旗艦模型：LFM3-1.7B 用於文字、LFM3-VL-2B 用於視覺、LFM3-Audio-2B 用於語音、LFM3-Omni-2B 則一次處理所有模態，另外還有兩個決策模型，d1-2B與d1-omni-2B。這六個模型全都分支自同一個預訓練主幹，LFM3-1.7B-Base，Liquid 也一併發布了這個主幹。該公司的定位是「專業化智慧」——刻意拒絕推出小型通用模型，以免在錯誤的軸線上競爭。

公告發布後不到一天，技術文章裡的一個數字就已經被誤讀了。LFM3 的架構列出帶有 256 個 token 視窗的滑動視窗注意力層。那是每一層的注意力幾何結構，不是模型的上下文長度。文字模型可接受 256K 個 token 的上下文。只匆匆掃過層級表格、就断定 Liquid 已推出一款記憶體只有 256 個 token 的 2026 年模型的人，腦中想的是錯誤的模型；在本文其他內容說得通之前，這一點值得先更正。

三混合架構實際上究竟是什麼

LFM3 以三種層類型堆疊於 24 層主體中，取代 LFM2 的雙向混合。其中十三層是閘控短卷積，五層是視窗大小為 256 個 token 的滑動視窗注意力，六層是完整的全域注意力。卷積核從 3 擴大到 7。還附帶三項較小的變更：一個 sigmoid 閘，會獨立縮放每個注意力頭的輸出；全域層中的部分旋轉嵌入，只旋轉每個注意力頭中頻率最高的那一半；以及三明治正規化，會調控每個區塊的輸入與輸出。

這個押注是：短卷積能低成本承載大部分局部結構，稀疏注意力處理中距離，而一小層全域注意力把整個 256K 視窗縫合起來。這就是為什麼 KV 快取能小到足以發揮作用——Liquid 回報，在相同測量下，完整的 128K token 快取為 1.6 GB，而 Qwen3.5-4B 為 4.3 GB、MiniCPM5-2B 為 5.6 GB。文字模型本身在 4 位元精度下約占 1 GB。

訓練分為四個階段：22 兆預訓練 token、3.5 兆 token 的中期訓練階段（大量著重代理軌跡與工具呼叫，並將上下文延伸至 256K）、1.75 兆 token 的監督式微調，然後是混合強化學習，結合來自六位專家教師的多領域同策略蒸餾。詞彙表為 128K token，與 LFM2.5-8B-A1B 共用，且建構目標是比前代更有效率地將非拉丁文字分詞。

六個模型，以及它們的上下文各自流向何處

Liquid 明確表示，這些是並列的同級模型，而非分層等級。每個模型都採用相同的骨幹，並針對不同的輸出形態進行後訓練。

• LFM3-1.7B — 稠密文字與代理模型，1.73B 參數，256K 上下文，原生工具呼叫與結構化輸出。

LFM3-VL-2B — 視覺語言模型，1.9B 參數，搭載自家視覺編碼器；Liquid 表示其所需運算量約為 SigLIP2 的三分之一。

• LFM3-Audio-2B — ASR、TTS、語音翻譯與音訊理解，採用自家研發的編碼器加上 LiquidCodec。

• LFM3-Omni-2B — Liquid 首款全模態模型：輸入文字、圖像、影片與音訊，輸出文字或語音。

• d1-2B — 一個由視覺分支建構的決策模型，能在單次前向傳遞中回答結構化問題，並以經校準的機率作答，而非自由形式的文字。

• d1-omni-2B — omni 分支上相同的決策介面。

這些上下文視窗並不統一，而這正是大多數發表報導漏掉的細節。Liquid 只公布了文字模型與基礎模型的視窗——256K，輸入與輸出合計——其餘四個模型則完全沒有公布。無論是發布公告還是模型文件，都沒有說明 LFM3-VL-2B、LFM3-Audio-2B、LFM3-Omni-2B 或兩個決策模型的上下文長度。第三方報導曾流傳視覺模型為 128K、全模態模型為 32K，這些數字很可能正確，但截至 10 月 28 日，它們並未出現在 Liquid 自己的頁面上。如果你正打算打造一個既能讀長文件、又能看截圖的代理，目前根本無法從第一方文件推估全模態模型的上下文長度。這個缺口值得被明確指出，而不是從某個部落格補上——那個部落格也是從別處補來的。

基準測試表，如實解讀

以下每一項效能數字都是 Liquid 自家的數據，是在 Liquid 自家的測試框架上產生的，而且沒有任何一項經過獨立重現。截至 2026 年 10 月 28 日，Artificial Analysis 上沒有 LFM3 的條目——沒有 Intelligence Index，也沒有來自中立第三方的速度或延遲測量。這一點在這裡比平常更重要，因為發表時所倚賴的比較是同一測試框架下的比較，而這種比較會美化該測試框架所針對調校的模型。

LFM3-1.7B 在 Liquid 的 27 項基準平均中得分 49.37。該公司自家的 LFM2.5-2.6B 在同一組基準上得分 31.55，這正是「參數少 35%」說法的由來。有意思的不是平均數那幾列：

• 工具使用 — BFCL V4 71.39、ToolSandbox 80.36、τ³-bench 68.01、MCP-Atlas 32.57。

• 代理式網路 — WebArena-Verified 38.42、AutomationBench 41.29、BrowseComp-Plus 37.00、LiveClaw 45.60。

• 代理式編碼 — SWE-bench Verified 43.40、SWE-bench Multilingual 23.00、Terminal-Bench 2.1 為 12.92。

• 指令遵循 — IFEval 96.66、IFStruct 93.72、IFBench 73.03、Multi-IF 89.10。

• 知識 — GPQA Diamond 63.37，HLE 在無工具下為 7.17，使用工具時為 13.90。

• 長上下文 — RULER 128K 65.56、AA-LCR 52.83。

若從整體輪廓而非總分來看，這份側寫是連貫的：指令遵循能力極強、單輪工具呼叫表現相當不錯，但一旦任務需要多個連續步驟，表現便急遽下滑。Terminal-Bench 2.1 的 12.92 與 SWE-bench Multilingual 的 23.00，並不是能賴以打造自主編碼代理的數字。Liquid 並未掩飾這一點——模型卡引導使用者避開複雜推理與多步驟編程，對一家供應商而言，這是發表當天異常直白的定位表述。

效率宣稱則是這套推銷說法的另一半。Liquid 表示，在 Q4_0 與 32K 上下文下，LFM3-1.7B 在三台測試裝置上都是最快的模型，比第二名的競爭者快 1.8 倍到 2.8 倍，同時記憶體占用最低。在單一 NVIDIA B300 上以 BF16 搭配 SGLang，它在 1,024 個並行請求下每天可處理 36 億個 token。該公司還以 Enron 電子郵件存檔為壓力測試場景，平行執行超過 300,000 個 LFM3-1.7B 代理。這些是廠商提供的數字，未經審計，但這類數字很難悄悄灌水。

授權與運行成本

權重以 BF16、FP8、NVFP4、GGUF、MLX 與 ONNX 版本形式發布於 Hugging Face，並在 vLLM、SGLang、Transformers、llama.cpp、MLX、ONNX Runtime、Ollama 與 LM Studio 中獲得首日支援。授權條款為 LFM Open License v1.0：年營收低於 1,000 萬美元可免權利金商用，超過此門檻則需另行簽訂協議。決定 LFM3 對某家公司是否免費的界線，是這個門檻，而非參數量。

Liquid 也營運一套託管 API，而這方面的公開紀錄比發表時所暗示的還要薄弱。文件列出了模型 ID 與 256K 的輸入加輸出上限，但沒有費率表。第三方報導指出，LFM3-1.7B 的託管費率約為每百萬輸入 token 0.08 美元、每百萬輸出 token 0.20 美元，而視覺、音訊、omni 與決策變體的價格更高；Liquid 尚未在自家頁面公布這些數字，因此應將其視為報導內容，而非已確認資訊。相較之下，自架主機完全沒有按 token 計價——成本在於機器，而在 4 位元下，那台機器可以是一支手機。

OrcaRouter 的適用之處——以及不適用之處

LFM3 並不在 OrcaRouter 的型錄中，我們也不會假裝它在。它是開放權重軟體，你可以自行執行，或透過 Liquid 自家的 API 呼叫。這款路由器的價值，在於它周邊的那一層。1.7B 的專用模型很少是管線中唯一的模型：它負責工具呼叫、分類或擷取，而更大的模型則處理需要判斷的那一輪。OrcaRouter 把那些託管模型放在同一個金鑰、0% 加成後面——供應商牌價直接透傳——因此從 LFM3 升級到前沿模型的路徑，就成了一條路由規則，而不是第二份合約。它的自動容錯移轉，對 LFM3 所鎖定的工作負載尤其重要：在那裡，單一小型模型就是請求與錯誤之間唯一的屏障。

路由 DSL是更切合的有趣選擇。在一次呼叫中把專才模型與通才模型組合起來——把 LFM3 形狀的工作路由到小型模型，其餘一切則落到託管模型——正是這個系列專為之打造的部署模式。Liquid 的整體論點是：在狹窄任務上，一個 2B 模型能以極小部分的成本勝過前沿模型。而路由器正是你擷取這份節省、又不必把整條管線押注其上的方式。

看什麼

悬而未决的问题不是 LFM3 是否擅长它所声称的事，而是这些说法能否经受住一个并非由 Liquid 编写的测试框架的检验。该系列的智能体（agentic）数据是最先需要复测的，因为 WebArena-Verified 的 38.42 和 AutomationBench 的 41.29 远高于 1.7B 模型历来所能达到的水平，而智能体基准对提示词脚手架和重试策略最为敏感。一次结果与 Liquid 的表格相差几个百分点以内的独立运行，将使 LFM3 成为端侧工具调用的默认选择。一次低十个百分点的运行，则会使其成为一个良好的指令遵循模型，只是其智能体方面的说法被夸大了。

在那一輪執行出現之前，誠實的總結是這樣：LFM3 是一個工程品質良好、異常坦率的小型模型系列，具有真正新穎的層組合、實質的記憶體優勢、在可行的授權門檻下公開的權重，而且任何主要基準測試都未經獨立驗證。架構表中的 256-token 視窗不是上下文長度。發布內容中的其餘一切，在有人證明並非如此之前，都值得暫且照字面採信——也值得在放到使用者面前之前自行測量。