LFM3-VL-2B：一個頭條評分取決於單一開關的 1.92B 視覺模型

LiquidAI/LFM3-VL-2B 已公開存在八天，Liquid AI 才終於對它發聲。Hugging Face 儲存庫於 2026 年 10 月 19 日建立，當晚就出現了 GGUF 版本；供應商的公告——一篇部落格文章、一個模型集合、一張附有完整基準測試表的模型卡——則於 10 月 27 日發布。它所取代的模型，LFM2.5-VL-3B，是顯而易見的衡量基準：它有 3.1B 參數，而新模型為 1.92B；在 Liquid 自家的 62 項基準測試套件中，新模型平均得分 71.4，舊模型則為 57.6。同一張模型卡還記錄了另一個較少受到關注的數字：在停用思考功能的情況下，LFM3-VL-2B 平均得分 62.1。光是這個單一配置旗標就值 9.3 分，而這正是決定性的世代勝利與小幅勝利之間的差距。

本文涵蓋截至10月28日實際有公開紀錄可查的內容——儲存庫時程、規格、基準測試表及其注意事項——並清楚標明證據止於何處。

出現了什麼，以及何時？

時間軸很重要，因為它說明了為什麼這個模型問世時毫無報導。Liquid AI 沒有發布預告、等候名單或研究貼文。它上傳了權重和模型卡，而模型卡就擱在那裡。第三方追蹤者注意到了該儲存庫，而第一篇關於 LFM3-VL-2B 的公開文章，是基於一個尚未合併的推論框架 pull request 所作的臆測，而非來自該供應商的任何內容。

• 儲存庫已建立 — 根據 Hugging Face API，2026 年 10 月 19 日 19:51 UTC。

• GGUF 儲存庫已建立 — 2026 年 10 月 19 日 20:29 UTC，三十八分鐘後。

• 卡片最後修改 — 2026年10月27日 16:24 UTC，公告當天。

• 廠商公告 — 2026 年 10 月 27 日：一篇家族部落格文章、一篇 Hugging Face 部落格文章，以及一個模型集合。

所以準確的描述並不是「悄悄出貨且仍未發布」，而是「悄悄出貨，八天後才發布」。在那段時間內撰寫這個儲存庫相關內容的人，所描述的是真實、可下載的檢查點，但並不是一個在 Liquid 產品陣容中有明確定位的產品。那個定位現在存在了：LFM3-VL-2B 是六個模型家族中的視覺成員，該家族建構於共享的 1.7B 基礎上，而廠商的定位是裝置端視覺理解——文件、圖表、應用程式畫面、物件尋找，以及機器人的空間推理。

模型，以卡片本身的數字來看

Liquid 的模型卡對於參數的去向交代得異常具體，這一點值得注意，因為模型名稱中的「2B」通常掩蓋的比揭示的還多。

• 總參數量 — 1.92B：1.73B 語言模型、164M 視覺編碼器，以及 25M 投影器。

• 編碼器 — 由內部自行建構，結合卷積與注意力機制，取代 LFM2.5 視覺模型中所使用的 SigLIP2 塔。

• 模態 — 輸入文字、圖像和影片；輸出文字。它是首個接受影片的 LFM 視覺模型，取樣率為每秒 2 幀。

• 視覺標記化 — 每個 2×2 的補丁區塊會成為一個語言 token，維持原生解析度。

• 上下文 — 128K 個 token，輸入加上輸出，最大位置為 128,000。

• 授權 — LFM Open License v1.0，與同系列其他成員一樣的非寬鬆但開放條款。

• 預訓練 — LFM3-1.7B-Base 主幹，總計 22T tokens，具備 128K 上下文擴展，並於中期訓練期間使用 256K 擴展。

• 不建議用於 — 程式設計、多輪對話或複雜推理，依照卡片本身的指引。

最後那一行值得讀兩遍。一個被明確不建議用於多輪對話的模型，也是一個其 128K 上下文視窗難以按照長上下文通常的使用方式來使用的模型。這個視窗是真實存在的，而且幾乎是 LFM2.5-VL-3B 的 32,768 個 token 的四倍。它也是在一個 1.92B 模型上，一份成長速度快過其所依附權重的 KV 快取。

