DSpark
论文蒸馏
这篇 paper 的核心不是“又做了一个 speculative decoding drafter”，而是把草稿 token 当成带置信度的队列任务： 先更聪明地产生草稿，再按系统负载选择哪些值得送去昂贵的 target model 验证。
DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation
用更连贯的草稿 + 更挑剔的验证，把 LLM 推理速度推到新的吞吐/交互边界。
English mirror: DSpark accelerates LLM inference by combining a semi-autoregressive drafter with load-aware verification, so the system drafts long blocks but only spends target-model capacity where acceptance is likely.
速读版
为什么不是“草稿越长越好”
旧瓶颈
Autoregressive 逐 token 生成，延迟跟输出长度线性增长。
naive fix
并行草拟更长 block，但后缀 token 因缺少依赖而快速掉 acceptance。
系统问题
高并发时，验证低置信 token 会占用 target model batch capacity。
DSpark 杠杆
草稿端补局部依赖；验证端按 survival probability 和硬件吞吐动态裁剪。
像机场调度：不是所有候选乘客都值得登机
大众转述版
这篇 DeepSeek 的 DSpark 论文讲的是怎么让大模型生成更快。传统大模型像一个人逐字打字，每个词都要等上一个词确认后才能继续。Speculative decoding 的想法是让一个小助手先打草稿，大模型一次性检查一段。但问题是，草稿越长，后面越容易错；而且高并发时，大模型检查一堆大概率会错的 token 也浪费资源。DSpark 的改法是两步：第一，让草稿模型虽然大部分并行生成，但加一点很轻的顺序依赖，让后面的词别跑偏；第二，给每个草稿 token 打置信度，根据当前机器负载决定验证到哪里为止。结果是离线 accepted length 更高，在线 DeepSeek-V4 部署里也把速度和吞吐边界往外推了。
问题设定：降低 L = (Tdraft + Tverify) / τ
论文把 speculative decoding 的速度拆成三个量：草稿时间 Tdraft、验证时间 Tverify、每轮接受长度 τ。Autoregressive drafter 的 τ 好，但 draft latency 随 block size 增长；parallel drafter 的 Tdraft 好，但后缀缺少条件依赖导致 τ 掉；固定长度验证又在高并发下浪费 target model capacity。
ABC → D → EFGH → keep EFG, drop H
输入
Prompt 是 ABC，target model 先产生 D 作为 anchor。
草稿
DSpark 用 parallel backbone + sequential head 生成 EFGH。
调度
置信度头给 c1-c4；scheduler 保留 EFG，丢掉低置信 H。
验证
target model 并行验证 EFG。E/F 接受，G 被拒后由 target 纠正成 G*。
三个核心概念
Speculative decoding
白话: 小模型先写草稿，大模型批量审核。
类比: 实习生先起草邮件，经理只改需要改的地方。
边界: 这里不是近似审核；标准 rejection sampling 仍保持 target distribution。
技术: draft model proposes block, target model verifies prefix in one pass.
Semi-autoregressive generation
白话: 大部分并行算，关键处补一点“看前文”的能力。
类比: 多人同时写句子，但第二个人先看第一个人实际写了什么。
边界: 它不是完整 autoregressive；sequential head 必须很轻。
技术: parallel logits U_k plus transition bias B_k over sampled prefix.
Confidence-scheduled verification
白话: 不检查所有草稿，只检查最有可能通过且系统负担得起的前缀。
类比: 机场安检高峰期优先放行证件最完整的队列。
边界: 不是只看单 token confidence；要看 prefix survival 和硬件吞吐曲线。
技术: maximize expected throughput Θ = τ · SPS(B).
论文证明了什么，没证明什么
Accepted length improves offline
Table 1: DSpark beats Eagle3 and DFlash across Qwen3/Gemma models and math/code/chat domains.
Caveat: offline scheduler disabled, so this isolates drafter quality, not full system gain.
Suffix decay is real for pure parallel draft
Figure 2: DFlash conditional acceptance drops at later positions; Eagle3 stays stable/upward.
Caveat: detailed plot shown on Qwen3-4B.
Confidence head can prune bad suffixes
Figure 5/6: threshold sweep raises acceptance rates; STS reduces ECE to about 1%.
Caveat: static sweep is diagnostic; production uses hardware-aware scheduling.
Production frontier shifts
Figure 7/8: live DeepSeek-V4 traffic shows 60-85% V4-Flash and 57-78% V4-Pro per-user speedups at matched capacities.
Caveat: production telemetry is not independently reproducible from the paper alone.
这篇 paper 自己承认的边界
DSpark 即使裁掉低置信验证，仍然要先付出固定 draft-side cost 来生成 γ-token block。对于本来 acceptance rate 很低的复杂请求，这个 upfront drafting compute 可能收不回来。论文提出未来可做 difficulty-aware early exiting，让这类请求绕过 full-block generation。
My inference / 我的推断：DSpark 最适合“有足够可预测性 + 系统负载动态变化 + target verification 昂贵”的服务场景；如果请求极难预测，或者系统不缺 target capacity，收益会变小。
两种场景怎么讲
3-minute technical version
DSpark attacks speculative decoding from both model architecture and serving scheduler. Architecturally, it keeps the heavy drafter parallel but adds a lightweight Markov/RNN sequential head, so later draft tokens condition on sampled prefix tokens and suffer less suffix decay. System-wise, it trains a calibrated confidence head to estimate prefix survival probabilities, then schedules verification length by maximizing expected throughput under the profiled SPS(B) curve. Offline, this raises accepted length versus Eagle3 and DFlash; online, the adaptive scheduler prevents verification waste under load and shifts the DeepSeek-V4 serving Pareto frontier.
Nontechnical friend version
想象大模型写字很慢，于是找了个小助手先写一段草稿。以前的问题是，小助手写得越长，后面越容易乱，而且老板还要浪费时间检查明显会错的部分。DSpark 让小助手写草稿时稍微参考前面已经写出的词，再根据每个词通过检查的概率和当前忙不忙，决定检查到哪里。这样既不牺牲最终大模型的结果，又能让系统更快服务更多人。