LFM2.5-24B-A2B-DSpark Is Live on Hugging Face — Liquid AI Just Hasn't Announced It

The model card for Liquid AI's largest model still says its speculative-decoding drafter is coming soon. The drafter is not coming. LFM2.5-24B-A2B-DSpark has had a public repository since 2026-10-19, a 655 MB BF16 checkpoint, a full benchmark table, a GGUF sidecar published the following evening, and launch flags for SGLang written into its card. What it does not have is an announcement. LFM2.5-24B-A2B, the 24B mixture-of-experts model it exists to accelerate, got a blog post, a dated launch, a price list and a playground link on 2026-10-13. Its drafter got a repo and a model card, and Liquid AI's own documentation page for speculative decoding still lists only the 1.2B, 2.6B, 8B and VL-3B targets as supported. The documented AI failures and agent incidents behind releases like this one are collected in the OrcaRouter AI Incident Archive where each entry carries its own sources, severity, confidence grade and disputed flag.

That gap is the story here, and it is worth being precise about what it does and does not mean. A repository whose weights are open, whose benchmarks are reproducible from a CSV sitting next to the model, and whose inference path is already merged upstream is a real release, not a leak. But nothing about it has been confirmed by the vendor in prose, no third party has measured it, and the numbers in the card are the same team's numbers measured on the same hardware they selected. This piece separates the two: what the repository establishes, and what remains a claim.

What is actually in the repository

The checkpoint is small enough that the file listing itself is informative. The whole thing is one model.safetensors at 655,421,522 bytes — 327.7M parameters in BF16 — plus a config, a licence and a benchmarks directory. Nothing else. There is no tokenizer, no embedding matrix and no LM head, because the architecture reuses all three from the target at load time. That is the design: the drafter only ever has to know how to guess the next block of tokens in the target's vocabulary, not how to represent the world.

The config confirms the shape the August DSpark write-up described. Five full-attention layers at hidden size 2,048 and intermediate size 6,144 with SiLU/SwiGLU; grouped-query attention with 32 heads and 8 KV heads at head dimension 64; a rank-256 Markov head and a separate confidence head; block size 9; vocabulary 128,000; and a maximum position embedding of 131,072, which matches the target's context window exactly. The one field that is specific to this drafter is target_layer_ids: [2, 10, 18, 26, 34] against num_target_layers: 40 — the five layers of the 24B model whose hidden states the drafter reads as context. Those indices are why a drafter trained for one LFM2.5 model cannot simply be pointed at another.

The licence is lfm1.0, the same custom licence as the rest of the family, which is worth noting for anyone planning to redistribute a bundled target-plus-drafter artifact rather than use it internally.

The benchmark table, read as a vendor table

The card publishes throughput for eight datasets at concurrency 1, 32 and 256, on a single NVIDIA B300 with the FP8 target, a BF16 KV cache and temperature 0. Every figure below is Liquid AI's own and has not been reproduced outside the company; the raw rows are in the repo's benchmarks/b300-fp8.csv if you want to check the arithmetic yourself.

• Arithmetic mean over the eight datasets — 2.38× at concurrency 1, 2.69× at concurrency 32, 1.71× at concurrency 256.

• Best single cell — MBPP at concurrency 32, 3.28×, with MATH-500 close behind at 3.04×.

• Worst single cell — LiveCodeBench at concurrency 256, 1.34×, and AIME at 256, 1.36×.

• Tokens accepted per step — 5.16 on average, against a ceiling of 10 set by the block size plus the target's bonus token.

• Highest acceptance — MBPP at 6.70 tokens per step; lowest — LiveCodeBench at 4.02.

Two things about that table are more interesting than the headline. The first is that the mean speedup is higher at concurrency 32 than at concurrency 1 — 2.69× against 2.38× — which is the opposite of the usual speculative-decoding story, where batching eats the benefit. The second is that it collapses at 256. At 256 concurrent requests the target alone is already generating around 15,000 tokens per second on that GPU for MATH-500, and the drafter's contribution falls to 1.79×. A serving team reading only "2.4×" would size a cluster wrong; the number that matters for a batched endpoint is the 1.71×, and even that is a B300 number with a concurrency profile most deployments will not match.

The sentence that changed since August

When Liquid AI released DSpark drafters for the 1.2B, 2.6B and 8B-A1B targets on 2026-08-20, its blog post made a strong claim: because the target verifies every proposed token and replaces rejections with its own choice, "the emitted sequence is therefore identical to baseline greedy by construction." The 8B drafter's model card repeats the spirit of it, promising "exactly the same outputs."

The 24B drafter's card does not say that. It says the target verifies every proposed token, and then: "Floating-point differences between batched verification and plain decoding can produce different text, including under greedy sampling." It adds that the measurements assess performance, not task accuracy.

This is a more careful sentence, and it is the right one. Batched verification does not perform the same floating-point operations in the same order as sequential decoding, so bit-identity is an assumption that holds in exact arithmetic and not always on real hardware. The fact that the newer card says so while the older one did not is either a documentation correction or a discovery during training this drafter — the repository does not tell you which, and Liquid has not published an explanation. What it means practically is narrow but real: if your regression suite diffs model output byte-for-byte, adding this drafter can trip it, and that is a property of the arithmetic rather than a bug in the draft.

Why the drafter arrived six days after its own model

The timeline is worth laying out because it explains the silence better than any speculation about strategy.

• 2026-08-20 — Liquid publishes the DSpark family: drafters for LFM2.5-1.2B-Instruct, LFM2.5-2.6B and LFM2.5-8B-A1B. No 24B target exists yet.

