LFM3-VL-2B vs WeVisOne-VL-4B: What 2.5× the Parameters Actually Buys

Tencent's own benchmark table argues against the obvious purchase. WeVisOne-VL-4B, the larger of the two perception models the WeChat Vision team published on 22 October 2026, is worse at box-prompted alpha matting than its own 2B sibling: 7.3 mean absolute difference on P3M-500-NP against the 2B's 6.6, where lower is better. The model most buyers will actually weigh it against, though, is not its sibling but LFM3-VL-2B — Liquid AI's 1.92B on-device vision model, whose weights appeared on 19 October and which was announced with the rest of the LFM3 family on 27 October.

Set those two side by side and the interesting question is not which one is smarter. It is what two and a half times the parameters buy you, and what they cost. The short answer, from the vendors' own tables: they buy dense detection, referring accuracy, and a much better rate of refusing to answer when the object is not there. They do not buy a generalist, they do not buy video, and they do not buy a model you can put on a phone. Everything below comes from the two published tables with the seams left visible — no independent harness has reproduced either model's numbers.

What each one actually is

LFM3-VL-2B is 1.92B dense parameters: a 1.73B language backbone, a 164M in-house vision encoder and a 25M projector. The backbone is Liquid's tri-hybrid stack — 24 layers split into 13 gated short convolutions, 5 sliding-window attention layers at a 256-token window, and 6 global attention layers. It takes text, images and video at native resolution, sampling video at 2 frames per second, holds a 128K-token context, covers 16 languages, and has an optional thinking mode that produces a reasoning pass before the answer. Its output is prose.

WeVisOne-VL-4B is built on a Qwen3-VL backbone and named 4B, though the Hugging Face metadata rounds it to 5B and third-party write-ups put the actual count near 4.83B. It does not answer in prose so much as emit geometry: boxes and points as normalized coordinate tokens from 0 to 1000, an OBJ marker (token id 152678) after each predicted box, and the literal string None when the target is absent. Masks and alpha mattes require a second artefact, mask_decoder.pt, a 9.6M-parameter pixel decoder that takes the hidden state of each OBJ token and the predicted box and returns full-resolution alpha at stride 1. It is single-turn and image-only, and it generates structured output directly, with no chain-of-thought.

The contrast in one pass:

• Size — LFM3-VL-2B 1.92B dense vs WeVisOne-VL-4B roughly 4.83B, plus a 9.6M decoder that is mandatory for masks

• Input — text, image and video at 2 fps vs text and a single image

• Output — prose and a thinking pass vs coordinate tokens, boxes, masks, mattes, or an explicit None

• Context — 128K tokens vs no inference limit published on the card; the paper describes training at 4,096 and 8,192 tokens

• Language coverage — 16 languages stated vs none stated

• Licence — LFM Open License v1.0, free for commercial use below $10M annual revenue vs Apache 2.0 for Tencent-authored code

• Runtime — GGUF/llama.cpp, MLX 4-bit, ONNX and BF16 vs BF16 through Transformers, vLLM or SGLang

The upgrade is uneven, and the paper shows where

WeVisOne-VL-2B and WeVisOne-VL-4B are the same architecture at two scales, trained on the same roughly 100M images through the same three-stage curriculum, and evaluated on the same table. That makes the sibling comparison the cleanest evidence available about what the extra parameters do — and it does not move in one direction.

Where the 4B clearly wins, on Tencent's numbers:

• Dense200 detection — 71.3 mean F1 vs 61.4, the largest single gain

• LVIS — 55.3 vs 53.3, a modest 2-point improvement

• RefCOCOg referring detection — 81.8 test vs 78.2

• RefCOCO referring segmentation — 84.5 cIoU on testA vs 82.9

• ReasonSeg — 71.2 cIoU on val vs 60.9, a 10-point jump on reasoning segmentation

• PointBench pointing — 71.9 vs 62.9

• WeRefMat referring matting — 9.8 mean absolute difference on the referring split vs 15.8, a 38% error reduction

Where it does not:

• P3M-500-NP box matting — 7.3 vs the 2B's 6.6, worse

• PPM-100 box matting — 6.1 vs 5.3, worse

• Ref-ZOM cIoU — 72.2 test vs 73.4, the 2B ahead again

The pattern is legible even if the cause is not published: the 4B pulls ahead on tasks that are hard and language-conditioned — referring segmentation, reasoning segmentation, referring matting on real scenes — and gives nothing back on the easier box-prompted matting sets, where both models are already close to the ceiling and the 9.6M decoder may be doing most of the work. Two of three box-prompted matting benchmarks move the wrong way. If alpha matting on a supplied box is your only task, the 4B is not an upgrade; it is a more expensive way to get the same answer, slightly worse.

Absent objects: better, still not solved

The most useful column in the paper is the one almost no vision-model card publishes. RefCOCOg-Rej is a variant in which every expression is modified so that no matching object exists in the image. A model that cannot say "no" will invent a box, and every downstream crop, count and mask inherits that fabrication.

