Liquid AI just dropped DSpark draft models for three of their LFM2.5 family checkpoints: the 1.2B-Instruct, 2.6B, and 8B-A1B models. The pitch is straightforward: add a ~300M parameter draft model, get up to 3.18× throughput on an H100 and up to 2.87× on an M4 Max MacBook, with zero quality degradation.
This is speculative decoding in production, and it ships with day-one support for llama.cpp and SGLang. If you've been waiting for speculative decoding to move from paper to packaged artifact, this is it.
Why Speculative Decoding Still Matters
LLM inference is memory-bound. Most of your latency comes from streaming weights from DRAM into SRAM, not from compute. You're bandwidth-limited, not flops-limited.
Speculative decoding addresses this by proposing multiple candidate tokens with a lightweight draft model, then verifying them all in a single forward pass through the target model. You amortize the cost of loading those big weights across all the tokens you verify, rather than paying the memory tax once per token.
The core trade is simple: add a small model that runs fast but might guess wrong, then batch-verify its guesses. When it's right, you decode multiple tokens for the price of one verification pass. When it's wrong, you discard the bad suffix and continue.
How DSpark Works
DSpark combines three components from recent research:
-
Parallel backbone (DFlash-style): The draft model conditions on the target model's context features and produces hidden states for all draft tokens in a single forward pass. No sequential bottleneck here.
-
Lightweight sequential head: Modeled as a Markov chain between neighboring tokens. This adds inter-token dependency, which raises the acceptance rate at later positions in the draft sequence.
-
Confidence-scheduled verifier: Predicts each token's survival probability and prunes low-confidence suffixes when verification would cost more than it saves. This is the trick that keeps you from wasting compute on garbage drafts.
Liquid trained these drafters on a larger and more diverse mix than the original DSpark paper—SFT, chat, code, and function-calling data. They ran 15 epochs and selected the checkpoint with the highest acceptance rate, not the lowest loss. Smart.
Architecture Details
The draft models are attention-only, 5 layers deep, with a block size of 9. Here's the parameter breakdown for the 2.6B drafter:
- Decoder stack (5 layers): 241.2M
- Hidden-state projection: 21.0M
- Markov head: 65.5M
- Norms + confidence head: 27.5k
- Total: 327.7M parameters
That's a ~12% memory overhead for the 2.6B target model. Minimal.
Quality Parity by Construction
This is the elegant part: under greedy decoding, a draft token is only accepted if it matches the target model's distribution. On rejection, the target model's own token takes its place.
The emitted sequence is therefore identical to baseline greedy decoding by construction. Benchmark accuracy (pass@1, exact match) is unchanged. You're not trading quality for speed—you're trading a bit of memory for throughput.
This matters for production. You can swap in the drafter without revalidating your entire eval suite.
Throughput Numbers
Liquid tested on five benchmark datasets—MATH500, HumanEval, MBPP, GSM8K, and MT-Bench—measuring throughput on both an H100 80GB (SGLang, BF16) and an M4 Max MacBook Pro (llama.cpp, FP16 GGUF, Metal).
LFM2.5-2.6B Results
This is the sweet spot for on-device deployment:
- H100: 2.67× average speedup (323 → 864 tok/s)
- M4 Max: 2.27× average speedup (61 → 139 tok/s)
- Acceptance rate: 4.81 tokens per draft block (out of 9)
On MATH500, the MacBook hits 137 tok/s—well above the ~140 tok/s ceiling you see from most proprietary cloud APIs. That's a meaningful UX threshold.
For function-calling workloads, DSpark cuts latency by 57% on average. If you're building agentic systems on-device, that's the headline.
LFM2.5-1.2B-Instruct Results
More variance here—acceptance rates swing from 3.90 to 6.02 depending on the dataset:
- H100: 2.10× average speedup (656 → 1384 tok/s)
- M4 Max: 2.54× average speedup (138 → 350 tok/s)
MT-Bench acceptance is notably lower (3.90), so speedup drops to 1.66× on GPU and 1.72× on-device. This tells you the drafter is less confident on conversational text.
LFM2.5-8B-A1B Results
This is the MoE model, and the numbers are instructive:
- H100: 2.54× average speedup (418 → 1074 tok/s)
- M4 Max: 1.18× average speedup (90 → 106 tok/s)
- Acceptance rate: 6.95 tokens per draft block
The acceptance rate is the highest of the three models, but on-device speedup is only 18%. Liquid attributes this to the current MoE implementation in llama.cpp's Metal backend and the fact that verifying multiple tokens activates more experts—more weight traffic than a single decode step.
This is a good reminder that speculative decoding interacts with your execution backend. MoE + Metal + multi-token verification is still a work in progress.
How to Use It
Both SGLang and llama.cpp support DSpark out of the box.
SGLang
Launch the target with the draft attached:
python -m sglang.launch_server \
--model-path LiquidAI/LFM2.5-2.6B \
--speculative-algorithm DSPARK \
--speculative-draft-model-path LiquidAI/LFM2.5-2.6B-DSpark \
--speculative-draft-attention-backend flashinfer \
--disable-radix-cache --mem-fraction-static 0.75 --port 30000
Then query the OpenAI-compatible endpoint at http://localhost:30000/v1. The block size is read from the draft's config.json.
llama.cpp
llama-server -m LFM2.5-2.6B-F16.gguf \
-md LFM2.5-2.6B-DSpark-F16.gguf \
--spec-type draft-dspark --spec-draft-n-max 10 --spec-draft-n-min 0 \
-fa on -ngl 99
The block size is read from the sidecar metadata. Greedy output is identical to the target alone; per-response timings report draft_n and draft_n_accepted.
What This Means
Speculative decoding has been a research curiosity for a while—EAGLE, Medusa, and now DSpark all promise big speedups, but adoption has been slow. Liquid is shipping the full stack: trained drafters, upstream integration in two major runtimes, and GGUF weights for on-device deployment.
This is what productionizing a research idea looks like. The drafters are open-weight, the integration PRs are merged upstream, and the benchmarks cover both cloud GPU and laptop.
The on-device numbers are especially interesting. 139 tok/s on a MacBook for a 2.6B model with function-calling support is a real UX unlock. You're not waiting for the model anymore—it's keeping up with you.
The MoE story is less polished. The acceptance rate is high, but the Metal backend isn't yet optimized for the multi-expert activation pattern that verification induces. That's solvable, but it's a reminder that speculative decoding isn't a silver bullet—it's a system-level optimization that interacts with your memory hierarchy, your kernel fusion, and your weight-loading strategy.
Where This Goes
I expect to see more model families ship with paired drafters as a standard artifact. Training a drafter is cheap relative to training the base model, and the speedup is too large to ignore.
The hard part is making it work across backends. Liquid did the work to integrate DSpark into SGLang and llama.cpp, which means it'll work with Ollama, LM Studio, and the rest of the llama.cpp ecosystem. That's the distribution strategy.
The confidence-scheduled verifier is also interesting. Most speculative decoding papers treat acceptance as a binary threshold, but DSpark explicitly models the cost-benefit tradeoff of verifying each suffix. That's a more principled approach, and I'd like to see ablations on how much of the speedup comes from the verifier versus the Markov head.
For now, if you're deploying LFM2.5 models, you should probably be using the DSpark drafters. The quality is identical, the memory overhead is small, and the speedup is real.
Checkpoints are live on Hugging Face in both Safetensors and GGUF formats.