Molmo2-4B vs WeVisOne-VL-4B: Points, Masks, and the Question Nobody Asks First

Ask both models to find the dog and you get an answer from each. Molmo2-4B returns a coordinate. WeVisOne-VL-4B returns a bounding box, and if you ask for the matte, a full-resolution alpha channel with the fur still on it. Those are three different products wearing the same word — "grounding" — and which one you need decides this comparison long before any benchmark does. Molmo2-4B is a 4.85B generalist vision-language model from the Allen Institute for AI with a point output and a real video path. WeVisOne-VL-4B is a 4.83B perception model from Tencent's WeChat Vision team that unifies detection, referring localisation, counting, pointing, OCR, referring segmentation and promptable alpha matting behind one checkpoint plus a 9.6M-parameter pixel decoder. Perception pipelines rarely stop at one model. 0% markup pricing The provider's list price is passed through unchanged, so a vendor cut is live the same day.

Neither is new. Molmo2-4B was announced on 11 December 2025 and its weights went up on 14 December. WeVisOne-VL-4B's repository appeared on 22 October 2026 with an arXiv paper, 2610.31329, attached. The recent change on the Molmo side is infrastructure rather than a model: native Transformers support merged on 9 October and shipped in v5.20.0 on 15 October, and Ai2 posted a Molmo2-4B robotics fine-tune on 5 November. Useful if you were waiting to run it without remote code. Not a release, and not a reason to call this a launch.

The output contract is the whole decision

• Molmo2-4B — a point, in 0–1000 of image width and height, wrapped in a tag with a published regex; in video mode each point carries a timestamp, and multi-image pointing flattens to frame-index, x, y triples.

• WeVisOne-VL-4B — a box, a point, a mask, or an alpha matte, selected by the task argument; dense tasks emit an instance token after each box and the pixel decoder turns those into masks and mattes.

• Pointing is the one output both produce, and it is the only place a fair comparison exists.

• Molmo2-4B has no segmentation head and cannot produce a matte. WeVisOne-VL-4B has no video path: its own documentation says video grids are rejected by the pixel decoder.

• Molmo2-4B is single-turn-capable but multi-image native; WeVisOne-VL-4B targets single-turn image perception and explicitly skips chain-of-thought for latency.

That fourth row ends most of the argument. If your pipeline needs an alpha channel — compositing, product cutouts, background replacement, anything where a hair edge matters — Molmo2-4B is not a candidate and never was. If your pipeline needs to follow an object through 384 frames of video, WeVisOne-VL-4B cannot enter the comparison. The rest of this article is about the narrow band where both are plausible.

Both are "4B" and neither is quite that

• Parameters — Molmo2-4B is 4,850,869,200; WeVisOne-VL-4B is 4,830,581,248. Within 0.4% of each other, which is the accident that makes the matchup interesting.

• Architecture — SigLIP 2 so400m plus Qwen3-4B-Instruct-2507 for Molmo2-4B; a Qwen3-VL backbone plus a separate 9.6M-parameter mask decoder for WeVisOne-VL-4B.

• Download — 19.42 GB of float32 safetensors in four shards for Molmo2-4B; roughly 9.7 GB of bfloat16 weights including the mandatory mask_decoder.pt for WeVisOne-VL-4B.

• Context — 36,864 positions for Molmo2-4B; a 262,144-token budget is not the operating constraint for WeVisOne, which evaluates at up to 1,960 visual tokens per image.

• Licence — Apache 2.0 for both, with Molmo2-4B's card adding that its training data is subject to academic and non-commercial research use only.

• Runtime — Transformers with remote code (or native since v5.20.0) plus molmo_utils and decord2 for Molmo2-4B; Tencent's own inference package with a transformers or vLLM backend for WeVisOne-VL-4B.

The download row is the practical surprise. Molmo2-4B is twice the size on disk despite being the same parameter count, because AI2 published it in float32 and Tencent published bfloat16. A 19.42 GB download that you immediately cast down is not the same object as a 9.7 GB download you serve as shipped, and only one of them fits comfortably beside a batch of other models on a single machine.

Where the numbers come from, and where they stop

Neither model has an independent scoreboard, so everything below is vendor-reported. The two vendors chose almost disjoint benchmark sets, which is exactly why the comparison keeps getting made badly.

