LFM2.5-DSpark: Up to 3.2x Faster Local AI

• Released 20 August 2026: three free draft models accelerating Liquid AI's LFM2.5-1.2B-Instruct, LFM2.5-2.6B and LFM2.5-8B-A1B models via speculative decoding, each roughly 300 million parameters.
• Lossless by construction: under greedy decoding, a draft token is only kept if it exactly matches what the full target model would have produced anyway - output quality is unchanged, only speed.
• Real, but uneven, speedups: Liquid's own numbers show a 2.67x mean speedup for LFM2.5-2.6B on an H100 GPU (peaking at 3.06x on MATH500) and 2.27x on an Apple M4 Max, with the smallest and largest models in the family showing different patterns again.
• Mixture-of-Experts is the weak point: LFM2.5-8B-A1B gained 2.54x on H100 but only 1.18x on Apple Silicon, because llama.cpp's Metal backend does not yet optimise MoE speculative decoding well.
• A concrete real-world win: on the BFCL v3 function-calling benchmark, LFM2.5-2.6B with DSpark cut simple tool-call latency on an M4 Max MacBook from 2.6 seconds to 1.1 seconds.
• Free and open: all three draft models are on Hugging Face in safetensors and GGUF formats, with day-one llama.cpp support and experimental SGLang Metal kernels, under Liquid's standard LFM Open License terms.
• Speedup depends on acceptance rate, not a flat multiplier - the same model and hardware can see anywhere from roughly 1.3x to 3.2x depending on how predictable the specific task is for the draft model.

Liquid AI is a Boston-based startup spun out of MIT's Computer Science and Artificial Intelligence Laboratory in 2023, founded by Ramin Hasani (CEO), Mathias Lechner (CTO), Alexander Amini (CSO) and Daniela Rus, the long-time director of MIT CSAIL. The company's pitch from the start has been narrower than most frontier labs: rather than chasing the largest possible model, Liquid builds "device-native" foundation models meant to run well on a phone, a laptop, or embedded hardware, not just a data-centre GPU cluster.

That focus shows up directly in the architecture. LFM2, released in July 2025, introduced Liquid's hybrid design: a stack of 16 blocks mixing double-gated short-range convolution blocks (10 of them) with grouped-query attention blocks (6 of them), rather than the all-attention transformer design most other labs use. Liquid reported roughly twice the decode and prefill speed of Qwen3 on CPU from that architecture alone, before any speculative decoding was involved. The family spanned 350 million to 8.3 billion parameters, including a Mixture-of-Experts variant (8.3B total, 1.5B active), all with a 32K-token context window.

LFM2.5 is the next generation of that same lineage, arriving through 2026 in stages - a 230-million-parameter model in June, and the on-device agentic LFM2.5-2.6B on 6 August 2026, which our research found to have 2.69 billion parameters across 30 layers (22 short-convolution layers plus 8 grouped-query-attention layers), a considerably longer 128K-token context window, and roughly 34 trillion training tokens. Liquid shipped it as two checkpoints - a base model for fine-tuning, and a post-trained version tuned specifically for agentic, tool-calling workloads - under the LFM Open License v1.0, which permits free commercial use for organisations under $10 million in annual revenue. On Liquid's own figures, the post-trained 2.6B model runs at roughly 220 tokens per second on an Apple M5 Max and around 30 tokens per second on a phone, using under 2.5GB of memory, entirely without DSpark. Two sibling models complete the family DSpark targets: LFM2.5-1.2B-Instruct, a smaller instruction-tuned dense model, and LFM2.5-8B-A1B, a Mixture-of-Experts model with roughly 1 billion active parameters per token.

DSpark, then, is not a new model in this lineage at all - it is an accelerator Liquid built specifically for the three LFM2.5 targets already described above, and the subject of the rest of this review.

Speculative decoding itself is not new - it is a technique used across the industry to speed up autoregressive generation by having a small, fast "draft" model propose several tokens ahead, which the large "target" model then checks in parallel rather than generating one token at a time sequentially. What Liquid built with DSpark is a specific implementation of that idea, tuned to its own LFM2.5 architecture, combining three named components in its release notes: a DFlash-style parallel backbone that produces hidden states and logits for several draft tokens at once, a lightweight sequential head modelled as a Markov chain to keep later draft tokens in the block accurate (since each guess depends on the ones before it), and a confidence-scheduled verifier that predicts how likely each draft token is to be accepted and prunes low-confidence tokens from the end of the block when the cost of verifying them outweighs the likely benefit.

Each draft model is small by design - roughly 300 million parameters, a small fraction of even the 1.2B target it accelerates. Liquid's own breakdown puts the LFM2.5-1.2B-Instruct drafter at 295.7 million parameters (a 5-layer decoder at 241.2M, a hidden-state projection at 21.0M, and a Markov head at 33.6M), while the drafters for both the 2.6B and 8B-A1B targets are slightly larger at 327.7 million parameters, with a bigger 65.5M Markov head to handle the larger target models' vocabulary and hidden-state size.

