LFM2.5-VL-3B-DSpark: Liquid AI's 279.5M Drafter Shipped Six Days Before Anyone Announced It

There is a version of this story where LFM2.5-VL-3B-DSpark is a new model. It is not. It is a 279.5M-parameter speculative-decoding draft model that exists for exactly one purpose — making Liquid AI's own vision-language model LFM2.5-VL-3B decode faster — and it cannot generate a usable answer on its own. The reason it is worth reading about anyway is the timeline: the weights landed on Hugging Face on September 18, 2026, with no announcement attached, sat there for six days, and only got a vendor blog post on September 24. Radar caught the repo in the gap.

That gap is also the boundary of what is knowable right now. Everything in the repository — the parameter breakdown, the block size, the framework integrations, the license — is a file on disk you or I can open. Every speedup figure is vendor-measured, from Liquid's own benchmark harness, and nobody outside the company has published a reproduction. This piece keeps those two piles separate on purpose.

What the repository actually contains

Open the model card and the shape of the thing is unambiguous. LFM2.5-VL-3B-DSpark is a draft model whose target is fixed in its metadata: base_model: LiquidAI/LFM2.5-VL-3B. You do not point it at a different model and you do not serve it alone.

• Total draft parameters — 279.5M, BF16, of which 193.0M is the 4-layer decoder stack, 65.5M is a Markov head, 21.0M is a hidden-state projection, and 6.4k is norms plus a confidence head

• Backbone — 4 full attention layers, hidden size 2,048, intermediate size 6,144 with SiLU/SwiGLU, grouped-query attention at 32 attention heads and 8 key-value heads, head dimension 64

• Extra heads — a Markov head at rank 256 and a confidence head, which is what separates DSpark drafting from a plain parallel drafter

• Block size — 9 during training; 8 or 9 at inference depending on hardware, and 8 specifically on Apple silicon

• Vocabulary — 128,000, tied to the target rather than carried by the draft

• Weight in the deployed stack — Liquid states the drafter increases the deployed parameter count by 8.9%

The 8.9% is the number to hold onto. The pitch for this class of model is never "faster inference is free"; it is "faster inference costs you about a tenth of a model's worth of memory." At 279.5M extra parameters on top of a 3.1B target, that is a smaller tax than the size of the drafter alone would suggest, because embedding and LM head are tied to the target and not duplicated.

DSpark is a DeepSeek technique before it is a Liquid model

The naming invites confusion, so it is worth being precise. DSpark is not a Liquid AI invention and not a model family. It is a speculative-decoding framework from a separate research line, described in a July 2026 paper as confidence-scheduled speculative decoding with semi-autoregressive generation. Its three ideas: a parallel backbone that drafts a whole block in one forward pass, a lightweight sequential module that restores some dependency between neighbouring draft tokens so acceptance does not collapse at the end of the block, and a verifier that shortens the verification window per request when the draft's own confidence suggests the tail will be rejected.

What Liquid did is apply that recipe to vision-language models and ship a checkpoint. The card is candid that this transfer is less dramatic than it sounds: from the drafter's point of view, modality is irrelevant, because by the time tokens reach the hidden layers an image patch and a text token are both just tensors. That is why a technique developed on text models ports to a VLM without being reinvented — and it is also why the drafter cannot be sold as a new capability.

Liquid had already shipped text DSpark drafters — the 2.6B, 8B-A1B and 1.2B-Instruct companions went up in August 2026, with GGUF exports following on August 19. The vision drafter is the same idea extended to the multimodal branch, and the fourth or fifth entry in a line, not a debut.

The speedup numbers, and who measured them

Every figure below is Liquid's own, collected on Liquid's benchmarking infrastructure, and none of it has an independent reproduction. Treat them as a vendor ceiling, not an expected result. The card separates decode speedup from end-to-end speedup, which matters more than the headline.

• Best decode speedup — 3.13× on COCO, measured with MLX-VLM on an Apple M5 Max at block size 8, FP16, batch size 1, temperature 0

• Best GPU decode speedup — 2.66× on COCO, SGLang on a single H100 80GB, BF16, block size 9

• Best llama.cpp decode speedup — 2.14× on COCO, Apple M3 Ultra, block size 8

• H100 decode range across six vision tasks — 2.04× to 2.66×, with end-to-end at 1.64× to 2.27×

• M5 Max decode range — 2.30× to 3.13×, end-to-end 1.56× to 2.62×

• M3 Ultra decode range — 1.57× to 2.14×, end-to-end 1.30× to 1.77×

• Draft acceptance — roughly 3.2 to 4.5 tokens accepted per target verification pass, on all three stacks

