LFM2.5-VL-3B-DSpark vs LFM2.5-VL-3B: You Don't Pick One, You Attach One

The search that brings people here is a comparison, but the honest answer is that LFM2.5-VL-3B-DSpark and LFM2.5-VL-3B are not two things you choose between. The second is a 3.1B vision-language model you can download and serve. The first is a 279.5M-parameter draft model that exists only to sit in front of the second one and make it decode faster. Pull the drafter out of the stack and it produces nothing; you cannot benchmark it on its own, because "on its own" is not a configuration it supports. The real comparison is LFM2.5-VL-3B running alone versus the same model running with the drafter attached.

Read it that way and the decision collapses to one question: does the extra memory and the extra runtime complexity buy you enough latency to matter for your workload? Liquid AI's own numbers say yes for decode-heavy work and explicitly say no when prefill dominates. Neither side of that has been reproduced outside the company.

The two checkpoints, side by side

What differs between them is the whole story, so it is worth putting the two repositories next to each other before the speed argument starts.

• Role — LFM2.5-VL-3B generates text and answers about images; LFM2.5-VL-3B-DSpark proposes tokens for it to verify and generates nothing usable by itself

• Parameters — 3.1B for the target, 279.5M BF16 for the drafter, which Liquid puts at an 8.9% increase to the deployed parameter count

• Architecture — the target is a hybrid model built on an LFM2.5-2.6B backbone with a SigLIP2 NaFlex vision encoder; the drafter is 4 full attention layers at hidden size 2,048 with grouped-query attention plus a Markov head and a confidence head

• Context window — 32,768 tokens for the target; the drafter carries no context of its own and inherits the target's

• Vision encoder — SigLIP2 NaFlex 400M on the target; the drafter has none and never sees the image directly

• Vocabulary — 128,000, and the drafter's embedding and LM head are tied to the target rather than duplicated, which is why the memory tax is smaller than 279.5M parameters would suggest

• License — both ship under Liquid's LFM1.0 license, which is "other" on Hugging Face rather than an OSI license, so read the terms before a commercial deployment

• Formats — the target ships as safetensors, GGUF, ONNX and MLX quantizations; the drafter ships as safetensors and a single F16 GGUF of roughly 567 MB

One line in that list deserves emphasis because it is the mechanical reason this pairing works at all: the drafter is not a small vision model. It has no vision encoder and it never touches the image. By the time tokens reach the hidden layers it drafts from, an image patch and a text token are both just tensors, so modality is invisible to the drafting computation. That is what let Liquid port a technique developed for text models onto a VLM without redesigning it.

What the drafter changes, and what it leaves alone

The target model does not change. That is not marketing — it is the correctness property of speculative decoding. Under greedy decoding, every draft token is verified by the target, so the output is exactly what the target would have produced alone. Under matched sampling settings at non-zero temperature, the output distribution matches the target's. The drafter trades memory for time and touches nothing else.

Which means every quality number you can find for LFM2.5-VL-3B applies unchanged to the paired configuration. On Liquid's own evaluation, the target scores 80.7 on ScreenSpot-v2, 61.5 on BLINK, 58.3 on MuirBench, 73.1 on MME, 63.3 on MMStar, 81.3 on ChartQA and 88.7 on POPE — all vendor-reported, none independently reproduced, and all equally true whether or not the drafter is attached. There is no quality-versus-speed trade-off to weigh here, and any comparison page that presents one has misread the model.

What does change is the cost of a token in wall-clock time. Liquid measures decode speedups from 2.04× to 2.66× on a single H100 in BF16 through SGLang at block size 9, 2.30× to 3.13× on an Apple M5 Max through MLX-VLM at block size 8, and 1.57× to 2.14× on an M3 Ultra through llama.cpp. End-to-end, the same runs land at 1.64×–2.27×, 1.56×–2.62× and 1.30×–1.77× respectively. Those pairs are the whole argument: decode improves roughly twice as much as end-to-end does, and the gap is the part of the workload the drafter cannot touch.

