LLaDA-UI 悄然上線：inclusionAI 的 Diffusion GUI Agent 現已開放下載

LLaDA-UI——inclusionAI 推出的約 167 億參數混合專家（Mixture-of-Experts）GUI 代理——於 2026 年 9 月 6 日出現在 Hugging Face 上，沒有任何公告。它之所以值得再看一眼，並非因為這份沉默，而是背後的機制：不同於主宰電腦使用研究的自迴歸視覺語言模型那樣逐 token 撰寫下一個動作，LLaDA-UI 採用擴散（diffusion）風格，每一步都對一整塊動作 token 進行去噪，之後才定下答案。廠商將它定位為實用且開放權重的擴散式 GUI 代理。以下各點皆如實標示其性質：你可自行查證的儲存庫事實、實驗室以外無人複現的技術報告宣稱，以及仍然未真正解決的缺口——其中最主要的是授權條款的缺失。

發布時間點之所以重要，是因為這已成為一種模式。inclusionAI 是螞蟻集團旗下的實驗室，也是 LLaDA 系列擴散語言模型的幕後推手；就在同一週，它於 9 月 4 日發布了 LLaDA-Image 與 LLaDA-Image-Turbo 影像檢查點、9 月 5 日發布了 LLaDA2.2-mini 代理模型，並於 9 月 6 日建立了 inclusionAI/LLaDA-UI 儲存庫。三天之內發布三個模型系列，且沒有任何一個在發布前有先行公告。就 LLaDA-UI 而言，實際發布的證據就是儲存庫本身：safetensors 權重存在且可載入，推論程式碼和 SGLang 伺服配方隨之提供，技術報告與專案頁面也都齊備。然而，缺少的是任何廠商公告、任何授權許可，以及——截至撰寫本文時，下載量仍停留在個位數——外界是否已注意到它的任何跡象。

已出貨，但尚未公告

inclusionAI/LLaDA-UI 儲存庫於9月6日05:08 UTC建立，是一份完整且自足的模型釋出，並非佔位符。樹中共有二十一個檔案：七個BF16 safetensors分片，總計約169億個參數（模型卡四捨五入為約167億總參數）、tokenizer與config檔案，以及——重要的是——模型自身的Python原始碼（modeling_llada2_vl_moe.py 與 configuration_llada2_vl.py）。該架構註冊為 `llada2vl` 模型類型下的 `LLaDA2MoE_VLForConditionalGeneration`，而由於這些檔案隨儲存庫一同提供，這並非標準Transformers架構：要載入它意味著必須取得自訂程式碼，無論是透過複製儲存庫，還是經由hub的遠端程式碼路徑。

儲存庫沒有包含的內容，同樣具有資訊價值。模型卡上沒有授權標籤，儲存庫目錄中也沒有 LICENSE 檔案，因此商業團隊第一個會問的標準問題——這些權重我能拿來做什麼？——目前還沒有答案。這篇論文是一份技術報告，以 PDF 形式放在 GitHub 儲存庫內，並從專案頁面提供連結；它尚未出現在 arXiv 上（頁面仍顯示「SOON」）。我們也找不到任何推理服務供應商在提供這個模型：Hugging Face 的模型卡顯示沒有部署任何推理供應商，這表示目前 LLaDA-UI 是「下載後自行託管」的版本，而不是可以透過 API 呼叫的服務。我們也沒有託管它——本文中的任何內容都不應被解讀為我們有託管它。

像影像模型般解碼的GUI代理

設計即是故事，因此值得精確說明 LLaDA-UI 與它所比較的自迴歸 GUI 模型有何不同。傳統的電腦使用模型——例如 Qwen2.5-VL-7B 或 Qwen3-VL-8B，或託管式電腦使用產品背後的 VLM——會接收螢幕截圖與指令，然後從左到右逐 token 預測，直到動作字串完成。因此，延遲會隨答案中的 token 數量而增加。相對地，LLaDA-UI 將整個回應視為一個起初被遮罩、而後逐步去噪的區塊：每個解碼步驟會並行精煉多個 token，經過固定步數後（參考腳本使用 32 步，區塊長度為 32），完整的推理加動作字串便會顯現。這正是該實驗室在影像生成上所用的同一概念性做法，如今應用於 GUI 動作。

