💬 NLP

D-cut: Adaptive Verification Depth Pruning for Batched Speculative Decoding

D-Cut 是一种用于批量投机解码的自适应验证深度剪枝方法，它根据草稿置信度和运行时成本模型，在并发请求之间动态分配验证预算，从而在显著提高高并发下推理加速比的同时，防止在被拒绝的标记上浪费计算资源。

原作者： Tianyu Liu, Yuhao Shen, Rui Cen, Junhan Shi, Jiebin Zhang, Guangshuo Qin, Hong Liu, Song Liu, Guanghua Yu, Jianchen Zhu

发布于 2026-07-17

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Tianyu Liu, Yuhao Shen, Rui Cen, Junhan Shi, Jiebin Zhang, Guangshuo Qin, Hong Liu, Song Liu, Guanghua Yu, Jianchen Zhu

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你正在经营着一家规模宏大、高速运转的图书馆，一位极其聪明的图书管理员（AI）同时为成千上万的人回答问题。这位管理员非常博学，但他们的工作方式非常特殊：他们一次只能写下一个词。为了回答一个复杂的问题，他们必须停顿、思考、写下一个词、再次停顿、思考、写下下一个词，以此类推。这种“一次一个词”的规则是导致图书馆积压的主要原因：管理员大部分时间都花在等待从书架上抓取下一个词上。

为了提高速度，工程师们发明了一个巧妙的技巧，叫做“投机采样解码”（speculative decoding）。与其让图书管理员一次写一个词，不如雇佣一名速度较快但聪明程度稍逊的助手（“草拟者”，drafter）来一口气猜出接下来的几个词。然后，图书管理员会快速检查这些猜测。如果猜测正确，管理员就会一次性接受所有词，从而跳过那个缓慢的“思考-停顿-书写”循环。这就像助手大声喊道：“我敢打赌接下来的三个词是‘The’、‘quick’和‘brown’！”而图书管理员说：“没错，你猜对了！”然后继续工作。当图书馆很安静时，这个方法效果极佳。但如果图书馆里挤满了 64 个人同时在大声提问，会发生什么呢？助手可能会为每个人大声喊出一长串猜测，但图书管理员在试图检查所有这些猜测时会感到应接不暇。如果猜测错误，图书管理员就会浪费宝贵的时间去检查那些最终被丢弃的词，从而拖慢整个图书馆的速度。这就是这篇论文要解决的难题：如何在人群变得庞大时，依然保持速度优势。

问题所在：猜测太多，时间不够

腾讯混元（Tencent Hunyuan）的研究人员注意到系统中出现了一个故障。最近，新的助手（例如一个名为 DFlash 的模型）变得非常擅长喊出长长的猜测列表——比如一次猜 15 个词。当图书馆空闲时，这是一种超能力；管理员接受了其中的大部分，图书馆处理问题的速度飞快。

但随着人群增加（即“批处理大小”或同时请求的数量增加），系统开始崩溃。助手不断喊出长长的列表，但此时已经精疲力竭的图书管理员无法足够快地检查它们。更糟的是，许多长列表都是错误的。图书管理员耗尽了所有的精力去检查那些最后证明是垃圾的词，结果却不得不把它们丢弃。这就像一名在拥挤的音乐会现场工作的保安，正在检查队列中 15 个人的身份证，结果发现其中 10 个是假的，白白浪费了本可以用来让真正的粉丝进场的时间。研究人员发现，在高负载情况下，这种“长列表猜测”的方法实际上比让图书管理员独自一个词一个词地工作还要慢。

解决方案：D-cut（聪明的门卫）

为了解决这个问题，团队提出了一个名为 D-cut 的新策略。把 D-cut 想象成站在助手和图书管理员之间的一名超级聪明的门卫。

D-cut 不再让助手为所有人喊出一个固定的长列表并让图书管理员检查所有内容，而是实时观察人群和猜测情况。它会询问两个简单的问题：

助手的信心如何？ 如果助手是在高信心地喊话，门卫就让这些猜测通过。如果助手在含糊其辞或不确定，门卫就会缩短列表。
图书管理员有多累？ 门卫会检查图书管理员当前的负载。如果图书管理员忙得不可开交（比如在繁忙的 GPU 芯片上），门卫就会变得更加严格并削减更多猜测。如果图书管理员精力充沛且功能强大（比如在另一块更快的芯片上），门卫就会让更多的猜测通过。

D-cut 不仅仅是为一个人削减列表，它还会观察整个请求批次。它意识到，对于某些人来说，助手是个天才；而对于另一些人来说，助手是在胡乱猜测。因此，D-cut 会获取“验证预算”（即图书管理员用来检查的时间），并将其分配给那些最有可能是正确的人。它通过剪枝（切掉）那些低置信度、长尾部分的猜测，将图书管理员的精力集中在高置信度的部分。

