Liquid AI DSpark Speeds LFM2.5 Decoding Up to 3.18x

Liquid AI has released LFM2.5-DSpark draft checkpoints that add speculative decoding to three LFM2.5 models. In the supplied MarkTechPost report, the release is reported at up to 3.18x faster decoding on an H100 and up to 2.87x on an M4 Max MacBook Pro, while greedy-decoded output remains unchanged. The practical story is not a new target model; it is a faster way to run the same one.

The official Liquid AI announcement frames LFM2.5-DSpark as a first public release of speculative-decoding models for Liquid Foundation Models. The checkpoints are aimed at developers who self-host LFM2.5 inference, especially single-user and agentic workloads where decode latency is visible to the person waiting for the next tool call. More on this: LFM2.5-2.6B makes local agents practical on edge devices.

Definition: LFM2.5-DSpark is a small draft-model family that proposes several tokens for an LFM2.5 target to verify in one pass.

Example: A roughly 300M-parameter drafter proposes a block of nine tokens, and the larger target keeps the matching prefix while correcting the first mismatch.

Key takeaway: DSpark changes the decoding path, not the target model's greedy output sequence.

Business impact: Faster decode can make locally hosted assistants and tool-using agents feel more responsive without retraining the target model.

What did Liquid AI release?

Liquid AI released three matching drafter checkpoints for LFM2.5-1.2B-Instruct, LFM2.5-2.6B, and LFM2.5-8B-A1B. The drafter sizes are 295.7M parameters for the 1.2B-Instruct target and 327.7M for the 2.6B and 8B-A1B targets, according to Liquid AI's release materials. Developers should treat each drafter as an add-on to its named target, not as a standalone language model, and download the matching pair before testing throughput.

LFM2.5-DSpark is a speculative-decoding release rather than a replacement checkpoint. The target model still performs the authoritative verification, while the draft model proposes a block of tokens after the current context. That distinction matters for operators: the potential gain comes with extra memory and runtime integration, so the correct comparison is a target-only deployment against the same target with its matching drafter attached.

How does DSpark preserve output quality?

LFM2.5-DSpark preserves the target model's greedy sequence because the target model verifies every proposed token before it is emitted. When a proposal matches, the target accepts it; when a proposal fails, the target supplies its own token and discards the suffix behind the first mismatch. This exact verification rule means developers can test latency without treating the drafter as an unverified second model.

The quality guarantee has a defined boundary: it is stated for greedy decoding, not as a promise that every sampling configuration will produce byte-for-byte identical text. The DSpark paper describes the broader method as confidence-scheduled speculative decoding with a semi-autoregressive draft, so teams should benchmark their own sampling, prompts, and stopping rules before production rollout.

Why can speculative decoding be faster?

Speculative decoding can be faster when a target model verifies several accepted tokens in one forward pass instead of streaming one token at a time. Liquid AI describes decode as largely memory-bound: the target repeatedly moves weights from memory into faster on-chip storage, so reusing one weight-loading pass across a verified block can improve tokens per second. The takeaway for an inference operator is to measure accepted tokens per target pass, not only the draft model's parameter count.

DSpark combines a DFlash-style parallel backbone, a lightweight sequential Markov head, and a confidence-scheduled verifier. The parallel backbone proposes positions together, the sequential head adds dependencies between neighboring draft tokens, and the verifier can trim low-confidence suffixes when checking them would cost more than it saves. Those components explain why DSpark is more than simply attaching a smaller autoregressive model to an LFM2.5 target.

Which benchmarks show the largest gains?

Liquid AI measured LFM2.5-DSpark at batch size 1 and temperature 0 on five datasets: MATH500, HumanEval, MBPP, GSM8K, and MT-Bench. The H100 measurements used BF16 with SGLang, while the M4 Max measurements used FP16 GGUF weights with llama.cpp and Metal. The table below reports the published means and the strongest individual cases; treat them as release measurements, not a universal speed guarantee.

The results show that acceptance rate is the main operational variable. LFM2.5-8B-A1B accepted 8.27 of 10 tokens per step on MATH500 and 4.02 on GSM8K in the H100 measurements, while its speedup moved from 3.18x to 1.29x. Operators should therefore test representative prompts and datasets instead of carrying the headline maximum into capacity planning.

Where does LFM2.5-DSpark fit local inference?

LFM2.5-DSpark is available for self-hosted inference in Safetensors and GGUF formats, with day-one support in compatible llama.cpp and SGLang builds. The LFM2.5-8B-A1B-DSpark model card lists the 327.7M-parameter drafter, its five-layer attention backbone, and the required target-model pairing. Developers should confirm the exact runtime support and memory footprint before treating a checkpoint as deployable.

The release is especially relevant to laptop-class and on-device deployments, but the hardware caveat is material. Liquid AI reports only a 1.18x average gain for LFM2.5-8B-A1B on the M4 Max, attributing the result to the current MoE implementation in llama.cpp's Metal backend and the extra expert weight traffic during multi-token verification. Teams comparing local options can use Yowox's Local LLM Hardware Calculator to check model-and-memory fit, then measure DSpark on their actual runtime.

Why does DSpark matter for AI agents?

LFM2.5-DSpark has a direct agentic use case because an AI agent may decode a plan before every function call and then decode again after the tool returns. Liquid AI reports a 57% average latency reduction for multi-tool function-calling scenarios with LFM2.5-2.6B. That result is a vendor-reported measurement on its tested setup, so an operator should replay its own traces rather than assume every agent loop will achieve the same reduction.

This makes DSpark an inference-layer optimization for the broader system described in Yowox's AI automation stack explainer. The model remains one layer alongside orchestration, tools, permissions, and monitoring; speeding decode cannot repair a slow API, an unclear approval policy, or an unreliable tool call. For a basic explanation of the behavior DSpark can accelerate, see what an AI agent does.

What should operators test next?

Operators evaluating LFM2.5-DSpark should start with a matched target-and-drafter pair, the same prompts, and the same decoding settings used for the baseline. Measure tokens per second, accepted tokens per step, peak memory, first-token latency, end-to-end tool-call latency, and output equality under the intended decoding mode. These measurements reveal whether the extra draft weights pay for themselves on the chosen hardware.

The release's strongest signal is therefore conditional rather than universal: DSpark can make LFM2.5 materially faster when the workload accepts long draft prefixes and the runtime handles verification efficiently. The H100 results reach 3.18x, the 2.6B target averages 2.27x on the M4 Max, and the 8B-A1B MoE case averages only 1.18x there. The right next step is a workload-specific benchmark, not a blanket assumption that every LFM2.5 deployment will become three times faster.