Liquid AI’s DSpark Model Speeds Up Vision AI Latency Up to 3.13x

TL;DR

• Liquid AI shipped an experimental draft model, LFM2.5-VL-DSpark, built to accelerate its LFM2.5-VL-3B vision-language model.
• The drafter tacks on just 280M parameters (an 8.9% bump over the 3B base) but pushes decode speeds up to 3.13x faster on Apple Silicon and 2.66x faster on NVIDIA H100 GPUs.
• End-to-end latency gains hit 2.62x on-device and 2.27x on H100 across six vision-language tasks, from chart reading to multi-turn chat.
• Support for llama.cpp, MLX-VLM, and SGLang arrived on day one, so this isn’t a research paper waiting for tooling. It’s usable now.

A Tiny Drafter Doing the Heavy Lifting

Liquid AI’s newest release doesn’t try to replace its LFM2.5-VL-3B model. It just makes it faster. The company built a draft model, DSpark, that sits alongside the main 3B vision-language model and speeds up how quickly it writes text after it’s looked at an image.

The trick is speculative decoding, a technique where a small, cheap model guesses several tokens ahead, and the bigger model checks those guesses in parallel instead of generating one token at a time on its own. Small model. Big payoff. Liquid AI had already done this for text-only models with earlier LFM2.5-DSpark releases. This is the first time the company has extended it to vision.

The numbers here are specific, not vague marketing fluff. The draft model adds 280M parameters, an 8.9% overhead on top of the 3B target model. In exchange, decode speeds climb up to 3.13x on an Apple M5 Max running MLX, and up to 2.66x on an NVIDIA H100 through SGLang. End-to-end latency, the full time a user actually waits, improves up to 2.62x on-device and 2.27x on the H100.

Liquid AI tested this across six vision-language tasks: visual question answering, image captioning, chart understanding, complex reasoning, and multi-turn conversation, following what it calls the MMSpec benchmark. And the tooling is already there. llama.cpp, MLX-VLM, and SGLang all support the drafter from launch, which matters more than it sounds. A lot of promising inference research dies in the gap between a paper and a checkpoint you can actually run.

The Part Speculative Decoding Can’t Touch

Here’s the honest catch, and Liquid AI says it outright: speculative decoding only speeds up the decode phase, the part where the model writes text token by token. It does nothing for vision encoding or prompt prefill, the upfront work of processing the image before generation even starts.

Think of it like a restaurant kitchen. Speculative decoding is a faster line cook plating dishes once the ingredients are already prepped. It can’t make the prep cook chop vegetables any quicker. If a vision-language task involves a huge image or a long visual prompt, that prefill time still sits there, unmoved, no matter how fast the decoder gets. That’s Amdahl’s law showing up in real hardware: speed up one part of a pipeline and the part you didn’t touch becomes the new bottleneck.

But why does that distinction matter so much for VLMs specifically? Because vision-language models burn an unusual amount of compute just turning pixels into tokens before they write a single word. Text-only models don’t carry that tax. So the tasks where this drafter helps most, chat-style back-and-forth, short captions, quick visual Q&A, aren’t the same tasks where prefill dominates, like dense chart parsing or multi-image reasoning. Liquid AI evaluated across all six categories anyway, which is the right call. It lets developers see exactly where the gains show up and where they thin out, instead of hiding the weak spots behind one averaged headline number.

I’ve watched a lot of “faster inference” announcements turn out to be faster on one narrow benchmark and slower everywhere else once real users touch it. This one at least names its own ceiling before anyone else has to find it the hard way.

What this really signals is a shift in where efficiency work happens. Custom inference pipelines at large labs have had tricks like this for a while. Open-weight VLMs mostly haven’t, because building a matched draft model for a multimodal target is genuinely fiddly: the drafter has to agree with the target closely enough that verification rarely fails, or the whole speedup evaporates. Getting that right for a vision model, not just text, and shipping the checkpoints openly with day-one runtime support, closes a gap that’s been sitting open for a while.

Why Draft Models Exist in the First Place

Speculative decoding isn’t new. It’s been used in text generation for a couple of years now as a way to squeeze latency out of large models without touching accuracy. The target model still verifies every token; nothing gets accepted just because the small model proposed it. Quality doesn’t get traded away for speed, at least not by design, and Liquid AI’s framing leans on that same guarantee.

What’s newer is doing this well for vision-language models. VLMs carry a structural handicap text models don’t: images turn into hundreds or thousands of tokens before the model writes a single word back. That’s a lot of extra weight riding on top of whatever the decoder is doing, and it’s part of why VLM inference has felt sluggish compared to text-only chat, especially on-device where memory and compute are both tight.

Liquid AI’s own background here is straightforward: it built text-only DSpark drafters first, proved the approach worked, then extended the same idea to its vision-language line. That’s a sensible order of operations, and it explains why this release reads less like a moonshot and more like the next obvious step in a plan someone had already mapped out.

Three Things Worth Tracking From Here

The immediate question is adoption: will other open-weight VLM builders start shipping matched drafters alongside their base models, the way Liquid AI just did, or does this stay a one-company trick? Keep an eye on whether llama.cpp, MLX-VLM, and SGLang usage data shows real uptake outside Liquid AI’s own benchmarks, since day-one support means nothing if nobody actually runs it.

Also worth tracking: independent benchmarks. Liquid AI’s numbers come from its own MMSpec-style evaluation, a reasonable methodology but still a self-reported one. Third-party testing on different hardware, different image sizes, and messier real-world prompts will tell us whether 3.13x holds up outside a controlled setup.

And finally, watch whether Liquid AI or anyone else tackles the prefill bottleneck directly. Speculative decoding fixes half the latency problem. The other half, getting image tokens processed faster in the first place, is still sitting there waiting for its own breakthrough.

Source: Hugging Face