PixelUMM 與 UI-Mate-27B：一個模型畫出它所見，另一個則點擊它

Tencen​t UI-Mate-27B 與 NVIDIA PixelUMM 在規格表上看起來相當——270 億參數對上約 152 億，兩者皆可公開下載，且都建構在 Qwe​n 骨幹之上——但它們根本無法相提並論。UI-Mate-27B 是一個基礎 GUI 代理：它會觀察即時螢幕截圖，根據目前螢幕上的內容進行規劃，並對真實桌面發出結構化的滑鼠與鍵盤動作。PixelUMM 是一個無編碼器的統一多模態模型，會以原始像素空間讀取圖像與影片，並從文字生成圖像與影片——它能感知，也能創造，但沒有動作空間、沒有游標，也無法觸碰螢幕。前者對世界採取行動。後者則描述並描繪世界。以下一切皆源於這個分野，而兩者之間的授權落差，是你需要知道的第二件事。

兩家實驗室都各自公布自己的數據，而兩者都沒有獨立評估。兩者都低調發布——發布風格正是相似之處真正結束的地方。

行動者與知覺者

UI-Mate-27B 僅憑自然語言指令與即時螢幕截圖就能執行任務。它會對可見狀態進行推理，隨著介面變化重新規劃，並輸出推理內容、簡潔的動作描述，以及涵蓋滑鼠、鍵盤、捲動、等待、使用者互動與任務完成的結構化電腦操作工具呼叫。它與眾不同之處在於示範引導式執行：只要向它示範一次工作流程，它就會將錄下的示範調整套用至當下任務，並在介面已經改變時以當前螢幕截圖為準。它是以 Qwen3.6-27B 為基礎微調而成，先進行監督式微調，接著在可執行的 GUI 環境中進行線上強化學習，並透過 vLLM 以 OpenAI 相容介面提供服務。

• 回報的基準測試 — OSWorld-Verified 平均 77.0、WindowsAgentArena 平均 66.2、OSWorkerBench 嚴格成功率 41.00、進度 76.86。全數為騰訊回報，未經重現。

• 動作空間 — 滑鼠、鍵盤、捲動、等待、使用者互動、任務完成，在正規化座標空間中，搭配與 pyautogui 相容的結構化呼叫。

• 硬體現實 — 27B 稠密模型，在騰訊自家的快速入門指南中，以張量平行化跨兩張 GPU 提供服務，採用 Apache-2.0 授權。

• 關於這張卡片本身，有一點重要的提醒 —— UI-Mate-27B 是代理檢查點，而非獨立的視覺對話模型。Tencent 建議採用其儲存庫中的官方提示詞、回應解析器與互動測試框架。若拿它來執行「描述這張圖片」，那你就是用錯工具了。

PixelUMM 佔據了相反的極端。其整體架構就是對表徵的一項主張：沒有 VAE、沒有視覺編碼器，圖像化為 16×16 像素區塊，影片化為 4 幀時空管狀單元，透過單層線性投影直接送入僅解碼器的 Transformer，並採用 Mixture-of-Transformers 設計，將共享注意力與任務特定參數配對。理解是自迴歸文字；生成是像素空間流匹配。推出四個檢查點，S8-F22-R05 為預設，涵蓋文字轉圖像、96 幀與 24 fps 的文字轉影片，以及兩種理解方向。

這兩種發布模式堪稱對比的典範

UI-Mate-27B 於 2026 年 8 月 14 日在 Hugging Face 上現身，附有模型卡、編號 2608.15930 的 arXiv 預印本、專案頁面、GitHub 儲存庫，以及一份有文件記載的 serving recipe。從那時到十月初，它累積了大約 780 次下載和 93 個讚——不算多，但這是一次正常的研究代理發布，文件手續齊備。

PixelUMM 的發展軌跡性質不同。GitHub 儲存庫於 2026 年 9 月 4 日建立；arXiv 預印本標註日期為 9 月 29 日；Hugging Face 儲存庫於 2026 年 10 月 1 日 21:40 UTC 建立，就在該儲存庫最後一次提交的幾分鐘後。針對它，沒有出現任何 NVIDIA 的部落格文章、新聞稿或發布討論串。專案頁面本身的 URL 路徑仍顯示為pixelumm-project-page-preview。本文撰寫時，它的下載次數為零。

從中解讀意圖是錯誤的——實驗室可以發表一項研究產物，日後再安排推出。能確知的事更狹隘，卻也更有用：其中一個模型有官方的服務途徑和十週的下載量；另一個則有一篇論文、一個儲存庫，卻完全沒有任何廠商聲明。

