Liquid AI just released LFM2.5-VL-DSpark, an experimental speculative decoding drafter for their 3B-parameter vision-language model. It's a technical follow-on to their text-only DSpark drafters from August, now extended to handle image inputs. The headline numbers are solid: up to 3.13x faster decoding on Apple silicon, 2.66x on H100, with end-to-end gains reaching 2.62x and 2.27x respectively.
But the more interesting story here isn't the speedup—it's the ceiling. Liquid's post includes an unusually candid discussion of why speculative decoding helps less for vision workloads than for pure text, especially on edge devices. It's a rare example of a model release that teaches you something about inference architecture, not just benchmark bragging rights.
How DSpark works for vision
The drafter uses the same architecture as Liquid's text models: it taps hidden states from a fixed set of layers in the target model and uses them to draft a block of candidate tokens. The key insight is that image patches and text tokens are projected into a shared representation before those tapped layers, so the drafter sees identical-dimensionality vectors regardless of input modality.
This means the inference algorithm is unchanged from the text case. The drafter doesn't need vision-specific logic—it just operates on the unified hidden states after the vision encoder has already done its work.
The final drafter has four attention-only layers with a block size of 9 (though they recommend 8 or 9 at inference time depending on hardware). Total parameter cost: 280M, an 8.9% increase over the 3B target. They trained it on a mixture of vision-language SFT data for 10 epochs, measuring acceptance rates after each epoch until hitting diminishing returns.
The speedup numbers
Liquid shipped day-one integrations for llama.cpp, MLX-VLM, and SGLang, and they benchmarked across six vision tasks: general VQA, text VQA, image captioning, chart VQA, complex reasoning, and multi-turn conversation.
On an M5 Max with MLX, decoding runs 2.30x to 3.13x faster by task, with end-to-end latency improving 1.56x to 2.62x. On an M3 Ultra with llama.cpp, decoding improves 1.57x to 2.14x and end-to-end 1.30x to 1.77x. On H100, decoding speeds up 2.04x to 2.66x, with end-to-end gains of 1.64x to 2.27x.
Those are meaningful wins, especially on device. But notice the gap between decode-only and end-to-end speedups. That gap is where the real lesson lives.
Amdahl's law bites harder on vision
Here's the part I wish more model releases would include: a clear-eyed analysis of where the technique doesn't help.
Speculative decoding only accelerates the decode phase—the autoregressive token generation after prefill. It does nothing for vision encoding or prefill itself. In text-only LLMs, prefill is compute-bound and grows sub-quadratically with prompt length, but it's often a small fraction of end-to-end latency for longer generations.
VLMs add two expensive upfront stages: the vision encoder processes the image, then the language backbone handles hundreds of visual tokens alongside the text prompt. On edge devices with far less compute than datacenter GPUs, prefill and vision encoding eat up much more of the total wall time.
Liquid explicitly invokes Amdahl's law: when the non-accelerated portion of a workload dominates, even a large speedup on the accelerated portion yields only modest overall gains. The M5's neural accelerators narrow this gap somewhat, but the fundamental constraint remains.
This is why the H100 shows smaller relative end-to-end gains than you'd expect from its decode speedup: the GPU blasts through prefill quickly, so decode is a bigger share of latency, so speeding it up helps more. On Apple silicon, prefill is slower relative to decode, so the end-to-end win is capped.
What this means for edge VLM inference
The implication is uncomfortable: speculative decoding is most valuable precisely where it's least needed (datacenter GPUs with fast prefill) and least valuable where you need it most (edge devices bottlenecked on prefill).
That doesn't make DSpark useless for edge VLMs—a 2.62x end-to-end speedup on M5 Max is nothing to sneeze at. But it does mean the returns are fundamentally limited by inference architecture, not draft model quality. You can't draft your way out of slow vision encoding.
The real path to faster edge VLM inference probably involves some combination of:
- Smaller vision encoders with less redundant computation
- Better prefill acceleration (quantization, flash attention, KV cache optimizations)
- Architectural changes that reduce the number of visual tokens fed into the language backbone
- Hybrid approaches that offload vision encoding to specialized hardware
DSpark helps, but it's attacking the part of the problem that's already moving fastest.
The bigger picture
Liquid's transparency here is worth calling out. Most model releases would trumpet the 3.13x decode speedup and bury the end-to-end numbers in a footnote. Instead, they lead with both metrics and explain why the gap exists.
This kind of honest engineering communication makes the field better. It helps practitioners set realistic expectations, and it frames the right questions for future work: if speculative decoding has an architectural ceiling for VLMs on edge, what complementary techniques can we layer in?
The models are open-weight and available on Hugging Face in Safetensors and GGUF formats. The integrations are already live in the respective repos (assuming the PRs have merged—check llama.cpp PR #29339, MLX-VLM PR #2280, and SGLang PR #40651).
If you're running VLMs on device and decode latency is your bottleneck, DSpark is an easy 2–3x win with minimal memory cost. But if prefill is your problem, this isn't the drafter you're looking for—and Liquid will tell you that themselves.