DSpark：让投机解码同时解决后缀质量与生产验证浪费

1. DSpark 在 LLM 服务中的位置：只改 decode cycle，不改模型语义

长 prompt 的 prefill、KV cache 分页、请求 admission 和持续批处理仍然存在。DSpark 出现在 decode 阶段：1 个轻量 drafter 先提出候选块，完整 target 在 1 次较宽的前向中验证其中的前缀，接受的 token 才能进入最终序列。官方 V4-Pro-DSpark 模型卡明确说明这是原 V4-Pro checkpoint 外加 speculative module，而不是新的基础模型。

因此 DSpark 的收益只可能体现在输出 token 的关键路径。它不减少预填充、不会凭空降低 KV 大小，也不能取代 02 · Prefill、decode 与批处理 中的 chunking 和 PD 设计。

2. 1 个标准 speculative cycle：提出、验证、提交、回滚

令已经提交的 token 为前缀 \(x\)。drafter 从自己的条件分布 \(q\) 按顺序产生 \(y_{1:\gamma}\)。target 对 \(x\mathbin{\Vert} y_{1:\ell}\) 做带因果 mask 的 verify，获得各位置 target distribution \(p_{1:\ell}\)。验证从左向右：一旦 \(y_k\) 被拒绝，后面的草稿都在不成立的条件前缀下生成，必须丢弃。

所有候选都被接受时，可从 target 的 bonus distribution 继续产生 1 个 token；首次拒绝时，系统用 target 的残差分布生成 correction。这样每轮至少有 1 个 target-correct token，且不必把验证后的每个 candidate 都对外输出。

3. 概率不变量：无损来自 residual sampling，不来自 drafter 准确

对候选 token \(v\)，标准接受概率是 \(\min(1, p(v)/q(v))\)。若拒绝后直接从完整 \(p\) 采样，drafter 与 target 重叠的概率质量会重复记账，分布将偏离 target。正确的修正只取 target 相对于 drafter 额外拥有的质量。

所以 drafter 可以很差而仍然无损，只是速度会差。反过来，接受率很高也不说明实现正确：top-k 直接接受、只在 target 或 drafter 一侧施加 JSON grammar、不同 temperature/top-p、不同 tokenizer 或不同 LoRA revision 都会破坏上述等式。完整通用推导见 21 · Speculative Decoding 与 MTP；本页以后只讨论 DSpark 怎样改善草稿质量和验证预算。

4. 动态长度也要无损：admission 不能利用未来 token 的实际值

“验证到第几位”的决定也会影响输出概率。若 scheduler 观察了第 \(k\) 个 token 的采样结果，或观察到由它决定的后继置信度，随后才决定是否验证第 \(k\) 位，选择过程就会偏向某些 token。被选中这一事件不再独立于 token 的实现值，标准 rejection-sampling 证明随之失效。

DSpark 论文将这个要求描述为 causal / non-anticipating admission。理论 greedy 版本在预计吞吐不再提升时停止继续看后缀；生产版使用历史容量估计来给下一轮定物理容量，避免用当前 candidate 的真实值回看筛选它。这个限定比“confidence 高就多验几个”严格得多。

5. 速度账本：后缀接受率与 target batch 容量必须一起优化

1 次 cycle 的延迟可以分为 drafter、scheduler、target verify 和 commit。令 \(\tau\) 为最终输出 token 数，时间是否下降取决于候选前缀带来的期望输出能否抵消额外 verify。后缀位置只能在此前所有位置通过时被提交，因此每位价值是条件接受率的连乘，不是独立相加。

在低并发、target 没有饱和时，多验 1 个低置信 token 的机会成本较小；在高并发时，它直接占用另一个用户可用的 target query slot。DSpark 的第 2 个问题正是把“最大草稿长度”转换为“本轮每个 request 的正期望回报验证长度”。

6. DSpark 的半自回归思想：并行 backbone 负责容量，顺序头补块内依赖

纯自回归 drafter 能让第 \(k\) 位条件在已采样的前缀上，后缀质量通常更好，但 drafting latency 随 \(\gamma\) 近似线性增长。纯并行 block drafter 1 次前向给出全部位置，速度很高，但各位置未条件于块内实际采样到的 token；当上下文有多种可行延续时，多个边缘分布会组合成不一致的后缀，接受率通常越往后越低。

DSpark 的公开设计分成两段：较重的 parallel backbone 1 次生成每个位置的 base logits 与 hidden states；轻量 sequential head 根据 anchor 和已采样的块内前缀，修正下 1 位置的 logits。完整 target decoder 不会为草稿重复执行多次，顺序工作只加在成本较低的 drafter 上。

