LFM3-VL-2B vs WeVisOne-VL-2B: Three Days Apart, Opposite Bets

LFM3-VL-2B appeared on Hugging Face on 19 October 2026. WeVisOne-VL-2B appeared on 22 October. Two models, both around two billion parameters, both open-weight, both from well-known labs, published within 72 hours of each other. You would expect them to be near-substitutes. They are closer to opposite bets on what "vision" means: one answers questions about what it sees, the other returns the precise shape of what it sees.

That distinction is easy to miss on a spec sheet, because both cards list boxes and both cards list OCR. The difference is in the output format and the training objective, and it decides whether you can drop either model into a pipeline without a parsing layer. It also decides which one has a reason to exist after the general-purpose models get better.

Two definitions of seeing

LFM3-VL-2B is Liquid AI's generalist. It takes text, images and video at 2 fps, outputs text, supports step-by-step thinking, carries a 128K context and covers 16 languages. The architecture is a dense 1.92B model — a 1.73B language backbone, a 164M in-house vision encoder and a 25M projector — with BF16, GGUF, MLX 4-bit and ONNX builds published. Liquid's family post frames it as a model that can "watch, reason, and understand the physical world," and the video path is genuinely new for the family.

WeVisOne-VL-2B is Tencent's WeChat Vision model. It is built on a Qwen3-VL backbone at roughly 2.4B parameters under Apache 2.0, and its purpose is unified perception: open-vocabulary detection, referring localisation, counting, pointing, OCR localisation, referring segmentation and promptable alpha matting. It returns normalised coordinates through dedicated tokens, plus masks through a separate 9.6M-parameter pixel decoder that must be loaded alongside the language model.

One model is a reader. The other is a measuring instrument. The overlap in their benchmark tables is real, but it is the overlap of two different products measuring the same scene.

The output format is the product

WeVisOne-VL-2B encodes coordinates as tokens from <0> to <1000>, marks each instance with an <OBJ> token and returns None when the requested target is absent. That last detail is the one practitioners notice: the card reports a rejection rate of 50.2 on RefCOCOg, against roughly 0.5 for Rex-Omni and LocateAnything. It is trained to say "not here" rather than hallucinate a box.

The pixel decoder is not optional. Segmentation and alpha matting require mask_decoder.pt, a 9.6M-parameter module triggered by the object token. If you load only the language model, you get coordinates but not masks. The GitHub repository ships the inference package that wires the two together, and the model is single-turn and image-only by design — the pixel decoder rejects video grids.

LFM3-VL-2B has no equivalent contract. It will describe a region, count objects, or reason about a scene in prose, and its grounding row (RefCOCO-avg 90.5) suggests it is competent at localization. But the output is text. For a pipeline that needs a mask, the difference between 90.5 and a parseable polygon is the difference between a demo and a product.

Grounding numbers you cannot subtract

The two cards both report RefCOCO-family results, and they are not the same measurement. LFM3-VL-2B reports RefCOCO-avg 90.5, which averages the referring-expression splits. WeVisOne-VL-2B reports RefCOCOg 77.1 mean F1 for referring detection and RefCOCO testA 82.9 cIoU for referring segmentation. RefCOCOg is a different split with longer, more conversational expressions; cIoU is a different metric from F1.

Subtracting 77.1 from 90.5 produces a number that means nothing. The honest reading is that both models are strong at referring localization on their own harnesses, that neither harness has been independently reproduced, and that the metric definitions differ enough that the ranking is unresolved. The same caution applies to OCR: LFM3-VL-2B reports OCRBench v1 86.3, while WeVisOne-VL-2B reports OCR HierText 30.5, which is a different benchmark on a harder dataset.

Where the comparison is clean, it favours the specialist on its own turf: WeVisOne-VL-2B reports COCO detection F1 55.2, LVIS 53.3 and Dense200 61.4, against a model that does not publish a detection F1 at all. That is not a win by default. It is a reminder that the generalist was not trained to be scored that way.

The matte is the moat

