LFM2.5-24B-A2B-DSpark vs LFM2.5-8B-A1B-DSpark: Same 328M File, Two Very Different Bets

Download either file and you get 655,421,522 bytes. LFM2.5-24B-A2B-DSpark and LFM2.5-8B-A1B-DSpark are the same size to the byte, share a five-layer backbone, the same rank-256 Markov head, the same block size of 9 and the same 128,000-token vocabulary — and neither one can answer a single prompt, because both are speculative-decoding drafters that only exist to guess tokens for a target model. What separates them is not their own specification. It is which target they were trained against, and how much evidence exists that the trick works on it. One has published GPU and MacBook measurements from a launch post; the other has a GPU table and no announcement. Choosing between them is therefore not a comparison of models at all — it is a comparison of two bets, and only one of them has been cashed. 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.

The files are twins; the jobs are not

Read the two config.json files side by side and almost every field matches: hidden size 2,048, intermediate size 6,144, SiLU activation, 32 attention heads over 8 KV heads at head dimension 64, five full-attention layers, block size 9, enable_confidence_head: true, a vanilla Markov head of rank 256. The parameter count is identical, which is why the safetensors files match byte for byte.

Three fields differ, and each one is load-bearing.

• Target layer taps — the 8B drafter reads hidden states from layers 2, 6, 10, 14 and 18 of a 24-layer target; the 24B drafter reads layers 2, 10, 18, 26 and 34 of a 40-layer target. This is the field that makes the files non-interchangeable.

• Maximum positions — 128,000 for the 8B drafter against 131,072 for the 24B, tracking their targets' context windows.

• RoPE theta — 5,000,000 against 10,000,000, set by the target's positional encoding rather than by anything about the drafter.

That last pair is the clearest evidence that these checkpoints were trained per target rather than scaled from a common base. The drafter has no independent identity: its input distribution is whatever the target's hidden states look like, and those change when the target's architecture and training change. Point the 8B drafter at the 24B model and the layer indices alone make it nonsense; even if they lined up, the logits it was trained to predict would not.

What each one is actually accelerating

The targets are more different than the "8B versus 24B" naming implies, and the difference runs the wrong way for anyone assuming the bigger model is the heavier lift on-device.

• Total and active parameters — LFM2.5-8B-A1B is 8.3B total with 1.5B active per token; LFM2.5-24B-A2B is 24.0B total with 2.45B active.

• Depth — 24 layers (18 gated convolutions plus 6 GQA) against 40 layers (30 convolutions plus 10 GQA).

• Context — 128,000 tokens against 131,072.

• Training budget — 38T tokens against 36T, so the smaller model was not undertrained relative to the larger one.

• Routing — the 8B uses a 64-expert MoE with top-4 routing, same as the 24B, so both pay the expert-activation penalty that hurts verification.

Both are reasoning models that think before answering, which matters here more than the parameter counts. Speculative decoding's biggest weakness is long, unconstrained output, and a chain of thought is exactly that. The vendor tables show it: the highest acceptance rows in both releases are short-answer benchmarks like MBPP and MT-Bench, and the lowest are the ones where the model has to invent a long solution path.

The evidence gap is the real difference

This is where the two releases stop being comparable. The 8B drafter shipped on 2026-08-20 as part of a full family announcement, with measurements on two very different machines: a single H100 80 GB in BF16 through SGLang, and an M4 Max MacBook Pro running FP16 GGUF weights through llama.cpp with experimental Metal kernels. It averaged 2.54× on the H100 with a 3.18× peak on MATH-500, and just 1.18× on the MacBook — 90 to 106 tokens per second, averaged across five datasets.

The 24B drafter has one hardware row: a single NVIDIA B300 with the FP8 target, BF16 KV cache, temperature 0. It averages 2.38× at concurrency 1, 2.69× at concurrency 32 and 1.71× at concurrency 256 across eight datasets, with a 3.28× peak on MBPP at concurrency 32. There is no Mac row, no H100 row, and no announcement post to explain the omission.

For the model whose entire pitch is on-device agents — Liquid's launch post for the 24B leads with 184 tokens per second on an Apple M5 Max — the missing MacBook number is the single most consequential blank in the release. The 8B result says why it might be small: verifying a block of tokens activates more experts than decoding one, so an MoE target moves more weight per accepted token. And acceptance alone is not the predictor: the 8B drafter actually averaged more accepted tokens per step than the 24B's card reports (6.95 over five datasets versus 5.16 over eight) and still delivered only 1.18× on a MacBook. That is the point worth keeping — on the 8B, strong acceptance did not rescue on-device throughput. Assuming the 24B behaves differently is a bet without a number behind it.

