LFM3-1.7B 在 Ollama 上：一個指令，還有一張一分為二的成績單

撰寫本文時，lfm3 的 Ollama 頁面已上線約一小時，並記錄到 45 次下載。這就是它迄今全部的公開使用量。其背後的模型 LiquidAI/LFM3-1.7B，於一天前、2026 年 10 月 27 日發布，作為以 LFM3-1.7B-Base 為骨幹建構的 LFM3 家族中的文字成員——與 Liquid AI 同批推出的視覺、音訊、全模態（omni）及兩個決策模型一同亮相。10 月 28 日改變的不是模型，而是交付方式：ollama run lfm3 取代了尋找相容於 LFM3 的 llama.cpp 建置版本，而那是發布當天的做法。

這張基準測試表之所以值得比一行更新日誌更多的篇幅，原因就在這裡。LFM3-1.7B 交出的是小型模型級別中最懸殊的成績表之一：它在瀏覽器自動化、工具呼叫與指令遵循上擊敗 Qwen3.5-9B——一個規模超過它五倍的模型——卻在一般知識與長上下文檢索上以兩位數差距輸給對方。那張表裡的每一個數字都出自 Liquid AI 自己。目前尚未有任何一項經過獨立重現。

10月28日實際上改變了什麼？

Ollama 為 lfm3 列出五個標籤，全都在同一小時內發布，全都標示 256K 上下文與純文字輸入。預設版本是大多數人會拉取的那個。

• lfm3:latest 與 lfm3:1.7b — 1.7 GB，預設的 Q4 等級成品，且這兩個名稱下的摘要相同

• lfm3:1.7b-mlx-bf16 — 3.5 GB，適用於 Apple 晶片的全精度 MLX

• lfm3:1.7b-mxfp8 — 2.1 GB，8 位元 MLX

• lfm3:1.7b-nvfp4 — 1.7 GB，而這是需要仔細閱讀的一項

最後那個標籤帶有摘要 2012d88e202f——與 :latest 背後是完全相同的產物。透過 Ollama 拉取 lfm3:1.7b-nvfp4 並不會取得 NVFP4 檢查點；真正的那個是 Hugging Face 上的獨立儲存庫，是為了 GPU 服務而發布，而非供本機拉取。這個標籤究竟是佔位符還是發布疏漏，Ollama 的頁面並未記載。摘要是可查驗的，而且它們完全相同，如果你原本指望在筆記型電腦上靠 FP4 節省記憶體，這正是關鍵所在。

Ollama 頁面本身並非社群上傳。Liquid AI 的模型卡將 Ollama 列為支援的 GGUF 引擎之一，與 llama.cpp 和 LM Studio 並列，因此這是廠商指定的途徑較晚出現，而非外人的建置。頁面上的模型卡文字是 Liquid 自己的：「LFM3-1.7B 是一款面向本機代理與專用應用程式的三混合模型。」

這套架構，從決定它是否合適的標準來看

LFM3-1.7B 擁有 1.73B 個參數，分佈於 24 層，其中只有六層執行完整注意力。十三層是卷積核大小為七的門控短卷積，相較上一代的三；五層是視窗大小為 256 個詞元的滑動視窗注意力。長提示中的大多數詞元根本不會進入全域注意力矩陣，記憶體方面的優勢正是由此而來。

Liquid 將 128K token 的 KV 快取控制在 1.6 GB。Qwen3.5-4B 的同一項數據是 4.3 GB，MiniCPM5-2B 則是 5.6 GB。這個差距——而非參數量——才是 1.7B 模型能在 4B 模型辦不到的硬體上維持長上下文的原因。另外兩個數字值得記住：22T 預訓練 token，以及最終 3.5T token 的中期訓練階段，該階段加重了代理軌跡與工具呼叫的比重。最後這個階段，是對接下來兩節所有內容最清楚的解釋。

模型卡也列出 16 種語言、與 LFM2.5-8B-A1B 共用的 128K 詞彙表，以及預設開啟的思考功能——Ollama 會將其呈現為能力標籤，而非隱藏旗標。256K 上下文在配置意義上確有其事，但模型卡僅公布 128K 下的 KV 數值；在完整的 256K 下，快取會隨視窗規模增長，因此應將該範圍的上限視為資料中心設定，而非筆電設定。

分數表現強勁之處

這個模式在每一個獎勵「用工具做事」而非「了解世界事物」的任務中都是一致的。這些是廠商回報的數字，而比較對象則是 Liquid AI 所選擇的。

• WebArena-Verified — LFM3-1.7B 為 38.42，LFM2.5-2.6B 為 3.02，Qwen3.5-9B 為 28.94