7. Markov 与 RNN head：它们改变 \(q\)，不改变最终 \(p\)

论文把 drafter 条件分布抽象为 base logits \(U_k\) 加上依赖块内前缀的偏置 \(B_k\)。最终 drafter 分布因而是 1 个具有内部条件依赖的 \(q\)，但 target 仍以自己的 \(p\) 决定接受和 correction。

Markov head 只看上一个已经采样的 token，论文用低秩分解避免保存完整词表乘词表的转移矩阵；RNN head 维护更长的块内 state。前者更像 1 张轻量条件查表，后者表达力更高但多出状态更新与部署复杂度。它们的作用是减缓 suffix decay，而非改变 speculative decoding 的概率证明。

论文实验默认值与发布 checkpoint 需要分开看。官方 V4-Pro-DSpark config 公开了该变体的 dspark_block_size=5、dspark_target_layer_ids=[58,59,60] 和 dspark_markov_rank=512；这些数值只描述当前 checkpoint，不能外推到所有 DSpark 模型或线上服务的实际验证长度。

8. Confidence head：需要预测“前缀存活率”，不能只给 token 打分

第 4 个 candidate 的收益以“前 3 个都被接受”为前提。DSpark 的 confidence head 因此需要估计各位置的条件接受率 \(c_{r,k}\)，scheduler 使用累积 survival probability \(a_{r,k}\) 评估验证到此处的期望价值。只看本位的 logit margin 或 entropy，无法正确量化后缀可提交的概率。

如果 confidence 只是排序对、绝对值却过度自信，用它乘硬件吞吐曲线会做出错误的 capacity 决策。论文因此采用按位置从左到右的后验温度校准来校正累计概率。实际服务要按 model revision、sampling 参数、domain、量化和上下文长度重测校准；代码、数学、开放聊天和工具调用不能共用 1 张永不过期的 calibration table。

9. Hardware-aware prefix scheduler：全局选择 prefix-closed 的 target work

本轮有 \(R\) 个请求，每个请求挑 1 个验证前缀长度 \(\ell_r\)。总物理 query token 数为 \(B\)，实测引擎在该形状的步骤吞吐记作 \(\operatorname{SPS}(B)\)。scheduler 的目标不再是“让每个请求都用最大 \(\gamma\)”，而是选择所有 request 的前缀集合，使预计有效输出乘以实际硬件速率最大。

候选必须 prefix-closed，不能只验证某个 request 的第 5 位。论文的 causal greedy 过程按累积存活率加入候选，发现 \(\Theta\) 不再改善就停止。相比每 request 固定阈值，这能随全局 batch 负载变化决定“本轮应把 target 算力留给谁”。

10. CUDA Graph 与异步容量：预测物理 shape，当前分数决定逻辑选择

真实 \(\operatorname{SPS}(B)\) 经常不是平滑曲线：CUDA Graph capture size、workspace、kernel tile、通信边界和 KV 容量会形成阶梯。与此同时，zero-overhead scheduling 要求下一步的物理 batch size 在当前 GPU 步尚未完成时便确定；等待同步 confidence 计算会形成 host-side bubble。

DSpark 论文提出以 2 步之前的 confidence 预测即将可用的容量 \(K\)，并用当前的累计 confidence 在该容量内做 top-K prefix selection。前者只是对物理 shape 的历史近似，后者仍必须对当前且尚未泄露的 candidate 排序。论文借这个异步边界处理图捕获与因果 admission 的矛盾；“2 步”是其公开实现的设计点，不是可直接复制到所有 runtime 的参数。

11. KV cache 状态机：验证过不等于已经提交

target 已提交的 KV 是可见前缀；target verify 为 candidate 分配临时页或临时 block-table 映射。若 drafter 不能与 target 共用 cache，还会有独立 drafter KV。首个 rejection 后，只有 accepted prefix 与 correction 对应的状态可提升为 committed；所有未提交 candidate 的 K/V、logprob、attention metadata 和 drafter 分支都必须释放或回滚。

常见事故包括先向客户端流式发送、后发现 KV commit 失败；只清 target 临时页而遗留 drafter 页；取消后迟到的 remote draft 写入新 epoch；共享 prefix page 未做 copy-on-write。DSpark 的变长验证不会替你解决这些事务问题，反而要求更严密的状态边界。缓存基础见 04 · KV cache 与内存。

12. Continuous batching：调度器的账本从“请求数”升级为 candidate token

1 个 DSpark request 会经过 DRAFT、READY_TO_VERIFY、VERIFYING、COMMITTING 与 FALLBACK_AR。每轮 scheduler 要同时给普通 decode、prefill chunk、drafter、target verify、temporary KV 和 commit 留预算。只限制 active request 数会掩盖某个 request 贡献 1 个还是 5 个 target positions 的差别。

