WeVisOne-VL-2B vs LFM2.5-VL-3B: A Mask Maker Against a Screen Reader

Give both models the same photograph and the same sentence — "the dog on the left" — and two different things come back. LFM2.5-VL-3B answers with a location and, if you asked, a description: a box, a point, or a short sentence about what it found. WeVisOne-VL-2B answers with a box too, and then a small decoder turns that box into a soft-edged alpha matte you could composite onto a new background without a halo around the fur. One model was built to read an interface and reply. The other was built to hand you pixels.

That difference is the entire comparison, and it survives every benchmark table either vendor has published. It also explains why the two models are rarely evaluated against each other: Liquid AI's card does not mention WeVisOne, Tencent's paper does not mention Liquid, and no third party has run them side by side. What follows is what each release actually put on the record, which of their numbers can be put next to each other, and which cannot.

Two releases, two very different amounts of evidence

LFM2.5-VL-3B was published by Liquid AI on 11 August 2026 — weights first, announcement the next day — and it arrived with a numeric benchmark table, a named baseline for every row, and a speed section measured on named hardware. It is a 3.12-billion-parameter dense model: an LFM2.5-2.6B language backbone paired with a SigLIP2 NaFlex 400M vision encoder, a 32,768-token context, a 128,000-token vocabulary and sixteen named languages. Its licence is Liquid's own LFM Open License v1.0, which is free for commercial use below a revenue threshold rather than unconditionally free.

WeVisOne-VL-2B was published by Tencent's WeChat Vision team on 22 October 2026, and its model card contains no benchmark table at all — no scores, no context length, no throughput figures, no hardware requirements. The numbers exist, but they are in the accompanying paper, which reports seven task tables across what the authors describe as more than thirty benchmarks. So the two releases are not just different models; they are different kinds of document. Liquid published a product spec. Tencent published a research result and left the spec sheet mostly blank.

That asymmetry matters when you read a comparison like this one. Liquid's figures were assembled to be read against its own baselines. Tencent's were assembled to win an academic table. Neither vendor chose its numbers with the other model in mind, which is precisely why the numbers do not line up.

The number that looks comparable and isn't

Both models publish a RefCOCO score, and putting them side by side produces a clean-looking headline: LFM2.5-VL-3B at 87.9 against WeVisOne-VL-2B at 79.7. That comparison is meaningless, and it is worth walking through why, because the same mistake is being made in spreadsheets right now.

• Liquid reports RefCOCO precision@1 averaged across splits. That is a detection statistic: did the top-ranked predicted box overlap the ground-truth box enough to count as correct.

• Tencent's 79.7 is on a segmentation table, and the paper states plainly that the RefCOCO-family figures there are cumulative IoU — total intersection over total union across the whole evaluation set.

• Tencent's referring detection table does not report RefCOCO at all. It reports RefCOCOg, where the 2B scores 77.1 mean F1.

So the 87.9 and the 79.7 measure three different things across two different tasks. A box that barely overlaps a target can score well on precision@1 and poorly on cIoU; a mask that covers a large object well can score highly on cIoU while its bounding box is sloppy. There is no arithmetic that reconciles them.

The same trap sits in OCR. Liquid publishes OCRBench v1 at 84.2 and OCRBench v2 English at 47.5 — transcription benchmarks. Tencent publishes OCR as localization F1 at a 0.5 IoU threshold: 62.1 on SROIE, 42.6 on ICDAR2015, 42.5 on TotalText, 30.5 on HierText. Those measure whether the model found and boxed the text, not whether it read it correctly. Quoting "84.2 versus 62.1" would be comparing a reading test to a pointing test.

What is actually a fair comparison

Strip out the scores and the two models line up along dimensions that do not need a harness:

• Size — about 3.12B dense parameters for LFM2.5-VL-3B vs about 2B for WeVisOne-VL-2B, plus a 9.5M-parameter decoder that must be downloaded separately and is required for dense outputs.

• Base — Liquid's own LFM2.5-2.6B hybrid backbone vs Qwen3-VL.

• Context — 32,768 tokens published on the card vs no published context length at all. The WeVisOne paper's training stages ran at 4,096 and 8,192 tokens, and inference caps each image at 1,960 visual tokens, but none of that is a deployment window.

• Output types — boxes, points and text vs boxes, points, binary masks and continuous alpha mattes.

