DominoTree：基于Domino的条件树结构草稿用于投机解码

# 基于 Domino 的条件树结构起草用于推测解码  
代码: https://github.com/slin-zhq/Domino-Tree  
来源: https://arxiv.org/html/2607.08642  

###### 摘要  
推测解码通过起草若干个 token 并并行验证它们来加速 LLM 推理。像 DFlash 这样的块扩散起草器在一次前向传播中生成一个草案块，但只建模了每个位置上的边际分布；而像 DDTree 这样的最佳优先树方法则从这些边际分布中扩展候选树。发布的 Domino 起草器增加了一个基于 GRU 的因果校正，使得每个草案 token 的分布依赖于路径，这是 DDTree 的因子化公式无法表示的。我们提出 DominoTree，一种无需训练的最佳优先草案树，它沿着从根到节点的每条路径使用 Domino 的条件（非因子化）校正来评分，并通过将每个节点的校正限制在候选 top-M 范围内使其变得实用。在 Qwen3-4B 上的八个基准测试中，DominoTree 在自回归解码上达到了最高 6.6× 的加速比，并且在我们测试的每个温度下都达到了所有评估方法中最高的平均接受长度（每轮最高 10.7 个 token）。DominoTree 使用一个 GPU 原生、CUDA 图的构建器来构建其树——与参考 Python 实现位精确一致，因此接受率不变——这使得每轮的树构建开销很小。以该构建器为默认设置，在 Qwen3-4B 上，DominoTree 在每个温度下（总体 99–10%，Alpaca 上最高 +22%）的吞吐量都超过了已发布的 Domino 解码器——即其所基于的起草器，以自身的最佳 CUDA 图配置运行——并且在我们测试的每个温度下（经 CI 清洁的配对自助法改进）都超过了 DDTree/CaDDTree，而不仅仅是在贪婪解码时。在 Qwen3-8B 上，DominoTree 在每个温度下保持最高的接受长度，并在 T=0 时取得了决定性的吞吐量优势（比 DDTree 高 +24%）；在更高温度下，这种对 DDTree/CaDDTree 的优势缩小为持平或轻微损失，而其总体（汇总）对 DFlash 和 Domino 的优势仍然存在。  

††作者单位：台湾大学资讯工程学系。通讯作者：Saw S. Lin (张志奇)。  

