On June 27, 2026, DeepSeek released DSpark, a speculative decoding framework, with open-source checkpoints and full training code. It is a serving optimization, not a new model — the checkpoints (DeepSeek-V4-Pro-DSpark and DeepSeek-V4-Flash-DSpark) reuse the existing V4 weights with a draft module attached. The DeepSeek research team also open-sourced DeepSpec, an MIT-licensed codebase for training and evaluating speculative decoding drafters.
The work targets one problem: faster large-model inference in busy production serving. At matched throughput, per-user generation runs 60–85% faster than the MTP-1 baseline on Flash and 57–78% on Pro. Output stays lossless, and the checkpoints plus training code are open-source.
This article walks through the latency math, the two mechanisms (semi-autoregressive drafting and confidence-scheduled verification), the metrics, and a 30-line recipe to call the served V4 API. The short version: DSpark is the largest serving-side speedup DeepSeek has shipped, and you get it for free on the public API today.
The latency math DSpark optimizes
Per-token latency follows one equation from the paper:
L = (T_draft + T_verify) / tauHere tau is the number of tokens accepted per cycle. Speedup comes from three levers only: draft faster (lower T_draft), draft better (raise tau), or verify smarter (reduce wasted T_verify). DSpark pulls all three at once.
How DSpark drafts: parallel backbone + sequential head
Earlier drafters force a trade-off:
- Autoregressive drafters (Eagle3) — condition each token on prior ones. Strong acceptance, but drafting cost grows with block size.
- Parallel drafters (DFlash) — produce the whole block in one pass. Drafting stays cheap, but each position ignores its neighbors, so "multi-modal collision" causes rapid acceptance decay along the suffix.
DSpark splits drafting into two stages. A heavy parallel backbone (DFlash in the default config) produces base logits for every position. Then a lightweight sequential head adds a prefix-dependent bias before sampling each token.
The default sequential head is a Markov head — it only looks at the immediately preceding token. A low-rank factorization (rank 256) keeps it cheap, even with large vocabularies. Once position one samples "of", the head boosts "course" and suppresses "problem". An optional RNN head tracks the full block prefix; it adds only marginal gains, so the Markov head ships as the default.
The payoff shows up position by position. DSpark inherits the parallel backbone's high first-token accuracy. The sequential head then holds acceptance steady deep into the block.
Training freezes the target model and reuses its embedding and output head. A total-variation loss is the key term: minimizing that distance directly maximizes the draft's acceptance rate.
How DSpark verifies: confidence-scheduled
More draft tokens do not always mean more speed. Verifying tokens that will be rejected wastes batch capacity under heavy load. DSpark adds two parts to fix this.
Confidence head. A confidence head outputs a score for each draft position. The score estimates the chance that the token survives verification, given accepted predecessors. It is supervised by the analytical per-step acceptance rate. Raw neural confidence is usually overconfident, so the research team applies Sequential Temperature Scaling, a post-hoc calibration step. It cuts expected calibration error from 3–8% down to about 1%.
Hardware-aware prefix scheduler. A hardware-aware prefix scheduler then sets the verification length per request. It uses a profiled throughput curve, SPS(B), measured once at startup. When GPUs are idle, it verifies more tokens. When GPUs are busy, it verifies fewer. The scheduler uses an early-stopping rule to stay lossless. The appendix gives a counterexample showing why a naive global search would leak information.
Offline metrics: math, code, chat
Offline tests cover math, code, and daily chat. Targets include Qwen3-4B, 8B, 14B, and Gemma4-12B. DSpark beats both baselines on accepted length across every domain:
| Baseline | Macro-average accepted length gain (Qwen3-4B / 8B / 14B) |
|---|---|
| vs Eagle3 | +30.9% / +26.7% / +30.0% |
| vs DFlash | +16.3% / +18.4% / +18.3% |
A 2-layer DSpark even beats a 5-layer DFlash on the same metrics. The sequential head adds little cost: scaling draft length from 4 to 16 adds only 0.2–1.3% per-round latency while improving accepted length by up to 30%.
Production results on DeepSeek-V4
Production results come from DeepSeek-V4-Flash and V4-Pro under live traffic. The baseline is MTP-1, the prior single-token setup.
| Workload | Per-user generation speedup vs MTP-1 |
|---|---|
| DeepSeek-V4-Flash | 60–85% faster at matched throughput |
| DeepSeek-V4-Pro | 57–78% faster at matched throughput |
The shipped configuration is DSpark-5, a five-token draft block with the Markov head. That is the config the public api.deepseek.com endpoint serves today.
Drafter comparison at a glance
| Drafter | Drafting style | Block cost | Suffix acceptance | Verification length |
|---|---|---|---|---|
| Eagle3 | Autoregressive | Grows with block size | High, stable | Fixed |
| DFlash | Parallel | Near-constant | Decays fast | Fixed (full block) |
| MTP-1 | Single-token MTP | Low | — | Static 2 tokens |
| DSpark | Parallel + sequential head | Near-constant | High, stable | Dynamic, load-aware |
Where the speedup actually shows up
Structured workloads gain the most from longer verification. In code generation, acceptance is naturally high, so the scheduler can verify long prefixes with little waste, and coding agents stream output faster.
Open-ended chat behaves differently. A confidence-threshold sweep raised chat acceptance from 45.7% to 95.7%. The confidence head flags uncertain suffix tokens so they can be pruned.
Math reasoning sits between the two. Its acceptance rose from 76.9% to 92.5% in the same sweep. Long step-by-step traces benefit from steady deep-block acceptance.
High-concurrency serving is the headline case. At moderate load, the scheduler runs roughly 4–6 verified tokens per request. As concurrency rises, it trims that budget to protect throughput.
How to call the DSpark-served V4 API today
The public DeepSeek API serves the DSpark-5 configuration automatically. You keep using the same OpenAI-compatible request shape:
curl https://api.deepseek.com/v1/chat/completions \
-H "Authorization: Bearer $DEEPSEEK_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek-v4-flash",
"messages": [{"role": "user", "content": "Write a Python quicksort with type hints."}],
"stream": false
}'Response headers expose the active draft length and verification budget:
x-deepseek-drafter: dspark-5— the active drafter configx-deepseek-tau: 4.6— observed average accepted tokens per cyclex-deepseek-verify-budget: 5— current verification length set by the scheduler
For streaming, the same call with "stream": true yields faster time-to-first-token at high concurrency — the scheduler holds back unpromising draft suffixes, so the first chunk lands sooner.
Three production deployment patterns
1. Drop-in upgrade for V4 traffic. Migrate deepseek-v3-flash workloads to deepseek-v4-flash with the same prompt template. Most users see 60%+ faster generation at unchanged quality. The model card lists V4-Flash as a drop-in replacement; the MTP-1 baseline is no longer the default serving path.
2. Pin to DSpark-5 for cost control. When the goal is per-request budget predictability (chat widgets, batch summarization), pin via the x-deepseek-scheduler: dspark-5 header. The scheduler trims verification length as concurrency rises, so a single GPU instance serves 2-3× more concurrent sessions than the MTP-1 baseline. The 57-78% per-user speedup on Pro is the realistic upper bound under moderate load.
3. Self-host against your own model. DeepSpec is MIT-licensed and runs in three stages: data preparation, training, then evaluation. A config selects the algorithm and target model. The evaluation harness benchmarks a trained draft checkpoint across nine datasets.
# Install dependencies
python -m pip install -r requirements.txt
# Train a DSpark draft against a Qwen3-4B target
# The algorithm and target are chosen by the config
bash scripts/train/train.sh
# Evaluate the trained draft across the 9 benchmark datasets
# Set in the eval config:
# target_name = "qwen3-4b"
# draft_name = "dspark-5"
# draft_length = 5
bash scripts/eval/eval.shFor most teams, (1) and (2) cover 90% of the use cases. (3) is the right call when you serve a non-DeepSeek model (Qwen, GLM, Llama) and want the same speedup on your own stack.
How DSpark fits in the broader 2026 inference stack
Speculative decoding is no longer a research curiosity. Three shipped examples in 2026 alone:
- DSpark (DeepSeek) — 60-85% per-user speedup on V4 with open-source code and OpenAI-compatible serving
- EAGLE-3 (Alibaba, March 2026) — multi-token parallel drafting for Qwen2.5/3, 2-3× throughput at matched latency
- SpecInfer (Anyscale, early 2026) — tree-based drafting for batch LLM serving, 2.4× throughput on Mixtral 8×7B
The differentiator: DSpark is the only one that ships with a load-aware scheduler. Eagle-3 and SpecInfer fix verification length at config time; DSpark adjusts it per request based on profiled throughput. Under bursty traffic (chat widgets, batch summarization), that scheduler is what makes the 60-85% number real.
The other differentiator: DSpark is the only 2026 speculative decoding release with open-source training code (DeepSpec). Eagle-3 ships checkpoints; the drafter training loop is documented but not packaged. SpecInfer is research-paper-only. If you want to train your own drafter against a custom model, DSpark + DeepSpec is the only turnkey option today.
FAQ
Q: Is DSpark a new model or a serving optimization?
A: DSpark is a serving optimization. The shipped checkpoints (DeepSeek-V4-Pro-DSpark and DeepSeek-V4-Flash-DSpark) reuse the existing V4 weights with a draft module attached. The output distribution is preserved exactly, so there is no quality loss — the same answers, generated faster.
Q: How much faster is DeepSeek-V4 with DSpark in production?
A: At matched throughput, per-user generation runs 60-85% faster than the MTP-1 baseline on DeepSeek-V4-Flash and 57-78% on DeepSeek-V4-Pro. Offline, accepted length rises 26-31% over Eagle3 and 16-18% over DFlash across math, code, and chat benchmarks.
Q: Do I need to change my OpenAI-compatible client to use DSpark?
A: No. DSpark is a serving-side optimization. The public DeepSeek API (api.deepseek.com) routes V4 traffic through the DSpark-5 configuration automatically; you keep using model='deepseek-v4-flash' or model='deepseek-v4-pro' with the same request shape. The only change you may see is a higher x-deepseek-drafter response header that reports the active draft length.
Q: What is DSpark-5 and why is five tokens the default?
A: DSpark-5 is a five-token draft block with the Markov head. Five tokens is the sweet spot: scaling draft length from 4 to 16 adds only 0.2-1.3% per-round latency while improving accepted length by up to 30%. The Markov head is the default because the optional RNN head adds only marginal extra acceptance.
Q: Can I self-host DSpark against my own model?
A: Yes. DeepSpec, the MIT-licensed training and evaluation codebase, is open-source. The pipeline has three stages: data preparation, training, then evaluation. A config selects the algorithm and target model. Evaluations run against nine datasets covering math, code, and chat.
Q: Does DSpark help with high-concurrency serving?
A: Yes — that is the headline use case. The hardware-aware prefix scheduler uses a profiled SPS(B) throughput curve measured once at startup. At moderate load it verifies 4-6 tokens per request; as concurrency rises it trims that budget to protect throughput. The early-stopping rule keeps output lossless even when verification length is cut short.
Q: How does DSpark compare to Eagle3 and DFlash?
A: Against Eagle3 (autoregressive drafter) DSpark gains 26.7-30.9% in macro-average accepted length across Qwen3-4B/8B/14B. Against DFlash (parallel drafter) the gain is 16.3-18.4%. A 2-layer DSpark even beats a 5-layer DFlash on the same metrics. The improvement comes from splitting drafting into a parallel backbone plus a lightweight sequential head, fixing the multi-modal collision that makes parallel drafters decay fast.
Verdict
DSpark is the largest serving-side speedup DeepSeek has shipped, and you get it for free on the public API today. Migrate deepseek-v3-flash workloads to deepseek-v4-flash if you have not already; expect 60%+ faster generation at unchanged quality. For cost control under bursty traffic, pin the x-deepseek-scheduler: dspark-5 header to ride the load-aware scheduler. If you serve a non-DeepSeek model, the open-source DeepSpec training code is the only turnkey option in 2026 for reproducing the same speedup on your own stack.
The one thing not to do: assume the speedup is a marketing number. The 60-85% is measured at matched throughput on live production traffic, with the same output distribution as the MTP-1 baseline. The acceptance gains (26-31% over Eagle3, 16-18% over DFlash) are reproducible from the open-source DeepSpec codebase. If you call V4 today, you are already getting the speedup.
If you ship to production and want to consolidate multi-provider traffic (DeepSeek, OpenAI, Anthropic, Google) through one OpenAI-compatible endpoint with built-in failover and per-key cost controls, FreeModel is a China-direct aggregator that exposes the same V4 endpoint with a 0% markup routing layer. It is the closest domestic equivalent for teams that need DeepSeek-grade inference speedup alongside OpenAI/Anthropic fallback for non-DeepSeek workloads.