DSpark：DeepSeek 點樣「一次估多個、驗證前綴、錯咗即修正」令 V4 快 60

你嘅理解其實非常接近：先估多幾個 token，再由大模型一次過驗證；估錯就喺第一個錯位即刻改正。 DeepSeek 同北京大學最新嘅 DSpark 再行多兩步：先用「大部分 parallel、少部分 sequential」嘅 drafter 減少亂估，再按每個 request 嘅信心同 GPU 即時負載，決定究竟值得驗證幾多個 token。結果喺 DeepSeek-V4 live traffic 上，相同總吞吐量之下，每位用戶嘅生成速度快咗 57–85%，而 target model 嘅輸出分佈保持不變。

DSpark speculative decoding：細型 drafter 先快速提出 token candidates，再由大型 target model 一次過驗證。

⚡ 一句話：DSpark 唔係令大模型少諗，而係將原本「逐個 token 做一次大 forward」改成「細模型一次估一段，大模型一次驗一段，只保留通過驗證嘅 prefix」。

TL;DR

📄 論文：DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation（DeepSeek-AI × Peking University，2026）
🎯 問題 1：Parallel drafter 後段容易亂。 每個位置獨立估，可能將兩個合理答案混成不合理組合，造成 suffix decay。
🔗 解法 1：Semi-autoregressive generation。 重型 backbone 平行計算整個 block，再用極細嘅 Markov head 逐步補回 token dependency。
📉 問題 2：估到 16 個唔代表值得驗證 16 個。 高 load 時，低信心 suffix 會霸住 batch capacity。
🧠 解法 2：Confidence-scheduled verification。 預測每個 prefix 存活概率，再按 GPU 嘅真實吞吐曲線分配 verification budget。
🚀 Offline：Qwen3-4B / 8B / 14B 上，平均 accepted length 比 EAGLE-3 高 26.7–30.9%，比 DFlash 高 16.3–18.4%。
🏭 Production：DeepSeek-V4-Flash 每位用戶快 60–85%；V4-Pro 快 57–78%（matched throughput）。
✅ 佢係 lossless speculative decoding：唔係用近似答案換速度，而係維持 target model 原本嘅 sampling distribution。
🧩 DSpark 唔係新 foundation model；佢係附加喺現有模型旁邊嘅 speculative decoding module。

1. 先用最直覺嘅方法理解：Guess → Verify → Fix

普通 autoregressive decoding 每次只生成一個 token：

pythonwhile not done:
    logits = target_model(prefix)   # 大模型完整 forward
    token = sample(logits)
    prefix.append(token)

如果輸出 1,000 個 tokens，大模型大致要做 1,000 輪 sequential decoding。每輪只產生一個 token，但要再讀模型權重同 KV cache；呢種工作通常受 memory bandwidth 限制。

Speculative decoding 改成：

pythonwhile not done:
    guesses, q = draft_model.propose(prefix, length=K)
    p = target_model.verify(prefix, guesses)  # 一次驗 K 個位置

    accepted_prefix, correction = rejection_sample(p, q)
    prefix.extend(accepted_prefix)
    prefix.append(correction)

流程係：

Guess：細 drafter 估下一段 tokens。
Verify：大 target model 一次 forward 計晒多個位置嘅 logits。
Accept：由左至右接受通過驗證嘅最長 prefix。
Fix：第一個 reject 嘅位置由 target distribution 重新抽一個 correction token。
Repeat：correction token 成為下一輪 anchor。

Loading diagram...

Guess → Verify → Fix：接受通過驗證嘅最長 prefix，第一個錯位由 target model 修正。

點解可以快，但又唔改答案分佈？

第 $k$ 個 draft token 嘅接受概率係：

P(accept\ x_k)=\min\left(1,\frac{p_k^t(x_k)}{p_k^d(x_k)}\right)

其中 $p^t$ 係 target distribution， $p^d$ 係 draft distribution。如果 reject，就由修正後嘅 residual distribution 抽 token。Leviathan 等人已證明，正確 rejection sampling 可以令最終輸出等價於直接由 target model sampling。

所以 speculative decoding 真正嘅 KPI 唔係「draft 猜中率」一個數，而係：

L=\frac{T_{draft}+T_{verify}}{\tau}

$T_{draft}$ ：估一段要幾耐
$T_{verify}$ ：大模型驗證要幾耐
$\tau$ ：每輪平均 commit 到幾多 tokens（包括 target bonus token）

想快，就要同時做到：draft 快、接受得多、verify 唔好浪費。

2. 舊方法點解卡住？Sequential 同 Parallel 各有一半答案

2.1 EAGLE-3 類：估得連貫，但 draft 本身都係 sequential

Autoregressive drafter 會逐個估：

plaintoken 1 → token 2 | token 1 → token 3 | token 1,2 → ...

優點係後一個 token 真係知道前面抽咗乜，句子比較連貫。缺點係 draft latency 隨 block length 線性增加：

T_{draft}\propto \gamma

因此 drafter 唔可以太深，亦唔可以無限拉長 block。

2.2 DFlash 類：一次估晒，但後段會「人格分裂」

Parallel drafter 可以一次 forward 出晒成個 block，draft latency 幾乎唔隨長度增加。問題係各個位置冇見到 block 入面實際抽中嘅前置 token。

例如 continuation 有兩個合理模式：

of course
no problem

如果兩個位置獨立計 marginal probability，就可能組成：

of problem
no course

呢種 multi-modal collision 令後段 acceptance 迅速跌落去，論文叫 suffix decay。

2.3 點解 parallel drafter 仍然可能打贏 sequential？

DSpark paper 發現一個幾反直覺嘅現象：DFlash 雖然後段跌得快，但第一個 draft token 可以比 EAGLE-3 更準。

