Liquid AI Ships DSpark: 3.18× Faster LFM2.5 Inference with a 300M Draft Model
A speculative-decoding scheme that integrates upstream into llama.cpp and SGLang, with the function-calling latency cut being the number that actually matters for a pipeline.
What happened
Liquid AI published LFM2.5-DSpark on 20 August 2026: a speculative-decoding scheme that cuts LFM2.5 inference time by up to 3.18× on a single H100 80 GB and 2.87× on an M4 Max MacBook Pro, with ~300M-parameter draft checkpoints released in Safetensors and GGUF on Hugging Face.
Context
Speculative decoding is a known pattern: a small draft model proposes tokens, a larger target verifies them in one forward pass, and the sequential bottleneck shrinks. What is new is the shipping surface. DSpark is integrated upstream into llama.cpp (PR #27383) and SGLang (PR #31041) as an open-source code path, not a third-party library. Liquid AI describes the Apple Silicon path as using experimental Metal kernels. For a studio already running LFM2.5 text models for script generation or agentic orchestration, the separate speculative-decoding project disappears.
How it works
Three components. A DFlash-style parallel backbone produces hidden states for all nine draft tokens in one forward pass, conditioned on the target's context features. A lightweight Markov-chain head adds sequential inter-token dependency so the draft is not nine independent guesses. A confidence-scheduled verifier prunes low-confidence suffixes before the target verifies, so you do not pay verification cost on tokens that will be rejected.
The draft model is ~300M parameters, attention-only, five layers, trained for 15 epochs on a mix of SFT, chat, code, and function-calling data. The selected checkpoint is the epoch with the highest acceptance rate, not the lowest loss. Under greedy decoding (temperature 0) the output is identical to the target model alone; the speedup is pure latency with no quality tradeoff.
Measurements ran across five benchmark datasets (not named in the post), up to 256 output tokens. GPU: SGLang, BF16, batch 1, single H100. On-device: llama.cpp + Metal, FP16 GGUF, M4 Max.
Our read
The post title rounds the speedup to 3.2×, but the body specifies 3.18×, and the "up to" qualifier is doing a lot of work. For LFM2.5-1.2B-Instruct, speedup varies by as much as 52% with the text distribution, so in the worst case you are closer to 1.8× than 3×. For the 8B-A1B MoE variant on the same M4 Max, average on-device improvement is 18%, which Liquid AI traces to llama.cpp's Metal backend and the extra expert-weight traffic during multi-token verification. If your studio runs the larger model on a Mac, DSpark is a convenience, not a transformation.
The number that matters for a pipeline is the 57% average function-calling latency cut on the 2.6B model. If your agentic workflow chains tool calls, ComfyUI node parameters, API orchestration, multi-step prompt refinement, that is the latency you feel in real time, and halving it changes the loop.
What the post does not state: whether DSpark generalises beyond the LFM2.5 family. Draft heads are trained per-target, the integration PRs reference LFM-compatible paths, and no cross-model claim is made. If you are on a different architecture, this is not a drop-in speedup.
What this changes
If your pipeline already uses an LFM2.5 text model, DSpark is now a flag in the inference engine rather than a separate project. You need the specific llama.cpp build (PR #27383) or SGLang build (PR #31041); stock releases do not include DSpark. The ~300M draft model adds negligible RAM overhead. On an M4 Max-class Mac, the 2.6B model reaches roughly 140 tok/s with DSpark, which is practical for interactive text steps.
This does not touch the ComfyUI diffusion pipeline. It accelerates the LLM components that feed into it. If you do not run LFM2.5, nothing changes on Monday.
License
No source in the brief states a licence for the DSpark draft checkpoints or the LFM2.5 target models. The llama.cpp and SGLang integration code inherits the parent projects' licences, but no DSpark-specific terms are given. Before building a commercial pipeline on these weights, check the Hugging Face model card.
Key takeaways
- DSpark delivers up to 3.18× GPU throughput (H100, SGLang, BF16) and 2.87× on-device (M4 Max, llama.cpp + Metal), with greedy output identical to the unmodified target model.
- The 57% function-calling latency reduction on LFM2.5-2.6B is the practically relevant number for agentic pipelines that chain tool calls.
- The 8B-A1B MoE variant gains only 18% on-device due to llama.cpp Metal backend limitations; larger-model benefits on Mac hardware are limited.
- DSpark requires specific llama.cpp or SGLang builds (PR #27383 / PR #31041); it is not in stock releases.
- No licence is stated in any source for the draft checkpoints or target models; commercial use is legally unresolved until the model card is checked.
Sources
How this post was made
Drafted from clustered primary sources by the models below, then read, edited and approved by a human before it was published. The sources are listed in full at the end of the article.
- Drafted
- Independent sources
- 1
- cluster pair
- gemma4:12b
- cluster label
- gemma4:12b
- radar brief
- gemma4:12b
- research brief
- qwen3.8:27b
- draft article
- qwen3.8:27b
- short script
- qwen3.8:27b
- seo pack
- gemma4:12b
- Run
- editorial-20260821T190508Z