它在现实中是如何运作的

研究人员在各种 AI 模型（从小型到大型）以及不同类型的计算机芯片上测试了这个想法。他们发现 D-cut 在繁忙时期是一个游戏规则的改变者：

在高负载下拯救局面： 当请求数量很高时（例如同时有 64 个人），旧方法（DFlash）往往会变得非常缓慢，甚至比标准的“一次一个词”方法还要慢。D-cut 解决了这个问题。即使在图书馆人满为患时，它也能保持加速效果。
数据表现： 在测试中，相比于标准方法，D-cut 在高负载下的平均速度从 1.26 倍提升到了 1.65 倍。在某些特定的超大型模型上，它甚至达到了 3.0 倍的速度。
适应硬件： D-cut 最酷的特性之一是，它能在人群到来之前了解图书管理员的速度。它会对计算机芯片（如 H20 或 H800 GPU）进行剖析，查看检查一个词的成本有多高。如果检查一个词的成本很高（比如在较慢的芯片上），D-cut 就会更激进地进行削减。如果成本很低，它就会减少削减。这意味着它不需要人类为每台新电脑进行手动调优，它能自动完成。

它不做什么（以及它排除了什么）

了解 D-cut 不是什么也很重要。它并不试图让助手变得更聪明，也不改变图书管理员的思考方式。它不会改变 AI 给出的最终答案；输出结果与图书管理员检查所有内容后的结果完全一致，只是到达的速度更快。

论文明确反对“越长越好”的观点。他们证明了在人群庞大时，盲目生成长列表（如 DFlash 中的 15 词块）是一个坏主意。“一刀切”地为每个人检查相同数量的猜测是行不通的，因为并非每个人都需要相同程度的检查。D-cut 证明了，选择性的检查比穷举式的检查更有效。

核心结论

研究人员不仅提出了这个想法，还进行了实测。他们在拥有数千个请求的实际服务器上运行了模拟和真实测试。结果表明，通过作为一个聪明的、自适应的门卫，剪掉低置信度的猜测并专注于高置信度的猜测，D-cut 即使在门槛被挤爆时，也能让 AI 图书馆保持高效运行。它将一个原本会陷入缓慢停滞的系统转变为一个保持高效的系统，这证明了：有时，想要跑得快，最好的办法就是停止检查那些你明知是错误的东西。

技术摘要：D-cut：面向批量投机解码的自适应验证深度剪枝

1. 问题陈述

投机解码已成为一种领先的无损加速大语言模型（LLM）推理的方法，它将草稿生成（draft generation）与验证（verification）解耦。最近的进展（例如 DFlash 等块并行草稿生成器）能够通过单次前向传播生成整个块的草稿 Token，从而使草稿长度与草稿延迟解耦，并在低并发设置下实现较高的平均接受 Token 数（MAT）。

然而，本文指出在高并发批量服务（high-concurrency batched serving）中存在一个关键瓶颈：

验证成本爆炸：随着批处理大小（ $B$ ）的增加，目标模型每步必须验证 $B \times (D+1)$ 个 Token（其中 $D$ 是草稿长度）。这使得验证过程从内存受限（memory-bound）转向了计算受限（compute-bound）。
资源分配效率低下：在高并发场景下，长且固定的深度草稿往往会导致较高的拒绝率。例如，当草稿长度为 15 时，平均接受长度可能仅为 ~6 个 Token，这意味着大约 60% 的被验证 Token 被拒绝了。
吞吐量不佳：验证这些被拒绝 Token 的计算成本增加了单步耗时，导致投机解码的吞吐量在高批处理大小（例如 $bs=64$）下趋于饱和甚至低于标准的自回归（AR）解码。
静态与动态需求的差异：现有方法通常在整个批次的所有请求中应用统一的验证深度。这未能考虑到并发请求之间接受长度的显著差异，也未能考虑到不同硬件环境（例如计算受限的 H20 与计算丰富的 H800 GPU）下验证计算成本的变化。

2. 方法论：D-cut

作者提出了 D-cut，这是一种自适应剪枝策略，它将验证预算视为整个批次的共享资源，并将其动态分配给最有可能被接受的 Token。该方法无需修改目标模型，也不需要额外的训练。

核心机制