在底層，這套技術堆疊包含一個原生解析度的視覺編碼器、一個空間投影器，以及一個擴散語言模型。視覺編碼器是從 SigLIP 初始化的 ViT，採用二維旋轉位置嵌入，並以螢幕截圖的原生長寬比執行——模型卡將 IMAGE_MAX_PIXELS 設定為 12,845,056，也就是說，在縮小處理之前，輸入約有 12.8 百萬像素；這對密集桌面 UI 中的小型點擊目標來說至關重要。其輸出會先在空間上以四比一的比例分組，再經由兩層 MLP 投影器送入語言主幹，也就是 LLaDA2.0-mini MoE 擴散語言模型。因此，Hugging Face 側邊欄顯示的「17B 參數」其實是混合專家（MoE）模型；每一次前向傳遞只會啟動一部分參數，而這正是下方延遲數據之所以合理的原因之一。

這個訓練方案值得一提，因為在紙面上它異常節省。根據技術報告，多模態主幹（backbone）透過三階段課程預訓練了大約1450億個token——先是一個簡短的僅投影器（projector-only）對齊階段，然後是感知密集與推理密集的完整模型階段——之後再針對GUI代理進行監督微調，使用了來自UI-Venus專案超過600萬個樣本，涵蓋超過100個中國行動應用程式、超過70個英文行動應用程式，以及桌面與網頁資料。廠商的說法是，145B token僅是自迴歸同類模型所耗用的一小部分（報告引用了Qwen2.5-VL的4.1T和Qwen3-VL的2.2T）。應將這些token數量與資料組成視為該實驗室自己的說法；能獨立驗證的只有模型存在且可以執行。

它實際所發出的

LLaDA-UI 有兩種輸出模式，而這兩種模式的差異會影響你要如何把它接入管道。在定位模式（grounding mode）中，模型會回傳單一地點：整數座標正規化到目標的 [0, 999] 範圍，例如 [742, 186]，參考腳本也會以 0 到 1 的分數形式輸出，用於乘以截圖的寬和高。如果要求的目標不在影像中，模型會被訓練成回答 [-1, -1]，而不是幻覺出一個位置——這對代理迴圈來說是個小而重要的可靠性特性。在代理／導航模式（agent/navigation mode）中，模型會先輸出一個推理標籤，再接一個結構化動作：

<think>搜尋列位於頁面頂端，標誌下方。</think><action>Click(box=(742, 186))</action>

動作詞彙是按平台定義的——行動裝置、桌面和網頁皆然——而且儘管欄位名稱如此，box 儲存的是單一互動座標，而非矩形範圍。think/action 的分工，讓模型在執行點擊前，能先將決策奠基於當前畫面；而座標形式的輸出，則確保結果可供機器直接解析，而非需要另一個剖析器去解讀的自由格式指令。

已標示的基準測試宣稱

這份技術報告的頭條結果，是一系列關於擴散式GUI模型在自動迴歸模型自己的地盤上擊敗它們的主張。以下依供應商所述原樣重現，摘自技術報告與專案頁面——這些內容均未經獨立複現，且除另有註明外，下列數字皆為LLaDA-UI對比Qwen3-VL-8B的結果：

• ScreenSpot-Pro（定位）— LLaDA-UI 52.9 對比 Qwen3-VL-8B 52.7，微幅領先。

• AndroidWorld（行動代理）— LLaDA-UI 53.5 對比 Qwen3-VL-8B 47.9。

• MobileWorld（行動代理）— LLaDA-UI 25.6 對比 Qwen3-VL-8B 9.4，為全場差距最大的一項。

