Liquid AI has released DSpark draft checkpoints for the LFM2.5 family—specifically for the 1.2B‑Instruct, 2.6B, and 8B‑A1B variants. Each drafter, roughly 300 M parameters, proposes a block of nine candidate tokens in a single forward pass; the larger target model then verifies the entire block. Because the drafter only adds a speculative path and does not alter the target’s weights, the generated sequence under greedy decoding remains identical to that of the target model alone, preserving benchmark accuracy.
The drafter architecture consists of five full‑attention layers with hidden_size = 2048, intermediate_size = 6144, grouped‑query attention (32 query heads over 8 KV heads), and a block size of 9. It employs a DFlash‑style parallel backbone conditioned on the target’s context features, a lightweight sequential head modeled as a rank‑256 Markov chain to capture inter‑token dependency, and a confidence‑scheduled verifier that prunes low‑confidence suffixes when verification cost outweighs benefit. The drafter shares the target’s embedding and LM head at load time, adding approximately 655 MB of BF16 memory for the 2.6B variant. Day‑one support is provided in llama.cpp and SGLang, with weights distributed as Safetensors and GGUF for self‑hosted deployment.
- Parameter counts: drafter ≈295.7 M (1.2B target) and ≈327.7 M (2.6B/8B targets)
- Reported speedups: up to 3.18× on H100 (BF16, SGLang) and 2.87× on M4 Max MacBook Pro (FP16 GGUF, llama.cpp)
- Acceptance‑rate‑dependent throughput: LFM2.5‑8B‑A1B achieves 8.27/10 tokens on MATH500 (3.18×) vs. 4.02/10 on GSM8K (1.29×); 1.2B model yields 1.66× on MT‑Bench (acceptance 3.90)
- Apple‑silicon MoE limitation: average gain ≈1.18× on M4 Max due to expert activation overhead in llama.cpp’s Metal backend
- Multi‑tool function‑calling latency: average 57% reduction for LFM2.5‑2.6B across agent‑style workflows
Why this matters
DSpark demonstrates that modest, task‑agnostic drafters can yield substantial inference speedups without retraining or altering model outputs, offering a practical trade‑off between memory footprint and latency. The variability of gains—tied to output predictability and hardware‑specific expert activation—highlights the importance of matching speculative decoding to workload characteristics, especially for reasoning‑heavy agent loops where repeated decoding steps dominate latency. This approach provides a portable optimization path for heterogeneous deployments, contingent on the availability of compatible inference backends.
Share this article
Found this insightful? Share it with your community on Reddit, X, or copy the link.
