WeVisOne-VL-2B vs UI-Venus-2-9B: Storleksgapet som namnet döljer

Nio miljarder parametrar är inte vad jämförelsen säger. Skrivet så som de flesta skriver det – WeVisOne-VL-2B vs UI-Venus 2.9B – framstår paret som två små visionsmodeller med ungefär samma parametervikt, en jämn kamp mellan en färsk 2B-checkpoint från Tencents WeChat Vision-team och något lite större från Ant Groups inclusionAI. Den andra hälften av det antagandet är falsk. UI-Venus-2-9B är UI-Venus 2 med 9 miljarder parametrar, initierad från Qwen3.5-9B; »2« är generationen, inte storleken. WeVisOne-VL-2B, som laddades upp till Hugging Face den 22 oktober 2026, har 2 miljarder parametrar på en Qwen3-VL-backbone. Den verkliga jämförelsen är därför en modell som är fyra och en halv gånger mindre, på en äldre backbone-generation, och som ger ett helt annat slags svar.

Det anlände också utan en lansering. Det finns ett Hugging Face-repo, ett GitHub-repo med en enda initial commit, en artikel på arXiv och en forskningsprojektsida – och inget leverantörsmeddelande, inget blogginlägg och ingen prissida som knyter ihop dem. Det formar vad den här artikeln ärligt kan göra. Vikterna, arkitekturen, licenstexten och artikelns tabeller går att kontrollera i dag. Oberoende utvärdering, genomströmning, latens och pris gör det inte, eftersom inget av dem finns ännu. Tencents modellkort publicerar inga benchmark-siffror alls; varje poäng som tillskrivs WeVisOne-VL-2B nedan kommer från författarnas egna sju uppgiftstabeller och är märkt som sådan. UI-Venus-2-9B är äldre och bättre dokumenterad, men dess siffror är precis lika självrapporterade.

Vad de två namnen faktiskt beskriver

WeVisOne-VL-2B är en perceptionsmodell. Ge den en bild och en fras, och den returnerar geometri: en avgränsningsruta, en punkt, ett antal, en binär mask eller en kontinuerlig alfa-matte. Dess språksida avger koordinater som dedikerade tokens från <0> till <1000>, normaliserade till bilden, och avslutar varje ruta i densa uppgifter med en speciell <OBJ>-token med id 152,678. Dessa tokens är bara markörer tills mask_decoder.pt läser det dolda tillståndet bakom dem – en nödvändig artefakt med 9,511,460 parametrar, levererad som en andra fil, som kortet beskriver som "en nödvändig kärnkomponent, inte ett valfritt tillägg." Utan den får du rutor. Med den får du masker och alfa-mattar med stride 1.

UI-Venus-2-9B är en agent. Ge den en skärmbild och en uppgift och den returnerar ett drag: nästa tryck, klick eller tangenttryckning, plus de resonemangstoken som producerade det, inom en sluten observera–resonera–agera-loop. Den tränades på interaktion med enbart skärmbilder inom grounding, CAPTCHA, mobil, webb och datoranvändning, och dess publicerade vLLM-recept parar en maximal modellängd på 262 144 med Qwen3-resonemangsparsern eftersom resonemangsspåret kommer ut före varje åtgärd.

Ställ de två sida vid sida och diskrepansen är omedelbar:

• Vad som returneras — rutor, punkter, antal, OCR-spann, masker och alfamattor från WeVisOne-VL-2B; en skärmåtgärd plus dess resonemangsspår från UI-Venus-2-9B.

• Parametrar – 2B för WeVisOne-VL-2B plus den separata 9,5M-dekodern; 9B dense för UI-Venus-2-9B, ungefär 4,5 gånger vikterna.

• Backbone — Qwen3-VL för WeVisOne-VL-2B, 28 textlager med en dold storlek på 2 048; Qwen3.5-9B för UI-Venus-2-9B. Olika generationer, olika textstackar.

• Vikter på disk — bfloat16 för båda, men ungefär 4 GB för 2B jämfört med fyra BF16-shards som totalt uppgår till cirka 18,8 GB för 9B.

• Kontexttak – 262 144 positioner för vardera, avlästa från WeVisOne-VL-2B:s konfiguration och från UI-Venus-2-9B:s serveringskommando. Ingen av leverantörerna visar att de använder något liknande.

• Publicerad evidens — sju uppgiftstabeller i Tencents artikel och inga på modellkortet; en lång leverantörsbenchmarklista på inclusionAI:s kort och inga tabeller i artikeln.

• Licens — Apache 2.0 för kod som Tencent har skrivit; "inväntar slutlig bekräftelse" för vikterna i 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 svarar på en fråga du inte har ställt. En perceptionsmodell som levererar en perfekt mask kan fortfarande inte trycka på en knapp. En agent som navigerar i en app felfritt kan fortfarande inte ge dig det utklipp du ville ha till en produktbild.

