LFM2.5-24B-A2B-DSpark vs LFM2.5-24B-A2B: Should You Actually Attach the Drafter?

Here is the decision in one line: LFM2.5-24B-A2B-DSpark is a 327.7M-parameter file you put next to LFM2.5-24B-A2B so that the 24B model produces the same kind of output faster. It is not an alternative to the model and it is not something you choose instead of it. The only real question the two names raise is an engineering one — do you attach the drafter to your deployment or leave it off — and the answer depends less on Liquid AI's headline speedup than on two numbers nobody advertises: how many tokens the draft gets accepted on your traffic, and how much concurrency you are already running. 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.

Liquid AI has not published a launch post for the drafter. The repository went public on 2026-10-19 with weights, a benchmark CSV and SGLang launch flags, while the target's own model card still labels the drafter "coming soon" and Liquid's speculative-decoding docs page lists only the 1.2B, 2.6B, 8B and VL-3B targets. So this is a comparison of a shipped artifact against a shipped model, written from the repository rather than from a press release — which means every performance number below is vendor-reported and none of it has been independently reproduced.

What the drafter actually changes, and what it does not

The mechanism is worth thirty seconds because it determines everything else. Decoding a token is memory-bound: the GPU spends most of its time streaming weights into SRAM, not doing arithmetic. Speculative decoding exploits that by having a small model guess the next several tokens at once, then having the real model check the whole guess in a single forward pass. If the guess was good, you produced nine tokens for roughly the cost of one. If it was bad, the target keeps its own token and you paid a little extra.

What changes: tokens per second, and the shape of your GPU utilisation. What does not change: the model's weights, its context window, its tool-calling behaviour, or its prices where it is sold. LFM2.5-24B-A2B keeps 24.0B total parameters with 2.45B active per token, 40 layers split across gated short convolutions and grouped-query attention, 64 experts per block with top-4 routing, a 131,072-token context and a 128,000-token vocabulary. The drafter adds five attention layers, a rank-256 Markov head and a confidence head, and reuses the target's embeddings and LM head instead of carrying its own.

One caveat moved between the two releases and deserves a line. In August, Liquid's DSpark write-up said the emitted sequence is "identical to baseline greedy by construction." The 24B drafter's card instead says floating-point differences between batched verification and plain decoding "can produce different text, including under greedy sampling." Both statements are defensible — the first is true in exact arithmetic — but if your evaluation harness compares outputs byte-for-byte, expect it to notice.

The cost side of the ledger

The drafter is not free. It occupies 655 MB in BF16 on the GPU (or a 664 MB F16 GGUF on CPU), it sits in the same memory pool as the target, and every step it proposes costs a verification forward pass over a block of tokens rather than a single token. On a MoE target that last part is more expensive than it sounds: verifying nine tokens activates more experts than decoding one, so the bytes moved per verified token go up, not down. Liquid named exactly this as the reason its 8B drafter delivered only 1.18× on an M4 Max despite strong acceptance.

Against that, the savings are large enough to measure in GPU-hours. Using the vendor's own B300 numbers from benchmarks/b300-fp8.csv, and doing nothing more than dividing a billion output tokens by observed throughput:

• MATH-500, concurrency 1 — 324 tok/s alone (857 GPU-hours per billion tokens) versus 853 tok/s with the drafter (326 GPU-hours). A 2.63× cut in compute time.

• MATH-500, concurrency 256 — 15,423 tok/s alone (18.0 GPU-hours) versus 27,579 tok/s with the drafter (10.1 GPU-hours). A 1.79× cut.

• GSM8K, concurrency 256 — 4,491 tok/s alone (61.9 GPU-hours) versus 9,660 tok/s with the drafter (28.8 GPU-hours). A 2.15× cut.

• LiveCodeBench, concurrency 256 — 18,812 tok/s alone (14.8 GPU-hours) versus 25,231 tok/s with the drafter (11.0 GPU-hours). Only a 1.34× cut, the weakest cell in the table.

Those are throughput ratios converted to time, not to money, because the money depends on what you pay per GPU-hour and this article is not going to invent a rate. But the ordering holds at any rate: attaching the drafter is worth two to three hours per ten for reasoning and code-generation traffic at low concurrency, and worth roughly a third of that at high concurrency. If your 24B deployment is a single-user agent on a workstation, the case is strong. If it is a saturated batch endpoint, the case is real but much thinner than the 2.4× headline suggests.

Where the drafter earns its keep, in workload terms

