arXiv’26 | DARTree：给 Diffusion Drafter 填一棵 AR 树，投机解码飙到 9.7×

原文：DARTree: Speculative Diffusion Decoding with Autoregressive Draft Trees

1. 前言：先把背景交代清楚

你有没有想过这样一个问题：投机解码的草稿模型，到底什么样的才算”好”？

一星期前我们刚聊过 DFlash——它把 drafter 从自回归（AR）换成了 Diffusion，一次 forward 直接把一整块 token 并行草拟出来，”打草稿”从串行苦力变成了一次性操作，给投机解码刷出了 6× 以上的加速。

但 DFlash 这种”并行整块猜”的草稿有个天生缺陷：block 内部的 token 之间没有因果依赖。每个位置都是独立取边际分布里的最高概率——单独看每个位置都没毛病，合起来却可能拼出 “no course” 这种鬼话。我在 DSpark 的解读里管这叫 suffix decay：草稿越长，越靠后的 token 越不靠谱。

接下来这个领域几乎所有的修修补补，本质都是同一件事：并行草拟块里缺的”序列条件依赖”，怎么低成本地补回来。

今天这篇 DARTree（arXiv 2608.13524，8 月 13 号刚挂出来）给的答案很妙：你手上已经有一个能把单条链修好的 AR correction head，为什么不让它去填一棵树？ 草稿做完后，树里保留多条互不冲突的候选路径，一次性验收；接受率直接起飞——在 GSM8K 上每轮平均收下 12.97 个 token，比 DFlash 多 98.6%，比目前最强的单链方案 Domino 多 27.9%，无损加速最高 9.73×。

听起来像又一次”把链换成树”的常规操作？往下看它的动机——树的好处大家都懂，之前的难点在于没人付得起树的代价。

2. 为什么之前没人做：串行 correction head + 树 = 打草稿比生成还慢

先说 DFlash 系 diffusion drafter 的完整流程：一次前向给出 block 的公共表征和 base logits，但想在 block 内部补上序列依赖，还得靠一个轻量的 AR correction head——每出一个草稿 token，就用 head 修正一次，这步本身是串行的。

这块 head 很轻，单次推理很便宜。问题出在你想在多棵候选路径上使用它的时刻：

Domino 用 correction head 修一条链——链上有了依赖，但一条链赌错一个位置就全盘皆输；
DDTree 先在 block 上用 heap 构建草稿树，但每从 heap 弹出一个节点，都要跟着跑一次 correction head 推理——这是逐节点串行计算，树里的节点一多，延迟当场爆炸。

论文里拆了一组数字：在 Qwen3-4B 上，逐节点串行的 correction 版本打一个草稿 round 要 62.7ms，而 DARTree 只要 28.5ms，前者换来的 τ 还更少。也就是说：“树”本身是好东西，”串行地建树”才是毒瘤——这组数据看着小，其实就是这整条线的拦路虎。

如下两图，动机拆解（左）和 DARTree 的总体流程（右）：一次 block 并行草拟 + 条件化树扩展 + 延迟裁剪（deferred pruning），最后 target 一次性验收：

DARTree 整体框架

延迟拆解：树构建方式决定了每轮开销

3. DARTree：把 AR Correction Head 从链迁移到树

3.1 基本流程

输入一个 anchor token，DARTree 沿用 DFlash 的一次 block-parallel 前向，得到共享的表征 ${H_d}$ 和 base logits ${L_d^{base}}$。关键在第二步：

候选生成：先解码 base logits，每个位置只保留 top-K 候选（默认 K=64），这等于预剪掉了所有”不可能成为树节点”的对象；
深度逐层扩展：第 $d$ 层时，把上一层存活的所有父节点批量喂给 correction head（一次矩阵运算算完），输出子节点打分；
打分函数：

\[s_\beta(u_{1:d}) = \sum_{i=1}^{d} \log q_i(u_i) + \beta \cdot d\]

其中 $q_i(u_i)$ 是修正后的位置条件概率，$\beta \le 0$ 是深度惩罚——惩罚树”长而浅”比”长而宽”更值，因为验收只看最长合法前缀，深度才是直接收益；

