WeVisOne-VL-4B 對上 LFM2.5-VL-3B：影像去背專家迎戰邊緣運算速度型選手

Liquid AI 為 LFM2.5-VL-3B 公布了速度數據，而騰訊則完全沒有為 WeVisOne-VL-4B 公布任何數字。這種不對稱——勝過任何一行基準測試成績——正是這場對決的關鍵。LFM2.5-VL-3B 是一款 3.1B 參數的邊緣模型，調校成單次推理就能作答：在 Apple M5 Max 上每秒 228 個 token，在 Galaxy S26 Ultra 上每秒 20 個 token，記憶體佔用低於 3.3 GB，支援十六種語言。WeVisOne-VL-4B 則是 4.83B 參數的感知模型，會耗用多達 1,960 個視覺 token 與一個 9.6M 參數的解碼器，交給你一張全解析度的 alpha 遮罩。一款是為了快到能進駐手機 UI 而打造；另一款則是為了輸出像素而打造。兩者的重疊只在「vision」這個詞上，幾乎別無其他。

這使得這項比較值得謹慎進行，因為最顯而易見的做法——把基準測試表格並排擺放，然後宣布贏家——會以一種具體且具啟發性的方式出錯。

基準測試表格彼此之間並不互通。

兩個模型都公布了指稱表達式的數字，兩個數字看起來相當。其實並非如此。LFM2.5-VL-3B 報告的 RefCOCO-avg P@1 為 87.9。WeVisOne-VL-4B 報告的 RefCOCOg test F1 mean 為 81.8。不同的資料集切分、不同的指標、不同的失敗模式：P@1 問的是排名最高的框是否正確，F1 mean 則是對 IoU 閾值從 0.5 到 0.95 的平均精確率與召回率。一個模型可以在其中一項勝出，卻在另一項大幅落敗，而這兩個結果都不會令人意外。

同樣的陷阱存在於其他每一列。Liquid 在 ScreenSpot-v2 上的 80.7 衡量的是 UI 元素定位；Tencent 沒有 ScreenSpot 數字。Tencent 在 WeRef-Bench 上 96.4% 的拒答率衡量的是當物件不存在時模型是否拒絕作答；Liquid 完全沒有公布拒答指標。兩家廠商都沒有評估對方的模型，因此兩張表中的任何一列都不是正面對決。

可以誠實地說，這只是方向性的。LFM2.5-VL-3B 在同尺寸中是很強的通用型模型——依 Liquid 自己的計算，在 28 項視覺基準上平均 69.4，與 Qwen3.5-4B 相差 0.7 分以內——而它在 ScreenSpot-v2 上從前一代近乎零躍升至 80.7，是其表格中最大的單一進步。WeVisOne-VL-4B 並不是在這個軸線上競爭。它最強的主張在於密集小物件偵測、拒答，以及像素級輸出，而這些都不是 LFM2.5-VL-3B 所嘗試的。

每個模型在物理上是什麼

• 參數 — WeVisOne-VL-4B 4.83B 稠密（F32 檢查點）對比 LFM2.5-VL-3B 3.12B 稠密（BF16）

• 視覺路徑 — Qwen3-VL 主幹加上 9.6M 像素解碼器，對比 LFM2.5-2.6B 混合卷積-注意力文字基礎模型加上 SigLIP2 NaFlex 400M 編碼器

• 記憶體 — F32 4B 檢查點在磁碟上約 19 GB，而 3B 的總佔用空間不到 3.3 GB

• 背景 — WeVisOne-VL-4B 並無公開數據，相較之下 LFM2.5-VL-3B 為 32,768 個 token

• 語言 — WeVisOne-VL-4B 未說明，而 LFM2.5-VL-3B 為 16，並具備專為非拉丁文字建構的 128K 詞彙表

• 輸出類型 — 邊界框、點、遮罩與 alpha 遮罩，對比僅邊界框與文字

• 授權 — 騰訊撰寫的程式碼採用 Apache 2.0，對比 LFM 開放授權 v1.0

• 速度 — 未公開，對比 M5 Max 的 228 tok/s、Ryzen AI Max+ 395 的 116 tok/s、Galaxy S26 Ultra 的 20 tok/s

真正決定勝負的能力差距

