LFM2.5-VL-3B-DSpark vs UI-Venus 2.9B: A Speed Multiplier Against a GUI Agent

LFM2.5-VL-3B-DSpark and UI-Venus 2.9B get filed under the same vague heading — small vision models — and then compared to each other, which is a category error worth fixing before it costs someone a week of integration. LFM2.5-VL-3B-DSpark is a 279.5M-parameter draft model that accelerates Liquid AI's LFM2.5-VL-3B. UI-Venus 2.9B, from Ant Group's inclusionAI lab, is a 9B GUI agent that reads screenshots, decides on an action, and executes it across mobile, web and desktop environments. One makes an existing model faster. The other is the thing doing the work. If what you need is a GUI agent, the drafter is not a cheaper option — it is not an option at all.

The useful comparison is not which is better but which problem each one solves, and what each costs you in the process. Both are also recent arrivals that the wider ecosystem has not caught up with, and the gap between what their repositories claim and what anyone else has verified is larger for one of them than the other.

What each one is, precisely

Start with the shapes, because they explain most of the rest.

• What it is — LFM2.5-VL-3B-DSpark is a speculative-decoding drafter; UI-Venus 2.9B is a general-purpose GUI agent policy

• Parameters — 279.5M BF16 for the drafter, against 9B for UI-Venus 2.9B initialized from Qwen3.5-9B

• Standalone capability — the drafter generates nothing usable alone and cannot be benchmarked in isolation; UI-Venus 2.9B runs as a complete agent

• Inputs — the drafter never sees the image itself, only the target model's hidden states; UI-Venus 2.9B consumes screenshots directly and is built entirely around them

• Outputs — the drafter proposes tokens for verification; UI-Venus 2.9B emits grounded actions with bounding boxes against a live interface

• Base — the drafter is tied to LiquidAI/LFM2.5-VL-3B in its own metadata; UI-Venus 2.9B builds on Qwen3.5-9B

• Context — the drafter inherits whatever the target provides; UI-Venus 2.9B is served at a 262,144-token maximum in the vendor's own vLLM recipe

• License — both are unresolved in different ways; Liquid ships under the LFM1.0 license, and UI-Venus 2.9B's card states outright that its weight license is pending final confirmation

That last bullet is the one to slow down on. Our own UI-Venus-2-9B coverage in late August described the release as Apache-2.0, because that is what the project's materials carried at the time. The model card today says something different and stronger: that the model-weight license is pending final confirmation and will be added before public release, and that an Apache-2.0 declaration has intentionally not been carried over because the current upstream materials contain conflicting license statements. If you are planning a commercial deployment of UI-Venus 2.9B, the license question is open on the vendor's own admission, and that is a material risk rather than a footnote.

The numbers each side actually published

The two repositories measure different things, which is the point. Liquid publishes throughput; Ant Group publishes task success.

For the drafter, per Liquid's own harness: 2.66× decode speedup at best on a single H100 80GB in BF16 through SGLang, 3.13× at best with MLX-VLM on an Apple M5 Max, and 2.14× at best with llama.cpp on an M3 Ultra. End-to-end, those same runs land between 1.30× and 2.62× depending on stack and task. Draft acceptance sits around 3.2 to 4.5 tokens per verification pass. Every one of those is vendor-measured with no external reproduction.

For UI-Venus 2.9B, the card's own tables report 80.2 on AndroidWorld, 65.8 on MobileWorld at a 50-step budget, 70.8 on OSWorld-Verified, 48.0 on DeskCraft, 90.8 on WebVoyager across the refreshed 595-task split, 74.0 on Online-Mind2Web, 73.0 on ScreenSpot-Pro and 77.1 on VenusBench-GD. On CAPTCHA it reports 78.1 on VenusBench-CAPTCHA and 75.7 on MCA-Bench. On the safety side it reports an 11.3% attack success rate on OSHarm against 25.3% for its Qwen3.5-9B base. All of these are vendor-reported, some baselines carry an asterisk meaning the UI-Venus authors evaluated them under the stated protocol, and the card itself warns that OSWorld-Verified comparisons use model-specific action scaffolds and should be read as benchmark-level references rather than controlled ablations.

