LFM3-VL-2B 對比 WeVisOne-VL-4B：2.5 倍參數實際上換來什麼

騰訊自家的基準表卻不支持這筆顯而易見的採購。 WeVisOne-VL-4B是微信視覺團隊於 2026 年 10 月 22 日發布的兩款感知模型中較大的一款，但在框提示 alpha 遮罩任務上，表現卻不如自家的 2B 版本：在 P3M-500-NP 上的平均絕對差異為 7.3，而 2B 版本為 6.6；此指標數值越低越好。不過，多數買家真正會拿來與它比較的模型，並不是它的同門 2B 版本，而是 LFM3-VL-2B——Liquid AI 的 1.92B 裝置端視覺模型，其權重於 10 月 19 日釋出，並於 10 月 27 日與 LFM3 系列其餘成員一同發布。

把這兩者並排比較，有趣的問題不是哪一個更聰明，而是 2.5 倍的參數為你換來了什麼，又付出了什麼代價。簡短的答案，來自廠商自己的表格：它們換來了密集偵測、指稱準確度，以及當物件不存在時高得多的拒答率。它們沒有換來通用模型，沒有換來影片能力，也沒有換來一個能放進手機的模型。以下全部內容都出自那兩份已公布的表格，並保留可見的接縫——尚無獨立測試框架重現過任一模型的數據。

每一個實際上是什麼

LFM3-VL-2B擁有 1.92B 稠密參數：1.73B 語言主幹、164M 自研視覺編碼器，以及 25M 投影器。主幹採用 Liquid 的三混合堆疊——24 層拆分為 13 層閘控短卷積、5 層滑動視窗注意力層（視窗為 256 個 token），以及 6 層全域注意力層。它接受原生解析度的文字、圖像與影片，影片以每秒 2 幀取樣，支援 128K token 上下文，涵蓋 16 種語言，並具備可選的思考模式，會在給出答案前先進行一輪推理。其輸出為散文。

WeVisOne-VL-4B建構於 Qwen3-VL 主幹之上，並命名為 4B，不過 Hugging Face 的中繼資料將其四捨五入為 5B，而第三方文章則將實際參數量估在接近 4.83B。與其說它以散文作答，不如說它輸出幾何資訊：以 0 到 1000 的歸一化座標 token 表示框與點，在每個預測框後附上一個 OBJ 標記（token id 152678），並在目標不存在時輸出字串 None。遮罩與 alpha matte 需要第二個產物 mask_decoder.pt，這是一個 9.6M 參數的像素解碼器，會接收每個 OBJ token 的隱藏狀態與預測框，並以步長 1 回傳全解析度 alpha。它是單輪且僅限影像，並直接產生結構化輸出，沒有思維鏈。

一次看清對比：

• 規模 — LFM3-VL-2B 為 1.92B 稠密模型，相較之下 WeVisOne-VL-4B 約 4.83B，另加一個 9.6M 解碼器，且該解碼器對遮罩而言是必需的

• 輸入 — 文字、影像與 2 fps 影片，對比文字與單一影像

• 輸出 — 自然語言文字與一段思考過程，對比座標 token、框、遮罩、去背遮罩，或明確的 None

• 背景 — 128K tokens，而模型卡上未公布推論上限；論文描述訓練時使用 4,096 與 8,192 tokens

• 語言涵蓋範圍 — 標示 16 種語言，對比未標示任何語言

• 授權條款 — LFM Open License v1.0，年營收低於 1,000 萬美元可免費商用，相較於 Tencent 撰寫的程式碼採用 Apache 2.0

• 執行環境 — GGUF/llama.cpp、MLX 4-bit、ONNX，以及透過 Transformers、vLLM 或 SGLang 進行的 BF16 對 BF16 比較

升級並不均衡，而論文指出了問題所在。

WeVisOne-VL-2B 與 WeVisOne-VL-4B 是同一架構的兩種規模，皆以相同的約 1 億張影像、透過相同的三階段課程訓練，並在同一張表上評估。這使得同系列比較成為現有關於額外參數作用的最純粹證據——而它並非朝單一方向發展。

