On August 20, Liquid AI released DSpark draft model checkpoints for the LFM2.5 family on Hugging Face, covering three target models: LFM2.5-1.2B-Instruct, LFM2.5-2.6B, and LFM2.5-8B-A1B. This is not a new base model — it bolts a speculative decoding engine onto existing ones. A roughly 300M-parameter draft model generates candidate tokens first, and the target model verifies them in a single forward pass, trading minimal memory for a large decoding speedup.
The official numbers: 3.18x on GPU, 2.87x on-device
In Liquid AI's tests (SGLang, single H100 80GB, BF16), throughput improved by up to 3.18x; on-device with llama.cpp + Metal on an M4 Max MacBook Pro running FP16 GGUF, up to 2.87x. Take LFM2.5-2.6B: on the MacBook, MATH500 goes from 61 to 137 tok/s and MT-Bench from 62 to 123 tok/s — the company says the ~140 tok/s level already exceeds the interactive throughput of most proprietary cloud models. More practically for agent developers: across multi-tool scenarios, function-calling latency for LFM2.5-2.6B drops by 57% on average.
The three pieces of DSpark
The bottleneck in LLM decoding is usually not compute but the bandwidth of streaming weights from DRAM into SRAM. Speculative decoding lets a lightweight draft model produce candidates continuously while the target verifies several at once, amortizing weight-loading cost across multiple tokens. DSpark splits this into three components: a DFlash-style parallel backbone conditioned on the target model's context features, producing hidden states for all draft tokens in one forward pass; a lightweight sequential head modeling a Markov chain between neighboring tokens, adding inter-token dependency and raising acceptance at later positions; and a confidence-scheduled verifier that predicts each token's survival probability and prunes low-confidence suffixes when verification would cost more than it saves. One engineering detail is counterintuitive: training ran 15 epochs, and the final pick was not the lowest-loss checkpoint but the highest-acceptance one — a draft model's KPI is being accepted, not being accurate on its own.
Zero quality loss is by construction
Many worry that speculative decoding sacrifices quality. No guessing needed here: under greedy decoding, a draft token is accepted only if it matches the target model's distribution, and rejected positions are filled by the target's own tokens. The emitted sequence is therefore identical to baseline greedy by construction, leaving benchmark accuracy (pass@1, exact match) unchanged. That is a stronger promise than the "almost no quality drop" framing of quantization approaches.
MoE hits a wall on-device
Interestingly, the 8B-A1B (MoE version) has the highest acceptance of the three (MT-Bench 8.52/10, MATH500 8.27/10) and delivered the best 3.18x speedup on H100 — but only an 18% average improvement on the M4 Max. The official explanation: limitations of llama.cpp's Metal backend for MoE — verifying k tokens activates more experts and thus more weight traffic. In other words, dense models fully harvest the speculative decoding dividend on-device, while MoE has to wait for inference frameworks to catch up.
Both integrations — llama.cpp (PR #27383) and SGLang (PR #31041) — are open-sourced upstream, and checkpoints ship in Safetensors and GGUF formats. Rather than chasing the next bigger base model, it pays to internalize that "verification is free" — for on-device agents, halving latency is worth more than a point on a leaderboard. See the Liquid AI blog post.