LFM2.5 DSpark and QAD: Faster Decode, Better 4-bit

What Liquid AI released: faster decoding and 4-bit GGUF

The DSpark release is a set of draft models for faster decoding, and the QAD release is a set of 4-bit GGUF files that recover accuracy lost to quantization. Liquid AI published one post for each in August 2026.

DSpark adds a speculative decoding path: a small draft model plus a verification step. Liquid AI says it trades a minimal increase in memory for a large decoding speedup, with no change in output quality. The post calls it the first public release of speculative decoding models for Liquid Foundation Models.

The QAD post describes quantization-aware distillation, where a high-precision teacher model is distilled into a quantized student. The result stays a Q4_0 GGUF file, so its memory footprint and throughput match plain Q4_0. The table below shows which sizes each release covers, as listed in the two posts.

LFM2.5 sizes covered by each release

Model size	DSpark draft model	QAD Q4_0 checkpoint
230M	No draft in the post	Yes
350M	No draft in the post	Yes
1.2B-Instruct	Yes	Yes
2.6B	Yes	Yes
8B-A1B	Yes	No checkpoint in the post

Only 1.2B-Instruct and 2.6B appear in both columns. The 230M and 350M sizes get only a QAD checkpoint, and 8B-A1B gets only a DSpark draft.

Draft model checkpoints for three LFM2.5 sizes

DSpark drafts exist for LFM2.5-1.2B-Instruct, LFM2.5-2.6B and LFM2.5-8B-A1B. They are on Hugging Face as Safetensors (for example, LFM2.5-2.6B-DSpark) and as GGUF (LFM2.5-2.6B-DSpark-GGUF). The post says the model cards explain how to run them.

Liquid AI open-sourced the LFM-compatible DSpark integration upstream in llama.cpp and SGLang. Both supported it from day one. llama.cpp is the route for edge devices, and SGLang is the route for GPU serving.

The llama.cpp numbers in the post came from experimental Metal kernels, which the post links as a pull request. DSpark itself is not Liquid AI's method: the post credits it to Cheng et al. (2026) and says Liquid AI followed that recipe, with a wider data mixture, to train its own drafts for LFM2.5.

Quantization-aware distillation for four Q4_0 sizes

QAD Q4_0 files exist for four sizes: 230M, 350M, 1.2B-Instruct and 2.6B. They are GGUF files on Hugging Face, and a QAD file has the same GGUF format, tensor layout and runtime path as a Q4_0 file made by post-training quantization (PTQ, quantizing a model after training is finished). It therefore runs at the speed of native Q4_0.

For each size, Liquid AI compares the PTQ GGUFs it had already released against the QAD Q4_0 file. The BF16 GGUF, a higher-precision file in the same format, is the upper bound. The QAD post names no 8B-A1B checkpoint.

How DSpark speculative decoding leaves output unchanged

Most decoding latency comes from loading weights from memory, and speculative decoding shares that cost across several tokens. In LLM inference, the decode phase is memory-bound: time goes mostly to moving model weights from DRAM into SRAM, not to arithmetic. The post says this holds for a GPU such as the NVIDIA H100 and for edge devices such as a MacBook or an iPhone.

Speculative decoding adds a small draft model that proposes candidate tokens. The large target model then checks all of them in a single forward pass, so the cost of loading its weights is shared by every token it checks. The post names EAGLE-3 and DFlash as the best-known earlier approaches and DSpark as the most recent.

Three parts of the draft model and its 300M size

Each draft has around 300M parameters and three parts. The post describes the parts as follows:

• A parallel backbone in the style of DFlash. It reads context features from the target model and, in one forward pass over a block, produces hidden states and base logits for each drafted token.
• A light sequential head modeled as a Markov chain between neighboring tokens. It pushes each position toward continuations that fit the token sampled just before it. This adds dependency between drafted tokens, which the DFlash approach lacks, and raises the acceptance rate at later positions.
• A confidence-scheduled verifier. A separate head predicts how likely each draft token is to be accepted. A hardware-aware scheduler then prunes low-confidence tails when verifying them would cost more batch capacity than they are worth.

In its own tests, Liquid AI served a fixed verify window instead of using this trimming, because the tokens the confidence head drops cost more than the compute it saves. The SGLang concurrency tests later in the post therefore ran without the confidence-scheduled verifier.

Liquid AI trained on a mix of supervised fine-tuning (SFT), chat, code and function-calling data. Ablation runs, which change one setting at a time on a subset of the data, covered layer count, block size and model architecture, and the first version of the drafts used simplified attention-only models. The final setting is 5 layers with block size 9, and each draft was trained for 15 epochs on the full dataset.

All training and ablations ran on AMD hardware with Liquid AI's own training framework. The published checkpoint for each draft is the epoch with the highest acceptance rate, not the lowest validation loss.