就騰訊的數據來看，4B 明顯勝出之處：

• Dense200 偵測 — 平均 F1 為 71.3，相較於 61.4，是單一最大增幅

• LVIS — 55.3 對 53.3，小幅提升 2 點

• RefCOCOg 指稱偵測 — 測試 81.8 對比 78.2

• RefCOCO 指稱分割 — testA 上 84.5 cIoU，相較於 82.9

• ReasonSeg — 驗證集上 cIoU 71.2 對比 60.9，推理分割躍升 10 個百分點

• PointBench 指向 — 71.9 對 62.9

• WeRefMat 指代摳圖 — 在指代分割上平均絕對差異為 9.8，相較之下為 15.8，誤差降低了 38%

在並不適用的地方：

• P3M-500-NP 框選摳圖 — 7.3，相較 2B 的 6.6 更差

• PPM-100 方框摳圖 — 6.1 對 5.3，較差

• Ref-ZOM cIoU — 測試 72.2 對 73.4，2B 再度領先

這個模式即使原因未公開也清晰可辨：4B 在困難且具語言條件化的任務上領先——指稱分割、推理分割、真實場景中的指稱去背——而在較簡單的框提示去背資料集上毫無增益，因為兩個模型都已接近上限，且 9.6M 解碼器可能承擔了大部分工作。三個框提示去背基準中有兩個朝錯誤方向變動。若你唯一的任務是對提供的框進行 alpha matting，4B 不是升級；它只是用更昂貴的方式得到相同答案，而且還略差。

缺失物件：較好，但仍未解決

這篇論文裡最有用的一欄，是幾乎沒有願景模型卡會公布的那一欄。RefCOCOg-Rej 是一種變體，其中每個表達式都經過修改，使得不存在相符的物件於影像中。一個不會說「不」的模型會憑空生出一個框，而每一個下游的裁切、計數與遮罩都會繼承這項捏造。

WeVisOne-VL-4B 正確拒絕的比例為 67.4%，而 2B 為 50.2%。這是真實且大幅的改進——提升 17 個百分點，讓管線的失敗模式從擲硬幣般的五五波，變成三分之一。這也意味著，對於每三個「物件不存在」的查詢，4B 仍有大約一個會回傳信心十足的框。在騰訊自家的內部 WeRef-Bench 上，拒絕率讀數為 96.4%，但該基準是該實驗室自行建立的 2,880 條中英文查詢，因此它衡量的分布比公開基準更友善。誠實的總結是：該模型具備可用的棄答行為，但尚未解決這個問題；如果你的應用程式無法容忍幻覺區域，無論你選哪個模型，都需要在此之上加一個閾值或第二道檢查。

那個看似可比、實則不然的數字

人們很容易把 LFM3-VL-2B 的 90.5 RefCOCO-avg 拿來和 WeVisOne-VL-4B 的 81.8 RefCOCOg 並列，然後宣告較小模型以 8.7 分勝出。千萬別這麼做。那些是不同的資料切分與不同的評估指標：Liquid 報告的是 RefCOCO 系列的平均值，騰訊報告的是用於指稱偵測的 RefCOCOg 測試 F1。把兩者相減，只會得到一個沒有指涉對象的數字。

同樣的陷阱也存在於 OCR 中。LFM3-VL-2B 在 OCRBench v1 上得分 86.3，該基準綜合了文字辨識、文字偵測與推理；WeVisOne-VL-4B 在 TotalText 這個場景文字定位基準上取得 52.0 的平均 F1。一個是範圍廣泛的考試，另一個是稠密預測任務。它們並不是同一種技能被測量兩次。

所以這兩份廠商表格並沒有在同一個對等數字上交集。能誠實比較的是能力與成本，這也是為什麼這項比較的其餘部分談的是契合度而非排名。任何人想從這兩份表格中發布一個贏家，都只是在憑空捏造。

記憶才是真正的代價