原因係 parallel drafter 只做一次 forward，所以可以負擔更深嘅 backbone；EAGLE-3 要逐步跑，為咗 latency 只能用較淺模型。Qwen3-4B 實驗入面：

Math 第一個位置：DFlash 約 0.88 conditional acceptance，EAGLE-3 約 0.81
Chat 第一個位置：DFlash 約 0.72，EAGLE-3 約 0.53

Speculative decoding 係 prefix game：第一個 token reject，後面全部作廢。因此第一步嘅 capacity advantage 特別值錢。

DSpark 嘅目標就係：保留 parallel backbone 嘅第一步優勢，再用極少 sequential compute 救返後段 coherence。

3. DSpark 第一招：Heavy Parallel Backbone + Tiny Sequential Head

DSpark 將 draft 拆成兩部分。

DSpark semi-autoregressive architecture：重型 parallel backbone 同時計算整個 block，輕量 sequential head 補回 token dependency。

3.1 Parallel backbone：一次計好整段 base logits

論文版本以 DFlash 做 backbone：target model 嘅多層 hidden states 經 projection 後注入 drafter；drafter 對整個 block 做 bidirectional attention，一次輸出：

每個位置嘅 hidden state $h_k$
每個位置嘅 base logits $U_k$

呢部分負責「大方向」同第一個 token 嘅高容量預測。

3.2 Sequential head：只加一個細小 transition bias

DSpark 唔會再跑一個完整 Transformer，而係逐位置加一個細 bias：

p_k(v\mid x_{<k})=softmax\left(U_k(v)+B_k(x_{<k},v)\right)

$U_k$ 係 parallel backbone 已經計好嘅分數； $B_k$ 只負責回答：「既然上一個實際抽中嘅 token 係呢個，今個位置邊啲 token 應該加分或減分？」

3.3 Markov head：記住上一個 token 已經夠有用

Default DSpark 用 first-order Markov head：

B(x_{k-1},\cdot)=W_1[x_{k-1}]W_2

如果 vocabulary size 係 $V$ ，直接做完整 $V\times V$ transition matrix 太大，所以用 rank- $256$ low-rank factorization：

$W_1$ ：上一個 token 嘅細 embedding
$W_2$ ：投影返 vocabulary logits

pythonbase_logits = parallel_backbone(anchor, masks)
prev = anchor

for k in range(block_size):
    transition_bias = W1[prev] @ W2
    probs = softmax(base_logits[k] + transition_bias)
    token = sample(probs)
    draft.append(token)
    prev = token

個 loop 雖然 sequential，但每步只係 lookup + 細 matrix multiply，唔係再跑 5 層 Transformer。

論文亦試過 RNN head，令每個位置記住整個 block prefix。不過 RNN 只喺長 proposal 有少量額外 gain，implementation 複雜好多，所以 production 選 Markov head。

3.4 「少少 autoregression」有幾值錢？

2-layer DSpark 已經全面超越 5-layer DFlash。
Block 由 7 拉長到 15 時，DSpark 對 DFlash 嘅 accepted-length 優勢由 Math / Code / Chat 嘅 16% / 15% / 18%，擴大到 30% / 26% / 22%。
Batch size 128 下，proposal length 由 4 加到 16，相比 DFlash 每輪 latency 只多 0.2–1.3%。

重點唔係「parallel 或 sequential 邊個贏」，而係：貴嘅 representation learning parallel 做，平嘅 dependency correction sequential 做。

4. DSpark 第二招：唔係估得越長越好，而係 Verify Smarter

即使 drafter 免費估到 16 個 tokens，都唔代表 target model 應該驗足 16 個。

Code、math 結構較強，長 prefix 通過機會高。
Open-ended chat entropy 高，後段較易 reject。
GPU 閒置時，多驗幾個幾乎免費。
高 concurrency 時，每個低信心 token 都會霸佔 batch capacity，拖慢其他 request。

所以「固定 verify K 個」喺 production 係錯誤抽象。正確問題係：以目前 workload 同硬件狀態，多驗下一個 token，預期回報值唔值佢佔用嘅 capacity？

5. Confidence Head：預測成個 prefix 生存到邊度

DSpark 為每個位置輸出 $c_k$ ：

c_k=P(\text{position }k\text{ passes}\mid\text{positions }1...k-1\text{ passed})

因此第 $j$ 個 token 真正有機會被執行到嘅 cumulative survival probability 係：

a_j=\prod_{i\le j}c_i

5.1 Training label 唔係硬 0/1，而係 distribution distance

Target 同 draft distribution 嘅 total variation distance 可以直接換成每步理論 acceptance：

c_k^*=1-\frac{1}{2}\|p_k^d-p_k^t\|_1

Drafter 嘅 training objective 包含：

Cross-entropy：估 ground-truth token
TV loss：令 draft distribution 貼近 target distribution
Confidence loss：預測 $c_k^*$

論文 default weights 係 $0.1 / 0.9 / 1.0$ ，反映 speculative decoding 最重要唔係普通 next-token accuracy，而係 distribution matching 同 acceptance estimation。

5.2 Confidence 要校準，淨係識排序唔夠

Scheduler 要用 $a_j$ 計 expected throughput，所以 0.8 真係要接近 80%，唔可以只係「比 0.7 更有信心」。

Raw confidence head 嘅 ROC-AUC 約 0.81–0.90，識分高低；但 ECE 有 3–8%，普遍過度自信。DSpark 用 Sequential Temperature Scaling（STS） 由左至右校準 cumulative probability，將平均 ECE 壓到約 1%。

6. Hardware-Aware Prefix Scheduler：GPU 忙就少驗，GPU 閒就多驗

