一張生成的主視覺卡片,標題為「WeVisOne-VL-2B 與 LFM2.5-VL-3B」,副標題為「一個能將物件去背,一個能讀懂螢幕。」,畫面左側卡片是標示為「遮罩」的貓咪剪影遮罩,右側卡片是手機螢幕與標示為「框選」的醒目按鈕,中央標籤則寫著「不同輸出」。
Guides & Insights

WeVisOne-VL-2B 對決 LFM2.5-VL-3B:遮罩製造者對上螢幕閱讀器

作者

Rowan Sterling

發佈日期

最新模型 · 20查看全部模型 →
基準測試:Artificial Analysis · 每日更新
返回全部文章

給兩個模型同一張照片和同一句話——「左邊的狗」——回傳的卻是兩種不同的結果。LFM2.5-VL-3B 會回答一個位置,若你要求,也會給出描述:一個邊界框、一個點,或一句關於它找到什麼的簡短句子。WeVisOne-VL-2B 也會回答一個邊界框,接著再由一個小型解碼器把那個框轉成柔和邊緣的 alpha 遮罩,讓你能合成到新背景上,而不會在毛髮周圍留下光暈。一個模型是為了讀取介面並回覆而打造。另一個則是為了把像素交到你手上而打造。

那個差異正是整場比較的核心,而且在兩家廠商已發布的每一張基準測試表中都成立。它也說明了為什麼這兩個模型很少被相互評估:Liquid AI 的說明卡未提及 WeVisOne,Tencent 的論文未提及 Liquid,且沒有第三方將它們並排實測。以下內容是各次發布實際留下的紀錄、其中哪些數字可以彼此並列對照,哪些則不能。

兩個版本,兩種截然不同的證據份量

LFM2.5-VL-3B 由 Liquid AI 於 2026 年 8 月 11 日發布——先釋出權重,隔日才公告——並隨附數值基準測試表、每一列都有具名基準,以及在具名硬體上測量的速度章節。它是個 31.2 億參數的稠密模型:以 LFM2.5-2.6B 語言主幹搭配 SigLIP2 NaFlex 400M 視覺編碼器、32,768 個 token 的上下文、128,000 個 token 的詞彙表,以及十六種具名語言。其授權為 Liquid 自家的 LFM Open License v1.0,在營收門檻以下可免費商用,而非無條件免費。

WeVisOne-VL-2B 由騰訊微信視覺團隊於 2026 年 10 月 22 日發布,其模型卡完全沒有基準測試表——沒有分數、沒有上下文長度、沒有吞吐量數據、沒有硬體需求。這些數字確實存在,但放在隨附論文中,論文報告了七個任務表格,涵蓋作者所稱的三十多個基準測試。因此,這兩個發布不只是不同的模型,而是不同類型的文件。Liquid 發布的是產品規格;騰訊發布的是研究成果,規格表大多留白。

這種不對稱在你閱讀像這樣的比較時就很重要。Liquid 的數字是為了對照自身基準而彙整的。騰訊的數字則是為了在學術表格中勝出而彙整的。兩家廠商在挑選數字時,都沒有把對方的模型納入考量,這正是這些數字對不上的原因。

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

兩個模型都公布了 RefCOCO 分數,而把它們並排放置,就會得出一個看起來很漂亮的頭條結論:LFM2.5-VL-3B 為 87.9,對上 WeVisOne-VL-2B 的 79.7。這種比較毫無意義,值得逐一拆解原因,因為現在試算表裡正有人犯下同樣的錯誤。

• Liquid 報告 RefCOCO precision@1在多個資料分割上取平均。那是一項偵測統計量:排名最高的預測框是否與真實標註框重疊到足以判定為正確。

• 騰訊的 79.7 出自一份分割表格,而論文明確指出,該表中的 RefCOCO 系列數字是累積 IoU——即整個評估集上的總交集除以總聯集。

• 騰訊的指稱偵測表格完全沒有報告 RefCOCO。它報告的是 RefCOCOg,其中 2B 的平均 F1 得分為 77.1。

所以,87.9 和 79.7 在兩個不同的任務中衡量了三種不同的東西。一個與目標幾乎不重疊的框,在 precision@1 上可以得分很高,但在 cIoU 上得分很低;一個能很好地覆蓋大型物件的遮罩,可以在 cIoU 上獲得高分,而其邊界框卻不精準。沒有任何算術能調和它們。

