vLLM团队公布了一份技术分析，在AMD Instinct MI300X、MI355X GPU和ROCm软件栈上测试了投机解码（speculative decoding）。测试覆盖五种草稿方案：原生MTP、Gemma 4 MTP、EAGLE-3、DFlash和DSpark。
vLLM给出的结论比较克制：能不能提速，取决于草稿方法、候选长度和模型家族，比原理本身更重要。这跟NVIDIA生态里"投机解码=默认加速"的印象不太一样。同样的机制搬到AMD平台和不同草稿实现上，收益不能照搬，得重新测。
MI300X、MI355X先验证了什么：一次验证多个token，不是顺序推进
标准自回归解码，每次只能往前走一个token。模型看当前序列，吐出下一个token，拼回去，再算下一个。生成4个token要跑4次完整前向计算。
投机解码在前面加了一步。一个轻量草稿组件先猜出几个候选token，目标模型用一次验证通道从左到右检查。猜对的直接算数，一旦某个候选被否，它后面的候选全部作废，目标模型给出真实的下一个token，流程重新开始。
vLLM在MI300X、MI355X、ROCm上分别接入并跑了这套流程，验证的是同一件事：一次目标模型验证，能不能提交多个token，从而减少目标模型往前推进的轮次。
候选越长不代表越快：接受率才是真正的变量
五种方案都是"先猜后验"，但猜的方式差别不小。
| 方案 | 生成方式 | 是否需要独立checkpoint | 关键特点 |
|---|---|---|---|
| 原生MTP | 顺序生成 | 不需要，架构内置 | 候选越长，顺序步骤越多 |
| Gemma 4 MTP | 顺序生成 | 需要，共享目标模型KV缓存 | 独立训练但仍逐步吐token |
| EAGLE-3 | 顺序自回归 | 需要 | 融合目标模型三层隐藏状态起草 |
| DFlash | 并行预测整块 | 需要 | 唯一并行方案，从锚点token起步 |
| DSpark | 并行预测+因果校正 | 需要 | DFlash基础上加置信度前缀筛选 |
vLLM特别提到，这些分组只是描述草稿组件的架构差异，不代表一个目标模型只能配一种草稿方式。同一个目标模型完全可以同时支持原生MTP，又单独训练EAGLE-3或DFlash的草稿模型。
真正决定收益的是候选token的接受率。草稿猜得越准，一次验证能确认的token越多，目标模型要跑的轮次越少。但只要中间一个候选被拒，后面排好的候选全部扔掉，草稿阶段的计算就白费了。
接受率跟目标模型家族、草稿checkpoint、配置的候选长度、实际业务负载绑在一起。同一个方法换个模型或换个场景，表现可能完全不一样。候选序列拉长也不必然缩短延迟——草稿计算开销和拒绝率会同时上升，抵消掉一部分收益。
对AMD部署团队来说：先测什么，再决定开不开
在AMD Instinct GPU上跑vLLM服务长文本生成的团队，这篇分析真正有用的地方不是"AMD也支持投机解码了"。它提醒团队，把这当成一个要逐个压测的工程选项。
不同场景该看的东西不一样：
- 长输出、低并发场景（长文档生成、多轮agent推理）：接受率对总延迟的影响最直接，值得先测这类场景。
- 高并发批量场景.草稿计算本身占GPU算力，可能跟批量吞吐抢资源，得看具体batch size下的实际数字。
- 显存紧张的部署.Gemma 4 MTP、EAGLE-3、DFlash、DSpark都需要额外的独立checkpoint，要跟KV cache占用一起算，不是白捡的加速。
具体要测四项指标：输出token吞吐、端到端延迟、显存占用、候选接受率。都要在自己的模型、并发度和输出长度下重新跑一遍。五种草稿方法谁更合适，没有统一答案。
vLLM这篇文章本身也没给出完整的吞吐、延迟和接受率数字，只讲清楚了机制和五种草稿方式的差异。目前还看不清AMD平台上具体能拿到多大加速幅度，也无法判断某种草稿方法是否普遍优于另一种。这些结论要等实际压测数据补上。