WeVisOne-VL-4B vs UI-Venus-2-9B: De ene retourneert een masker, de andere retourneert een klik

Geef dezelfde screenshot van een afrekenpagina aan WeVisOne-VL-4B en aan UI-Venus-2-9B en je krijgt twee verschillende soorten antwoorden. De eerste geeft je geometrie: een kader rond het winkelwagenpictogram, een segmentatiemasker rond het kortingsveld, een alpha-mat die de productfoto uit haar achtergrond snijdt. De tweede geeft je een zet: de coördinaten van de volgende tik, plus de redenering die daartoe leidde. Het WeChat Vision-team van Tencent publiceerde WeVisOne-VL-4B op Hugging Face zonder aankondiging en dateerde zijn technische paper op 23 oktober 2026; inclusionAI's UI-Venus-2-9B is sinds 26 augustus 2026 te downloaden. Ze worden onder hetzelfde modaliteitslabel geschaard en ze zijn geen vervangers van elkaar.

Dat maakt dit tot een vergelijking met een ongebruikelijk probleem in de kern: de twee modellen hebben geen gemeenschappelijke benchmark. Geen enkele score staat op beide modelkaarten. Geen van beide is onafhankelijk geëvalueerd, geen van beide wordt door een inferentieprovider ingezet en geen van beide heeft een gepubliceerde prijs. Wat eerlijk kan worden vergeleken, is wat elk model oplevert, hoe elk is getraind om te weigeren, wat de uitvoering kost en onder welke licentie je het zou uitbrengen — dus dat is wat dit artikel doet, en het markeert door de leverancier gerapporteerde cijfers telkens als zodanig wanneer er een voorkomt.

De twee modellen beantwoorden niet dezelfde vraag.

WeVisOne-VL-4B is een perceptiemodel. Het is gebouwd op een Qwen3-VL-backbone en voegt een vereiste pixeldecoder van 9,6 miljoen parameters toe — mask_decoder.pt, geleverd als een tweede artefact — die de boxvoorspellingen van het taalmodel omzet in instance masks en vervolgens in stride-1 alpha mattes. Coördinaten worden als speciale tokens gegenereerd, lopend van <0> tot <1000>, genormaliseerd ten opzichte van de afbeelding, en een speciaal <OBJ>-token (id 152.678) sluit elke box in dense taken. De takenlijst in het artikel is een opsomming van geometrie: open-vocabulary-detectie, referring-localisatie, tellen, pointing, OCR-localisatie, referring-segmentatie en promptable alpha matting.

UI-Venus-2-9B is een agent. Het wordt geïnitialiseerd vanuit Qwen3.5-9B en getraind op interactie uitsluitend via screenshots binnen vijf taakfamilies — grounding, CAPTCHA, mobiel, web en computer — via mid-training, offline reinforcement learning op stappenniveau en multi-teacher on-policy distillatie. De output is een actie in een gesloten observe–reason–act-lus, en het vLLM-recept combineert --max-model-len 262144 met --reasoning-parser qwen3 omdat het vóór elke actie reasoning-tokens genereert.

Zet de specificaties naast elkaar en het verschil is meteen duidelijk:

• Wat eruit komt — boxen, punten, maskers en alpha mattes van WeVisOne-VL-4B; één actie plus de bijbehorende redeneertrace van UI-Venus-2-9B.

• Backbone — Qwen3-VL voor WeVisOne-VL-4B; Qwen3.5-9B voor UI-Venus-2-9B. Verschillende generaties, verschillende families van de tekststack.

Grootte — 5B parameters vermeld op de repo ondanks een "4B"-naam, plus een aparte decoder van 9,6M parameters; 9B dense voor UI-Venus-2-9B over vier BF16-shards, ongeveer 18,8 GB.

• Gewichtsformaat — F32-safetensors op de WeVisOne-VL-4B-kaart, wat ongewoon is voor deze grootte en de download groter maakt dan het aantal parameters doet vermoeden; BF16 voor UI-Venus-2-9B.

• Licentie — Apache 2.0 voor WeVisOne-VL-4B; "in afwachting van definitieve bevestiging" voor UI-Venus-2-9B.

