Beyond the News
Sign in
Artificial IntelligenceOpen ModelsInference & APIs Active dossier

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.

Reviewed and published by Lars Jansen Updated 6 min read
First published

Key details

  1. Liquid AI published LFM2.5-DSpark checkpoints on August 20, 2026.
  2. Target models covered are LFM2.5-1.2B-Instruct, LFM2.5-2.6B and LFM2.5-8B-A1B.
  3. Draft checkpoints are roughly 296M–328M parameters and are available as Safetensors and GGUF.
  4. Liquid documents day-one deployment paths for llama.cpp and SGLang.
  5. Vendor benchmarks use batch size 1, temperature 0, an H100 80 GB for SGLang and an M4 Max MacBook for llama.cpp/Metal.
  6. Liquid reports up to 3.18× H100 throughput and 2.87× M4 Max throughput on individual tests; gains vary materially by model and dataset.
  7. For LFM2.5-8B-A1B, Liquid reports only a 1.18× mean M4 Max speedup despite a 2.54× mean H100 speedup.
  8. Liquid reports a 57% average function-calling latency reduction for LFM2.5-2.6B in its own multi-tool scenarios.

What builders should take away

  1. Benchmark DSpark on your exact prompts, hardware, quantization and serving engine; acceptance rate and speedup are workload-dependent.
  2. Compare total tokens per second and latency against the baseline target with identical decoding settings rather than relying on the largest published speedup.
  3. Budget the draft checkpoint's memory overhead explicitly on edge devices even though it is small relative to the target model.
  4. 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.
  5. 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.
  6. 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 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.

What to watch next

  • 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.

Still unclear

  • 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

Direct reading behind this dossier.

3 sources
Continue reading
Artificial Intelligence

Meta’s Muse Glimmer puts a 30B multimodal agent model on 24GB-class hardware

Meta’s Muse Glimmer 30B combines tool use, coding, vision and agentic task completion with official local-runtime artifacts. A 17GB GGUF build targets 24GB-VRAM machines, but Meta also attaches a separate usage policy, so builders should distinguish weight availability from unrestricted use.

Artificial Intelligence

Qwen3.8-27B brings stronger agentic coding into a locally deployable 27B model

Qwen3.8-27B is now available as open weights on Hugging Face and ModelScope. For builders, the important change is not another benchmark bump: a comparatively compact 27B model now combines native vision, long context, controllable reasoning and OpenAI-compatible serving paths for local or self-hosted coding and agent workloads.