WeVisOne-VL-2B vs UI-Venus-2-9B: The Size Gap the Name Hides

Nine billion parameters is not what the matchup says. Written the way most people write it — WeVisOne-VL-2B vs UI-Venus 2.9B — the pairing reads as two small vision models of roughly the same weight, a fair fight between a fresh 2B checkpoint from Tencent's WeChat Vision team and something a little larger from Ant Group's inclusionAI. The second half of that assumption is false. UI-Venus-2-9B is UI-Venus 2 at 9 billion parameters, initialised from Qwen3.5-9B; the "2" is the generation, not the size. WeVisOne-VL-2B, pushed to Hugging Face on 22 October 2026, is 2 billion parameters on a Qwen3-VL backbone. The real comparison is therefore a model four and a half times smaller, on an older backbone generation, that returns an entirely different kind of answer.

It also arrived without a launch. There is a Hugging Face repository, a GitHub repository carrying a single initial commit, a paper on arXiv and a research project page — and no vendor announcement, no blog post and no pricing page tying them together. That shapes what this article can honestly do. The weights, the architecture, the licence text and the paper's tables are checkable today. Independent evaluation, throughput, latency and price are not, because none of them exists yet. Tencent's model card publishes no benchmark numbers at all; every score attributed to WeVisOne-VL-2B below comes from its authors' own seven task tables and is labelled that way. UI-Venus-2-9B is older and better documented, but its numbers are exactly as self-reported.

What the two names actually describe

WeVisOne-VL-2B is a perception model. Hand it an image and a phrase and it returns geometry: a bounding box, a point, a count, a binary mask, or a continuous alpha matte. Its language side emits coordinates as dedicated tokens spanning <0> to <1000>, normalised to the image, and closes each box in dense tasks with a special <OBJ> token at id 152,678. Those tokens are just markers until mask_decoder.pt reads the hidden state behind them — a required 9,511,460-parameter artifact, shipped as a second file, which the card describes as "a required core component, not an optional add-on." Without it you get boxes. With it you get masks and stride-1 alpha mattes.

UI-Venus-2-9B is an agent. Hand it a screenshot and a task and it returns a move: the next tap, click or keystroke, plus the reasoning tokens that produced it, inside a closed observe–reason–act loop. It was trained on screenshot-only interaction across grounding, CAPTCHA, mobile, web and computer use, and its published vLLM recipe pairs a 262,144 maximum model length with the Qwen3 reasoning parser because the reasoning trace comes out ahead of every action.

Put the two side by side and the mismatch is immediate:

• What comes back — boxes, points, counts, OCR spans, masks and alpha mattes from WeVisOne-VL-2B; one screen action plus its reasoning trace from UI-Venus-2-9B.

• Parameters — 2B for WeVisOne-VL-2B plus the separate 9.5M decoder; 9B dense for UI-Venus-2-9B, about 4.5 times the weights.

• Backbone — Qwen3-VL for WeVisOne-VL-2B, 28 text layers at a hidden size of 2,048; Qwen3.5-9B for UI-Venus-2-9B. Different generations, different text stacks.

• Weights on disk — bfloat16 for both, but roughly 4GB for the 2B against four BF16 shards totalling about 18.8GB for the 9B.

• Context ceiling — 262,144 positions on each, read from WeVisOne-VL-2B's config and from UI-Venus-2-9B's serving command. Neither vendor demonstrates using anything like it.

• Published evidence — seven task tables in Tencent's paper and none on the model card; a long vendor benchmark list on inclusionAI's card and no paper tables.

• Licence — Apache 2.0 for Tencent-authored code; "pending final confirmation" for the UI-Venus-2-9B weights.

The practical consequence is that you cannot swap one for the other, and any article handing you a winner is answering a question you did not ask. A perception model that returns a perfect matte still cannot press a button. An agent that navigates an app perfectly still cannot hand you the cutout you wanted for a product shot.

The case for the smaller model is stronger than 2B versus 9B suggests

The instinct on seeing a 2B next to a 9B is that the small one is the budget compromise. On the work it was trained for, Tencent's paper argues otherwise, and one of its own results argues against its own larger release. All figures here are the authors' own, run by the authors, reproduced by nobody.

• Zero-shot detection — mean F1 of 55.2 on COCO, 53.3 on LVIS, 61.4 on Dense200 and 40.4 on VisDrone. The Qwen3-VL-2B baseline scores 45.2, 40.8, 10.0 and 23.1 on the same table. The Dense200 gap is the one to notice: six times the base model on crowded scenes.

• Counting — 90.9 and 88.1 exact match on the two PixMo-Count splits, but 27.5 and 26.9 on CLOC, 29.5 and 32.4 on KubriCount, and 47.9 on CountQA. Counting is not one skill, and the spread is the most honest thing in the paper.

