LFM2.5-VL-3B-DSpark 對決 UI-Venus 2.9B：速度倍增器對上 GUI 代理

LFM2.5-VL-3B-DSpark 和 UI-Venus 2.9B 被歸到同一個含糊的標題之下——小型視覺模型——然後被拿來互相比較，這是一種範疇錯誤，值得在它害某人賠上一週整合時間之前先修正。LFM2.5-VL-3B-DSpark 是一個 279.5M 參數的草稿模型，用來加速 Liquid AI 的 LFM2.5-VL-3B。UI-Venus 2.9B 來自螞蟻集團旗下 inclusionAI 實驗室，是一個 9B 的 GUI 代理，會讀取螢幕截圖、決定動作，並在行動裝置、網頁和桌面環境中執行該動作。一個讓現有模型跑得更快。另一個才是真正在做事的東西。如果你需要的是 GUI 代理，草稿模型並不是更便宜的選項——它根本算不上是個選項。

有用的比較不在於哪個更好，而在於各自解決什麼問題，以及各自會讓你在過程中付出什麼代價。兩者也都是新近出現、而更廣泛生態系尚未跟上的事物；此外，它們的儲存庫所宣稱的內容與其他人實際驗證的內容之間的落差，其中一方比另一方更大。

確切地說，每一個究竟是什麼

先從這些形狀開始，因為它們解釋了其餘的大部分。

• 這是什麼 — LFM2.5-VL-3B-DSpark 是一款推測解碼（speculative decoding）草稿模型；UI-Venus 2.9B 則是通用型 GUI 代理策略

• 參數 — 草稿模型為 279.5M BF16，對比由 Qwen3.5-9B 初始化的 UI-Venus 2.9B 之 9B

• 獨立能力——草擬器單獨運作時無法產生任何可用內容，也無法單獨進行基準測試；UI-Venus 2.9B 則以完整代理的形式運行

• 輸入 — 草稿模型從不直接看到圖像本身，只看得到目標模型的隱藏狀態；UI-Venus 2.9B 則直接接收螢幕截圖，且完全圍繞這些截圖打造

• 輸出 — 草擬器提出待驗證的 token；UI-Venus 2.9B 則針對實際運作中的介面，輸出附有邊界框的接地動作

• 基礎 — 草稿模型在其自身的中繼資料中繫結至 LiquidAI/LFM2.5-VL-3B；UI-Venus 2.9B 則建構於 Qwen3.5-9B 之上

• 脈絡 — 草擬器會繼承目標模型所提供的一切；UI-Venus 2.9B 在廠商自家的 vLLM recipe 中是以 262,144 個 token 為上限提供服務

• 授權 — 兩者各自以不同方式懸而未決；Liquid 以 LFM1.0 授權條款發布，而 UI-Venus 2.9B 的模型卡直接表明其權重授權仍待最終確認

最後那一點是值得放慢腳步仔細看的。我們自己八月底對 UI-Venus-2-9B 的報導，將該發布描述為 Apache-2.0，因為當時該專案的資料就是這樣標示。今天的模型卡說法不同，而且更加強硬：模型權重授權正待最終確認，並會在公開發布前補上；而且 Apache-2.0 的宣告是刻意未沿用，因為目前的上游資料含有相互衝突的授權聲明。如果你正計劃對 UI-Venus 2.9B 進行商業部署，授權問題依廠商自己承認仍懸而未決，而這是重大風險，不是腳註。

雙方各自實際公布的數字

這兩個儲存庫衡量的是不同的東西，而這正是重點。Liquid 公布的是吞吐量；螞蟻集團公布的是任務成功率。

以草稿模型而言，根據 Liquid 自家的測試框架：在單張 H100 80GB 上以 BF16 透過 SGLang 執行，解碼最高可加速 2.66 倍；在 Apple M5 Max 上使用 MLX-VLM 最高可達 3.13 倍；在 M3 Ultra 上使用 llama.cpp 最高則為 2.14 倍。就端到端而言，同樣的測試在 1.30 倍到 2.62 倍之間，取決於堆疊與任務。草稿接受度約為每次驗證通過 3.2 到 4.5 個 token。上述每一項數據皆由廠商自行測量，並無外部重現。

對於 UI-Venus 2.9B，其模型卡自身的表格回報：AndroidWorld 上為 80.2、50 步預算下的 MobileWorld 上為 65.8、OSWorld-Verified 上為 70.8、DeskCraft 上為 48.0，而在重新整理的 595 項任務切分中，WebVoyager 上為 90.8、Online-Mind2Web 上為 74.0、ScreenSpot-Pro 上為 73.0，以及 VenusBench-GD 上為 77.1。在 CAPTCHA 方面，它回報 VenusBench-CAPTCHA 上為 78.1、MCA-Bench 上為 75.7。在安全性方面，它回報 OSHarm 上的攻擊成功率為 11.3%，相較於其 Qwen3.5-9B 基礎模型的 25.3%。以上全數為廠商自行回報，部分基線帶有星號，表示 UI-Venus 作者是在所述協定下對其進行評估，而模型卡本身也警告：OSWorld-Verified 的比較使用各模型專屬的動作鷹架，應被解讀為基準層級的參考值，而非受控的消融實驗。

