DominoTree：让推测解码的多米诺骨牌自己长出一棵树

一个老问题

你正在和 ChatGPT 聊天，它一个字一个字地往外吐。每个字大约耗时 30 毫秒，一段一千字的回复就要等半分钟。这背后是大语言模型（LLM）的自回归解码——每生成一个 token，都要把整个模型的前向传播跑一遍，哪怕你只是想多写一个”的”。

能不能让模型一次多猜几个字，再批量验证？这就是推测解码（Speculative Decoding）的核心思路：用一个轻量级的”起草者”（drafter）快速生成几个候选 token，再用大模型一次性并行验证它们。如果猜对了，就免费多拿几个 token；猜错了，就回退到正确位置。

听起来很美，但魔鬼藏在细节里。起草者怎么猜？猜多少个？怎么组织这些候选 token？这些问题的答案，直接决定了加速比的上限。

2026 年 7 月，来自台湾大学的研究者 Saw S. Lin（张志齐）和 Jyh-Shing Roger Jang 在 arXiv 发表了一篇论文 DominoTree: Conditional Tree-Structured Drafting with Domino for Speculative Decoding，给出了一个优雅的答案：让多米诺骨牌自己长出一棵树。

两条路线的困境

要理解 DominoTree 的贡献，得先看看它之前的两条技术路线。

第一条：块扩散（Block Diffusion）。代表方法是 DFlash。它一次性生成一整块 draft token（比如 8 个），速度极快。但问题在于，它为每个位置建模的只是边缘概率——也就是不考虑上下文的”孤立猜测”。第 3 个 token 猜什么，完全不管第 1、2 个 token 猜了啥。这就像你写小说时，每个字都单独预测，完全不看前面写了什么——准确率自然上不去。

第二条：最佳优先树（Best-First Tree）。代表方法是 DDTree。它从边缘概率出发，构建一棵候选 token 树，用最佳优先搜索扩展最有希望的分支。树结构天然能表达”如果第 1 个 token 是 A，那第 2 个 token 更可能是 B”这种条件关系。但 DDTree 有一个致命限制：它的评分函数是因子化的（factorized），也就是说，它把路径上的概率拆成一个个独立的边缘概率相乘。这数学上方便，但现实中的语言不是这么工作的。

然后来了 Domino。Domino 是一个 drafter，它在 DFlash 的基础上加了一个 GRU（门控循环单元）做因果校正。这使得每个 draft token 的分布是路径依赖的——第 3 个 token 的预测会考虑”前面猜了什么”。这比边缘概率准确得多。

但 Domino 只是一条线性序列，没有树结构。DDTree 想用树，但它的因子化评分又用不了 Domino 的条件信息。

两条路线的优势无法兼得。

DominoTree 的破局

DominoTree 的核心洞察很简单：为什么不直接用 Domino 的条件评分来构建树？

具体来说，DDTree 的评分函数是这样的：

   

每个位置独立打分，然后乘起来。这叫因子化。

DominoTree 的评分函数是这样的：

   

每个位置的打分依赖于之前选了什么。这叫非因子化。

数学上，这等价于沿着从根到节点的路径，逐个应用 Domino 的条件校正。直觉上，这就像下棋时，每走一步都要重新评估局面，而不是按预先算好的评分表走。

但这里有个工程难题：条件评分的计算量远大于边缘评分。如果每个节点的候选集是整个词表（通常 5 万+），那构建一棵深度 8 的树就要做 5 万 × 8 次条件评分——太慢了。

DominoTree 的解法叫候选限制（Candidate Restriction）：每个节点只对 top-M 个候选做条件评分，M 通常设为 8 或 16。这把计算量砍到了可接受的范围，同时几乎不损失质量——因为语言模型的概率分布本来就是长尾的，top-16 之外的 token 概率极低。

GPU 原生树构建器

光有算法还不够。推测解码的瓶颈往往不在算法本身，而在工程实现——尤其是树构建的开销。

传统做法用 Python 逐节点构建树，每构建一个节点都要启动一次 GPU kernel，开销巨大。在 4B 模型上，Python 构建器可能吃掉 30% 的端到端时间。

DominoTree 的第二个贡献是一个 GPU 原生的 CUDA-graph 树构建器。它把整个树构建过程编译成一个 CUDA graph，一次性在 GPU 上执行，中间不需要 CPU-GPU 同步。关键的是，这个构建器的输出和 Python 参考实现位级一致（bit-identical）——也就是说，它不改变任何接受率，只是把构建开销从”不可忽略”降到了”几乎免费”。