截至 2026 年 10 月 28 日，這兩個模型都沒有公布每 token 價格。Liquid 的模型卡連結到可透過其主控台使用的 API 與 Playground 存取權，但並未公布 LFM3-VL-2B 的費率表；列出 Liquid 文字模型費率的第三方追蹤網站並未涵蓋該視覺模型。騰訊則完全沒有託管端點。因此，這項比較是自行託管比較，而帳單是以記憶體計價。

• LFM3-VL-2B — 依參數數量推算，BF16 下約 3.84 GB，並同步發布 4 位元 MLX、GGUF 與 ONNX 版本

WeVisOne-VL-4B — 依第三方估計，BF16 下約 9.7 GB，F32 下約 19 GB，另加必要的 mask_decoder.pt

那個 2.5× 差距不只是 GPU 更大而已。它代表的是不同級別的裝置。LFM3-VL-2B 的規格頁明確指出，該模型是為裝置端工作而打造——關於影片、文件、圖表和應用程式畫面的提問、尋找物件、機器人的空間推理——而 MLX 4-bit 與 GGUF 版本正是兌現這項承諾的方式：筆電、手機、機器人底盤。WeVisOne-VL-4B 記載的途徑是 BF16 上的 Transformers、vLLM 與 SGLang，沒有官方量化版本，也沒有裝置端執行環境。它需要伺服器 GPU。

框架支援這點，值得拿你自己的路徑來核對，而不是只看表格。在 LFM3-VL-2B 中，2 fps 的影片是模型本身的能力，但某個執行環境是否接受影片網格則是另一回事；而且模型卡、移植版本與上游 PR 在這點上未必總是一致。請測試你打算實際交付的確切組合。

OrcaRouter 並未託管這兩個模型。此事是於 2026 年 10 月 28 日對照型錄查證所得，並非假設——Liquid 的 LFM3 系列與騰訊的 WeVisOne 皆未出現在模型清單中——因此此處任何內容都不應被解讀為通往兩者的途徑。OrcaRouter 模型型錄確實收錄的是Qwen3-VL-8B，提供 instruct 與 thinking 兩種變體；若您真正的需求是當下已有公開定價的託管視覺模型，而非自架檢查點，這便是務實的選擇。一組金鑰即可觸及全部，按供應商定價計費、不加價；而若您正以尚未驗證的開放權重模型進行原型開發，透過具備容錯移轉的路由器來執行，勝過將生產路徑接上一個尚未經過獨立評估的檢查點。

該選哪一個

• 當交付成果是幾何資訊——遮罩、alpha matte、密集邊框、計數、指向——且用於靜態影像，當查詢是以語言為條件而非以邊框提示，且有餘裕的 GPU 可用時，選擇 WeVisOne-VL-4B

• 當你的任務是在一般場景上進行框提示式去背時，請選用 WeVisOne-VL-2B 而非 4B；根據已公布的數據，較小的模型在這方面表現更好，且所需記憶體不到一半

• 當輸入包含影片、文件很長、答案需要是句子而非多邊形，或裝置不是伺服器時，請選擇 LFM3-VL-2B

• 如果你本週需要一個已公布每 token 價格的託管端點，兩者都別選——兩家供應商都沒有提供，再多的基準測試也無法彌補這個落差。

• 唯有在您接受兩套輸出結構與兩條整合路徑時，才同時選用兩者；共通的「約 2B 到 5B」參數區間，掩蓋了兩款不同的產品

什麼會改變這個

三件事。一套獨立的測試框架，讓兩個模型在同一批影像上、以相同的提示詞運行——在那之前，上述一切都只是被仔細讀過的廠商表格；這比粗心地讀廠商表格要好，但並不是品質的證據。一個量化版的 WeVisOne 建置，或是一套裝置端執行環境，這會讓記憶體方面的論點從決定性變成可商榷。以及任一方公布的每 token 價格，這能用一個可以據以編列預算的數字，取代關於 GB 的算術推演。

三者中最不可能發生的，卻是對這個特定組合最關鍵的一項：WeVisOne 像素解碼器中的影片支援。目前 2B 通用模型能接收影片，4B 專用模型則不能，而再多的參數量也無法修補一個從未訓練過的模態。