WeVisOne-VL-4B vs UI-Venus-2-9B: Den ena returnerar en mask, den andra returnerar ett klick

Ger du samma skärmbild av en kassasida till WeVisOne-VL-4B och till UI-Venus-2-9B får du två olika typer av svar. Den första ger dig geometri: en ruta runt varukorgsikonen, en segmenteringsmask runt rabattfältet, en alfamatte som skär ut produktbilden ur dess bakgrund. Den andra ger dig en åtgärd: koordinaterna för nästa tryck, plus resonemanget som ledde fram till det. Tencent:s WeChat Vision-team publicerade WeVisOne-VL-4B på Hugging Face utan tillkännagivande och daterade sitt tekniska paper till 23 oktober 2026; inclusionAI:s UI-Venus-2-9B har varit nedladdningsbar sedan 26 augusti 2026. De sorteras under samma modalitetsetikett och de är inte utbytbara.

Det gör detta till en jämförelse med ett ovanligt problem i centrum: de två modellerna har ingen gemensam benchmark. Inte en enda poäng förekommer på båda korten. Ingen av dem har utvärderats oberoende, ingen av dem driftsätts av en inferensleverantör, och ingen av dem har ett publicerat pris. Det som går att jämföra ärligt är vad var och en ger som utdata, hur var och en har tränats att vägra, vad de kostar att köra och vilken licens du skulle distribuera under — så det är vad den här artikeln gör, och den markerar leverantörsrapporterade siffror som leverantörsrapporterade varje gång en sådan förekommer.

De två modellerna svarar inte på samma fråga.

WeVisOne-VL-4B är en perceptionsmodell. Den bygger på en Qwen3-VL-backbone och lägger till en obligatorisk pixelavkodare med 9,6 miljoner parametrar – mask_decoder.pt, som levereras som en andra artefakt – vilken omvandlar språkmodellens boxprediktioner till instansmasker och sedan till alfa-mattor med stride 1. Koordinater sänds ut som dedikerade token som spänner från <0> till <1000>, normaliserade mot bilden, och en särskild <OBJ>-token (id 152,678) avslutar varje box i densa uppgifter. Artikelns uppgiftslista är en lista över geometri: detektion med öppen vokabulär, refererande lokalisering, räkning, pekning, OCR-lokalisering, refererande segmentering och promptbar alfa-mattning.

UI-Venus-2-9B är en agent. Den initieras från Qwen3.5-9B och tränas på interaktion med enbart skärmbilder över fem uppgiftsfamiljer – grounding, CAPTCHA, mobil, webb och dator – genom mid-training, offline stegvis förstärkningsinlärning och multi-teacher on-policy-destillation. Dess utdata är en åtgärd i en sluten observera–resonera–agera-loop, och dess vLLM-recept parar --max-model-len 262144 med --reasoning-parser qwen3 eftersom den avger resonemangstoken före varje åtgärd.

Ställ specifikationerna sida vid sida, så blir skillnaden omedelbar:

• Vad som kommer ut – boxar, punkter, masker och alfamattor från WeVisOne-VL-4B; en åtgärd plus dess resonemangsspår från UI-Venus-2-9B.

• Backbone — Qwen3-VL för WeVisOne-VL-4B; Qwen3.5-9B för UI-Venus-2-9B. Olika generationer, olika familjer av textstack.

• Storlek — 5B parametrar angivna i repot trots ett "4B"-namn, plus en separat dekoder med 9,6M parametrar; 9B dense för UI-Venus-2-9B över fyra BF16-shards, cirka 18,8 GB.

• Viktformat — F32 safetensors på WeVisOne-VL-4B-kortet, vilket är ovanligt i den här storleken och gör nedladdningen större än vad parameterantalet antyder; BF16 för UI-Venus-2-9B.

• Licens — Apache 2.0 för WeVisOne-VL-4B; "väntar på slutlig bekräftelse" för UI-Venus-2-9B.