Argumentet för den mindre modellen är starkare än vad 2B kontra 9B antyder.

Instinkten när man ser en 2B bredvid en 9B är att den lilla är budgetkompromissen. I det arbete den tränades för hävdar Tencent-artikeln motsatsen, och ett av dess egna resultat talar emot dess egen större lansering. Alla siffror här är författarnas egna, körda av författarna, reproducerade av ingen.

• Zero-shot-detektion – genomsnittlig F1 på 55,2 på COCO, 53,3 på LVIS, 61,4 på Dense200 och 40,4 på VisDrone. Qwen3-VL-2B-baslinjen får 45,2, 40,8, 10,0 och 23,1 i samma tabell. Gapet för Dense200 är det man bör lägga märke till: sex gånger basmodellen i trånga scener.

• Räkning — 90,9 och 88,1 exakt matchning på de två PixMo-Count-delningarna, men 27,5 och 26,9 på CLOC, 29,5 och 32,4 på KubriCount och 47,9 på CountQA. Räkning är inte en enda färdighet, och spridningen är det mest ärliga i artikeln.

• OCR-lokalisering — genomsnittlig F1 på 30,5 för HierText, 42,6 för ICDAR2015, 42,5 för TotalText och 62,1 för SROIE, vid en IoU-tröskel på 0,5. Dessa är lokaliseringspoäng med tillhörande koordinater, inte transkriptionsnoggrannhet, så de är inte jämförbara med det OCRBench-värde som vanligtvis anges för konsument-VLM:er.

• Refererande segmentering — 79,7 kumulativt IoU på RefCOCO-validering, 73,1 på RefCOCO+, 74,4 på RefCOCOg och 60,9 gIoU på ReasonSeg.

• Promptbar matting – 6,6 i genomsnittlig absolut skillnad på P3M-500-NP med en box-prompt, jämfört med 15,4 för SAM2-Matting; 5,7 jämfört med 12,1 på AM-2K; 15,8 jämfört med 23,0 för en pipeline med Qwen3-VL-8B plus SAM2-Matting på den svårare referring-spliten i WeRefMat. Lägre är bättre genomgående.

Mattningsresultatet är där storleksargumentet vänds på. I samma box-prompt-test för P3M-500-NP får 2B 6,6 och Tencent:s egen 4B-syskonmodell 7,3. Den mindre modellen är den bättre av de två, Tencent förklarar inte varför, och artikeln publicerar det ändå. Om ditt jobb är att klippa ut objekt ur bilder är den billigaste varianten i familjen inte en nedgradering – den är för närvarande det val som mätts bäst.

Det som artikeln inte visar är lika viktigt att känna till. Det finns ingen MMMU, ingen MMBench, ingen DocVQA och ingen benchmark för bildbeskrivning någonstans i de sju tabellerna, och avsnittet om begränsningar medger att begränsade allmänna träningsdata "kan försämra de allmänna förmågorna jämfört med basmodellen". Finjusteringen som gjorde den bra på perception kan ha gjort den till en sämre allmän assistent, och ingenting i lanseringen testar det. Det finns heller inga utdata i form av tankekedjor, inget minne över flera turer och inget stöd för video – pixelavkodaren avvisar videorutnät helt och hållet.

Det enda jämförelsemått som skulle avgöra detta finns inte.

Ställer man de två utvärderingssviterna bredvid varandra upphör deras ojämförbarhet att vara en teknikalitet. UI-Venus-2-9B:s främsta resultat är framgångsfrekvenser 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. De mäter huruvida en uppgift slutfördes och sammanför perception, planering, minne och felåterhämtning till ett enda tal.

Det närmaste man kommer en gemensam axel är GUI-grounding – att lokalisera ett litet gränssnittselement i en högupplöst skärmbild. UI-Venus-2-9B uppnår 73,0 på ScreenSpot-Pro. WeVisOne-VL-2B rapporterar inget ScreenSpot-Pro-resultat, inget ScreenSpot-V2-resultat och ingen GUI-benchmark av något slag, varken på sitt modellkort, i sin artikel eller på sin projektwebbplats. Åt andra hållet rapporterar WeVisOne-VL-2B OCR-lokalisering och dense pointing, och UI-Venus-2-9B rapporterar inget av det.

Det finns en hake som får den parning som rubriken lyfter fram att verka ännu märkligare. inclusionAI har redan släppt en 2B-modell byggd på Qwen3-VL – UI-Venus-1.5-2B – och dess modellkort anger 57,7 på ScreenSpot-Pro, mot 68,4 för dess 8B-syskon och 69,6 för 30B-A3B. Det är den äkta storleksmatchade motsvarigheten till WeVisOne-VL-2B, på samma backbone-familj, mätt på det enda benchmark som båda serierna bryr sig om. Det är helt enkelt inte modellen som namnges i den här jämförelsen.