De praktische consequentie is dat je het ene niet voor het andere kunt inruilen, en elk artikel dat een winnaar aanwijst, beantwoordt een vraag die je niet hebt gesteld. Een perceptiemodel dat een perfect masker oplevert, kan nog steeds niet klikken. Een agent die perfect klikt, kan je nog steeds niet de matte geven die je wilde voor de productshoot.

Waar ze echt overlappen: beide teams leerden hun model nee te zeggen

Dit is de enige ontwerpbeslissing die beide releases hebben genomen, en het is het meest interessante aspect van de combinatie. Open-vocabulary-localisatiemodellen falen op een specifieke, dure manier: vraag om de brandblusser in een kamer waar er geen is, en een model dat altijd antwoordt, zal vol vertrouwen de radiator omkaderen. Stroomafwaarts is dat een gehallucineerd object in je asset-pipeline of een verkeerd gerichte tik in je automatiseringslus.

WeVisOne-VL-4B lost dit op door None terug te geven, en het artikel rapporteert het afwijzingspercentage als een eigen metriek naast de nauwkeurigheid. Op RefCOCOg bereikt het 4B-model een afwijzingspercentage van 67,4, waar zijn Qwen3-VL-4B-basis op 18,8 zit. Op de WeChat-interne WeRef-Bench rapporteert het 96,4 afwijzing tegenover 61,9 voor het basismodel, en op Ref-ZOM 86,0 tegenover 0,3 voor UniPixel-7B. Dat zijn zelfgerapporteerde cijfers uit een artikel dat vandaag is gepubliceerd, en de afwijzingsbenchmarks zijn grotendeels van de auteurs zelf — beschouw de richting als geloofwaardig en het exacte verschil als niet geverifieerd.

UI-Venus-2-9B benadert hetzelfde probleem vanuit de agentkant en erft refusal-aware grounding van de UI-Venus-lijn: het model is getraind om te weigeren wanneer het gevraagde element niet op het scherm staat, in plaats van een plausibele locatie te raden. De groundingcijfers — ScreenSpot-Pro 73,0, VenusBench-GD 77,1, OSWorld-G-R 78,5 — zijn door de leverancier gerapporteerd, en de kaart stelt expliciet dat dit het risico op schadelijke acties niet wegneemt en raadt menselijke bevestiging plus beveiligingsmaatregelen op applicatieniveau aan. De veiligheidstabel toont het effect dat het wel claimt: een aanvalsuccespercentage van 11,3% op OSHarm tegenover 25,3% voor de Qwen3.5-9B-basis, en 48,8% op OSBlind tegenover 79,4%.

Dus beide modellen zijn gebouwd door teams die een localisator hebben zien liegen, en beide kozen onthouding boven dekking. Als de faalmodus van je applicatie 'zelfverzekerd fout' is, weegt die gedeelde prioriteit zwaarder dan het aantal parameters.

De cijfers die de modelkaart van Tencent niet toont

Elk verslag over WeVisOne-VL-4B tot nu toe heeft hetzelfde gezegd, en dat klopt: op de modelkaart staan geen benchmarks. In het technische paper staan ze wel, en dat verscheen op 23 oktober 2026, waardoor dit het deel van het verhaal is dat nog niet de ronde heeft gedaan. Het is allemaal door de auteurs zelf gerapporteerd, niets ervan is onafhankelijk gereproduceerd, en het model is één dag oud — lees dit dus als beweringen met een vorm, niet als definitieve resultaten.

Vergeleken met zijn eigen Qwen3-VL-4B-basis zijn de verschillen groot genoeg om zelfs na forse afzwakking interessant te zijn:

• Detectie, COCO zero-shot gemiddelde F1 — 57,1 voor WeVisOne-VL-4B versus 48,7 voor Qwen3-VL-4B, en 55,3 versus 44,0 op LVIS.

• Detectie, Dense200 gemiddelde F1 — 71,3 versus 15,2. Dat is geen typfout in de tabel van het artikel; dichte scènes met kleine objecten zijn waar het basismodel instort.

• Referentiedetectie, RefCOCOg val — 80,8 vs 74,1, met het afwijzingspercentage op 67,4 vs 18,8.

• Tellen, exacte overeenkomst op PixMo-Count val — 93,7 vs 69,6; op MixCount val, 42,0 vs 3,5.

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