• AutomationBench — 41.29，相較於 LFM2.5-2.6B 的 0.94 與 Qwen3.5-9B 的 15.10

• BFCL V4 工具呼叫 — 71.39，相較於同樣兩者的 55.89 與 62.83

• IFBench — 73.03，相較於 Qwen3.5-9B 的 48.84

• IFEval — 96.66，在 Liquid 的表格中最高

• LiveCodeBench v6 — 73.46，領先 Qwen3.5-9B 的 69.86

最有趣的那一列並不是最大的那一列。AA-Omniscience 是一項基準，部分評分取決於模型是否拒絕回答而非猜測，而 LFM3-1.7B 在非幻覺項目上錄得 92.93，Qwen3.5-9B 則為 52.59。它在同一集合上的準確率是 7.07。合起來看，這兩個數字描述的是一個大多說自己不知道的模型——對於即將採取行動的代理而言，這是一項被低估的特性；對於被期望回答問題的助理而言，則是一項糟糕的特性。

在它落敗之處，有時還敗得很慘

同一張表格，換個方向讀。

• GPQA Diamond — 63.37，相較之下 Qwen3.5-9B 為 80.40、MiniCPM5-2B 為 65.15，而後者是個 2B 模型卻勝過它

• Humanity's Last Exam，不使用工具 — 7.17，相較於 Qwen3.5-9B 的 16.41

• RULER 128K — 65.56，相較於 Qwen3.5-4B 的 84.63 與 Qwen3.5-9B 的 87.11

• AA-LCR 長上下文推理 — 52.83，相較於 Qwen3.5-9B 的 62.00

• MCP-Atlas — 32.57，相較於 Qwen3.5-4B 的 41.37 與 Qwen3.5-9B 的 42.67

• SWE-bench Verified — 43.40，相較於 Qwen3.5-9B 的 51.20

• Terminal-Bench 2.1 — 12.92，相較於 Qwen3.5-9B 的 17.98

RULER 那一橫列值得單獨用一句話來說明：以 256K 視窗為主打規格的模型，竟是自家比較表中最弱的長上下文檢索器，還輸給宣稱視窗只有其四分之一的模型。長視窗和能否在視窗裡找到東西是兩種不同的能力，而 LFM3-1.7B 只具備前者，未具備後者。任何打算把它用於大型程式碼倉庫或長篇合約的人，都應先測試那一列，再決定是否相信規格表。

MCP-Atlas 與 SWE-bench 這對基準傳達的是同一堂課，只是換了不同的語域。LFM3-1.7B 擅長驅動具備明確契約的單一工具。它在代理框架實際設計來處理的多步驟、多工具工作上落後，而當工作涉及必須了解程式碼庫在做什麼時，落後得更多。

這些數字代表什麼，又不代表什麼

上述每一個數字都來自 Liquid AI 自己的評估執行，並與發布一同公布。方法論並未寫在公告中：沒有各項測試的測試框架配置，沒有說明平均了多少次嘗試，也沒有指出對照模型是由 Liquid 自行運行，還是引自其自家的模型卡。一張只有單一來源的 27 列表格是論點，不是量測。

截至 10 月 28 日，Artificial Analysis 上並沒有 LFM3-1.7B 的條目，因此沒有第三方數字可供與廠商公布的數字對照。這種情況將會改變，而當它改變時，最具參考價值的比較會是 agentic 相關的那幾列，因為廠商在這些項目上的領先幅度最大，因此也最需要第三方觀點。

有一個細節則相反，值得肯定。Liquid 專門訓練了一個量化感知蒸餾檢查點，用來挽回 Q4_0 量化所損失的準確度，並將其作為獨立的 GGUF 檔案發布。以人們實際會運行的精度公布小型模型數據，這比大多數廠商做得更多，也讓 4 位元數據比事後量化稍微更可信。

執行它，以及重要的設定

這句一行指令是 ollama run lfm3，而在 16 GB 的機器上，1.7 GB 的預設版本就是正確的起點。這個頁面還附了四個一行啟動器，能把模型接進你既有的代理框架——ollama launch claude --model lfm3，以及 OpenCode、Hermes Agent 和 OpenClaw 的同樣模式。這是整頁最有用的地方：這代表模型可以直接放進你已經在跑的代理迴圈裡，不必自己寫客戶端，而這比大多數本機模型的推出方式門檻都低。

卡片上有兩組取樣設定，而且它們不能互換：聊天、工具使用、代理與程式設計採用 temperature 0.1、top_k 50 與重複懲罰 1.1；數學與科學採用 temperature 1.0、top_p 0.95 與 top_k 20。在數學題上執行代理設定，是讓這個模型看起來比實際表現更差的最常見方式。