Note what is absent from both lists: anything measured by a third party. For the drafter that is because the checkpoint is days old. For UI-Venus 2.9B it is because GUI-agent benchmarks are expensive to reproduce and the live-environment results move with the environment's state on the evaluation date — a caveat the card volunteers.

Where the two actually meet

There is a real overlap, and it is narrower than the category label suggests. Both are relevant if you are building an on-device or edge visual agent, and both are concerned with the cost of getting pixels through a model. They attack it from opposite ends.

UI-Venus 2.9B attacks it with training: a three-stage pipeline of multimodal mid-training over simulated mobile, web and OS environments, per-domain offline RL, then multi-teacher on-policy distillation into a single policy. The published capability is the result. The model is 9B, which is small for a GUI agent and large for an edge device, and the card's intended serving configuration is a vLLM deployment — the same documentation notes that configuration was not live-canary-validated as part of the card update and tells you to pin and verify your vLLM version for Qwen3.5 before deploying.

LFM2.5-VL-3B-DSpark attacks it with runtime: it leaves the target model's weights untouched and buys speed by drafting and verifying tokens. On a phone-class device the trade is one-sided in the drafter's favour, because the output is provably the target's and the extra memory is under a tenth of a model.

The consequence for anyone choosing: an agent loop makes many model calls per task, and every call pays prefill for a fresh screenshot. Vision encoding and prefill are precisely the stages speculative decoding does not accelerate — Liquid's own announcement makes this argument against an unlimited reading of its headline numbers. So the drafter's advantage shrinks in exactly the workload UI-Venus 2.9B lives in. Conversely, UI-Venus 2.9B's advantage — actually completing the task — is not something a drafter provides at any speed.

Running the two

Neither is a hosted endpoint on OrcaRouter. LFM2.5-VL-3B-DSpark and UI-Venus 2.9B both require you to pull weights and serve them yourself, and their serving stories are shaped by their very different roles. The drafter needs SGLang v0.5.19 or newer with a DSPARK speculative algorithm flag and a block size of 9, or MLX-VLM v0.7.2 or newer with the drafter passed as a draft model and temperature forced to zero, or llama.cpp with a 567 MB F16 GGUF paired to a quantized target. UI-Venus 2.9B needs a vLLM server large enough for a 9B model at a 262,144-token maximum length, plus the reference prompts and action parsers from the project's code repository — the card is explicit that starting the server alone does not give you a working closed-loop GUI agent.

Both also leave the same gap at the edges of what they can do. A small vision-language model paired with a drafter still meets screens and tasks it cannot handle, and a GUI agent still fails on environments outside its training distribution. The queries that fall through land somewhere, and in most production designs that is a larger general-purpose model. Routing those through a single endpoint covering 200+ models at each provider's list price, with automatic failover when a provider degrades, keeps the fallback path off the critical integration list rather than turning it into a second deployment project with its own keys and contracts.

How to decide in one minute

If you need software that operates a user interface — clicking, typing, navigating an app it has never seen — you are buying a policy, and that is UI-Venus 2.9B. Budget for a 9B vLLM deployment, read the pending license question before you commit commercially, and treat the vendor's benchmark table as a strong starting hypothesis rather than a settled result, particularly the OSWorld-Verified comparisons the card itself flags as scaffold-dependent.

If you already run LFM2.5-VL-3B and want it faster on hardware you own, you are buying a runtime optimization, and that is LFM2.5-VL-3B-DSpark. Check three things first: that your workloads are decode-heavy rather than prefill-heavy, that you are serving at 16-bit rather than a 4-bit export, and that your runtime meets the version floors. If all three hold, the memory cost is 8.9% and the output is unchanged by construction.

The one thing that does not survive contact with either repository is treating them as substitutes. They are a speed multiplier and an agent, and the only scenario in which they compete is the one where you have already decided what you are building and are looking for a reason to build something cheaper instead.

OrcaRouter reaches 200+ models through one key at provider list price with 0% markup, with routing policy and automatic failover for the queries an edge model or an agent should not take. one API for the fallback path Neither model on this page is hosted there - both are served from your own weights - but the fallback path is the part you do not have to build.