假設同一輪有 $R$ 個 active requests，每個 request $r$ 選 verification length $\ell_r$ ：

B=\sum_r(1+\ell_r)

係 target model 今輪真正處理嘅 token batch；預期 commit tokens：

\tau=\sum_r\left(1+\sum_{j=1}^{\ell_r}a_{r,j}\right)

Engine 啟動時先 profile 一條硬件曲線 $SPS(B)$ （batch size 為 $B$ 時每秒跑到幾多 steps）。Scheduler 目標係：

\max_{\ell_1...\ell_R}\ \Theta=\tau\cdot SPS(B)

實際做法可以理解為：

計晒所有 request 嘅 prefix survival probability。
將下一個可延長位置按 expected return 排序。
逐個加入 verification batch。
每加入一個，就查硬件 curve，睇總 expected throughput 有冇升。
一旦再加會令 throughput 跌，就停。

Loading diagram...

Hardware-aware scheduling：GPU 輕載時驗證較長 prefix；高負載時只保留高信心 tokens，提早剪走低回報 suffix。

呢個 scheduler 令 speculation 由一個純 model algorithm，變成 model × workload × hardware 嘅 global resource-allocation problem。

7. 一個好容易忽略但重要嘅位：Scheduler 都要保持 lossless

Markov confidence 用到上一個實際抽中嘅 token。如果 scheduler 偷睇未來 token，再回頭決定前面值唔值得 admission，就會引入 selection bias，破壞 target distribution。

論文嘅理論 algorithm 用 early stopping：一旦 estimated throughput 開始跌，立即停，唔再用未來資訊回頭改決定。

Production 又有另一個現實問題：GPU throughput curve 係 jagged，唔一定 smooth；而 Zero-Overhead Scheduling 同 CUDA Graph 需要提早知道下一步 batch size。DeepSeek 嘅工程做法係：

用 兩步之前嘅 confidence 預測下一步 capacity $K$
當前 tokens 仍按最新 cumulative confidence 排序
舊資訊只決定 top- $K$ 有幾大，而唔決定某個當前 token 嘅 admission

呢個 two-step causal barrier 既可以避開 future leakage，又可以將 scheduling latency 藏喺 asynchronous pipeline 入面。

8. Offline 實驗：Accepted Length 真係高咗幾多？

公平比較設定：

Targets：Qwen3-4B / 8B / 14B、Gemma4-12B
Baselines：1-layer EAGLE-3、5-layer DFlash
DSpark：5-layer backbone + default Markov head
Block size：7
Training：Open-PerfectBlend 1.3M prompts；responses 由 target model 重新生成
Evaluation：Math、Code、Chat 共 9 個 benchmarks；temperature 1.0；non-thinking mode
Offline comparison 關閉 confidence scheduler，純粹比較 drafter quality

Macro-average improvement

Target	vs. EAGLE-3	vs. DFlash
Qwen3-4B	+30.9%	+16.3%
Qwen3-8B	+26.7%	+18.4%
Qwen3-14B	+30.0%	+18.3%

幾個實際 accepted-length 例子

Target / Benchmark	EAGLE-3	DFlash	DSpark
Qwen3-8B / GSM8K	5.30	5.33	6.17
Qwen3-8B / HumanEval	4.33	4.64	5.52
Qwen3-8B / Alpaca	2.54	2.98	3.58
Qwen3-14B / MATH500	4.60	4.84	5.74
Gemma4-12B / HumanEval	5.37	4.95	5.64

Domain gap 亦好清楚：structured tasks 通常可以接受更長；chat 更需要 confidence pruning。Qwen3-4B 嘅固定長度驗證下，confidence threshold sweep 可以令：

Chat acceptance rate：45.7% → 95.7%
Math：76.9% → 92.5%
Code：67.6% → 92.0%

但要留意：acceptance rate 上升唔等於 tokens per step 一定上升，因為 threshold 太高會連有價值嘅 token 都剪走。真正 production scheduler 要連 hardware curve 一齊計。

9. Live production：點解 60–85% 呢個數可信，但 661% 唔應該當 headline？

DeepSeek 將 DSpark-5 部署到 V4-Flash 同 V4-Pro live traffic，對比舊 production baseline MTP-1。

Matched throughput 下嘅 per-user speed

Serving model	每位用戶生成速度提升
DeepSeek-V4-Flash	+60% 至 +85%
DeepSeek-V4-Pro	+57% 至 +78%

Moderate SLA 下嘅 aggregate throughput

V4-Flash @ 80 tok/s/user：aggregate throughput +51%
V4-Pro @ 35 tok/s/user：aggregate throughput +52%

Strict SLA 下，DSpark 打破 baseline 嘅 performance cliff

V4-Flash @ 120 tok/s/user：論文報 nominal +661% throughput
V4-Pro @ 50 tok/s/user：nominal +406%

但作者自己特別提醒：呢兩個巨大倍率唔應理解成一般情況嘅 6.61× / 4.06× speedup。原因係 MTP-1 喺嚴格 latency target 下已經接近 operational boundary，只能維持極細 concurrent batch；分母接近崩潰先令 ratio 特別大。

比較穩陣嘅 headline 仍然係：matched practical throughput 下，每位用戶快 57–85%；moderate SLA 下，總 throughput 約提升 51–52%。

Scheduler 實際點分 budget？

Moderate load：每個 request 由 MTP-1 固定 2 個 verification tokens，擴到約 4–6 個。
Load 上升、GPU 飽和：平均 verification length 會自動下降，優先剪走低信心 suffix。

即係：閒時用多啲 GPU 換 latency；忙時收斂 speculation，保住 capacity。

10. DSpark vs. EAGLE-3 vs. DFlash vs. DDTree

