LLaDA-UI släpps tyst: inclusionAI:s Diffusion GUI Agent är nu nedladdningsbar.

LLaDA-UI — en GUI-agent med mixture-of-experts och ungefär 16,7 miljarder parametrar, från inclusionAI — dök upp på Hugging Face den 6 september 2026 utan något tillkännagivande. Det som gör att den förtjänar en närmare titt är inte tystnaden utan mekanismen under ytan: i stället för att skriva nästa åtgärd en token i taget, som de autoregressiva vision-språkmodeller som dominerar forskningen kring datoranvändning gör, avbrusar LLaDA-UI ett helt block av åtgärdstoken per steg i diffusionstil och först därefter förbinder sig till svaret. Tillverkaren framställer den som en praktisk, diffusionsbaserad GUI-agent med öppna vikter. Allt nedan är märkt för vad det är: fakta om repositoryt som du kan kontrollera själv, påståenden i den tekniska rapporten som ingen utanför labbet har reproducerat, och luckor — med en saknad licens som den främsta — som fortfarande är genuint olösta.

Utgivningsramen är viktig eftersom detta nu är ett mönster. inclusionAI är laboratoriet med koppling till Ant Group som ligger bakom LLaDA-familjen av diffusionsspråkmodeller, och samma vecka som det publicerade LLaDA-Image- och LLaDA-Image-Turbo-bildcheckpoints (4 september) samt agentmodellen LLaDA2.2-mini (5 september) skapade det även arkivet inclusionAI/LLaDA-UI den 6 september. Tre modellfamiljer på tre dagar, ingen av dem föregicks av ett lanseringsinlägg. För LLaDA-UI specifikt är beviset på en faktisk utgivning själva arkivet: safetensors-vikterna finns på plats och går att ladda, inferenskoden och ett SGLang-serveringsrecept följer med, och en teknisk rapport och projektsida finns. Vad som inte finns är något tillkännagivande från leverantören, någon licens, eller – vid skrivande stund, med nedladdningar fortfarande i ensiffrigt antal – något tecken på att omvärlden ännu har uppmärksammat det.

Skickad, men inte annonserad

inclusionAI/LLaDA-UI-repositoriet skapades klockan 05:08 UTC den 6 september och är en komplett, fristående modellversion snarare än en platshållare. Tjugoett filer finns i trädet: sju BF16-safetensors-delar som tillsammans uppgår till cirka 16,9 miljarder parametrar (modellkortet avrundar till totalt ~16,7B), tokeniserar- och konfigurationsfilerna samt — viktigt — modellens egen Python-källkod (modeling_llada2_vl_moe.py och configuration_llada2_vl.py). Arkitekturen registreras som LLaDA2MoE_VLForConditionalGeneration under en modelltyp av llada2vl, och eftersom dessa filer ingår i själva repot är detta inte en standard-Transformers-arkitektur: att ladda den innebär att hämta den anpassade koden, antingen genom att klona repot eller via hubbens fjärrkodsväg (remote-code path).

Det som repot inte innehåller är minst lika informativt. Det finns ingen licenstag på modellkortet och ingen LICENSE-fil i trädet, så den första frågan ett kommersiellt team ställer — vad får jag göra med dessa vikter? — har ännu inget svar. Artikeln är en teknisk rapport som distribueras som en PDF i GitHub-repot och länkas från en projektsida; den har inte publicerats på arXiv (sidan säger fortfarande "SOON"). Och ingen inferensleverantör vi kan hitta serverar modellen: modellkortet på Hugging Face rapporterar ingen distribuerad inferensleverantör, vilket innebär att LLaDA-UI för närvarande är en release för nedladdning och självhosting, inte något du kan anropa via ett API. Vi hostar den inte heller — ingenting i den här texten ska läsas som ett påstående om att vi gör det.

En GUI-agent som avkodar som en bildmodell.

Designen är berättelsen, så det är värt att vara noggrann med hur LLaDA-UI skiljer sig från de autoregressiva GUI-modeller som den mäts mot. En konventionell datoranvändningsmodell – Qwen2.5-VL-7B eller Qwen3-VL-8B, till exempel, eller VLM:en bakom en värdbaserad datoranvändningsprodukt – tar skärmbilden och instruktionen och förutsäger sedan en token i taget, från vänster till höger, tills åtgärdssträngen är komplett. Svarstiden skalar därför med antalet tokens i svaret. LLaDA-UI behandlar i stället hela svaret som ett block som initialt är maskerat och successivt avbrusat: varje avkodningssteg förfinar många tokens parallellt, och efter ett fast antal steg (referensskriptet använder 32 steg med en blocklängd på 32) avslöjas hela resonemangs- och åtgärdssträngen. Det är samma konceptuella grepp som labbet använde vid bildgenerering, tillämpat på GUI-åtgärder.