The prefill problem, stated by the vendor

The most useful sentence in Liquid's own announcement is the one arguing against an unlimited reading of its headline. Vision-language inference pays a prefill cost that text inference does not: the image goes through a vision encoder, and the language backbone then processes the hundreds of visual tokens that encoder emits. On an edge device that prefill is a large share of end-to-end latency. Speculative decoding accelerates decode only — vision encoding and prefill are unchanged. Where prefill dominates, a 3× decode speedup converts into a much smaller end-to-end win.

That is Amdahl's law applied by the vendor to the vendor's own product, and it should shape who reads this page. A long transcription of a single scanned page, a caption, a multi-turn conversation carrying one image forward — decode-heavy, and the drafter earns its 279.5M parameters. A short question about a large high-resolution image — prefill-heavy, and it does not. Put the same target on a server at high concurrency and the picture shifts again: Liquid measures a throughput-interactivity frontier rather than a single number, and reports that DSpark keeps its advantage at every concurrency level tested while the gap narrows as concurrency rises.

Two smaller scoping notes from the same source. All measurements use 16-bit processing for both the vision encoder and the language backbone, and acceleration of quantized models is outside the scope of the release. If your plan was to pair a 4-bit target export with the drafter because the whole appeal of a 3B VLM is fitting in a few gigabytes, that combination is not what was measured.

What attaching it actually costs you

Memory is the visible cost and the card quantifies it: 8.9% more parameters in the deployed stack. Runtime complexity is the invisible one. SGLang needs v0.5.19 or newer and a launch line carrying --speculative-algorithm DSPARK, the draft model path and a block size; the card's own example also disables the radix cache and pins a static memory fraction, which are serving decisions you now have to reason about. MLX-VLM needs v0.7.2 or newer and takes the drafter through --draft-model, but DSpark decoding there currently uses greedy sampling, so temperature has to be forced to 0 — a real constraint if your application relies on sampling diversity. llama.cpp works through the GGUF drafter paired with the GGUF target, not with the original safetensors checkpoint.

There is one more cost that shows up in production rather than in a benchmark: the drafter and the target have to travel together. Version-skew between them is a failure mode that does not exist in a single-model deployment, and rolling either one independently is now a two-artifact problem.

This is a self-hosted pairing. OrcaRouter does not route LFM2.5-VL-3B or its drafter — you download both and serve them yourself — so the routing question is about everything the small model hands off to. Most deployments that pair a 3B edge VLM with the drafter still have queries the small model should not answer, and sending those to a single endpoint covering 200+ models at each provider's list price, with automatic failover if a provider degrades, is one integration instead of one per vendor. It also means the moment a provider cuts a price, your rate reflects it the same day rather than at the next contract renewal.

Which one to download

If your workload is decode-heavy and your hardware is one of the three Liquid tested, attach the drafter — the downside is bounded, because the output is provably the target's and the memory cost is under a tenth of a model. If your latency is prefill-dominated, or you are running a quantized target, or you depend on non-greedy sampling in a runtime that has not lifted that restriction, run LFM2.5-VL-3B alone. It is fast on its own terms: 228 tokens per second on an M5 Max, 116 on an AMD Ryzen AI Max+ 395, and 20 on a Galaxy S26 Ultra, all vendor figures, in roughly 3 GB of memory.

What nobody can tell you yet is whether Liquid's numbers hold on your hardware. The drafter had 37 downloads on Hugging Face at the time of writing and no independent reproduction of any figure in its tables. The engineering is sound and the correctness argument is a proof rather than a claim, but the magnitude is a measurement — and measurements from one lab on one set of machines are exactly the kind of number to verify yourself before you put them in a capacity plan.

OrcaRouter reaches 200+ models through one key with each provider's list price passed straight through at 0% markup and automatic failover between providers. provider list price passed through at 0% markup The pairing on this page is self-hosted either way - the router is for everything the small model hands off to, and it means a provider price cut shows up in your rate the same day.