LFM3-VL-2B 對 WeVisOne-VL-2B：相隔三日，押注相反

LFM3-VL-2B於 2026 年 10 月 19 日出現在 Hugging Face 上。WeVisOne-VL-2B於 10 月 22 日出現。兩個模型都有約二十億個參數，皆為開放權重，也都出自知名實驗室，彼此在 72 小時內發布。你會預期它們幾乎可互相替代。但它們更像是對「視覺」意涵的相反押注：一個針對所見內容回答問題，另一個則回傳所見內容的精確形狀。

這種區別在規格表上很容易被忽略，因為兩張模型卡都列出了邊界框，也都列出了 OCR。差異在於輸出格式與訓練目標，而這決定你是否能把任一模型直接放進管線中，而不需要解析層。這也決定在通用型模型變得更強之後，哪一個還有存在的理由。

看見的兩種定義

LFM3-VL-2B 是 Liquid AI 的通用型模型。它能接收文字、影像與每秒 2 幀的影片，輸出文字，支援逐步思考，具備 128K 上下文，並涵蓋 16 種語言。其架構為稠密 1.92B 模型——包含 1.73B 語言主幹、164M 自研視覺編碼器與 25M 投影器——並已發布 BF16、GGUF、MLX 4-bit 與 ONNX 版本。Liquid 在家族發布文章中將它定位為能「觀看、推理並理解實體世界」的模型，而影片處理路徑對該家族而言確實是全新功能。

WeVisOne-VL-2B 是 Tencent 的 WeChat Vision 模型。它建構於 Qwen3-VL 主幹上，約有 2.4B 參數，採用 Apache 2.0 授權，其目的在於統一感知：開放詞彙偵測、指稱定位、計數、指向、OCR 定位、指稱分割與可提示的 Alpha 去背。它透過專用 token 回傳正規化座標，並透過一個獨立的 9.6M 參數像素解碼器回傳遮罩，該解碼器必須與語言模型一起載入。

一個模型是讀者，另一個是量測儀器。它們基準測試表上的重疊是真實的，但那是兩個不同產品在量測同一個場景時的重疊。

輸出格式就是產品

WeVisOne-VL-2B 將座標編碼為從 <0> 到 <1000> 的 token，並用 <OBJ> token 標記每個實例；當請求的目標不存在時，則回傳 None。最後這個細節正是實務人員會注意到的：模型卡在 RefCOCOg 上報告的拒絕率為 50.2，而 Rex-Omni 和 LocateAnything 約為 0.5。它被訓練成說「不在這裡」，而不是憑空捏造一個框。

像素解碼器不是可有可無的。分割與 Alpha 去背需要 mask_decoder.pt，這是一個由物件 token 觸發、具備 960 萬參數的模組。若只載入語言模型，你只會得到座標，得不到遮罩。GitHub 儲存庫隨附推論套件，用來串接兩者；而此模型在設計上是單輪且僅限影像——像素解碼器會拒絕影片網格。

LFM3-VL-2B 沒有對等的契約。它會以散文描述一個區域、計數物件，或對場景進行推理，而其定位列（RefCOCO-avg 90.5）顯示它擅長定位。但輸出是文字。對於需要遮罩的管線而言，90.5 與可解析多邊形之間的差異，就是示範與產品之間的差異。

你無法減去的基礎數字

這兩張卡片都回報 RefCOCO 系列的結果，但它們並不是同一種測量。LFM3-VL-2B 回報 RefCOCO-avg 90.5，這是對各個指稱表達式劃分取平均。WeVisOne-VL-2B 回報 RefCOCOg 77.1 的平均 F1（用於指稱偵測），以及 RefCOCO testA 82.9 cIoU（用於指稱分割）。RefCOCOg 是另一種劃分，其中的表達式更長、更口語化；cIoU 則是與 F1 不同的指標。

從 90.5 減去 77.1 所得的數字毫無意義。誠實的解讀是：兩個模型在各自的測試框架上都擅長指稱定位，但這兩個框架都尚未被獨立重現，而且指標定義的差異足以讓排名無法確定。同樣的謹慎也適用於 OCR：LFM3-VL-2B 回報 OCRBench v1 為 86.3，而 WeVisOne-VL-2B 回報 OCR HierText 為 30.5，後者是在更困難資料集上的不同基準。

在比較條件單純的情況下，結果有利於在自己擅長領域作戰的專家模型：WeVisOne-VL-2B 回報的 COCO 偵測 F1 為 55.2、LVIS 為 53.3、Dense200 為 61.4，而對照模型完全沒有公布偵測 F1。這並非預設的勝利，而是提醒我們：通用型模型並不是按照那種方式接受訓練與評分的。

霧面就是護城河

