LFM2.5-2.6B-DSpark: The 328M Drafter That Makes Liquid's On-Device Agent Run 2.3× Faster

Nobody outside Liquid AI has run LFM2.5-2.6B-DSpark on their own hardware and published a number yet. That is the honest place to start with this model, because the entire thing is a performance claim: it is not a better 2.6B, it is a 328M-parameter draft model that sits in front of the 2.6B agentic model LFM2.5-2.6B and proposes tokens for it to verify, so the agent runs about twice as fast without changing its output.

Released August 20, 2026 with a technical write-up on Hugging Face and a companion post on Liquid's own blog, LFM2.5-2.6B-DSpark is the flagship of a small family of speculative-decoding drafter checkpoints Liquid published that day. Everything below in the speed column is vendor-measured and not yet independently confirmed; everything in the repo, the formats, and the framework support is simply there to be checked.

What DSpark is, in one breath

Speculative decoding is the trick of running a cheap draft model ahead of the real one: the drafter guesses the next handful of tokens, the target checks the whole batch in a single forward pass, and it keeps the tokens it agrees with. When the guesses are right you move several tokens for the price of one, so throughput climbs without touching the target's weights. DSpark — the technique, originally proposed by DeepSeek researchers in July 2026 and already deployed in DeepSeek-V4 — is a version of that trick tuned for small on-device models. Liquid calls it confidence-scheduled speculative decoding, and it has three moving parts: a parallel backbone that produces hidden states for all draft tokens in one pass, a lightweight sequential head that models dependency between neighboring tokens so the acceptance rate does not collapse late in the block, and a verifier that prunes low-confidence suffixes when checking them would cost more than it saves.

That last piece is what makes DSpark feel different from a plain drafter: it does not always push a full block through verification. When the draft's own confidence says a suffix is unlikely to be accepted, it cuts the block short and saves the wasted compute. The draft block is nine tokens, so the target verifies up to ten at a time.

The drafter, by the numbers

The LFM2.5-2.6B-DSpark checkpoint is a 0.3B-parameter, attention-only draft model: five full attention layers (hidden size 2,048, grouped-query attention with 32 heads and 8 key-value heads), a 128K-token vocabulary, a Markov head with rank 256, and a confidence head. Liquid trained it for 15 epochs on a mix of instruction, conversation, code, and function-calling data — on AMD hardware — and picked the epoch by the highest acceptance rate rather than the lowest loss.

That acceptance rate is the number that decides how much the drafter is worth. Across five benchmarks at batch size 1 and temperature 0, LFM2.5-2.6B-DSpark averaged 4.83 accepted tokens per decoding step on an H100 and 4.42 on an M4 Max — roughly half the block accepted, which is where the two-times speedups come from.

The speedups, labeled

All of the following figures come from Liquid AI's own measurement — SGLang on a single H100 80GB in BF16, and llama.cpp with the Metal backend on an M4 Max MacBook Pro in FP16 GGUF, batch size 1, temperature 0 — and none have been reproduced by an independent party as of this writing:

• H100 mean — 2.67×, from 323 to 864 tokens/s. By benchmark: MATH500 3.06×, HumanEval 2.56×, MBPP 2.64×, GSM8K 2.22×, MT-Bench 2.87×.

• M4 Max mean — 2.27×, from 61 to 139 tokens/s. By benchmark: MATH500 2.25×, HumanEval 2.63×, MBPP 2.11×, GSM8K 2.36×, MT-Bench 1.99×.

• Tool calling — in multi-tool function-calling scenarios, average latency dropped 57%.

• Family context — the largest drafter in the family, LFM2.5-8B-A1B-DSpark, hit up to 3.18× on H100 and the 1.2B drafter up to 2.87× on M4 Max; the 2.6B numbers above are the middle of the pack.

Two things about those numbers matter beyond the averages. First, they are measured at temperature 0 and batch size 1 — the config that favors speculation and the config that interactive on-device agent work mostly is. The identity guarantee also holds there: speculative decoding verifies every proposed token, so under greedy decoding the emitted text is exactly what the target would have produced alone. Second, the gap closes as concurrency rises: on a single H100, Liquid reports DSpark's advantage converging around batch size 128, so the drafter is a latency win for interactive and tool-heavy workloads, not a raw-throughput silver bullet for a maxed-out server.

What is confirmed, and what is not

Confirmed, in the sense that the repo is public and checkable: the drafter ships as Safetensors (BF16) and GGUF; it pairs with the post-trained LFM2.5-2.6B, not with the base; day-one support landed upstream in llama.cpp (with experimental Metal kernels) and in SGLang; it is licensed under Liquid's LFM Open License v1.0; and — important for anyone planning around it — the model card states that no inference provider serves it, so this is a run-it-yourself component.

Not yet confirmed: that the speedups reproduce on other hardware and configurations (nobody outside Liquid has published a measurement), how the drafter behaves under sampling rather than greedy decoding, and whether the 57% tool-call latency figure holds across real agent harnesses beyond the benchmark harness Liquid used. None of those are accusations — the release is a day old — but they are the difference between a promising number and a verified one.

Running it

In SGLang you use a build with DSpark support, launch the server against the target model, and name the drafter: the speculative algorithm is DSPARK, the draft model path points at LiquidAI/LFM2.5-2.6B-DSpark, and the block size is read from the draft's config.json. In llama.cpp you load the target GGUF with the draft GGUF as the draft model and set the spec type to draft-dspark, with the block size read from the sidecar metadata. Both integrations are upstreamed, so no forks are needed — just a build new enough to contain them.

When it is worth adding

LFM2.5-2.6B-DSpark earns its roughly 0.3GB of extra memory when you are actually deploying the 2.6B agent where Liquid designed it to live — on a phone, a laptop, or an edge box — for interactive or tool-calling workloads that are latency-bound and run greedy. That is precisely the profile where the 2.27× on-device figure and the 57% tool-call latency cut do the work. It is less interesting if you are serving at high batch on a server (the speedup converges toward 1×), or if your workload runs at temperature above zero, where the reported numbers stop applying. And if you are on the 8B-A1B variant of the family, note the edge case: its on-device speedup is only about 1.18× today, because verifying draft tokens activates more experts in llama.cpp's Metal backend — Liquid flags this as known.

Nothing about DSpark changes where the 2.6B agent runs — it is a self-host story by design, and it will sit alongside the hosted models you already call. That mix of a local drafter and a dozen API endpoints is exactly the kind of plumbing a routing layer exists to collapse: one API key across 200+ models, automatic failover when a provider degrades, and provider list prices passed through at 0% markup, so the local-versus-hosted cost comparison for a 2.6B-class agent stays legible instead of living in a spreadsheet.

The right way to read LFM2.5-2.6B-DSpark today is as a promising, vendor-measured, not-yet-independent speed claim attached to a real, downloadable, runnable checkpoint. If you deploy the 2.6B agent on-device, the drafter is cheap to try and easy to remove — add the two speculative flags to the SGLang command, keep greedy decoding, and measure against your own workload before you trust the 2.3×. The repo is there; the independent verification is the open item.