Så den ärliga hållningen är snäv. Inget publicerat tal jämför WeVisOne-VL-2B med UI-Venus-2-9B i någon uppgift, och ingen har kört 2B-perceptionsmodellen på en GUI-groundinguppsättning. Att köra WeVisOne-VL-2B på ScreenSpot-Pro är den enskilt mest användbara saknade mätningen i den här jämförelsen: den skulle visa om en 2B-perceptionsspecialist hittar gränssnittselement bättre eller sämre än en 9B-agent, och tills någon kör den bygger varje rangordning av dessa två efter hur bra de hittar saker på extrapolering från arkitekturen.

Vad var och en gör när objektet inte är där

Beteendet vid frånvarande objekt är där perceptionsmodeller i tysthet misslyckas. Fråga efter brandsläckaren i ett rum där det inte finns någon, och en modell som alltid svarar kommer självsäkert att rita en ruta runt radiatorn – och i en automatiserad pipeline blir det ett hallucinerat objekt i ett asset-bibliotek, eller en felriktad tryckning i en agentloop.

WeVisOne-VL-2B svarar None i stället, och artikeln rapporterar avvisning som ett eget mått vid sidan av träffsäkerheten. På RefCOCOg rapporterar den en avvisningsfrekvens på 50,2 för frågor om frånvarande objekt, mot 0,5 för Rex-Omni-3B och 0,6 för LocateAnything-3B i samma tabell. Det är ett annat designmål än att maximera recall, och det är siffran som gör en liten modell användbar som komponent: ett geometriben som säger "inte närvarande" är säkert att mata in i en planerare, medan ett som hittar på en box tyst korrumperar den.

UI-Venus-2-9B angriper samma problem från handlingssidan och ärver avböjningsmedveten grundning från UI-Venus-serien – den ä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 rimlig koordinat. Dess säkerhetstabell visar den effekt den 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 %. Kortet är också tydligt med att detta inte eliminerar risken för skadliga handlingar och rekommenderar mänsklig bekräftelse plus skyddsåtgärder på applikationsnivå. Båda teamen valde avståenden framför täckning; ingen av dem har fått det valet oberoende mätt.

Kör en 2B bredvid en 9B

{{1}}Den ärliga relationen mellan dessa två modeller är inte rivalitet utan sekvens.{{/1}} {{2}}Den ena returnerar geometri, den andra agerar på den.{{/2}} {{3}}Om du bygger ett system för skärmautomatisering placerar en rimlig arkitektur WeVisOne-VL-2B längst fram som den som rapporterar vad som finns var — boxar, OCR-spann, masker — och UI-Venus-2-9B bakom den som den som beslutar vad som ska göras.{{/3}} {{4}}Det är komposition, inte konkurrens, och det är det enda ramverk där kombinationen ger operativ mening.{{/4}}

Minnet gör den sammansättningen billig på en enda maskin. I bfloat16 är 2B-stommen ungefär 4 GB vikter före avkodaren, och 9B-modellen är cirka 18,8 GB fördelat över fyra shards. Båda får plats på ett enda 24 GB-kort med plats över för kontext; 2B ensam får plats på ett 8 GB-kort, vilket är det mer intressanta faktumet. Kontexttaken stämmer överens på 262 144 positioner, men de innebär olika saker: agenten använder lång kontext som episodminne och håller en historik med skärmbilder, medan perceptionsmodellens publicerade utvärderingar ligger på ungefär 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.

Kostnaden är där formerna skiljer sig åt. Ingen av leverantörerna publicerar ett pris per token, så för båda är den verkliga kostnaden GPU-timmar på hårdvara som du hyr eller äger. En agent betalar för en 9B-forwardpassning plus resonemangstoken vid varje steg, och en episod består av många steg – en siffra som du inte kan förutse utifrån kortet. En perceptionsmodell betalar för en 2B-passning plus en dekoder-forwardpassning per bild, och en bild är ett anrop. Hundra tusen produktbilder är förutsägbar aritmetik per bild; en webbläsaruppgift är det inte.

Det är också här som ett routningslager förtjänar sin plats i stället för att vara en slogan. Ingen av modellerna finns på OrcaRouter i dag – kontrollerat mot den aktuella katalogen med 209 modeller, och WeVisOne-VL-2B:s modellkort anger att den inte är driftsatt hos någon inferensleverantör över huvud taget. För de modeller vi faktiskt tillhandahåller är de användbara egenskaperna en OpenAI-kompatibel endpoint, 0 % påslag med leverantörens listpris vidarebefordrat oförändrat, ett routnings-DSL som komponerar flera modellanrop bakom ett enda gränssnitt, och automatisk failover. För en arkitektur med två ben som den ovan är DSL:et där kompositionen ligger och där endera benet kan bytas ut utan att anroparen skrivs om. Den dag 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.

