/bin/zsh -lc "/tmp/deepspec-pdf-venv/bin/python - <<'PY' >/tmp/dspark_paper.txt
from pypdf import PdfReader
reader=PdfReader('/tmp/DSpark_paper.pdf')
for i,page in enumerate(reader.pages, start=1):
    print(f'\\n\\n--- PAGE {i} ---')
    print(page.extract_text() or '')
PY
rg -n \"Table 1|Table 2|Table 3|macro-average|accepted length|V4-Flash|V4-Pro|60%|85%|57%|78%|DFlash|Eagle3|throughput|confidence|scheduler|Qwen3\" /tmp/dspark_paper.txt | sed -n '1,240p'"


binary file matches (found "\0" byte around offset 11852)


/bin/zsh -lc "tr -d '\\000' < /tmp/dspark_paper.txt > /tmp/dspark_paper_clean.txt
rg -n \"Table 1|Table 2|Table 3|macro-average|accepted length|V4-Flash|V4-Pro|60%|85%|57%|78%|DFlash|Eagle3|throughput|confidence|scheduler|Qwen3\" /tmp/dspark_paper_clean.txt | sed -n '1,260p'"


19:wastes critical batch capacity on tokens with high rejection risks, severely degrading throughput
21:that unifies high-throughput parallel generation with adaptive, load-aware verification. To
24:and mitigate suffix decay. To optimize system efficiency, DSpark employs confidence-scheduled
26:prefix survival probabilities and engine-specific throughput profiles. On offline benchmarks
27:across diverse domains, DSpark substantially improves the accepted length over state-of-the-art
31:60%–85% at matched throughput levels. More importantly, by preventing severe throughput
66:blocks, indiscriminately verifying all proposed tokens degrades system throughput, particularly
74:unifies high-throughput parallel generation with adaptive, load-aware verification. At its core,
81:• Second, to resolve the system-level bottleneck, DSpark employs confidence-scheduled
82:verification. By coupling a confidence head—which estimates per-position prefix survival
83:probabilities—with a hardware-aware scheduler, DSpark dynamically tailors the verifica-
84:tion length for each request. This scheduler leverages real-time engine throughput profiles
93:across the Qwen3-4B, 8B, and 14B target models (Yang et al., 2025), it improves the macro-average
94:accepted length over the autoregressive Eagle3 (Li et al., 2026b) by 30.9%, 26.7%, and 30.0%, and
95:over the parallel DFlash (Chen et al., 2026) by 16.3%, 18.4%, and 18.3%, respectively. Beyond top-
102:envelope. Specifically, it consistently accelerates per-user generation speeds by 60%–85% (V4-
103:Flash) and 57%–78% (V4-Pro) at matched aggregate throughput capacities. Furthermore, under
106:robust throughput. By overcoming this performance cliff, DSpark unlocks strict interactivity
110:the DeepSeek-V4-Flash (preview) and DeepSeek-V4-Pro (preview) models. Furthermore, we
111:open-source DeepSpec, an algorithm-driven training repository, including Eagle3, DFlash and
150:attention, but the large number of verification tokens reduces overall serving throughput.
155:Among them, DFlash (Chen et al., 2026) is a state-of-the-art parallel drafter, which conditions
173:drafting requires only a single forward pass regardless of block size, DFlash can afford deeper
179:predicted independently. Meanwhile, fixed-length verification wastes𝑇verify on low-confidence
185:• Confidence-scheduled verification(Section 3.2). A confidence head estimates per-position
186:acceptance probabilities, and a hardware-aware scheduler uses these estimates to prune
187:low-confidence suffix tokens, cutting unnecessary verification compute.
218:confidence scores 𝑐1–𝑐4 . The Hardware-Aware Prefix Scheduler then evaluates these scores to
219:retain the prefix EFG and drop the low-confidence token H . Finally, the target model verifies
233:Parallel stage.A parallel backbone (in our instantiation, DFlash (Chen et al., 2026)) runs a
235:𝑈1,... ,𝑈𝛾. We make only a minor modification to the original DFlash backbone: instead of
284:throughput, especially in high-concurrency scenarios (Hu et al., 2026; Liu et al., 2024c).
299:achieves this by coupling aconfidence head(Section 3.2.1) that predicts prefix survival proba-
300:bilities, with ahardware-aware prefix scheduler(Section 3.2.2) that dynamically determines the
303:Drawing inspiration from Huang et al. (2024); Wang et al. (2026), the confidence head outputs a
324:et al., 2024b; Zhang et al., 2026b), which only require confidence scores to correctly rank draft
327:expected acceptance length𝜏. Because neural confidence estimates are often overconfident (Guo
328:et al., 2017; Ovadia et al., 2019), using the raw confidence scores directly would distort the
329:throughput estimation, leading to suboptimal scheduling.
340:confidence head.
347:Require: Active requests𝑟∈{ 1,... ,𝑅}; confidence sequence𝑐𝑟,1,... ,𝑐𝑟,𝛾 per request; profiled
362:9:Current throughputΘ←𝜏 ∗·SPS(𝐵)
374:confidence scores to determine verification length. While effective under isolated, single-request
377:To address this, we formulate verification length selection as a global throughput maximiza-
379:be the per-position confidence estimates, and letℓ𝑟∈{ 0,... ,𝛾} denote the scheduled verification
389:. Let SPS(𝐵) denote the engine throughput, measured in steps per second, for
391:initialization and stored as a lightweight cost table. Our scheduler then aims to maximize the
392:expected system-wide token throughput Θ=𝜏·SPS(𝐵) by dynamically selecting verification
409:sorted pool, updating the expected throughput Θ via an𝑂(1) lookup from the pre-profiled cost
413:Because our confidence head relies on the Markov feature of the previously sampled token,
418:To enforce strict causality, the scheduler (Algorithm 1) employs an early-stopping mech-
419:anism. By breaking the greedy search immediately when the throughput drops ( Θ≤Θ best),
422:this stepwise early-stopping yields the global maximum throughput if and only if the objective
430:updating only the backbone drafter, sequential block, and confidence head.
432:matching loss Ltv, and a confidence loss Lconf. All three are position-weighted by 𝑤𝑘 =
455:the expected acceptance rate. The confidence lossLconf is a binary cross-entropy that trains the
456:confidence head to predict the soft acceptance label𝑐∗
477:the effectiveness of confidence scheduler under online production traffic in Section 5. The
482:scales and model families: Qwen3-{4B, 8B, 14B} (Yang et al., 2025), and Gemma4-12B (Google
484:DFlash (Chen et al., 2026), a state-of-the-art parallel drafter, and Eagle3 (Li et al., 2026b), an
486:drafters in the same training framework and on the same data. We align Eagle3’s TTT horizon (7)
487:with the block size (7) used by DFlash and DSpark, and we use the same target-model feature
488:layers for all drafters. For the number of draft model layers, we set 1 for Eagle3 and 5 for DSpark
489:and DFlash (Chen et al., 2026). Unless otherwise stated, DSpark denotes the Markov-head
505:2023) with the sampling temperature set to 1.0. We report the accepted length (𝜏) per decoding
508:3For clarity, unless otherwise stated, all reported metrics for accepted length and acceptance rate include the
514:Table 1| Main speculative decoding results.We report accepted length ( 𝜏) per decoding
518:Qwen3-4B
519:Eagle3 5.14 4.62 3.92 3.69 4.16 3.77 2.39 2.26 2.55
520:DFlash 5.40 4.85 4.15 4.40 4.74 4.18 3.07 2.96 2.83
522:Qwen3-8B
523:Eagle3 5.30 4.77 3.91 3.96 4.33 4.17 2.66 2.54 2.54
524:DFlash 5.33 4.91 4.07 4.36 4.64 4.39 3.11 2.98 2.81
526:Qwen3-14B
527:Eagle3 5.24 4.60 3.71 3.81 4.14 4.01 2.62 2.47 2.48
528:DFlash 5.41 4.84 3.98 4.44 4.59 4.33 3.10 2.94 2.72
531:Eagle3 5.87 5.46 4.83 4.72 5.37 4.16 3.19 3.06 2.72
532:DFlash 5.45 5.04 4.22 4.39 4.95 3.70 2.98 2.84 2.59
536:disables the confidence scheduler, forcing all drafters to propose a fixed block of tokens. The
537:main results, measured by the average accepted length (𝜏) per round, are reported in Table 1.
538:DSpark consistently outperforms both the autoregressive baseline (Eagle3) and the parallel
539:baseline (DFlash) across all evaluated target models and benchmark domains. Specifically,
540:across the Qwen3-4B, 8B, and 14B models, DSpark improves the macro-average accepted length
541:over Eagle3 by 30.9%, 26.7%, and 30.0%, respectively. Similarly, compared to DFlash, DSpark
545:Beyond the average improvements, Table 1 reveals a strong domain effect: the accepted
546:length is naturally higher on structured tasks (e.g., 5.57 on math and 5.12 on code for Qwen3-4B)
549:This directly motivates our confidence-scheduled verification, which dynamically prunes the
553:Table 1 presents a counter-intuitive observation: the parallel drafter (DFlash) and the semi-
554:autoregressive drafter (DSpark) often yield longer accepted lengths than the fully autoregressive
555:drafter (Eagle3). This finding contrasts with the standard expectation that step-by-step autore-
558:To analyze this behavior, we examine performance beyond the macro-level accepted length.
559:Using the Qwen3-4B target model and the benchmark sets described in Section 4.1, we introduce
591:DFlash Eagle3 DSpark
593:rate for each draft position, averaged across benchmarks within each domain using the Qwen3-
596:sive drafter (Eagle3) remains stable or trends upward, while the parallel drafter (DFlash) suffers
605:strictly from architectural capacity: autoregressive models like Eagle3 are constrained to shallow
607:networks. This structural gap yields a substantial accuracy margin at position 1, with DFlash
608:starting noticeably higher than Eagle3 (e.g., 0.88 vs. 0.81 on Math, and 0.72 vs. 0.53 on Chat).
611:Consequently, this initial capacity advantage disproportionately boosts the final accepted length,
617:Autoregressive models like Eagle3 effectively leverage this conditional certainty, maintaining or
619:contrast, DFlash suffers from rapid acceptance decay, dropping from 0.87 to 0.78 on Code and
641:Method DSpark DFlash
645:DFlash baseline, highlighting the parameter efficiency of sequential modeling.
683:DSpark (markov) DSpark (rnn) DFlash
685:DFlash across various block sizes (left three panels). The rightmost panel demonstrates that the
695:size 𝛾). Unless otherwise stated, all experiments in this section use Qwen3-4B as the target
699:DSpark layers from 1 to 5, comparing it against a 5-layer DFlash baseline. Figure 3 aggregates the
700:accepted lengths across the math, code, and chat domains. As expected, DSpark’s performance
702:layers. Notably, a 2-layer DSpark outperforms the 5-layer DFlash baseline across all domains.
713:three panels of Figure 4 show that DSpark consistently outperforms DFlash at every proposal
715:parallel generation (DFlash) suffers from rapid acceptance decay (Figure 2), its marginal utility
716:diminishes for long blocks. DSpark mitigates this decay, causing its relative gain over DFlash
717:to grow. For instance, at𝛾= 7, DSpark improves the accepted length by 16% on math, 15% on
729:0.2% to 1.3% to the full-round latency over the DFlash baseline, despite delivering up to a 30%
730:improvement in accepted length.
735:blind verification a waste of target compute. To evaluate whether the confidence head can
737:Qwen3-4B. We validate the estimator in isolation here, reserving the hardware-aware prefix
738:scheduler (Section 3.2.2) for live production evaluation in Section 5.
740:the overall acceptance rate (line) across confidence thresholds. As the threshold increases, the
742:rejected (hashed bars). This suggests that the confidence head can identify lower-value suffix
768:60%
778:confidence head effectively prunes tokens that would ultimately be rejected (hashed bars).
802:Figure 6| The Reliability Diagram on Alpaca Dataset.While the raw confidence estimator
806:different confidence bins.
809:verifying low-confidence tokens incurs minimal opportunity cost under low concurrency, but
811:hardware-aware prefix scheduler. As formulated in Section 3.2, maximizing system-level
812:throughput requires the confidence model to exhibit both strong predictive discrimination
816:3%–8%). Applying post-hoc STS (Section 3.2.1) mitigates this overconfidence, reducing the
827:optimizations necessary to deploy the hardware-aware prefix scheduler (Section 3.2.2), and the
830:The DSpark draft models are co-deployed with the preview versions of DeepSeek-V4-Flash and
831:DeepSeek-V4-Pro (DeepSeek-AI, 2026). The parallel backbone comprises three MoE layers (Dai
834:the confidence head is trained end-to-end alongside the draft model and subsequently calibrated
860:To navigate the trade-offs among system compatibility, throughput, and algorithmic correct-
861:ness, we adapt the scheduler to operate asynchronously. Because ZOS requires the batch size for
864:using the confidence head outputs from two steps prior. Mechanically, the candidate tokens in
865:the current step are still strictly sorted by their actual, up-to-date cumulative confidence scores;
878:prevent the scheduler from being trapped in local minima by jagged SPS cliffs, we remove the
885:barrier, maximizing physical throughput across hardware cliffs while preserving the exact target
889:objectives: per-request latency and aggregate throughput (Kwon et al., 2023; Zhao et al., 2025a;
899:simplifies: given a fixed concurrency limit, maximizing per-GPU total token throughput and
902:To achieve this maximum throughput, the asynchronous scheduler (Section 5.2) actively
913:to support this variable-length routing, allowing the dynamic scheduler to operate seamlessly
926:DeepSeek-V4-Flash
927:+51% throughput
928:+60% TPS
929:+661% throughput
930:+85% TPS
939:DeepSeek-V4-Pro
942:+52% throughput
943:+57% TPS
944:+406% throughput
945:+78% TPS
947:Figure 7| Throughput vs. TPS.Aggregate output token throughput against per-request genera-
949:observed throughput–interactivity frontier relative to the MTP-1 baseline under the measured
953:1 (DeepSeek-AI, 2024) baseline within the production serving engines of DeepSeek-V4-Flash (pre-
954:view) and DeepSeek-V4-Pro (preview). MTP-1 represents the former production setup, having
957:drafter (e.g., MTP-3/5) strictly degrades aggregate throughput under high concurrency due to
964:throughput and per-user generation speed (interactivity). To quantify DSpark’s behavior under
968:For the V4-Flash engine, we evaluate the system at SLA anchors of 80 and 120 tok/s/user.
969:At the moderate 80 tok/s/user SLA, DSpark improves aggregate throughput by 51% over the
972:can sustain only a very small concurrent batch. Consequently, the relative throughput ratio
974:throughput. We therefore interpret this high-SLA point primarily as evidence that DSpark
976:over a well-utilized baseline. At matched practical throughput levels, which provide a more
977:stable comparison, DSpark accelerates per-user generation speeds by 60% to 85%.
982:The V4-Pro deployment shows the same pattern. At the moderate 35 tok/s/user SLA,
983:DSpark improves aggregate throughput by 52%. At the stricter 50 tok/s/user SLA, MTP-1
984:again enters a low-concurrency regime, yielding a nominal 406% relative throughput advantage
985:for DSpark. As with V4-Flash, we treat this point as an indication that DSpark sustains useful
986:throughput under an interactivity target that the baseline cannot efficiently support. At matched
987:system capacities, DSpark delivers 57% to 78% faster per-user generation. Overall, these results
988:show that DSpark shifts the observed throughput–interactivity frontier outward: it improves
989:throughput in moderate-SLA regimes and, more importantly, preserves non-degenerate serving
996:DeepSeek-V4-Flash
1003:DeepSeek-V4-Pro
1020:Figure 8| Load-adaptive throughput and verification budgets.Top row (a, b): Aggregate output
1021:throughput across varying levels of system concurrency. Bottom row (c, d): The average target
1022:verification budget allocated per request. As concurrent load increases, the dynamic scheduler
1025:these gains by plotting aggregate throughput (top row) and the dynamic verification budget
1028:than 200 concurrent requests for V4-Flash and 150 for V4-Pro), the hardware-aware sched-
1032:throughput gains observed on the Pareto frontier.
1033:• As system concurrency scales and target capacity saturates, the scheduler dynamically
1035:suring that low-confidence draft tokens are pruned before they consume critical batch
1043:Limitations.Although the prefix scheduler minimizes wasted target-model verification, DSpark
1064:DFlash use diffusion-inspired prediction to generate entire blocks in a single forward pass (An
1066:trees (Ringel and Romano, 2026). Concurrent efforts also improve DFlash: Domino (Huang et al.,
1072:confidence heuristics (Du et al., 2024; Li et al., 2024b; Liu et al., 2026c; Mamou et al., 2024; Wen and
1113:formulate verification length selection as a global throughput maximization problem, employing
1114:a hardware-aware prefix scheduler that dynamically tailors the target model’s verification
1399:Magicdec: Breaking the latency-throughput tradeoff for long context generation with spec-
1466:Z. Wen and Y. Feng. Specbound: Adaptive bounded self-speculation with layer-wise confidence
1510:A. Yang, A. Li, B. Yang, B. Zhang, B. Hui, B. Zheng, B. Yu, C. Gao, C. Huang, C. Lv, et al. Qwen3
1560:large language model serving throughput. In Proceedings of the 19th USENIX Conference on
1572:must be determined by scheduler-visible information available before the token𝑥𝑟,𝑘 is sampled.
1574:(𝑅= 1) and maximum draft length (𝛾= 2). Suppose the pre-token confidence for the first position
1577:The expected throughputs for verifying 0 and 1 draft tokens are
1580:Without early-stopping, the scheduler proceeds to evaluate Θ2 before committing any admission
1581:decisions. Because the Markov confidence head uses the previously sampled token, the next
1582:confidence score𝑐2 explicitly depends on the realization of𝑥1. Consequently, the second-prefix
1588:The expected throughput for length 2 is
1590:Since Θ2 is the global maximum among{1.0, 0.9, 1.134}, the scheduler returnsℓ= 2. The
1594:The expected throughput for length 2 is
1596:Here, the global maximum remains Θ0 = 1.0, so the scheduler returnsℓ= 0. The first token
1599:token itself. This retrospective dependence introduces selection bias: the scheduler favors tokens
1614:matching the assumed value (𝑎1 = 0.8). Suppose the retrospective scheduler behaves as above:
1615:𝑥1 =𝐴 yields a high continuation confidence and hence ℓ= 2, while 𝑥1 =𝐵 yields a low
1616:continuation confidence and henceℓ= 0. Then the first output token is distributed as follows. If
1635:that the retrospective scheduler is not lossless. The early-stopping mechanism prevents this
1636:issue in the causal greedy scheduler. Since Θ1 <Θ 0, the scheduler halts immediately and returns


The DSpark paper is usable now. The key app-worthy finding is the “why”: DSpark is not just another checkpoint row; it combines DFlash-style parallel block drafting with a tiny sequential dependency head, then schedules verification length by confidence and live serving load.


/bin/zsh -lc "sed -n '500,550p' /tmp/dspark_paper_clean.txt
sed -n '920,990p' /tmp/dspark_paper_clean.txt
sed -n '630,650p' /tmp/dspark_paper_clean.txt
sed -n '680,732p' /tmp/dspark_paper_clean.txt"


2. Code Generation, including MBPP (Austin et al., 2021b), HumanEval (Chen et al., 2021)
and Live-CodeBench (Jain et al., 2025).
3. Daily Chat, including MT-Bench (Zheng et al., 2023), Alpaca (Taori et al., 2023) and
Arena-Hard (Li et al., 2024a, 2025b).
For all benchmarks, we use standard speculative decoding (Chen et al., 2023; Leviathan et al.,
2023) with the sampling temperature set to 1.0. We report the accepted length (𝜏) per decoding
round3. For all drafters, we use chain-based drafting.
2https://huggingface.co/datasets/mlabonne/open-perfectblend
3For clarity, unless otherwise stated, all reported metrics for accepted length and acceptance rate include the
target-generated bonus token.
10

--- PAGE 11 ---
Table 1| Main speculative decoding results.We report accepted length ( 𝜏) per decoding
round (higher is better) for different target models and domains.Boldmarks the best results.
Target Drafter Math Code Chat
GSM8K MATH AIME25 MBPP HumanEval LCB MT-Bench Alpaca Arena-Hard
Qwen3-4B
Eagle3 5.14 4.62 3.92 3.69 4.16 3.77 2.39 2.26 2.55
DFlash 5.40 4.85 4.15 4.40 4.74 4.18 3.07 2.96 2.83
DSpark6.11 5.70 4.89 5.13 5.38 4.86 3.64 3.54 3.29
Qwen3-8B
Eagle3 5.30 4.77 3.91 3.96 4.33 4.17 2.66 2.54 2.54
DFlash 5.33 4.91 4.07 4.36 4.64 4.39 3.11 2.98 2.81
DSpark6.17 5.78 5.01 5.16 5.52 5.17 3.72 3.58 3.21
Qwen3-14B
Eagle3 5.24 4.60 3.71 3.81 4.14 4.01 2.62 2.47 2.48
DFlash 5.41 4.84 3.98 4.44 4.59 4.33 3.10 2.94 2.72
DSpark6.21 5.74 4.94 5.26 5.43 5.02 3.70 3.58 3.13
Gemma4-12B
Eagle3 5.87 5.46 4.83 4.72 5.37 4.16 3.19 3.06 2.72
DFlash 5.45 5.04 4.22 4.39 4.95 3.70 2.98 2.84 2.59
DSpark6.05 5.78 5.12 5.11 5.64 4.51 3.49 3.35 2.92
4.2. Experimental Results
To isolate the raw draft quality from system-level scheduling policies, our offline evaluation
disables the confidence scheduler, forcing all drafters to propose a fixed block of tokens. The
main results, measured by the average accepted length (𝜏) per round, are reported in Table 1.
DSpark consistently outperforms both the autoregressive baseline (Eagle3) and the parallel
baseline (DFlash) across all evaluated target models and benchmark domains. Specifically,
across the Qwen3-4B, 8B, and 14B models, DSpark improves the macro-average accepted length
over Eagle3 by 30.9%, 26.7%, and 30.0%, respectively. Similarly, compared to DFlash, DSpark
yields relative improvements of 16.3%, 18.4%, and 18.3% across the three scales. Crucially, this
advantage generalizes across model families, as demonstrated by the consistent performance
gains on the Gemma4-12B target.
Beyond the average improvements, Table 1 reveals a strong domain effect: the accepted
length is naturally higher on structured tasks (e.g., 5.57 on math and 5.12 on code for Qwen3-4B)
than on open-ended chat (3.49). This inherent variance in data predictability means a static
verification length often wastes compute on trailing tokens that are highly likely to be rejected.
This directly motivates our confidence-scheduled verification, which dynamically prunes the
draft block based on expected acceptance.
0
5k
10k
15k
20k
Throughput (token/s/gpu)
DeepSeek-V4-Flash
+51% throughput
+60% TPS
+661% throughput
+85% TPS
20 40 60 80 100 120
0
1k
2k
3k
4k
5k
6k
DeepSeek-V4-Pro
MTP
DSpark
+52% throughput
+57% TPS
+406% throughput
+78% TPS
TPS (token/s/user)
Figure 7| Throughput vs. TPS.Aggregate output token throughput against per-request genera-
tion speed (tok/s/user) under live traffic. In our production deployment, DSpark improves the
observed throughput–interactivity frontier relative to the MTP-1 baseline under the measured
traffic and engine configurations.
5.4. Performance under Live User Traffic
We evaluate DSpark-5 (configured with a maximum draft length of 𝛾= 5) against the MTP-
1 (DeepSeek-AI, 2024) baseline within the production serving engines of DeepSeek-V4-Flash (pre-
view) and DeepSeek-V4-Pro (preview). MTP-1 represents the former production setup, having
been superseded by DSpark two weeks following the DeepSeek-V4-preview release. This single-
token setup was historically maintained in production because deploying a static multi-token
drafter (e.g., MTP-3/5) strictly degrades aggregate throughput under high concurrency due to
excessive verification overhead. Therefore, comparing DSpark against this established baseline
directly demonstrates its ability to safely unlock the performance potential of larger draft blocks
in dynamic serving environments. In all figures, the scatter points represent raw telemetry data
sampled directly from live user traffic, capturing complex, real-world request distributions,
while the solid lines represent the fitted performance frontiers.
The Serving Pareto Frontier.Figure 7 illustrates the trade-off between aggregate system
throughput and per-user generation speed (interactivity). To quantify DSpark’s behavior under
practical deployment constraints, we evaluate the system at several interactivity SLA anchors.
Here, an SLA (Service Level Agreement) specifies the minimum per-user generation speed (in
tokens per second) that the system must guarantee.
For the V4-Flash engine, we evaluate the system at SLA anchors of 80 and 120 tok/s/user.
At the moderate 80 tok/s/user SLA, DSpark improves aggregate throughput by 51% over the
MTP-1 baseline. The stricter 120 tok/s/user SLA represents a qualitatively different regime:
under this constraint, the single-token MTP-1 baseline approaches its operational boundary and
can sustain only a very small concurrent batch. Consequently, the relative throughput ratio
at this point is numerically large, with DSpark achieving a nominal 661% higher aggregate
throughput. We therefore interpret this high-SLA point primarily as evidence that DSpark
extends the feasible interactivity frontier, rather than as a representative multiplicative speedup
over a well-utilized baseline. At matched practical throughput levels, which provide a more
stable comparison, DSpark accelerates per-user generation speeds by 60% to 85%.
18

--- PAGE 19 ---
The V4-Pro deployment shows the same pattern. At the moderate 35 tok/s/user SLA,
DSpark improves aggregate throughput by 52%. At the stricter 50 tok/s/user SLA, MTP-1
again enters a low-concurrency regime, yielding a nominal 406% relative throughput advantage
for DSpark. As with V4-Flash, we treat this point as an indication that DSpark sustains useful
throughput under an interactivity target that the baseline cannot efficiently support. At matched
system capacities, DSpark delivers 57% to 78% faster per-user generation. Overall, these results
show that DSpark shifts the observed throughput–interactivity frontier outward: it improves
throughput in moderate-SLA regimes and, more importantly, preserves non-degenerate serving
capacity under strict interactivity constraints.
GSM8K MATH500 AIME25 MBPP
HumanEval
LiveCodeBench
MT-Bench Alpaca
Arena-Hard v2
2
3
4
5
6
Accepted Length
Method DSpark DFlash
Depth 1L 2L 5L
Figure 3| Effect of drafter depth.With proposal length fixed, DSpark’s performance improves
as drafter layers are added. Notably, a shallow 2-layer DSpark outperforms a deeper 5-layer
DFlash baseline, highlighting the parameter efficiency of sequential modeling.
4 8 12 16
4
5
6
7Accepted Length
+0.9%
+1.3%
Draft Length
DSpark (markov) DSpark (rnn) DFlash
Figure 4| Effect of proposal length and latency overhead.DSpark consistently outperforms
DFlash across various block sizes (left three panels). The rightmost panel demonstrates that the
sequential head introduces minimal latency overhead during serving.
motivates DSpark’s semi-autoregressive design. As shown in Figure 2, DSpark inherits the high
initial acceptance of the deep parallel drafter (e.g., starting at 0.93 on Math). Simultaneously, its
lightweight sequential head mitigates the rapid acceptance decay typical of parallel generation.
By resolving this trade-off, DSpark maintains a high and stable conditional acceptance rate
throughout the entire draft block.
4.3.2. A Little Autoregression Goes a Long Way
Building on the insights from Section 4.3.1, we explore the architectural design space of DSpark
along two dimensions: drafter depth (number of transformer layers) and proposal length (block
size 𝛾). Unless otherwise stated, all experiments in this section use Qwen3-4B as the target
model and follow the evaluation protocol detailed in Section 4.1.
Drafter Depth.Increasing the number of transformer layers naturally expands a draft model’s
predictive capacity. To isolate this effect, we fix the block size to 7 and vary the number of
DSpark layers from 1 to 5, comparing it against a 5-layer DFlash baseline. Figure 3 aggregates the
accepted lengths across the math, code, and chat domains. As expected, DSpark’s performance
improves monotonically with depth, with the steepest marginal gain occurring from one to two
layers. Notably, a 2-layer DSpark outperforms the 5-layer DFlash baseline across all domains.
13

--- PAGE 14 ---
This demonstrates that injecting local auto-regression via a lightweight sequential head offers a
highly favorable accuracy-parameter trade-off, achieving better sequence coherence than simply
stacking deeper parallel layers.
Proposal Length.Next, we fix the drafter depth to 5 layers and scale the draft length (proposal
length 𝛾 plus one anchor token) across{4, 8, 12, 16} to evaluate performance on longer draft
blocks. For DSpark, we evaluate both the default Markov head and the RNN head. The first
three panels of Figure 4 show that DSpark consistently outperforms DFlash at every proposal
length. More importantly, the performance gap steadily widens as𝛾 increases. Because pure
parallel generation (DFlash) suffers from rapid acceptance decay (Figure 2), its marginal utility
diminishes for long blocks. DSpark mitigates this decay, causing its relative gain over DFlash
to grow. For instance, at𝛾= 7, DSpark improves the accepted length by 16% on math, 15% on
code, and 18% on chat; at𝛾= 15, these gains expand to 30%, 26%, and 22%, respectively. Also,
RNN head provides only marginal additional gains over the Markov head, mainly at longer
proposal lengths. Given its higher implementation complexity and less favorable deployment
properties, we use the Markov head as the default.
Latency Overhead.We quantify the overhead of the sequential generation loop in DSpark.
The rightmost panel of Figure 4 reports the per-round engine latency—comprising one target
verification pass, the parallel draft block forward, and the serial sampling loop—measured
at a batch size of 128. To prevent sequence-length bias, the reported latency represents the
arithmetic mean across varying context lengths ({512, 1024, 2048, 4096}tokens ). Since the target
model dominates the verification compute time at this batch size, the sequential block’s latency
overhead is negligible. Consequently, scaling the draft length from 4 to 16 adds a marginal
0.2% to 1.3% to the full-round latency over the DFlash baseline, despite delivering up to a 30%
improvement in accepted length.
4.3.3. Verify Smarter, Not Longer: The Role of Confidence Head
While DSpark sustains high acceptance over long draft blocks, verifying the entire proposal


I’ve confirmed the individual released checkpoint pages are sparse: they are BF16 safetensors repos, not hosted inference endpoints, and the model cards are absent. For the Space, I’m going to avoid pretending these can all run interactively on a free CPU Space; the stronger angle is an interactive research dashboard and speculative-decoding simulator backed by the paper’s metrics.


/bin/zsh -lc 'for repo in deepseek-ai/dspark_qwen3_4b_block7 deepseek-ai/dspark_qwen3_8b_block7 deepseek-ai/dspark_qwen3_14b_block7 deepseek-ai/dspark_gemma4_12b_block7 deepseek-ai/dflash_qwen3_4b_block7 deepseek-ai/dflash_qwen3_8b_block7 deepseek-ai/dflash_qwen3_14b_block7 deepseek-ai/dflash_gemma4_12b_block7 deepseek-ai/eagle3_qwen3_4b_ttt7 deepseek-ai/eagle3_qwen3_8b_ttt7 deepseek-ai/eagle3_qwen3_14b_ttt7 deepseek-ai/eagle3_gemma4_12b_ttt7; do curl -L --silent --fail "https://huggingface.co/api/models/$repo" | jq -r '"'[.id, (.safetensors.parameters|to_entries|map(.value)|add // null), .config.model_type, (.siblings|map(.rfilename)|join(\",\")), ((.cardData // {})|keys|join(\",\"))] | @tsv'; done"


deepseek-ai/dspark_qwen3_4b_block7	1393133569	qwen3	.gitattributes,config.json,model.safetensors
deepseek-ai/dspark_qwen3_8b_block7	2371081729	qwen3	.gitattributes,config.json,model.safetensors
deepseek-ai/dspark_qwen3_14b_block7	3416263169	qwen3	.gitattributes,config.json,model.safetensors
deepseek-ai/dspark_gemma4_12b_block7	3430444550	gemma4_text	.gitattributes,config.json,model.safetensors
deepseek-ai/dflash_qwen3_4b_block7	1315339520	qwen3	.gitattributes,config.json,model.safetensors
deepseek-ai/dflash_qwen3_8b_block7	2293286144	qwen3	.gitattributes,config.json,model.safetensors
deepseek-ai/dflash_qwen3_14b_block7	3338466560	qwen3	.gitattributes,config.json,model.safetensors
deepseek-ai/dflash_gemma4_12b_block7	3296222725	gemma4_text	.gitattributes,config.json,model.safetensors
deepseek-ai/eagle3_qwen3_4b_ttt7	927344896	qwen3	.gitattributes,config.json,model.safetensors
deepseek-ai/eagle3_qwen3_8b_ttt7	1546666240	qwen3	.gitattributes,config.json,model.safetensors
deepseek-ai/eagle3_qwen3_14b_ttt7	2053918976	qwen3	.gitattributes,config.json,model.safetensors
deepseek-ai/eagle3_gemma4_12b_ttt7	2362269185	gemma4_unified_text	.gitattributes,config.json,model.safetensors


The HF API confirms all 12 repos contain only `.gitattributes`, `config.json`, and `model.safetensors`, with exact parameter counts ranging from about 0.93B to 3.43B for the draft modules. I’m sampling the configs next to turn the family differences into concrete UI data rather than generic descriptions.


/bin/zsh -lc 'curl -L --silent --fail https://huggingface.co/deepseek-ai/dspark_qwen3_4b_block7/raw/main/config.json | jq .'


/bin/zsh -lc 'curl -L --silent --fail https://huggingface.co/deepseek-ai/eagle3_qwen3_4b_ttt7/raw/main/config.json | jq .'


/bin/zsh -lc 'curl -L --silent --fail https://huggingface.co/deepseek-ai/dflash_qwen3_4b_block7/raw/main/config.json | jq .'


/bin/zsh -lc 'curl -L --silent --fail https://huggingface.co/deepseek-ai/dspark_gemma4_12b_block7/raw/main/config.json | jq .'


I have enough research to implement a first version. Plan:
1. Build a Gradio “DeepSpec Decoding Lab” with the 12-checkpoint inventory, paper table metrics, architecture comparisons, production Pareto claims, and a deterministic speculative-decoding simulator.
2. Push it early to `Mike0021/deepspec-decoding-lab` as a CPU Gradio Space.
3. Stream build/runtime logs, make targeted fixes only from the first error, then verify with `gradio_client.view_api()` and a `/simulate` call.


Research DeepSpec models and linked papers

Implement Gradio Space files

Create and upload Hugging Face Space

Stream logs and fix first failure if needed

Verify live Space with gradio_client


I’m adding the Space files now: `app.py` for the interactive dashboard/simulator, `README.md` with proper Space frontmatter and source notes, pinned `requirements.txt`, and `.hfignore` so the saved prompt/log do not get uploaded.


The first implementation is in place. I’m doing the allowed local syntax check now, then I’ll create/upload the Space and use the live logs as the source of truth.


/bin/zsh -lc 'python3 -m py_compile app.py'


PROMPT.txt
requirements.txt
app.py
README.md
rollout.jsonl


/bin/zsh -lc "sed -n '1,80p' README.md && sed -n '1,20p' requirements.txt"


---
title: DeepSpec Decoding Lab
emoji: ⚡
colorFrom: teal
colorTo: orange
sdk: gradio
sdk_version: 6.10.0
app_file: app.py
short_description: Interactive DeepSpec speculative decoding lab
startup_duration_timeout: 1h
---

# DeepSpec Decoding Lab

An interactive research dashboard for the DeepSeek-AI DeepSpec collection:
DSpark, DFlash, and EAGLE-3 draft modules across Qwen3 and Gemma4 targets.

The Space uses the DSpark paper's Table 1 accepted-length measurements, public
Hugging Face checkpoint metadata, and a deterministic speculative-decoding
simulator to make the collection easy to inspect without requiring a multi-GPU
serving stack.

Sources:

- DeepSpec collection: https://huggingface.co/collections/deepseek-ai/deepspec-6a410e3f1831ca8ca801b88b
- DeepSpec repository: https://github.com/deepseek-ai/DeepSpec
- DSpark paper: https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf
- DFlash paper: https://arxiv.org/abs/2602.06036
- EAGLE-3 paper: https://arxiv.org/abs/2503.01840
gradio==6.10.0
plotly==5.24.1


`app.py` compiles cleanly. I’m creating the Space under `Mike0021/deepspec-decoding-lab` and uploading only the app files next.


Implement Gradio Space files

Create and upload Hugging Face Space

Verify live Space with gradio_client


/bin/zsh -lc 'hf repos create Mike0021/deepspec-decoding-lab --type space --space-sdk gradio --exist-ok'


The Space repo exists at `https://huggingface.co/spaces/Mike0021/deepspec-decoding-lab`. Uploading the initial Gradio build now.


/bin/zsh -lc "hf upload Mike0021/deepspec-decoding-lab . . --type space --exclude '.git/*' --exclude '__pycache__/*' --exclude '.venv/*' --exclude '*.pyc' --commit-message 'Initial DeepSpec decoding lab'"


Error: Invalid value. Invalid metadata in README.md.
- "colorFrom" must be one of [red, yellow, green, blue, indigo, purple, pink, gray]
- "colorTo" must be one of [red, yellow, green, blue, indigo, purple, pink, gray]
Hint: set HF_DEBUG=1 as environment variable for full traceback.


The first upload failed before build because HF README metadata only accepts a fixed color list. I’m making that single frontmatter fix, then I’ll upload again.