Den praktiska konsekvensen är att du inte kan byta ut det ena mot det andra, och varje artikel som utser en vinnare besvarar en fråga som du inte har ställt. En perceptionsmodell som returnerar en perfekt mask kan fortfarande inte klicka. En agent som klickar perfekt kan fortfarande inte ge dig den matte du ville ha för produktfotograferingen.

Där de verkligen överlappar varandra: båda teamen lärde sin modell att säga nej

Det här är det enda designbeslut som båda utgåvorna fattade, och det är det mest intressanta med de två tillsammans. Modeller för lokalisering med öppen vokabulär misslyckas på ett specifikt och kostsamt sätt: be om brandsläckaren i ett rum som inte har någon, och en modell som alltid svarar kommer självsäkert att sätta en box runt radiatorn. I förlängningen innebär det ett hallucinerat objekt i din asset pipeline eller ett tryck på fel ställe i din automatiseringsloop.

WeVisOne-VL-4B hanterar det genom att returnera None, och artikeln rapporterar avvisningsfrekvensen som ett eget mått vid sidan av noggrannheten. På RefCOCOg når 4B-modellen en avvisningsfrekvens på 67,4, medan dess Qwen3-VL-4B-bas ligger på 18,8. På WeChat-interna WeRef-Bench rapporterar den 96,4 i avvisning mot 61,9 för basmodellen, och på Ref-ZOM 86,0 mot 0,3 för UniPixel-7B. Det är självrapporterade siffror från en artikel som publicerades idag, och avvisningsbenchmarkarna är till stor del författarnas egna – betrakta riktningen som trovärdig och den exakta skillnaden som overifierad.

UI-Venus-2-9B angriper samma problem från agentsidan och ärver avvisningsmedveten grounding från UI-Venus-serien: modellen är tränad att avböja när det efterfrågade elementet inte finns på skärmen i stället för att gissa en trolig plats. Dess grounding-siffror – ScreenSpot-Pro 73,0, VenusBench-GD 77,1, OSWorld-G-R 78,5 – är leverantörsrapporterade, och kortet anger uttryckligen att detta inte eliminerar risken för skadliga åtgärder och rekommenderar mänsklig bekräftelse plus skyddsåtgärder på applikationsnivå. Dess säkerhetstabell visar den effekt den faktiskt hävdar: en attackframgångsgrad på 11,3 % på OSHarm jämfört med 25,3 % för Qwen3.5-9B-basen, och 48,8 % på OSBlind jämfört med 79,4 %.

Så båda modellerna byggdes av team som hade sett en lokaliserare ljuga, och båda prioriterade att avstå från att svara framför täckning. Om din applikations felmod är ”säkert fel” spelar den gemensamma prioriteringen större roll än parameterantalen.

Siffrorna som Tencents modellkort inte visar

Varje genomgång av WeVisOne-VL-4B hittills har sagt samma sak, och det stämmer: modellkortet publicerar inga benchmarks. Det tekniska rapporten gör det, och den publicerades den 23 oktober 2026, vilket gör detta till den del av historien som ännu inte har spridits. Allt är egenrapporterat av författarna, inget har reproducerats oberoende, och modellen är en dag gammal – så läs detta som påståenden med en form, inte som fastställda resultat.

Jämfört med sin egen Qwen3-VL-4B-bas är skillnaderna tillräckligt stora för att de skulle vara intressanta även efter kraftig diskontering:

• Detektion, COCO zero-shot medel-F1 — 57,1 för WeVisOne-VL-4B mot 48,7 för Qwen3-VL-4B, och 55,3 mot 44,0 på LVIS.

• Detektion, Dense200 medel-F1 — 71,3 mot 15,2. Det är inte ett stavfel i artikelns tabell; täta scener med små objekt är där basmodellen kollapsar.

• Referensdetektion, RefCOCOg val — 80,8 vs 74,1, med avvisningsgraden på 67,4 vs 18,8.

• Räkning, PixMo-Count val exakt matchning — 93,7 vs 69,6; på MixCount val, 42,0 vs 3,5.