跨请求剪枝（基于置信度引导）：
- D-cut 不再为每个请求验证固定的深度，而是使用草稿模型的预测置信度对批次中的每个候选 Token 位置进行评分。
- 它为每个位置计算一个“前缀积”得分（ $s_{i,k}$ ），代表该块能存活到深度 $k$ 的概率。
- 所有候选位置在整个批次中根据这些得分进行全局排序。低置信度的后缀会被剪枝，而高置信度的前缀会被保留。这确保了验证预算从低收益请求转移到高收益请求。
运行时自适应深度选择：
- 意识到验证额外 Token 的成本高度依赖于运行时环境（GPU 类型、模型架构、并行策略和批处理大小），D-cut 引入了一个剖析成本模型（profiled cost model）。
- 剖析（Profiling）：在服务器启动时，D-cut 对不同离散验证预算比例（ $\rho \in \{0.25, 0.50, 0.75, 1.00\}$ ）和批处理大小下的端到端投机步骤延迟进行剖析。
- 优化：在服务期间，D-cut 动态选择最优的全局预算比例 ( $\rho^*$ )，以最大化预期加速比。加速比的公式是预期收益（基于置信度估计的 MAT）与硬件剖析运行成本的比值。
- 这使得 D-cut 能够在计算受限的硬件（如 H20）或草稿质量较低时进行激进的剪枝，同时在计算丰富的硬件（如 H800）上保留更多 Token，因为在这些硬件上验证成本较低。

流水线概览

草稿生成（Drafting）：草稿模型生成一组带有置信度得分的 Token 块。
评分与排序（Scoring & Ranking）：选择器展平所有位置，计算前缀积得分，并在全局范围内进行排序。
预算选择（Budget Selection）：选择器参考预先剖析的成本表，选择能使效用/成本比最大化的最优预算比例 $\rho^*$ 。
打包（Packing）：将得分最高的 $K$ 个位置打包成一个稠密的验证批次。至关重要的是，由于得分是前缀积，每个请求保留的位置形成一个连续的前缀，从而确保了与现有推理引擎及 CUDA 图（CUDA graphs）的兼容性。
验证（Verification）：目标模型验证打包后的批次。

3. 核心贡献

识别瓶颈：本文通过实验证明，在高并发批量服务中，长固定深度草稿（如 DFlash）会导致吞吐量低于标准 AR 解码，因为验证被拒绝 Token 的成本过高。
D-cut 算法：提出了一种无需训练的无损剪枝策略，通过草稿置信度和运行时自适应深度选择进行跨请求的验证深度剪枝。
运行时成本建模：引入了剖析成本模型，使剪枝策略能够适应特定的部署环境（硬件、批处理大小、模型架构），而非依赖静态启发式方法。
系统集成：该方法通过将验证预算限制在离散比例内，旨在与现有推理引擎（如 vLLM）协同工作，以兼容分段式 CUDA 图捕获并避免形状爆炸问题。

4. 实验结果

作者在六个目标模型（涵盖 Dense 和 MoE 架构）以及五个基准测试（数学、代码、对话）上，使用 NVIDIA H20 和 H800 GPU 对 D-cut 进行了评估。

吞吐量提升：在高并发（批处理大小为 32）下，D-cut 将相对于 DFlash 基线的平均相对于自回归解码的加速比从 1.26× 提升至 1.65×。
恢复加速能力：对于那些在使用长草稿时 DFlash 在高并发下性能会跌破 AR 解码的 Dense 模型，D-cut 恢复了正向加速。
MoE 性能：在混合专家（MoE）模型上，D-cut 实现了相对于自回归解码高达 3.0× 的加速。
硬件适应性：
- 在计算受限的 H20 上，D-cut 进行激进剪枝（通常选择 25% 的预算），显著优于固定比例的基线。
- 在计算丰富的 H800 上，D-cut 自动调整以保留更多 Token（通常为 50% 或更高），在不产生不必要剪枝的情况下最大化吞吐量。
鲁棒性：即使在目标模型采用随机采样（Temperature = 1）的情况下，D-cut 仍能保持优势，而标准的长草稿方法在这种情况下会完全失效。

5. 重要性与主张

本文声称 D-cut 解决了当前投机解码系统中一个根本性的错配：即假设“更长的草稿总是更好”的假设。作者认为，在批量服务中，验证计算才是稀缺资源，而不仅仅是生成草稿的能力。

范式转移：这项工作将关注点从最大化单个请求的接受长度，转向了管理批量验证效率。
实际影响：D-cut 使得在高性能、高并发的生产环境中能够使用强大的块并行草稿生成器，否则这些生成器在这些环境下反而会产生负面影响。
局限性：作者承认存在系统集成挑战：变化的验证批次形状需要仔细处理，以符合当前推理引擎（如 Spec-V2 和分段式 CUDA 图）的静态形状假设。他们指出，要实现动态验证的全部潜力，可能需要与服务框架进行更紧密的协同设计。

总之，D-cut 提供了一种机制，能够动态平衡“接受更多 Token 的算法收益”与“验证它们的硬件成本”之间的权衡，从而确保即使在重负载下，投机解码仍是一种可行的加速技术。