方法	Draft 方式	主要強項	主要弱點
EAGLE-3	Autoregressive	後段有完整 dependency	Draft latency 隨 block 長度升
DFlash	Parallel block	一次 forward；第一步 capacity 高	Independent positions 導致 suffix decay
DDTree	DFlash + tree verify	利用多條 candidate path	Tree node 會增加 verifier workload
DSpark	Parallel backbone + tiny sequential head	兼顧 draft latency、coherence、load-aware serving	要 train 專用 drafter，仍有固定 draft cost

DSpark 唔係單純「DFlash 再加一個 head」咁簡單。佢最重要嘅貢獻係將三個問題串埋：

Model quality：Markov head 救 suffix coherence。
Probability estimation：confidence head + STS 估 prefix survival。
Serving economics：hardware-aware scheduler 將 verification capacity 分去最高回報 tokens。

11. Production 版本同 paper benchmark 版本有咩唔同？

Paper offline benchmark 主要用 dense Qwen / Gemma targets，DSpark block size 7；V4 production 版本則為大型 MoE serving 特別調整：

3 個 MoE draft layers
mHC residual architecture
Sliding-window attention = 128
Maximum draft length $\gamma=5$
Default Markov head
Confidence head end-to-end training，再做 STS calibration
Variable-length verified prefixes flatten 成獨立 physical tokens
用 marker tensor 喺 sparse attention kernel 表達 logical dependency

DeepSeek 亦已將 DeepSpec open source。Repository 包含 DSpark、DFlash、EAGLE-3 嘅 training / evaluation pipeline，同 Qwen3、Gemma4 checkpoints；V4-Flash / V4-Pro 亦有 DSpark module。vLLM 可以用 speculative-config 啟用，但 V4-Pro 級別嘅本地部署仍然係 datacenter-class hardware，唔係一般單卡桌面 demo。

bashvllm serve deepseek-ai/DeepSeek-V4-Pro-DSpark \
  --speculative-config \
  '{"method":"dspark","num_speculative_tokens":7,"draft_sample_method":"greedy"}'

12. 限制同 Caveats

12.1 唔係所有 request 都值得 speculate

極高 entropy 或非常困難嘅 query，draft acceptance 低，但 parallel backbone 嘅 fixed drafting cost 已經付咗。Paper 建議未來加 difficulty-aware early exit，讓部分 request bypass full-block drafting。

12.2 每個 target model 都要配專用 drafter

DSpark 共享 target embedding / LM head，亦依賴 target hidden features；唔係一個 draft checkpoint 任配所有模型。DeepSpec 可以幫你 retrain，但 default Qwen3-4B target cache 甚至約 38 TB，training pipeline 並唔輕。

12.3 Offline accepted length 唔等於 production tok/s

Accepted length 高，只代表每輪 commit 多；真實速度仲受 batch size、context length、KV cache、kernel、MoE routing、network communication 同 scheduler 影響。DSpark paper 最有價值嘅地方，正正係佢唔停喺 offline benchmark，而係畀咗 live production Pareto frontier。

12.4 「Lossless」有嚴格前提

要保持 target distribution：

Draft 要提供正確 per-token probabilities
Verify 要用正確 rejection sampling
Scheduler admission 唔可以偷睇未來 candidate
Sampling / implementation 必須遵守 non-anticipating rule

如果改成簡單 argmax compare、用未校準 confidence 亂剪、或者 retrospective schedule，就未必保留原 distribution。

13. 我覺得呢篇 paper 最重要嘅三個 insight

Insight 1：Parallel 同 sequential 唔係二選一

真正合理嘅分工係：重 compute parallel，輕 dependency sequential。 Rank-256 Markov head 已經可以用極低 latency 修正 parallel block 嘅主要弱點。

Insight 2：Speculative decoding 最後係 scheduling problem

當 GPU 空閒，多 verify 幾個 token 近乎免費；當 GPU 飽和，同一個 token 會擠走其他 request。最佳 $K$ 唔係 model 常數，而係隨 domain、confidence、batch 同硬件動態變。

Insight 3：平均 speedup 唔夠，要睇 Pareto frontier

Production 系統同時追求：

per-user tok/s
aggregate throughput
concurrent users
SLA / tail latency

DSpark 真正嘅貢獻唔只係 accepted length，而係將可達到嘅 throughput–interactivity frontier 推咗出去。

14. 總結

如果用你原本嘅描述重講一次 DSpark：

先由細模型一次估多幾個 token；用一個極輕量 sequential head，令後面嘅估計跟返前面實際抽中嘅 token；再由 confidence scheduler 揀最值得驗證嘅 prefix；最後由大模型一次過 verify，接受正確部分，第一個錯位即刻修正。

佢成功嘅原因唔係單一 trick，而係同時改善三個變數：

\text{Speed}\uparrow\quad\Longleftrightarrow\quad T_{draft}\downarrow,\ \tau\uparrow,\ T_{verify\ waste}\downarrow

Parallel backbone 壓低 $T_{draft}$
Markov head 提高 accepted length $\tau$
Confidence scheduler 壓低無效 verification

最後換來嘅係：Qwen / Gemma offline accepted length 全面領先，以及 DeepSeek-V4 live serving 上 57–85% per-user speedup at matched throughput。

DSpark 最值得記住嘅一句唔係「一次估更多」，而係：

🧠 估幾多係 model 問題；驗幾多係 system 問題；點樣保持完全一致嘅輸出分佈，係 probability 問題。DSpark 將三樣嘢一次過解。

TL;DR