The eight-dataset spread in the vendor table is not noise; it maps onto prompt types, and the mapping is the most useful thing in the release. Acceptance ranged from 6.70 tokens per step on MBPP down to 4.02 on LiveCodeBench. The datasets that scored high are the ones where the model's output is constrained by the prompt — short unit-test-style functions, arithmetic with a checkable path, multiple-choice answers. The ones that scored low are the ones where the model has to invent a long, unconstrained solution: competitive-programming problems and AIME-style math.

That is the intuition to carry into your own evaluation. A 24B reasoning model sold for agentic work spends most of its output tokens inside a chain of thought, which looks more like LiveCodeBench than like MBPP. A model used for structured extraction, classification with a schema, or a fixed tool-call format looks much more like the high-acceptance rows. If your workload is the former, expect to land nearer the 1.34× bottom of the range than the 3.28× top. Nobody has published per-workload acceptance for this drafter, and the card's eight datasets are the closest thing to a guide.

Set against that: the 24B is a reasoning-only model. Liquid says it always thinks before answering — the chat template inserts a <think> tag automatically. That is the worst possible shape for speculation, because the reasoning span is exactly the long, low-acceptance stretch. The drafter will still help; it will help most on the final answer and least on the part that takes the longest.

How to tell, on your own hardware, in an afternoon

You do not have to trust any of the above. Both inference paths expose the acceptance counter, which is the only number that decides whether the drafter is paying for itself on your traffic.

On SGLang, launch the target with the drafter attached, block size 9 and ten draft tokens, then read the speculative-decoding metrics the server reports per request. The acceptance rate in the vendor table sits between 0.33 and 0.65 depending on dataset; a run that lands well below the relevant row means the drafter is guessing wrong and you are paying for verification without collecting the speedup. On llama.cpp with the F16 GGUF sidecar, the per-response timings carry draft_n and draft_n_accepted directly. Divide one by the other.

Two operational details will cost you an hour if you miss them. The SGLang server needs a build that includes the LFM2-MoE DSpark path merged on 2026-08-31 — on anything older the drafter architecture is simply unknown. And the block size is a property of the checkpoint, not a free parameter: llama.cpp clamps --spec-draft-n-max to the sidecar's metadata value of 9, so asking for 12 buys nothing.

The question this comparison cannot answer

There is a version of "should I attach the drafter" that has nothing to do with GPUs, and it is the one most teams actually face. If you call LFM2.5-24B-A2B through a hosted API, the drafter decision is not yours. The serving stack either attaches a speculative decoder or it does not; you see a tokens-per-second figure and a price, and both were decided upstream. Liquid's own Console lists the 24B at $0.10 per million input tokens, $0.05 cached input and $1.00 per million output — a published rate that already reflects whatever decode path they run, and one that can change without notice.

That is the seam where routing helps rather than complicates. A hosted call and a self-hosted deployment are not competing plans so much as two settings of the same cost knob: self-hosting plus the drafter minimises cost per token if your volume keeps the GPU busy, and a hosted endpoint minimises the work of getting an answer. OrcaRouter is built for the second — one key across 200-plus models at 0% markup on the provider's list price, so a vendor price change shows up on our side the same day, with automatic failover if a provider degrades and a routing DSL for splitting traffic rather than hard-coding one backend. We do not currently serve the LFM2.5 family, so for this specific model the hosted side means Liquid's own API or your own GPUs; the comparison worth running is against the models we do carry, such as Qwen3.6-35B-A3B — the model Liquid benchmarks against on agentic tasks — or Gemma 4 26B-A4B.

So: attach it or not

Attach it if you are serving LFM2.5-24B-A2B yourself at modest concurrency, especially for structured or extraction-shaped output, and if you have 655 MB of headroom beside the target. The vendor's numbers say you will roughly halve or third your decode time there, and the downside is bounded: a bad drafter costs a verification pass, not a wrong answer.

Leave it off if your endpoint is already saturated in the hundreds, if your output is long free-form reasoning, or if you need Apple-silicon numbers before you commit — the card has none, and the closest analogue from the same family shipped at 1.18× on a MacBook. And leave it off, obviously, if you are not running the model at all: a drafter is an optimisation for a deployment, and there is nothing to optimise until the deployment exists.

What would settle the rest is a vendor post and a Mac measurement. Neither exists as of 2026-10-21, which is a strange state for a release whose weights are already downloadable — and, for anyone willing to run the acceptance counter themselves, an unusually cheap opportunity to be the first independent number on the board.