Liquid AI Adds QAD Quantization and DSpark Speculation to LFM2.5

Liquid AI released two complementary inference optimizations for LFM2.5

Liquid AI published two closely related LFM2.5 updates on August 19 and August 20, 2026. One attacks the quality loss that comes from aggressive 4-bit quantization; the other attacks autoregressive decoding latency.

The first release uses Quantization-Aware Distillation (QAD) to train updated Q4_0 checkpoints for LFM2.5-230M, 350M, 1.2B-Instruct and 2.6B.

The second releases DSpark speculative-decoding draft models for LFM2.5-1.2B-Instruct, 2.6B and 8B-A1B, with integrations available in llama.cpp and SGLang.

Both sets of checkpoints are available on Hugging Face. Performance and quality figures below come from Liquid AI's own evaluations and should be treated as vendor-reported until independently reproduced across more workloads and hardware.

QAD tries to make fast 4-bit checkpoints lose less quality

Traditional post-training quantization compresses a trained model after the fact. It is fast and convenient, but lower-bit formats can lose accuracy because the model was not optimized for the quantized representation.

Liquid AI's QAD approach instead distills a high-precision teacher into a student that is trained while accounting for the 4-bit target format.

The company released updated Q4_0 GGUF checkpoints for four LFM2.5 sizes. Liquid says the models retain roughly 97% of their BF16 average performance across its aggregate benchmark setup while preserving the low memory footprint and throughput characteristics of Q4_0.

Its benchmark suite includes reasoning, instruction following, tool use and agent-oriented tests such as GPQA Diamond, MMLU-Pro, IFEval, IFBench, Multi-IF and BFCLv4.

Liquid also reports that its QAD Q4_0 models match or approach higher-quality quantization formats on several evaluated sizes while remaining smaller or faster. These comparisons depend on model size, runtime, hardware and benchmark mix, so users should test the exact deployment configuration that matters to them.

The edge-hardware scope is unusually broad

Liquid measured QAD checkpoints across devices including an Apple M5 Max MacBook Pro, AMD Ryzen AI Max+ 395 hardware, a Samsung Galaxy S26 Ultra and Raspberry Pi 5.

That breadth is important because 'edge AI' is not one hardware class. A quantization format that performs well on a laptop GPU may behave differently on an Arm CPU or small single-board computer due to kernels, memory bandwidth and runtime support.

The release therefore reinforces a useful deployment principle: model quality, file size and decode speed should be evaluated together on the target device rather than inferred from parameter count alone.

DSpark attacks decode latency with a trained draft model

One day after the QAD release, Liquid released DSpark draft checkpoints for three LFM2.5 models.

Speculative decoding uses a smaller or specialized draft model to propose multiple future tokens. The main model verifies those proposals, potentially accepting several tokens at once instead of performing a full expensive forward pass for every single output token.

Liquid describes DSpark as confidence-scheduled speculative decoding with semi-autoregressive generation. The company reports up to 3.18x throughput improvement on GPU and up to 2.87x on-device in its tests, with a small additional memory requirement.

The key claim is that speculative decoding changes how quickly the base model's output is produced rather than intentionally changing the output distribution. In practice, integration details and verification rules matter, so teams should validate deterministic behavior, latency tails and memory usage in their own serving stack.

llama.cpp and SGLang support makes the release more deployable

Liquid says its LFM-compatible DSpark integration is open-sourced upstream in llama.cpp and SGLang.

That matters because a research acceleration method is far more useful when it lands in runtimes that developers already use. llama.cpp has a large local and edge deployment ecosystem, while SGLang is commonly used for high-performance model serving.

The release is also a reminder that inference optimization is becoming a co-design problem. The model weights, quantization method, draft architecture, runtime kernels and target device all influence real performance.

QAD and DSpark optimize different bottlenecks

The two releases should not be confused. QAD focuses on recovering quality lost when compressing a model into a fast 4-bit format. DSpark focuses on reducing the number of expensive sequential decoding steps through speculation.

They can therefore be thought of as complementary directions: make each stored model more memory-efficient without giving up as much quality, then make token generation require fewer full-model steps.

For edge developers, that combination is especially attractive because local devices face both memory constraints and latency limits. But vendor headline speedups are not universal. Prompt length, generation length, acceptance rate, batch size, hardware, quantization and runtime version can all change the outcome.

The most useful next step is to benchmark the exact checkpoint and runtime on the intended device, comparing quality, peak memory, first-token latency, decode throughput and energy—not just one headline metric.