The pattern in those ranges is the honest part. End-to-end gains are consistently the smaller half of each pair, because the drafter accelerates decoding and nothing else. Note also that the same drafter at the same block size lands at 3.13× on one stack and 1.57× on another — the acceptance rate is a property of the drafter and the workload, but the wall-clock gain is a property of the hardware and the runtime's overhead. A "2.66× faster" claim with no stack attached is not a claim you can act on.

Two correctness points from the card are worth stating plainly, because they are what make a drafter acceptable in production at all. Under greedy decoding, speculative decoding is exact: the target verifies every proposed token, so the text is what the target would have produced alone. Under matched sampling settings at non-zero temperature, it preserves the target's output distribution. Liquid's phrasing — you get the speedup, not a different model — is accurate as far as it goes, and the card is honest that raising temperature lowers acceptance and therefore erodes the throughput benefit.

What Liquid's own post admits

The September 24 blog post is more useful than the model card for one reason: it names the limit. Vision-language inference pays a prefill cost that text inference does not — the image has to pass through a vision encoder, and the language backbone then has to process the hundreds of visual tokens that encoder produces. On a device, that prefill dominates end-to-end latency. Speculative decoding accelerates decode only. Vision encoding and prefill are untouched. Liquid invokes Amdahl's law against its own product and points out that where prefill is a large share of wall time, a large decode speedup buys only a modest end-to-end improvement.

That is a real constraint on the buying decision, and it explains why time-to-first-token is not on the list of things this drafter improves. It also implies the workloads that benefit most are ones that generate long outputs from a modest image — a caption, a long OCR transcription, a multi-turn conversation with one image carried forward — rather than ones that answer a short question about a large image.

The post adds two more scoping limits. All numbers use 16-bit processing for both the vision encoder and the language backbone, and acceleration of quantized models is out of scope for this release. Given that the whole selling point of a 3B edge VLM is running in a couple of gigabytes, "the speedups are measured at FP16" is a meaningful caveat for anyone who planned to pair it with a 4-bit export. Liquid also notes the drafter was trained entirely on AMD hardware.

Running it

Day-one support is real and covers three runtimes, which is more than most drafters get. SGLang on NVIDIA requires v0.5.19 or newer and takes the drafter through --speculative-algorithm DSPARK with the draft path and a block size of 9. MLX-VLM on Apple silicon requires v0.7.2 or newer and detects the drafter when it is passed with --draft-model; there is one sharp edge — DSpark decoding in MLX-VLM currently uses greedy sampling, so temperature has to be set to 0. For llama.cpp there is a separate GGUF repository, with a single F16 export at roughly 567 MB, and the card is explicit that you pair the quantized drafter with the quantized target rather than with the original safetensors checkpoint.

Where a routing layer earns its place here is not on this model — OrcaRouter does not route LFM2.5-VL-3B-DSpark or LFM2.5-VL-3B, and this is a self-hosted drafter pairing you download and serve yourself. It is on the rest of the stack around it. The same application that runs a small open-weight vision model on-device usually has a fallback path for the queries the small model cannot handle, and pointing that path at a single endpoint covering 200+ models — billed at each provider's list price with no markup added, with automatic failover when a provider degrades — is a smaller integration than standing up a second vendor contract. The drafter improves one leg of that architecture; the router is what keeps the other leg from becoming a second project.

What is not known yet

The repository has 37 downloads and 6 likes at the time of writing. There is no entry for this drafter on any public benchmark aggregator, no third-party reproduction of any of the speedup ranges, and no independent measurement of the acceptance rate on hardware Liquid did not test. There are also no quality benchmarks on the card for obvious reasons — the drafter is output-preserving by construction, so the quality numbers belong to LFM2.5-VL-3B, and the card points at that model's benchmarks rather than inventing its own.

One detail in the metadata is a small tell about how new this is: the model carries an SGLang library tag and an SGLang algorithm flag that exists specifically to invoke it. Framework support had to land before the announcement did, which is consistent with the six-day gap between the repository and the blog post.

So: a genuine, useful, narrowly-scoped piece of engineering, announced a week after it shipped, whose entire value proposition is a vendor-measured number on hardware you may not own. If you are serving LFM2.5-VL-3B on an H100 or an M-series Mac and your workload is decode-heavy, the memory cost is 8.9% and the downside is close to zero because the output is provably the target's. If your latency is dominated by prefill, or you were counting on the 4-bit export, Liquid's own post tells you it will not help. The reproduction, when it comes, is the thing to wait for.

OrcaRouter puts 200+ models behind one key at provider list price with 0% markup, and expresses the fallback path as a routing layer rather than application code. The drafter is self-hosted either way - the router is what keeps the leg your small model hands off to from becoming a second project.