LFM2.5-8B-A1B-DSpark vs Qwen3-8B: The Draft That Speeds Up a Model, Against the 8B Everyone Already Runs

Liquid AI released the LFM2.5-8B-A1B-DSpark draft checkpoint on August 20, 2026 — a 327.7M-parameter speculative-decoding helper that makes the LFM2.5-8B-A1B edge MoE generate up to 3.18× faster on a single H100. Before this comparison can be honest, one fact has to sit on top of the table: the DSpark checkpoint is not a model you can call. It only accelerates another model. So the real deployment question this release feeds is the one most teams have been weighing all year — LFM2.5-8B-A1B or Qwen3-8B, two 8B-class open-weight models at very different moments in their lives.

The frame matters more than usual here, because the two sides are not the same kind of thing. Qwen3-8B is a complete, deployable model that you can self-host or buy tokens for today. LFM2.5-8B-A1B is a complete, deployable model too — the DSpark draft is an add-on to it, not a version of it. Everything the draft promises is vendor-measured and a day old; everything about the repos and formats is simply there to be checked. This piece keeps those two buckets separate.

First, the word "DSpark" is not the noun in this sentence

Speculative decoding runs a cheap draft model ahead of the real one: the drafter guesses the next handful of tokens, the target verifies the whole block in a single forward pass, and it keeps whatever it agrees with. When the guesses are good, you move several tokens for the price of one weight-loading pass, so throughput climbs without touching the target's weights — and because the target checks every proposed token, the output under greedy decoding is identical to running the LFM2.5-8B-A1B alone. Liquid calls this "lossless by construction," and it is the whole reason a draft is safe to bolt on.

Liquid's LFM2.5-8B-A1B-DSpark is a deliberately small drafter: five attention-only layers, a block of nine proposed tokens per step, and a Markov head over the target's 128,000-token vocabulary, trained for 15 epochs on a mix of chat, code, and function-calling data with checkpoints picked by acceptance rate rather than loss. It is one of three drafts the vendor shipped that day, alongside LFM2.5-1.2B-Instruct and LFM2.5-2.6B, each in Safetensors and GGUF with day-one SGLang and llama.cpp support. It is also, importantly for anyone reading a comparison with an 8B-class model: it is not served by any inference provider and has no per-token price. It lives only inside your own speculative-decoding stack.

The two models that actually deploy

Strip the draft away and the real comparison is between the model it accelerates and the incumbent. Both are open-weight and roughly 8B-class, and then the resemblance ends:

• Architecture — LFM2.5-8B-A1B is a sparse MoE with 8.3B total parameters but only ~1.5B active per token; Qwen3-8B is a dense 8.2B model that activates every parameter on every token.

• Release — LFM2.5-8B-A1B shipped May 28, 2026; Qwen3-8B shipped April 2025 and is over a year old, already deprecated on some serving platforms.

• Context — LFM2.5-8B-A1B offers a native 128K context with a 128K-token vocabulary; Qwen3-8B offers 32K native, extensible to around 128K via YaRN.

• Reasoning — LFM2.5-8B-A1B is a reasoning model that emits an explicit chain of thought; Qwen3-8B toggles between thinking and non-thinking modes per request.

• Intelligence — per Artificial Analysis, LFM2.5-8B-A1B scores an Intelligence Index of 8 and Qwen3-8B scores 8–8.3, both below the median of 9 for comparable open-weight models; neither is a frontier brain, and both are honest about it.

• Speed — per Artificial Analysis, LFM2.5-8B-A1B outputs roughly 340 tokens per second across providers; Qwen3-8B sits around 37–40 tokens per second, among the slowest in its class.

• License — LFM2.5-8B-A1B is under Liquid's LFM Open License v1.0; Qwen3-8B is Apache-2.0.

Speed is where this stops being close

The single biggest reason the 8B-class open-weight conversation moved is speed per unit of memory. Qwen3-8B is a dense model: every token it produces streams all 8.2B weights across the memory bus, which is why it is slow for its size and why it needs real VRAM. LFM2.5-8B-A1B routes every token through about 1.5B active parameters, which is the entire design point — an on-device MoE that stays fast and small. Liquid's own claims go further: roughly 253 tokens per second on an M5 Max CPU under 6GB of memory, vendor-reported. On raw throughput for the deployable model, the draft does not even matter for this part of the story — the MoE is already several times faster than the dense 8B before you add speculation.