• OCR-localisatie, SROIE-gemiddelde F1 — 68,1 vs 40,4, en beter dan de 58,6 van PP-OCRv5.

• Verwijzende segmentatie, ReasonSeg val gIoU — 71,2, tegenover 65,0 voor LISA-13B.

• Matting met prompts, AM-2K box-prompt-MAD — 5,0 tegen 12,1 voor SAM2-Matting; bij WeRefMat-verwijzingsprompts 9,8 tegen 51,9.

Het matting-resultaat is het resultaat waarbij je even moet stilstaan, omdat het het vermogen is dat niets anders in deze prijsklasse via een prompt biedt. Een visie-taalmodel vragen om "de persoon, als een alpha matte" en een stride-1-uitvoer krijgen die een SAM2-mattingpipeline verslaat op MAD, is een ander product dan een detectiekop met een aangehecht masker. Het is ook het punt waarop de paper het minst flatteus is voor zijn eigen 4B: bij P3M-500-NP-box-prompts scoort het 2B-model 6,6 MAD tegenover 7,3 voor de 4B, dus de grotere variant is niet uniform beter en de auteurs drukken dat af.

Wat de cijfers van UI-Venus-2-9B meten, en waarom ze niet overdraagbaar zijn

Zet de twee benchmarksuites naast elkaar, en de onvergelijkbaarheid is geen technisch detail meer. De meest in het oog springende resultaten van UI-Venus-2-9B zijn allemaal succespercentages op basis van de eindtoestand in een omgeving: AndroidWorld 80,2, OSWorld-Verified 70,8, WebVoyager 90,8, Online-Mind2Web 74,0, MobileWorld 65,8 bij het standaard stappenbudget van de kaart en 75,2 bij 100 stappen. Die cijfers meten of een taak is voltooid, waardoor perceptie, planning, geheugen en foutherstel in één getal samenvallen.

Het dichtst bij een gedeelde as komt GUI-grounding. UI-Venus-2-9B scoort 73,0 op ScreenSpot-Pro, een benchmark voor het lokaliseren van kleine interface-elementen in schermafbeeldingen met hoge resolutie — en WeVisOne-VL-4B rapporteert dat niet. WeVisOne-VL-4B rapporteert resultaten voor OCR-lokalisatie en dense pointing, en UI-Venus-2-9B rapporteert die niet. De eerlijke positie is dus dat het enkele nuttigste getal voor deze vergelijking nog niet bestaat: WeVisOne-VL-4B op ScreenSpot-Pro draaien zou laten zien of een 5B-perceptiespecialist een 9B-agent verslaat bij het vinden van een knop, en tot iemand dat doet, gokt iedereen die deze twee op grounding rangschikt.

De eigen suite van de agent legt ook zijn zwakke plek publiekelijk bloot. Op OSWorld 2.0 scoort het 9B-model 7,5 op partial en 0,0 op binary; het 27B-zustermodel haalt 13,2 op partial en 2,8 op binary. Langdurig desktopwerk is op deze omvang niet opgelost, en de kaart zegt dat ook.

Het serveren ervan is een grotere kloof dan de benchmarkkloof.

Voor een team dat beslist wat het volgende week gaat draaien, zal het operationele verschil meer uitmaken dan welke score dan ook. UI-Venus-2-9B is één model dat je met één vLLM-commando start, met een OpenAI-compatibel endpoint en tensor-parallelisme van 1. WeVisOne-VL-4B heeft zijn inferencepakket van GitHub nodig plus het afzonderlijke decoder-artifact, en wordt aangeroepen via zijn eigen WeVisOneVL(...)-wrapper met een task-argument — predict(image, task="matting", query="person", temperature=0.0). De modelkaart documenteert de paden voor Transformers, vLLM en SGLang, maar de pixeldecoder is niet optioneel: het taalmodel alleen kan geen masker produceren.

Het geheugen ligt dichter bij elkaar dan de parameteraantallen doen vermoeden. Bij bf16 is de 5B-backbone ongeveer 10 GB vóór de decoder, tegenover ongeveer 18,8 GB voor de vier shards van UI-Venus-2-9B. Beide passen qua gewichten op één kaart van 24 GB; het verschil zit in hoeveel ruimte er overblijft voor context.