The three-step decode loop

Liquid's architecture diagram (below) lays the process out as three repeating steps. In step one, the target model runs a normal prefill pass over the prompt tokens, producing its own next-token hidden state. In step two, the small draft model takes that hidden state and proposes a block of several candidate tokens at once, run through its parallel block to generate logits, then its sequential Markov-chain block to refine each token given the ones proposed before it, before a hardware-aware prefix scheduler decides how many of the proposed tokens are worth sending forward for verification and drops the rest. In step three, the target model verifies the entire surviving block in a single parallel forward pass - in the diagram's worked example, of three proposed tokens (E, F and G), two are accepted and one (G) is rejected and regenerated normally by the target model, at which point the whole loop repeats from the newly-extended sequence.

Why it is lossless, not an approximation

The detail most worth understanding, because it is easy to assume any "speed hack" costs some quality, is that DSpark does not: under greedy decoding, a draft token is accepted only if it exactly matches the token the target model's own probability distribution would have produced on its own. Liquid states this directly. Any draft token the target model disagrees with is discarded and regenerated by the target model as normal, exactly as if DSpark had never been used for that token. The chart above shows why this matters for evaluating the release: what improves during DSpark's training is not the target model's output quality at all (that never changes) but the draft model's mean acceptance length - literally, how many tokens in a row the small model can correctly predict before the big model would have disagreed. A higher acceptance length means fewer verification round-trips per output token, which is the entire source of the speedup.

Because DSpark's speedup depends entirely on how often the draft model guesses correctly, the useful numbers are broken down by model, hardware and task rather than a single headline figure - Liquid AI's own release does exactly this, and the results are genuinely mixed rather than uniformly impressive:

For LFM2.5-2.6B specifically, Liquid published per-task numbers across five standard benchmarks on both platforms: MATH500 reached 3.06x on H100 and 2.25x on M4 Max, HumanEval reached 2.56x and 2.63x, MBPP reached 2.64x and 2.11x, GSM8K reached 2.22x and 2.36x, and MT-Bench reached 2.87x and 1.99x. The highest single figure across the whole release, and the one behind Liquid's "up to 3.2x" headline, sits around this MATH500/H100 result. For LFM2.5-1.2B-Instruct, throughput went from 656 to 1,384 tokens per second on H100, and from 138 to 350 tokens per second on the M4 Max. LFM2.5-8B-A1B's H100 throughput ranged as high as 326 to 1,074 tokens per second, but its Apple Silicon result was the one clear underperformer in the release: Liquid attributes the far smaller 1.18x gain specifically to how Mixture-of-Experts models currently run on Metal in llama.cpp, and to the memory bandwidth the larger target model needs on a laptop chip - a known current limitation of the ecosystem rather than a flaw specific to DSpark's method.

Liquid is candid in its own materials about why the multiplier moves around so much: speedup tracks acceptance rate, not the model or hardware alone. Its own example is stark - LFM2.5-8B-A1B accepts an average of 8.27 out of 10 proposed tokens per step on MATH500, a highly predictable, formulaic task for the draft model, but only 4.02 out of 10 on GSM8K, a benchmark with more varied reasoning paths. That difference in predictability is the entire gap between a 3.18x speedup and a 1.29x speedup on the exact same model and hardware. Anyone benchmarking DSpark on their own workload should expect a range, not a single number, and should treat the "up to 3.18x" figure as a ceiling reached under favourable, repetitive tasks rather than a typical result.

Standalone throughput benchmarks are useful for comparing models, but the number that matters for an actual on-device AI agent is end-to-end latency for a real task. Liquid published exactly this for tool-calling specifically, using the Berkeley Function-Calling Leaderboard (BFCL v3) with 50 requests per category at temperature 0, running LFM2.5-2.6B with DSpark through llama.cpp's Metal backend on an M4 Max MacBook - the kind of local, on-device agent loop Liquid's whole product line is built around.

The gains are consistent across every category tested, though not identical in size: simple single-function calls dropped from 2.6 seconds to 1.1 seconds (a 2.4x cut), while the hardest category tested, live_simple - real-world, less curated tool-calling scenarios with an accepted-token rate of just 4.42 out of 10 - improved more modestly from 4.0 seconds to 1.9 seconds (a 2.1x cut). For an agent making several tool calls in sequence, shaving two-plus seconds off each round-trip compounds quickly, which is the practical case Liquid is making here rather than the more abstract raw-throughput numbers above.