📄 論文：DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation（DeepSeek-AI × Peking University，2026）
🎯 問題 1：Parallel drafter 後段容易亂。 每個位置獨立估，可能將兩個合理答案混成不合理組合，造成 suffix decay。
🔗 解法 1：Semi-autoregressive generation。 重型 backbone 平行計算整個 block，再用極細嘅 Markov head 逐步補回 token dependency。
📉 問題 2：估到 16 個唔代表值得驗證 16 個。 高 load 時，低信心 suffix 會霸住 batch capacity。
🧠 解法 2：Confidence-scheduled verification。 預測每個 prefix 存活概率，再按 GPU 嘅真實吞吐曲線分配 verification budget。
🚀 Offline：Qwen3-4B / 8B / 14B 上，平均 accepted length 比 EAGLE-3 高 26.7–30.9%，比 DFlash 高 16.3–18.4%。
🏭 Production：DeepSeek-V4-Flash 每位用戶快 60–85%；V4-Pro 快 57–78%（matched throughput）。
✅ 佢係 lossless speculative decoding：唔係用近似答案換速度，而係維持 target model 原本嘅 sampling distribution。
🧩 DSpark 唔係新 foundation model；佢係附加喺現有模型旁邊嘅 speculative decoding module。

1. 先用最直覺嘅方法理解：Guess → Verify → Fix

普通 autoregressive decoding 每次只生成一個 token：

pythonwhile not done:
    logits = target_model(prefix)   # 大模型完整 forward
    token = sample(logits)
    prefix.append(token)

Speculative decoding 改成：

pythonwhile not done:
    guesses, q = draft_model.propose(prefix, length=K)
    p = target_model.verify(prefix, guesses)  # 一次驗 K 個位置

    accepted_prefix, correction = rejection_sample(p, q)
    prefix.extend(accepted_prefix)
    prefix.append(correction)

流程係：

Guess：細 drafter 估下一段 tokens。
Verify：大 target model 一次 forward 計晒多個位置嘅 logits。
Accept：由左至右接受通過驗證嘅最長 prefix。
Fix：第一個 reject 嘅位置由 target distribution 重新抽一個 correction token。
Repeat：correction token 成為下一輪 anchor。

Loading diagram...

Guess → Verify → Fix：接受通過驗證嘅最長 prefix，第一個錯位由 target model 修正。

點解可以快，但又唔改答案分佈？

第 $k$ 個 draft token 嘅接受概率係：

P(accept\ x_k)=\min\left(1,\frac{p_k^t(x_k)}{p_k^d(x_k)}\right)

所以 speculative decoding 真正嘅 KPI 唔係「draft 猜中率」一個數，而係：

L=\frac{T_{draft}+T_{verify}}{\tau}

$T_{draft}$ ：估一段要幾耐
$T_{verify}$ ：大模型驗證要幾耐
$\tau$ ：每輪平均 commit 到幾多 tokens（包括 target bonus token）

想快，就要同時做到：draft 快、接受得多、verify 唔好浪費。

2. 舊方法點解卡住？Sequential 同 Parallel 各有一半答案

2.1 EAGLE-3 類：估得連貫，但 draft 本身都係 sequential

Autoregressive drafter 會逐個估：

plaintoken 1 → token 2 | token 1 → token 3 | token 1,2 → ...

優點係後一個 token 真係知道前面抽咗乜，句子比較連貫。缺點係 draft latency 隨 block length 線性增加：

T_{draft}\propto \gamma

因此 drafter 唔可以太深，亦唔可以無限拉長 block。

2.2 DFlash 類：一次估晒，但後段會「人格分裂」

Parallel drafter 可以一次 forward 出晒成個 block，draft latency 幾乎唔隨長度增加。問題係各個位置冇見到 block 入面實際抽中嘅前置 token。

例如 continuation 有兩個合理模式：

of course
no problem

如果兩個位置獨立計 marginal probability，就可能組成：

of problem
no course

呢種 multi-modal collision 令後段 acceptance 迅速跌落去，論文叫 suffix decay。

2.3 點解 parallel drafter 仍然可能打贏 sequential？

DSpark paper 發現一個幾反直覺嘅現象：DFlash 雖然後段跌得快，但第一個 draft token 可以比 EAGLE-3 更準。

原因係 parallel drafter 只做一次 forward，所以可以負擔更深嘅 backbone；EAGLE-3 要逐步跑，為咗 latency 只能用較淺模型。Qwen3-4B 實驗入面：

Math 第一個位置：DFlash 約 0.88 conditional acceptance，EAGLE-3 約 0.81
Chat 第一個位置：DFlash 約 0.72，EAGLE-3 約 0.53

Speculative decoding 係 prefix game：第一個 token reject，後面全部作廢。因此第一步嘅 capacity advantage 特別值錢。

DSpark 嘅目標就係：保留 parallel backbone 嘅第一步優勢，再用極少 sequential compute 救返後段 coherence。

3. DSpark 第一招：Heavy Parallel Backbone + Tiny Sequential Head

DSpark 將 draft 拆成兩部分。

DSpark semi-autoregressive architecture：重型 parallel backbone 同時計算整個 block，輕量 sequential head 補回 token dependency。

3.1 Parallel backbone：一次計好整段 base logits

論文版本以 DFlash 做 backbone：target model 嘅多層 hidden states 經 projection 後注入 drafter；drafter 對整個 block 做 bidirectional attention，一次輸出：

每個位置嘅 hidden state $h_k$
每個位置嘅 base logits $U_k$

呢部分負責「大方向」同第一個 token 嘅高容量預測。

3.2 Sequential head：只加一個細小 transition bias

DSpark 唔會再跑一個完整 Transformer，而係逐位置加一個細 bias：

p_k(v\mid x_{<k})=softmax\left(U_k(v)+B_k(x_{<k},v)\right)

$U_k$ 係 parallel backbone 已經計好嘅分數； $B_k$ 只負責回答：「既然上一個實際抽中嘅 token 係呢個，今個位置邊啲 token 應該加分或減分？」

