LFM2.5-VL-DSpark cuts vision-language model latency by up to 3.13x

Liquid AI published, on September 24, 2026, on the Hugging Face blog, an auxiliary model called LFM2.5-VL-DSpark, built to speed up inference for its vision-language model (VLM) LFM2.5-VL-3B. The technique behind this isn't new (speculative decoding has existed for a few years for text LLMs), but applying it to a multimodal model, which processes image and text in the same pipeline, is what makes this release relevant for anyone building products with open-source VLMs running outside a datacenter.

The problem speculative decoding solves

Language models generate token by token, sequentially and autoregressively. Each new token depends on the previous one, which locks generation into a slow cadence even on powerful GPUs, because the bottleneck is memory, not raw compute. Speculative decoding attacks this with a simple trick: a small, cheap model (the "drafter") proposes a block of several candidate tokens at once, and the large model (the "target") verifies all of them in parallel in a single pass. When the drafter is right, you gain several tokens for the price of one verification; when it's wrong, the target discards whatever is incorrect and proceeds normally. The critical point, which Liquid AI emphasizes in the announcement, is that the process is exact: the final greedy output is identical to what the target model alone would produce, so there's no quality loss, only a speed gain.

What changes with LFM2.5-VL-DSpark is extending this idea to multimodal input. According to Liquid AI, the vision drafter uses the same architecture as the text drafters in the LFM2.5-DSpark line (released in August 2026): it captures the target model's hidden states at a fixed set of layers and uses that to predict a block of k candidate tokens. The engineering move is that image patches and text tokens are projected into a shared representation before those layers, so the drafter sees hidden-state vectors with the same dimensionality regardless of whether the input is a pixel or a word. In practice, this means the speculative inference algorithm needed no adaptation to handle images: the same code that works for pure text works here.

Architecture and memory cost

The drafter is described as a 4-layer attention-only model, with a block size of 8 or 9 tokens, chosen after ablation tests comparing 3, 4, and 5 layers. Liquid AI trained it for 10 epochs on a mix of vision-language SFT data weighted toward the workloads the model is expected to serve, measuring the drafter's acceptance rate at each epoch until the gains started to diminish.

The final result has about 280 million parameters, distributed as follows: 193M in the decoder stack (4 layers), 21M in the hidden-state projection, 65.5M in the "Markov head," and a residual fraction in normalizations and the confidence head. This represents an 8.9% addition on top of the 3B parameters of the target model LFM2.5-VL-3B. It's a number worth noting: to run this setup you need enough memory (VRAM or unified RAM) for both models simultaneously, not just the target.

Speedup numbers, by platform

The evaluation was carried out with block size 8 on six different visual tasks (general VQA, text VQA, image captioning, chart VQA, complex reasoning, and multi-turn conversation), following the MMSpec benchmark. The results released by Liquid AI:

• MLX on Apple M5 Max: decode 2.30x to 3.13x faster; end-to-end 1.56x to 2.62x.
• llama.cpp on Apple M3 Ultra: decode 1.57x to 2.14x; end-to-end 1.30x to 1.77x.
• H100 (SGLang): decode up to 2.66x; end-to-end up to 2.27x.

Note that the decode gain is always larger than the end-to-end gain, and that's not an accident: it's the technique's own structural limit, which Liquid AI addresses in the limitations section of the post.

Where the technique doesn't help (and why it matters more at the edge)

Speculative decoding only speeds up the decode phase, token by token. It doesn't touch prefill (processing the initial prompt) or the image encoding done by the vision encoder, which in a VLM adds up to hundreds of visual tokens processed even before the first output token is generated. On datacenter GPUs like the H100, prefill tends to be fast enough that it doesn't dominate total latency. On edge devices, with far less compute power, prefill (including image encoding) ends up consuming a larger share of total response time, and that's exactly what the time-to-first-token numbers on Apple Silicon show.

Liquid AI calls this by its right name: Amdahl's law. If half of your response time is spent on prefill and vision encoding, no decode speedup, no matter how large, will make the total response more than twice as fast. This explains why applications that process large images or long prompts (scanned documents, high-resolution screenshots, extensive multi-turn context) tend to feel the DSpark gain less than short-response applications with little visual context, like a support chatbot that analyzes a small screenshot and answers in one or two sentences.

How to run it in practice

Day-one support covers three runtimes well known to anyone already running LLMs locally. With SGLang, you need a build with DSpark support for LFM2 models (PR #40651 of the project), and the command points to the target and the drafter separately:

python -m sglang.launch_server \
 --model-path LiquidAI/LFM2.5-VL-3B \
 --speculative-algorithm DSPARK \
 --speculative-draft-model-path LiquidAI/LFM2.5-VL-3B-DSpark \
 --speculative-draft-attention-backend flashinfer \
 --speculative-dspark-block-size 9 \
 --disable-radix-cache

The baseline for comparison is the same command without the three --speculative-* flags. With llama.cpp (build from PR#29339), the command looks like this:

llama-server -m models/LFM2.5-VL-3B-F16.gguf \
 --mmproj models/mmproj-LFM2.5-VL-3B-F16.gguf \
 -md LFM2.5-2.6B-DSpark-F16.gguf \
 --spec-type draft-dspark --spec-draft-n-max 8 --spec-draft-n-min 0 \
 -fa on -ngl 99 -c 8192

And with MLX-VLM (build from PR#2280), the integration is more direct:

mlx_vlm.server --model LiquidAI/LFM2.5-VL-3B --draft-model LiquidAI/LFM2.5-VL-3B-DSpark

In every case, block size is read from the drafter's configuration, and each response reports draft_n / draft_n_accepted, which gives real visibility into acceptance rate in production, useful for deciding whether it's worth keeping speculation on for a specific workload or turning it off when the gain doesn't justify the extra memory.

What changes for builders

For anyone already running open VLMs locally (on their own server, on an edge device, or in a desktop application with MLX on Apple Silicon), DSpark is a latency gain with no quality trade-off, since verification is exact. The real cost is memory: 8.9% more resident parameters, which in tight-VRAM scenarios can be the difference between fitting or not fitting on the available hardware. It's worth testing which of the six MMSpec task categories best fits your use case, because the variation in gains across tasks was large (from 1.30x to 2.62x end-to-end, depending on the platform and task).

The most important takeaway for anyone deciding to adopt this now is: if your application processes large images or long prompts before generating little output, the practical gain tends to be modest, because the bottleneck is in prefill, not decode. But for applications that run many rounds of relatively long generation from a small image (UI description, chart reading, conversational multimodal assistant), the decode gain translates almost directly into lower perceived latency for the end user, something that matters a lot for products running in Brazil, where cloud GPU cost is still a decisive factor in making applied AI viable in production.