六十二項基準測試、一間實驗室，以及一張點名競爭對手的表格

基準測試部分是本次發布內容中最有用的部分，而且不僅僅是因為分數很高。Liquid 公布了一張涵蓋 62 項基準測試的表格，其中包含自家模型在兩種配置下的表現，以及九個競爭對手：LFM2.5-VL-3B、MiniCPM-V 4.7 1B、Qwen3.5 2B、Qwen3.5 4B、InternVL3.5 4B、Gemma 4 E2B、Gemma 4 12B、GPT-5.6 Luna 與 Gemini 3.5 Flash Lite。每項分數都正規化至 0–100，每個類別為其各項基準測試的未加權平均，而總平均則是全部 62 項的未加權平均。

這件產物比新聞稿圖表更具可證偽性。它列出了所用工具、列出了競爭對手，卡片註腳也說明哪些模型是在啟用推理的情況下運行、哪些則沒有。這仍是廠商自家的工作：Liquid 挑選了這 62 項基準，跑過每一個模型，並公布了表格。公司外部沒有任何單位重現過其中任何部分。

• 平均 — LFM3-VL-2B 為 71.4，相較於 LFM2.5-VL-3B 的 57.6 與 MiniCPM-V 4.7 1B 的 57.5。

• 文件、OCR 與圖表 — 83.9，裝置端宣傳最倚重的類別。

• GUI 理解 — 83.1，相較於 LFM2.5-VL-3B 的 66.0。

• 視覺定位 — 77.3，相較於 68.3。

• 影片 — 在首個真正能處理影片的 LFM 視覺模型上，達到 61.2，相較於 41.3。

• 代理能力 — 42.5，相較於 21.1。這是表中每個小型模型最弱的類別。

• 數學與邏輯推理 — 68.8，相較於 40.6。記住這個數字；它才是值得注意的那個。

這張模型卡以文字提出三項比較性主張：在 62 項基準測試中，LFM3-VL-2B 的得分至少領先所有規模相近的模型 8 分；它與 Gemma 4 12B 相當；以及它與 GPT-5.6 Luna 的差距在 2 分以內，同時勝過 Gemini 3.5 Flash Lite。對照表格查核後，這些說法成立：Gemma 4 12B 平均為 71.7，GPT-5.6 Luna 為 73.4，Gemini 3.5 Flash Lite 為 70.0。一個 1.92B 模型平均落在 12B 模型 0.3 分以內，這是頭條主張，而這是廠商針對自家跑分數據所提出的說法。

思考開關承擔了大部分工作

LFM3-VL-2B 對同一組權重回報了兩個分數。在推理模式下，它平均為 71.4。關閉思考時，平均為 62.1。這個差距並非均勻分佈於各類別——它集中在你会預期推理有幫助的地方，而在你不会預期的地方幾乎不存在。

• 數學與邏輯推理 — 有思考時為 68.8，無思考時為 41.0。相差 27.8 分，是迄今最大的差距。

• 文件、OCR 與圖表——83.9 對 71.6。在看似屬於感知、但往往並非如此的任務上，出現 12.3 分的差距。

• GUI 理解 — 83.1 對 81.5。幾乎沒有變動，這表示螢幕閱讀能力存在於編碼器與後訓練中，而非推理迴圈。

• 感知 — 75.6 對 68.9。

• 平均 — 71.4 對 62.1。

結果是，這種頭條式比較以特定方式美化了新模型。LFM2.5-VL-3B 不支援推理模式，因此 Liquid 是把一個會思考的模型拿來跟一個不會思考的模型比較。公平的對決是 62.1 對 57.6——仍然是勝出，但只是 4.5 分的勝差，而不是 13.8 分。而在那樣的配置下，它不再領先周邊所有模型：Qwen3.5 2B 平均為 64.0，不過那個數字同樣來自啟用推理模式的執行結果。

這一切都不會讓這次發布變得不那麼有趣。它讓這次發布變得清晰易懂。Liquid 打造了一個小型模型，其預設部署快速且不進行推理，而當你讓它思考時，其上限會高得多。哪個數字適用於你，完全取決於你的產品是否能負擔在手機上進行推理迴圈的延遲。