En wat context betreft, komen de twee configs op een manier overeen die makkelijk te overinterpreteren is. De config van WeVisOne-VL-4B levert een max_position_embeddings van 262.144 — dezelfde bovengrens die UI-Venus-2-9B biedt met zijn maximale modellengte van 262.144. Maar ze gebruiken die voor verschillende doelen: de agent behandelt lange context als episodisch geheugen en houdt de schermafbeeldingsgeschiedenis van een taak vast, terwijl de gepubliceerde evaluaties van het perceptiemodel draaien op 1.960 visuele tokens per afbeelding. Een venster van 256K op een single-turn model dat alleen afbeeldingen verwerkt, is een bovengrens, geen aangetoonde capaciteit, en de modelkaart noemt videorasters iets dat de pixeldecoder ronduit afwijst.

Licentie: één van deze is geregeld en één niet.

WeVisOne-VL-4B valt onder Apache 2.0, met door Tencent geschreven code onder dezelfde voorwaarden. Je kunt het lezen, forken, het in een product verwerken en hoeft daar geen advocaat over te raadplegen.

De modelkaart van UI-Venus-2-9B vermeldt dat de licentie voor de modelgewichten wacht op definitieve bevestiging en vóór de publieke release wordt toegevoegd, en dat de eerdere Apache-2.0-verklaring bewust niet is overgenomen omdat de upstream-materialen tegenstrijdige licentievoorwaarden bevatten. Die zin staat sinds augustus op de kaart en is niet veranderd. Het weerhoudt je er niet van het model te evalueren, en het verhindert intern gebruik bij de meeste organisaties niet — maar het betekent wel dat een extern product dat op die gewichten is gebouwd, op een onopgeloste kwestie is gebouwd, en geen enkele benchmarkscore lost dat op. Als je tussen deze twee kiest voor iets dat je van plan bent uit te brengen, beslist de licentiekolom sneller dan de nauwkeurigheidskolom.

Wat elk kost, aangezien geen van beide een prijs heeft

Voor geen van beide modellen bestaat een door de leverancier vastgestelde prijs per token. Op de pagina van WeVisOne-VL-4B staat dat het door geen enkele inferenceprovider wordt aangeboden; UI-Venus-2-9B heeft geen first-party-endpoint en geen door inclusionAI gepubliceerde prijslijst, dus wat een externe host ervoor rekent, is het tarief van die host, niet dat van het team. Voor beide geldt dat de kosten GPU-uren zijn op hardware die je huurt of bezit, wat betekent dat de vergelijking niet "inputprijs versus outputprijs" is, maar "hoeveel kaarten heb ik nodig en hoeveel afbeeldingen per seconde verwerkt het?"

Geen van beide papers publiceert doorvoer of latency, dus dat tweede getal is voor beide onbekend. Wat wel kenbaar is, is de vorm: UI-Venus-2-9B betaalt voor een 9B-forward-pass plus reasoning-tokens bij elke stap van een episode, en een agent-episode bestaat uit vele stappen. WeVisOne-VL-4B betaalt voor een 5B-pass plus een decoder-forward per afbeelding, en één afbeelding is één aanroep. Als je workload honderdduizend productfoto's is, zijn de kosten van het perceptiemodel per afbeelding en voorspelbaar; als het een browsertaak is, schaalt de kosten van de agent met het aantal acties dat de taak vereist, en dat is het getal dat je niet uit de kaart kunt voorspellen.

Dit is ook waar een routinglaag zijn plek verdient in plaats van een slogan te zijn. Geen van beide modellen staat vandaag op OrcaRouter, en dit stuk gaat niet doen alsof dat anders is — WeVisOne-VL-4B heeft helemaal geen inference-provider, en UI-Venus-2-9B wordt aangeboden via hosting door derden in plaats van uit onze eigen catalogus. Wat OrcaRouter biedt voor de modellen die het wél aanbiedt, is één OpenAI-compatibel endpoint voor 200+ daarvan met 0% opslag, waarbij de lijstprijs van de provider ongewijzigd wordt doorgegeven, zodat een prijsverlaging van een leverancier je bereikt op de dag dat die gebeurt in plaats van bij de volgende contractverlenging. Voor een architectuur die een perceptiemodel en een agentmodel achter elkaar aanroept, is de routing-DSL de plek waar die compositie zit — twee modelaanroepen, één plek om elk van beide benen te vervangen — en automatische failover is wat een agentloop in leven houdt wanneer het model erachter midden in een episode verslechtert. Zodra een van deze twee bij een provider beschikbaar komt, is dat de goedkoopste manier om erachter te komen of het in je stack thuishoort.