Reading the two tables against each other

The headline ratios are not apples to apples and should not be subtracted from one another. Different GPU, different target precision, different dataset sets, different concurrency sweeps. But two patterns survive the mismatch.

First, the ceiling is similar. The 8B's best H100 cell was 3.18× on MATH-500 at batch size 1; the 24B's best B300 cell is 3.28× on MBPP at concurrency 32. Drafters of this design land in the same 1.5×–3.3× band regardless of which target they serve, which is what you would expect when the drafter architecture is held fixed and only the weights change.

Second, and more usefully, the floor is where the targets diverge. The 8B's weakest H100 cell was GSM8K at 1.29×; the 24B's weakest B300 cell at concurrency 256 was LiveCodeBench at 1.34× and AIME at 1.36×. Neither release produces a case where speculation is free, and both produce cases where it is barely worth the memory.

There is also a documentation change between the two cards that is easy to miss and worth flagging. The August material said output under greedy decoding is identical to the baseline "by construction"; the 8B card promises "exactly the same outputs." The 24B card instead warns that floating-point differences between batched verification and plain decoding can produce different text, including under greedy sampling. The later card is the more careful one, and if you run byte-level output diffs in CI, both are worth treating as potentially non-identical rather than trusting the older promise.

Which one is relevant to you is decided by your target, not your budget

There is no scenario in which a team picks one of these over the other on merit. You run the 24B because you need a 24B model's capability on a machine that can hold it — 14.5 GB at Q4_K_M in GGUF, or a single B300 for the FP8 serving configuration. You run the 8B because 8.3B total parameters with 1.5B active is what fits an edge device or a laptop, and the drafter recovers some of the decode speed you gave up by going small. The drafter is an accessory to that first decision, and the decision is nearly always made on memory and quality long before speculation enters the conversation.

The one case where the choice is live is evaluation. If you are testing whether DSpark is worth adopting at all in your stack, the 8B pairing is the cheaper experiment: it fits on one H100, it has Mac numbers you can check against your own laptop, and its failure mode on-device has already been documented by the vendor. The 24B pairing is the more interesting production experiment and the less documented one.

For either, the number that decides the outcome is the acceptance counter, not the vendor table. SGLang exposes speculative-decoding acceptance per request; llama.cpp reports draft_n and draft_n_accepted in per-response timings. Run your own prompts for ten minutes and divide. If acceptance sits near the card's mean, the drafter pays; if it sits at the low end, you are buying verification passes and should detach it — and that conclusion will hold across both checkpoints, because the mechanism is the same.

Neither checkpoint is a model you can call

This is the part that catches people who meet these names in a model catalogue and assume they are options on a menu. They are not endpoints. Neither drafter has a price per million tokens, neither appears in an API listing, and neither will ever be routed to by a platform that serves models — because the correct pairing is a server-side configuration, not a request parameter.

Liquid AI sells the 24B target itself at $0.10 per million input tokens, $0.05 cached, and $1.00 per million output, and any speculation it runs behind that price is invisible to the caller. That is the ordinary shape of the market now: the interesting engineering happens inside the serving stack, and what reaches a developer is a rate and a tokens-per-second figure. Where routing platforms earn their place is in the comparison above that layer — putting a candidate next to the models it has to beat. OrcaRouter runs one endpoint across 200-plus models at 0% markup on provider list price, so when a vendor's rate changes, the rate you see moves the same day, and failover keeps a candidate model from becoming a single point of failure while you evaluate it. The LFM2.5 family is not among them today, so a self-hosted 8B or 24B with its drafter attached stays a local deployment; the models worth testing against it — Qwen3.6-35B-A3B on the agentic side, Gemma 4 26B-A4B on the efficiency side — are the ones we route.

What a year of DSpark releases has established

The family now spans four text targets and one vision target, from 1.2B to 24B, all sharing one drafter recipe: around 300M parameters, five attention layers, block 9, trained on the target's own hidden states. That consistency is the actual finding. Liquid has turned speculative decoding from a per-model research project into a manufacturing step — the same drafter, retargeted, shipped within days of each new model. Whether that step is worth taking on your hardware is a question about your traffic, and the answer differs by workload far more than it differs by which of these two files you download.

What the 24B release adds to that picture is not a better ratio. It is the first time a drafter has shipped without the accompanying write-up — and the first time the vendor's own card has told you, in plain language, that the outputs might not be bit-identical after all.