• Pekning, PointBench F1 — 71,9 vs 57,1.

• OCR-lokalisering, SROIE genomsnittligt F1 — 68,1 mot 40,4, och bättre än PP-OCRv5:s 58,6.

• Refererande segmentering, ReasonSeg val gIoU — 71,2, jämfört med 65,0 för LISA-13B.

• Promptbar matting, AM-2K box prompt-MAD — 5,0 mot 12,1 för SAM2-Matting; på referring prompts i WeRefMat, 9,8 mot 51,9.

Mattingresultatet är det man bör stanna upp vid, eftersom det är den förmåga som inget annat i den här prisklassen erbjuder via en prompt. Att be en visuell-språkmodell om "personen, som alfa-matta" och få en stride-1-utdata som slår en SAM2-mattingpipeline på MAD är en annan produkt än ett detektionshuvud med en mask påhängd. Det är också där artikeln är minst smickrande mot sin egen 4B: på box-prompter för P3M-500-NP får 2B-modellen 6,6 MAD mot 4B:ans 7,3, så den större varianten är inte genomgående bättre och författarna skriver ut det.

Vad siffrorna för UI-Venus-2-9B mäter, och varför de inte går att överföra

Ställ de två benchmarksviterna bredvid varandra, så upphör oförlikneligheten att bara vara en teknikalitet. UI-Venus-2-9B:s huvudresultat är alla framgångsgrader för sluttillstånd i en miljö: AndroidWorld 80,2, OSWorld-Verified 70,8, WebVoyager 90,8, Online-Mind2Web 74,0, MobileWorld 65,8 vid kortets standardstegbudget och 75,2 vid 100 steg. Dessa siffror mäter huruvida en uppgift blev slutförd, vilket väver samman perception, planering, minne och felåterhämtning till en enda siffra.

Det som kommer närmast en gemensam axel är GUI-grounding. UI-Venus-2-9B får 73,0 på ScreenSpot-Pro, ett benchmark för att lokalisera små gränssnittselement i högupplösta skärmbilder – och WeVisOne-VL-4B rapporterar det inte. WeVisOne-VL-4B redovisar resultat för OCR-lokalisering och dense pointing, och UI-Venus-2-9B rapporterar inte dem. Så den ärliga hållningen är att det enskilt mest användbara numret för den här jämförelsen ännu inte finns: att köra WeVisOne-VL-4B på ScreenSpot-Pro skulle visa om en 5B-perceptionsspecialist slår en 9B-agent på att hitta en knapp, och tills någon kör det gissar alla som rangordnar dessa två efter grounding.

Agentens egen svit bär också sin svaghet offentligt. På OSWorld 2.0 får 9B-modellen 7,5 partial och 0,0 binary; syskonmodellen på 27B når 13,2 partial och 2,8 binary. Skrivbordsarbete över lång horisont är inte löst vid den här storleken, och kortet säger det.

Att betjäna dem är ett större gap än benchmarkgapet

För ett team som bestämmer vad de ska köra nästa vecka kommer den operativa skillnaden att spela större roll än någon poäng. UI-Venus-2-9B är en enda modell som du startar med ett enda vLLM-kommando och som exponerar en OpenAI-kompatibel slutpunkt med tensorparallellism på 1. WeVisOne-VL-4B behöver sitt inferenspaket från GitHub plus den separata dekoderartefakten, och den anropas via sin egen WeVisOneVL(...)-wrapper med ett uppgiftsargument — predict(image, task="matting", query="person", temperature=0.0). Kortet dokumenterar vägarna för Transformers, vLLM och SGLang, men pixelavkodaren är inte valfri: enbart språkmodellen kan inte producera en mask.

Minnet är närmare än vad parameterantalen antyder. Vid bf16 är 5B-stommen ungefär 10 GB före dekodern, mot cirka 18,8 GB för UI-Venus-2-9B:s fyra shards. Båda får plats på ett enda 24 GB-kort för vikterna; det som skiljer är hur mycket utrymme som återstår för kontext.

