DSpark 不是“换一个更聪明的 Transformer”，而是一套推理解码加速框架： 轻量草稿器先猜一小段，目标模型一次验一段；再根据“这段有多可能通过”和“GPU 此刻有多忙”，决定究竟验多长。
生成阶段通常是自回归的：第 2 个 token 要等第 1 个 token 出来，第 3 个又要等前两个。每多写一个 token，庞大的目标模型就要再做一次前向计算。
下面每亮一次“大模型”，就代表一次昂贵的目标模型前向计算。
token 是模型处理文字的基本片段，可能是一个字、半个词、标点或代码片段。这里把它画成“词块”，只是为了便于观察。
若一次循环花费“草稿时间 + 验证时间”，却能一次接收更多 token，那么平均每个 token 的时间就会下降。DSpark 的全部设计都在优化这三个量。
这叫 。关键不是盲信草稿，而是利用已知候选 token，让目标模型在一次前向中同时评估多个位置。
为降低认知负担，动画省略了标准算法中“bonus token”等实现细节。
DSpark 的价值不只是做投机解码，而是同时修复：草稿后半段容易失去一致性，以及高并发时验证太多会拖垮吞吐。
纯并行草稿的多个位置同时预测，后一个位置不知道前一个位置最终采样了什么。两个都合理的表达，可能被拼成不合理的混合。
后面的 token 只有在前面全部被接受时才有机会生效。GPU 空闲时多验几个几乎免费；GPU 忙时，多验一个低成功率 token 可能挤掉别人的请求。
看条件接受率随草稿位置变化：纯并行 DFlash 后段下滑，DSpark 用轻量顺序依赖把曲线托住。
你可以把 DSpark 记成两个互补的补丁：半自回归草稿修质量，置信度调度修系统效率。
① 顺序头给基础 logits 加“转移偏置”：
pₖ(v) ∝ exp(Uₖ(v) + Bₖ(已采样前缀, v))
Uₖ 来自一次并行骨干；Bₖ 很轻，只负责让后缀与已采样前缀保持一致。
② Markov head 的低秩近似：
B(前一 token, ·) = W₁[前一 token] · W₂
论文默认秩 r=256，避免保存巨大的“词 × 词”转移矩阵。
③ 第 k 位前缀存活概率：
aₖ = c₁ × c₂ × … × cₖ
越往后，必须闯过的门越多，所以即使单点 cₖ 尚可，累计 aₖ 也会下降。
④ 调度器优化目标：
期望系统吞吐 Θ = 期望产出 τ × 引擎步速 SPS(B)
它不是笼统的“模型自信”，而是更具体的条件概率：在前面草稿都被目标模型接受的前提下，这一位也被接受的概率。训练标签来自草稿分布与目标分布之间的总变差距离。
因为神经网络置信度常偏高，论文又做 Sequential Temperature Scaling（STS）校准，让累计存活概率更接近真实接受率。
目标模型保持冻结；训练并行草稿骨干、顺序头和置信度头。损失包含三部分：预测真实 token 的交叉熵、贴近目标分布的总变差损失、以及置信度预测损失。
更靠前的位置权重更大，因为前面一旦拒绝，后面的草稿全部失效。
RNN head 能记住整段草稿前缀，长块上略有额外收益；但论文实验认为提升有限，而部署复杂度更高。生产配置因此使用更简单的一阶 Markov head。
下面按论文 Algorithm 1 做一个教学模拟：把所有请求的“下一枚候选 token”按累计存活概率排序，逐个加入，直到继续加入反而降低期望吞吐。
每个小格显示条件接受率 cₖ；颜色表示当前是否送去验证。
离线实验主要衡量“每轮能接受多长”；线上生产实验同时考察单用户生成速度与整机吞吐。两类数字不能混为一谈。
在 Qwen3 4B / 8B / 14B 上，DSpark 对比自回归 Eagle3 与并行 DFlash。
每用户生成速度（tok/s/user）提升范围。
每用户生成速度提升范围。
Flash 在 80 tok/s/user、Pro 在 35 tok/s/user 的整机吞吐提升。
论文特别提醒：此时旧基线已接近服务边界、并发能力坍塌。大倍率更适合解释为“DSpark 把可行的交互速度边界推远了”，不应当当作日常场景的典型加速倍数。
不考术语拼写，只考你能否抓住因果关系。
完成三题后，这里会生成一段可带走的总结。