同樣的陷阱也存在於 OCR。Liquid 公布的 OCRBench v1 為 84.2、OCRBench v2 英文版為 47.5——這些是轉錄基準。騰訊則將 OCR 公布為 0.5 IoU 閾值下的定位 F1:SROIE 上 62.1、ICDAR2015 上 42.6、TotalText 上 42.5、HierText 上 30.5。這些衡量的是模型是否找到文字並將其框出,而非是否正確讀出文字。引用「84.2 對 62.1」會是在拿閱讀測驗比指向測驗。

A generated two-column scoreboard titled 'WeVisOne-VL-2B vs LFM2.5-VL-3B — the scoreboard'. WeVisOne-VL-2B: Output masks, alpha mattes; Parameters 2B + 9.5M decoder; Context not published; Licence Apache 2.0; Quantized builds none announced; Hosted API none. LFM2.5-VL-3B: Output text, boxes, points; Parameters 3.12B dense; Context 32,768 tokens; Licence LFM Open License v1.0; Quantized builds GGUF, ONNX, MLX; Hosted API none. Footer: 'Both vendors' figures; no shared benchmark and no independent run.'

什麼才算是真正公平的比較?

剔除分數後,這兩個模型在不需要測試框架的維度上保持一致:

• 大小 — LFM2.5-VL-3B 約有 3.12B 稠密參數,而 WeVisOne-VL-2B 約有 2B,另有一個 9.5M 參數的解碼器,必須另行下載,且為產生稠密輸出所必需。

• 基礎版 — Liquid 自家 LFM2.5-2.6B 混合主幹 vs Qwen3-VL。

• 上下文——產品卡上公布的是 32,768 個 token,而完全沒有公布上下文長度。WeVisOne 論文的訓練階段分別以 4,096 與 8,192 個 token 執行,推論時每張圖片上限為 1,960 個視覺 token,但這些都不是部署時的視窗。

• 輸出類型 — 邊界框、點與文字,對比邊界框、點、二值遮罩與連續 alpha 遮罩。

• 推理 — LFM2.5-VL-3B 刻意採用非推理設計,直接回答以保持低延遲;WeVisOne 同樣是非推理,但原因不同:為了推論效率,不經思維鏈生成結構化輸出。兩個模型在回答前都不「思考」,兩家廠商也都未假裝不是如此。

• 工具呼叫 — 於 LFM 上受支援並經基準測試(ToolSandbox 59.5、BFCL v4 32.5),而 WeVisOne 則未將此列為能力。

• 語言 — LFM 卡片上列出十六種,而 WeVisOne 卡片未註明。

• 授權 — LFM Open License v1.0,設有營收門檻,相較於適用於 Tencent 撰寫程式碼的 Apache 2.0。

• 量化版本 — Liquid 提供 GGUF、ONNX 與 MLX 匯出,而騰訊則未宣布任何相關支援。

• 獨立評估——截至本文撰寫時,這兩個模型在 Artificial Analysis 上都還沒有收錄資料。本文中來自兩家廠商的每個數字,都是廠商自行提供的。

A screenshot of the WeVisOne-VL project page at tencent.github.io, captured 23 October 2026, showing the WeChat Vision · Tencent Inc. badge, the title 'Unified Visual Perception from Objects to Pixels', the eight author names, and buttons linking to Paper, Code, Weights (4B) and Weights (2B).

部署差距比參數差距更大

LFM2.5-VL-3B 專為在手機上運行而打造,而模型卡以數字證明了這一點:記憶體佔用低於 3.3GB,在 Galaxy S26 Ultra 上每秒可處理 20 個 token,在 Apple M5 Max 上每秒可處理 228 個 token,在 AMD Ryzen AI Max+ 395 上每秒可處理 116 個 token,並且在單張 H100 上高併發時每秒約可輸出 11,000 個 token。它提供消費級執行環境實際可載入的格式。

WeVisOne-VL-2B 完全沒有公開任何那類內容。它確實公開的內容,則暗示著另一筆代價。解碼器的最後階段會產生步長為 1 的全解析度 alpha matte,這表示稠密輸出的尺寸與輸入影像相同,而非固定大小的向量——這項成本會隨解析度而非參數量成長。對現代 GPU 上的 2B 模型來說,這還算可控。但對手機而言,這顯然完全不算可控,而騰訊也未曾聲稱它可控。