WeVisOne-VL-4B, from the technical report: Dense200 71.3, LVIS 55.3, RefCOCOg test 81.8, ReasonSeg val cIoU 71.2, PointBench 71.9, Ref-ZOM test cIoU 72.2, TotalText F1 52.0. On matting, the P3M-500-NP box-prompted MAD is 7.3 and the WeRefMat text-prompted MAD is 9.8 — lower is better, and both beat the SAM2-Matting baselines the paper compares against.

Molmo2-4B, from its card: a 62.8 average over 15 academic benchmarks, behind its own 8B sibling at 63.1 and ahead of Qwen3-VL-4B at 58.1, InternVL3.5-4B at 53.4 and GLM-4.1V-9B at 56.9, with Gemini 3 Pro at 70.0 and GPT-5 at 70.6 on the same table.

Not one of those rows is shared. The only benchmark where both appear in the same evaluation at all is counting, and even there the numbers come from different papers with different protocols.

The uncomfortable finding inside WeVisOne's own paper

The most actionable thing in WeVisOne's tables is not the 4B's score. It is that the 4B sometimes loses to its own 2B sibling.

• Better at 4B — Dense200 71.3 vs 61.4, LVIS 55.3 vs 53.3, RefCOCOg test 81.8 vs 78.2, ReasonSeg val cIoU 71.2 vs 60.9, PointBench 71.9 vs 62.9, WeRefMat MAD 9.8 vs 15.8.

• Worse at 4B — P3M-500-NP box matting MAD 7.3 vs 6.6, PPM-100 6.1 vs 5.3, Ref-ZOM test cIoU 72.2 vs 73.4.

Read that second bullet twice. On ordinary-scene box-prompted matting, the extra 2.8B of language model buys nothing and costs a tenth of a MAD point, most likely because the mandatory 9.6M decoder is doing the dense work and the language model is only choosing what to point at. The 4B earns its size on hard, language-conditioned tasks — referring segmentation, dense counting, crowded detection — and coasts or slightly regresses on the easy ones.

So "get the bigger WeVisOne" is not a safe default. Name the task before naming the checkpoint.

False positives, which nobody benchmarks

Both models can be asked for something that is not there. Their published behaviour differs sharply, and this is the row that should worry anyone building a verification loop.

WeVisOne's report gives three rejection rates that are routinely merged into one figure and must not be: RefCOCOg-Rej 67.4, WeRef-Bench Rej 96.4 and PR-Bench Rej 52.6. The gap between 96.4 and 52.6 is the story. On the in-house benchmark the model almost always correctly declines when the queried object is absent; on the public adversarial set it invents an answer about half the time.

Molmo2-4B publishes no rejection rate at all. Its card reports averages on 15 benchmarks and nothing about abstention. If your application relies on the model saying "not present," that is an unmeasured property on one side of this comparison, and it deserves a test set of your own rather than a benchmark citation.

What each one is for

Take WeVisOne-VL-4B when the deliverable is a region or a pixel: open-vocabulary detection, referring segmentation, promptable matting, dense OCR localisation on a single image. Take the 2B sibling instead when the task is easy-scene box matting, because the paper says the 4B does not improve there. Take neither if video is in scope, because the pixel decoder rejects video grids.

Take Molmo2-4B when the deliverable is a location in a stream: point at the object, track it across frames, count instances across time, reason over a set of images. Take it when a coordinate plus a timestamp is the useful artefact and a mask would be overkill. Budget for the float32 download and the cast.

There is a third pattern that shows up in production more often than either pure choice: run both, because the tasks are complementary rather than competing. A detection pass on a still frame and a pointing pass on the video that follows it are two calls with two different output shapes, and the plumbing between them is the expensive part. That plumbing is what a routing layer is for — the routing DSL composes multiple models into one call so the handoff between a matting model and a pointing model is a configuration rather than a service. Neither WeVisOne-VL-4B nor Molmo2-4B is in the OrcaRouter catalogue; both are weights you host, and the honest framing is that routing sits above them.

The one-line answer

If you need pixels, this is not a comparison — WeVisOne-VL-4B is the only one that produces them, and you should check whether its 2B sibling beats it on your specific matting task before paying for the 4B. If you need points over time, it is not a comparison either — Molmo2-4B is the only one with a video path. The matchup only becomes real when the task is "find the object in this still image," and there the deciding factor is not accuracy but abstention: WeVisOne has published rejection numbers, Molmo2-4B has none.