LFM3-VL-2B vs UI-Venus 2.9B: The 2.9B That Is Actually a 9B

There is no model called UI-Venus 2.9B. The checkpoint at inclusionAI/UI-Venus-2-9B is UI-Venus-2-9B — version two of Ant Group's UI-Venus agent, at 9 billion parameters, built on Qwen3.5-9B. The directory name reads like a decimal and is not one. Against LFM3-VL-2B at 1.92 billion parameters, that makes this a 2B-versus-9B comparison wearing a 2B-versus-2B label.

The mistake matters because it changes the question. If both models were roughly 2B, you would compare benchmark rows and pick the better one. At 9B versus 2B, the smaller model is not competing on the same hardware, and the larger one is not a general vision model at all. UI-Venus-2-9B is a GUI agent trained to operate phones, browsers and desktops from screenshots. LFM3-VL-2B is a general vision-language model that happens to include a GUI category among its 62 benchmarks. The overlap is narrower than the naming suggests.

How the name got mangled

Ant Group's naming convention is family-version-size. UI-Venus-2-9B parses as UI-Venus, generation 2, 9B parameters. A catalogue or a radar that splits on hyphens and looks for a decimal reads "2-9" as "2.9", which is how a 9B model ends up filed beside 2B models. The same convention produces UI-Venus-2-27B, the larger sibling, and both were published together in late August 2026.

This is not a cosmetic error. Parameter count is the first filter in every deployment decision, and a reader who arrives expecting a 2.9B model will be surprised by an 18.8 GB BF16 checkpoint that does not fit the device they had in mind. The repository's own metadata is unambiguous: Qwen3.5-9B architecture, BF16, image-text-to-text.

Two jobs, not two sizes

LFM3-VL-2B takes text, images and video at 2 fps, produces text, supports a thinking mode, and carries a 128K context across 16 languages. It is a generalist: documents, charts, grounding, embodied reasoning, GUI understanding and video all appear as categories on its card. Liquid AI published it on Hugging Face on 19 October 2026 and announced the family on 27 October, with no API price and no inference provider listed.

UI-Venus-2-9B takes screenshots and a task description and returns the next action in a closed observe–reason–act loop. Its training is three-stage: multimodal mid-training on simulated trajectories across 170-plus mobile apps and 4,000-plus web domains, offline step-level reinforcement learning across grounding, CAPTCHA, mobile, web and computer tasks, then multi-teacher on-policy distillation into one policy. It runs on vLLM with an OpenAI-compatible endpoint and a Qwen3 reasoning parser. That is an agent runtime, not a captioning model.

The practical consequence: you cannot swap them. LFM3-VL-2B will describe a screenshot and answer questions about it. UI-Venus-2-9B will decide where to tap next, and it expects the surrounding harness — action parsers, prompts, examples — from the project's GitHub repository to do anything useful.

The one benchmark that lines up

Both models report ScreenSpot-Pro, which is the rare case where the comparison is legitimate. LFM3-VL-2B scores 55.5 with thinking and 49.3 without. UI-Venus-2-9B scores 73.0. That is a 17.5-point gap in favour of the model that is almost five times larger, and it is the single clearest number in this matchup.

Do not extend it to the rest of the GUI story. UI-Venus-2-9B also reports AndroidWorld 80.2, OSWorld-Verified 70.8, WebVoyager 90.8, Online-Mind2Web 74.0 and VenusBench-GD 77.1. LFM3-VL-2B reports a GUI category average of 83.1 across a different set of tasks, and averaging a category is not the same as scoring a single benchmark. The categories are not comparable and should not be subtracted.

One number on the UI-Venus card is worth flagging because it cuts against the headline: on OSWorld 2.0 the model scores 0.0 on the binary metric and 7.5 on the partial metric. Whatever the harness issue is, a 9B agent that leads on OSWorld-Verified and scores near zero on the successor benchmark is a model with a boundary, and the card reports it honestly.

Context windows that measure different things

UI-Venus-2-9B reports up to 256K tokens of context, and the useful part is what that context holds: a history of screenshots, so the agent can remember what the screen looked like four steps ago. LFM3-VL-2B reports 128K, and its card does not state the image-token budget or a maximum video length. Neither number tells you how many screenshots you can keep in a loop before the model loses the first one. Both require measurement on your own resolution and step count.

The difference in kind still matters. A long screenshot history is a memory requirement for an agent that runs for minutes. A 128K context on a general VLM is a document or video requirement. The numbers look comparable and answer different questions.

Deployment: 4 GB against 19 GB

LFM3-VL-2B is 1.92B parameters, about 3.84 GB of weights in BF16 by arithmetic, with GGUF, MLX 4-bit and ONNX builds already published. UI-Venus-2-9B is roughly 18.8 GB in BF16 and is served through vLLM; there is a community GGUF, but the vendor's serving path assumes a GPU with room for the full checkpoint. These do not compete for the same slot. One is an edge candidate; the other is a server-side agent.

That difference, not the benchmark gap, is why the pairing is interesting. A team that wants GUI understanding on a device has exactly one option here. A team that wants a GUI agent with near-state-of-the-art scores has the other, and needs a GPU to run it.

The licence question nobody has answered

LFM3-VL-2B uses the LFM Open License v1.0: commercial use is licensed only while the licensee stays below $10 million in annual revenue. That is restrictive but legible, and the text is published.

UI-Venus-2-9B is less clear. The project's code repository says Apache 2.0; the model card states that the weight licence is pending final confirmation because upstream statements conflict. As of 28 October 2026 that has not been resolved. A pending licence is not a blocker for research and is a real blocker for a commercial deployment that needs to know its terms before it ships. Anyone planning to build on UI-Venus-2-9B should get the answer in writing rather than infer it from a repository tag.

Where OrcaRouter fits, if at all

OrcaRouter serves neither checkpoint, and this piece does not claim we do. What we do have is a routing DSL that can compose several models into one call — useful here because the natural architecture is not "pick one." A small general VLM can read the screen and decide whether the task is a document question or an interaction; a larger GUI specialist can take the interaction steps. Routing between them by task type is a configuration, not a second integration.

That is a more honest use of the comparison than pretending the two models are alternatives. They are two stages of the same pipeline, with a 5× parameter difference between them.

Which one you actually want

• LFM3-VL-2B if the job is understanding rather than acting, if you need video or document input, or if the model has to run in about 4 GB. Accept the revenue-capped licence and the fact that nobody outside Liquid has evaluated it.

• UI-Venus-2-9B if the job is operating an interface end to end, if you can supply 19 GB of GPU memory and a vLLM serving stack, and if you can wait for the weight licence to be confirmed. Accept that it is a specialist with a harness, not a general assistant.

• Neither if what you wanted was a 2.9B model. That model does not exist, and the two real options are both more specialised than the name implied.

The correction is the takeaway. A parameter count in a folder name is not a specification, and in this case it hid a five-fold size difference and a completely different job. Read the architecture field before the slug.