3.3 Markov head：記住上一個 token 已經夠有用

Default DSpark 用 first-order Markov head：

B(x_{k-1},\cdot)=W_1[x_{k-1}]W_2

如果 vocabulary size 係 $V$ ，直接做完整 $V\times V$ transition matrix 太大，所以用 rank- $256$ low-rank factorization：

$W_1$ ：上一個 token 嘅細 embedding
$W_2$ ：投影返 vocabulary logits

pythonbase_logits = parallel_backbone(anchor, masks)
prev = anchor

for k in range(block_size):
    transition_bias = W1[prev] @ W2
    probs = softmax(base_logits[k] + transition_bias)
    token = sample(probs)
    draft.append(token)
    prev = token

個 loop 雖然 sequential，但每步只係 lookup + 細 matrix multiply，唔係再跑 5 層 Transformer。

論文亦試過 RNN head，令每個位置記住整個 block prefix。不過 RNN 只喺長 proposal 有少量額外 gain，implementation 複雜好多，所以 production 選 Markov head。

3.4 「少少 autoregression」有幾值錢？

2-layer DSpark 已經全面超越 5-layer DFlash。
Block 由 7 拉長到 15 時，DSpark 對 DFlash 嘅 accepted-length 優勢由 Math / Code / Chat 嘅 16% / 15% / 18%，擴大到 30% / 26% / 22%。
Batch size 128 下，proposal length 由 4 加到 16，相比 DFlash 每輪 latency 只多 0.2–1.3%。

重點唔係「parallel 或 sequential 邊個贏」，而係：貴嘅 representation learning parallel 做，平嘅 dependency correction sequential 做。

4. DSpark 第二招：唔係估得越長越好，而係 Verify Smarter

即使 drafter 免費估到 16 個 tokens，都唔代表 target model 應該驗足 16 個。

Code、math 結構較強，長 prefix 通過機會高。
Open-ended chat entropy 高，後段較易 reject。
GPU 閒置時，多驗幾個幾乎免費。
高 concurrency 時，每個低信心 token 都會霸佔 batch capacity，拖慢其他 request。

所以「固定 verify K 個」喺 production 係錯誤抽象。正確問題係：以目前 workload 同硬件狀態，多驗下一個 token，預期回報值唔值佢佔用嘅 capacity？

5. Confidence Head：預測成個 prefix 生存到邊度

DSpark 為每個位置輸出 $c_k$ ：

c_k=P(\text{position }k\text{ passes}\mid\text{positions }1...k-1\text{ passed})

因此第 $j$ 個 token 真正有機會被執行到嘅 cumulative survival probability 係：

a_j=\prod_{i\le j}c_i

5.1 Training label 唔係硬 0/1，而係 distribution distance

Target 同 draft distribution 嘅 total variation distance 可以直接換成每步理論 acceptance：

c_k^*=1-\frac{1}{2}\|p_k^d-p_k^t\|_1

Drafter 嘅 training objective 包含：

Cross-entropy：估 ground-truth token
TV loss：令 draft distribution 貼近 target distribution
Confidence loss：預測 $c_k^*$

論文 default weights 係 $0.1 / 0.9 / 1.0$ ，反映 speculative decoding 最重要唔係普通 next-token accuracy，而係 distribution matching 同 acceptance estimation。

5.2 Confidence 要校準，淨係識排序唔夠

Scheduler 要用 $a_j$ 計 expected throughput，所以 0.8 真係要接近 80%，唔可以只係「比 0.7 更有信心」。

6. Hardware-Aware Prefix Scheduler：GPU 忙就少驗，GPU 閒就多驗

假設同一輪有 $R$ 個 active requests，每個 request $r$ 選 verification length $\ell_r$ ：

B=\sum_r(1+\ell_r)

係 target model 今輪真正處理嘅 token batch；預期 commit tokens：

\tau=\sum_r\left(1+\sum_{j=1}^{\ell_r}a_{r,j}\right)

Engine 啟動時先 profile 一條硬件曲線 $SPS(B)$ （batch size 為 $B$ 時每秒跑到幾多 steps）。Scheduler 目標係：

\max_{\ell_1...\ell_R}\ \Theta=\tau\cdot SPS(B)

實際做法可以理解為：

計晒所有 request 嘅 prefix survival probability。
將下一個可延長位置按 expected return 排序。
逐個加入 verification batch。
每加入一個，就查硬件 curve，睇總 expected throughput 有冇升。
一旦再加會令 throughput 跌，就停。

Loading diagram...

Hardware-aware scheduling：GPU 輕載時驗證較長 prefix；高負載時只保留高信心 tokens，提早剪走低回報 suffix。

呢個 scheduler 令 speculation 由一個純 model algorithm，變成 model × workload × hardware 嘅 global resource-allocation problem。

7. 一個好容易忽略但重要嘅位：Scheduler 都要保持 lossless

論文嘅理論 algorithm 用 early stopping：一旦 estimated throughput 開始跌，立即停，唔再用未來資訊回頭改決定。

用 兩步之前嘅 confidence 預測下一步 capacity $K$
當前 tokens 仍按最新 cumulative confidence 排序
舊資訊只決定 top- $K$ 有幾大，而唔決定某個當前 token 嘅 admission

呢個 two-step causal barrier 既可以避開 future leakage，又可以將 scheduling latency 藏喺 asynchronous pipeline 入面。

8. Offline 實驗：Accepted Length 真係高咗幾多？

公平比較設定：

Targets：Qwen3-4B / 8B / 14B、Gemma4-12B
Baselines：1-layer EAGLE-3、5-layer DFlash
DSpark：5-layer backbone + default Markov head
Block size：7
Training：Open-PerfectBlend 1.3M prompts；responses 由 target model 重新生成
Evaluation：Math、Code、Chat 共 9 個 benchmarks；temperature 1.0；non-thinking mode
Offline comparison 關閉 confidence scheduler，純粹比較 drafter quality