• OCR localisation — mean F1 of 30.5 on HierText, 42.6 on ICDAR2015, 42.5 on TotalText and 62.1 on SROIE, at a 0.5 IoU threshold. These are localisation scores with coordinates attached, not transcription accuracy, so they are not comparable to the OCRBench number usually quoted for consumer VLMs.

• Referring segmentation — 79.7 cumulative IoU on RefCOCO validation, 73.1 on RefCOCO+, 74.4 on RefCOCOg and 60.9 gIoU on ReasonSeg.

• Promptable matting — 6.6 mean absolute difference on P3M-500-NP with a box prompt against 15.4 for SAM2-Matting; 5.7 against 12.1 on AM-2K; 15.8 against 23.0 for a Qwen3-VL-8B plus SAM2-Matting pipeline on the harder WeRefMat referring split. Lower is better throughout.

The matting result is where the size argument inverts. On that same P3M-500-NP box-prompt test, the 2B scores 6.6 and Tencent's own 4B sibling scores 7.3. The smaller model is the better matter of the two, Tencent does not explain why, and the paper prints it anyway. If your job is cutting objects out of images, the cheapest variant in the family is not a downgrade — it is currently the best-measured choice.

What the paper does not show is equally worth knowing. There is no MMMU, no MMBench, no DocVQA and no captioning benchmark anywhere in the seven tables, and the limitations section concedes that limited general-purpose training data "may compromise the general capabilities relative to the base model." The fine-tuning that made this good at perception may have made it a worse general assistant, and nothing in the release tests that. Nor is there any chain-of-thought output, any multi-turn memory, or support for video — the pixel decoder rejects video grids outright.

The one benchmark that would settle this does not exist

Set the two evaluation suites beside each other and the incomparability stops being a technicality. UI-Venus-2-9B's headline results are end-state success rates in an environment: AndroidWorld 80.2, OSWorld-Verified 70.8, WebVoyager 90.8, Online-Mind2Web 74.0, MobileWorld 65.8 at the card's default step budget and 75.2 at 100 steps. Those measure whether a task got finished, folding perception, planning, memory and error recovery into a single number.

The closest thing to a shared axis is GUI grounding — locating a small interface element in a high-resolution screenshot. UI-Venus-2-9B posts 73.0 on ScreenSpot-Pro. WeVisOne-VL-2B reports no ScreenSpot-Pro result, no ScreenSpot-V2 result and no GUI benchmark of any kind, on its card, in its paper or on its project page. In the other direction, WeVisOne-VL-2B reports OCR localisation and dense pointing, and UI-Venus-2-9B reports neither.

There is a wrinkle that makes the headline pairing look stranger still. inclusionAI already ships a 2B model built on Qwen3-VL — UI-Venus-1.5-2B — and its card reports 57.7 on ScreenSpot-Pro, against 68.4 for its 8B sibling and 69.6 for the 30B-A3B. That is the genuine size-matched counterpart to WeVisOne-VL-2B, on the same backbone family, measured on the one benchmark both lines care about. It is simply not the model named in this matchup.

So the honest position is narrow. No published number compares WeVisOne-VL-2B to UI-Venus-2-9B on any task, and nobody has run the 2B perception model on a GUI grounding set. Running WeVisOne-VL-2B on ScreenSpot-Pro is the single most useful missing measurement in this comparison: it would tell you whether a 2B perception specialist finds interface elements better or worse than a 9B agent, and until somebody runs it, anyone ranking these two on finding things is extrapolating from architecture.

What each one does when the object is not there

Absent-object behaviour is where perception models quietly fail. Ask for the fire extinguisher in a room that has none and a model that always answers will confidently box the radiator — and in an automated pipeline that becomes a hallucinated object in an asset library, or a misdirected tap in an agent loop.

WeVisOne-VL-2B answers None instead, and the paper reports rejection as its own metric next to accuracy. On RefCOCOg it reports a rejection rate of 50.2 for absent-object queries, against 0.5 for Rex-Omni-3B and 0.6 for LocateAnything-3B on the same table. That is a different design goal from maximising recall, and it is the number that makes a small model usable as a component: a geometry leg that says "not present" is safe to feed into a planner, while one that invents a box silently corrupts it.

UI-Venus-2-9B comes at the same problem from the action side, inheriting refusal-aware grounding from the UI-Venus line — it is trained to decline when the requested element is not on screen rather than guess a plausible coordinate. Its safety table shows the effect it claims: an 11.3% attack success rate on OSHarm against 25.3% for the Qwen3.5-9B base, and 48.8% on OSBlind against 79.4%. The card is also explicit that this does not eliminate harmful-action risk and recommends human confirmation plus application-level safeguards. Both teams chose abstention over coverage; neither has had that choice independently measured.

Running a 2B beside a 9B

The honest relationship between these two models is not rivalry but sequence. One returns geometry, the other acts on it. If you are building a screen automation system, a plausible architecture puts WeVisOne-VL-2B in front as the thing that reports what is where — boxes, OCR spans, masks — and UI-Venus-2-9B behind it as the thing that decides what to do. That is composition, not competition, and it is the only framing in which the pairing makes operational sense.

