DeepSeek boosts inference speed by another 85%: How the new DSpark technology pulls it off

You open DeepSeek's web version and type "help me write a leave note," and the characters popping up on your screen may have just gotten subtly faster.

At the end of June, DeepSeek open-sourced DSpark—a new "speculative decoding" algorithm that has already been deployed into the V4 series online.

💡 What You Will Learn

DeepSeek boosts inference speed by another 85%: How the new DSpark technology pulls it off You open DeepSeek's web version and type "help me write a leave note," and the characters popping up on your

📜 Table of Contents

• What Speculative Decoding Actually Does
• DSpark's Two Scalpels
• Side-by-Side with Peers
• What Does This Mean for Ordinary People?
• Personal Take: DSpark's Real Moat Isn't the Algorithm, It's the Engineering

DeepSeek Boosts Inference Speed Another 85%: How the New DSpark Technology Works

You open DeepSeek's web version and type "help me write a leave request," and the speed at which characters appear on screen may have just quietly gotten faster.

At the end of June, DeepSeek open-sourced DSpark — a new "speculative decoding" algorithm already deployed in the V4 series' online inference service. Official self-reported data: on the user-typing-speed dimension, DSpark is 60%–85% faster than the MTP-1 baseline DeepSeek previously used online.

Not a GPU upgrade, not a bigger model — the engine underneath was swapped out.

What Speculative Decoding Actually Does

Large models are inherently a "token-by-token" task — to generate the 100th token, you have to look at all the previous 99, and the GPU computes once.

Speculative decoding works like this: first, a cheap small model "drafts" 8 candidate tokens, then the large model grades all 8 at once like a test paper — correct ones are kept, wrong ones are sent back for rewriting.

That grading step is parallel, so the GPU isn't "fed" one token at a time — it's "stuffed" with a whole batch. GPU utilization goes straight up.

This "draft first, then grade" two-stage approach has been running in the industry for three years. EAGLE, EAGLE-2, Medusa, and Lookahead all belong to this line.

But before DSpark, the industry generally fell into two pitfalls:

• Draft degradation — the longer the 8 drafted tokens, the more likely the first few are correct while the later ones drift off, making verification on the tail largely wasted work.
• Verification waste — draft quality varies per request, but everyone verifies all 8 tokens indiscriminately; for requests with poor draft quality, it's wasted compute.

DSpark's solution happens to hit both pitfalls head-on.

DSpark's Two Scalpels

First scalpel: Semi-autoregressive drafting

Traditional drafting is "parallel" — 8 tokens each guessed independently, unrelated to each other. It's fast, but guessing 8 times is about as accurate as guessing once, and quality degrades further down the line.

DSpark uses semi-autoregression — the first 6 tokens are still guessed in parallel (fast), but after each token is guessed, a lightweight "tail module" reads back through the already-guessed tokens to give the later tokens a bit more contextual dependency.

The result: each token is still computed in parallel, but tokens are no longer fully independent. The paper calls it "intra-block dependency modeling" — within the same draft block, tokens now have dependencies, and quality decay slows down noticeably.

Second scalpel: Confidence-scheduled verification

This one is DSpark's most noteworthy engineering contribution.

Traditional approach: every request gets the same verification length — a fixed 8 tokens. But in reality, some requests have high draft quality (first 7 correct), others have low quality (wrong by token 2). One-size-fits-all is a massive waste.

DSpark ships a confidence scheduler: after each token is generated, the scheduler computes "is it worth verifying the next token?" — if yes, keep going; if not, stop early and let the large model rewrite.

Analogy: It's like a hospital triage desk — not everyone gets called in order; instead, "the ones who look like they're dying get rescued first, the ones with a cold can wait." GPU compute is saved, and the saved compute is redistributed to more concurrent requests.

The paper offers an interesting data point: these two mechanisms combined give DSpark an "acceptance length" (the actual adoption rate of drafts) of 1.56× to 5.06× across multiple benchmarks — that's offline test data, an academic metric, not user-perceived.

Side-by-Side with Peers

Note that DFlash is also open-sourced this time — the DeepSpec repo now contains a full family of three algorithms (DSpark / DFlash / Eagle3). DSpark is the one DeepSeek chose for production.

What Does This Mean for Ordinary People?

Layer one: Free users benefit directly.

The "typing" speed on DeepSeek's web version and app will get faster, with zero action needed from you. This is a backend engine swap, not a Pro upgrade. The official 60%–85% figure is conservative; actual feel depends on request length — the longer the request, the higher the draft/verification reuse rate, and the more noticeable the speedup.

Layer two: API developers benefit indirectly.

If you run apps on the DeepSeek API, the same max_tokens=1000 now yields more tokens per unit time — meaning for the same request volume, server costs drop. DeepSeek didn't cut prices, but your batch job throughput will rise.

Layer three: The open-source ecosystem follows.

The DeepSpec repo is MIT-licensed, with training code, training data, configs, and checkpoints all included. You can run the same stack on Qwen3 / Gemma series and reproduce every number in the paper. This is different from the "release model weights but not training scripts" playbook.

Personal Take: DSpark's Real Moat Isn't the Algorithm, It's the Engineering

There are already plenty of speculative decoding algorithms in the industry — EAGLE series, DFlash, Medusa all deliver solid speedups in different scenarios.

But DeepSeek's move here — the real differentiator isn't how novel the algorithm is, it's landing the "confidence scheduling" engineering idea — getting the scheduler to learn how to dynamically decide verification length based on each request's actual draft quality.

In a paper, this sounds like "it's just a scheduler," but in production, it means:

• Fairness of concurrency across requests of different lengths
• Throughput stability across different GPU cards
• Tail latency (p99) when users are typing

Each of these three is a pitfall DeepSeek hit while serving hundreds of millions of requests daily. Algorithms can be reused from papers; engineering pain can't be reused from papers — that's DeepSeek's real moat.

Conversely, DSpark is also not a "perfect answer." Its semi-autoregressive design makes the draft module heavier than purely parallel DFlash / Medusa, and it might even lose slightly on short requests; its biggest sweet spot is long context + high concurrency — the two typical production scenarios.

So if you only look at benchmark tables, DSpark won't top every category; but when you factor in "it's actually run hundreds of millions of times on DeepSeek's production line," its position in production is currently irreplaceable.

My locally running Hermes Agent has been using the DeepSeek V4 API as its primary model. The most obvious change from this DSpark upgrade is a massive speed boost for Hermes — getting a major free speed upgrade without a price change is genuinely a great deal.

What model are you using to run your local Agent now?