本記事はAIを利用して作成した技術解説・実装例です。掲載するコードや手順は一次情報を基に構成していますが、筆者による実機での動作確認は行っていません。環境やバージョンによって動作が異なる場合があります。
在大语言模型（LLM）的推理处理中，加速自回归解码阶段是一个关键课题。NVIDIA Technical Blog 上发布的一手资讯介绍了“推测解码（Speculative Decoding）”协同设计（Co-Design）的 5 个指南，以及各种草稿机制的比较，作为在保持模型准确性的同时加速推理的方法。本文将根据一手资讯整理其组成要素和选定标准。
スペキュラティブデコードの基本構造
推测解码是一种通过小型草稿模型预测多个 Token、并由规模更大的目标模型对它们进行并行验证，从而在保持输出准确性的同时减少解码迭代次数的方法。
flowchart TD
A["小型草稿模型"] -->|预测 D 个 Token| B["大规模目标模型"]
B -->|实施并行验证| C["采用 Token 直到首次不匹配"]
C -->|进入下一个预测循环| A
根据一手资讯，该过程的主要概念定义如下：
草稿长度（$D$）：目标模型每次迭代时建议的 Token 数量。
接受长度（$AL$）：目标模型每次迭代时实际生成（批准）的 Token 数量。由于目标模型除了被批准的草稿 Token 外，始终可以生成 1 个真实的 Token，因此 $AL$ 的范围是从 $1$ 到 $(1 + D)$。
基于 5 个指南选择草稿长度
为了在整个帕累托前沿（Pareto frontier）选择最佳的草稿长度和机制，一手资讯给出了 5 个指南。
1. 转移至 GEMM 的计算受限区域
为了提高计算负载，建议在不引起 KV 缓存容量挤压的情况下，增加推测解码的草稿长度，将 GEMM 推向计算受限（compute-bound）区域。
2. 注意力处理占据主导时的草稿长度
当注意力机制在推理或智能体工作负载中占据执行时间的主导地位时，若将查询头数除以 KV 头数设为 $G$，则解码注意力的算术强度约为 $2 times G$。通过推测解码，该强度增加到 $2 times G times (1 + D)$。在现有的 GPU 设备上，由于注意力内核在 GEMM-$M = 128$ 时可实现良好的硬件利用率，因此最佳草稿长度为 $D = frac{128}{G} – 1$。
3. 考虑瓦片（Tile）边界
注意力的运行时间也取决于瓦片大小。当 $G times (1 + D)$ 跨越基准测试注意力内核的软件瓦片大小（128）的倍数时，运行时间会逐步增加。当选择 $D > frac{128}{G} – 1$ 时，建议选择能使 $G times (1 + D)$ 成为 128 的倍数的值，以防止瓦片未被充分利用。
4. 低延迟区域中的草稿长度
在延迟极低的区域，仅当接受率提升带来的收益能够正当化额外的草稿成本时，才建议增加 $D$。草稿的开销表示为 $rho D$（其中 $rho$ 是草稿模型层数与目标模型层数的比率）。
草稿机制的比较与权衡
生成草稿 Token 的方法有多种选择，例如外部小型 LLM、辅助层或字符串匹配。在一手资讯的表格中，对以下机制进行了比较：
外部草稿模型：使用小型独立 LLM 的方式。在 LPU 或 GPU 环境中得到应用。
EAGLE-3 / MTP：结合解码器层和线性投影，利用目标模型隐藏状态等的方式。
DFlash / DSpark：利用融合了目标隐藏状态的 KV，在并行步骤中生成多个 Token 的方式。分别在大模型和小模型中进行探讨。
后缀 / n-gram：不使用模型，通过字符串匹配重用 Token 流中模式的方式。适用于重复较多的工作负载。
用于工作负载测量的生态系统
在一手资讯中，列举了以下工具用于实际工作负载的性能测量和优化：
SPEED-Bench：由 NVIDIA 开发的推测解码基准测试。涵盖编程和摘要等任务领域，推荐用于测量真实提示词下的接受长度。
NVIDIA TensorRT LLM：展示了利用高性能推理框架来量化草稿开销的方法。
NVIDIA/Model-Optimizer：提供了 EAGLE-3、DFlash、DSpark 等训练示例，以及在 Nemotron 3.5 Lightning 等中得到验证的微调与量化工作流。
参考信息
source_title: Co-Designing AI Models Using Speculative Decoding for Faster LLM Inference
source_url: https://developer.nvidia.com/blog/co-designing-ai-models-using-speculative-decoding-for-faster-llm-inference/
コメント