1.92B 在裝置上能換到什麼

效率論述才是 Liquid 真正在賣的東西，而這張卡用實測數據、而非形容詞來佐證。在單張 NVIDIA B300 上以 BF16 執行 SGLang，模型在 1,024 個並行請求下每秒可產生超過 12,000 個輸出 token。這個數字更能說明批次處理的效果，而非模型本身，但它證明了 serving 路徑從第一天就已存在。

在裝置端，這張卡片會公布每個受比較模型在固定工作負載下的預填、解碼與峰值記憶體：一張 512×512 影像、輸入 1,024 個文字 token、輸出 256 個 token，全部在 llama.cpp 中進行，並使用 Q4_0 GGUF 語言模型與 F16 視覺投影器。這是可重現的設定，而在決定投入手機之前，該看的就是記憶體欄位。

工具鏈確實存在，但發展並不均衡。SGLang 支援在推出時就已具備。llama.cpp 支援正在審核中——pull request 31252——並附有 Liquid 的明確但書：目前不支援影片輸入。GGUF 權重已經存在，且比公告早八天。如果你想要這個模型的原因是影片，那麼本機路徑尚未完成，而說明卡上也這麼寫。

尚未可知的事物

本文的誠實界線在於：上文所有量化內容皆來自 Liquid AI。目前沒有對 LFM3-VL-2B 的獨立評估、沒有第三方排行榜登錄、沒有重現 62 項基準測試套件，且截至 10 月 28 日，Liquid 自家 API 上該模型也沒有公布每 token 價格。模型卡列出可透過 Hugging Face、Liquid playground 與 Liquid API 取得，權重雖開放，但「open weights」與「經獨立驗證」是不同主張。

匯總分數與實際部署情況之間也存在落差。62 項基準的平均分，用來為模型排名是個好工具，用來預測你的實際工作負載則很差。LFM3-VL-2B 最強的類別——GUI 理解、視覺定位、文件與圖表閱讀——恰恰是廠商只要挑選不同的基準題目，就能讓分數相差好幾分的類別。它最弱的類別，也就是得分 42.5 的代理式工作，卻最可能是產品卡所宣傳的機器人應用場景中真正關鍵的部分。

如果你正在打造某個東西，這適合放在哪裡

LFM3-VL-2B 並未列於OrcaRouter 的目錄（截至本文撰寫時）——這是供你自行下載並執行的檢查點，而不是可透過我們的 API 呼叫的項目。這反而形塑出有用的做法，而非將其排除在外。本次發布在成本上競爭的模型——那些處理文件和影片長尾需求的託管視覺模型——正是你會納入路由的模型；而將本機檢查點與託管備援分別放在同一個路由決策的兩端，正是這些數字實際上所支持的架構。在裝置上執行 1.92B 模型，並將困難的影格升級處理至更大的託管模型，正是讓 62.1 這個數字可被接受的部署方式，因為它失敗的案例，正是那些會離開裝置的案例。

對於我們確實在路由的模型，{{1}}一個端點就代表一把金鑰{{/1}}，不需要第二份合約，而且當主要供應商效能下降時，會自動跨供應商容錯移轉。{{2}}那是系統中需要路由器的那一半{{/2}}；裝置端的那一半則需要良好的量化與電池預算。

什麼會改變這幅景象？

三件事，按它們會有多大影響排序。獨立重現 62 項基準測試表，要麼會證實該發布中最有趣的說法，要麼會改寫它。一個已合併、支援影片的 llama.cpp 建置，會讓裝置端主張從計畫變成產品。而公布 API 價格，會讓任何人都能從決定大多數部署的那個軸線來比較它，而那個軸線目前是一格空白。

在那之前，站得住腳的解讀既狹窄又實用：Liquid 推出了一個 1.92B 視覺模型，在廠商自家的測試套件上勝過它所取代的 3.1B 模型；啟用推理時決定性地贏得該比較，未啟用時則小幅勝出，並在螢幕與文件方面領先同尺寸級別。該儲存庫在公告前八天就已公開，這是關於 Liquid 發布流程的事實，而非關於模型本身——但這正是 LFM3-VL-2B 的首批報導屬於推測而非評測的原因。