June 27, 2026 DeepSeek released DSpark — a speculative decoding framework that accelerates response generation for DeepSeek V4 Flash and Pro by 60–85% without model retraining and without new hardware. This is not a new model — the weights are the same, an additional module for faster inference.
Spoiler: if you are already using DeepSeek V4 through the official API — DSpark is already working for you automatically, nothing needs to be enabled. If you are self-hosting the model — separate steps are required, which are detailed below.
⚡ In Brief
✅ What it is: DSpark — a speculative decoding framework for DeepSeek-V4-Flash and V4-Pro, presented in the technical report "DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation", co-authored with researchers from Peking University
✅ Numbers: per-user generation is 60–85% faster (V4-Flash) and 57–78% (V4-Pro) compared to the previous MTP-1 baseline; on offline benchmarks, accepted length is 26.7–30.9% higher compared to Eagle3 and 16.3–18.4% higher compared to DFlash
✅ Already working: DSpark has been active in the DeepSeek production API since June 27, 2026 — it operates automatically for all requests to deepseek-v4-flash and deepseek-v4-pro
✅ Open source: DeepSpec — a full MIT-licensed stack for training your own draft models, supports Qwen3 and Gemma
⚠️ Honest disclaimer: all figures are self-reported, independent verification as of late June 2026 is not yet available — the first community benchmark confirms the direction, but with significantly more modest numbers
🎯 You will get: an explanation of the mechanics in simple terms, a breakdown of where the numbers are real and where they are marketing, instructions for self-hosting, and practical advice for your DeepSeek stack
🎯 What is speculative decoding (basics for those who don't know)
Imagine you are dictating a letter to a secretary. You can dictate word by word, waiting for the secretary to write down each one — slowly, but reliably. Or you can hire a junior assistant who quickly drafts a whole paragraph based on how you usually write. The secretary then reads this draft at a glance and says, "these first five words are correct, and I'll rewrite the rest myself."
This is exactly how speculative decoding works. The "secretary" is a large model (target model) that generates the final correct text. The "junior assistant" is a small, fast draft model that proposes a block of tokens in advance. The large model then checks the entire block in one pass (not token by token) and accepts the longest correct prefix. Accepted tokens are a pure speed gain. Rejected ones simply mean the model returns to normal generation from that point.
A critically important detail: this is a lossless technique. Through rejection sampling, it is mathematically guaranteed that the final token distribution is identical to what the model would produce without speculative decoding at all. Quality does not decrease — it's not a "speed at the cost of accuracy" trade-off, but purely an engineering acceleration of the backend.
💡 Speed here is not a "bonus," but a key business metric: for any product that pays for GPU time or serves users in real-time, every percentage point of acceleration is a direct reduction in the cost per output token.
🐌 The "toothpaste" problem: why standard generation is slow
Standard autoregressive generation — the same process we detailed in the article on AI hallucination mechanics — generates exactly one token at a time. Each step requires a full forward pass through the entire model. For DeepSeek-V4-Pro, this is 1.6 trillion parameters (49 billion active per token) — an expensive pass for a single word.
Engineers call this "toothpaste-like generation": slow, drop by drop, regardless of how predictable the next piece of text is. If the model writes for i in range(, the next token is almost certainly len — but the system still spends a full, expensive pass to confirm it.
Before DSpark, there were two dominant approaches to solving this problem:
Eagle3 — a sequential (autoregressive) draft method. A small model generates tokens one by one, like the large one, but faster. It offers high acceptance accuracy but has an internal speed ceiling — it's also sequential.
DFlash — a parallel draft method. It generates the entire block of tokens simultaneously, which is fast but suffers from suffix decay: later positions in the block are guessed "blindly," without knowing what the model just chose for the preceding positions. The longer the block, the worse the acceptance accuracy towards the end.
So, the industry had a choice: fast but inaccurate (DFlash) — or accurate but slow (Eagle3). DSpark claims to bridge this gap.
🔧 What's new in DSpark: a hybrid approach
DSpark is short for Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation. The name is long, but it accurately describes what's happening: a combination of parallel and sequential approaches plus intelligent verification scheduling.
Hybrid drafting: parallel + Markov correction
DSpark uses a parallel backbone (conceptually similar to DFlash) to generate the base hidden states for all positions in the block simultaneously — this is cheap and fast. But then it adds a lightweight sequential Markov head: a rank-256 factorization that introduces a biased shift (bias) before sampling each token, based only on the immediately preceding token — not the entire prefix.
This is the trick: the head only considers one preceding token, not the whole chain, so it remains cheap and fast — but this is enough to correct the suffix decay that purely parallel DFlash suffers from.
The second innovation is dynamic verification length scheduling. Instead of blindly sending the entire block of draft tokens for verification (and wasting the large model's expensive computation on tokens that will almost certainly be rejected), DSpark has a confidence head — a separate module that estimates the probability of token acceptance.
Paired with a hardware-aware scheduler, this works as follows: when GPUs are idle — the system verifies longer prefixes, even with lower confidence, because computational resources are free. When the load is high — only tokens with the highest confidence are verified, and the low-probability "tail" is discarded immediately, without wasting batch capacity.
For production environments, the scheduler additionally uses an asynchronous Zero-Overhead Scheduling (ZOS) mechanism: the truncation length is determined based on predictions from the two previous steps, which hides scheduling latency and prevents GPU idle time.
Comparison table: DSpark vs. predecessors
Method
Drafting type
Strength
Weakness
Eagle3
Sequential (autoregressive)
High acceptance accuracy
Internal speed ceiling — still one token at a time
DFlash
Parallel
Fast block generation
Suffix decay — accuracy drops towards the end of the block
DSpark
Hybrid (parallel + Markov correction)
DFlash speed + reduced suffix decay, plus intelligent scheduling
New technique, limited official verification by independent parties
An interesting technical nuance from the original report: the 2-layer DSpark configuration outperforms the 5-layer DFlash in acceptance accuracy — a smaller and cheaper draft model yields better results due to architectural advantage, not just more parameters.
📊 Numbers: Offline Benchmarks vs. Production Results
It is important here to distinguish between two fundamentally different types of measurements, which are often mixed together in the news.
Offline Benchmarks: Controlled Tests on Qwen3
DeepSeek tested DSpark on models from the Qwen3 family (4B, 8B, 14B) under controlled offline conditions — mathematics, code generation, dialogue. The metric is accepted length, which is the average number of draft tokens a large model accepts per round. The higher it is, the faster the actual generation.
Model
Improvement over Eagle3
Improvement over DFlash
Qwen3-4B
+30.9%
+16.3%
Qwen3-8B
+26.7%
+18.4%
Qwen3-14B
+30.0%
+18.3%
The results are also generalized to Gemma4-12B — meaning the method is not exclusively tied to DeepSeek's architecture.
Production Results: Real Traffic of DeepSeek-V4
This is a separate category — measurements on live traffic of DeepSeek-V4-Flash and V4-Pro itself, compared to the previous production baseline MTP-1 (a single-token configuration that is itself not "naive" autoregression, but a prior optimization).
Model
Per-user generation speed (matched throughput)
Aggregate throughput (moderate SLA)
V4-Flash
+60% to +85%
+51% at SLA of 80 tokens/sec/user
V4-Pro
+57% to +78%
+52% at SLA of 35 tokens/sec/user
The highest results are for structured tasks: code generation has naturally high predictability of the next token (after import, something unexpected rarely follows), so the accepted length is highest there. Open dialogue is less predictable — and the acceleration there is more modest.
This is the most important section for an honest understanding of the release. In some materials about DSpark, figures of 661% (V4-Flash) and 406% (V4-Pro) flash by — and this provokes headlines like "DeepSeek accelerated the model 7 times." This is an incorrect interpretation.
These extreme numbers measure something completely different than the 60–85% described above. Here's the difference:
60–85% (per-user generation speed) — how much faster an individual user receives tokens at matched system-wide throughput. This is a fair, representative number for typical production load.
661% / 406% (aggregate throughput at strict SLA) — how many more requests the system can handle when a very strict per-user speed threshold is set (120 tokens/sec/user for Flash, 50 tokens/sec/user for Pro). This is not "overall acceleration" — it's a measurement in a mode where the old baseline (MTP-1) hits its performance ceiling and literally cannot serve as many users at such a strict SLA, while DSpark can.
In other words: 661% is not "the model became 7.6 times faster for you." It's "in a narrow, extreme service mode, the system handles 7.6 times more concurrent users at a given strict SLA — because the old system is practically choking there." This is a real and useful metric for infrastructure engineers designing capacity planning for peak loads — but it is absolutely wrong to extrapolate it to the "normal" user experience.
🎯 Practical takeaway: aim for 60–85% (Flash) and 57–78% (Pro) as a realistic estimate for typical production load. Figures with three digits of percentage are niche capacity metrics, not overall acceleration.
🛠️ DeepSpec: Open Source for Your Own Draft Models
Alongside DSpark, DeepSeek has released DeepSpec — a complete MIT-licensed stack for training and evaluating speculative decoding draft models. This is not just the DSpark code, but a whole infrastructure with three built-in algorithms: DSpark, DFlash, and Eagle3.
What's included in the repository:
Data preparation utilities
Multi-GPU training pipelines
Evaluation scripts on nine benchmarks, including GSM8K, MATH500, HumanEval, and LiveCodeBench
Support for target models: Qwen3 and Gemma — only these two families for now
An important hardware caveat: the typical configuration targets a single node with 8 GPUs. For the Qwen3-4B configuration by default, the target cache can occupy approximately 38 TB of storage — and this applies only to training, not inference. This is a project for teams with serious resources, not for a solo developer on a laptop.
For those who simply want to speed up an already trained V4 without retraining — there are ready-made checkpoints on Hugging Face: DeepSeek-V4-Flash-DSpark and DeepSeek-V4-Pro-DSpark. Important: these are not new models — it's the same checkpoint with the speculative decoding module added. The weights, training data, and output distribution have not changed.
# Running via vLLM with a ready DSpark checkpoint
pip install vllm
vllm serve "deepseek-ai/DeepSeek-V4-Pro-DSpark"
🔬 Independent Verification: What the Community Says
An honest methodology requires stating upfront: all figures from the technical report are self-reported. As of June 29, 2026, no independent verification of offline accepted-length or production figures has been published. This does not mean the figures are false — DeepSeek has a reputation from V3 and R1, where self-reported benchmarks were later confirmed. But the rule "trust but verify" applies here too.
The first community reactions, which appeared within 1–2 days after the release:
Rafael Caricio (GitHub PR, single-stream test on V4-Flash): 26.33 tokens/sec without speculative decoding → 39.88 tokens/sec with MTP-1 → approximately 60 tokens/sec with DSpark. This is approximately 1.5× over MTP-1 and 2.3× over the absence of speculative decoding altogether — the direction is confirmed, but the absolute number (60 tokens/sec for a single stream on a "bare" single-stream test) significantly differs from the marketing positioning and requires separate comparative context.
Daniel Han (Unsloth, X/Twitter): confirmed that DSpark generalizes beyond V4 — it trains successfully on Gemma and Qwen targets, not just DeepSeek's own models.
Practical caveat from the same Caricio test: in realistic multi-turn coding sessions, performance can degrade as context grows, because the acceptance of draft tokens decreases. This means DSpark speeds up decoding, but the quality of acceptance still determines how much real speed you get on your specific workload.
Simon Willison's simple test (known for his comment on the V4 launch itself — "almost at the frontier, for a fraction of the price") has not yet published a separate DSpark test, but the community's general methodology is to test on their own prompt distribution, rather than trusting a single number from a press release.
📌 What to remember: the first external test confirms the direction (DSpark is indeed faster than MTP-1), but the absolute numbers and behavior on long sessions require separate verification on your own workload — do not rely on the figures from the technical report as a guarantee for your specific use case.
🌐 Data Travels Through China: What You Should Know
This is a point that often goes unnoticed in technical reviews, but is important for anyone planning production use of DeepSeek's hosted API (not self-host).
When requests go through DeepSeek's official hosted API or web application, the data is transmitted to servers in China and falls under Chinese national legislation. DeepSeek's updated privacy policy (as of February 10, 2026) explicitly states: personal data is collected, processed, and stored within the PRC. Additionally, two laws apply: the People's Republic of China National Intelligence Law (2017), Article 7, which legally obligates all organizations and citizens to assist and cooperate with state intelligence agencies upon request, and the Cybersecurity Law of the People's Republic of China (2017), which requires network operators to provide the state with access for infrastructure inspection.
This does not mean "don't use DeepSeek" — for most neutral production tasks (RAG for public content, code generation without sensitive secrets, testing), this is an acceptable risk profile, especially considering the price. However, for regulated industries, enterprise contracts with data residency requirements, or tasks with sensitive corporate data — this is a factor that should be explicitly considered when choosing: DeepSeek's official hosted API versus self-hosted deployment of the same open weights on your own or Western cloud infrastructure.
It's important to distinguish: DSpark's speed advantages are pure engineering that operate independently of the deployment model. A team self-hosting the open V4 weights on their own or Western cloud infrastructure gets the same DSpark speed — and completely eliminates data jurisdiction issues, as user requests never reach DeepSeek's servers. The MIT license here works in your favor: you can download the weights (including the DSpark-accelerated checkpoints) and deploy them on AWS, GCP, Azure, or your own hardware.
🚀 How to try: connecting to your stack
If you are already using the official DeepSeek API or Ollama Cloud
Nothing needs to be done. DSpark has been active in the DeepSeek production API since June 27, 2026 — it is automatically applied to all requests to deepseek-v4-flash and deepseek-v4-pro through the official endpoint api.deepseek.com. This is not a switch that the API client can turn on or off externally — DeepSeek itself has migrated its production infrastructure to the new technology. If you configured the integration according to our previous guide on launching V4 Flash — you are already getting acceleration without any code changes.
If you are self-hosting DeepSeek-V4 on your own hardware
Download the ready-made DSpark checkpoint instead of the standard one and run it through vLLM:
pip install vllm
vllm serve "deepseek-ai/DeepSeek-V4-Flash-DSpark"
# or for Pro:
vllm serve "deepseek-ai/DeepSeek-V4-Pro-DSpark"
The minimum requirement is a configuration with 8 GPUs per node for a full V4 deployment. The 38-terabyte storage requirement applies only to training your own draft models through DeepSpec, not to running already prepared DSpark checkpoints.
If you want DSpark acceleration for Qwen3 or Gemma
Clone DeepSpec, prepare training data based on your real workload distribution, and train a specialized draft model. The acceptance rate on a narrow domain task (e.g., code generation for a specific framework) will be significantly higher than in general chat — this directly follows from the nature of speculative decoding: the more predictable the next token, the higher the accepted length.
Honest advice on benchmarking
Do not compare your "before" latency with naive autoregression — the baseline MTP-1 is already an optimization in itself, not a "bare" autoregressive decode. Measure your own latency before and after under your real production load and concurrency, not under DeepSeek's testing conditions.
If you access through OpenRouter
There is a nuance here that is worth understanding honestly. Unlike the official api.deepseek.com, where DSpark is DeepSeek's own solution for its infrastructure, OpenRouter is a router over several independent providers who host the V4 weights themselves. The model page on OpenRouter allows you to choose the routing mode — Balanced (price + speed), Nitro (fastest), or Exacto (fixed provider) — and each provider decides independently whether to deploy the DSpark checkpoint instead of the standard one.
Practical conclusion: if speed is critical, choose the Nitro mode and measure the real latency on your traffic — most serious inference providers have a direct incentive to switch to DSpark checkpoints, as this reduces GPU time costs on their side. However, there is no formal guarantee of "DSpark everywhere on OpenRouter" because DeepSeek does not control it. If it is fundamentally important to know that you are getting DSpark-accelerated inference, it is more reliable to go directly through api.deepseek.com, where this has been officially confirmed since June 27, 2026.
✅ Conclusions: who it is really useful for now
Useful today:
Anyone using DeepSeek V4 through the official API — gets acceleration for free and automatically
Teams self-hosting V4 on their own 8-GPU infrastructure — ready-made DSpark checkpoints provide a boost without additional training
Coding agents and structured workflows — the highest accepted length precisely on predictable tasks like code generation
Teams already working with Qwen3 or Gemma on their own hardware — DeepSpec provides a direct path to DSpark-style acceleration without waiting for official support from other providers
Too early for:
Production solutions where independently verified stability of numbers is critical — wait for additional external benchmarks
Teams without 8-GPU infrastructure who want to train their own draft models through DeepSpec — the entry barrier is high
Regulated industries using the DeepSeek hosting API without assessing data residency risks — self-hosting should be considered first
The most important fact of this release is not the 85% figure itself. It is that DeepSeek has put its own production infrastructure on DSpark and immediately open-sourced it. This is the strongest proof of the technology's readiness that exists: the company is not demonstrating a research prototype, it is showing what its real traffic is already running on.
No. DSpark is a speculative decoding module added to the existing DeepSeek-V4-Flash and V4-Pro weights. The model cards on Hugging Face clearly state: the same checkpoints with an additional draft module for acceleration. The weights, training data, and output token distribution have not changed.
Do I need to enable anything to get DSpark acceleration?
If you are using the official DeepSeek API (api.deepseek.com) — no, DSpark has been active automatically since June 27, 2026 for all requests to V4 models. If you are self-hosting the model — you need to explicitly download the DSpark checkpoint (DeepSeek-V4-Flash-DSpark or DeepSeek-V4-Pro-DSpark) instead of the standard one.
Does DSpark reduce response quality for the sake of speed?
No. Speculative decoding is a mathematically lossless technique through rejection sampling: the final token distribution is identical to what the model would produce without acceleration. This is purely a server-side engineering optimization, not a change in generation quality.
Where do the 661% and 406% figures come from if the real acceleration is 60–85%?
These are two different measurements. 60–85% is how much faster an individual user receives tokens at comparable system throughput (a realistic metric). 661%/406% is how many more concurrent users the system serves under a very strict SLA (120 and 50 tokens/sec/user respectively), where the old baseline practically hits its ceiling. This is a niche capacity metric for infrastructure planning, not general acceleration for a typical user.
Can DSpark be applied to models other than DeepSeek?
Yes, partially. DeepSpec — an open training stack — officially supports training DSpark-style draft models for Qwen3 and Gemma. Support for other model families will depend on community contributions. For DeepSeek-V4 itself, ready-made DSpark checkpoints are immediately available without training.
Is it safe to use the DeepSeek hosting API for production data?
It depends on data sensitivity. Requests through the official hosting API pass through servers in China and are subject to Chinese legislation, including the National Intelligence Law (2017). For neutral tasks, this is usually an acceptable risk given the price. For regulated industries or sensitive corporate data, it is worth considering self-hosting the same open weights on your own or Western cloud infrastructure — the MIT license allows this without restrictions.
