What does a 300-million-parameter add-on do to a 2.6-billion-parameter model on a laptop?

The draft model is smaller than the main model by a factor of ten

Each DSpark checkpoint weighs roughly three hundred million parameters. The three targets — LFM2.5-1.2B-Instruct, LFM2.5-2.6B, and LFM2.5-8B-A1B — range from 1.2 to 8 billion. The draft adds a parallel backbone that produces hidden states for nine candidate tokens in one forward pass. A lightweight Markov head then stitches those tokens together. A confidence head predicts which suffixes are worth verifying. The whole stack fits in 295.7 million parameters for the 1.2B pair and 327.7 million for the other two.

Training ran for fifteen epochs on a mix of supervised, chat, code, and function-calling data. The team kept the epoch with the highest acceptance rate, not the lowest loss. Acceptance rate means how many of the nine drafted tokens survive verification. On MATH500 the 2.6B draft accepts 5.42 tokens on average. On MT-Bench it accepts 5.07. The 1.2B draft swings wider: 6.02 on MATH500 but only 3.90 on MT-Bench. The 8B-A1B draft accepts the most — 8.27 on MATH500 and 8.52 on MT-Bench — yet its on-device speedup barely reaches 18 percent.

The speedup lives in the memory wall

Decoding is memory-bound. Weights stream from DRAM into SRAM; compute waits. Speculative decoding amortizes that weight load across several tokens. The target model verifies the whole batch in one pass. If a token matches the target distribution it stays. If it mismatches the target token replaces it. The final sequence is identical to greedy decoding by construction. Benchmark accuracy does not change.

On an H100 80 GB in BF16 the 2.6B pair moves from 323 to 864 tokens per second on average — a 2.67× gain. On an M4 Max MacBook Pro in FP16 GGUF the same pair moves from 61 to 139 tokens per second — a 2.27× gain. The 1.2B pair jumps from 656 to 1384 tokens per second on H100 and from 138 to 350 on the MacBook. The 8B-A1B pair reaches 1074 tokens per second on H100 but only 106 on the MacBook. The gap comes from the current MoE implementation in llama.cpp Metal: verifying nine tokens activates more experts and more weight traffic than a single decode step.

Function calling latency drops by more than half

Across multi-tool scenarios the 2.6B model cuts latency by 57 percent on average. The 1.2B model shows high variance — speedup varies by up to 52 percent depending on the underlying text distribution. The 8B-A1B model does not report a function-calling figure.

Day-one support ships for llama.cpp and SGLang. The llama.cpp command loads the target GGUF and the draft GGUF with a draft type flag and a maximum draft length of ten. The block size of nine comes from the sidecar metadata. SGLang requires a build with DSpark support for LFM2 targets. The launch command attaches the draft model path and sets the speculative algorithm to DSPARK. Both stacks report per-response draft tokens and accepted tokens.

Where the models live

Safetensors and GGUF checkpoints sit on Hugging Face under the LiquidAI organization. Six repositories total: three Safetensors and three GGUF. The draft models are open-sourced upstream in both inference engines. No quantization-aware distillation is mentioned for these drafts. The blog cites the DSpark paper from July 2026 and the earlier EAGLE-3 and DFlash papers.