實際後果是,這兩個模型不會競爭同一個部署槽位。其中一個是可打包進應用程式裡的元件;另一個則是你會在伺服器或工作站上,與其他任何需要進行遮罩處理的項目並行執行的元件。

依輸出類型挑選,而非依分數

如果工作內容是讀取螢幕——解析結帳流程、尋找標示為「Continue」的按鈕、從拍攝的文件影像中擷取表格——LFM2.5-VL-3B 顯然是首選。它的 ScreenSpot-v2 為 80.7、DocVQA 為 91.1、ChartQA 為 81.3,而 ToolSandbox 分數則顯示它能依據所見內容採取行動,而不只是描述所見。它同時在 28 項基準測試中平均達 69.4,這是 Liquid 針對具名同系列產品所公布的數據,至少能讓你了解供應商認為自家產品所處的競爭區間是什麼樣子。

如果工作是要將物件獨立出來——產品去背、複雜背景中的人物、有飛散髮絲或透明邊緣的前景——LFM2.5-VL-3B 不會產生那樣的輸出,再怎麼提示也做不到。WeVisOne-VL-2B 可以,而且在去背評測表上的差距很大:在 P3M-500-NP 上,平均絕對差異為 6.6,相較之下 SAM2-Matting 為 15.4;在語言提示的 WeRefMat 分割集上為 15.8,相較之下 Qwen3-VL-8B 加 SAM2 管線為 23.0。

還有一個情況,WeVisOne 有一項值得注意的主張:缺席。騰訊在 RefCOCOg 上報告,對於目標不在影像中的查詢,拒絕率為 50.2%,而同一張表上兩個專門的定位模型分別為 0.5 和 0.6。如果你的管線要處理數千個裁切影像,而其中大多數不包含你關心的內容,一個能可靠地說「不在那裡」的模型就能幫你省下一個下游分類器。LFM2.5-VL-3B 的模型卡沒有報告可相比的拒絕率數字,因此沒有東西可以並列對照——這是證據上的缺口,不是損失。

這些都不是二選一、讓另一個退場的理由,而值得誠實面對路由器適合什麼位置。OrcaRouter 並不提供這兩個模型;兩者都不在我們的目錄上,而且尤其就 WeVisOne 而言,兩者也都沒有託管在我們能驗證的任何地方。我們提供的其實是周邊的整套技術堆疊:如果你的流程用託管的視覺模型負責「讀取」那一半,用自架模型負責「遮罩」那一半,託管的呼叫會透過單一 API 金鑰、以供應商定價、不加價送達,當某個供應商狀況變差時,容錯移轉會把它們移到另一個供應商,而路由 DSL 讓你把這兩半放在同一個端點後面,讓你的應用程式永遠不會知道是哪一個回答的。

A screenshot of the Hugging Face model page for LiquidAI/LFM2.5-VL-3B, captured 23 October 2026, showing the lfm1.0 licence tag, the 16 languages tag, 'Model size 3B params', tensor type BF16, 27,611 downloads last month, and the card's efficiency line reporting 228 tok/s on an Apple M5 Max and 116 tok/s on an AMD Ryzen AI Max+ 395 in under 3.3 GB of memory.

究竟什麼才能真正解決這件事?

一套由不屬於任一廠商的人所運行、在同一批影像上進行,並同時回報兩個模型的偵測統計指標與分割統計指標的獨立測試框架,目前並不存在。在它出現之前,站得住腳的立場就是那個乏味的立場:這些模型回答的是不同的問題,它們已發表的數字是用不同的工具測量出來的,而要在兩者之間做選擇,取決於你的下游程式碼預期收到什麼——一句話,或一個遮罩。

如果你只能從這份比較中帶走一件事,那就帶走證據的形狀。Liquid AI 給你的是你可以證偽的表格。Tencent 給你的是你可以閱讀的論文,以及一張坦白告訴你這個模型不會做什麼的卡片。兩者都沒有給你一個能與對方相比的數字,而任何把 87.9 印在 79.7 旁邊、卻不加註這個但書的文章,都是在賣你一個根本不存在的排名。