• WebVoyager（網頁代理）— LLaDA-UI 56.9 對比 Qwen3-VL-8B 45.2。

上述是所報告六個 GUI 基準測試中的四個；報告坦承，LLaDA-UI 在其他兩個測試上並未勝過 Qwen3-VL-8B——ScreenSpot-V2 十分接近，而 OSWorld-Verified 仍是差距所在，作者將其歸因於在帶有小目標的超大截圖上表現退化。面對較舊的 Qwen2.5-VL-7B，這項宣稱則是無條件的：在所報告的全部六個基準測試上均勝出。此外還有一項速度宣稱，由該實驗室在相同硬體上以成對的非快取伺服運行進行量測：LLaDA-UI 每次回應需 4.8 至 6.4 秒，而 Qwen3-VL-8B 需 17 至 53 秒，引用為網頁輸入平均加速 3.58 倍、桌面 6.83 倍、行動裝置 8.95 倍——報告並指出，即使每次呼叫生成更多 token，並行區塊解碼在實際耗時上依然佔優勢，即便答案更長。

以閱讀準確度數據時同樣的懷疑態度，來看待這項延遲宣稱。擴散解碼的並行區塊優勢，在機制上是真實存在的，而效應的方向——每個回應所需的序列步驟更少——與該架構的運作方式一致，但 3.6 倍到 9 倍的加速，是由打造該模型的人們，在他們自選的硬體上量測出來的，而且尚未經過複現驗證。準確度差距同樣重要：OSWorld-Verified 是該領域最接近現實桌面代理測試的基準，而作者恰恰表示，模型正是在這個環節表現吃力——亦即在大尺寸截圖中尋找小型目標。一個在行動端與網頁端表現出色、卻在密集桌面 UI 上失手的 GUI 代理，呈現的是特定強項輪廓，而非通用能力。

如何執行它，以及還缺少什麼

若想親自試用 LLaDA-UI，路徑是權重優先：checkpoint 在 BF16 下約 32 GB。參考環境為 Python 3.10、PyTorch 2.5.1、Transformers 4.51.0 與 FlashAttention 2.7.4.post1；快速入門會以 --gen-length 32 --steps 32 --block-length 32 對單張圖片執行一次 grounding 推論。可透過 SGLang 提供服務，但僅限於該實驗室自帶的啟動器：儲存庫內附 serve_llada_ui.sh 與一個用戶端腳本，二者皆假設 LLaDA-UI 特有的多模態擴散修補；模型卡也明確表示無法從原版 SGLang 安裝啟動。大型截圖還可能需要調高預設的 --max-length 8192。這款模型適合熟悉自行 clone 儲存庫、能針對自身 CUDA 環境編譯 FlashAttention、並善於除錯擴散解碼流程的使用者——它還不是一條指令即可呼叫的 API。

有四件事會改變讀者能用 LLaDA-UI 做什麼，而截至本文撰寫為止，沒有一件已經發生。明確宣告的授權條款，將解決目前尚無答案的商業問題。arXiv 上的條目，會把儲存庫內的技術報告變成可引用且可受同儕檢視的內容。透過 WebVoyager 數據獨立重現 ScreenSpot-Pro，則能把該架構的真實能力與作者自身的評估區分開來。另外，若有供應商實際提供此模型，使用者就不必下載 32 GB 檔案、也不需 GPU 即可測試。一旦最後這一步成真，路由問題便會成為例行公事——在所有模型目錄間共用同一組 API 金鑰、供應商牌價不加價直接轉傳、自動容錯移轉，讓三天前的檢查點永遠不會獨自留在生產路徑上。在那之前，LLaDA-UI 是一個格外值得關注的開放權重：一個有真實基準測試宣稱的擴散式 GUI 代理、一個具體且誠實揭露的弱點，以及完全沒有能讓多數團隊今天就採用的法律或營運支架。請關注儲存庫中的授權條款與論文，並依此順序。