• 2026-08-31 — SGLang merges PR #31041, adding LFM2 and LFM2-MoE DSpark speculative decoding support. The MoE path the 24B needs lands here, a month and a half before the model it will serve.

• 2026-10-13 — LFM2.5-24B-A2B ships with a blog post and a price. On the same day, SGLang merges PR #43939, which lets the server reuse the Hugging Face LFM2-MoE configuration directly.

• 2026-10-19 — the LFM2.5-24B-A2B-DSpark repository appears, with weights and benchmarks.

• 2026-10-20 — the GGUF sidecar lands: a single 664 MB F16 file for llama.cpp.

• 2026-10-21 — the target model card gains a drafter row. It still reads Coming soon.

Read that sequence and the most likely explanation is the boring one. The infrastructure shipped before the artifact; the artifact shipped when training finished; the announcement is a marketing task that has not happened yet. Nothing in the repository suggests a deliberately quiet launch — the card is complete, the benchmarks are documented down to the protocol, and the SGLang and llama.cpp invocations are written out in full. Quiet here means unannounced, not hidden.

What is not knowable yet

The honest boundary of this piece is a short list, and each item is a real gap rather than a formality.

No independent measurement. There is no Artificial Analysis entry, no third-party acceptance run, no reproduction of the throughput table. As of 2026-10-21 the repository showed seven downloads and one like. Every speedup in this article is the vendor's, on the vendor's chosen GPU, with the vendor's chosen target precision.

No announcement, so no framing. We do not know whether Liquid intends this as a production recommendation for the 24B or as a research artifact. The card's tone — full launch flags, a family table, a contact link — suggests the former, but that is inference.

No price, because there cannot be one. A drafter is not a served model. It has no per-million-token rate and will never appear on a model catalogue as a callable endpoint. Its cost is the 655 MB of VRAM or unified memory it occupies next to the target, plus the extra compute of verifying a block instead of a token.

No Apple-silicon numbers. This is the largest gap, and the next section explains why it matters more than the others.

The missing Mac number is the interesting omission

The 24B model is sold as an on-device model. Liquid's launch post leads with 184 tokens per second on an Apple M5 Max and calls it built for fast, private agents on-device. The drafter's card, by contrast, reports only B300 numbers. For the 8B drafter in August, Liquid published both H100 and M4 Max results and was candid about the gap between them: a 2.54× mean speedup on an H100 turned into 1.18× on a MacBook. Its stated reason was mechanical — verifying k tokens activates more experts than a single decode step, so an MoE target pays more weight traffic per verified token, and llama.cpp's Metal backend made that worse.

LFM2.5-24B-A2B is also a mixture of experts: 64 experts per block with top-4 routing. The same mechanism applies, and the 24B is a bigger model with a larger expert set to page through. That does not prove the on-device speedup is small — the drafter was trained specifically for this target, and acceptance is much better than the 8B's was at first — but it does mean the one number a laptop user needs is the one number the card does not contain. Treat any assumption that the B300 ratio carries over to a Mac as unverified.

Running it, and the one flag that will bite you

On GPU, the published recipe is SGLang with the FP8 target and the drafter attached, block size 9 and ten draft tokens. The installed SGLang must be recent enough to include the LFM2-MoE DSpark path from PR #31041 and the configuration reuse from PR #43939; on an older build the server will not recognise the drafter architecture at all. Note that the benchmark numbers assume the FP8 target — the BF16 target will behave differently, and not necessarily better, because the drafter was trained against a specific distribution of target logits.

On CPU and Apple silicon the path is llama.cpp with the F16 GGUF sidecar. The sidecar reads its block size from its own metadata and clamps --spec-draft-n-max to it, so setting the draft length to 12 does not get you 12. Per-response timings expose draft_n and draft_n_accepted, which is the field to watch on your own workload: if acceptance on your traffic sits far below the card's 5.16 mean, the drafter is costing you a forward pass and buying little, and the honest move is to detach it.

What this means if you are choosing a model this week

For most teams the practical consequence is small, because the drafter changes speed and not capability. LFM2.5-24B-A2B is the thing that answers prompts; the drafter only changes how many of those answers you get per second. If the 24B was not on your shortlist last week, a faster version of it does not put it there.

If it was on your shortlist, the drafter improves the case for self-hosting and does nothing for the API case. That distinction is worth stating plainly: a speculative-decoding checkpoint is invisible to anyone calling a hosted endpoint, because the serving stack decides whether to attach it. What you can compare on equal terms is the model itself against the alternatives you would otherwise route to — and if you are evaluating it against something like Qwen3.6-35B-A3B, the model Liquid benchmarks against on five of eight agentic tasks, OrcaRouter carries that comparison target behind one key at 0% markup on the provider's list price, with automatic failover across providers. We do not serve the LFM2.5 family today, so the 24B itself has to come from the vendor's own API or your own GPUs; what we offer is the other side of the comparison without a second contract.

What would change this picture

Three things, in order of how much they would move the story. A blog post from Liquid would settle the framing — whether this is a recommended production pairing or a research release. A published Mac measurement would settle the claim that matters to the audience the 24B was built for. And an independent acceptance run on real traffic, rather than eight benchmark datasets at temperature 0, would tell you whether 5.16 tokens per step survives contact with the messy, long, tool-calling prompts this model is actually sold for.

Until then the repository is public, the weights are downloadable, the CSV is right there, and the vendor's own model card is the last place you should look for news of it. That is an unusual state for a release to be in — but it is a real one, and the artifact does not become less real because nobody wrote the blog post.