← Back to all posts
News

DeepSeek Open-Sourced Its Whole Speculative-Decoding Stack. DSpark Makes Generation Up to 85% Faster.

June 27, 2026 · News
DeepSeek Open-Sourced Its Whole Speculative-Decoding Stack. DSpark Makes Generation Up to 85% Faster.

TL;DR

DeepSeek just dropped two things at once: DeepSpec, a full-stack, MIT-licensed codebase for training and evaluating speculative-decoding draft models, and DSpark, the specific draft-model design it now runs in production. DSpark boosts per-user generation speed by 60-85% on DeepSeek-V4 Flash and 57-78% on V4 Pro versus plain single-token decoding, with no change to output quality, because speculative decoding is mathematically guaranteed to match the target model's distribution. The interesting part is not the speedup, it is that DeepSeek shipped the entire pipeline, data prep, training, and eval, as open infrastructure that also works on Qwen3 and Gemma. If you self-host an LLM, this is a free lever on your tokens-per-second that you did not have last week.

speculative decoding: draft cheap, verify once, keep the good run draft modelguesses K tokens big model checksall K in one pass keep acceptedtokens, repeat One verify pass replaces K generations; longer accepted runs win bigger.
The whole game is making the draft cheap and the accepted run long.

What speculative decoding actually does

Generating text one token at a time is slow for a dumb reason: a giant model has to do a full forward pass for every single token, and most of that pass is spent waiting on memory, not doing math. The GPU is bored. Speculative decoding fills the boredom by having a tiny, fast draft model guess the next few tokens, then letting the big target model verify all of those guesses in a single parallel pass. Any guesses that match what the big model would have produced are kept for free; the first wrong guess is corrected and you start again.

The analogy: a junior writer drafts the next sentence and a senior editor speed-reads it, keeping every word up to the first one they would have written differently. If the junior is good, the editor approves long runs at a glance and the book gets written far faster, but the prose is still exactly what the editor would have signed off on. Crucially, the output is identical in distribution to running the big model alone, so this is a pure latency win, not a quality-for-speed trade.

The whole optimization therefore lives in one number: the acceptance length, how many drafted tokens survive verification per round. Push that up and you do fewer expensive verify passes per token produced. That is the exact dial DSpark turns.

What DSpark changes

Most modern draft models follow the EAGLE recipe (now on its third version, Eagle3): a small head that predicts tokens one at a time at the feature level. DeepSeek's earlier in-house method, DFlash, went the other way and predicted several tokens in parallel for raw throughput. DSpark is the merge of the two: a heavy parallel head proposes a block of tokens at once, then a small sequential head models the dependencies between them so the block holds together. DeepSeek calls this a semi-autoregressive draft, and it is the reason the accepted runs get longer.

The second trick is operational. DSpark adds a confidence-scheduled verifier: a lightweight confidence head scores how likely each drafted token is to survive, and the system shortens or lengthens how much it speculates based on current GPU load. Under heavy traffic it speculates conservatively to avoid wasting compute on rejected guesses; when the box is quiet it goes long. That is why DeepSeek frames the win as per-user generation speed while overall cluster throughput stays flat, it is spending idle headroom, not magicking up new FLOPs.

per-user generation speedup vs single-token decode (top of range) V4 Flash+85% V4 Pro+78% Ranges: Flash +60-85%, Pro +57-78%, measured in live DeepSeek traffic.
Same weights, same answers, up to 85% more tokens per second per user.

The benchmarks that matter

Against the two methods it borrows from, DSpark wins on the only metric that counts. On Qwen3 targets, its average acceptance length is 26.7% to 30.9% higher than Eagle3 and 16.3% to 18.4% higher than DFlash. Longer accepted runs mean fewer verification passes per token, which is where the end-to-end speedup comes from. These are not cherry-picked toy prompts either; DeepSpec evaluates across gsm8k, math500, aime25, humaneval, mbpp, livecodebench, mt-bench, alpaca, and arena-hard-v2.

avg acceptance length gain on Qwen3 (longer = more tokens/verify) vs Eagle3+30.9% vs DFlash+18.4% Top of the reported ranges; gains start at +26.7% (Eagle3) and +16.3% (DFlash).
DSpark keeps more of its guesses, which is the whole ballgame.

Why the open-source part is the real story

Speedups come and go. What is durable here is that DeepSeek published the training pipeline, not just a checkpoint. DeepSpec is a full-stack codebase: data preparation, draft-model implementations for DSpark, DFlash, and Eagle3, training code, and evaluation scripts, all under an MIT license. It already supports Qwen3 and Gemma as target families, which means you can train a custom draft head for a model DeepSeek never shipped and skip the months of plumbing that usually gate this kind of work.

That matters because speculative decoding has a dirty secret: the published draft models are trained for someone else's target model on someone else's data distribution, and acceptance rates fall off when your workload looks different. The win has always belonged to whoever could train their own draft model, which until now meant a research team with infrastructure. A maintained, MIT-licensed reference implementation drags that capability down to anyone with a GPU and a weekend. Runtimes like vLLM and SGLang already support EAGLE-style drafts, so a DSpark head trained in DeepSpec has somewhere to plug in.

The catch

This is not a one-click download. Training a draft model means running your target model over a big corpus to cache its hidden features first, and DeepSpec is upfront that the default Qwen3-4B setup wants roughly 38 TB of disk for that cache. The draft model is free; the 38 terabytes you need to train it are emphatically not. You also still need the hardware and patience to run the three-stage training, and the headline 60-85% figures are DeepSeek's own measurements on its own V4 models in its own serving stack. Your mileage on a different model, batch size, and prompt mix will vary, sometimes a lot. Treat the numbers as a credible ceiling, not a promise.

Still, the direction is unmistakable. While the frontier labs fight over who gets to use the biggest closed model, DeepSeek keeps handing out the tools to make the open ones cheaper to run. For a self-hoster, a free 1.6-1.8x on generation latency with zero quality loss is the kind of boring, load-bearing improvement that actually changes what you can afford to serve.

Key Takeaways

  • DeepSeek released DSpark, a semi-autoregressive speculative-decoding draft method, and DeepSpec, the MIT-licensed full-stack codebase to train and evaluate such draft models.
  • DSpark raises per-user generation speed 60-85% on DeepSeek-V4 Flash and 57-78% on V4 Pro versus single-token decoding, with output quality unchanged.
  • It beats Eagle3 by 26.7-30.9% and DFlash by 16.3-18.4% on average acceptance length (Qwen3 targets), the metric that drives the speedup.
  • DeepSpec supports Qwen3 and Gemma targets, so you can train a custom draft head for your own model and serve it via runtimes like vLLM or SGLang.
  • The catch: training a draft model needs a large feature cache (about 38 TB for the default Qwen3-4B setup), and DeepSeek's speedup figures are from its own serving stack.

Sources: DeepSpec (GitHub), DeepSeek-V4-Pro-DSpark (Hugging Face), 36Kr, KuCoin News, EAGLE (GitHub)

AIDeepSeekinferencespeculative decodingopen sourceQwenlocal AIoptimization
CONSOLE
$