Under huven är stacken: en vision-encoder med nativ upplösning, en rumslig projektor och en diffusionsspråkmodell. Vision-encodern är en ViT som initialiserats från SigLIP, får 2D-roterande positionsinbäddningar och körs med skärmbildens ursprungliga bildförhållande – modellkortet sätter IMAGE_MAX_PIXELS till 12 845 056, alltså ungefär 12,8 megapixlar indata före nedskalning, vilket har betydelse för små klickytor i täta skrivbordsgränssnitt. Dess utdata grupperas rumsligt fyra till ett och skickas genom en tvålagers MLP-projektor till en språkryggrad som är LLaDA2.0-mini MoE-diffusionsspråkmodellen. Så de "17B params" som Hugging Face-sidofältet visar är en mixture-of-experts-modell; endast en bråkdel av parametrarna är aktiva för varje enskilt framåtpass, vilket är en del av anledningen till att latensbeskrivningen nedan ens är trovärdig.

Träningsreceptet är värt att notera eftersom det är ovanligt ekonomiskt på pappret. Enligt den tekniska rapporten förtränades den multimodala backbone-modellen på cirka 145 miljarder tokens i tre faser — en kort anpassningsfas med endast projektorn, därefter faser med hela modellen med fokus på perception respektive resonemang — innan en övervakad finjustering för GUI-agenter på mer än sex miljoner exempel hämtade från UI-Venus-projektet, som spänner över fler än 100 kinesiska mobilapplikationer, fler än 70 engelska mobilapplikationer samt data från stationära datorer och webben. Leverantörens framställning är att 145 miljarder tokens är en bråkdel av vad de autoregressiva motsvarigheterna förbrukade (rapporten citerar 4,1 biljoner för Qwen2.5-VL och 2,2 biljoner för Qwen3-VL). Betrakta tokenantalet och datablandningen som labbets egna uppgifter; det enda som oberoende kan verifieras är att modellen existerar och går att köra.

Vad den faktiskt avger

LLaDA-UI har två utdatalägen, och skillnaden spelar roll för hur du skulle koppla in den i en pipeline. I groundning-läge returnerar modellen en enda punkt: heltalskoordinater normaliserade till ett intervall [0, 999] för målet, t.ex. [742, 186], vilket referensskriptet också skriver ut som ett bråk mellan 0 och 1 att multiplicera med skärmbildens bredd och höjd. Om det begärda målet inte finns i bilden är modellen tränad att svara [-1, -1] snarare än att hallucinera en plats – en liten men viktig tillförlitlighetsegenskap för en agentloop. I agent-/navigationsläge genererar modellen en resonemangstagg följd av en strukturerad åtgärd:

<think>Sökfältet finns högst upp på sidan, under logotypen.</think><action>Click(box=(742, 186))</action>

Handlingsvokabulären definieras per plattform – mobil, desktop och webb – och trots fältnamnet innehåller box en enda interaktionskoordinat snarare än en rektangel. Uppdelningen i tänka/agera är det som låter modellen förankra sitt beslut i den aktuella skärmen innan den utför ett klick, och den koordinatbaserade utdatan är det som gör resultatet maskinläsbart snarare än en fritextinstruktion som en separat parser måste tolka.

De märkta riktmärkespåståendena

De viktigaste resultaten i den tekniska rapporten är en uppsättning påståenden om att en diffusiv GUI-modell slår autoregressiva modeller på deras eget spel. Återgivet här exakt som leverantören rapporterar dem, från den tekniska rapporten och projektsidan — inget av detta har oberoende reproducerats, och siffrorna nedan är LLaDA-UI mot Qwen3-VL-8B om inte annat anges:

• ScreenSpot-Pro (grounding) — LLaDA-UI 52.9 mot Qwen3-VL-8B 52.7, en knapp marginal.

• AndroidWorld (mobil agent) — LLaDA-UI 53.5 vs Qwen3-VL-8B 47.9.