For 1.2B-Instruct, acceptance rises with each epoch and tracks the fall in loss. For 2.6B, acceptance flattens well before the loss does. The 8B-A1B draft is the least stable: its loss keeps falling with more tokens, but acceptance does not improve.

DSpark draft model size by component

Component	1.2B-Instruct	2.6B	8B-A1B
Decoder stack (5 layers)	241.2M	241.2M	241.2M
Hidden-state projection	21.0M	21.0M	21.0M
Markov head	33.6M	65.5M	65.5M
Norms + confidence head	27.5k	27.5k	27.5k
Total	295.7M	327.7M	327.7M

Among the three drafts, only the Markov head differs in size. The embedding layer and output (LM) head are tied to the target model, so the drafts do not carry them.

Why speculative decoding gives identical greedy output

With DSpark under greedy decoding, the output is identical to the target model's own greedy output by construction. A draft token is accepted only if it matches the target model's distribution, and a rejected one is replaced by the target model's own token. Benchmark scores such as pass@1 and exact match therefore do not change.

Every number in the post was measured at temperature 0, and the guarantee applies to greedy decoding. The post publishes no result for sampled decoding.

DSpark speedups on an H100 with SGLang and a MacBook

DSpark speeds up all three models on both an H100 and an M4 Max MacBook, but the gain is only 1.18x for 8B-A1B on the MacBook. Liquid AI ran the per-model speed measurements with block size 9, batch size 1, temperature 0 and up to 256 output tokens, on five datasets: MATH500, GSM8K, HumanEval, MBPP and MT-Bench. Speedup means DSpark throughput divided by the same model's throughput without it.

GPU numbers come from SGLang on a single H100 80 GB in BF16. On-device numbers come from llama.cpp with Metal on an M4 Max MacBook Pro, using FP16 GGUF weights and the experimental Metal kernels. Each headline figure comes from a single table cell.

The 3.18x is LFM2.5-8B-A1B on MATH500 on the H100, and the post's title rounds it to 3.2x. The 2.87x is LFM2.5-1.2B-Instruct on HumanEval on the M4 Max.

Mean speedup by model on H100 and M4 Max

Mean speedups run from 1.18x to 2.67x, and the lowest is LFM2.5-8B-A1B on the MacBook. The chart shows each model's mean speedup on the two machines, with the change in tokens per second under the model name.

Mean DSpark speedup by model

H100 with SGLang (BF16)

Bar height is relative to the largest speedup in the figure, 2.67x, set to 100.

2.10x1.2B-Instruct (656 to 1384 tok/s)

2.67x2.6B (323 to 864 tok/s)

2.54x8B-A1B (418 to 1074 tok/s)

012x

M4 Max with llama.cpp Metal (FP16 GGUF)

Same scale as the H100 chart.

2.54x1.2B-Instruct (138 to 350 tok/s)

2.27x2.6B (61 to 139 tok/s)

1.18x8B-A1B (90 to 106 tok/s)

012x

Acceptance is reported out of 10, and it does not map one-to-one to speedup. 8B-A1B has the highest mean acceptance, 6.95, against 5.02 for 1.2B-Instruct and 4.81 for 2.6B, yet the smallest MacBook gain. For 2.6B, Liquid AI says the MacBook's roughly 140 tok/s (the exact figure varies by dataset) is far above what most proprietary cloud models deliver.

LFM2.5-1.2B-Instruct is a non-reasoning model, and its acceptance varies more across datasets than 2.6B's. On the H100 its speedup runs from 1.66x on MT-Bench to 2.56x on MATH500. The post says the speedup varies by as much as 52% with the type of text.

LFM2.5-8B-A1B gets only 1.18x from llama.cpp Metal

LFM2.5-8B-A1B gets a mean of 1.18x on the MacBook, against 2.54x on the H100. It is a thinking model, and its acceptance is higher than that of 1.2B-Instruct and 2.6B, but the MacBook speedup does not follow. The post describes the 1.18x as an 18% improvement, and per dataset it runs from 1.04x on MT-Bench to 1.44x on GSM8K.

The post attributes the gap to two things. The first is how llama.cpp's Metal backend currently handles mixture-of-experts (MoE) models, which send each token through only some of their weight blocks (the experts); the second is that verifying k draft tokens activates more experts, and so moves more weights, than one decode step does. Liquid AI says it will address this in later work and that it published the numbers for transparency.

Agentic latency drops 57% on BFCL function calling

DSpark cuts latency by 57% on average across multi-tool scenarios on BFCL, the Berkeley Function Calling Leaderboard dataset. Liquid AI's main goal for LFM2.5-2.6B was to make it the first viable on-device agentic model.