Promptable alpha matting is the feature neither LFM3-VL-2B nor most of its size class offers. WeVisOne-VL-2B reports a mean absolute difference of 6.6 on P3M-500-NP for soft-edged mattes — the semi-transparent boundary around hair, glass and fur that a binary segmentation mask turns into a hard cut. The card is candid about the limits: fine alpha boundaries degrade under occlusion, low resolution and transparency. But for product cut-outs, compositing and background replacement, a matte is the output the pipeline actually needs.

This is the strongest argument for the model's existence. A 2B generalist can describe an image; it cannot hand you a soft alpha channel. Tencent built a small model around a pixel decoder because that output is expensive to get from a large general-purpose model, and the 4B sibling exists for teams that need more accuracy at the same task.

Video and thinking are the other moat

LFM3-VL-2B's differentiator runs the other way. It accepts video at 2 fps and reports Video-MME 62.8 without subtitles, MVBench 69.4 and MMMB 85.2. WeVisOne-VL-2B is single-turn and image-only; its pixel decoder rejects video grids. If your input is a clip, the comparison is over before the benchmark table starts.

The thinking mode adds a second gap. LFM3-VL-2B reports MathVista 84.2 with thinking against 68.5 without, and MMMU 55.7 against 48.6. WeVisOne-VL-2B has no chain-of-thought by design, for efficiency. That is a legitimate engineering choice for a perception component and a hard limit for a model you want to reason about a chart.

Memory, licence and the price of admission

• Parameters — LFM3-VL-2B 1.92B dense vs WeVisOne-VL-2B roughly 2.4B, plus a 9.6M pixel decoder.

• Memory — about 3.84 GB BF16 by arithmetic for LFM3-VL-2B, with a 4-bit MLX build; roughly 9.1 GB of weights in F32 and an estimated 4.9 GB in BF16 for WeVisOne-VL-2B, per third-party deployment notes rather than the card.

• Input — text, image and video at 2 fps vs image and text only, single turn.

• Output — prose, optionally with reasoning vs text, normalised coordinates, masks and alpha mattes.

• Context — 128K vs not stated as a document-scale window; the pixel decoder is the constraint.

• Licence — LFM Open License v1.0, commercial use below $10M annual revenue vs Apache 2.0 at any size.

• Published — repository 19 October 2026, family announcement 27 October vs repository 22 October 2026.

The licence row is the reverse of the usual story. Tencent's model is the permissively licensed one; Liquid's is the one with a revenue ceiling. For a company building a commercial perception product, Apache 2.0 removes a diligence item that the LFM licence creates. That does not make the models interchangeable, but it does mean the smaller, more general model carries the larger legal constraint.

Neither model has a hosted price

Both cards publish weights and neither publishes a per-token API rate. Hugging Face lists no inference provider for LFM3-VL-2B; WeVisOne-VL-2B's card likewise has no hosted endpoint, though community ports exist for LiteRT, Core AI, GGUF and Android. This is the current shape of the 2B vision tier: the weights are free, the serving is yours, and the real cost is the GPU and the integration work.

If you would rather rent that tier than own it, OrcaRouter routes hosted vision models — Qwen3-VL-8B among them — through one API with provider list price passed through at 0% markup, and model fusion if you want a perception model and a reasoning model to answer as a panel. We do not serve either checkpoint in this comparison, and nothing here implies we do. The relevant point is that renting a slightly larger hosted model is a legitimate third option when neither open-weight model ships with an endpoint.

How to choose

• Take WeVisOne-VL-2B if the output is geometry: boxes, masks, alpha mattes, counts, or a "not present" signal. Take it if Apache 2.0 is non-negotiable, or if you are building a cut-out, compositing or robotics-perception pipeline.

• Take LFM3-VL-2B if the input includes video, if you need reasoning across a chart or a form, or if you want one small model to answer general questions rather than measure shapes.

• Take both only if you are prepared to run two pipelines. They share a parameter class and almost nothing else, and the integration cost of pretending otherwise is higher than the cost of the second model.

The three-day gap between their repositories is a coincidence. The divergence in what they return is not. Two labs looked at the same 2B budget and spent it on different outputs, and the right question is not which one is better — it is which output your next pipeline step can actually consume.