# Liquid’s LFM2.5 DSpark checkpoints make speculative decoding deployable in llama.cpp and SGLang Liquid AI has released small DSpark draft checkpoints for three LFM2.5 models with day-one llama.cpp and SGLang paths, turning speculative decoding into a downloadable deployment option rather than a serving-engine research feature. LFM2.5-DSpark adds roughly 300M-parameter draft models for LFM2.5 1.2B, 2.6B and 8B-A1B. Liquid reports large throughput gains on H100 and M4 Max, but the gains vary sharply by model and workload and current llama.cpp integration still has practical edge cases. - Status: Active - Published: 2026-08-22T22:55:34+12:00 - Updated: 2026-08-22T22:55:34+12:00 - Categories: Artificial Intelligence, Open Models, Inference & APIs - Tags: LFM2.5, Liquid AI, speculative decoding - Canonical HTML: https://beyondthe.news/dossiers/liquid-lfm2-5-dspark-speculative-decoding-llama-sglang ## What changed On August 20, Liquid AI released DSpark draft-model checkpoints for LFM2.5-1.2B-Instruct, LFM2.5-2.6B and LFM2.5-8B-A1B in Safetensors and GGUF form. Each draft model is roughly 296M–328M parameters and implements a DSpark-style parallel draft backbone with a lightweight sequential Markov head and confidence-based pruning. Liquid also published working paths for llama.cpp and SGLang. The target model verifies proposed tokens, so Liquid says greedy decoding preserves the target model's baseline output while reducing decoding work when enough draft tokens are accepted. ## Why it matters Speculative decoding is useful only when a builder can obtain a compatible draft model, run it in the serving stack they already use, and measure a real end-to-end speed gain. Liquid's release packages those pieces for three relatively small open LFM models instead of leaving teams to train their own drafter. That is particularly relevant to local and on-device inference where memory bandwidth, not arithmetic, often dominates token generation. The trade-off is workload sensitivity: Liquid's own results range from large gains to only an 18% average improvement for the 8B-A1B model on M4 Max, and community llama.cpp reports show that speculative paths still have integration and quantization edge cases that should be tested rather than assumed away. ## Three small draft checkpoints sit beside the target models Liquid released DSpark companions for LFM2.5-1.2B-Instruct, LFM2.5-2.6B and LFM2.5-8B-A1B. The draft models use five attention-only layers with a block size of nine plus a Markov head and confidence head, totaling about 296M parameters for the 1.2B target and about 328M for the two larger targets. Safetensors and GGUF artifacts are available, so builders do not need to reproduce the training recipe before evaluating the technique. ## The speed gains are real claims, not a universal constant Liquid measured batch-one greedy decoding on one H100 80 GB through SGLang and an M4 Max MacBook through llama.cpp/Metal. Its published results reach 3.18× on H100 and 2.87× on M4 Max for individual benchmark/model combinations. The 2.6B model averaged 2.67× on H100 and 2.27× on M4 Max across five datasets, while the 8B-A1B model averaged 2.54× on H100 but only 1.18× on M4 Max because of current MoE/Metal behavior. These are first-party measurements and acceptance rates vary with text distribution. ## Greedy output should match because the target verifies proposals The drafter proposes a block, but the target model remains the verifier. Liquid describes greedy output as identical to running the target alone because rejected proposals are replaced by the target's own token. That is an important property for adoption: the intended optimization changes how tokens are produced, not the target model's greedy decision rule. Builders should still regression-test their actual serving build; llama.cpp users have reported speculative-decoding divergence with some quantized targets, an issue not established as specific to Liquid's checkpoints. ## llama.cpp and SGLang make this deployable now, with boundaries Liquid documents `draft-dspark` usage in llama.cpp and the `DSPARK` speculative algorithm in SGLang. That makes local and server deployment accessible through familiar stacks. The integration is not equally mature for every embedding scenario: a recent llama.cpp issue notes that speculative decoding lives in the server/common layer and is not exposed through the core C API for in-process hosts, so language bindings that drive `llama_decode` directly may need their own orchestration. ## Key details - Liquid AI published LFM2.5-DSpark checkpoints on August 20, 2026. - Target models covered are LFM2.5-1.2B-Instruct, LFM2.5-2.6B and LFM2.5-8B-A1B. - Draft checkpoints are roughly 296M–328M parameters and are available as Safetensors and GGUF. - Liquid documents day-one deployment paths for llama.cpp and SGLang. - Vendor benchmarks use batch size 1, temperature 0, an H100 80 GB for SGLang and an M4 Max MacBook for llama.cpp/Metal. - Liquid reports up to 3.18× H100 throughput and 2.87× M4 Max throughput on individual tests; gains vary materially by model and dataset. - For LFM2.5-8B-A1B, Liquid reports only a 1.18× mean M4 Max speedup despite a 2.54× mean H100 speedup. - Liquid reports a 57% average function-calling latency reduction for LFM2.5-2.6B in its own multi-tool scenarios. ## Builder takeaways - Benchmark DSpark on your exact prompts, hardware, quantization and serving engine; acceptance rate and speedup are workload-dependent. - Compare total tokens per second and latency against the baseline target with identical decoding settings rather than relying on the largest published speedup. - Budget the draft checkpoint's memory overhead explicitly on edge devices even though it is small relative to the target model. - If output equivalence matters, regression-test greedy generations on the exact quantized build you plan to ship; do not assume every speculative implementation preserves behavior perfectly in every backend. - For llama.cpp embeddings that call the core C API directly instead of `llama-server`, verify whether your binding can expose speculative decoding before choosing these checkpoints. - Instrument draft acceptance (`draft_n` and `draft_n_accepted` in llama.cpp) so you can tell whether poor speedup comes from low acceptance or backend overhead. ## What to watch - Whether independent benchmarks reproduce Liquid's gains across other hardware and longer production prompts. - Whether llama.cpp exposes speculative decoding through its public core API for in-process hosts. - Resolution of quantized-target output-divergence reports in llama.cpp speculative paths. - More LFM2.5 targets, quantizations and serving backends receiving maintained DSpark checkpoints. - Whether SGLang and llama.cpp improve MoE speculative performance enough to close the M4 Max gap for LFM2.5-8B-A1B. ## Uncertainties - Liquid's performance and function-calling latency results are first-party benchmarks and may not generalize to other prompt distributions, batch sizes, hardware or quantizations. - A llama.cpp issue reports greedy-output divergence for some quantized speculative-decoding targets; it is not established as specific to Liquid's LFM2.5 checkpoints, but it is a reason to verify exactness in the intended build. - The llama.cpp core C API currently lacks a first-class speculative-decoding surface for some in-process users, according to an open community issue. ## Sources - [Up to 3.2x Faster Inference with LFM2.5-DSpark](https://huggingface.co/blog/LiquidAI/lfm25-dspark) — Liquid AI / Hugging Face · primary · 2026-08-20T00:00:00+12:00. Primary release for checkpoints, architecture, deployment commands and vendor benchmark methodology/results. - [Eval bug: Speculative decoding (draft-mtp / draft-dspark): greedy output diverges from vanilla on quantized targets](https://github.com/ggml-org/llama.cpp/issues/25618) — ggml-org/llama.cpp · community_issue · 2026-07-13T00:00:00+12:00. Open community report qualifying the assumption of exact greedy equivalence for some quantized speculative-decoding paths; not shown to be Liquid-specific. - [Library (in-process) hosts cannot use speculative decoding / DSpark — no core C-API for draft/spec params](https://github.com/ggml-org/llama.cpp/issues/27089) — ggml-org/llama.cpp · community_issue · 2026-08-14T00:00:00+12:00. Documents a current integration limitation for in-process llama.cpp hosts using the public C API.