In an agentic workload the model reasons before every tool call, and the user waits through all of it. Liquid AI ran the function-calling test on an M4 Max MacBook Pro with FP16 GGUF weights at batch size 1 and temperature 0.

How batch size and concurrency change the gain

DSpark keeps its lead at higher concurrency for 1.2B-Instruct and 8B-A1B, while for 2.6B the two converge around batch size 128. The post also tests serving many users at once, which it calls interactivity. All of these runs used SGLang on a single H100, without the confidence-scheduled verifier.

As concurrency rises, the workload moves from memory-bound toward compute-bound, where arithmetic rather than memory traffic limits speed. The extra draft tokens the target model must verify add to that compute load, and together these effects close the gap between DSpark and the baseline. The result differs by model:

• 2.6B: DSpark and the baseline converge around batch size 128 at block size 9, depending on the task mix.
• 1.2B-Instruct: DSpark is still clearly ahead at batch size 128.
• 8B-A1B: DSpark beats the base model on every dataset and concurrency level tested, even on lower-acceptance datasets such as GSM8K.

The post explains the 8B-A1B result this way: batching and speculation activate the same larger part of the model. At high concurrency the baseline pays that cost too, so the overhead stops counting against speculation.

QAD 4-bit accuracy against BF16, Q5_K_M and Q4_K_M

Every QAD checkpoint ends up at roughly 97% of its BF16 average, and the post compares the files against the 5-bit Q5_K_M and 4-bit Q4_K_M formats. Liquid AI scores each file on six benchmarks: GPQA Diamond, MMLU-Pro, IFEval, IFBench, Multi-IF and BFCLv4. They cover reasoning, instruction following, tool use and agentic skills.

Each model also gets one math test suited to its size: GSM8K for 230M and 350M, and AIME25 for 1.2B-Instruct and 2.6B. Scores are averaged over five runs.

Recovery is the share of the quality drop from BF16 to Q4_0 that QAD wins back. The baseline is the PTQ GGUF Liquid AI had already released, and the BF16 GGUF is the upper bound.

How much of the BF16 gap QAD closes at each size

QAD closes 48.4% to 73.4% of the BF16-to-Q4_0 gap, and the checkpoints retain 96.5% to 97.4% of BF16. The charts give both measures for each size.

QAD recovery against the BF16 baseline

Share of the BF16-to-Q4_0 gap closed

Bars are on a 0 to 100 percent scale.

70.6%230M

73.4%350M

65.5%1.2B-Instruct

48.4%2.6B

0204060%

Share of BF16 performance retained

Bars are on a 0 to 100 percent scale.

97.1%230M

96.5%350M

97.4%1.2B-Instruct

96.6%2.6B

0255075%

The post says recovery is generally strongest in the smaller models, where PTQ Q4_0 loses more quality in relative terms. The 2.6B model closes the smallest share of its gap, 48.4%, and retains 96.6% of BF16.

Q4_0 against Q4_K_M and Q5_K_M on quality and speed

QAD Q4_0 matches Q5_K_M at 230M and 350M, comes within half a point at 1.2B, and outscores Q4_K_M. Without QAD, Q4_0 is the weakest 4-bit format on quality and the fastest across Liquid AI's backends, and QAD targets exactly that trade-off. The match at 230M and 350M is within run-to-run variance, and QAD Q4_0 stays smaller and faster than Q5_K_M. The post calls Q4_K_M the standard 4-bit option, and says QAD Q4_0 matches Unsloth's UD-Q4_K_XL, a third-party post-training quantization checkpoint it calls strong.

Because a QAD file and a native Q4_0 file share the same format, the throughput figures for native Q4_0 apply to QAD Q4_0 as well. Liquid AI measured llama.cpp decode throughput on four backends:

• MacBook Pro with an Apple M5 Max, running on the GPU
• NucBox EVO-X2 with an AMD Ryzen AI Max+ 395, running on the GPU
• Samsung Galaxy S26 Ultra with a Qualcomm Snapdragon 8 Elite Gen 5, running on the Arm CPU
• Raspberry Pi 5 with a Broadcom BCM2712, running on the Arm CPU

On the first three devices, each run generates 100 tokens after a 256-token prompt. On the Raspberry Pi 5, the 230M, 350M and 1.2B models get a shorter run that decodes only 32 tokens and skips the prompt-processing (prefill) step.

LFM2.5 DSpark and the QAD checkpoints are separate releases for the same family, and they overlap only at 1.2B-Instruct and 2.6B. The DSpark speedups were measured on FP16 GGUF weights on the MacBook and BF16 weights on the H100, so neither post tells you what happens when you pair a DSpark draft with a QAD Q4_0 file. The 2.6B model itself is covered in Liquid AI LFM2.5-2.6B: Fast Agents, Not for Coding.