Licens, pris och det som ingen har bekräftat

Modellkortet för WeVisOne-VL-2B anger Apache 2.0 för ”Tencent-authored code in this repository”, vilket är det tillåtande svaret som de flesta team vill ha. En detalj komplicerar saken: GitHubs API rapporterar att repots licens är ”Other” utan någon SPDX-identifierare. De här uppgifterna behöver inte nödvändigtvis stå i konflikt med varandra – tredjepartskomponenter behåller sina egna villkor – men det innebär att licensfilen är värd att läsa innan detta kommer i närheten av en produkt, i stället för att lita blint på märkningen.

UI-Venus-2-9B:s kort är det oklara. Det anger att licensen för modellvikterna inväntar slutlig bekräftelse och kommer att läggas till före offentlig lansering, och att den tidigare Apache-2.0-deklarationen medvetet inte fördes över eftersom uppströmsmaterial innehåller motstridiga licensangivelser. Den meningen har stått på kortet sedan augusti och har inte ändrats. Det stoppar inte utvärdering eller de flesta interna användningar, men en extern produkt som bygger på dessa vikter bygger på en öppen fråga, och inget benchmarkresultat stänger den.

Ingen av modellerna har ett pris som satts av leverantören. WeVisOne-VL-2B har ingen inferensleverantör och ingen prislista. UI-Venus-2-9B har ingen förstapartsendpunkt och inget pris som publicerats av inclusionAI, så vad en tredjepartsvärd än tar betalt är det den värdens siffra, inte teamets.

Vilken ska man välja?

Beslutet är en arbetsbeskrivning, inte en rangordning.

Välj WeVisOne-VL-2B om svaret du behöver är geometri – boxar till en annoteringspipeline, masker för ett redigeringsverktyg, alfamattor för produktbilder, antal i en tät bildruta, eller OCR med tillhörande koordinater – och särskilt om du behöver det på liten hårdvara. Det är den enda modellen här som returnerar en matta från en textprompt, den är bättre än sitt eget större syskon på att skapa mattor, och dess licens är den fastställda.

• Välj UI-Venus-2-9B om svaret du behöver är en slutförd uppgift: ett ifyllt formulär, en app navigerad, en CAPTCHA löst, ett skrivbordsarbetsflöde utfört. Du köper en agentloop, och du bör gå in i det med vetskapen att licensen är oklar och att långsiktigt skrivbordsarbete inte är löst i den här storleken — kortets egna OSWorld 2.0-siffror är 7,5 partiella och 0,0 binära.

Välj UI-Venus-1.5-2B i stället om det du faktiskt ville ha var en liten GUI-grounder. Det är den 2B stora, Qwen3-VL-baserade modellen i inclusionAI:s serie, den rapporterar 57,7 på ScreenSpot-Pro, och det är den storleksmatchade jämförelsemodellen som den här duellens namn antyder men inte namnger.

• Kör båda i sekvens om du bygger skärmautomation som behöver se precist och sedan agera — geometridelen först, agentdelen sedan, en GPU.

• Vänta, om en GUI-grounding-siffra för WeVisOne-VL-2B är det som ditt beslut hänger på. Den finns inte ännu, och att gissa den utifrån parameterantal är inte en metod.

Vad skulle ändra det här svaret?

Fyra saker, i ordning efter användbarhet. En ScreenSpot-Pro- eller ScreenSpot-V2-körning av WeVisOne-VL-2B skulle förvandla den centrala luckan i den här texten till en jämförelse, och med tanke på att modellen är en dag gammal och Apache 2.0 är det en helgs arbete för alla med en GPU och utvärderingsramverket. En licensavklaring för UI-Venus-2-9B skulle undanröja det enda hindret som ingen noggrannhetssiffra kan argumentera emot. En inferensleverantör som listar endera modellen skulle ersätta GPU-timmesaritmetik med ett faktiskt pris. Och en {{1}}4B-till-2B-jämförelse som förklarar varför den mindre modellen matchar bättre{{/1}} skulle berätta för köpare huruvida familjens namngivning betyder något alls.

Fram till dess är det användbara sättet att betrakta dessa två inte som rivaler på en resultattavla utan som olika instrument: ett som mäter bilden och ett som agerar på skärmen. Namnet på den här matchen antyder att du väljer mellan nästan likvärdiga små modeller. Du väljer mellan en 2B-specialist och en 9B-agent, och det enda de verkligen har gemensamt är en vana att säga nej.