Liquid AI Releases LFM2.5-DSpark Draft Models That Deliver Up to 3.18x Faster Decoding Without Changing Model Outputs

Liquid AI has released DSpark draft model checkpoints for three models in its LFM2.5 family: LFM2.5-1.2B-Instruct , LFM2.5-2.6B , and LFM2.5-8B-A1B . Each drafter adds a speculative decoding path to an existing target model. A roughly 300M-parameter draft proposes a block of nine candidate tokens, and the target model verifies the whole block in a single forward pass. The trade is a small memory increase for a large decoding speedup: up to 3.18x on an H100 and up to 2.87x on an M4 Max MacBook Pro. Output does not change. Under greedy decoding, the emitted sequence is identical to the target model running alone, so benchmark accuracy is unchanged. Both llama.cpp and SGLang have day-one support.

Yes, if you self-host. The weights ship as Safetensors and GGUF, and the drafter checkpoints are not served by any hosted inference provider on Hugging Face today. Running them needs an SGLang or llama.cpp build with DSpark support for LFM2 targets.

Speculative decoding uses a small model to propose tokens that a larger model verifies. Each LFM2.5 drafter is roughly 300M parameters: 295.7M for the 1.2B-Instruct target and 327.7M for the 2.6B and 8B-A1B targets. The backbone is 5 full-attention layers with hidden_size=2048 , intermediate_size=6144 , GQA at 32 heads over 8 KV heads, and a block size of 9. The drafter ships no vocabulary weights; embedding and LM head are tied from the target at load time. The 2.6B drafter repository is 655 MB in BF16, which is the real memory cost you are adding.

DSpark combines three parts. A DFlash -style parallel backbone, conditioned on the target’s context features, produces hidden states for all draft tokens in one forward pass. A lightweight sequential head, modeled as a Markov chain between neighboring tokens at rank 256, restores inter-token dependency and lifts acceptance at later block positions. A confidence-scheduled verifier predicts each token’s survival probability and prunes low-confidence suffixes when verification would cost more than it saves.

Liquid AI reports throughput on 1xH100 in BF16 via SGLang, and on an M4 Max MacBook Pro via llama.cpp with Metal and FP16 GGUF weights. Both use block size 9, batch size 1 and temperature 0, across MATH500, HumanEval, MBPP, GSM8K and MT-Bench.

Speedup tracks acceptance rate, which tracks how predictable the output is. LFM2.5-8B-A1B accepts 8.27 of 10 tokens per step on MATH500 and only 4.02 on GSM8K, so the same model swings from 3.18x to 1.29x on the same GPU. On the 1.2B model, MT-Bench acceptance drops to 3.90 and the H100 gain falls to 1.66x.

The MoE result on Apple silicon is the clearest caveat: LFM2.5-8B-A1B gains only 1.18x on average on the M4 Max. Liquid AI attributes this to the current MoE implementation in llama.cpp’s Metal backend, and to the fact that verifying k tokens activates more experts, and therefore more weight traffic, than a single decode step.