Welke moet je kiezen?

De beslissing is een functiebeschrijving, geen ranglijst.

• Kies WeVisOne-VL-4B als de output die je nodig hebt geometrie is — bounding boxes voor een annotatiepipeline, masks voor een bewerkingstool, alpha mattes voor productafbeeldingen, aantallen objecten in een druk luchtbeeld, of OCR met bijbehorende coördinaten. Niets anders in de open 5B-klasse levert een matte op basis van een tekstprompt, en de mattingcijfers van de paper tegenover een SAM2-pipeline zijn de sterkste claim in de release.

• Kies UI-Venus-2-9B als de output die je nodig hebt een voltooide taak is — een ingevuld formulier, een doorlopen app, een opgeloste CAPTCHA, een desktopworkflow die vanuit screenshots wordt aangestuurd. Het wordt geleverd als één vLLM-commando met een OpenAI-compatibel endpoint, wat een dag werk is in plaats van een week, en de AndroidWorld- en WebVoyager-resultaten zijn de cijfers om tegen je eigen omgeving te vergelijken.

• Kies nog geen van beide als je onafhankelijk bewijs, een gepubliceerde prijs of een definitieve licentie voor een product dat op de markt wordt gebracht nodig hebt. Alle drie ontbreken voor de licentie van UI-Venus-2-9B en voor de benchmarks van beide modellen.

• Overweeg beide als je een agent bouwt die afbeeldingen moet manipuleren in plaats van alleen door schermen te klikken. De combinatie is de interessante: UI-Venus-2-9B bepaalt waar moet worden gehandeld, WeVisOne-VL-4B produceert het pixelaccurate artefact waarop de actie was gericht. Dat kost twee modelaanroepen per stap en levert een precisie op die geen van beide modellen alleen heeft.

Wat zou dit antwoord veranderen?

Vier dingen, in volgorde van hoeveel ze eraan zouden veranderen.

Een ScreenSpot-Pro-run van WeVisOne-VL-4B. Het is de enige benchmark waarop beide partijen redelijkerwijs kunnen zitten, en die zou beslechten of een perceptiespecialist op de helft van de omvang een speciaal voor UI gebouwde agent beter lokaliseert. Iedereen met een GPU en een middag kan hem produceren, en toch heeft niemand dat gedaan.

Een onafhankelijke evaluatie van elk van beide modellen. Elk getal in dit artikel is terug te voeren op een modelkaart of een paper geschreven door het team dat het ding heeft gebouwd. Dat is normaal op de releasedag, en het blijft een leemte.

Een uitgeklaarde licentie voor UI-Venus-2-9B. "In afwachting van definitieve bevestiging" staat al acht weken op de kaart. Als het uitdraait op iets permissiefs, wordt de agent aanzienlijk gemakkelijker aan te bevelen voor commercieel werk; zo niet, dan beantwoordt dat de vraag in omgekeerde zin.

Een first-party endpoint voor beide. Geen van beide leveranciers host vandaag zijn eigen model, waardoor het publiek beperkt blijft tot teams die bereid zijn een serving-stack te draaien, en aan de WeVisOne-VL-4B-kant tot teams die bereid zijn een custom inference-package te gebruiken. Een door de leverancier gepubliceerd tarief zou de kostenvergelijking veranderen van rekenwerk in een regelpost.

Tot dan is de eerlijke samenvatting deze: Tencent heeft een perceptie-toolkit uitgebracht die iets doet wat geen enkel klein open model eerder deed, en dat zo stil dat de eigen benchmarktabellen ervan nog niet zijn gelezen, en Ant Group bracht anderhalve maand eerder een agent uit die makkelijker te draaien en moeilijker te licentiëren is. Ze zijn geen rivalen. De fout zou zijn er één te kiezen omdat de ander hoger scoorde op een benchmark die ze niet delen.