Macro-average improvement

Target	vs. EAGLE-3	vs. DFlash
Qwen3-4B	+30.9%	+16.3%
Qwen3-8B	+26.7%	+18.4%
Qwen3-14B	+30.0%	+18.3%

幾個實際 accepted-length 例子

Target / Benchmark	EAGLE-3	DFlash	DSpark
Qwen3-8B / GSM8K	5.30	5.33	6.17
Qwen3-8B / HumanEval	4.33	4.64	5.52
Qwen3-8B / Alpaca	2.54	2.98	3.58
Qwen3-14B / MATH500	4.60	4.84	5.74
Gemma4-12B / HumanEval	5.37	4.95	5.64

Domain gap 亦好清楚：structured tasks 通常可以接受更長；chat 更需要 confidence pruning。Qwen3-4B 嘅固定長度驗證下，confidence threshold sweep 可以令：

Chat acceptance rate：45.7% → 95.7%
Math：76.9% → 92.5%
Code：67.6% → 92.0%

9. Live production：點解 60–85% 呢個數可信，但 661% 唔應該當 headline？

DeepSeek 將 DSpark-5 部署到 V4-Flash 同 V4-Pro live traffic，對比舊 production baseline MTP-1。

Matched throughput 下嘅 per-user speed

Serving model	每位用戶生成速度提升
DeepSeek-V4-Flash	+60% 至 +85%
DeepSeek-V4-Pro	+57% 至 +78%

Moderate SLA 下嘅 aggregate throughput

V4-Flash @ 80 tok/s/user：aggregate throughput +51%
V4-Pro @ 35 tok/s/user：aggregate throughput +52%

Strict SLA 下，DSpark 打破 baseline 嘅 performance cliff

V4-Flash @ 120 tok/s/user：論文報 nominal +661% throughput
V4-Pro @ 50 tok/s/user：nominal +406%

比較穩陣嘅 headline 仍然係：matched practical throughput 下，每位用戶快 57–85%；moderate SLA 下，總 throughput 約提升 51–52%。

Scheduler 實際點分 budget？

Moderate load：每個 request 由 MTP-1 固定 2 個 verification tokens，擴到約 4–6 個。
Load 上升、GPU 飽和：平均 verification length 會自動下降，優先剪走低信心 suffix。

即係：閒時用多啲 GPU 換 latency；忙時收斂 speculation，保住 capacity。

10. DSpark vs. EAGLE-3 vs. DFlash vs. DDTree

方法	Draft 方式	主要強項	主要弱點
EAGLE-3	Autoregressive	後段有完整 dependency	Draft latency 隨 block 長度升
DFlash	Parallel block	一次 forward；第一步 capacity 高	Independent positions 導致 suffix decay
DDTree	DFlash + tree verify	利用多條 candidate path	Tree node 會增加 verifier workload
DSpark	Parallel backbone + tiny sequential head	兼顧 draft latency、coherence、load-aware serving	要 train 專用 drafter，仍有固定 draft cost

DSpark 唔係單純「DFlash 再加一個 head」咁簡單。佢最重要嘅貢獻係將三個問題串埋：

Model quality：Markov head 救 suffix coherence。
Probability estimation：confidence head + STS 估 prefix survival。
Serving economics：hardware-aware scheduler 將 verification capacity 分去最高回報 tokens。

11. Production 版本同 paper benchmark 版本有咩唔同？

Paper offline benchmark 主要用 dense Qwen / Gemma targets，DSpark block size 7；V4 production 版本則為大型 MoE serving 特別調整：

3 個 MoE draft layers
mHC residual architecture
Sliding-window attention = 128
Maximum draft length $\gamma=5$
Default Markov head
Confidence head end-to-end training，再做 STS calibration
Variable-length verified prefixes flatten 成獨立 physical tokens
用 marker tensor 喺 sparse attention kernel 表達 logical dependency

bashvllm serve deepseek-ai/DeepSeek-V4-Pro-DSpark \
  --speculative-config \
  '{"method":"dspark","num_speculative_tokens":7,"draft_sample_method":"greedy"}'

12. 限制同 Caveats

12.1 唔係所有 request 都值得 speculate

12.2 每個 target model 都要配專用 drafter

12.3 Offline accepted length 唔等於 production tok/s

12.4 「Lossless」有嚴格前提

要保持 target distribution：

Draft 要提供正確 per-token probabilities
Verify 要用正確 rejection sampling
Scheduler admission 唔可以偷睇未來 candidate
Sampling / implementation 必須遵守 non-anticipating rule

如果改成簡單 argmax compare、用未校準 confidence 亂剪、或者 retrospective schedule，就未必保留原 distribution。

13. 我覺得呢篇 paper 最重要嘅三個 insight

Insight 1：Parallel 同 sequential 唔係二選一

真正合理嘅分工係：重 compute parallel，輕 dependency sequential。 Rank-256 Markov head 已經可以用極低 latency 修正 parallel block 嘅主要弱點。

Insight 2：Speculative decoding 最後係 scheduling problem

Insight 3：平均 speedup 唔夠，要睇 Pareto frontier

Production 系統同時追求：

per-user tok/s
aggregate throughput
concurrent users
SLA / tail latency

DSpark 真正嘅貢獻唔只係 accepted length，而係將可達到嘅 throughput–interactivity frontier 推咗出去。

14. 總結

如果用你原本嘅描述重講一次 DSpark：

