大模型推理的军备竞赛，正在从“买更多卡”转向“让每一张卡少干点冤枉活”。
vLLM团队最近放出一份在AMD Instinct™ MI300X / MI355X上的实测报告，主题只有一个：speculative decoding（推测性解码）。他们没有换更贵的硬件，也没有改模型结构，而是让模型在生成文本时先“打草稿”，再由主模型一次性验证。结果最猛的组合跑出了2.87倍的吞吐提升。
但这份报告最有趣的地方不是最高数字，而是它毫不客气地告诉你：没有一种方法能通吃所有模型和所有任务。
瓶颈不是算力，是“一个字一个字往外蹦”
现在绝大多数LLM服务系统用的都是最基础的自回归解码：模型生成一个token，把它拼回输入，再生成下一个token。
简单、稳、可预测。
但问题也在这里——每输出一个token，就要完整地跑一轮目标模型。长文本生成时，这个“一字一顿”的循环会把延迟和吞吐都拖垮。
vLLM博客里的原话很直接：
“Can we preserve the output behavior of the original model while reducing how often generation advances by only one token at a time?”
换句话说：能不能在结果不变的前提下，一次多走几步？
推测性解码就是冲着这个问题去的。
“草稿+验证”：一次猜七个，错了就撤回
它的核心思路分两步：
- Draft（打草稿）：用一个轻量级的“草稿组件”先猜一串未来token。
- Verify（验证）：目标模型把这一串候选token放到一起，一次性验证。
验证从左到右进行，只要遇到第一个通不过的token，后面整段草稿就作废，由目标模型在那个位置给出“正确答案”，然后下一轮重新来。
博客里举了个例子：当前句子是 “The weather is”，草稿模型猜了 “sunny and warm outside”。验证时，前两个词 “sunny and” 通过了，第三个词 “warm” 被主模型改成 “clear”，那么最后的 “outside” 直接丢弃。
** accepted就前进，rejected就重来。**
听起来像是“先开枪再画靶”，但只要验证环节严格把关，最终输出和目标模型原本会生成的输出是一致的。
五种“猜题流派”，谁更懂模型心思？
vLLM这次对比了五种草稿方案，本质区别在于两点：草稿模型从目标模型那里拿到什么信息，以及候选token是串行生成还是并行生成。
Native MTP
这是模型原生的多token预测模块，直接内嵌在目标模型架构里。它用目标模型的隐藏表示作为上下文，再逐个生成候选token。好处是不需要额外加载草稿权重，内存开销小；缺点是它跟目标模型架构强绑定。
Gemma 4 MTP
Gemma 4用的是独立的MTP草稿checkpoint，但推理时仍共享目标模型的KV cache。可以理解为“外挂式MTP”，既保留了原生MTP的紧密耦合，又允许单独发布和维护草稿组件。
EAGLE-3
EAGLE-3是一个专门为目标模型训练的小草稿网络。它从目标Transformer的三个阶段抽取隐藏状态，拼接、投影成一个融合特征，再和采样token的embedding一起进入草稿解码器。它的候选token是自回归生成的，后一个token依赖前一个token。
DFlash
DFlash不走自回归路线，而是一次性并行预测整个token块。它用一个已知的anchor token作为起点，在一个前向传播里把后面所有masked位置一起算出来。因为不是逐token生成，所以长草稿块后期的质量更依赖训练数据和任务本身。
DSpark
DSpark在DFlash的并行 backbone 上加了两样东西：一个是轻量的Markov sequential head，让同一块内的草稿token之间产生依赖，缓解“of problem”这种前后不一致；另一个是confidence-based prefix selection，可以根据置信度选择更短的草稿前缀提交验证。不过报告里特别说明，在vLLM测试路径中，confidence selection功能尚未启用。
五种方法，一个比一个更像在“揣摩主模型的心思”。
AMD实测：有人翻了2.87倍，也有人跑了个寂寞
实验在AMD Instinct™ MI300X和MI355X GPU、ROCm™平台上进行，覆盖了Gemma、Qwen、MiniMax、Kimi等模型家族。
结果不是一张简单的“加速榜”，而是一堆有条件的胜利。
- google/gemma-4-26B-A4B-it：Gemma 4 MTP在GSM8K和MBPP上分别达到2.74×和2.62×；DFlash在MATH500和HumanEval上达到2.87×和2.79×；EAGLE-3则在2.11×到2.27×之间。
- google/gemma-4-31B-it：Gemma 4 MTP约2.00×，DFlash在MATH500上冲到2.34×。
- Qwen3-8B：DSpark在GSM8K上1.63×，MATH500上只有1.15×；EAGLE-3在MATH500上甚至低于基线。
- Qwen3.5 / 3.6 系列：原生MTP反而比DFlash更猛，Qwen3.5-122B-A10B在MATH500上达到2.20×。
- Kimi-K2.5：DFlash最高2.68×，EAGLE-3最高2.33×。
- MiniMax-M3-MXFP8：EAGLE-3在HumanEval上达到2.09×。
最有意思的是，同一个方法在同一模型家族的不同型号上表现都可能不同。比如Qwen3.6-27B和Qwen3.6-35B-A3B，最佳策略和最佳proposal长度都不一样。
所以这份报告真正想说的不是“DFlash最强”或者“MTP无敌”，而是：脱离具体模型、任务和参数配置谈加速，都是耍流氓。
调参比选方法还重要
vLLM把推测性解码定位为运行时优化，而不是一个“开了就完事”的开关。
关键参数是 num_speculative_tokens，也就是一次草稿要猜多少个token。
- 对Native MTP，建议从N=1开始，稳定后逐步扫到2、3、4……7。
- 对Gemma 4 MTP和EAGLE-3，N增加会引入更多串行草稿开销，通常先升后平。
- 对DFlash，很多checkpoint按固定block size训练，比如block size 16时最大N=15，但实测N=7往往已经很高，部分任务N=11更好。
- 对DSpark，vLLM实验里完整提交配置长度，N=3和N=7需要端到端对比。
比调N更重要的是看acceptance行为：每个位置被接受的比例、平均接受长度、整体吞吐。如果前几个位置接受率很高，后面几乎不接受，那说明N开大了，直接调小反而更快。
报告里反复强调：高接受率不等于高吞吐，因为草稿本身也要消耗算力；低接受率也不一定差，如果草稿生成极快，整体仍可能划算。
下一步：还没卷完
vLLM团队在文末列了几条未来方向：
- 引入n-gram speculation、suffix decoding等非学习式方法，尤其适合代码编辑、agent循环等重复模式多的场景；
- 在不同并发、prompt长度、batch size、采样参数下做更全面的benchmark；
- 研究训练数据对speculator接受率的影响，比如数学、代码、聊天、多语言、工具调用等；
- 更深入地 profiling 草稿生成、目标验证、KV cache、图执行和调度。
这些方向指向同一个判断：推测性解码的优化空间还远没到头。
写在最后
AMD GPU + ROCm + vLLM的组合，正在用实测数据证明一件事：大模型推理的加速，不一定需要更贵的卡，而需要更聪明的调度。
但这份报告也泼了一盆冷水——没有银弹。同样的方法，换一款模型、换一个任务、换一个N，结果可能天差地别。
所以真正的问题不是“要不要上speculative decoding”，而是：你愿不愿意为自己的模型和任务，老老实实做一轮端到端的调参？
【锐评】：堆卡只能解决“有没有”，会调参才能决定“快多少”。
参考链接：
https://vllm.ai/blog/2026-08-23-speculative-decoding-amd-gpus