LFM2.5-VL-3B：Liquid AI 專為邊緣端設計的全新 3B 視覺語言模型

關於 LFM2.5-VL-3B，首先要知道的是，它是以兩個半步驟的形式發布的。權重於 2026 年 8 月 11 日出現在 Hugging Face 上——包含一個完整的 bf16 檢查點、一張附有基準測試表的模型卡、一份十六種語言的 README，而且沒有任何公告。模型卡顯示的下載次數為零。隔天，8 月 12 日，Liquid AI 發布了官方文章〈LFM2.5-VL-3B: A Better and Faster Vision-Language Model for the Edge〉，這次低調的發布才真正成為正式發布。如果你正好在同一週讀到這篇文章，你讀到的是最早一批獨立評測之一；這款模型除了 Liquid 實驗室內部的人以外，幾乎還沒有任何人實際運行過——所以接下來要說的是，哪些是可以從儲存庫中確實得知的，哪些不是。

LFM2.5-VL-3B 是什麼

LFM2.5-VL-3B 是一個視覺語言模型——輸入影像與文字，輸出文字——建構於 Liquid AI 的 LFM2.5 文字骨幹之上。具體而言：語言模型是 LFM2.5-2.6B，搭配 SigLIP2 NaFlex 400M 視覺編碼器，總參數量約 31 億。它繼承了該系列混合架構，交織短程門控卷積區塊與群組查詢注意力，擁有 128,000 詞彙量的詞彙表，以及 32,768 詞元的上下文視窗。它支援十六種語言（英文、阿拉伯文、中文、法文、德文、印度文、印尼文、義大利文、日文、韓文、波蘭文、葡萄牙文、俄文、西班牙文、泰文、越南文），以 bfloat16 格式提供，並採用 Liquid 的 lfm1.0 開放授權。

這不是一個從零開始打造的模型。模型卡將其描述為 LFM2.5 的多模態變體，建立在先前的 LFM2-VL-3B 之上，並進一步進行了中期和後期訓練。這個血統很重要：視覺能力是疊加在一個已經預先訓練過約 34 兆個 token 的文字模型之上的，因此語言端並非玩具——它與純文字模型使用的是同一個家族引擎，只是焊接上了一個視覺編碼器，並針對視覺任務進行了重新訓練。

它能做什麼

Liquid 的文章點出了相較於先前的 LFM2-VL-3B 的四項改進：螢幕與 UI 理解、函式呼叫、grounding，以及多圖輸入。簡單來說，就是：

• Grounding — 使用自然語言查詢（如「停止標誌」、「價格欄」）指向物體，並取得正規化的位置。

• 螢幕理解 — 回答關於螢幕上顯示什麼內容及其所在位置的問題，並在 ScreenSpot-v2 上進行基準測試。

• 具版面註解的 OCR — 全頁 OCR 同時回傳文件結構，包含 23 種版面標籤（文字、標題、清單、表格、表格標題、圖表、方程式、程式碼、頁首與頁尾等），以正規化整數座標表示。

• 工具使用——一個四步驟的函式呼叫流程，以 JSON 形式接收工具定義，在工具呼叫 token 之間發出 Pythonic 呼叫，並回傳最終的純文字答案。

• 多圖輸入 — 在單一輪次中跨多張圖片進行推理。

Liquid 自身對其不適用之處的指引異常具體。該卡片建議將其用於單回合、高吞吐量、低延遲的任務——例如汽車領域的近即時物體偵測、掃描文件的批次 OCR、裝置上的選單與路標翻譯——並明確警告不要用於長上下文、推理密集型的工作、視覺網頁設計，以及高度技術性的藍圖問題。

這些數字——全部由供應商報告

本節中的每個圖表皆來自 Liquid AI 自家的模型卡與部落格文章。這些內容均未經獨立重現驗證，在第三方實際運行該檢查點之前，你應將這些視為主觀宣稱，而非客觀事實。這個標籤在此處具有實質意義，因為就紙面上的紀錄而言，確實相當亮眼：

• 定位 — RefCOCO 的 macro precision@1 為 87.9，高於前一代 LFM2-VL-3B 的 57.1 — 約莫提升了三十個百分點，Liquid 將此歸功於視覺後期訓練。

• 畫面理解 — ScreenSpot-v2 平均分數為 80.7，Liquid 報告稱其領先於他們歸因於 Qwen3.5-4B 的 78.5。