WeVisOne-VL-4B rejects correctly 67.4% of the time, against 50.2% for the 2B. That is a real and large improvement — a 17-point gain that changes a pipeline's failure mode from coin-flip to two-in-three. It also means the 4B still returns a confident box for roughly one absent-object query in three. On Tencent's own in-house WeRef-Bench, the rejection rate reads 96.4%, but that benchmark is 2,880 English and Chinese queries the lab built itself, so it measures a friendlier distribution than the public one. The honest summary is that the model has a usable abstention behaviour and has not solved the problem; if your application cannot tolerate a hallucinated region, this needs a threshold or a second check on top, whichever model you pick.

The number that looks comparable and is not

It is tempting to put LFM3-VL-2B's 90.5 RefCOCO-avg next to WeVisOne-VL-4B's 81.8 RefCOCOg and announce an 8.7-point win for the smaller model. Do not. Those are different splits and different metrics: Liquid reports an average across the RefCOCO family, Tencent reports RefCOCOg test F1 for referring detection. Subtracting them produces a number with no referent.

The same trap sits in OCR. LFM3-VL-2B scores 86.3 on OCRBench v1, a composite of text recognition, spotting and reasoning; WeVisOne-VL-4B scores 52.0 F1 mean on TotalText, a scene-text localisation benchmark. One is a broad exam, the other is a dense-prediction task. They are not the same skill measured twice.

So the two vendor tables do not intersect on a single like-for-like number. What can be compared honestly is capabilities and cost, which is why the rest of this comparison is about fit rather than rank. Anyone publishing a winner from these two tables is inventing one.

Memory is the real price

Neither model has a published per-token price on 28 October 2026. Liquid's card links API and Playground access through its console, but no rate card was published for LFM3-VL-2B; the third-party trackers that list Liquid text-model rates do not cover the vision model. Tencent has no hosted endpoint at all. So the comparison is a self-hosting comparison, and the bill is denominated in memory.

• LFM3-VL-2B — about 3.84 GB at BF16 by arithmetic from the parameter count, with 4-bit MLX, GGUF and ONNX builds published alongside it

• WeVisOne-VL-4B — roughly 9.7 GB at BF16 per third-party estimates, about 19 GB in F32, plus the required mask_decoder.pt

That 2.5× gap is not just a bigger GPU. It is a different class of device. The LFM3-VL-2B card is explicit that the model is built for on-device work — questions about video, documents, charts and app screens, finding objects, spatial reasoning for robots — and the MLX 4-bit and GGUF builds are how that promise is kept: a laptop, a phone, a robot chassis. WeVisOne-VL-4B's documented paths are Transformers, vLLM and SGLang on BF16, with no official quantised build and no on-device runtime. It wants a server GPU.

Framework support is worth checking against your own path rather than the table. Video at 2 fps is a model capability in LFM3-VL-2B, but whether a given runtime accepts a video grid is a separate question, and the model card, the ports and the upstream PRs have not always agreed on that. Test the exact combination you intend to ship.

OrcaRouter does not host either model. That is verified against the catalogue on 28 October 2026, not assumed — neither Liquid's LFM3 line nor Tencent's WeVisOne appears in the model list — so nothing here should be read as a route to either. What the OrcaRouter model catalogue does carry is Qwen3-VL-8B, in instruct and thinking variants, which is the pragmatic option if your actual requirement is a hosted vision model with a published price today rather than a self-hosted checkpoint. One key reaches all of it at provider list price with no markup, and if you are prototyping against an unproven open-weight model, running it through a router with failover beats wiring a production path to a checkpoint that has not yet had an independent evaluation.

Which one to pick

• Pick WeVisOne-VL-4B when the deliverable is geometry — masks, alpha mattes, dense boxes, counts, pointing — on still images, when the queries are language-conditioned rather than box-prompted, and when you have a GPU to spare

• Pick WeVisOne-VL-2B instead of the 4B when your task is box-prompted matting on ordinary scenes; on the published numbers the smaller model is better at it and costs less than half the memory

• Pick LFM3-VL-2B when the input includes video, when the document is long, when the answer needs to be a sentence rather than a polygon, or when the device is not a server

• Pick neither if you need a hosted endpoint with a published per-token price this week — neither vendor offers one, and no amount of benchmarking closes that gap

• Pick both only if you accept two output schemas and two integration paths; the shared "about 2B to 5B" parameter band disguises two different products

What would change this

Three things. An independent harness that runs both models on the same images with the same prompts — until then, everything above is a vendor table read carefully, which is better than a vendor table read carelessly but is not evidence of quality. A quantised WeVisOne build, or an on-device runtime, which would move the memory argument from decisive to negotiable. And a published per-token price from either side, which would replace arithmetic about gigabytes with a number someone can budget against.

The least likely of the three is the one that would matter most for this specific pairing: video support in WeVisOne's pixel decoder. Right now the 2B generalist takes a video and the 4B instrument cannot, and no parameter count fixes a modality that was never trained.