如果你直接下載 GGUF，而不是透過 Ollama，檔案大小的安排會很實用。QAD Q4_0 檢查點是 1.05 GB，比 1.1 GB 的 Q4_K_M 略小，而且它是專門訓練來承受量化的版本。Q6_K 是 1.43 GB，若有餘裕，Q8_0 是 1.85 GB；BF16 是 3.47 GB，在這個尺寸下通常不太值得。

LFM Open License v1.0 是授權條款——實質上為 Apache 2.0，但增加一項條件：年營收低於 1,000 萬美元時可免費商用；達到或超過此門檻則需付費授權。此門檻以企業集團合計計算，且會隨微調模型一併適用，因此即使衍生物改名也無法規避。非營利與研究使用者不論營收皆可豁免。若你接近該門檻，請閱讀授權條款全文，而非摘要，包括這份摘要。

分割設定檔對你的部署方式意味著什麼

一個在指令遵循與工具契約上很強、在參數知識與長上下文檢索上很弱，而且便宜到足以在筆電上執行的模型，並不是通用型助理。它是執行器。適合它的架構是本地迴圈——由模型決定要呼叫哪個工具、格式化引數、遵循結構描述——並把知識密集與真正需要長上下文的步驟交給更大的東西來處理。

這種分工正是路由器得以發揮價值的情況，而值得精確說明 OrcaRouter 在此涵蓋什麼、不涵蓋什麼。LFM3-1.7B 是開放權重模型，可在你自己的硬體上執行；它不在我們的型錄中，本文也完全不是在為它推銷 API。我們提供的是這種分工的另一半：以單一金鑰跨200 多個託管模型處理升級步驟，並具備供應商定價零加成、供應商效能下降時自動容錯移轉，以及可將多個模型組合為單次呼叫的路由 DSL。實際做法是，本機模型仍是迴圈中的預設選項，而需要真正知識的呼叫則透過單一端點送出，不必再額外使用第二套 SDK 和第二份合約。

如果你是在評估這個模型，而不是要部署它，容錯移轉是成本較低的方式，能看出它是否經得起考驗：把一小部分流量導向它，保留已設定好的備援，並在你自己的任務上比較，而不是看 Liquid AI 的表格。

發表會留下的未解問題

Ollama 的建置版本和 Hugging Face 的 GGUF 是同樣的東西嗎？

不完全是。Ollama 預設的 1.7 GB 屬於 Q4 等級，對應的是一般通用 GGUF，而不是量化感知檢查點；後者是 Hugging Face 上另一個 1.05 GB 的檔案，經過訓練以還原 Q4_0 的準確度。nvfp4 標籤解析出的 digest 與 :latest 相同，因此儘管名稱如此，它並非 NVFP4 版本。如果量化品質對你的任務很重要，請拉取 QAD 檔案並直接透過 llama.cpp 執行。

筆記型電腦可以使用完整的 256K 視窗嗎？

很少見。Liquid 公布的 1.6 GB 快取數字是針對 128K，而快取記憶體會隨視窗大小呈比例增加，因此在計入權重與執行階段之前，完整的 256K 大約需要這個數字的兩倍。在 16 GB 的機器上，32K 到 64K 範圍的工作上下文是現實的上限；較大的視窗更適合解讀為伺服器部署的餘裕宣稱，而非筆電能力。

為什麼代理分數和知識分數差異這麼大？

因為它們衡量的是不同的東西，而這次訓練流程偏重了其中一項。最後的 3.5T token 中期訓練階段強調代理軌跡與工具呼叫，接著後訓練加入了 1.75T token 的監督式微調，以及涵蓋工具使用與結構化輸出的強化學習。參數知識正是 1.7B 模型最沒有空間儲存的東西，而 AA-Omniscience 的分項——7.07 準確率對比 92.93 非幻覺率——顯示它被訓練成拒答，而不是猜測。那是設計選擇，而對代理來說這是正確的選擇。

裁決

LFM3-1.7B 是同權重級別中第一個模型：其中 agentic 基準測試的列是下載它的理由，而不是附註。如果你正在打造一個需要可靠呼叫工具、遵循結構定義，並在無法確定時棄答而不是憑空編造答案的本地代理，它現在只差一個指令，而且整體條件正好符合這項工作。如果你需要一個具備知識、能從長文件中準確檢索，或能完成多步驟工程任務的模型，表格已明確表示你應該另尋他處——而 256K 規格是表中最不可信的一行。

真正該看的數字不是 49.37 的平均值，而是獨立重跑能否重現代理式任務的領先幅度，因為那些正是 1.7B 模型宣稱勝過 9B 模型的資料列，也是廠商自家評測框架最有空間美化結果的地方。