WeVisOne-VL-4B vs LFM2.5-VL-3B: A Matting Specialist Against an Edge Speedster

Liquid AI publishes a speed number for LFM2.5-VL-3B and Tencent publishes none for WeVisOne-VL-4B. That asymmetry, more than any benchmark row, is the matchup. LFM2.5-VL-3B is a 3.1B-parameter edge model tuned to answer in one pass: 228 tokens per second on an Apple M5 Max, 20 tokens per second on a Galaxy S26 Ultra, under 3.3 GB of memory, sixteen languages. WeVisOne-VL-4B is a 4.83B-parameter perception model that will spend up to 1,960 visual tokens and a 9.6M-parameter decoder to hand you a full-resolution alpha matte. One is built to be fast enough to sit inside a phone UI; the other is built to output pixels. They overlap on the word "vision" and almost nowhere else.

That makes this a comparison worth doing carefully, because the obvious version of it — put the benchmark tables side by side, declare a winner — would be wrong in a specific and instructive way.

The benchmark tables do not talk to each other

Both models publish referring-expression numbers and both numbers look comparable. They are not. LFM2.5-VL-3B reports RefCOCO-avg P@1 of 87.9. WeVisOne-VL-4B reports RefCOCOg test F1 mean of 81.8. Different dataset split, different metric, different failure model: P@1 asks whether the top-ranked box is right, F1 mean averages precision and recall across IoU thresholds from 0.5 to 0.95. A model can win one and lose the other by a wide margin without either result being surprising.

The same trap sits in every other row. Liquid's 80.7 on ScreenSpot-v2 measures UI element grounding; Tencent has no ScreenSpot number. Tencent's 96.4% rejection rate on WeRef-Bench measures whether the model refuses to answer when the object is not there; Liquid publishes no rejection metric at all. Neither vendor evaluated the other's model, so no row in either table is a head-to-head.

What can be said honestly is directional. LFM2.5-VL-3B is a strong generalist at its size — 69.4 average across 28 vision benchmarks on Liquid's own count, within 0.7 points of Qwen3.5-4B — and its ScreenSpot-v2 jump from near-zero in the previous generation to 80.7 is the single largest improvement in its table. WeVisOne-VL-4B is not competing on that axis. Its strongest claims are on dense small-object detection, rejection, and pixel-level output, none of which LFM2.5-VL-3B attempts.

What each model physically is

• Parameters — WeVisOne-VL-4B 4.83B dense (F32 checkpoint) vs LFM2.5-VL-3B 3.12B dense (BF16)

• Vision path — a Qwen3-VL backbone plus a 9.6M pixel decoder vs an LFM2.5-2.6B hybrid convolution-attention text base plus a SigLIP2 NaFlex 400M encoder

• Memory — roughly 19 GB on disk for the F32 4B checkpoint vs under 3.3 GB total footprint for the 3B

• Context — no published figure for WeVisOne-VL-4B vs 32,768 tokens for LFM2.5-VL-3B

• Languages — not stated for WeVisOne-VL-4B vs 16 for LFM2.5-VL-3B, with a 128K vocabulary built for non-Latin scripts

• Output types — boxes, points, masks and alpha mattes vs boxes and text only

• License — Apache 2.0 for Tencent-authored code vs the LFM Open License v1.0

• Speed — unpublished vs 228 tok/s on an M5 Max, 116 tok/s on a Ryzen AI Max+ 395, 20 tok/s on a Galaxy S26 Ultra

The capability gap that actually decides it

LFM2.5-VL-3B can tell you where a person is in an image. WeVisOne-VL-4B can tell you where a person is, return a binary mask for that instance, and return a continuous alpha matte with soft edges — hair, fur, sheer fabric, motion blur — at full resolution. That is a categorical difference, not a quality difference. If your product needs to composite a subject onto a new background, cut out a product photo, or drive a video call's background replacement, LFM2.5-VL-3B has nothing to offer you and no amount of prompt engineering changes that.

Run the comparison the other way and the same thing happens. If your product needs to find a button on a phone screen in 40 milliseconds, WeVisOne-VL-4B is the wrong shape entirely: it is a 4.83B model with no published latency figure, no quantized edge builds, and a decoder that assumes one image per turn. Liquid ships GGUF, MLX, ONNX and native builds, plus a 32K context and tool-calling benchmarks. Tencent ships a research inference package and vLLM/SGLang serving.

Rejection is the underrated column

One capability in Tencent's table deserves attention even if you never touch matting. On WeRef-Bench, WeVisOne-VL-4B correctly rejects 96.4% of queries for objects that are not in the image, against 73.0% for the best baseline the authors list; on PR-Bench the rejection rate is 52.6% against 10.8% for Qwen3-VL-4B. The model returns None rather than inventing a box. A detector that hallucinates is worse than no detector, because the failure is silent and downstream code trusts it.

LFM2.5-VL-3B's documentation does not report a rejection figure, so there is nothing to compare against — which is itself the point. Absence of evidence is not a failure, but if you are building an agent that decides whether to click something, the presence of a measured rejection rate is a genuine reason to look at the Tencent model first.

Licensing is the quiet differentiator

This is where the two diverge in a way that matters to anyone shipping commercially. WeVisOne-VL-4B's weights are Apache 2.0 for Tencent-authored code, with third-party components keeping their own terms. LFM2.5-VL-3B ships under the LFM Open License v1.0, which is free for commercial use below a revenue threshold and requires a commercial agreement above it. If you are a small team, the difference is academic. If you are not, one of these is a legal review and the other is a line in a dependency file.

Neither license grants you a hosted service. WeVisOne-VL-4B has no API at all; LFM2.5-VL-3B is a weights release, and any third-party hosting is a separate arrangement. Stating that plainly matters more than it used to, because a model with no endpoint is a commitment to own the inference stack.

Where OrcaRouter fits, and where it does not

Neither of these models is in OrcaRouter's catalogue today, so nothing here is a route to calling them. What the platform does offer is the surrounding decision. Most teams evaluating a 3B edge VLM are not replacing one model with another — they are adding a second one beside the general-purpose model already in production, and the operational cost of a second vendor contract, a second key and a second failure mode usually kills the experiment before the model does.

Routing both intents through one endpoint, with more than 200 models behind one key at 0% markup over provider list price, means the perception model can be a routing decision rather than an integration project. If the edge model is unavailable, automatic failover sends the request elsewhere instead of returning a 503. That is the part OrcaRouter actually solves here; the weights and the GPU are still yours.

Which one to pick

Pick LFM2.5-VL-3B if the job is latency-bound and text-shaped: screen understanding, UI agents, document OCR with layout, on-device translation, tool calling. It is faster than almost anything at its size, it runs in a phone's memory budget, and Liquid has published enough numbers for you to sanity-check the claims against your own workload.

Pick WeVisOne-VL-4B if the job ends in pixels. Segmentation, matting, dense detection of small objects, or any pipeline where "the model said no" needs to be a reliable answer. Accept that you are an early adopter: no independent benchmark run exists, no hosted endpoint exists, the fine-tuning code is still on the TODO list, and the paper is two days old.

The one thing not to do is pick between them on a single benchmark score. They were not measured against each other, on the same data, by anyone.