注意兩份清單中都缺少了什麼：任何由第三方衡量的項目。對 drafter 而言，這是因為檢查點已有數日之久。對 UI-Venus 2.9B 而言，這是因為 GUI 代理基準測試的重現成本高昂，而且即時環境結果會隨評估當日環境的狀態而變動——這是該模型卡主動提出的但書。

兩者真正交會之處

確實有重疊，而且比類別標籤所暗示的還要窄。如果你正在建構裝置端或邊緣視覺代理程式，兩者都與你相關，而且兩者都關注讓像素通過模型的成本。它們從相反的兩端切入處理。

UI-Venus 2.9B 以訓練來攻克它：一套三階段流程——在模擬的行動、網頁與作業系統環境上進行多模態中期訓練，接著是各領域的離線 RL，然後透過多教師同策略蒸餾整合成單一策略。所發布的能力就是成果。該模型為 9B，這對 GUI 代理而言算小，對邊緣裝置而言則算大，而該卡片預定的服務配置是 vLLM 部署——同一份文件指出，該配置在卡片更新時並未經過上線金絲雀驗證，並提醒你在部署前先固定並驗證你用於 Qwen3.5 的 vLLM 版本。

LFM2.5-VL-3B-DSpark 以執行階段手法來應對它：它不更動目標模型的權重，並透過草擬與驗證詞元來換取速度。在手機級裝置上，這筆交易一面倒地對草擬器有利，因為輸出可證明是目標模型的，而額外記憶體不到一個模型的十分之一。

對任何做出選擇的人來說，後果是：代理迴圈會讓每項任務進行多次模型呼叫，而每一次呼叫都得為一張全新的螢幕截圖支付預填充成本。視覺編碼與預填充正是推測解碼無法加速的階段——Liquid 自家的發布說明也正是以此論點，反對對其頭條數字做出無限上綱的解讀。因此，草稿模型的優勢恰恰會在 UI-Venus 2.9B 所處的那類工作負載中縮水。反過來說，UI-Venus 2.9B 的優勢——真正完成任務——並不是草稿模型在任何速度下所能提供的。

執行這兩個

兩者都不是 OrcaRouter 上的託管端點。LFM2.5-VL-3B-DSpark 與 UI-Venus 2.9B 都要求你自己拉取權重並自行部署服務，而它們的部署方式也因各自截然不同的角色而有所差異。草稿模型需要 SGLang v0.5.19 或更新版本，並搭配 DSPARK 推測演算法旗標與區塊大小 9；或者 MLX-VLM v0.7.2 或更新版本，將草稿模型以 draft model 傳入並強制將 temperature 設為零；或者使用 llama.cpp，搭配 567 MB 的 F16 GGUF 並與量化後的目標模型配對。UI-Venus 2.9B 需要一部足以在 262,144 個 token 最大長度下運行 9B 模型的 vLLM 伺服器，還需要專案程式碼儲存庫中的參考提示與動作解析器——模型卡明確指出，單靠啟動伺服器並不能讓你得到可運作的閉環 GUI 代理。

兩者在能力邊界上也留下同樣的缺口。搭配草稿模型的小型視覺語言模型，仍會遇到無法處理的畫面與任務；而 GUI 代理程式在訓練分布之外的環境中依然會失敗。那些漏接的查詢總得有個去處，而在多數正式環境的設計中，那就是更大的通用模型。將這些查詢透過單一端點路由，涵蓋 200 多個模型，皆依各供應商的定價計費，並在供應商服務劣化時自動容錯移轉，就能讓備援路徑不必列入關鍵整合清單，而不是把它變成另一個得自管金鑰與合約的部署專案。

如何在一分鐘內做決定

如果你需要的是能操作使用者介面的軟體——點擊、輸入、在它從未見過的應用程式中瀏覽——你買的是一套策略，那就是 UI-Venus 2.9B。請為 9B vLLM 部署編列預算，在商業採用前先閱讀尚未解決的授權問題，並將廠商的基準測試表視為強而有力的起始假設，而非已成定論的結果，尤其是模型卡本身標示為取決於 scaffold 的 OSWorld-Verified 比較。

如果你已經在執行 LFM2.5-VL-3B，並想讓它在你自己擁有的硬體上跑得更快，那你買的其實是執行階段最佳化，也就是 LFM2.5-VL-3B-DSpark。請先確認三件事：你的工作負載以解碼為主，而非以預填充為主；你是在 16 位元下提供服務，而不是使用 4 位元匯出檔；以及你的執行階段符合版本下限。如果這三項都成立，記憶體成本是 8.9%，而且輸出在設計上維持不變。

與這兩個儲存庫接觸之後，唯一無法存活的，就是把它們當成彼此的替代品。它們是速度倍增器，也是代理程式；而它們唯一會相互競爭的情境，就是你已經決定好要打造什麼，並且正在尋找理由改做更便宜的方案。

OrcaRouter 透過單一金鑰即可觸及 200 多個模型，以供應商定價提供、零加成，並為邊緣模型或代理程式不該處理的查詢提供路由與自動容錯移轉。一個用於備援路徑本頁的兩個模型都不是託管在那裡——兩者都是由你自己的權重所提供——但備援路徑正是你不必自行建置的部分。