Liquid AI Releases DSpark Draft Models for LFM2.5 Family

Liquid AI has announced the release of new DSpark draft model checkpoints designed to accelerate inference across three distinct architectures within its LFM2.5 model family, specifically covering the LFM2.5-1.2B-Instruct, LFM2.5-2.6B, and LFM2.5-8B-A1B variants. This release introduces a specialized speculative decoding pipeline that trades a minimal increase in memory usage for substantial gains in token generation speed without altering the final output quality of the base models.

During standard large language model execution, the decoding phase is typically bound by memory constraints rather than raw computational intensity. The primary bottleneck stems from the necessity of streaming model weights continuously from dynamic random-access memory into static random-access memory for every single token produced. Speculative decoding mitigates this limitation by employing a smaller, highly efficient draft model to generate a sequence of candidate tokens. The larger target model then verifies these proposed tokens in a single consolidated forward pass, effectively amortizing the heavy cost of weight loading across multiple accepted tokens simultaneously.

While several speculative architectures have emerged over recent years, including EAGLE-3 and DFlash, the engineering team adopted the DSpark recipe due to its specific combination of components. The newly trained drafters follow an attention-only architecture consisting of five layers and a block size of nine, utilizing roughly three hundred million parameters each. Training involved a diverse data mixture encompassing supervised fine-tuning, conversational text, code generation, and function-calling tasks over fifteen epochs, with checkpoint selection prioritized by token acceptance rate rather than lowest loss.

Because the speculative mechanism operates under greedy decoding rules where any rejected token is immediately replaced by the target model's own calculation, the resulting output sequence remains mathematically identical to standard execution. Consequently, standard evaluation metrics such as pass at one and exact match scores remain entirely unchanged. Day one integration support has been rolled out for both llama.cpp, utilizing experimental metal kernels, and SGLang through official implementation pull requests.

Performance evaluations conducted on varied hardware setups demonstrate significant throughput improvements across both large scale enterprise accelerators and local consumer devices. Tests utilizing an M4 Max MacBook Pro running FP16 GGUF weights alongside an NVIDIA H100 GPU running BF16 configurations highlighted major acceleration. For instance, the LFM2.5-2.6B configuration achieved speedups reaching up to 3.2x, bringing local interactive generation rates far beyond standard cloud offerings. Multi-task scenarios similarly showed latency reductions averaging fifty seven percent for that specific model.

However, performance gains varied depending on the underlying architecture and hardware backend. The LFM2.5-1.2B-Instruct variant exhibited notable variance in dataset acceptance rates, leading to speedup fluctuations of up to fifty two percent. Meanwhile, the mixture-of-experts LFM2.5-8B-A1B model achieved an on device improvement of only eighteen percent despite having higher acceptance rates, a limitation attributed to current mixture-of-experts backend implementations where verifying multiple tokens triggers a higher volume of active expert weights.

Developers can immediately access the new Safetensors and GGUF checkpoints directly through Hugging Face. Utilizing the checkpoints requires specific build versions of either llama.cpp or SGLang with integrated speculative decoding flags, allowing teams to seamlessly deploy the accelerated pipelines across both edge computing environments and high throughput data centers.