Och vad gäller kontext överensstämmer de två konfigurationerna på ett sätt som lätt kan övertolkas. WeVisOne-VL-4B:s konfiguration levereras med max_position_embeddings på 262,144 – samma tak som UI-Venus-2-9B erbjuder med sin maximala modellängd på 262,144. Men de använder det för olika saker: agenten behandlar lång kontext som episodminne och håller kvar skärmbildshistoriken för en uppgift, medan perceptionsmodellens publicerade utvärderingar körs vid 1 960 visuella tokens per bild. Ett 256K-fönster på en enkelomgångsmodell som bara hanterar bilder är ett tak, inte en demonstrerad förmåga, och kortet listar videorutnät som direkt avvisade av pixelavkodaren.

Licens: en av dessa är avgjord och en är inte

WeVisOne-VL-4B är Apache 2.0, med kod skriven av Tencent under samma villkor. Du kan läsa den, forka den, leverera den i en produkt och inte prata med en advokat om det.

Modellkortet för UI-Venus-2-9B anger att licensen för modellvikterna inväntar slutlig bekräftelse och kommer att läggas till före offentlig lansering, samt att den tidigare Apache-2.0-deklarationen medvetet inte fördes över eftersom uppströmsmaterial innehåller motstridiga licensuppgifter. Den meningen har funnits på modellkortet sedan augusti och har inte ändrats. Den hindrar dig inte från att utvärdera modellen, och den hindrar inte intern användning i de flesta organisationer – men den innebär att en extern produkt som byggs på dessa vikter byggs på en olöst fråga, och hur högt benchmarkresultatet än är löser det inte det. Om du väljer mellan dessa två för något som du avser att släppa avgör licenskolumnen snabbare än noggrannhetskolumnen.

Vad var och en kostar, med tanke på att ingen av dem har något pris

Det finns inget leverantörsbestämt pris per token för någon av modellerna. WeVisOne-VL-4B:s sida säger att den inte driftsätts av någon inferensleverantör; UI-Venus-2-9B har ingen förstaparts-endpoint och ingen prislista publicerad av inclusionAI, så det pris en tredjepartsvärd tar ut för den är värdens siffra, inte teamets. För båda är kostnaden GPU-timmar på hårdvara du hyr eller äger, vilket innebär att jämförelsen inte är "pris för indata mot pris för utdata" utan "hur mycket kort behöver jag och hur många bilder per sekund klarar den".

Ingen av artiklarna publicerar genomströmning eller latens, så den andra siffran är okänd för båda. Det som går att veta är formen: UI-Venus-2-9B betalar för ett 9B-framåtpass plus resonemangstoken vid varje steg i en episod, och en agentepisod består av många steg. WeVisOne-VL-4B betalar för ett 5B-pass plus ett dekoderframåtpass per bild, och en bild är ett anrop. Om din arbetsbelastning är hundratusen produktfoton är perceptionsmodellens ekonomi per bild och förutsägbar; om det är en webbläsaruppgift skalas agentens kostnad med hur många åtgärder uppgiften kräver, vilket är siffran du inte kan prognostisera utifrån kortet.

Det är också här ett routinglager förtjänar sin plats i stället för att vara en slogan. Ingen av modellerna finns på OrcaRouter i dag, och den här artikeln tänker inte låtsas något annat — WeVisOne-VL-4B har ingen inferensleverantör alls, och UI-Venus-2-9B serveras via tredjepartsvärdskap i stället för från vår egen katalog. Det OrcaRouter erbjuder för de modeller den faktiskt betjänar är en OpenAI-kompatibel slutpunkt över 200+ av dem med 0 % påslag, med leverantörens listpris vidarebefordrat oförändrat, så att en leverantörs prissänkning når dig samma dag som den sker i stället för vid nästa avtalsförnyelse. För en arkitektur som anropar en perceptionsmodell och en agentmodell i följd är det routing-DSL:en som är platsen där den sammansättningen lever — två modellanrop, en plats att byta ut endera delen på — och automatisk redundansväxling är det som håller en agentloop vid liv när modellen bakom den försämras mitt i en episod. I samma stund som någon av dessa två blir tillgänglig hos en leverantör är det det billigaste sättet att ta reda på om den hör hemma i din stack.