这个设计哲学很值得玩味：工程优化不应该改变算法语义。很多推测解码的”加速”其实是靠牺牲接受率换来的，而 DominoTree 的 CUDA 构建器做到了”加速但不改变结果”。

实验结果：6.6 倍加速

在 Qwen3-4B 上跨 8 个基准测试，DominoTree 的成绩单：

– 最高 6.6 倍加速 over 自回归解码 – 平均接受长度最高 10.7 tokens/轮——也就是说，每轮验证平均能接受 10.7 个 token – 在所有温度下都是”最高平均接受长度”的方法 – 相比 Domino（它所基于的 drafter）的吞吐量提升：整体 9-10%，Alpaca 数据集上最高 +22% – 相比 DDTree/CaDDTree：在 T=0（贪心解码）下全面胜出，在高温下略有损失

在 Qwen3-8B 上，DominoTree 保持了最高接受长度，在 T=0 下相比 DDTree 吞吐量提升 +24%。

一个值得注意的消融实验：增益来自条件评分，而不是树构建本身。如果你用同样的树结构但换成因子化评分，性能会掉到 DDTree 的水平。这说明 DominoTree 的核心价值确实是”条件信息”的引入，而不是”多了一棵树”。

一个类比：导航软件的路径规划

想象你在用导航软件。块扩散（DFlash）就像一个导航系统，为每个路口独立计算最可能的方向，不管你之前走了哪条路——它只知道”从 A 出发，最可能去 B”，但不知道”如果你刚从 C 转过来，那从 A 出发更可能去 D”。

DDTree 好一些，它建了一棵路径树，但评分时还是按”每个路口独立打分再相乘”——它知道路径之间有依赖，但数学上处理不了。

DominoTree 就像一个真正的导航系统：每到一个路口，都根据你实际走过的路径重新计算最优方向。这更符合现实，因为语言生成本质上就是一条路径依赖的过程——”The cat sat on the” 后面跟 “mat” 的概率，远高于跟 “quantum” 的概率，但这个判断只有在你知道前面是 “The cat sat on the” 时才成立。

局限与诚实评价

论文也坦率承认了几个局限：

1. 原型而非产品级系统：DominoTree 目前是一个研究原型，还没有集成到 vLLM、TensorRT-LLM 等推理框架中。实际部署还需要工程适配。

2. 自适应预算仍是开放问题：每轮构建多大的树、限制 top-M 设为多少，目前需要手动调参。论文尝试了一个叫 CondAdaptive 的自适应方案，但结果是负面的——校准驱动的自适应不如固定预算。

3. 高温下优势收窄：在 T>0 时，DominoTree 相比 DDTree 的优势会缩小，甚至在某些情况下略有落后。这是因为高温下模型分布更平坦，条件信息的边际价值下降。

4. 硬件对比不直接：A6000 和 RTX 5080 的吞吐量数据不能直接比较，因为架构差异。

更大的图景

DominoTree 的故事其实指向一个更深的道理：在 AI 系统中，很多”工程瓶颈”的本质是”信息利用不充分”。

DFlash 快，但它丢弃了路径依赖信息。DDTree 想用路径信息，但数学框架不允许。Domino 有路径信息，但没用树结构。DominoTree 把两者结合，不是靠什么惊天动地的新算法，而是靠”把已有的信息用对地方”。

这让我想起一个古老的工程原则：好的优化不是加更多东西，而是去掉不必要的限制。DDTree 的因子化假设是一个数学上的简化，方便推导但限制了表达力。DominoTree 去掉了这个假设，性能就上去了。

在 LLM 推理成本动辄百万美元的今天，6.6 倍加速不是小数目。如果你正在服务一个 4B 模型，这意味着同样的硬件可以服务 6.6 倍的请求量。而这一切都是训练无关（training-free）的——不需要重新训练模型，不需要额外数据，只需要换一个 drafter 的评分方式。

有时候，最好的创新就是看见房间里的大象。

—

论文链接：https://arxiv.org/abs/2607.08642

开源代码：https://github.com/slin-zhq/Domino-Tree

作者：Saw S. Lin (Zhiqi Zhang), Jyh-Shing Roger Jang（台湾大学信息工程学系）

发布日期：2026 年 7 月 9 日