• MobileWorld (mobilagent) — LLaDA-UI 25.6 mot Qwen3-VL-8B 9.4, den största skillnaden på listan.

• WebVoyager (webagent) — LLaDA-UI 56.9 vs Qwen3-VL-8B 45.2.

Detta är fyra av de sex rapporterade GUI-riktmärkena; rapporten är ärlig med att LLaDA-UI inte klarar Qwen3-VL-8B på de andra två — ScreenSpot-V2 är nära, och OSWorld-Verified förblir ett glapp, vilket författarna tillskriver försämring på mycket stora skärmbilder med små mål. Mot den äldre Qwen2.5-VL-7B är påståendet ovillkorligt: segrar på alla sex rapporterade riktmärken. Det finns också ett hastighetspåstående, mätt av labbet på parade icke-cachade serveringskörningar på identisk hårdvara: 4,8 till 6,4 sekunder per svar för LLaDA-UI jämfört med 17 till 53 sekunder för Qwen3-VL-8B, angivna som genomsnittliga snabbningar på 3,58x för webbinmatningar, 6,83x för skrivbord och 8,95x för mobil — samtidigt som fler token genereras per anrop, enligt rapporten, eftersom parallell blockavkodning vinner på väggklockan även när svaret är längre.

Behandla latenspåståendet med samma skepsis som noggrannhetssiffrorna. Diffusionsavkodningens fördel med parallella block är mekanistiskt verklig, och effektens riktning – färre sekventiella steg per svar – är förenlig med hur arkitekturen fungerar, men 3,6x–9x hastighetsökningar uppmättes av dem som byggde modellen på hårdvara som de själva valt, och de har inte replikerats. Noggrannhetsluckorna spelar också roll: OSWorld-Verified är det närmaste fältet har till ett realistiskt skrivbordsagenttest, och det är just där författarna säger att modellen kämpar – på stora skärmbilder med små mål. En GUI-agent som bemästrar mobil och webb men halkar på täta skrivbordsgränssnitt är en specifik styrkeprofil, inte en generell sådan.

Hur man kör det, och vad som fortfarande saknas

Om du vill prova LLaDA-UI själv, är vägen att börja med vikterna. Checkpointen är cirka 32 GB i BF16. Referensmiljön är Python 3.10, PyTorch 2.5.1, Transformers 4.51.0 och FlashAttention 2.7.4.post1, och snabbstarten utför en enda körning av bild-grounding med --gen-length 32 --steps 32 --block-length 32. Det går att servera modellen via SGLang, men bara genom labbets egen launcher: repot innehåller en serve_llada_ui.sh och ett klient-skript som förutsätter LLaDA-UI-specifika multimodala diffusionspatchar, och modellkortet anger uttryckligen att modellen inte kan startas från en standardinstallation av SGLang. Stora skärmbilder kan också kräva att man höjer --max-length från standardvärdet 8192. Det här är en modell för den som är bekväm med att klona ett repo, bygga FlashAttention mot sin CUDA-miljö och felsöka en diffusionsavkodning – ännu inte ett API-anrop med ett enda kommando.

Fyra saker skulle förändra vad en läsare kan göra med LLaDA-UI, och ingen av dem har hänt i skrivande stund. En deklarerad licens skulle lösa den kommersiella frågan som för närvarande saknar svar. En arXiv-post skulle göra den tekniska rapporten i repot citerbar och kollegialt granskningsbar. En oberoende reproduktion av resultaten från ScreenSpot-Pro och WebVoyager skulle skilja arkitekturens verkliga kapacitet från författarnas utvärdering. Och en leverantör som faktiskt tillhandahåller modellen skulle göra den testbar utan en nedladdning på 32 GB och en GPU. Om och när det sista steget sker blir routingfrågan rutin – en API-nyckel för alla modellkataloger, leverantörernas listpriser som förs vidare utan påslag och automatisk failover, så att en tre dagar gammal checkpoint aldrig ligger ensam på en produktionssökväg. Tills dess är LLaDA-UI ett ovanligt intressant open-weights-projekt att bevaka: en diffusionsbaserad GUI-agent med verkliga benchmarkanspråk, en specifik och ärligt redovisad svaghet och inget av den juridiska eller operativa stödstruktur som skulle göra det möjligt för de flesta team att använda den i dag. Håll utkik i repot efter licensen och rapporten, i den ordningen.