All three DSpark draft models are live now on Hugging Face - LiquidAI/LFM2.5-1.2B-Instruct-DSpark, LiquidAI/LFM2.5-2.6B-DSpark and LiquidAI/LFM2.5-8B-A1B-DSpark - each published in both safetensors format and quantised GGUF format for llama.cpp users. Liquid gave the release day-one support in llama.cpp, the most widely used local-inference runtime, alongside experimental Metal-kernel support in SGLang for Apple Silicon. Running DSpark requires downloading both the relevant target model (the full LFM2.5-1.2B-Instruct, 2.6B or 8B-A1B checkpoint) and its matching draft model - the draft model provides no benefit, and cannot be used, on its own.

On licensing, Liquid's base LFM2.5 checkpoints are released under the company's own LFM Open License v1.0, which allows free commercial use for organisations with under $10 million in annual revenue; larger companies need to contact Liquid AI directly for a commercial licence rather than using the models under the open terms. That is a materially more permissive stance than a fully closed API-only release, but a narrower one than a permissive licence like Apache 2.0 or MIT, and worth checking against your own organisation's size before deploying commercially.

• Speedup is task-dependent, not a flat multiplier. The same model and hardware can range from roughly 1.3x to 3.2x depending on how predictable the task is for the draft model - the "up to 3.18x" headline is a ceiling, not a typical result.
• Mixture-of-Experts gains are weak on Apple Silicon today. LFM2.5-8B-A1B saw only a 1.18x speedup on M4 Max versus 2.54x on H100, a gap Liquid attributes to current llama.cpp Metal-backend limitations for MoE models specifically, not a fundamental ceiling.
• Only benefits greedy or near-greedy decoding as tested. Liquid's lossless guarantee is stated for greedy decoding; behaviour and speedup under higher-temperature sampling were not detailed in the release materials reviewed for this article.
• Requires downloading and pairing two models, the target and its matching draft checkpoint, adding setup complexity and extra (though modest, at ~300M parameters) memory overhead versus running the target model alone.
• LFM Open License, not a fully permissive one. Free for organisations under $10M revenue, but larger companies need a separate commercial agreement with Liquid AI.
• No independent third-party benchmark of DSpark's reported speedups had been published at the time of writing; every figure in this article is Liquid AI's own internal result, albeit one with a transparent, verifiable claim (lossless output) that is straightforward for a user to check themselves.

DSpark is not a competitor to frontier API models like Claude Opus 4.8 or Gemini 3.7 Flash in any capability sense - it makes a small on-device model run faster, it does not make it smarter. The more relevant comparison is against the wider open-weight local-model ecosystem this site has covered recently: Qwen3.8-27B and Ornith 1.5 both compete on raw capability-per-parameter for locally-run models, but neither ships a dedicated, purpose-trained speculative-decoding accelerator alongside the base release the way Liquid has done here. Speculative decoding itself is a known technique used elsewhere in the industry (including inside some of the agent harnesses covered in our DeepSeek Harness review), but Liquid's specific contribution is training and shipping ready-made, free draft models tuned to its own architecture on day one, rather than leaving users to build or find a compatible drafter themselves.

Within Liquid's own line-up, DSpark is additive rather than a replacement for anything - it changes nothing about which LFM2.5 model is the right size for a given device or task, only how quickly whichever one you choose responds once it's running.

Worth trying now: anyone already running LFM2.5 models locally through llama.cpp, particularly on repetitive, formulaic tasks like structured data extraction, tool-calling agents, or code completion, where acceptance rates - and therefore speedups - tend to be highest. The setup cost is low (an extra ~300MB-1.3GB draft-model download) against a real, measured latency win, and there is no quality trade-off to weigh against it.

Less impactful for: anyone running LFM2.5-8B-A1B specifically on Apple Silicon today, given the currently weak MoE speedup on Metal; anyone whose workload leans toward open-ended, less predictable generation (closer to GSM8K's 4.02/10 acceptance rate than MATH500's 8.27/10) where gains will sit closer to the low end of the reported range; and anyone not already using one of the three specific LFM2.5 target models DSpark was built for, since it provides no benefit to any other model family.

LFM2.5-DSpark is a genuinely useful, low-risk release rather than a headline-chasing one: it costs nothing, changes no outputs, and Liquid AI has been unusually transparent about exactly where the gains are largest (repetitive, predictable tasks on dense models, particularly on GPU) and where they are currently weakest (Mixture-of-Experts models on Apple Silicon). The "up to 3.18x" top-line figure is real, achievable, and clearly sourced to a specific benchmark and platform - but the honest expectation for most real workloads sits closer to the reported means of 2.1x-2.7x, with function-calling latency roughly halved in Liquid's own on-device test.

For the specific audience it targets - developers already committed to running LFM2.5 locally - this is close to a free win: download the matching draft model, and the same model answers noticeably faster with no change in what it says.