Liquid AI's DSpark Triples LFM2.5 Speed Without Changing Its Outputs

Liquid AI just dropped speculative decoding companions for its LFM2.5 model lineup, and the numbers are hard to ignore: up to 3.18x throughput on an H100 and 2.87x on an M4 Max MacBook, without changing what the base model outputs. The release, called DSpark, ships three lightweight draft models paired with the 1.2B, 2.6B, and 8B mixture-of-experts variants of LFM2.5, plus upstream integration in llama.cpp and SGLang so you can run it today.

The idea behind speculative decoding is straightforward. Decoding is memory-bound. Most of the latency comes from streaming weights from DRAM into SRAM rather than intense computation, so if you can verify many tokens in a single forward pass, you get most of the speedup for free. A small draft model proposes a block of candidate tokens, and the big target model checks them all at once. Rejected tokens fall back to the target's own output, meaning under greedy decoding the emitted sequence is identical to baseline greedy by construction, so benchmark accuracy is unchanged.

What is actually new in DSpark

DSpark isn't just another EAGLE clone. It combines three components that address different failure modes of prior speculation methods:

• A DFlash-style parallel backbone that runs a single forward pass over a block and produces hidden states and base logits for each of k draft tokens.
• A lightweight sequential head, modeled as a Markov chain between neighboring tokens, that biases each position's logits toward continuations consistent with the token sampled just before it, which fixes the independence assumption that hurts DFlash's acceptance at later positions.
• A confidence-scheduled verifier: a separate head predicts each draft token's acceptance probability conditioned on all previous ones being accepted, and a hardware-aware scheduler prunes low-confidence suffixes whenever verifying them would cost more batch capacity than they're worth.

Each draft model lands around 295 to 328 million parameters, with embedding and LM head tied to the target rather than carried by the draft. The architecture settled on 5 layers with a block size of 9, using simplified attention-only draft models for this first version.

The speedup breakdown

Numbers were measured at batch size 1, temperature 0, with SGLang on a single H100 in BF16 and llama.cpp with Metal on an M4 Max using FP16 GGUF weights. The three models behave quite differently:

The most interesting result is on agent workloads. In agentic workloads the model reasons before every tool call, and the user waits through it all. That is where speculation pays most. Across various multi-tool scenarios on the Berkeley Function Calling Leaderboard, DSpark reduces latency by 57% on average for the 2.6B model on a MacBook. That is the difference between a tool-using assistant that feels laggy and one that feels immediate.

Where it struggles

The 8B mixture-of-experts model is the honest weak spot. While DSpark achieves a 2.54x throughput improvement on average on GPU, it gets only an 18% improvement on edge devices. Liquid attributes this to how MoE inference currently runs on llama.cpp's Metal backend: verifying k tokens activates more experts and thus more weight traffic than a single decode step. They're publishing the numbers as-is and flagging it for follow-up work.

Acceptance rates also vary heavily by task. For the 1.2B model there is much more variance in dataset acceptance rates, so speedup varies by as much as 52% depending on the distribution of the underlying text. Math and code accept longer drafts than open-ended chat.

Training notes

The recipe follows the DSpark paper with an expanded data mixture covering SFT, chat, code, and function-calling data. Each model and every ablation study was trained exclusively on AMD hardware using Liquid AI's training framework, specifically MI325x GPUs. They ran 15 epochs on the entire dataset for each draft model, and picked final checkpoints by acceptance rate rather than validation loss after finding that loss kept dropping on the larger drafts even after acceptance had plateaued.

Getting it running

The draft models are on Hugging Face as both Safetensors and GGUF. For GPU serving, the SGLang integration landed in PR #31041. Launching a server looks like this:

python -m sglang.launch_server \
  --model-path LiquidAI/LFM2.5-1.2B-Instruct \
  --speculative-algorithm DSPARK \
  --speculative-draft-model-path LiquidAI/LFM2.5-1.2B-Instruct-DSpark \
  --speculative-draft-attention-backend flashinfer \
  --disable-radix-cache --mem-fraction-static 0.75 --port 30000

For local inference, the llama.cpp integration is upstream, with experimental Metal kernels in a separate PR that unlock the reported device numbers. The models are open-weight under Liquid's LFM1.0 license, so you can fine-tune and deploy without asking permission.

The broader takeaway is that speculation is becoming standard equipment rather than a niche trick. When a 1.2B model on a laptop can serve 350 tokens per second while producing bit-for-bit identical outputs to its baseline, the interactivity ceiling for on-device agents just moved. The MoE gap on Metal is the caveat worth watching, but for dense models and GPU serving, there's little reason not to plug the drafter in.