实测基准显示，在部署 Qwen3 模型并结合 vLLM、Kubernetes 与 AWS AI Chips 时，inter-token latency 更快。
在 AWS Trainium 上，推测解码可将以解码为主的工作负载中的 token 生成速度最高提升至 3 倍，有助于降低每个输出 token 的成本，并在不牺牲输出质量的前提下提升吞吐量。如果你构建的是 AI 写作助手、编码代理或其他生成式 AI 应用，你的工作负载很可能输出的 token 远多于输入的 token，这会使解码阶段成为推理成本的主要来源。在自回归解码过程中，token 按顺序逐个生成，导致硬件加速器受限于内存带宽且利用率不足，从而推高每个生成 token 的成本。推测解码通过让一个较小的草稿模型一次提出多个 token，再由目标模型通过一次前向传递完成验证，以此解决这一瓶颈。串行解码步骤减少，意味着更低的延迟和更高的硬件利用率，从而有助于降低推理成本。
什么是推测解码？
推测解码通过使用两个模型来加速自回归生成：
如果想更深入了解其底层机制，包括 token 的接受与拒绝、基于 EAGLE 的推测方法，以及更一般的推测解码概念，可参考 AWS Inferentia2 上的博客文章、这篇 SageMaker EAGLE 演练以及这篇入门文章。本文重点讨论实际中可控的两个参数：草稿模型和 num_speculative_tokens。
草稿模型与目标模型必须共享相同的 tokenizer 和词表，因为推测解码基于 token ID，并由目标模型直接验证。我们建议选择同一架构家族中的模型，因为它们对下一个 token 的预测更容易一致。如果不同架构的模型共享 tokenizer，也可以进行配对，但草稿模型与目标模型之间较低的一致性会降低接受率，并抵消大部分性能收益。
当目标模型接受草稿 token 时，这些 token 就可以被直接提交，而无需承担完整的串行解码成本。你主要控制的参数是 num_speculative_tokens，它决定草稿模型一次提出多少个 token。当接受率较高时，增大这个值可以让你在每次验证时跳过更多串行解码步骤，从而直接降低 inter-token latency。
性能提升主要来自两个方面。第一，推测解码减少了目标模型的解码步骤数量，从而降低了 KV-cache 的内存往返次数。（KV cache 用于存储先前计算出的 key 和 value 张量，使模型不必为过去的 token 重新计算注意力。每个解码步骤都需要从内存中读取完整缓存，因此解码阶段受限于内存带宽。）第二，推测解码提升了解码期间的硬件利用率。在标准自回归解码中，每个解码步骤只生成一个新 token：加速器启动高成本的矩阵乘法内核，却只为一个 token 提供计算，导致处理单元引擎大部分时间未被充分利用。而在验证阶段，目标模型会一次处理 n 个 token，从而摊薄内存访问成本，并把一串小而低效的单 token 计算转变为计算更密集的工作负载。如果把 num_speculative_tokens 设得过低，速度收益会受限。
如果把它设得过高，则更容易在较早阶段被拒绝，既浪费草稿模型的计算，也会提高目标模型的验证成本。你需要根据观测到的接受率，在草稿计算成本与验证成本之间做平衡来调优这个值。
图 1：推测解码配置的权衡
为了说明这些权衡，我们比较了 Qwen3-0.6B 和 Qwen3-1.7B 两个草稿模型。更小的 0.6B 模型运行更快，但其接受率大约低了 60%，足以抵消计算节省带来的收益。Qwen3-1.7B 在速度和接受率之间取得了更好的平衡。
对于 num_speculative_tokens，我们评估了 5 到 15 的取值。较小的设置（例如 5）只能带来有限加速；较大的窗口（例如 15）则会增加拒绝率并降低性能。最佳配置高度依赖提示结构。我们测试了结构化提示（如重复、数字序列和简单代码）以及开放式自然语言。综合来看，Qwen3-1.7B 搭配 7 个 speculative tokens 的平衡最好。完整调优细节见 Lessons learned 部分。
NeuronX Distributed Inference（NxD Inference）支持什么
AWS Neuron 是 AWS AI 芯片的软件开发工具包。NeuronX Distributed Inference（NxDI）是其用于在 Trainium 和 Inferentia 上实现可扩展、高性能 LLM 推理的库。NxDI 在 Trainium 上为推测解码提供四种模式的原生支持：
完整文档可参考 Speculative Decoding 指南和 EAGLE Speculative Decoding 指南。本文使用 fused speculation，其中草稿模型（Qwen3-1.7B）和目标模型（Qwen3-32B）通过 enable_fused_speculation=true 一起编译，以在 Neuron 上获得最佳性能。
在 AWS Trainium 上开始使用推测解码
我们在同一个 Amazon Elastic Kubernetes Service（Amazon EKS）集群中的 Trainium 实例上部署了两个 vLLM 推理服务，除解码方式外其余都保持一致，以隔离性能影响。基线服务（qwen-vllm）使用标准解码提供 Qwen3-32B。推测解码服务（qwen-sd-vllm）则在相同的 Qwen3-32B 目标模型基础上，增加了一个 Qwen3-1.7B 草稿模型，并将 num_speculative_tokens 设为 7。
两个服务在 Trn2（trn2.48xlarge）上运行完全相同的配置，包括相同的加速器分配、tensor parallelism（将模型权重分布到多个 NeuronCore 上以容纳大模型）、序列长度、批处理限制和 Neuron DLC 镜像。唯一的区别是推测解码服务增加了 Qwen3-1.7B 草稿模型，并将 num_speculative_tokens 设为 7。完整设置见图 2。
为在相同负载下比较这两种配置，我们使用 llmperf 向两个端点生成相同的流量模式。我们通过 CloudWatch Container Insights 采集基础设施遥测数据，并将请求级自定义指标（TTFT、inter-token latency 和端到端延迟）发布到 CloudWatch 仪表板中，以进行并排分析。
基准测试设置
我们使用 LLMPerf 针对基线部署和推测解码部署运行了结构化、以解码为主的测试用例。基准测试在一个 Kubernetes Pod 中运行，即 qwen-llmperf-pod.yaml，它会并发向两个端点发起请求，并记录 token 级延迟指标。测试用例覆盖从高度结构化的提示（重复序列、数字续写、简单代码模式）到开放式自然语言补全，涵盖了推测解码的最佳和最差情况。完整提示集可在 samples 仓库中获得。
为便于说明，我们将分析重点放在两类具有代表性的提示上：一种是高度结构化、确定性的提示（重复文本生成），另一种是开放式提示。这两种情况分别展示了推测解码的最佳和最差表现。
该 Pod 在控制输入输出长度并将 temperature=0.0 的条件下运行 llmperf，以强化确定性解码路径。我们记录并发布了 inter-token latency、TTFT、吞吐量和端到端延迟等指标到 CloudWatch。
结果
图 3：推测解码的端到端延迟
推测解码对延迟的降低是有选择性的：其效果高度依赖提示结构，而且这种依赖性在所测量的各项指标中都持续出现。对于不同提示类型，你可以预期如下表现：
图 4：推测解码的 inter-token latency（Decode）
TTFT（Time to First Token，首 token 时间）在不同配置下基本保持不变（见图 5）。TTFT 主要由 prefill 阶段决定，也就是模型对输入上下文进行编码的阶段。推测解码不会改变这一阶段，因此 prefill 延迟既不会改善，也不会变差。
图 5：推测解码的 TTFT（Prefill）
综合来看，这些结果表明，推测解码是通过减少目标模型执行的解码步骤数量来改善总延迟的，而不是通过加速单个解码步骤本身或 prefill 阶段。因此，在结构化提示下，收益会体现在端到端延迟中，但不会体现在 inter-token latency 和 TTFT 上；而在开放式生成中，推测解码则会回到接近基线的表现。
复现实验结果
我们在 AWS Neuron EKS samples 仓库中提供了端到端代码示例和 Kubernetes 配置。该仓库包括：
这些示例可以让你复现本文使用的相同实验设置，从模型部署到基准测试，再到指标采集。
结论
以解码为主的 LLM 工作负载受限于自回归生成的串行特性。推测解码通过减少生成完整输出所需的目标模型解码步骤数量，打破了 AWS Trainium2 上的这一瓶颈，实质上提高了每次前向传递生成的 token 数量。对于输出空间可预测的工作负载，如代码生成、结构化数据提取、模板化报告生成或配置文件合成，这可以直接转化为更低的每输出 token 成本和更高的吞吐量，且不牺牲质量。推测解码并不是通用优化手段。它的效果取决于提示结构、草稿模型质量以及推测参数调优。在适合的工作负载中，它能为基于 Trainium 的推理系统带来有意义的延迟和成本改善。
下一步
若要开始在 AWS Trainium 上使用推测解码，可参考以下资源：
关于作者
Yahav Biran 是 Amazon 的 Principal Architect，专注于大规模 AI 工作负载。他参与开源项目，并在 AWS 博客和学术期刊上发表内容，包括 AWS compute 和 AI 博客以及 Journal of Systems Engineering。他经常进行技术演讲，并与客户合作设计云应用。Yahav 拥有 Colorado State University 的 Systems Engineering 博士学位。
Truong Pham 是 Amazon 旗下 Annapurna Labs 的软件工程师，专注于优化 AWS Inferentia 和 Trainium 等 AWS AI 加速器上的大语言模型推理性能，并为 AWS Neuron 软件栈设计对开发者友好的 API。Truong 拥有 University of Minnesota 的 Chemical Engineering 博士学位。