逐层裁剪：每层只留 top-W 个节点（修剪版 W=12 / 固定版 W=4），把宽度压住；
延迟裁剪（deferred pruning）：先扩一棵比最终更大的 supertree，再一次性全局选出 top-B 个节点（B=64）——论文 Lemma 1 保证在 $\beta \le 0$ 下，这个全局 top-B 等价于 heap 的 best-first 弹出，树重建一遍 + 一次裁剪，杜绝逐节点串行。

3.2 为什么这能跑起来：树是一次前向的副产品

验收一步全是标准操作：所有 draft token 一次性喂给 target model，用 tree attention mask 并行验证所有路径，取最长合法前缀。注意关键点——DARTree 全程只多了一次块并行前向 + 一次批量树修正前向，correction head 的逐节点串行开销正式取消，变成整层批处理 + 一次前向。

4. 效果：Acceptance Length 和 Speedup 全面开火

4.1 主结果

Table 1 对比 DARTree 与四条基线（AR baseline、DFlash、Domino、DDTree），在 Qwen3-4B/8B、温度 0 和 1、七个 benchmark 上全部打平。简单摘录 Qwen3-4B temp=0 的关键行：

GSM8K：τ=12.97，speedup 9.73×，比 DFlash 多收 98.6% 的 token，比 Domino 多 27.9%；
平均 τ=9.81，平均 speedup 6.99×；固定版（等宽 W=4）也有 9.36 τ / 6.55×；
温度 1 也不崩：平均 8.48 τ / 5.93×；
同比树方案 DDTree：τ 最多多 28.9%，speedup 最多多 22.7%；对比单链的 Domino：τ 最多多 46.8%，speedup 最多多 40.1%。

主结果：Qwen3-4B/8B 上的 τ 与 speedup

4.2 位置接受率：两头的好都占了

如下图，按草稿位置画接受率：DDTree 赢在早期（前几个位置接受率高），Domino 赢在后期（靠链式修正兜底），而 DARTree 把两头的长处都占了——GSM8K 上近半的 round 几乎整块被接受：

位置条件接受率对比

4.3 机制隔离与 DSpark 兼容

论文 Table 2 做了一次非常诚实的机制隔离：把 DARTree 的”延迟裁剪”换回朴素的”heap 弹出→修正”组合，GSM8K 上每 round 延迟从 28.5ms 飙回 62.7ms，speedup 从 9.7× 掉到 4.38×——真正的瓶颈是树的构建方式，不是树本身。

更实用的是 Table 3：把 correction head 换成 DSpark 开源的 Markov head，不重新训练、不多跑 backbone forward，DARTree 直接在 GSM8K/HumanEval/MT-Bench 上再赚 14.6%–40.6% 的 τ，speedup 最多再涨 34.3%。这说明 DARTree 不是 DFlash 专属补丁，而是给”任意 diffusion drafter 装树”的通用配件。

4.4 并发服务

单请求快不算数，服务端收益才是真金白银。在 RTX 6000 Ada + SGLang 上，并发度 C=2 时 DARTree 跑出 6.19× 提速（同期 DFlash 4.10×、Domino 5.79×）；并发到 C=4 时，配合自适应预算（B 从 64 收到 32、宽度从 12 收到 3）仍保持 5.66×，吞吐从 311.9 TPS 拉到 1766.2 TPS。另外深度惩罚 β 取 −0.2~−0.1、top-K 从 32 加到 512 都没什么影响——超参很钝，不挑环境。

5. 我的 Take

投机解码卷到现在，方向已经不再是”换个更聪明的 drafter”，而是在同一份草稿上把筹码铺开：DSpark 用置信度决定草稿长块，DARTree 用一棵树铺满块内所有可能路径。这篇最难得的地方是在 DSpark 的 Markov head 上零训练直接平放（Table 3），等于给整个 diffusion drafter 家族留了一条现成的加速通道。

要不要担心树的验收 overhead？树大了 target 一次 forward 全验完，代价主要是 tree attention mask——超长上下文里会略有感，但论文在预算被压到 16 个节点的极端情况下依然是正收益。更关键的是，这篇顺手证明了”并行草拟块的软肋，可以用一棵树来治”——方向感比具体数字更重要。

如果这篇文章涉及的投机解码、LLM 推理优化你想系统深入，可以看看我之前推出的《动手学AutoML：从 NAS 到大语言模型优化实战》，书里有专门一章讲 LLM 推理效率和 KV Cache 优化，和本文的推理加速是同一套工程背景。