先由細模型一次估多幾個 token；用一個極輕量 sequential head，令後面嘅估計跟返前面實際抽中嘅 token；再由 confidence scheduler 揀最值得驗證嘅 prefix；最後由大模型一次過 verify，接受正確部分，第一個錯位即刻修正。

佢成功嘅原因唔係單一 trick，而係同時改善三個變數：

\text{Speed}\uparrow\quad\Longleftrightarrow\quad T_{draft}\downarrow,\ \tau\uparrow,\ T_{verify\ waste}\downarrow

Parallel backbone 壓低 $T_{draft}$
Markov head 提高 accepted length $\tau$
Confidence scheduler 壓低無效 verification

最後換來嘅係：Qwen / Gemma offline accepted length 全面領先，以及 DeepSeek-V4 live serving 上 57–85% per-user speedup at matched throughput。

DSpark 最值得記住嘅一句唔係「一次估更多」，而係：

🧠 估幾多係 model 問題；驗幾多係 system 問題；點樣保持完全一致嘅輸出分佈，係 probability 問題。DSpark 將三樣嘢一次過解。

TL;DR

Table of Contents

1. 先用最直覺嘅方法理解：Guess → Verify → Fix

點解可以快，但又唔改答案分佈？

2. 舊方法點解卡住？Sequential 同 Parallel 各有一半答案

2.1 EAGLE-3 類：估得連貫，但 draft 本身都係 sequential

2.2 DFlash 類：一次估晒，但後段會「人格分裂」

2.3 點解 parallel drafter 仍然可能打贏 sequential？

3. DSpark 第一招：Heavy Parallel Backbone + Tiny Sequential Head

3.1 Parallel backbone：一次計好整段 base logits

3.2 Sequential head：只加一個細小 transition bias

3.3 Markov head：記住上一個 token 已經夠有用

3.4 「少少 autoregression」有幾值錢？

4. DSpark 第二招：唔係估得越長越好，而係 Verify Smarter

5. Confidence Head：預測成個 prefix 生存到邊度

5.1 Training label 唔係硬 0/1，而係 distribution distance

5.2 Confidence 要校準，淨係識排序唔夠

6. Hardware-Aware Prefix Scheduler：GPU 忙就少驗，GPU 閒就多驗

7. 一個好容易忽略但重要嘅位：Scheduler 都要保持 lossless

8. Offline 實驗：Accepted Length 真係高咗幾多？

Macro-average improvement

幾個實際 accepted-length 例子

9. Live production：點解 60–85% 呢個數可信，但 661% 唔應該當 headline？

Matched throughput 下嘅 per-user speed

Moderate SLA 下嘅 aggregate throughput

Strict SLA 下，DSpark 打破 baseline 嘅 performance cliff

Scheduler 實際點分 budget？

10. DSpark vs. EAGLE-3 vs. DFlash vs. DDTree

11. Production 版本同 paper benchmark 版本有咩唔同？

12. 限制同 Caveats

12.1 唔係所有 request 都值得 speculate

12.2 每個 target model 都要配專用 drafter

12.3 Offline accepted length 唔等於 production tok/s

12.4 「Lossless」有嚴格前提

13. 我覺得呢篇 paper 最重要嘅三個 insight

Insight 1：Parallel 同 sequential 唔係二選一

Insight 2：Speculative decoding 最後係 scheduling problem

Insight 3：平均 speedup 唔夠，要睇 Pareto frontier

14. 總結

相關資源

Primary sources

Background

FAQ

DSpark 係乜？

呢篇文章適合邊類讀者？

Related Articles

DeepSeek-V4：1.6T MoE × 1M context × Hybrid Attention，DeepSeek 點樣將 long-context inference 砍到 V3.2 嘅 27% FLOPs / 10% KV cache？

DeepSeek Reasonix：以 Prefix Cache 為核心嘅 AI Coding Agent

DeepSeek-OCR 2：點樣教 AI 好似人咁「睇」文件？Visual Causal Flow 完全拆解

TL;DR

Table of Contents

1. 先用最直覺嘅方法理解：Guess → Verify → Fix

點解可以快，但又唔改答案分佈？

2. 舊方法點解卡住？Sequential 同 Parallel 各有一半答案

2.1 EAGLE-3 類：估得連貫，但 draft 本身都係 sequential

2.2 DFlash 類：一次估晒，但後段會「人格分裂」

2.3 點解 parallel drafter 仍然可能打贏 sequential？

3. DSpark 第一招：Heavy Parallel Backbone + Tiny Sequential Head

3.1 Parallel backbone：一次計好整段 base logits

3.2 Sequential head：只加一個細小 transition bias

3.3 Markov head：記住上一個 token 已經夠有用

3.4 「少少 autoregression」有幾值錢？

4. DSpark 第二招：唔係估得越長越好，而係 Verify Smarter

5. Confidence Head：預測成個 prefix 生存到邊度

5.1 Training label 唔係硬 0/1，而係 distribution distance

5.2 Confidence 要校準，淨係識排序唔夠

6. Hardware-Aware Prefix Scheduler：GPU 忙就少驗，GPU 閒就多驗

7. 一個好容易忽略但重要嘅位：Scheduler 都要保持 lossless

8. Offline 實驗：Accepted Length 真係高咗幾多？

Macro-average improvement

幾個實際 accepted-length 例子

9. Live production：點解 60–85% 呢個數可信，但 661% 唔應該當 headline？

Matched throughput 下嘅 per-user speed

Moderate SLA 下嘅 aggregate throughput

Strict SLA 下，DSpark 打破 baseline 嘅 performance cliff

Scheduler 實際點分 budget？

10. DSpark vs. EAGLE-3 vs. DFlash vs. DDTree

11. Production 版本同 paper benchmark 版本有咩唔同？

12. 限制同 Caveats

12.1 唔係所有 request 都值得 speculate