Liquid AI released two LFM2.5 deployment optimizations on consecutive days: quantization-aware distillation (QAD) checkpoints on August 19, 2026, and DSpark draft models on August 20. Both promise faster local inference, but they attack different costs. QAD changes the model artifact so a 4-bit checkpoint keeps more of the full-precision model's quality. DSpark changes the decoding path so a small draft model proposes tokens that the target model verifies in batches.
That distinction matters because “local AI is slow” is not one diagnosis. If a model barely fits, QAD is the relevant lever. If it fits but generates too slowly, DSpark may help. Treating the releases as interchangeable—or assuming they can be stacked without testing—turns useful engineering tools into benchmark theater.
Two Bottlenecks, Two Mechanisms
Liquid AI's QAD release ships Q4_0 GGUF checkpoints for four LFM2.5 sizes: 230M, 350M, 1.2B-Instruct, and 2.6B. During training, a higher-precision teacher transfers behavior into a quantized student. The result remains a Q4_0 artifact, so the deployment benefit is about getting better quality from a compact representation rather than adding a second inference model.
DSpark is different. It adds a draft model of roughly 300 million parameters beside the target LFM2.5 model. The draft proposes several future tokens; the target verifies them together. With greedy decoding, accepted tokens preserve the target model's output. Performance depends on how many draft tokens survive verification and on whether the hardware can turn fewer target passes into lower latency.
The practical mapping is simple:
| Symptom | First lever to test | Why |
|---|---|---|
| The model does not fit comfortably in memory | QAD Q4_0 | It changes the target weights and storage footprint |
| A 4-bit model fits, but quality drops too far | QAD Q4_0 | It is trained to recover quality lost during quantization |
| The target fits, but decode throughput is poor | DSpark | It reduces target-model decoding work through accepted draft tokens |
| Tool calls are correct but too slow | DSpark | Liquid AI reports a dedicated function-calling latency evaluation |
| You need a predictable production upgrade | Benchmark both separately | Runtime support and workload-specific acceptance matter more than headline speedups |
What the QAD Numbers Actually Say
Liquid AI reports that its four QAD Q4_0 checkpoints retain between 96.5% and 97.4% of their respective BF16 baseline performance on its aggregate evaluation. The evaluation covers reasoning, instruction following, tool use, mathematics, and related tasks, with results averaged over repeated runs.
The more operational comparison is against other quantizations. For the 230M and 350M models, the company says QAD Q4_0 matches Q5_K_M quality within evaluation variance while decoding 4% to 33% faster. For the 1.2B and 2.6B models, it reports quality comparable to Q4_K_M with 3% to 14% higher throughput. Those are vendor measurements across a MacBook Pro, a NucBox, a Galaxy phone, and a Raspberry Pi—not a universal speed guarantee.
The model repository exposes QAD and conventional quantizations as distinct files. That makes an A/B test straightforward: keep prompts, context length, sampler settings, and runtime build fixed; swap only the GGUF artifact. Measure task quality, resident memory, prompt processing, and decode throughput separately. A faster decode result is not useful if your own structured-output or multilingual evaluation regresses.
What DSpark Changes—and What It Costs
DSpark's headline is larger: Liquid AI reports up to 3.18× throughput improvement on a GPU and up to 2.87× on-device. It also reports a 57% average reduction in function-calling latency for LFM2.5-2.6B. Those are best or averaged results from the company's test matrix, not promises for every prompt.
Acceptance rate explains the variability. The llama.cpp integration shows a laptop RTX 4070 example ranging from 1.33× to 3.22× across five prompt types. Code-oriented prompts accepted more draft tokens than explanation and summary prompts in that sample. The mean was 2.12×, which is useful, but the spread is the real lesson: speculative decoding is workload-sensitive.
DSpark also adds another model artifact and some memory use. If memory pressure is already the constraint, adding a draft model may be the wrong first move even when decode speed looks attractive. Conversely, a server with headroom and repetitive code or tool-call traffic may gain substantially.
Runtime Support Is Part of the Benchmark
The llama.cpp support pull request merged on August 20 with the DSpark path and partial rollback for LFM2 recurrent state. A user initially hit a crash because a packaged build predated the merged change; the maintainer advised building from source or waiting for a newer release. The user later confirmed that a newer build worked and reported a large speedup.
That sequence is a useful deployment warning. “Supported upstream” does not mean every package manager, desktop app, or container already contains the required commit. The official DSpark model card provides runtime examples, but teams should record the exact llama.cpp commit or release used in their test. SGLang support was still represented by an open pull request during this review, so treat it as integration work in progress rather than a stable release assumption.
Do not assume that a QAD target and DSpark draft are a validated pair. Liquid AI presents the techniques in separate releases, and its documented DSpark llama.cpp example uses full-precision target and draft files. The llama.cpp discussion also shows a failed attempt involving a QAD Q4_0 target before the user's runtime was updated, which does not establish whether that pairing is broadly supported or optimal. Test the documented configurations first.
A Five-Test Evaluation Plan
- Freeze the baseline. Record the exact model file, runtime commit, backend, context size, sampler settings, and concurrency.
- Measure the bottleneck. Separate load time, prompt evaluation, first-token latency, decode tokens per second, peak memory, and end-to-end task latency.
- Use representative work. Include your actual languages, tool schemas, context lengths, and response shapes. A poem benchmark cannot predict an agent loop.
- Score correctness before speed. For QAD, compare task accuracy and structured-output validity. For DSpark, verify output parity under the decoding mode you deploy.
- Inspect the tail. Report median and high-percentile latency. A higher average throughput can still hide slow requests when draft acceptance collapses.
Run QAD against a conventional quantization at the same nominal target size. Run DSpark against the same target without speculation. Only after both independent tests pass should you explore a combined configuration, and only if your runtime explicitly supports it.
Limitations and Caveats
Most published measurements come from Liquid AI, which built both optimizations. The hardware range is useful, but the workloads, runtime versions, and sampling settings may not match yours. Aggregate benchmark retention also compresses task-specific failures into one percentage.
DSpark's benefit varies with draft-token acceptance and can shrink on prompts unlike its training mix. QAD preserves more aggregate quality than ordinary Q4_0 in the reported evaluation, but it is still a 4-bit model. Neither technique removes the need to test tool-call syntax, long contexts, multilingual behavior, and failure cases on the exact application path.
The Bottom Line
QAD and DSpark are complementary ideas, not interchangeable products. Choose QAD when memory or 4-bit quality is the binding constraint. Choose DSpark when the target model already fits and decoding latency dominates. The strongest deployment decision is not the largest vendor multiplier; it is the smallest change that fixes the measured bottleneck on your hardware and workload.
