Parameters unchanged, benchmarks unchanged—yet the same DeepSeek-V4 suddenly generates text much faster. On June 27, 2026, Unsloth co-founder Daniel Han tweeted:
> DeepSeek just released DSpark for V4 Flash & Pro, a new speculative decoding method boosting throughput by 51% to 400%!
The tweet drew 436K views. The immediate question in the replies: can both numbers be true? The answer is yes—but they sit on entirely different curves.
Not a New Model
The Hugging Face model card for DeepSeek-V4-Pro-DSpark states in bold:
> Note: DeepSeek-V4-Pro-DSpark is not a new model. It is the same checkpoint with an additional speculative decoding module attached.
V4 Pro remains a 1.6 trillion-parameter MoE model (~49B activated); V4 Flash remains 284B (~13B activated). Knowledge, capabilities, and behavior are identical. Only the way the model emits tokens changed.
Why LLMs Generate Slowly
Autoregressive decoding generates one token at a time, with each step requiring a full pass over tens of layers. During generation, GPUs spend most of their time moving weights from memory rather than computing. Speculative decoding addresses this: a small draft model guesses several tokens ahead, and the large model verifies the whole chunk in one pass. Verification uses rejection sampling, so the output distribution is mathematically identical to standard decoding—faster, with no quality loss.
Three Curves, Three Numbers
The paper *DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation* (arXiv 2607.05147, DeepSeek-AI with Peking University) gives the most careful framing:
> Compared to the established production baseline (MTP-1), DSpark accelerates per-user generation speeds by 60 to 85 percent at matched throughput levels.
Three layers:
- 60–85%: per-user generation speedup at matched aggregate throughput (the most rigorous claim)
- ~51%: additional users served at a fixed per-user latency target (e.g., 80 tok/s), i.e., capacity gain
- 400%+: relative gains where strict latency requirements cause the old baseline to collapse; the ratio is amplified near this cliff
- Autoregressive shallow drafts (MTP, EAGLE): accurate but serial, limiting draft depth
- Parallel drafts (Medusa, DFlash): fast block emission but positions within a block are predicted independently, causing "suffix acceptance rate decay"
- vLLM (July 2): native support via
method: dspark; on 8x B300, V4-Pro-DSpark reached ~250 tok/s at batch size 1, with mean acceptance length ~5 and acceptance rate 12–42% higher than MTP. - SGLang (July 6): blog post *"DSpark in SGLang: Speculative Decoding with Confidence-Driven, Variable-Length Verification"*; reproduced the full throughput-latency Pareto curve dominating MTP, implemented variable-length verification with per-request lengths and CUDA graphs captured by actual token counts. 383.7 tok/s on B300 TP8, batch 1.
- fal (July 8): *"How We Achieved ~1000 tok/s and 16x Throughput with DSpark for Ideogram V4 Prompt Expander"*; for latency-sensitive prompt expansion (Qwen3.6 + SGLang + DSpark), 16x throughput and ~1000 tok/s—though specific to that workload, it shows DSpark works as a portable component beyond DeepSeek's own API.
How DSpark Works
Prior approaches split into two camps:
DSpark combines both. A parallel backbone produces hidden states and base logits for an entire block in one forward pass, with the most compute concentrated on the first position (whose error invalidates the whole draft). A lightweight sequential Markov head then injects the previously sampled token into each next prediction, restoring within-block dependency.
For production efficiency, a per-position confidence head predicts survival probability, calibrated via Sequential Temperature Scaling (raw error 3–8% compressed to ~1%). Combined with measured verify-speed-vs-batch curves, the engine dynamically chooses per-request verification lengths, maximizing accepted tokens × verification throughput: verify long when the system is idle, only high-confidence prefixes when busy.
Adoption Within Two Weeks
Community Reaction
Fireworks CTO Dmytro Dzhulgakov posted a ten-part thread:
> DSpark from @deepseek_ai ingeniously integrates many speculative decoding ideas to achieve 1.5x to 5x higher throughput in a real production system
He noted most individual ideas existed before; DeepSeek's strength is assembling them into a complete system that runs on real traffic. On Hacker News (797 points, 362 comments), discussion covered whether Google also publishes such work, and whether MTP weights should ship with main models. A concise comment from Noé Flandre captured the strategy:
> MTP at training time, DSpark at inference time.
Training teaches the model to predict multiple steps ahead; inference cashes that in as service speed.
The 38TB README Warning
The open-sourced DeepSpec training/evaluation framework warns that fully training a draft model for a model like Qwen3-4B under default configs can require ~38TB of cache. Most smaller teams will use official checkpoints or fine-tune drafts for vertical scenarios (code completion, support dialogs) instead.
The Takeaway
DSpark adds no knowledge, but lets the same GPUs serve more users with shorter waits. The paper's finding—that learning to depend on the previous token beats stacking deeper drafts (2-layer DSpark beats 5-layer DFlash)—raises a broader question: where to spend compute budget may matter more than how large to build the model. From the June 27 tweet to engine-level support took under two weeks: an MIT-licensed repo, weights, and engine flags moved this from "paper to read" to "deployable today."