On this page · 12 sections
- What actually shipped on 20 August 2026
- The 3.2x is an H100 number, and the on-device numbers are the story
- No phone has been measured
- The LEAP gap
- The licence is the buried lede
- What it costs in app-bundle bytes
- Where the documents disagree with each other
- What is still unknown
- India-specific considerations
- FAQ
- How eCorpIT can help
- References
Summary. Liquid AI published LFM2.5-DSpark on 20 August 2026: three speculative-decoding draft models of 295.7M to 327.7M parameters that attach to existing LFM2.5 targets. The post is titled "Up to 3.2x Faster Inference". No measurement in it reaches 3.2x. The highest cell in any published table is 3.18x, and it is an H100 running SGLang, not a device. On an M4 Max MacBook Pro the LFM2.5-2.6B mean is 2.27x, the 1.2B mean is 2.54x, and the 8B-A1B mixture-of-experts model averages 1.18x — on MT-Bench it moves 87 tok/s to 90 tok/s. The drafter adds 174 MB to 664 MB of weights on top of the target model. The licence is not open source: LFM Open License v1.0 withdraws commercial rights above $10,000,000 in annual revenue. And no phone SoC appears anywhere in the release.
What actually shipped on 20 August 2026
DSpark is not a model you run. It is a drafter you bolt onto one you already run. The model card for LFM2.5-2.6B-DSpark states it plainly: "LFM2.5-DSpark is a family of speculative-decoding draft models that adapt DSpark for the LFM2.5 architecture. They allow LFM2.5 models to run faster without degrading quality."
Three drafters shipped, each paired to one target, in BF16 safetensors and in GGUF. The parameter counts come from the Hugging Face launch post: 295.7M for the LFM2.5-1.2B-Instruct drafter, and 327.7M each for the 2.6B and 8B-A1B drafters. Embeddings and the LM head are not carried by the drafter; they are shared from the target at load time. The GGUF card calls the file "a standalone draft sidecar", and it will not run alone.
The architecture has three parts, quoted from the launch post: a "DFlash-style parallel backbone", "a lightweight sequential head, modeled as a Markov chain between neighboring tokens", and "a confidence-scheduled verifier that predicts each token's survival probability and prunes low-confidence suffixes when verification would cost more than it saves."
Hold on to that third component. It matters later.
The 3.2x is an H100 number, and the on-device numbers are the story
Liquid AI's measurement setup is stated exactly once, in the launch post: "We measure on-device throughput with llama.cpp and Metal on an M4 Max MacBook Pro using FP16 GGUF weights and up to 256 output tokens. We measure GPU throughput with SGLang on a single H100 80 GB in BF16. Both configurations use a DSpark block size of 9, a batch size of 1, and a temperature of 0."
One laptop. One datacentre GPU. Batch size 1. Here is what the published tables report as the mean across five benchmarks:
| Draft model | Mean acceptance (of 10) | Mean speedup, 1xH100 SGLang | Mean speedup, M4 Max Metal |
|---|---|---|---|
| LFM2.5-1.2B-Instruct-DSpark | 5.02 | 2.10x (656 to 1384 tok/s) | 2.54x (138 to 350 tok/s) |
| LFM2.5-2.6B-DSpark | 4.81 | 2.67x (323 to 864 tok/s) | 2.27x (61 to 139 tok/s) |
| LFM2.5-8B-A1B-DSpark | 6.95 | 2.54x (418 to 1074 tok/s) | 1.18x (90 to 106 tok/s) |
The 3.18x that became "3.2x" in the title is one cell: LFM2.5-8B-A1B on MATH500 on the H100. The post's own first bullet is more careful than its title — "up to 3.18 throughput improvement on a GPU and up to 2.87x on-device" — and the best on-device figure, 2.87x, belongs to the 1.2B drafter on HumanEval, not to the 8B model that carries the headline.
The 8B-A1B row is where a mobile roadmap goes wrong. It is a mixture-of-experts model, the size most teams reach for when they want an on-device agent rather than a completion box, and on Metal it returns 1.21x, 1.12x, 1.09x, 1.44x and 1.04x. Liquid AI does not hide this. The launch post says: "For LFM2.5-8B-A1B, the acceptance rate increases compared to two dense models, yet on-device we get only an 18% improvement on average. This gap is due to the current MoE implementation in llama.cpp's Metal backend, and to the fact that verifying k tokens activates more experts and thus more weight traffic than a single decode step."
That is an honest paragraph buried under a headline that contradicts it.
No phone has been measured
Across the launch post, Liquid AI's own blog version, and all six model cards, one piece of hardware is named: an M4 Max MacBook Pro. There is no iPhone number. No A-series, no Snapdragon, no Tensor, no Dimensity. No iOS or Android measurement of any kind, no RAM-required figure, and no battery or sustained-throughput data. The Hugging Face post carries a heading that reads "Inference Speed Up on CPU and GPU"; every measurement under it is Metal GPU or H100.
An M4 Max has memory bandwidth a phone does not. Speculative decoding pays off when decoding is memory-bound and there is spare compute to verify a block of nine tokens in the time one token would have cost. That is a hardware-dependent trade, and the 8B row already shows what happens when the verification step costs more weight traffic than expected. Treating 2.27x as a phone number is an assumption, not a measurement.
The LEAP gap
For a team shipping an app, the operative question is whether this reaches the SDK. Liquid AI's LEAP SDK overview promises "Day-one model coverage. New LFM checkpoints land in the SDK release that announces them."
The LEAP SDK changelog records its latest release as v0.10.7. That page contains zero mentions of DSpark, speculative decoding, or draft models. Neither does the llama.cpp deployment guide, which never mentions the speculative flags.
So the two documented ways to run DSpark today are a custom llama.cpp build and a custom SGLang build. Neither is the shipping iOS or Android SDK. Anyone planning a Q4 2026 mobile release on this should budget for maintaining a forked inference runtime, not for a dependency bump.
The runtime story is also inconsistent inside Liquid AI's own repos. The GGUF card says "DSpark speculative decoding is in mainline, ggml-org/llama.cpp #25173." The launch post says "Running them with llama.cpp requires the respective llama.cpp build (PR#27383)", and adds that the published numbers were produced "with experimental metal kernels" from a third PR. Three PR numbers, and "in mainline" and "requires the respective build" are opposite claims about whether stock llama.cpp works.
The licence is the buried lede
All six repos are tagged lfm1.0. Liquid AI's launch page describes the release as "Open-weight — Download, fine-tune, and deploy without restrictions."
The LICENSE file in the same repository says something else. Section 5, verbatim:
5. Commercial Use Limitation.
(a) The rights granted under this License for Commercial Use are conditioned upon You or
Your Legal Entity not exceeding the Threshold.
(b) Any Commercial Use of the Work or a Derivative Work by a Legal Entity that exceeds the
Threshold is not licensed under this Agreement.
"Threshold" is defined in the same document as "annual revenue of 10 million United States dollars ($10,000,000) or more." Liquid AI's own licence FAQ states it without hedging: "If your company's annual revenue exceeds $10 million USD, your right to use the models commercially under this license ends. Contact sales@liquid.ai to obtain a commercial license."
Two details matter for anyone doing diligence. "Legal Entity" is defined as "the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity" — a small studio inside a larger group is measured at group revenue. And Section 11 terminates the licence "automatically and immediately" on any non-compliance, with an obligation to delete all copies.
A $10M revenue threshold is a real ceiling for a funded product company, and it applies to the 191 MB drafter exactly as it applies to the target model. The honest engineering read: this is free to prototype with and needs a commercial conversation before it ships in anything that scales.
What it costs in app-bundle bytes
The GGUF cards publish file sizes for the drafter only. These are additive to the target model already in the bundle.
| Drafter quant | LFM2.5-1.2B-Instruct | LFM2.5-2.6B | LFM2.5-8B-A1B | Card's note |
|---|---|---|---|---|
| F16 | 594 MB | 664 MB | 664 MB | "best accept length, recommended when memory allows" |
| Q8_0 | 315 MB | 349 MB | 349 MB | "accept length -2% vs F16" |
| Q4_K_M | 174 MB | 191 MB | 191 MB | "accept length -3% vs F16, smallest recommended" |
Every published benchmark used FP16 weights, so the 2.27x figure corresponds to the 664 MB row, not the 191 MB one. The cards warn against going lower: "sub-4-bit draft quants measurably hurt both accept length and throughput." They also note the drafter quant is a weak lever anyway — "Draft quantization changes speed only marginally (the drafter is a small share of each cycle); choose by memory budget."
For an iOS app that is 174 MB to 664 MB of extra download and extra resident memory, on top of a target model that is already the largest asset in the bundle. That arithmetic decides this before any benchmark does. Teams weighing that trade against an API call should start from our on-device versus cloud AI build guide for mobile apps and the Apple silicon local LLM break-even analysis.
Where the documents disagree with each other
Three conflicts are worth recording, because each one changes a number somebody will quote.
First, the model cards contradict themselves. LFM2.5-2.6B-DSpark publishes two acceptance tables for the same benchmarks on the same hardware. The first, headed "Acceptance", reports MATH-500 at 5.67 on the H100 and MT-Bench at 4.69. The second, fifteen lines below, reports MATH500 at 5.42 and MT-Bench at 5.07. The same doubled-table mismatch appears on the 1.2B card (MT-Bench 3.11 against 3.90) and the 8B card (mean 7.21 against 6.95). Only the second set appears in the blog post.
Second, the confidence-scheduled verifier — one of DSpark's three advertised components — was switched off for every published benchmark. That admission appears only on liquid.ai, not on Hugging Face: "All of the tests were run on SGLang with a single H100 without a confidence-scheduled verifier. DSpark's confidence head can dynamically trim how many tokens to verify per request, but in our experiments the tokens it drops cost more than the compute it saves, so we serve a fixed verify window instead."
Third, the speedup does not survive concurrency. Liquid AI's blog states it directly: as concurrency rises the workload moves "from the memory-bound to the compute-bound regime", which "closes the cumulative speedup gap between the model running with DSpark and the baseline model", converging around batch size 128 for the 2.6B model at block size 9. Anyone planning to reuse these drafters on a shared inference server rather than a device should read our note on vLLM speculative decoding with P-EAGLE, DFlash and DSpark before sizing hardware.
What is still unknown
No phone or tablet SoC has been measured by anyone, including Liquid AI. No CPU-only figures exist despite the section heading that implies them. Behaviour above temperature 0 is not addressed anywhere; the quality-parity claim is explicitly conditioned on greedy decoding, where "the emitted sequence is therefore identical to baseline greedy by construction." The merge status of the llama.cpp pull requests could not be confirmed from a primary source for this article. And the 57% function-calling latency reduction cited for LFM2.5-2.6B on the BFCL dataset is published only as a chart image, with no numeric table behind it in either post.
India-specific considerations
For Indian product teams the licence threshold arrives earlier than it looks. $10,000,000 is roughly Rs 88 crore of annual revenue at late-2026 rates, and it is measured across the whole corporate group, not the app. A services firm building an on-device feature for a large client inherits the client's position, not its own.
The privacy argument for on-device inference remains the strongest one. Under the Digital Personal Data Protection Act 2023, inference that never leaves the handset removes an entire class of transfer and retention questions. That argument holds whether the model runs at 61 tok/s or 139 tok/s, which is a reason to evaluate DSpark on latency and battery rather than on the headline multiplier.
FAQ
How eCorpIT can help
eCorpIT builds production mobile applications with on-device and hybrid inference paths, and we size the trade with measurements rather than launch-post multipliers. If you are weighing a local model against an API call for a shipping iOS or Android product, we can benchmark both on your target handsets, model the bundle-size and battery cost, and flag licence constraints before they reach procurement. Our custom mobile app development team runs that evaluation as a fixed-scope exercise. Start at /contact-us/.
References
Last updated: 22 August 2026.