{{1}}LFM2.5-VL-3B{{/1}} 能告訴你影像中的人在哪裡。{{2}}WeVisOne-VL-4B{{/2}} 能告訴你一個人在哪裡、針對該實例傳回二值遮罩，並以全解析度傳回具柔和邊緣的連續 Alpha 遮罩——包括頭髮、毛皮、薄透布料與動態模糊。這是類別上的差異，不是品質上的差異。如果你的產品需要將主體合成到新背景、為產品照片去背，或執行視訊通話的背景替換，LFM2.5-VL-3B 完全幫不上忙，再多的提示工程也改變不了這一點。

反過來做比較，結果也一樣。如果你的產品需要在 40 毫秒內在手機螢幕上找到一個按鈕，WeVisOne-VL-4B 完全不適合：它是 4.83B 模型，沒有公布延遲數據，沒有量化邊緣版本，而且解碼器假設每輪只有一張影像。Liquid 提供 GGUF、MLX、ONNX 與原生版本，還有 32K 上下文與工具呼叫基準測試。Tencent 則提供研究用推論套件以及 vLLM/SGLang 服務。

拒絕是被低估的專欄

騰訊那張表上有一項能力值得注意，即使你從不接觸去背（matting）。在 WeRef-Bench 上，WeVisOne-VL-4B 對圖片中不存在的物件查詢，正確拒絕率達 96.4%，而作者列出的最佳基準模型為 73.0%；在 PR-Bench 上，拒絕率為 52.6%，Qwen3-VL-4B 則為 10.8%。模型會回傳 None，而不是憑空編造一個邊界框。會產生幻覺的偵測器比沒有偵測器更糟，因為這種失敗是無聲的，而下遊程式碼卻會信任它。

LFM2.5-VL-3B 的文件並未回報拒絕率數字，因此沒有可供比較的基準——而這正是重點所在。缺乏證據並不代表失敗，但如果你正在打造一個會決定是否點擊某個東西的代理，那麼一份經過實測的拒絕率，就是一個確實值得先看看騰訊那款模型的理由。

授權是那靜默的差異化關鍵

這正是兩者分歧之處，而且對任何要商業出貨的人來說都很重要。WeVisOne-VL-4B 的權重對騰訊撰寫的程式碼採用 Apache 2.0，第三方元件則保留其自身條款。LFM2.5-VL-3B 以 LFM Open License v1.0 發布，在營收門檻以下可免費商用，超過門檻則需簽訂商業協議。如果你是小團隊，這個差異只是學術上的；如果你不是，其中一個會是法務審查，另一個則只是相依性檔案裡的一行。

兩個授權都沒有授予你託管服務。WeVisOne-VL-4B 完全沒有 API；LFM2.5-VL-3B 是權重釋出，任何第三方託管都是另行安排。把這件事講清楚，比以往任何時候都更重要，因為一個沒有端點的模型，就是對自行擁有推論堆疊的承諾。

OrcaRouter 適合的地方，以及不適合的地方

這兩個模型目前都不在 OrcaRouter 的目錄中，所以這裡並沒有任何能呼叫它們的途徑。這個平台真正提供的，是圍繞這項選擇的整體決策支援。多數在評估 3B edge VLM 的團隊，並不是要用一個模型取代另一個模型——他們是在已投入生產的通用模型之外，再加第二個模型；而第二份供應商合約、第二把金鑰與第二種故障模式所帶來的營運成本，往往會在模型本身讓實驗失敗之前，就先讓實驗夭折。

將這兩種意圖都透過同一個端點路由，並搭配單一金鑰背後有超過 200 個模型，且以供應商定價零加價，這代表感知模型可以是一項路由決策，而不是一個整合專案。若邊緣模型無法使用，自動容錯移轉會將請求送往其他地方，而不是回傳 503。這正是 OrcaRouter 在此實際解決的部分；權重和 GPU 仍然由你負責。

該選哪一個

如果工作任務受延遲限制且以文字為主，就選擇 LFM2.5-VL-3B：螢幕理解、UI 代理、具版面配置的文件 OCR、裝置端翻譯、工具呼叫。它在同等規模中幾乎比任何模型都快，能在手機的記憶體預算內運行，而且 Liquid 已公布足夠的數據，讓你以自己的工作負載核對這些說法。

如果任務最終產出是像素，就選 WeVisOne-VL-4B。分割、去背、密集偵測小物件，或任何「模型說沒有」必須是可靠答案的流程，都適合。但要接受你是早期採用者：沒有獨立的基準測試結果、沒有託管端點、微調程式碼還在待辦清單上，而且論文才發表兩天。

唯一不該做的事，就是只憑一項基準測試分數在兩者之間做取捨。從來沒有人用相同的資料，讓他們彼此對照測量過。