Parameters unchanged, benchmarks unchanged — yet the same DeepSeek-V4 suddenly outputs tokens far faster. On the surface it sounds like marketing. But a tweet in the early hours of June 27, 2026 made many engineers pause for a few seconds.
One tweet, two alarming numbers
The tweet came from Daniel Han, co-founder of Unsloth:
> DeepSeek just released DSpark for V4 Flash & Pro, a new speculative decoding method boosting throughput by 51% to 400%!
The attached official poster was information-dense: an architecture diagram on the left, an "accepted length" table on the right, curves in the middle, and a throughput-vs-latency frontier chart at the bottom. The top right corner emphasized, in bold: +51% to +400% throughput vs MTP.
The tweet drew 436,000 views and 3.6K likes. The first reactions weren't "how did they do it" but "can these numbers be trusted?" 51% and 400% differ by nearly eightfold — how can one technique produce both?
The answer comes later: both numbers are honest, they just sit on two entirely different curves.
The bold warning on the model card
On Hugging Face, the DeepSeek-V4-Pro-DSpark model card opens with a bold warning:
> Note: DeepSeek-V4-Pro-DSpark is not a new model. It is the same checkpoint with an additional speculative decoding module attached.
That sentence defines the whole event. V4 Pro is still the 1.6-trillion-parameter MoE model (~49B activated); V4 Flash remains 284B parameters (~13B activated). Same knowledge, same capability boundaries, same temperament. What changed is how the brain emits words.
Why LLMs speak so slowly
Counterintuitively, large models generate text one token at a time: for every token, the full stack of parameters must be computed. This is autoregressive decoding.
The problem is efficiency: during generation, GPUs spend most of their time hauling tens to hundreds of GB of weights from memory, with little time spent actually computing. The fix is speculative decoding: a smaller, faster draft model guesses several tokens ahead, then the big model verifies the whole chunk at once. Correct guesses stay; generation restarts from the first error.
Crucially, the process is mathematically exact. Verification uses rejection sampling based on the probability ratio between target and draft models, so the output distribution is identical to what the big model would generate alone. Speed changes; answers don't degrade.
Three curves, three coordinate systems
The paper *DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation* (arXiv 2607.05147, DeepSeek-AI with Peking University) makes its most careful claim:
> Compared to the established production baseline (MTP-1), DSpark accelerates per-user generation speeds by 60 to 85 percent at matched throughput levels.
That's layer one: with the same number of users and unchanged aggregate throughput, each user's generation is 60–85% faster. The most solid number.
Layer two: at interactive targets (e.g., 80 tokens/s per user), aggregate throughput rises ~51% — capacity gained on the same GPUs.
Layer three is the most misread: under extreme latency constraints, the old baseline suffers capacity collapse — queues explode and service degrades. DSpark, having reclaimed wasted verification compute, holds up, and the relative ratio in that cliff-edge regime gets amplified to 406% or higher.
Three curves, three meanings: 60–85% belongs in any serious report; 51% describes capacity; 400% only holds where latency requirements are extreme and the baseline has already collapsed.
Under the hood: why parallel drafts "get weirder"
Before DSpark, speculative decoding had two camps:
- Autoregressive shallow drafts (MTP, EAGLE): token-by-token, accurate but serial, limited depth.
- Parallel drafts (Medusa, DFlash): one forward pass emits a whole chunk, but positions within the block are predicted relatively independently, causing "suffix acceptance rate decay" — accurate first token, increasingly incoherent later ones.
- vLLM (around July 2) announced native support with a
method: dsparkoption. Official tests: on 8×B300, V4-Pro-DSpark at batch size 1 hits ~250 tokens/s with an average accepted length of ~5, acceptance rate 12–42% higher than the original MTP. - SGLang (July 6) published an engineering post, *DSpark in SGLang: Speculative Decoding with Confidence-Driven, Variable-Length Verification*, reproducing the shape of the throughput-latency frontier — DSpark dominates MTP and no-speculative-decoding across the curve. They implemented variable-length verification (different requests in a batch verify different lengths), with CUDA graphs captured per actual token count and pruned, not padded. On B300 TP8, batch size 1, V4-Pro reached 383.7 tokens/s.
- fal (July 8) delivered the most persuasive evidence from a company that doesn't build chatbots: *How We Achieved ~1000 tok/s and 16x Throughput with DSpark for Ideogram V4 Prompt Expander*. Using Qwen3.6 + SGLang + DSpark for prompt expansion in an image-generation pipeline, they reached ~1000 tokens/s — 16x baseline throughput. Caveat: 16x is specific to that workload, but it proves DSpark has become a portable general-purpose component for any latency-sensitive, batch-friendly text stage.
DSpark merges the two. Drafting happens in two stages:
1. A parallel backbone performs one forward pass to obtain hidden states and base logits for the entire block, concentrating compute on the first position — the highest-leverage spot, since one error there ruins the whole draft. 2. A very lightweight sequential head (by default a Markov head) injects the just-sampled previous token into each prediction, resolving conflicts between independent parallel predictions.
Good drafts aren't enough; verification matters in production. At high concurrency, the target model must verify roughly batch size × draft length tokens per step — verifying a doomed draft wastes compute slots belonging to other users. DSpark attaches a confidence head to each draft position, predicting survival probability, calibrated via Sequential Temperature Scaling (raw error 3–8% compressed to ~1%). Combined with the engine's measured verify-speed-vs-batch curve, the system dynamically decides each request's verification prefix length to maximize accepted tokens × verification speed. Idle system: verify longer. Busy system: verify only the confident prefix.
From paper to running service in two weeks
A paper becomes an infrastructure event when people actually integrate it. DSpark was adopted fast:
How the tech community responded
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 traced the path from memory-bound decoding through EAGLE, MTP, and DFlash, and concluded candidly: 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), the top comment noted that DeepSeek keeps publishing detailed "how it works" papers — something many US labs rarely do now. Others countered that Google still does (including the original 2022 speculative decoding paper and MTP code for Gemma 4). One short reply captured it best — Noé Flandre:
> MTP at training time, DSpark at inference time.
Training lets the model learn to predict multiple steps ahead; inference cashes that in as serving speed. The two efforts have been paving the way for each other.
The 38TB hidden in the README
DSpark ships with an open-source training/eval framework called DeepSpec, whose README carries a sobering note: under default configs, training a full draft model for something like Qwen3-4B can generate a cache of re-generated target-model answers on the order of 38TB. A real barrier. Most smaller teams should instead use the released checkpoints or fine-tune drafts for vertical scenarios (code completion, customer service) where ROI is higher. That's presumably why DeepSeek released paper, code, and weights together — a runnable repo weighs more than a readable PDF.
The race changed tracks
What's worth remembering isn't 51% or 400%. For two years, model releases were judged by parameter counts and benchmark climbs. DSpark didn't add a single bit of knowledge — it let the same GPUs serve more users and shortened every waiting person's wait.
The paper suggests a broader lesson: stacking the draft architecture deeper is less cost-effective than learning to depend on the previous token — two-layer DSpark beats five-layer DFlash. Where you spend the compute budget may matter more than how big the model should be.
From the June 27 seed tweet to vLLM, SGLang, HN, and fal following suit took under two weeks. An MIT-licensed repo, weights, and engine flags were enough to move a technique from "read the paper" to "deploy today." The same brain, with a faster mouth — which, for everyone waiting on a model's answer, is hundreds of milliseconds genuinely saved.