Vilken ska man välja?

Beslutet är en arbetsbeskrivning, inte en rangordning.

• Välj WeVisOne-VL-4B om resultatet du behöver är geometri – avgränsningsrutor in i en annoteringspipeline, masker för ett redigeringsverktyg, alfamattor för produktbilder, antal objekt i en tät flygbild, eller OCR med tillhörande koordinater. Inget annat i den öppna 5B-klassen returnerar en matta från en textprompt, och artikelns mattningssiffror mot en SAM2-pipeline är det starkaste påståendet i släppet.

• Välj UI-Venus-2-9B om det du behöver är en slutförd uppgift – ett ifyllt formulär, en app som navigerats, en CAPTCHA som lösts, ett skrivbordsarbetsflöde som styrs från skärmbilder. Det levereras som ett enda vLLM-kommando med en OpenAI-kompatibel endpoint, vilket är en dags arbete snarare än en vecka, och dess resultat för AndroidWorld och WebVoyager är siffrorna att jämföra mot din egen miljö.

• Välj ingen av dem ännu om du behöver oberoende bevis, ett publicerat pris eller en fastställd licens för en produkt som ska levereras. Alla tre saknas för UI-Venus-2-9B:s licens och för båda modellernas benchmarkresultat.

• Överväg båda om du bygger en agent som måste manipulera bilder i stället för att bara klicka sig igenom skärmar. Kompositionen är den intressanta: UI-Venus-2-9B bestämmer var den ska agera, WeVisOne-VL-4B producerar den pixelakurata artefakt som åtgärden syftade på. Det kostar två modellanrop per steg och köper en precision som ingen av modellerna har på egen hand.

Vad skulle ändra det här svaret?

Fyra saker, i ordning efter hur mycket de skulle påverka det.

En ScreenSpot-Pro-körning av WeVisOne-VL-4B. Det är det enda riktmärket som båda sidor rimligen skulle kunna ställa upp på, och det skulle avgöra om en perceptionsspecialist på halva storleken lokaliserar bättre än en specialbyggd UI-agent. Vem som helst med en GPU och en eftermiddag kan ta fram den, och ingen har gjort det.

En oberoende utvärdering av endera modellen. Varje siffra i den här artikeln går tillbaka till ett modellkort eller en artikel skriven av teamet som byggde saken. Det är normalt på lanseringsdagen, och det är fortfarande en avsaknad.

En avgjord licens för UI-Venus-2-9B. "Väntar på slutlig bekräftelse" har stått på kortet i åtta veckor. Om den resulterar i något tillåtande blir agenten betydligt lättare att rekommendera för kommersiellt arbete; om den inte gör det besvarar det frågan åt andra hållet.

En förstapartsendpoint för endera. Ingen av leverantörerna tillhandahåller sin egen modell i dag, vilket begränsar målgruppen till team som är villiga att driva en serveringsstack, och på WeVisOne-VL-4B-sidan till team som är villiga att driva ett anpassat inferenspaket. En leverantörspublicerad taxa skulle förändra kostnadsjämförelsen från aritmetik till en budgetpost.

Fram till dess är den rättvisande sammanfattningen denna: Tencent har släppt ett perceptionsverktyg som gör något som ingen liten öppen modell gjort tidigare, tillräckligt diskret för att dess egna benchmarktabeller ännu inte har lästs, och Ant Group släppte en agent en och en halv månad tidigare som är enklare att köra och svårare att licensiera. De är inte rivaler. Misstaget skulle vara att välja den ena eftersom den andra fick högre poäng på en benchmark som de inte har gemensamt.