LFM3-VL-2B 對比 UI-Venus 2.9B：其實是 9B 的 2.9B

並沒有名為 UI-Venus 2.9B 的模型。位於 inclusionAI/UI-Venus-2-9B 的檢查點是 UI-Venus-2-9B——螞蟻集團 UI-Venus 代理的第二版，擁有 90 億個參數，基於 Qwen3.5-9B 建構。目錄名稱讀起來像小數，但並不是小數。相較於 LFM3-VL-2B 的 19.2 億個參數，這使得這是一場披著 2B 對 2B 標籤的 2B 對 9B 比較。

這個錯誤之所以重要，是因為它改變了問題本身。如果兩個模型大約都是 2B，你會比較基準測試的列，然後選出較好的那個。在 9B 對上 2B 的情況下，較小的模型並非在同一硬體上競爭，而較大的模型根本不是通用視覺模型。UI-Venus-2-9B 是一個 GUI 代理，經過訓練可根據螢幕截圖操作手機、瀏覽器與桌面。LFM3-VL-2B 是一個通用視覺語言模型，恰好在其 62 項基準測試中包含一個 GUI 類別。兩者的重疊範圍比名稱所暗示的更窄。

名字是怎麼被弄亂的

螞蟻集團的命名慣例是family-version-size。UI-Venus-2-9B 會解析為 UI-Venus、第 2 代、9B 參數。若目錄或雷達按連字號切分並尋找小數點，就會把「2-9」讀成「2.9」，這就是為什麼一個 9B 模型最後會被歸在 2B 模型旁邊。同樣的慣例也產生 UI-Venus-2-27B，這個更大的同系列模型，而兩者於 2026 年 8 月下旬一同發布。

這不是表面性的小錯。參數數量是每個部署決策的第一道篩選，而一位預期看到 2.9B 模型的讀者，會對一個 18.8 GB 的 BF16 檢查點感到意外，因為它放不進他原先設想的裝置。該儲存庫自身的中繼資料明確無誤：Qwen3.5-9B 架構、BF16、影像-文字轉文字。

兩項工作，不是兩種尺寸

LFM3-VL-2B 可接收文字、圖像與每秒 2 幀的影片，並產生文字；它支援思考模式，並具備涵蓋 16 種語言的 128K 上下文。它是通用型模型：文件、圖表、定位、具身推理、GUI 理解與影片都列在其模型卡的分類中。Liquid AI 於 2026 年 10 月 19 日在 Hugging Face 發布它，並於 10 月 27 日宣布該系列；未列出 API 價格，也未列出推論供應商。

UI-Venus-2-9B 會接收螢幕截圖與任務描述，並在封閉的觀察–推理–行動迴圈中回傳下一個動作。它的訓練分為三個階段：先以涵蓋 170 多個行動應用程式與 4,000 多個網域的模擬軌跡進行多模態中期訓練；接著在涵蓋元素定位、CAPTCHA、行動、網頁與電腦任務上進行離線逐步強化學習；最後透過多教師同策略蒸餾整合為單一策略。它可在 vLLM 上執行，搭配 OpenAI 相容端點與 Qwen3 推理剖析器。這是代理執行環境，不是圖說模型。

實際影響是：你不能把它們互換。LFM3-VL-2B 會描述螢幕截圖並回答相關問題。UI-Venus-2-9B 會決定下一步要點哪裡，而且它需要專案 GitHub 儲存庫中周邊的測試框架——動作解析器、提示詞、範例——才能發揮作用。

唯一對得上的基準

兩個模型都報告了 ScreenSpot-Pro，這是比較具有正當性的罕見情況。LFM3-VL-2B 在開啟思考時得分 55.5，未開啟時得分 49.3。UI-Venus-2-9B 得分 73.0。這代表幾乎大五倍的模型領先 17.5 分，也是這場對決中最明確的單一數字。

不要將其延伸至其餘的 GUI 敘事。UI-Venus-2-9B 也回報 AndroidWorld 80.2、OSWorld-Verified 70.8、WebVoyager 90.8、Online-Mind2Web 74.0 和 VenusBench-GD 77.1。LFM3-VL-2B 回報在另一組不同任務上的 GUI 類別平均為 83.1，而類別平均不等同於單一基準的得分。這些類別無法互相比較，也不應相減。

