DSpark 属于推测解码第三代。第一代用独立小模型做草稿（如标准推测采样），接受率仅 60% 左右，效率有限。第二代以 Medusa / EAGLE 系列为代表，EAGLE-3 通过复用目标模型顶层特征，将 3-token 接受率推至 82%，加速比可达 3-6.5 倍。DSpark 的独特之处在于第三代：不堆层数，用 2 层半自回归架构击败 EAGLE-3 的 5 层，并把控制权从「草稿质量」移交给了「系统调度」——推理加速的天平已从模型结构倾向了系统工程。

并行草稿模型（如 DFlash）一次产出所有候选 token，速度快但每个位置「看不见」前面的 token，导致第 7 个 token 的接受率从 0.72 骤降到 0.63。DSpark 的并行主干先快速铺开基础特征，再用仅 2 层的 Markov Head 或 RNN Head 逐 token 注入前缀依赖——相当于先画好轮廓，再一笔笔补细节。离线测试显示，2 层 DSpark 的接受长度已超越 5 层 EAGLE-3 约 30%，参数效率翻倍。

多用户并发时，盲目验证长草稿会让 GPU 算力被低置信 token 占满。DSpark 额外训练了一个置信度头，为每个候选 token 预测「存活概率」，并用顺序温度缩放将预测误差从 3%-8% 压到 1% 以内。硬件感知调度器据此动态截断低置信后缀：忙时只验证前几个高置信 token，闲时放开长度。这套调度让 DeepSeek-V4 在高并发下的系统吞吐提升 51%-52%，名义吞吐优势可达 6 倍以上。

DSpark 证实了「不拘泥于模型结构，转向系统调度」的可行性，但它留下的问题也很明确：草稿模型仍需要针对每个目标模型手工调参。下一阶段的焦点会是草稿架构的自动化搜索——能否让框架根据目标模型的参数规模、推理负载曲线自动生成最优的草稿模块（层数、顺序头类型、置信度阈值）？另外，DSpark 开源的 DeepSpec 训练代码库，可能成为行业的「推理优化标准套件」，让更多团队绕开重复造轮子，直接聚焦更高层的调度创新。

DSpark 在代码/数学/对话任务上表现优异，但它依赖一个关键假设：目标模型推理的 token 分布能被轻量草稿模块以线性成本近似。如果推理任务涉及大量罕见 token 或高度结构化的输出（如 JSON schema），半自回归的 Markov Head 能否保持 30% 以上的接受长度优势？另一个开放问题是：置信度调度在极端高并发（数千并发）下，自身的调度开销是否会抵消收益？这需要更大规模的线上 A/B 测试来回答。