详细内容或原文请订阅后点击阅览
CPU上的推测解码：DFlash实现近4倍令牌生成加速
推测性解码可以将未充分利用的 CPU 计算转化为更快的令牌生成，而无需更改模型的输出。在我们的 vLLM 测试中，DFlash 在并发数为 1 时在 Intel Xeon 6 上使用 Qwen3.5-9B 实现了 3.92 倍的自回归吞吐量。我们详细分析了加速的来源，解释了接受指标，并展示了决定推测是否有效的因素。CPU 上的推测解码：使用 DFlash 使令牌生成速度加快近 4 倍首先出现在《走向数据科学》上。
来源:走向数据科学解决了语言模型推理中缓慢的、顺序的token生成的根本挑战。DFlash推测解码支持最近在vLLM v0.25.0中为CPU启用。在我们使用Qwen3.5-9B在r8i AWS实例上进行的测试中，搭载带性能核的英特尔至强6处理器，DFlash在并发度为1时将平均token生成吞吐量提高到自回归基线的3.92倍——每个生成token的成本降低74%。
本文解释了什么是推测解码，以及DFlash如何特别允许您加速在CPU上的AI工作负载。如果您想跟随并复现结果，我们的配置详述在本文末尾。
什么是推测解码？
典型的自回归解码器生成一个token，将其附加到上下文中，并再次运行以预测下一个token。没有任何kernel优化可以在尚未解决的依赖关系上进行并行化，因此500个token的响应需要大约500个依赖周期。每个token生成步骤都需要将整个模型的参数从内存传输到处理器的计算单元。这使得操作受内存限制，并在低并发度下使那些计算单元大部分处于空闲状态。推测解码在不改变模型输出分布的情况下解决了这种串行依赖。轻量级草稿模型提出几个未来token。较大的目标模型在单次传递中检查所有token，接受最长的有效前缀，并纠正第一个错误，并且——如果每个token都被接受——生成一个奖励token。当草稿建议质量高且速度快时，每次昂贵的目标传递提交多个token而不是一个。与量化等有损优化技术不同，推测解码是一种无损加速，因为拒绝采样恢复了目标分布。
这项技术对至强上的推理尤其相关。在小批量大小下，解码通常花费大部分时间将模型权重从内存移入，而每个权重的工作量很少。验证将依赖英特尔AVX-512的每个token矩阵-向量运算转变为英特尔AMX加速的矩阵-矩阵运算：目标权重一旦加载，就会在多个候选位置上重复使用。问题在于推测增加了一个草稿器并扩大了验证。只有当接受的工作超过该开销时，它才值得：我们是用备用计算来换取节省的内存带宽；当没有备用计算时，这种交换就变成了损失。
DFlash：用于起草的块扩散加上目标KV注入
DFlash是Z Lab开发的一种新颖的推测解码方法。与一些旧算法中串行生成草稿token不同，DFlash推测器使用小型块扩散草稿器在单次传递中预测一个块。它还将目标模型的隐藏特征注入草稿模型的KV缓存中，这提高了草稿质量，而无需草稿器自行重建完整上下文。
接受率取决于您的模型，与对话相比，对于代码或数学等更结构化的提示，接受率通常更高。如果目标模型是领域特定的，接受率在不相关的提示上会下降。当在对话数据集上对编码器模型进行基准测试时，您不应期望看到太多性能改进。
草稿器在单次前向传播中预测所有掩码位置，块内具有双向注意力。掩码位置的数量——在下面的命令中——是一个服务器参数，其最优值取决于几个因素，包括目标模型和草稿模型、基准数据集、最大并发度以及您的硬件。
让我们看看如何使用vLLM通过额外的配置标志使用DFlash提升模型性能：
docker run --rm \
--name vllm-cpu-server \
--network host --ipc host --security-opt seccomp=unconfined --cap-add SYS_NICE \
-e VLLM_TARGET_DEVICE=cpu \
-e VLLM_CPU_KVCACHE_SPACE=40 \
-v ~/.cache/huggingface:/root/.cache/huggingface \
vllm/vllm-openai-cpu:latest \
Qwen/Qwen3.5-9B \
--dtype bfloat16 \
--trust-remote-code \
--speculative-config '{"method": "dflash", "model": "z-lab/Qwen3.5-9B-DFlash", "num_speculative_tokens": 15}'
效果在流式响应中很容易看到。使用相同的提示和确定性解码设置，DFlash在产生相同输出的同时显著更快地完成响应。
一些最近的模型如Muse Glimmer附带草稿模型。如果您的用例不是这种情况，请从Z Lab的DFlash集合开始，探索流行模型的草稿器。其他选项请参见Red Hat AI的模型集合，其中包括使用Speculator库训练的模型。以下是与自回归基线相比，Qwen3.5-9B在并发度为1和输出长度128时的加速结果。token生成成本降低是在相同实例上的固定并发度下测量的，因此不依赖于小时费率。平均值取自编程、数学和多轮对话问题的三个数据集。
理解推测解码指标
vLLM报告了几个统计数据，描述了目标模型接受DFlash建议的有效性。考虑表1中的HumanEval运行，设置为15：
接受率（%）：39.56 接受长度： 6.93 草稿数： 381 草稿token： 5715 接受token： 2261
是由目标模型验证的推测块数：381个验证步骤承载了本次运行的2560个输出token，而自回归基线需要大约2560次顺序传递才能生成。因为381个块中的每个包含15个建议，所以有15 x 381 = 5715个草稿token。在这些建议中，目标接受了2261个，产生报告的接受率2261/5715 = 39.56%。最后，每轮产生平均2261/381 = 5.93个接受的草稿token。验证还发出一个目标token，要么作为纠正，要么在块被完全接受时作为奖励token。因此产生的接受长度为5.93 + 1 = 6.93。
需要谨慎说明。对于DFlash使用的固定长度起草，总体接受率是下面每个位置值的平均值，因此当块变长时它通常会下降，即使吞吐量提高。使用接受长度而非接受率来比较每轮验证的进展，但从测量的吞吐量或延迟中选择块大小。此外，推测解码计数器可以包括在最终块中接受但在请求达到其输出长度限制时被丢弃的token，因此这些计数器隐含的token数量可能超过返回给客户端的数量。
每个位置的统计数据显示了建议通常在块中存活多远：
位置0： 85.83% … 位置4： 51.44% … 位置14： 11.81%
这些是存活概率。位置n被接受意味着目标接受了通过位置n的完整推测前缀，因此该列按构造递减，并求和为每轮接受的草稿token数。将连续值相除得到每个位置的条件下接受率。条件接受率的崩溃表明后续建议越来越不可能存活。
平均接受长度6.93 = 5.93 + 1并不意味着块应该缩短为六个token，因为分布是偏斜的：14%的块的所有建议都被拒绝，12%被完全接受。这样做将消除目标可以接受更长前缀的所有轮次。此外，我们不能无限增加块大小，因为被拒绝的尾部位置仍然消耗起草和验证资源。最优块大小在有用进展和总轮次成本之间取得平衡：
分子中的两个项通常随块大小增长，而分母随着每个位置存活概率通常趋近于零而饱和，因此可达到的增益是有界的。
接受统计数据有助于解释性能，但它们本身并不能确定最优值。为了调优，在预期的模型、数据集、硬件和并发度上对几个块大小进行基准测试，然后选择产生最佳吞吐量或延迟的值。
关键要点
收益在智能体工作负载中复合，其中模型在多步骤循环中被重复调用，每一步解码都很重要——这就是推测解码支撑英特尔开源智能体栈的原因。
并行起草的工作正在迅速推进，超越DFlash。DSpark增加了半自回归纠正阶段和可变长度验证，而DFlash 2使用轻量级路径选择器来跟踪通过每个位置顶级候选的连贯路径，并使用局部卷积来减少每个块末尾附近草稿精度的衰减。请关注更新的推测解码方法，因为支持将到达CPU推理框架。
致谢
作者感谢Alex Sin、Eric Petit、Eze Lanza和Pradeep Surabhi对本文的审阅和反馈。
参考文献
通知和免责声明
性能因使用、配置和其他因素而异。在www.Intel.com/PerformanceIndex了解更多信息。
性能结果基于配置中所示日期的测试，可能不反映所有公开可用的更新。有关配置详情请参见备查文件。没有任何产品或组件是绝对安全的。
您的成本和结果可能有所不同。
英特尔技术可能需要启用硬件、软件或服务激活。
©英特尔公司。英特尔、英特尔徽标和其他英特尔标志是英特尔公司或其子公司的商标。其他名称和品牌可能被声明为他人的财产。
配置：1节点，Amazon EC2 r8i.16xlarge，1x Intel(R) Xeon(R) 6975P-C，32核，未知TDP，HT开启，Turbo开启，总内存512GB（1x512GB DDR5 7200MT/s [未知]），BIOS 1.0，微码0x1000434，1x弹性网络适配器，1x 400G Amazon弹性块存储，Ubuntu 24.04.4 LTS，7.0.0-1009-aws，vLLM 0.26.1rc1.dev124+gb88916617。英特尔于2026年7月测试。