DFlash showed that a small block-diffusion model can draft an entire future block in one pass. That removes the serial loop from the drafter. It also creates two new costs.
First, positions in the block do not condition on the tokens that were actually sampled. Acceptance decays toward the suffix. Second, a long proposal is not free to verify. Under load, every extra draft token occupies target-model batch capacity that could have served another request.
DSpark is DeepSeek’s answer. It keeps the DFlash-style parallel backbone, adds a cheap sequential head so neighboring tokens can agree, then uses a confidence head to decide how much of the block is worth verifying.
DFlash: draft the whole block in one pass, then verify all of it
DSpark: draft the whole block in one pass
sample a locally coherent path with a tiny sequential head
verify only the prefix the scheduler expects to survive
The unique idea is the third line. DFlash 2 later showed that suffix decay can be repaired without a sequential head. DSpark’s lasting contribution is treating verification length as a serving decision, not a model hyperparameter.
Two bottlenecks after you already have a parallel drafter
Speculative decoding’s per-token latency is
\[L = \frac{T_{\text{draft}} + T_{\text{verify}}}{\tau}.\]Here $\tau$ includes the target’s bonus token when the whole draft survives. A parallel drafter collapses $T_{\text{draft}}$ to one backbone pass and makes it largely insensitive to moderate changes in block size $\gamma$. That is DFlash’s win. The remaining levers are $\tau$ (accept more) and $T_{\text{verify}}$ (verify less waste). Crucially, $T_{\text{verify}}$ itself depends on how many proposal tokens share the target batch.
DSpark argues that those two levers interact. A longer block can raise $\tau$ on math and code, then hurt throughput on chat under high concurrency, because the suffix is rejected and still occupied a verification slot.
light load verifying a shaky suffix is almost free
heavy load that same suffix steals batch from other users
A static block size is one compromise for both regimes. DSpark wants a per-request, per-step horizon.
Semi-autoregressive generation
The expensive work stays parallel. A DFlash-style backbone produces hidden states $h_1,\ldots,h_\gamma$ and base logits $U_1,\ldots,U_\gamma$ in one forward pass. DSpark makes a small input change: the anchor is treated as the first prediction position, so $\gamma$ inputs (anchor plus $\gamma-1$ masks) yield $\gamma$ draft logits.
The cheap work is sequential. A lightweight head adds a prefix-dependent bias $B_k$ and samples left to right:
\[p_k(v \mid x_0, x_{<k}) = \operatorname{softmax}\bigl(U_k(v) + B_k(x_0, x_{<k}, v)\bigr).\]$U_k$ already contains the parallel guess. $B_k$ only has to resolve local collisions: once position 1 samples "of", position 2 should prefer "course" over "problem".
The sequential module must stay tiny. If $T_{\text{sequential}}$ approaches $T_{\text{parallel}}$, DSpark has given back DFlash’s reason to exist.
The Markov head
The default head is first-order. The bias at position $k$ depends only on the previous token. A full $V \times V$ transition matrix would be huge, so DSpark uses a low-rank factorization with rank $r = 256$ by default:
\[B(x_{k-1}, \cdot) = W_1[x_{k-1}]\, W_2 \in \mathbb{R}^{V}.\]$W_1$ is an embedding lookup. $W_2$ projects back to vocabulary logits. One previous token, one matrix-vector product, a full-vocabulary correction.
parallel backbone: U1, U2, U3, U4 (all at once)
Markov sampling: anchor --+--> token 1
|
B(token 1) --+--> token 2
|
B(token 2) --+--> token 3
This is sequential, but it is not another Transformer. The paper reports that stretching draft length from 4 to 16 adds 0.2% to 1.3% full-round latency over a DFlash baseline at batch 128, while accepted length can rise by up to about 30%. The batch-size qualifier matters: target verification dominates at batch 128, so this result does not imply that sequential-head overhead is negligible at batch 1, with a smaller target, or in a less optimized runtime.
The RNN head
The Markov head is memoryless beyond one step. An RNN head keeps a recurrent state $s_k$ inside the block, mixing the previous state, the previous token embedding, and the current backbone hidden $h_k$. That helps a little at longer $\gamma$. The extra implementation cost is real, and the paper’s default remains the Markov head.
Confidence-scheduled verification
Drafting a long block is only useful if the target verifies the part that will survive. DSpark attaches a confidence head to each position:
\[c_k = \sigma\bigl(w^{\top}[h_k;\, W_1[x_{k-1}]]\bigr).\]$c_k$ is the predicted probability that position $k$ is accepted given that the prefix so far survived. The training label is free. If $p^d_k$ and $p^t_k$ are the draft and target distributions,
\[c_k^{*} = 1 - \tfrac{1}{2}\|p^d_k - p^t_k\|_1,\]which is exactly the per-step acceptance probability under speculative decoding.
“Probability” is not enough; the value must also be calibrated. The raw confidence head ranks good and bad proposals reasonably well, but the paper reports expected calibration errors of roughly 3–8%. DSpark therefore applies sequential temperature scaling. It fits one temperature per position, left to right, against cumulative prefix-survival probabilities. That preserves the ranking while bringing average calibration error to roughly 1%, so a predicted survival probability of 0.8 can be used as a quantity—not merely a score.
The scheduler does not threshold each $c_k$ in isolation. Prefix survival is a product:
\[a_j = \prod_{i \le j} c_i.\]A static threshold (verify while $c_k > 0.8$) is a useful diagnostic. In the paper’s Qwen3-4B sweep, raising that threshold lifted chat acceptance from 45.7% to 95.7% by dropping tokens that would have been rejected. Math and code needed less pruning. A fixed cutoff still ignores load: the same low-confidence token is cheap when the GPU is idle and expensive when the batch is full.
Hardware-aware prefix scheduling
DSpark treats verification length as a throughput maximization problem. For a batch of $R$ requests, each request $r$ may verify a prefix of length $\ell_r$. The target batch size in tokens is
\[B = \sum_r (1 + \ell_r),\]and the expected number of accepted tokens depends on the survival products $a_{r,j}$. The engine’s steps-per-second curve $\operatorname{SPS}(B)$ is profiled once at startup. If every request contributes one baseline token and selected extension $(r,j)$ survives with probability $a_{r,j}$, expected committed tokens are
\[E[\text{tokens}] = R + \sum_{(r,j)\in\mathcal{S}} a_{r,j}.\]The $R$ term is the target-produced token every request obtains even if no draft extension is admitted. The objective is therefore
\[\Theta(\mathcal{S}) = \left(R + \sum_{(r,j)\in\mathcal{S}} a_{r,j}\right) \operatorname{SPS}(B).\]The greedy idea is simple: initialize $B=R$, globally rank candidate prefix extensions by survival probability, admit them while $\Theta$ increases, and stop when admitting the next token would reduce throughput. Prefix ordering still matters: request $r$ cannot admit token $j+1$ unless it also admits token $j$.
request A: high-confidence math suffix keep verifying
request B: shaky chat suffix truncate early
request C: medium code prefix keep a few more
load high -> shorter prefixes, protect batch
load low -> longer prefixes, spend idle compute
Two production constraints change the textbook algorithm. Real $\operatorname{SPS}(B)$ is jagged, not smooth. CUDA graphs and zero-overhead scheduling need the next batch size before the current step finishes. DeepSeek’s deployment therefore schedules asynchronously: historical confidence from two steps prior sets the capacity cap, while current scores still rank which tokens fill that cap.
There is an important correctness boundary here. Confidence may decide how much speculative work to perform, but it cannot replace verification. Every retained token still goes through the usual target-model accept-or-correct rule. Provided the chosen horizon does not depend on unseen outcomes from the same future target sample, truncation changes compute allocation, not the output distribution. The stale capacity signal is an engineering device for making that decision early; exact rejection sampling on the retained prefix is what preserves losslessness.
How DSpark is trained
The model is optimized for more than next-token accuracy. Its loss combines three terms:
\[\mathcal{L} = \alpha_{\text{ce}}\mathcal{L}_{\text{ce}} + \alpha_{\text{tv}}\mathcal{L}_{\text{tv}} + \alpha_{\text{conf}}\mathcal{L}_{\text{conf}}.\]$\mathcal{L}{\text{ce}}$ is position-weighted hard-label cross entropy. $\mathcal{L}{\text{tv}}$ distills the full target distribution by minimizing total variation distance $|p^d_k-p^t_k|1$. $\mathcal{L}{\text{conf}}$ is binary cross entropy against the soft acceptance label above. All token-level terms use the same front-loaded weight as DFlash,
\[w_k = \exp\left(-\frac{k-1}{\gamma}\right),\]because an early error invalidates the suffix. The paper’s default coefficients are $\alpha_{\text{ce}}=0.1$, $\alpha_{\text{tv}}=0.9$, and $\alpha_{\text{conf}}=1.0$. The heavy distillation weight is meaningful: speculative acceptance depends on distributional overlap, not merely whether draft and target share an argmax.
This training recipe needs target distributions. In production, however, DSpark need not ship full-vocabulary logits between devices: target hidden states can be communicated and projected through a local copy of the LM head. That distinction matters when judging whether an algorithmic speedup survives a distributed serving stack.
What the numbers say
On offline benchmarks, DSpark retrains DFlash, EAGLE-3, and itself in one framework and on the same data. Across Qwen3-4B, 8B, and 14B, it reports 16–18% longer accepted length than DFlash and 27–31% longer than EAGLE-3. Position-wise curves show the intended split: DFlash starts strong at position 1 because the parallel backbone can be deeper; EAGLE-3 holds up better in the tail because it is autoregressive; DSpark tries to keep the strong start and flatten the tail.
A 2-layer DSpark beating a 5-layer DFlash in that setup is the efficiency argument for the sequential head: local dependence is cheaper than stacking more parallel layers.
Those are DSpark’s numbers, on DSpark’s training recipe, against DFlash v1. They are not a verdict against DFlash 2.
DSpark vs DFlash 2
Both methods start from DFlash. They disagree about how to restore local dependence.
| DSpark | DFlash 2 | |
|---|---|---|
| Backbone | DFlash-style parallel block | Same idea |
| Suffix repair | Sequential Markov or RNN head over the full vocabulary | Two-tap convolution inside the backbone |
| Token choice | Sample from corrected full-vocab logits | Score a top-$k$ candidate lattice in parallel |
| Serving idea | Confidence head plus load-aware verify length | Fixed block; keep draft fully parallel |
| Extra sequential work | Yes, but the head is small | No Transformer-level recurrence |
Inco AI’s DFlash 2 blog treats DSpark-style sequential correction as the expensive way to buy coherence. In their Qwen3-4B GSM8K ablation, a DSpark-style head added 77.8M parameters and 9.6% latency for a smaller acceptance gain than a 2.0M-parameter path selector. In their matched Qwen3.5-4B table, DFlash 2’s mean acceptance length is 5.97 against DSpark’s 5.49.
Read that as a draft-quality comparison under one setup, not as a serving comparison. DSpark’s production claim is different: on DeepSeek-V4-Flash and V4-Pro, against an MTP-1 production baseline, it reports 60–85% and 57–78% faster per-user generation at matched throughput, and it keeps useful capacity at interactivity SLAs where MTP-1 falls over. Under light load the scheduler verifies about 4–6 tokens; as concurrency rises, it shortens the prefix. One extreme percentage in the paper occurs where the baseline is already at its service boundary, which is useful operationally but should not be read as a typical model-only speedup.
DFlash 2 is the better answer to “how do we repair a parallel drafter without serializing it?” DSpark is the better answer to “how do we spend verification compute under real load?” Those are not the same question.
How to evaluate DSpark
Acceptance length is not enough. The method exists to change what the target verifies.
- Per-position acceptance, with and without the Markov head, to see whether suffix decay actually moved.
- Verified length vs accepted length. If they stay glued together as load rises, the scheduler is not pruning.
- Throughput versus tokens per second per user. This is the Pareto plot the paper cares about.
- Chat vs code vs math at the same concurrency. Chat should truncate more.
- Confidence calibration. Report ECE or reliability curves, not just ROC AUC; scheduling needs probabilities with useful numerical meaning.
- Losslessness. Any confidence truncation that peeks at future target outcomes can bias the target distribution.
If a deployment uses DSpark weights with a fixed verify width, it is using the drafter and throwing away the production scheduler. The public DeepSpec code is useful for reproducing model-side behavior, but a checkpoint alone does not reproduce DeepSeek’s profiled SPS curve, asynchronous capacity planning, CUDA-graph choices, or distributed communication path.
Final perspective
DSpark is not the next DFlash. It is a fork.
DFlash removed serial work from drafting. DSpark puts a little serial work back, on purpose, then spends its original budget on the target-model queue. DFlash 2 later showed that the serial head is not required for local coherence. The confidence scheduler remains the part that does not collapse into “just a better drafter.”
DFlash: guess the block all at once
DSpark: guess the block all at once,
repair the path cheaply,
verify only the prefix worth the target's time
The serving lesson generalizes past this family. Once draft blocks get long, the scarce resource is often not draft FLOPs. It is verification slots.
References
- Xin Cheng et al. DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation, 2026.
- Jian Chen, Yesheng Liang, and Zhijian Liu. DFlash: Block Diffusion for Flash Speculative Decoding, 2026.
- Inco AI. DFlash 2: Keep Drafting Parallel, 2026.
- Yaniv Leviathan, Matan Kalman, and Yossi Matias. Fast Inference from Transformers via Speculative Decoding, 2022.
- DeepSeek-AI. DeepSpec, 2026.