UI-Venus 卡片上有一個數字值得特別指出，因為它與標題結論相悖：在 OSWorld 2.0 上，該模型在二元指標上得分 0.0，在部分指標上得分 7.5。無論測試框架的問題是什麼，一個在 OSWorld-Verified 上領先、卻在後繼基準上得分接近零的 9B 代理，就是一個有邊界的模型，而卡片誠實地報告了這一點。

衡量不同事物的上下文視窗

UI-Venus-2-9B 回報最高可達 256K 個 token 的上下文，而真正有用的是該上下文所容納的內容：一連串螢幕截圖的歷史紀錄，讓代理能記得四步之前的畫面長什麼樣子。LFM3-VL-2B 回報 128K，而其說明卡並未載明影像 token 預算或最大影片長度。這兩個數字都無法告訴你，在模型遺失第一張截圖之前，你可以在一個迴圈中保留多少張截圖。兩者都需要在你自己的解析度與步數設定下實測。

性質上的差異仍然重要。冗長的截圖歷史，是對一個運行數分鐘的代理所提出的記憶需求。通用 VLM 上的 128K 上下文，則是文件或影片的需求。這些數字看起來相當，卻在回答不同的問題。

部署：4 GB 對比 19 GB

LFM3-VL-2B 有 1.92B 個參數，以算術推算，BF16 權重約 3.84 GB，且已發布 GGUF、MLX 4 位元與 ONNX 版本。UI-Venus-2-9B 在 BF16 下約 18.8 GB，並透過 vLLM 提供服務；雖然有社群版 GGUF，但廠商的服務路徑假設 GPU 有足夠空間容納完整檢查點。兩者並非競爭同一個定位。一個是邊緣運算候選方案；另一個是伺服器端代理。

真正讓這個組合有趣的是那個差異，而不是基準測試的差距。想在裝置上實現 GUI 理解的團隊，在這裡恰好只有一個選項。想要擁有接近最先進分數的 GUI 代理的團隊，則有另一個選項，而且需要 GPU 才能運行它。

無人回答的許可證問題

LFM3-VL-2B 採用 LFM Open License v1.0：只有在被授權方的年營收低於 1,000 萬美元時，才授予商業使用授權。這雖然具限制性，但條文清楚易讀，而且已公開發布。

UI-Venus-2-9B 的情況較不明確。該專案的程式碼儲存庫標示為 Apache 2.0；模型卡則指出，由於上游陳述相互矛盾，權重授權仍在等待最終確認。截至 2026 年 10 月 28 日，此事尚未解決。授權待定對研究而言並非阻礙，但對商業部署來說卻是實實在在的阻礙，因為商業部署必須在出貨前了解其條款。任何打算以 UI-Venus-2-9B 為基礎進行開發的人，都應取得書面答覆，而非從儲存庫標籤推斷。

OrcaRouter 適合放在哪裡（如果有的話）

OrcaRouter 兩個檢查點都不提供，而本文也未主張我們有提供。我們真正擁有的是路由 DSL，能將多個模型組合成一次呼叫——這在這裡很有用，因為自然的架構並不是「只挑一個」。小型通用 VLM 可以讀取畫面，判斷任務是文件問題還是互動操作；較大的 GUI 專家則可以負責互動步驟。依任務類型在兩者之間路由是一項設定，而不是第二次整合。

這是更誠實地運用這項比較，而不是假裝這兩個模型是替代方案。它們是同一條管線的兩個階段，彼此之間有 5 倍的參數差距。

你真正想要哪一個？

• LFM3-VL-2B如果任務是理解而非執行，如果你需要影片或文件輸入，或者模型必須在大約 4 GB 的記憶體中執行。接受有營收上限的授權，以及 Liquid 以外沒有人評估過它的事實。

• UI-Venus-2-9B：若這項工作是端到端操作介面，且你能提供 19 GB 的 GPU 記憶體與 vLLM 服務堆疊，並能等待權重授權確認，就選它。要接受它是配有測試框架的專精模型，而非通用助理。

• 兩者皆非 如果你想要的是 2.9B 模型。該模型並不存在，而兩個實際選項都比名稱所暗示的更為專門。

更正才是重點。資料夾名稱裡的參數數量並不是規格，而在這個案例中，它掩蓋了五倍的大小差異，以及完全不同的用途。先讀架構欄位，再讀 slug。