Memory makes that composition cheap on one machine. At bfloat16 the 2B backbone is roughly 4GB of weights before the decoder, and the 9B is about 18.8GB across four shards. Both fit on a single 24GB card with room left for context; the 2B alone fits on an 8GB card, which is the more interesting fact. Context ceilings agree at 262,144 positions, but they mean different things: the agent uses long context as episode memory, holding a history of screenshots, while the perception model's published evaluations run at roughly 1,960 visual tokens per image. A 256K window on a single-turn, image-only model is a ceiling, not a demonstrated capability.

Cost is where the shapes diverge. Neither vendor publishes a per-token price, so for both the real cost is GPU-hours on hardware you rent or own. An agent pays for a 9B forward pass plus reasoning tokens on every step, and an episode is many steps — a number you cannot forecast from the card. A perception model pays for a 2B pass plus a decoder forward per image, and one image is one call. A hundred thousand product photos is predictable per-image arithmetic; a browser task is not.

This is also where a routing layer earns its place rather than being a slogan. Neither model is on OrcaRouter today — checked against the live catalogue of 209 models, and WeVisOne-VL-2B's card states it is not deployed by any inference provider at all. For the models we do serve, the useful properties are one OpenAI-compatible endpoint, 0% markup with provider list price passed through unchanged, a routing DSL that composes several model calls behind one interface, and automatic failover. For a two-leg architecture like the one above, the DSL is where the composition lives and where either leg can be swapped without rewriting the caller. The day either of these two lands on a provider, that is the cheapest way to find out whether it belongs in your stack.

Licence, price, and what nobody has confirmed

WeVisOne-VL-2B's card grants Apache 2.0 for "Tencent-authored code in this repository," which is the permissive answer most teams want. One detail complicates it: the GitHub API reports the repository licence as "Other" with no SPDX identifier. Those statements are not necessarily in conflict — third-party components keep their own terms — but it means the licence file is worth reading before this goes near a product rather than taking the badge at face value.

UI-Venus-2-9B's card is the unresolved one. It states that the model-weight licence is pending final confirmation and will be added before public release, and that the earlier Apache-2.0 declaration was intentionally not carried over because upstream materials contain conflicting licence statements. That sentence has been on the card since August and has not changed. It does not stop evaluation or most internal use, but an external product built on those weights is built on an open question, and no benchmark score closes it.

Neither model has a vendor-set price. WeVisOne-VL-2B has no inference provider and no rate card. UI-Venus-2-9B has no first-party endpoint and no pricing published by inclusionAI, so whatever a third-party host charges is that host's number, not the team's.

Which one to pick

The decision is a job description, not a ranking.

• Pick WeVisOne-VL-2B if the answer you need is geometry — boxes into an annotation pipeline, masks for an editing tool, alpha mattes for product imagery, counts in a dense frame, or OCR with coordinates attached — and especially if you need it on small hardware. It is the only model here that returns a matte from a text prompt, it beats its own larger sibling at matting, and its licence is the settled one.

• Pick UI-Venus-2-9B if the answer you need is a completed task: a form filled, an app navigated, a CAPTCHA solved, a desktop workflow executed. You are buying an agent loop, and you should go in knowing the licence is unresolved and long-horizon desktop work is not solved at this size — the card's own OSWorld 2.0 figures are 7.5 partial and 0.0 binary.

• Pick UI-Venus-1.5-2B instead if what you actually wanted was a small GUI grounder. It is the 2B, Qwen3-VL-based model in inclusionAI's line, it reports 57.7 on ScreenSpot-Pro, and it is the size-matched comparator this matchup's name implies but does not name.

• Run both in sequence if you are building screen automation that needs to see precisely and then act — geometry leg first, agent leg second, one GPU.

• Wait if a GUI-grounding number for WeVisOne-VL-2B is the thing your decision turns on. It does not exist yet, and guessing it from parameter counts is not a method.

What would change this answer

Four things, in order of usefulness. A ScreenSpot-Pro or ScreenSpot-V2 run of WeVisOne-VL-2B would convert the central gap in this piece into a comparison, and given the model is one day old and Apache 2.0, that is a weekend of work for anyone with a GPU and the evaluation harness. A licence resolution on UI-Venus-2-9B would remove the one blocker that no accuracy figure can argue with. An inference provider listing either model would replace GPU-hour arithmetic with an actual price. And a 4B-to-2B comparison that explains why the smaller model mats better would tell buyers whether the family's naming means anything at all.

Until then, the useful way to hold these two is not as rivals on a leaderboard but as different instruments: one that measures the image and one that acts on the screen. The name of this matchup suggests you are choosing between near-equal small models. You are choosing between a 2B specialist and a 9B agent, and the only thing they genuinely share is a habit of saying no.