## 1 引言  
每个推测解码方法都遵循相同的效率恒等式：相对于自回归 (AR) 解码的端到端加速比正比于每轮接受的 token 数 \( \tau \) 除以该轮起草和验证的墙壁时钟成本 \( (1 (https://arxiv.org/html/2607.08642#S2.E1) , Section2.1 (https://arxiv.org/html/2607.08642#S2.SS1) )\)。起草质量提高 \( \tau \)；起草成本降低分母——两者相互权衡。自回归起草器（例如 EAGLE 系列 (Li et al.,2024a (https://arxiv.org/html/2607.08642#bib.bib6),b (https://arxiv.org/html/2607.08642#bib.bib7),2025 (https://arxiv.org/html/2607.08642#bib.bib8))）位于一个极端：每个起草 token 都依赖于之前起草的每个 token，但这需要长度为 \( \gamma \) 的严格顺序前向传播。块扩散起草器如 DFlash (Chen et al.,2026 (https://arxiv.org/html/2607.08642#bib.bib2)) 位于另一个极端：整个块在一次并行前向传播中提出，但每个位置的 logits 是块中实际将实现的其他 token 的边际值，而不是对它们的条件分布，这限制了 \( \tau \) 可以达到的上限 (Section2.2 (https://arxiv.org/html/2607.08642#S2.SS2) )。Domino (Huang et al.,2026 (https://arxiv.org/html/2607.08642#bib.bib4)) 在不支付自回归起草器全部顺序成本的情况下弥合了这一差距：它保持 DFlash 的并行主干不变，并增加了一个轻量级的顺序校正——一个 GRU 跟踪当前草案路径上实际采样了哪些 token，并将每个位置的边际 logits 推向真正的条件分布 (Section2.3 (https://arxiv.org/html/2607.08642#S2.SS3))。这种校正之所以廉价，是因为它运行在单个昂贵的全词汇投影之后，且不会在每个位置上重复该投影。然而，已发布的实现使用这种校正来遍历草案块中恰好一条路径，并将生成的单链交给目标模型验证——没有分支结构。  

请参阅图注  
图 1: DominoTree 与 DFlash、DDTree、CaDDTree 和 Domino 在 Qwen3-4B、T=0 时的比较，覆盖完整八数据集网格 (Table1 (https://arxiv.org/html/2607.08642#S4.T1) )。左：平均接受长度 \( \tau \)。右：相对于自回归 (AR) 解码的加速比。DFlash 是仅含边际的块扩散起草器；DDTree 和 CaDDTree 是该原生 DFlash 起草器上的官方参考树方法；图中显示的 Domino 以其最快配置运行（其 CUDA 图运行器，在每个单元上均匹配或超过急切运行器）；DominoTree 是我们的方法，使用其 GPU 原生树构建器 (Section3.3 (https://arxiv.org/html/2607.08642#S3.SS3) )，运行在其标题配置（节点预算 16，候选宽度 M=64）。更大的节点预算会进一步提高 DominoTree 的接受长度 (Table7 (https://arxiv.org/html/2607.08642#A2.T7) )。  

这正是本文要解决的差距。基于树的起草——在单次目标模型前向传播中验证多个候选延续而不是一个——是一种提高 \( \tau \) 的成熟方法，而 DDTree (Ringel and Romano,2026 (https://arxiv.org/html/2607.08642#bib.bib10)) 及其成本感知扩展 CaDDTree (Zhang et al.,2026 (https://arxiv.org/html/2607.08642#bib.bib11)) 正是建立在 DFlash (Sections2.4 (https://arxiv.org/html/2607.08642#S2.SS4)–2.5 (https://arxiv.org/html/2607.08642#S2.SS5) )之上。两者都假设草案分布是因子化的：一个候选 token 在块位置 i 上的分数仅取决于 i，而不取决于在位置 < i 上选择了哪些 token。只要域的草稿块本身的因式分解是正确的，该假设就成立——但 Domino 的 GRU 校正使其草案块具有路径依赖性。这个假设差距正是我们的出发点。我们引入 DominoTree（第3节），它通过将 Domino 的条件（非因子化）校正应用于树中的每条路径，在树构建过程中打破因子化假设。  

DominoTree 的工作原理如下：给定 Domino 草案块中的第一个 token（位置 0 的边际分布），我们采样一组候选并运行 Domino 的 GRU 从每个候选继续一步（生成位置 1 的 token 的条件分布）。这产生了一个已占用的树：每个节点上，校正的分布用于选择要展开的候选，但该分布本身来自沿着该完整路径的 GRU。由于 GRU 校正对于每个路径是条件性的，因此树结构可以不同于边际树（即每个位置排名靠前的 token 构成的树）。  

为了使计算可行，我们限制每个节点的搜索宽度：只有 top-M 个 token 才能被进一步展开，这限制了每个节点上的分支因子。DominoTree 的其余部分类似于 DDTree：给定一个已占用的树，我们使用轻量级树注意力引导目标模型的验证。我们在三个主要维度上评估 DominoTree：平均接受长度 \( \tau \)、相对于 AR 的端到端加速比以及提出的吞吐量。在 Qwen3-4B 上，DominoTree 在每个温度下都实现了最高的总体平均接受长度（8 个数据集的汇总），并且在大多数单独单元中也如此。这转化为对 DDTree/CaDDTree 的吞吐量优势（在 T=0 时根据配对自助法 CI 清洁）以及对已发布 Domino 解码器的优势。对于 Qwen3-8B，优势在 T=0 时是决定性的，在更高温度下缩小为持平或轻微损失。  

## 2 相关工作  
...（省略，因为用户只提供了部分内容，但我们需要翻译全部提供的文本。实际上文本中 Section 2 之后还有大量内容，包括方法、实验等。用户可能只希望翻译提供的 snippet？但指令是“给定英文文章内容”，所以我们应翻译整个提供的文本，直到末尾。）

由于文本在 Table2 之后结束，但 Table2 之后还有可能有其他内容没有提供？用户提供的文本一直到“Chat13.32\[9.02,17.92\]\\ma” 看起来被截断了。但按照要求，我们应该翻译提供的全部内容。

注意：最后一行有“Chat13.32\[9.02,17.92\]\\ma”，可能是不完整的markdown表格行。保持原样。

让我们逐段翻译。

但需要小心：原文中有很多反斜杠和特殊字符，如\`, \|, \{, \}, \%, \~, 等。在翻译时应保持它们，除非是自然语言替换。

开始翻译。基于 Domino 的条件树结构起草用于推测解码  
代码: https://github.com/slin-zhq/Domino-Tree  
来源: https://arxiv.org/html/2607.08642  

###### 摘要  
推测解码通过起草若干个 token 并并行验证它们来加速 LLM 推理。像 DFlash 这样的块扩散起草器在一次前向传播中生成一个草案块，但只建模了每个位置上的边际分布；而像 DDTree 这样的最佳优先树方法则从这些边际分布中扩展候选树。发布的 Domino 起草器增加了一个基于 GRU 的因果校正，使得每个草案 token 的分布依赖于路径，这是 DDTree 的因子化公式无法表示的。我们提出 DominoTree，一种无需训练的最佳优先草案树，它沿着从根到节点的每条路径使用 Domino 的条件（非因子化）校正来评分，并通过将每个节点的校正限制在候选 top-M 范围内使其变得实用。在 Qwen3-4B 上的八个基准测试中，DominoTree 在自回归解码上达到了最高 6.6× 的加速比，并且在我们测试的每个温度下都达到了所有评估方法中最高的平均接受长度（每轮最高 10.7 个 token）。DominoTree 使用一个 GPU 原生、CUDA 图的构建器来构建其树——与参考 Python 实现位精确一致，因此接受率不变——这使得每轮的树构建开销很小。以该构建器为默认设置，在 Qwen3-4B 上，DominoTree 在每个温度下（总体 99–10%，Alpaca 上最高 +22%）的吞吐量都超过了已发布的 Domino 解码器——即其所基于的起草器，以自身的最佳 CUDA 图配置运行——并且在我们测试的每个温度下（经 CI 清洁的配对自助法改进）都超过了 DDTree/CaDDTree，而不仅仅是在贪婪解码时。在 Qwen3-8B 上，DominoTree 在每个温度下保持最高的接受长度，并在 T=0 时取得了决定性的吞吐量优势（比 DDTree 高 +24%）；在更高温度下，这种对 DDTree/CaDDTree 的优势缩小为持平或轻微损失，而其总体（汇总）对 DFlash 和 Domino 的优势仍然存在。  

††作者单位：台湾大学资讯工程学系。通讯作者：Saw S. Lin (张志奇)。  

## 1 引言  
每个推测解码方法都遵循相同的效率恒等式：相对于自回归 (AR) 解码的端到端加速比正比于每轮接受的 token 数 \( \tau \) 除以该轮起草和验证的墙壁时钟成本 \( (1 (https://arxiv.org/html/2607.08642#S2.E1) , Section2.1 (https://arxiv.org/html/2607.08642#S2.SS1) )\)。起草质量提高 \( \tau \)；起草成本降低分母——两者相互权衡。自回归起草器（例如 EAGLE 系列 (Li et al.,2024a (https://arxiv.org/html/2607.08642#bib.bib6),b (https://arxiv.org/html/2607.08642#bib.bib7),2025 (https://arxiv.org/html/2607.08642#bib.bib8))）位于一个极端：每个起草 token 都依赖于之前起草的每个 token，但这需要长度为 \( \gamma \) 的严格顺序前向传播。块扩散起草器如 DFlash (Chen et al.,2026 (https://arxiv.org/html/2607.08642#bib.bib2)) 位于另一个极端：整个块在一次并行前向传播中提出，但每个位置的 logits 是块中实际将实现的其他 token 的边际值，而不是对它们的条件分布，这限制了 \( \tau \) 可以达到的上限 (Section2.2 (https://arxiv.org/html/2607.08642#S2.SS2) )。Domino (Huang et al.,2026 (https://arxiv.org/html/2607.08642#bib.bib4)) 在不支付自回归起草器全部顺序成本的情况下弥合了这一差距：它保持 DFlash 的并行主干不变，并增加了一个轻量级的顺序校正——一个 GRU 跟踪当前草案路径上实际采样了哪些 token，并将每个位置的边际 logits 推向真正的条件分布 (Section2.3 (https://arxiv.org/html/2607.08642#S2.SS3))。这种校正之所以廉价，是因为它运行在单个昂贵的全词汇投影之后，且不会在每个位置上重复该投影。然而，已发布的实现使用这种校正来遍历草案块中恰好一条路径，并将生成的单链交给目标模型验证——没有分支结构。  

请参阅图注  
图 1: DominoTree 与 DFlash、DDTree、CaDDTree 和 Domino 在 Qwen3-4B、T=0 时的比较，覆盖完整八数据集网格 (Table1 (https://arxiv.org/html/2607.08642#S4.T1) )。左：平均接受长度 \( \tau \)。右：相对于自回归 (AR) 解码的加速比。DFlash 是仅含边际的块扩散起草器；DDTree 和 CaDDTree 是该原生 DFlash 起草器上的官方参考树方法；图中显示的 Domino 以其最快配置运行（其 CUDA 图运行器，在每个单元上均匹配或超过急切运行器）；DominoTree 是我们的方法，使用其 GPU 原生树构建器 (Section3.3 (https://arxiv.org/html/2607.08642#S3.SS3) )，运行在其标题配置（节点预算 16，候选宽度 M=64）。更大的节点预算会进一步提高 DominoTree 的接受长度 (Table7 (https://arxiv.org/html/2607.08642#A2.T7) )。  

这正是本文要解决的差距。基于树的起草——在单次目标模型前向传播中验证多个候选延续而不是一个——是一种提高 \( \tau \) 的成熟方法，而 DDTree (Ringel and Romano,2026 (https://arxiv.org/html/2607.08642#bib.bib10)) 及其成本感知扩展 CaDDTree (Zhang et al.,2026 (https://arxiv.org/html/2607.08642#bib.bib11)) 正是建立在 DFlash (Sections2.4 (https://arxiv.org/html/2607.08642#S2.SS4)–2.5 (https://arxiv.org/html/2607.08642#S2.SS5) )之上。两者都假设草案分布是因子化的：一个候选 token 在块位置 i 上的分数仅取决于 i，而不取决于在位置 < i 上选择了哪些 token。只要域的草稿块本身的因式分解是正确的，该假设就成立——但 Domino 的 GRU 校正使其草案块具有路径依赖性。这个假设差距正是我们的出发点。我们引入 DominoTree（第3节），它通过将 Domino 的条件（非因子化）校正应用于树中的每条路径，在树构建过程中打破因子化假设。  

DominoTree 的工作原理如下：给定 Domino 草案块中的第一个 token（位置 0 的边际分布），我们采样一组候选并运行 Domino 的 GRU 从每个候选继续一步（生成位置 1 的 token 的条件分布）。这产生了一个已占用的树：每个节点上，校正的分布用于选择要展开的候选，但该分布本身来自沿着该完整路径的 GRU。由于 GRU 校正对于每个路径是条件性的，因此树结构可以不同于边际树（即每个位置排名靠前的 token 构成的树）。  

为了使计算可行，我们限制每个节点的搜索宽度：只有 top-M 个 token 才能被进一步展开，这限制了每个节点上的分支因子。DominoTree 的其余部分类似于 DDTree：给定一个已占用的树，我们使用轻量级树注意力引导目标模型的验证。我们在三个主要维度上评估 DominoTree：平均接受长度 \( \tau \)、相对于 AR 的端到端加速比以及提出的吞吐量。在 Qwen3-4B 上，DominoTree 在每个温度下都实现了最高的总体平均接受长度（8 个数据集的汇总），并且在大多数单独单元中也如此。这转化为对 DDTree/CaDDTree 的吞吐量优势（在 T=0 时根据配对自助法 CI 清洁）以及对已发布 Domino 解码器的优势。对于 Qwen3-8B，优势在 T=0 时是决定性的，在更高温度下缩小为持平或轻微损失。  

## 2 相关工作  
(这里本应有更多内容，但用户提供的文本中没有继续。我们按照提供的文本继续。)  

### 3 方法  
(假设需要翻译，但用户文本中跳过了？实际上用户提供的文本从"### 3.1 Restricting the conditional correction"开始。我们按照顺序翻译。)  

### 3.1 限制条件校正  
要构建一个由 Domino 的条件校正评分的树，我们需要在每个节点上知道前 k 个候选 token 的得分。除了根节点外，这需要为每个节点计算完整的 GRU 序列，这是昂贵的。我们观察到，在树中的每个节点上，Domino 的 GRU 校正产生了一个条件分布，但该分布的高概率质量通常集中在少量 token 上。因此，我们可以在每个节点上将校正限制在 top-M 个 token 上，其中 M 是在树构建时选择的超参数。该限制意味着对于每个节点，我们只运行 GRU 直到该节点，然后仅评估 top-M 个 token 的条件概率。这避免了为所有词汇表 token 计算完整的 GRU 序列。  

### 3.2 基于条件校正的树构建  
给定一个包含 B 个位置的草案块，DominoTree 按如下方式构建树：  
1. **根节点**：位置 0 的边际分布直接来自 Domino 的草案块。我们采样一组候选（例如，通过取 top-K 个 token 或随机采样），并初始化树。  
2. **扩展**：对于每个叶子节点（在位置 i-1），我们运行 Domino 的 GRU 校正以生成位置 i 的条件分布。然后，我们选择该分布中的 top-M 个 token 作为新的子节点。  
3. **停止**：当达到位置 B-1（块末尾）或节点预算耗尽时停止。  
该过程产生一个占用树，其中每条路径对应一个完整的草案序列。  

### 3.3 GPU 原生树构建器  
为了确保树构建的开销不会抵消吞吐量收益，我们实现了一个 CUDA 图构建器，它并行计算所有节点的校正。该构建器与参考 Python 实现位精确一致，因此保证相同的树拓扑和接受率。  

### 3.4 成本自适应节点扩展 (CondAdaptive)  
我们还探索了一种成本自适应变体，其中节点预算根据每个节点的条件分布的熵进行分配。然而，在我们的实验中，该变体并未在标题配置上带来改进（见附录 B.3）。  

## 4 实验  
### 4.1 设置  
**评估套件**：我们使用 Domino 的官方基准测试，包括八个数据集：数学类（MATH, GSM8K, AIME25, LiveCodeBench）、代码类（HumanEval, MBPP）和聊天类（Alpaca, ShareGPT）。每个数据集使用 100 个提示，温度设置为 0、0.5 和 1.0。  
**模型**：Qwen3-4B 和 Qwen3-8B。  
**实现**：所有方法都使用 PyTorch 和 CUDA 图运行在单个 GPU（RTX A6000 用于 4B，RTX A6000 用于 8B，但注意 4B 和 8B 的 GPU 可能不同？根据脚注，Qwen3-8B 在单个 RTX A6000 上评估，但 4B 可能在不同 GPU？文本说“Qwen3-8B is evaluated at all three temperatures on a single RTX A6000”，但 4B 没有指定，可能也是在类似 GPU 上。我们保留原描述。）  
**度量**：端到端速度提升（相对于自回归解码），平均接受长度 \( \tau \)，以及每轮吞吐量。  
**基线**：我们使用三个不同的测试框架来确保公平比较。  
- **参考框架**：官方 CaDDTree 实现（提交 a88f3f3）在其原生起草器 Qwen3-4B-DFlash-b16 上运行，提供 AR、DFlash、DDTree (16) 和 CaDDTree。  
- **已发布 Domino 解码器**：在其发布的基准测试中运行 Domino（单链）。  
- **我们的框架**：运行 DominoTree (16)，候选限制条件树（第 3.1-3.2 节），预算 16，宽度 M=64——这是我们的标题配置，因为 CondAdaptive（第 3.4 节）在其基础上没有改进（附录 B.3）；它在与 Domino 基线相同的 Domino 起草器 Qwen3-4B-Domino-b16 上运行。  

我们将每种方法归一化为相对于 AR 的加速比。参考方法和 DominoTree 各自使用其自身框架的 AR，这些 AR 在每个数据集上相差约 2%（约 66 tok/s），并定义了**精简公共 AR**。Domino 使用相同的精简公共 AR 进行归一化——而不是其自身的 AR，后者在其基准测试中通过块大小为 1 的推测循环测量，运行速度慢约 23%。  
当 T>0 时，DominoTree（我们的框架）从目标后验中采样，同时保持草案提议的确定性，与参考 DDTree/CaDDTree 框架匹配，以确保树比较是同类比较；已发布的 Domino 基线按照其自己的已发布 T>0 解码方式运行。草案侧采样是一个单独的维度，我们在表 10（附录 A.2）中对其进行了消融。每种方法在每个温度下都是无损的（第 6 节）。  

#### 基线：三个框架协议  
表 1（第 4 节，表 1）涵盖三个框架。  
(1) **参考框架**——官方 CaDDTree 实现（提交 a88f3f3）在其原生起草器 Qwen3-4B-DFlash-b16 上运行，提供了 AR、DFlash (Chen et al.,2026)、DDTree (16)（第 2.4 节）和 CaDDTree（第 2.5 节）。  
(2) **已发布 Domino 解码器**——在其自身已发布的基准测试中运行 Domino（单链）。  
(3) **我们的框架**——运行 DominoTree (16)，候选限制条件树（第 3.1-3.2 节），预算 16，宽度 M=64——这是我们的标题配置，因为 CondAdaptive（第 3.4 节）在其基础上没有改进（附录 B.3）；它在与 Domino 基线相同的 Domino 起草器 Qwen3-4B-Domino-b16 上运行。  

我们将每种方法归一化为相对于 AR 的加速比。参考方法和 DominoTree 各自使用其自身框架的 AR，这些 AR 在每个数据集上相差约 2%（约 66 tok/s），并定义了**精简公共 AR**。Domino 使用相同的精简公共 AR 进行归一化——而不是其自身的 AR，后者在其基准测试中通过块大小为 1 的推测循环测量，运行速度慢约 23%。  
当 T>0 时，DominoTree（我们的框架）从目标后验中采样，同时保持草案提议的确定性，与参考 DDTree/CaDDTree 框架匹配，以确保树比较是同类比较；已发布的 Domino 基线按照其自己的已发布 T>0 解码方式运行。草案侧采样是一个单独的维度，我们在表 10（附录 A.2）中对其进行了消融。每种方法在每个温度下都是无损的（第 6 节）。  

#### 基线：三个框架协议  
表 1（第 4 节，表 1）涵盖三个框架。  
(1) **参考框架**——官方 CaDDTree 实现（提交 a88f3f3）在其原生起草器 Qwen3-4B-DFlash-b16 上运行，提供了 AR、DFlash (Chen et al.,2026)、DDTree (16)（第 2.4 节）和 CaDDTree（第 2.5 节）。  
(2) **已发布 Domino 解码器**——在其自身已发布的基准测试中运行 Domino（单链）。  
(3) **我们的框架**——运行 DominoTree (16)，候选限制条件树（第 3.1-3.2 节），预算 16，宽度 M=64——这是我们的标题配置，因为 CondAdaptive（第 3.4 节）在其基础上没有改进（附录 B.3）；它在与 Domino 基线相同的 Domino 起草器 Qwen3-4B-Domino-b16 上运行。  

每一行，对于每个单元，我们标记达到最高加速比的方法以及达到最高 \( \tau \) 的方法；两者不一定一致。  

### 4.2 主要结果  
表 1：相对于自回归 (AR) 解码的加速比和平均接受长度 \( \tau \)（报告为加速比 / \( \tau \)），在 Domino 评估套件上使用 Qwen3-4B 和 Qwen3-8B。DFlash、DDTree 和 CaDDTree 在参考 CaDDTree 框架中运行，使用原生 DFlash 起草器；Domino 是已发布的 Domino 解码器，在其自身基准测试中运行；DominoTree (16)（节点预算 16，候选宽度 M=64，GPU 原生构建器）是我们的框架——两者都在 Domino 起草器上运行。每个加速比都相对于各自框架内的 AR 进行归一化，但官方的 Domino 除外，它使用精简公共 AR 进行归一化（第 4.1 节）。粗体表示在每个单元中达到最高加速比的方法，以及达到最高 \( \tau \) 的方法；两者不一定一致。Qwen3-8B 在所有三个温度下在单个 RTX A6000 上评估；其加速比相对于每个框架的 T=0 AR 吞吐量（温度无关，误差在 1% 以内），因为 8B T>0 AR 未单独重新测量。  

DominoTree (16)，我们的标题配置（节点预算 16，候选宽度 M=64），在表 1 的总体列中，在每个温度下都达到了所有方法中最高的平均接受长度 \( \tau \)，并且在 24 个单独数据集 × 温度单元中的 21 个也是如此；例外是在每个温度下的 LiveCodeBench 以及在 T=1.0 时的 AIME25，其中 DDTree/CaDDTree 的边际树每轮接受更多 token。更大的预算会在增加构建成本的同时进一步提高 \( \tau \)（表 7，附录 A.2）。  

这种接受长度的领先使得 DominoTree 在两种模型上，在每个温度下都成为总体最快的方法。它对所基于的已发布 Domino 解码器的最大优势出现在聊天任务上——在 Alpaca 上最高 +22%（Qwen3-4B, T=0.5；表 1）——而且，与动态方法不同，其优势不会随着采样锐化而减弱：在 Qwen3-8B Alpaca 上，它从 T=0 时的 +12.3% 增长到 T=1.0 时的 +15.7%，因为条件树继续提出高接受度的延续，而单链路径则减弱。  

表 2（第 4 节，表 2）精确给出了基线的比较，报告了按汇总和温度分组的配对自助法吞吐量 Δ%（95% CI）；我们只陈述标题，并将每个单元留给表格。在总体 8 数据集汇总上，DominoTree 在其所基于的已发布 Domino 在每个温度下、两种模型上都表现更好——CI 清洁，在 Qwen3-4B 上为 +9 到 +10%，在 Qwen3-8B 上为 +4 到 +6%。这是一个**汇总**优势：在 Qwen3-8B 上，Domino 的 CUDA 图运行器在原始加速比上仍然在每个温度的一个数据集上略胜 DominoTree（上表 1），而汇总在每种温度下都偏爱 DominoTree。相对于 DDTree/CaDDTree，总体优势在 4B 上每个温度都是 CI 清洁的，在 8B 上 T=0 时最大（+24%），随着温度升高缩小为持平然后轻微损失，其中 Code 是唯一落后的汇总项。特别是，8B 的吞吐量领先仅因为 GPU 原生构建器（第 4.3 节）而存在，并且 4B/8B 的绝对数值在两个 GPU 上不可比（第 6 节）。  

表 2: DominoTree (16) 相对于每个基线的配对自助法吞吐量 Δ%，附带 95% CI，按模型、汇总类别和温度分组。*相对于 Domino* 比较相同提示上的原始每提示 TPS；因为 DominoTree 和官方 Domino 共享精简公共 AR（第 4.1 节），这个原始 TPS 比率等于它们的加速比比率；*相对于 DDTree (16)* 和 *相对于 CaDDTree* 比较跨框架的相对于自身 AR 的加速比（第 4.1 节），因为原始 TPS 在框架间不可比。粗体表示 CI 清洁的改进（Δ>0 且 95% CI 排除零）；损失和持平表示为普通字体。  

| 类别 | 相对于 Domino | | 相对于 DDTree (16) | | 相对于 CaDDTree | |
|------|--------------:|-------------:|-------------------:|--------------:|-------------------:|--------------:|
|      | Δ%            | 95% CI       | Δ%                 | 95% CI        | Δ%                 | 95% CI        |
| **Qwen3-4B** | | | | | | |
| **Temperature = 0** | | | | | | |
| Math | 5.40 | **[3.87, 7.08]** | 13.62 | **[9.59, 17.75]** | 12.28 | **[7.38, 17.18]** |
| Code | 9.51 | **[7.31, 11.88]** | -1.30 | [-3.72, 1.27] | -1.22 | [-3.67, 1.32] |
| Chat | 14.85 | **[11.88, 18.27]** | 13.36 | **[9.90, 17.07]** | 13.45 | **[10.03, 17.10]** |
| Overall | 9.21 | **[7.95, 10.57]** | 7.67 | **[5.63, 9.80]** | 7.26 | **[4.93, 9.58]** |
| **Temperature = 0.5** | | | | | | |
| Math | 5.48 | **[2.93, 8.13]** | 11.96 | **[8.36, 15.71]** | 10.53 | **[6.77, 14.47]** |
| Code | 9.99 | **[7.21, 12.79]** | -3.76 | **[-6.46, -1.08]** | -2.51 | [-5.39, 0.41] |
| Chat | 16.64 | **[13.12, 20.37]** | 10.06 | **[6.30, 14.17]** | 9.83 | **[5.66, 14.21]** |
| Overall | 9.89 | **[8.21, 11.61]** | 5.18 | **[3.07, 7.29]** | 5.19 | **[3.08, 7.45]** |
| **Temperature = 1** | | | | | | |
| Math | 6.84 | **[3.46, 10.36]** | 7.62 | **[3.78, 11.55]** | 7.71 | **[3.81, 11.67]** |
| Code | 10.86 | **[7.79, 14.04]** | -4.74 | **[-7.