• Reasoning — LFM2.5-VL-3B is deliberately non-reasoning, answering directly to keep latency low; WeVisOne is also non-reasoning, but for a different reason, generating structured output without chain-of-thought for inference efficiency. Neither model "thinks" before it answers, and neither vendor pretends otherwise.

• Tool calling — supported and benchmarked on LFM (ToolSandbox 59.5, BFCL v4 32.5) vs not a stated capability on WeVisOne.

• Languages — sixteen named on the LFM card vs not stated on the WeVisOne card.

• Licence — LFM Open License v1.0, with a revenue threshold, vs Apache 2.0 for Tencent-authored code.

• Quantized builds — GGUF, ONNX and MLX exports offered by Liquid vs none announced by Tencent.

• Independent evaluation — neither model has an entry on Artificial Analysis as of this writing. Every number in this article, from both vendors, is vendor-reported.

The deployment gap is wider than the parameter gap

LFM2.5-VL-3B was engineered to run on a phone and the card proves it with numbers: under 3.3GB of memory, 20 tokens per second on a Galaxy S26 Ultra, 228 tokens per second on an Apple M5 Max, 116 on an AMD Ryzen AI Max+ 395, and about 11,000 output tokens per second at high concurrency on a single H100. It ships in formats that consumer runtimes can actually load.

WeVisOne-VL-2B publishes none of that. What it does publish implies a different bill. The decoder's final stage produces a stride-1 full-resolution alpha matte, which means the dense output is the size of the input image rather than a fixed-size vector — a cost that scales with resolution, not with parameter count. For a 2B model on a modern GPU that is manageable. For a phone, it is not obviously manageable at all, and Tencent has not claimed it is.

The practical consequence is that these two models do not compete for the same deployment slot. One is a component you could ship inside an app. The other is a component you would run on a server, or on a workstation, next to whatever else needs masking.

Pick by output type, not by score

If the job is reading a screen — parsing a checkout flow, finding the button labelled "Continue", extracting a table from a photographed document — LFM2.5-VL-3B is the obvious candidate. It has ScreenSpot-v2 at 80.7, DocVQA at 91.1, ChartQA at 81.3, and a ToolSandbox score that suggests it can act on what it sees rather than merely describe it. It also has a 28-benchmark average of 69.4 that Liquid publishes against named siblings, which at least tells you what the vendor thinks its own neighbourhood looks like.

If the job is isolating an object — a product cutout, a person against a busy background, a foreground with flyaway hair or a transparent edge — LFM2.5-VL-3B does not produce that output and no amount of prompting will make it. WeVisOne-VL-2B does, and the margin on the matting tables is large: 6.6 mean absolute difference against 15.4 for SAM2-Matting on P3M-500-NP, 15.8 against 23.0 for a Qwen3-VL-8B plus SAM2 pipeline on the language-prompted WeRefMat split.

There is one more case where WeVisOne has a claim worth noting: absence. Tencent reports a 50.2 rejection rate on RefCOCOg for queries whose target is not in the image, against 0.5 and 0.6 for two specialised grounding models on the same table. If your pipeline runs thousands of crops and most of them contain nothing you care about, a model that reliably says "not there" saves you a downstream classifier. LFM2.5-VL-3B's card does not report a comparable rejection figure, so there is nothing to put beside it — a gap in the evidence, not a loss.

None of this is a reason to pick one and retire the other, and it is worth being honest about where a router fits. OrcaRouter does not serve either model; neither is on our catalogue, and neither is hosted anywhere we can verify for WeVisOne in particular. What we do offer is the surrounding stack: if your pipeline uses a hosted vision model for the reading half and a self-hosted model for the masking half, the hosted calls come through one API key at provider list price with no markup, failover moves them to another provider when one degrades, and the routing DSL lets you put both halves behind a single endpoint so your application never learns which one answered.

What would actually settle it

One independent harness, run by someone who is not either vendor, on the same images, reporting both a detection statistic and a segmentation statistic for both models. That does not exist. Until it does, the defensible position is the boring one: these models answer different questions, their published numbers are measured with different instruments, and the choice between them is decided by what your downstream code expects to receive — a sentence, or a mask.

If you only take one thing from this comparison, take the shape of the evidence. Liquid AI gave you a table you can falsify. Tencent gave you a paper you can read and a card that tells you, candidly, what the model will not do. Neither gave you a number that can be compared to the other, and any article that prints 87.9 next to 79.7 without that caveat is selling you a ranking that does not exist.