可提示的 alpha 摳像（alpha matting）是 LFM3-VL-2B 與其同級多數模型都不具備的功能。WeVisOne-VL-2B 在 P3M-500-NP 上針對柔邊遮罩回報的平均絕對誤差為 6.6——也就是髮絲、玻璃與毛髮周圍的半透明邊界，而二元分割遮罩會把它變成生硬的切邊。模型卡也坦率說明其限制：精細的 alpha 邊界在遮蔽、低解析度與透明度下會劣化。但對於產品去背、合成與背景替換而言，遮罩才是流程真正需要的輸出。

這是該模型存在的最有力論據。一個 2B 的通用型模型能描述影像，卻無法直接給你柔和的 alpha 通道。騰訊圍繞像素解碼器打造了一個小模型，因為要從大型通用模型取得這種輸出代價高昂；而 4B 的同系列模型，則是為需要在同一任務上獲得更高準確度的團隊而存在。

影片與思考是另一道護城河

LFM3-VL-2B 的差異化優勢則朝相反方向發展。它接受 2 fps 的影片，並在無字幕情況下回報 Video-MME 62.8、MVBench 69.4 與 MMMB 85.2。WeVisOne-VL-2B 是單輪且僅支援圖像；其像素解碼器會拒絕影片網格。若你的輸入是影片片段，比較在基準表開始前就已結束。

思考模式又拉開了第二道差距。LFM3-VL-2B 在 MathVista 上回報，開啟思考模式時為 84.2，未開啟時為 68.5；MMMU 則是 55.7 對 48.6。WeVisOne-VL-2B 基於效率考量，設計上不具備思維鏈。對感知元件而言，這是合理的工程選擇；但對你希望用來推理圖表的模型而言，這則是硬性限制。

記憶、授權與入場的代價

• 參數 — LFM3-VL-2B 為 1.92B 稠密模型，對比 WeVisOne-VL-2B 約 2.4B，外加一個 9.6M 像素解碼器。

• 記憶體 — 依算術估算，LFM3-VL-2B 在 BF16 下約需 3.84 GB，並有 4 位元 MLX 版本；WeVisOne-VL-2B 的權重約 9.1 GB（F32），BF16 估計約 4.9 GB；上述數據來自第三方部署筆記，而非官方規格卡。

• 輸入 — 文字、圖像與 2 fps 影片，相較於僅圖像與文字，單輪。

• 輸出 — 散文，可選搭配推理或文字、正規化座標、遮罩與 alpha 遮罩。

• 上下文 — 128K，相對於未說明為文件規模的視窗；像素解碼器才是限制所在。

• 授權 — LFM Open License v1.0，年營收低於 1,000 萬美元可商業使用；相較之下，Apache 2.0 不限規模皆可。

• 已發布 — 資料庫 2026年10月19日，家族公告 10月27日，對比資料庫 2026年10月22日。

授權條款那一列的情況與常見故事相反。Tencent 的模型採用寬鬆授權；Liquid 的模型則有營收上限。對一家打造商用感知產品的公司而言，Apache 2.0 移除了 LFM 授權所帶來的其中一項盡職調查項目。這並不代表這兩個模型可以互換，但確實意味著較小、較通用的模型反而背負較大的法律限制。

這兩款模型都沒有託管價格。

兩張卡都公布了權重，但都沒有公布每 token 的 API 費率。Hugging Face 上沒有列出 LFM3-VL-2B 的推論供應商；WeVisOne-VL-2B 的卡同樣沒有託管端點，儘管社群已有 LiteRT、Core AI、GGUF 和 Android 的移植版本。這就是目前 2B 視覺層級的樣貌：權重免費，服務得自己來，而真正的成本在於 GPU 和整合工作。

如果你寧願租用那個層級，而不是自行擁有，OrcaRouter 會透過單一 API 路由託管的視覺模型——其中包括 Qwen3-VL-8B——並以 0% 加價按供應商定價原價轉嫁，還提供模型融合，讓感知模型與推理模型組成小組共同回答。在本比較中，我們不提供這兩個檢查點中的任何一個，本文也沒有任何內容暗示我們提供。重點是：當兩個開放權重模型都沒有隨附端點時，租用稍微大一點的託管模型是合理的第三個選項。

如何選擇

• 在以下情況選用 WeVisOne-VL-2B：輸出為幾何資訊——框、遮罩、alpha matte、計數，或「不存在」訊號。若 Apache 2.0 是不可妥協的條件，或你正在建構去背、合成或機器人感知流程，也請選用它。

• LFM3-VL-2B若輸入包含影片、需要跨圖表或表單進行推理，或想用一個小型模型回答一般問題而非量測形狀，請選擇

• 兩者都採用——前提是你已準備好要跑兩套管線。它們共用一個參數類別，除此之外幾乎別無共同點；而硬要假裝它們共通的整合成本，比多養一個模型的代價還高。

他們的儲存庫相隔三天是巧合。它們回傳內容的差異則不是。兩個實驗室面對同樣的 2B 預算，卻把它花在不同的產出上，而正確的問題不是哪一個比較好——而是你的下一個 pipeline 步驟實際能取用哪一個產出。