On price, both are open weights, so self-hosting either costs whatever your hardware costs. The hosted comparison is lopsided in availability: Qwen3-8B is served by Alibaba's API at a list price of $0.18 per million input tokens and $2.10 per million output tokens, and by a broad set of third-party open-model hosts; LFM2.5-8B-A1B has no first-party hosted token pricing of note, and the draft has none at all. Which means the practical way most teams will run Liquid's edge MoE today is self-hosted, on a laptop, an edge box, or a GPU they own — and that is exactly the setup where the DSpark draft becomes the relevant variable.

What the draft actually changes for this decision

The draft changes one axis only: how fast the LFM2.5-8B-A1B produces tokens in a serving stack you control. It does not make the model smarter, and it does not change what it answers — greedy output is bit-identical to the target alone. Where it helps is GPU serving at single-request throughput: Liquid measured a mean 2.54× on a single H100 across five benchmarks (418 → 1,074 tokens per second), with a best of 3.18× on MATH500, at batch size 1 and temperature 0. Where it barely helps is Apple silicon: the same model averaged just 1.18× on an M4 Max (90 → 106 tok/s), because verifying a block of draft tokens activates more experts in llama.cpp's current Metal MoE backend and moves more weight traffic — the exact cost speculative decoding is meant to amortize. All of these are vendor figures from the day of release, not independently reproduced.

That split maps directly onto a decision rule. If you serve LFM2.5-8B-A1B on a GPU you own, the draft is a real cost lever — roughly 2.5× more tokens per second from the same silicon, with zero output change, and you only need a build with the August 20 DSpark integrations. If you call the model through an API instead, the provider keeps the speedup and the draft is irrelevant to you. And if the device is a laptop or a phone, the draft for this particular model is close to a no-op today; the sibling drafts for the dense LFM2.5-1.2B-Instruct and LFM2.5-2.6B are the ones with the on-device wins, at 2.54× and 2.27× respectively. Qwen3-8B, for its part, needs no draft at all — it is simply a slower, denser model that does not require speculative decoding to be deployable.

The choice, a year into Qwen3-8B's life

Qwen3-8B is the boring, correct default: mature, Apache-2.0, 119 languages, thinking and non-thinking modes, served everywhere, and still a perfectly good generalist for chat, code, and structured text. Its problems are age and speed — a 16-month-old dense 8B that is slow for its class and already deprecated on some platforms, which is a maintenance signal worth taking seriously if you are starting a greenfield project today.

LFM2.5-8B-A1B is the newer, narrower bet: an edge-first MoE built for tool calling and instruction following at speed on consumer hardware, with the DSpark draft as an optional serving boost for the GPU self-host case. It is not a smarter model — both sit below the open-weights median on Artificial Analysis — but it is a dramatically faster one at a fraction of the memory per token, which is the trade-off that matters for on-device agents. Its caveats are the mirror image of Qwen3-8B's: a younger release, no first-party hosted pricing, and a speculative-decoding story whose numbers nobody outside the vendor has reproduced yet.

The routing layer underneath stays the same either way. Neither LFM2.5-8B-A1B nor Qwen3-8B is in OrcaRouter's hosted catalog today, so the honest framing is what a router does for the mix: one API across 200+ hosted models with provider list prices passed through at 0% markup, so a vendor price cut is live on the platform the same day it is announced; automatic failover so an unproven new model is something you try against real traffic rather than something you bet a production path on; and a routing DSL that can front a model you serve yourself, which is how a self-hosted LFM2.5-8B-A1B stack coexists with hosted endpoints behind one key.

If you are building for a laptop or an edge box and care about tool-calling speed, LFM2.5-8B-A1B is the direction to test, and the draft is a free 2.5× on the GPU serving path when the time comes. If you want a generalist you can stop thinking about, Qwen3-8B still works — just know it is a model from early 2025 that the ecosystem is starting to rotate out. The one thing neither the draft nor the target changes is the honest state of the evidence: everything fast about the DSpark release is a single vendor's measurement from a single day, and independent benchmarks are the open item that decides how much of this you actually trust.