• 工具使用 — ToolSandbox 59.5，是 Liquid 在 LFM2-VL-3B 上測得的 26.4 的兩倍多；BFCLv4 32.5，從 20.5 提升。

• 通用視覺推理 — MME 73.1, MMStar 63.3, RealWorldQA 73.1, MMMB 83.0, ChartQA 81.3, MathVista 68.5, POPE 88.7.

• OCR — OCRBenchv2（英文子集）47.5，高於先前的 43.9。

• 困難的多模態推理 — MMMU Pro 30.5、BLINK 61.5、MuirBench 58.3 — 較弱的環節，對於 3B 模型來說意料之中。

• 速度（供應商實測）——在 Apple M5 Max 上為每秒 228 個 tokens，在 AMD Ryzen AI Max+ 395 上為每秒 116 個 tokens，在 Galaxy S26 Ultra 上為每秒 20 個 tokens，且全部在約 3.3 GB 記憶體內運作。在搭載 vLLM 的 H100 上，Liquid 聲稱在高並發下可達每秒約 11K 個輸出 tokens，五幀片段的首次輸出延遲約為 34 毫秒，並將其歸因於模型直接作答而非進行推理。

對於一個 3B 模型來說，這些宣稱相當多，而且值得重申模型自家卡片頁尾的警示：這些是 Liquid 的數據。在「實驗室評測表現良好」與「在你的資料上經得起考驗」之間的差距，正是這種新模型通常會栽跟頭的地方。

尚未知曉的事

開放問題的誠實清單：

• 無獨立基準 — 截至撰寫本文時，LFM2.5-VL-3B 未出現在任何第三方排行榜上。上述所有分數均為廠商自行報告。

• 沒有託管端點——目前尚無任何推理提供者提供此服務。這是一則自架的故事，句號。

• 沒有使用數據——上線首日零下載，代表沒有社群回饋、沒有微調、沒有「我在 X 上執行，結果在 Y 出錯」這類回報。第一批真實世界的使用回報仍在我們前方。

• 一項實驗性功能 — Liquid 本身將版面註解輸出標記為「實驗性」，並表示其「可能變更、可能不可靠，且可能不易解析。」請勿貿然以此為基礎建置您的解析器。

• 第三方報導稀少——第一週的新聞多為簡短新聞彙整，尚未有人進行深入的獨立測試。

這些都不代表這個模型不好，只表示它尚未經過驗證，就像任何模型在發布後初期一樣。

如何自行執行

對於如此年輕的模型來說，生態系統的表現異常出色。{{1}}格式變體與權重在同一天發布：{{2}}包括適用於 llama.cpp 的 GGUF、ONNX，以及五種適用於 Apple Silicon 的 MLX 量化版本，{{/2}}{{3}}同時還有適用於 Transformers、vLLM 和 SGLang 的原生 bf16 檢查點。{{/3}}{{/1}}{{4}}Liquid 列出首日支援涵蓋 llama.cpp、MLX、vLLM、SGLang 和 ONNX，{{/4}}{{5}}此外還有 WebGPU 瀏覽器示範。{{/5}}{{6}}建議的取樣參數為 temperature 0.2、top_k 50、repetition penalty 1.0，{{/6}}{{7}}視覺功能則由模型的 processor 設定處理。{{/7}}{{8}}如果你想今晚就在筆電上試試看，{{/8}}{{9}}MLX 或 GGUF 版本是最快的途徑。{{/9}}

看什麼

有兩件事決定 LFM2.5-VL-3B 能否超越炒作週期而真正舉足輕重。第一，grounding（定位）與螢幕理解的數據能否經得起獨立複現——ScreenSpot-v2 的 80.7 與 RefCOCO 的 87.9 是最值得查證的兩項宣稱，因為正是這兩個數字會讓它成為真正具顛覆性的邊緣模型。第二，是否會出現託管端點，因為那會把評價從「有趣的自架專案」翻轉為「今天就能出貨」。而正是在那一刻，路由層才真正值回票價：一個 API 涵蓋 200 多個模型，意味著當 Liquid 或某家供應商上線端點的那一天，你只需把 LFM2.5-VL-3B 加進你原本就在呼叫的模型旁邊，無需變更整合方式，以供應商牌價、零加價取得；自動故障轉移讓你能把真實流量導向它，同時由經過驗證的模型接手它失手的呼叫。在那之前，它只是個前景可期的自架故事——而對一個才一週大的模型來說，這已經比大多數發布的模型所能獲得的還要多了。