公开 SGLang 文档要求大于默认 capture batch 的 DeepSeek MTP 同时调整 max-running-requests 与 CUDA graph batch list，并公开 overlap scheduling 参数。这说明 speculation 是 runtime shape 与资源会计问题，不是把 1 个模型 flag 打开即可稳定获益。具体 scheduler 基础见 05 · Runtime scheduler。

13. 变长 verify 内核：把逻辑序列关系交给 marker，而不是 padding

若 A 需要验证 3 个 token、B 需要 1 个、C 需要 2 个，朴素实现会把它们 pad 到 3，重新制造验证浪费。DSpark 论文披露的 DeepSeek-V4 路径将这些 logical tokens flatten 成一段连续物理 query rows，再将每条序列的边界和可见关系以 marker tensor 交给 sparse attention。物理 kernel 因而处理规则的 token list，逻辑依赖仍由 block table 和 marker 表达。

论文称 V4 的 index-attention 与 compress kernels 需要为这种变长路由适配。实现时要分别测量 marker 构造、flatten/gather、index-attention、compress kernel 与通信 overlap，避免把多段执行成本合并成 1 个 kernel 名称。

14. TP、EP 与 MoE：candidate token 小，验证后的 hidden-state 流很大

草稿 token id 本身只占很少字节。成本主要来自 target verify 逐层触发的 tensor-parallel collective、expert-parallel all-to-all、attention/KV 读写、dispatch/combine 和 GPU stream 同步。每多验证 1 个 token，即使最后被拒绝，也可能已经支付 expert 选择与通信成本。

V4-Pro 官方模型卡示例组合 data parallel、expert parallel、MoE backend 和 DSpark，说明它必须与并行策略协同。算子与通信基础见 03 · GPU 算子，更宽泛的 speculative/MTP 比较见 21 · 总览。

15. 失败模式：算法正确、状态正确、性能正确是三套独立测试

• 算法：p/q 采用不同 tokenizer、adapter、sampling policy 或 grammar；拒绝后没从 residual 采样；admission 读取未来 token。
• 状态：temporary KV 未回滚；block table 和 streaming output 非原子；RNG 走不同拒绝分支后失同步；cancel 后仍 commit。
• 性能：drafter 权重和临时页挤掉普通 decode；固定 gamma 在高并发下吞掉 batch capacity；graph shape miss 静默退回 eager。
• 分布式：各 TP/EP rank 对 candidate layout 认识不一致；A2A token counts 与 marker 错位；远端草稿返回旧 model epoch。
• 观测：只看平均 accepted length 或单请求 tok/s，遗漏 P99 ITL、wasted verify、KV peak、A2A 与 fallback。

16. 测量 DSpark：先验证 target-equivalence，再看在线 Pareto 曲线

DSpark 论文在 live traffic、匹配 aggregate throughput 的计时边界下，相对既有 MTP-1 baseline 报告 V4-Flash 每用户生成速度提高 60%–85%，V4-Pro 提高 57%–78%。这些数字受硬件、并发、模型和计时边界约束，不能直接换算成 API 用户会看到的固定倍数。

1. 用小词表或可穷举 target 验证 acceptance/residual 实现；sampling 比较输出频率或 logprob 容差。
2. 固定 target revision、prompt、输出上限、temperature/top-p、quantization、TP/EP 配置，与 target-only 和 MTP baseline 对比。
3. 按代码、数学、开放聊天、JSON/tool-call、长上下文分桶，报告每位置的条件接受率。
4. 扫描并发与 maximum gamma，画 aggregate output throughput 对 per-user tok/s、TTFT、P99 ITL 的 Pareto 曲线。
5. 逐项采集 draft、scheduler、verify、commit、TP collective、EP all-to-all、temp-KV peak、reclaim 和 fallback rate。
6. 注入 OOM、cancel、model update、drafter crash、graph-shape miss 与网络抖动，确认都无损回退 target-only。

17. 部署蓝图：把 DSpark 作为受限策略，而不是永久打开的开关

合理的 guardrail 是：给 drafter 与临时 KV 设置硬上限；confidence 失校准、queue 过载或 predicted gain 为负时缩短/关闭 speculation；把 target、drafter、tokenizer、adapter 和 sampling 绑定到不可变 revision；按位置和 domain 分桶监测接受率与延迟。官方模型卡中的 method=dspark、num_speculative_tokens=7 是特定 checkpoint/runtime 的示例起点，不是通用生产命令。

18. DSpark 复现对象与验收项

19. Mainline 连接：将 DSpark 放回完整推理系统

20. 一手来源与版本边界