Liquid AI speeds up its models up to 3.2x without changing a single output token
On August 20, 2026, Liquid AI released DSpark draft models for its LFM2.5 family, with throughput gains of up to 3.18x on GPU and 2.87x on-device and no change to the output. Teams serving open LLMs in production now have a concrete reason to reprice their cost per token.
August 20, 2026. Liquid AI publishes DSpark draft model checkpoints on the Hugging Face blog for three models in its LFM2.5 family: the 1.2B-Instruct, the 2.6B and the 8B-A1B. Up to 3.18x throughput on an H100, 2.87x on a M4 Max MacBook. 57% lower function-calling latency on average.
For anyone serving open models in production, the promise fits in one sentence: speculative decoding is no longer a lab technique — it is a setting you can switch on today, without touching output quality.
The bottleneck is not compute, it is memory
The decode phase of an LLM is, in most cases, memory-bound. The latency comes less from computation than from streaming weights out of DRAM into SRAM — the weights are re-streamed for every token, and the hardware spends more time waiting than computing.
Speculative decoding sidesteps that bottleneck. A small “draft” model proposes several candidate tokens; the target model then verifies them all in a single forward pass. The cost of loading the weights is shared across every token verified at once, instead of being paid token by token. The result is higher throughput for an identical final output.
The technique is not new: EAGLE-3, then DFlash, and most recently DSpark refined its variants. What changes with LFM2.5-DSpark is that a vendor ships ready-made, trained, open draft models instead of asking you to build them yourself.
Three building blocks, one mechanism
DSpark combines three components. First, a DFlash-style parallel backbone, conditioned on the target model’s context features, that produces hidden states for all draft tokens in a single forward pass. Second, a lightweight sequential head, modeled as a Markov chain between neighboring tokens, that adds inter-token dependency and raises the acceptance rate at later positions. Third, a confidence-scheduled verifier that predicts each token’s survival probability and prunes low-confidence suffixes when verification would cost more than it saves.
The draft models stay small — roughly 300 million parameters — against targets that run to several billion. For LFM2.5-2.6B, the draft weighs 327.7 million parameters; for the 1.2B, 295.7 million. Training followed the DSpark recipe over 15 epochs, selecting the epoch with the highest acceptance rate rather than the lowest loss — a metric choice that says everything about the goal: speed, not draft likelihood.
Quality does not move, by construction
The reassuring point, which Liquid AI makes explicit, is quality parity. Under greedy decoding, a draft token is accepted only if it matches the target model’s distribution. On rejection, the target’s own token takes its place. The emitted sequence is therefore identical to the baseline greedy output, by construction — pass@1 and exact-match benchmark scores do not change.
In other words, the speed gain is not paid for in accuracy. That is what separates speculative decoding from aggressive quantization: nothing is degraded, the compute is simply organized better.
# Speculative decoding with llama.cpp: the LFM2.5-DSpark draft accelerates the target
./llama-cli -m LFM2.5-2.6B.gguf --model-draft lfm2.5-dspark-draft.gguf \
--draft-max 9 -p "Explain the difference between a draft and a target."The numbers behind the promise
On an H100 80 GB in BF16 via SGLang, LFM2.5-2.6B climbs from 323 to 864 tokens/s on average — a 2.67x factor. On a M4 Max MacBook via llama.cpp and Metal, it climbs from 61 to 139 tokens/s, or 2.27x. The peak reaches 3.06x on MATH500 on the GPU, and 2.87x on HumanEval on-device for the 1.2B.
The detail that matters for agent builders: on multi-tool scenarios, DSpark cuts function-calling latency by 57% on average for the 2.6B. That is exactly where speculative decoding pays off most, because tool calls chain short sequences where every millisecond counts.
LFM2.5-2.6B — mean throughput across 5 datasets
H100 (SGLang, BF16) : 323 -> 864 tok/s (x2.67)
M4 Max (llama.cpp) : 61 -> 139 tok/s (x2.27)
Function-calling latency : -57% on averageThe 8B-A1B — a MoE architecture with roughly 1 billion active parameters — receives the same treatment, showing the technique applies to sparse models too, not just dense ones.
What it changes for those who serve LLMs
Support is announced day one in llama.cpp and SGLang, with the DSpark integration open-sourced upstream. Operationally: you do not have to wait for a fork or write your own engine. The two most common paths for local and GPU inference already carry the piece.
For a team that pays per token or charges for a service, a 2 to 3x throughput gain with no quality loss translates directly: either the same cost for three times the traffic, or a cost divided by three at constant traffic. It is rare for an optimization to fit in a single line of configuration.
Verdict
If you serve an LFM2.5-family model — or any model with a compatible draft — switch on speculative decoding today. The memory overhead is minimal, the output is identical by construction, and the throughput gain is measured, not promised.
If you are evaluating an open model for an agent, add “does a ready-made speculative draft exist” to your checklist. It is what will determine whether your end-to-end latency — and especially your tool-call latency — meets your targets, not just the theoretical benchmark throughput.
The rule to remember: speculative decoding has moved from research technique to production setting. The day an open-source model hits proprietary-cloud throughput, what counts is no longer model size, it is how the compute is organized.