不重疊的計分板

他們報告了一項基準，而這本身就是那項基準：他們並不是在解決同一個問題。

• 代理式電腦操作 — UI-Mate-27B：OSWorld-Verified 77.0，WindowsAgentArena 66.2。PixelUMM：沒有動作空間，因此無法評分。

• 圖像理解 — UI-Mate-27B：以螢幕截圖作為代理輸入，並非作為一般 VLM 進行評估。PixelUMM：MMMU 41.67，AI2D 80.12，DocVQA 90.42，ChartQA 82.96，OCRBench 78.00。

• 影片 — UI-Mate-27B：無。PixelUMM：MVBench 70.53、Video-MME 57.33、LongVideoBench 59.61、LVBench 40.41。

• 生成 — UI-Mate-27B：無。PixelUMM：使用提示詞重寫器時 GenEval 0.83，DPG-Bench 85.74，VBench Part 1 品質 84.10。

• 部署成本 — UI-Mate-27B：27B 稠密模型，透過 vLLM 分散在大約兩張 GPU 上，外加官方評估工具。PixelUMM：約 30 GB 的分散式檢查點分片、CUDA 13 搭配從原始碼建置的 FlashAttention、視訊路徑所需的權限管制護欄模型，以及為它另外準備的第二個 Python 環境。

• 授權 — UI-Mate-27B：Apache-2.0，程式碼與權重。PixelUMM：Apache-2.0 程式碼，檢查點採用 NVIDIA One-Way 非商業授權條款。

• 規模 — 27B 稠密模型對比約 15.2B 總量，在 PixelUMM 自己的論文表格中呈現為「8B MoT」。

唯一真正可供比較的說法是關於來源出處，而且兩者皆適用：上述每個數字都是廠商自家的，沒有一個曾在產出它的實驗室之外重新跑過，而這兩個模型中有一個明確將自己的結果標示為初步。

用它們來建構，以及為什麼你可能會兩者都用

這兩者搭配起來，比相互競爭更好。桌面自動化技術堆疊會需要 UI-Mate-27B 作為行動層，還需要能對所見內容進行推理的東西；內容或檢測管線則會需要 PixelUMM 的讀取與生成，完全不需要游標。兩者重疊之處在於感知邊界：UI-Mate-27B 的螢幕截圖錨定是任務專屬的，而 PixelUMM 的則是一般通用的——相同的像素，兩種截然不同的工作。

當你真的讓數個模型彼此對測——代理模型對上通用型 VLM，或新的研究檢查點對上已投入生產的版本——比較成本通常來自整合，而非推論：兩種 API 形式、兩套驗證機制、兩份合約。這正是路由層存在的目的：消除這個問題，而這也正是 OrcaRouter 設計發揮價值之處：一組金鑰通行 200+ 個模型、供應商定價以 0% 加成直接轉嫁、跨供應商自動故障轉移，以及路由 DSL 加上模型融合，可將數個模型組合成單一次呼叫。PixelUMM 和 UI-Mate-27B 目前都不在任何託管端點上，而OrcaRouter 兩者都不路由——因此這說的是當它們上線後的工作流程，而非宣稱目前可用。

哪一個用於哪個工作？

如果任務最後是以一次點擊、一次按鍵，或一份填寫完成的表單作結，那麼這裡只有一個候選者，那就是 UI-Mate-27B。它採用 Apache-2.0 授權，有一篇 arXiv 論文和一套官方測試框架，而它回報的 OSWorld 與 WindowsAgentArena 分數，正是任何擁有兩張 GPU 以及 Windows 或 Ubuntu 測試映像檔的人都能查核的那種主張——而這正是它值得查核、而不是直接信任的原因。

如果任務最終會產出答案或影像，PixelUMM 就是能做到這件事的模型，而且它首先是一項研究產物。它的論文對自身限制異常誠實，坦承不同的訓練資料意味著其基準比較「無法確立哪種架構更優越」。它的檢查點是非商業授權。它的強項在於架構新穎性與廣度，而非最先進的數字，而其當下價值在於提供給任何研究無編碼器統一模型是否能在影片規模下運作的人。下載它是為了閱讀程式碼並執行示範；不要為了推出功能而下載它。

這兩行總結與證據所給出的結論相同：一個模型能行動卻無法創造，另一個能創造卻無法行動，而它們之間在授權與成熟度上的差距，比任何參數數量都更重要。