文档教程技术博客大模型人工智能【免费下载链接】one-small-step这是一个简单的技术科普教程项目主要聚焦于解释一些有趣的前沿的技术概念和原理。每篇文章都力求在 5 分钟内阅读完成。项目地址https://gitcode.com/gh_mirrors/on/one-small-step点击查看免费下载推测性解码Speculative Decoding是一种专门用于优化大语言模型LLM推理性能的加速技术核心思路是在主模型生成当前 token 的同时用一个更小、更快的草稿模型Draft Model提前预测后续多个 token再由主模型一次性并行验证从而在几乎不损失输出质量的前提下显著提升吞吐。读完本文你将掌握它的双模型结构、多头预测与验证机制以及模型选型、预测头数量等工程实现要点明白为什么它特别适合对响应速度要求高的生产环境。为什么需要推测性解码自回归生成的速度瓶颈当前主流的大语言模型基本都是基于 Transformer 架构的自回归模型Auto-Regressive Model每生成一个 token都要把已经生成的全部序列重新过一遍模型才能预测下一个 token。这意味着生成是逐 token 串行的N 个 token 需要 N 次前向传播每次前向传播都要从显存HBM中读取模型全部权重推理过程往往受内存带宽限制而非算力限制序列越长历史信息越多KV Cache 占用也越大。在仓库的《Transformer 的优化方案都有哪些》一文中推测解码Speculative Decoding就被列为与连续批处理Continuous Batching、动态批处理并列的推理加速技术而与 KV Cache 相关的缓存失效问题则可参考《如何避免 KVCache 失效》一文。推测性解码正是从减少大模型前向传播次数这个角度切入把串行瓶颈转化为并行验证。核心思想用一个快模型替慢模型探路推测性解码的核心思想是在当前大模型生成当前 token 的同时使用小的草稿模型对未来的 token 进行预测。也就是说把每一步都必须由大模型亲自走一遍的模式改造成小模型先跑一段大模型只做抽查验收。由于小模型速度快、成本低它可以以极低的代价连续猜测多个后续 token大模型则只需一次前向传播就能同时验证这些猜测是否正确从而把原本多次串行的大模型前向传播压缩成一次并行验证。工作原理双模型结构推测性解码天然依赖双模型结构二者各司其职主模型Target Model完整的大语言模型精度高但速度较慢负责最终的验收和兜底生成草稿模型Draft Model较小的模型速度快但精度较低负责快速猜出后续 token。草稿模型通常不是随便选一个模型而是主模型的蒸馏版本或更小的变体——关于蒸馏Distillation如何把大模型知识迁移给小模型仓库中的《什么是 LLM 蒸馏技术》一文有详细介绍。蒸馏得到的学生模型天然与大模型行为接近预测被主模型认可的概率更高接受率更高加速效果也就更好。多头预测Speculative Heads为了让草稿模型一口气猜出多个后续 token需要在模型中添加多个预测头speculative heads每个预测头负责预测未来的一个 tokenN1, N2, N3...这样就可以在单次前向传播中预测多个 token使用较小的草稿模型快速预测多个可能的后续 token草稿模型通常是主模型的蒸馏版本或更小的变体。多头预测把一步一猜升级为一步猜一串是推测性解码能省下多次串行前向传播的关键。验证机制预测正确与否最终要由主模型把关主模型会验证草稿模型预测的 token 序列如果预测正确就可以直接使用这些 token无需再逐个重新生成如果预测错误则回退到主模型重新生成并从第一个错误位置开始纠正。这里有一个细节值得说明主模型对草稿序列的验证是在一次前向传播内并行完成的而不是逐个 token 串行验证——这正是加速的来源。当某个位置的预测与主模型不一致时模型会在该位置截断只保留之前被验证正确的部分。这种接受若干正确 token 回退纠正一个错误 token的机制可以保证最终输出分布与主模型单独生成时的分布保持一致这也是输出质量不受影响的底气所在该机制源自论文Fast Inference from Transformers via Speculative Decoding提出的拒绝采样思路原文档 Reference 一节对该论文有详细引用。一次完整的推测性解码流程把上面的机制串起来一次完整执行大致是草稿模型先自回归地生成 γ 个候选 tokenγ 即预测头数量/推测深度将这 γ 个候选 token 拼接在真实历史序列之后交给主模型做一次前向传播主模型并行校验 γ 个位置上的预测是否与自己的分布一致从第一个不一致的位置开始回退接受连续正确的一段同时用主模型在该位置给出的正确 token 补齐下一轮重复上述过程。每轮主模型只需要跑一次前向却可能白赚多个 token实际生成速率因此大幅提升。性能提升根据原始文章引用的论文报告数据推测性解码能带来可观的加速语言模型可获得约2 倍的速度提升代码模型可获得约3 倍的速度提升。需要说明的是这只是论文报告的代表性数据。实际加速比取决于接受率acceptance rate——即草稿模型预测被主模型认可的比例草稿模型与主模型越对齐接受率越高需要回退重写的 token 越少加速效果越明显。这也是为什么草稿模型强烈倾向于选用主模型的蒸馏版本。实现考虑模型选择草稿模型不是越小越好也不是越大越好需要在速度和接受率之间取舍草稿模型通常是主模型的1/4 到 1/2 大小例如如果主模型是 70B 参数草稿模型可能是7B 或 13B参数。一个现实中的典型对应是 DeepSeek-R1 与其蒸馏版本 DeepSeek-R1-Distill-Qwen-32B后者正是从前者蒸馏出的小变体天然适合充当前者的草稿候选。仓库中的《如何本地运行 GGUF 格式的 LLM 模型》一文就以DeepSeek-R1-Distill-Qwen-32B-GGUF为例演示了用 llama.cpp 在本地运行这类蒸馏小模型的完整流程下载量化包 → 编译 →llama-server -m ... --host 0.0.0.0 --port 9990→ 浏览器访问可作为动手实验的参考起点。预测头数量预测头数量即单轮推测的 token 数 γ对不同任务有不同的经验取值语言模型通常使用3-4 个预测头代码模型可以使用6-8 个预测头。代码类任务模式更规律、更易预测因此可以用更深的推测深度而开放式自然语言生成不确定性更高推测太深反而容易在较远位置出错造成浪费。效率平衡实现推测性解码本质上是在计算量、内存使用和预测准确性之间找平衡预测头数量增加会带来额外计算开销草稿模型要生成更长的候选序列主模型验证的并行计算量也随之上升但如果预测准确可以减少内存访问次数每接受一个草稿 token就省下一次大模型的完整权重读取——在内存带宽受限的推理场景下这比省算力更关键过深的推测会拉低接受率过浅的推测又省不下几次前向传播因此 γ 的最优值需要针对具体模型与任务实测调优。优点与适用场景推测性解码这项技术的主要优势在于它能显著提升模型的推理速度同时保证输出质量不受影响。因为最终的验收仍然由高精度的主模型把关被采用的 token 都经过主模型确认输出分布不会偏离主模型的原始行为。它特别适合需要快速响应的生产环境使用例如在线聊天、实时问答等对首字延迟和吞吐敏感的交互式服务批量生成场景下希望用同样的硬件跑出更高吞吐希望在本地消费级硬件上用较小的草稿模型加速一个大模型的场景。从仓库《Transformer 的优化方案都有哪些》一文的编排来看推测解码属于推理侧的优化手段常与 KV Cache、量化如 Q4_K_M 等 GGUF 量化版本详见《什么是大语言模型量化》、Flash Attention详见《什么是 Flash Attention》等技术组合使用共同压低大模型推理的成本与延迟。小结推测性解码用一个小而快的草稿模型替大而慢的主模型探路再用主模型一次性并行验收把串行的逐 token 生成改造成多 token 并行验证在保持输出质量的前提下换来约 23 倍的推理加速。它的工程要点可以概括为三句话草稿模型选主模型的蒸馏版本或 1/41/2 大小的变体语言模型用 3-4 个预测头、代码模型用 6-8 个预测头在计算开销、内存访问与预测准确率之间反复调优找到合适的推测深度。参考Fast Inference from Transformers via Speculative DecodingarXiv:2211.17192推测性解码的原始论文原文档 Reference 一节附有详细阅读链接Hitchhikers Guide to Speculative DecodingPyTorch 官方博客原文档 Reference 一节附有阅读链接本仓库关联阅读什么是 LLM 蒸馏技术、Transformer 的优化方案都有哪些、如何本地运行 GGUF 格式的 LLM 模型。赞分享文档教程技术博客大模型人工智能【免费下载链接】one-small-step这是一个简单的技术科普教程项目主要聚焦于解释一些有趣的前沿的技术概念和原理。每篇文章都力求在 5 分钟内阅读完成。项目地址https://gitcode.com/gh_mirrors/on/one-small-step点击查看免费下载相关推荐深入解析 corsair-dev/linkedin基于 Corsair 的 LinkedIn 集成插件OAuth 认证、8 大 API 域与 Provider 细节深入解析 corsair dev/linkedin 基于 Corsair 的 LinkedIn 集成插件OAuth 认证、8 大 API 域与 Provi预训练大模型人工智能基础模型微调模型评测本地部署MLX 投机解码实战用 T5-small 草稿模型加速 T5-XXL 文本生成Speculative DecodingMLX 投机解码实战用 T5 small 草稿模型加速 T5 XXL 文本生成Speculative Decoding 导读 本文围绕 llms/spec示例工程人工智能PaddleNLP 投机解码Speculative Decoding推理加速实战inference_with_reference 与 MTP 完整指南PaddleNLP 投机解码Speculative Decoding推理加速实战inference_with_reference 与 MTP 完整指南 投人工智能大模型预训练微调LoRARLHF强化学习分布式训练模型推理服务推理引擎模型量化模型压缩本地部署NLP上一篇告别图标管理噩梦Heroicons SVG精灵技术从零散引用到性能飞升下一篇Qwopus3.6-35B-A3B-Coder终极指南打造高效本地AI编码助手创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/6 1:57:35 · 阅读 1.2k 什么是推测性解码（Speculative Decoding）？如何用草稿模型加速 LLM 推理
文档教程技术博客大模型人工智能【免费下载链接】one-small-step这是一个简单的技术科普教程项目主要聚焦于解释一些有趣的前沿的技术概念和原理。每篇文章都力求在 5 分钟内阅读完成。项目地址https://gitcode.com/gh_mirrors/on/one-small-step点击查看免费下载推测性解码Speculative Decoding是一种专门用于优化大语言模型LLM推理性能的加速技术核心思路是在主模型生成当前 token 的同时用一个更小、更快的草稿模型Draft Model提前预测后续多个 token再由主模型一次性并行验证从而在几乎不损失输出质量的前提下显著提升吞吐。读完本文你将掌握它的双模型结构、多头预测与验证机制以及模型选型、预测头数量等工程实现要点明白为什么它特别适合对响应速度要求高的生产环境。为什么需要推测性解码自回归生成的速度瓶颈当前主流的大语言模型基本都是基于 Transformer 架构的自回归模型Auto-Regressive Model每生成一个 token都要把已经生成的全部序列重新过一遍模型才能预测下一个 token。这意味着生成是逐 token 串行的N 个 token 需要 N 次前向传播每次前向传播都要从显存HBM中读取模型全部权重推理过程往往受内存带宽限制而非算力限制序列越长历史信息越多KV Cache 占用也越大。在仓库的《Transformer 的优化方案都有哪些》一文中推测解码Speculative Decoding就被列为与连续批处理Continuous Batching、动态批处理并列的推理加速技术而与 KV Cache 相关的缓存失效问题则可参考《如何避免 KVCache 失效》一文。推测性解码正是从减少大模型前向传播次数这个角度切入把串行瓶颈转化为并行验证。核心思想用一个快模型替慢模型探路推测性解码的核心思想是在当前大模型生成当前 token 的同时使用小的草稿模型对未来的 token 进行预测。也就是说把每一步都必须由大模型亲自走一遍的模式改造成小模型先跑一段大模型只做抽查验收。由于小模型速度快、成本低它可以以极低的代价连续猜测多个后续 token大模型则只需一次前向传播就能同时验证这些猜测是否正确从而把原本多次串行的大模型前向传播压缩成一次并行验证。工作原理双模型结构推测性解码天然依赖双模型结构二者各司其职主模型Target Model完整的大语言模型精度高但速度较慢负责最终的验收和兜底生成草稿模型Draft Model较小的模型速度快但精度较低负责快速猜出后续 token。草稿模型通常不是随便选一个模型而是主模型的蒸馏版本或更小的变体——关于蒸馏Distillation如何把大模型知识迁移给小模型仓库中的《什么是 LLM 蒸馏技术》一文有详细介绍。蒸馏得到的学生模型天然与大模型行为接近预测被主模型认可的概率更高接受率更高加速效果也就更好。多头预测Speculative Heads为了让草稿模型一口气猜出多个后续 token需要在模型中添加多个预测头speculative heads每个预测头负责预测未来的一个 tokenN1, N2, N3...这样就可以在单次前向传播中预测多个 token使用较小的草稿模型快速预测多个可能的后续 token草稿模型通常是主模型的蒸馏版本或更小的变体。多头预测把一步一猜升级为一步猜一串是推测性解码能省下多次串行前向传播的关键。验证机制预测正确与否最终要由主模型把关主模型会验证草稿模型预测的 token 序列如果预测正确就可以直接使用这些 token无需再逐个重新生成如果预测错误则回退到主模型重新生成并从第一个错误位置开始纠正。这里有一个细节值得说明主模型对草稿序列的验证是在一次前向传播内并行完成的而不是逐个 token 串行验证——这正是加速的来源。当某个位置的预测与主模型不一致时模型会在该位置截断只保留之前被验证正确的部分。这种接受若干正确 token 回退纠正一个错误 token的机制可以保证最终输出分布与主模型单独生成时的分布保持一致这也是输出质量不受影响的底气所在该机制源自论文Fast Inference from Transformers via Speculative Decoding提出的拒绝采样思路原文档 Reference 一节对该论文有详细引用。一次完整的推测性解码流程把上面的机制串起来一次完整执行大致是草稿模型先自回归地生成 γ 个候选 tokenγ 即预测头数量/推测深度将这 γ 个候选 token 拼接在真实历史序列之后交给主模型做一次前向传播主模型并行校验 γ 个位置上的预测是否与自己的分布一致从第一个不一致的位置开始回退接受连续正确的一段同时用主模型在该位置给出的正确 token 补齐下一轮重复上述过程。每轮主模型只需要跑一次前向却可能白赚多个 token实际生成速率因此大幅提升。性能提升根据原始文章引用的论文报告数据推测性解码能带来可观的加速语言模型可获得约2 倍的速度提升代码模型可获得约3 倍的速度提升。需要说明的是这只是论文报告的代表性数据。实际加速比取决于接受率acceptance rate——即草稿模型预测被主模型认可的比例草稿模型与主模型越对齐接受率越高需要回退重写的 token 越少加速效果越明显。这也是为什么草稿模型强烈倾向于选用主模型的蒸馏版本。实现考虑模型选择草稿模型不是越小越好也不是越大越好需要在速度和接受率之间取舍草稿模型通常是主模型的1/4 到 1/2 大小例如如果主模型是 70B 参数草稿模型可能是7B 或 13B参数。一个现实中的典型对应是 DeepSeek-R1 与其蒸馏版本 DeepSeek-R1-Distill-Qwen-32B后者正是从前者蒸馏出的小变体天然适合充当前者的草稿候选。仓库中的《如何本地运行 GGUF 格式的 LLM 模型》一文就以DeepSeek-R1-Distill-Qwen-32B-GGUF为例演示了用 llama.cpp 在本地运行这类蒸馏小模型的完整流程下载量化包 → 编译 →llama-server -m ... --host 0.0.0.0 --port 9990→ 浏览器访问可作为动手实验的参考起点。预测头数量预测头数量即单轮推测的 token 数 γ对不同任务有不同的经验取值语言模型通常使用3-4 个预测头代码模型可以使用6-8 个预测头。代码类任务模式更规律、更易预测因此可以用更深的推测深度而开放式自然语言生成不确定性更高推测太深反而容易在较远位置出错造成浪费。效率平衡实现推测性解码本质上是在计算量、内存使用和预测准确性之间找平衡预测头数量增加会带来额外计算开销草稿模型要生成更长的候选序列主模型验证的并行计算量也随之上升但如果预测准确可以减少内存访问次数每接受一个草稿 token就省下一次大模型的完整权重读取——在内存带宽受限的推理场景下这比省算力更关键过深的推测会拉低接受率过浅的推测又省不下几次前向传播因此 γ 的最优值需要针对具体模型与任务实测调优。优点与适用场景推测性解码这项技术的主要优势在于它能显著提升模型的推理速度同时保证输出质量不受影响。因为最终的验收仍然由高精度的主模型把关被采用的 token 都经过主模型确认输出分布不会偏离主模型的原始行为。它特别适合需要快速响应的生产环境使用例如在线聊天、实时问答等对首字延迟和吞吐敏感的交互式服务批量生成场景下希望用同样的硬件跑出更高吞吐希望在本地消费级硬件上用较小的草稿模型加速一个大模型的场景。从仓库《Transformer 的优化方案都有哪些》一文的编排来看推测解码属于推理侧的优化手段常与 KV Cache、量化如 Q4_K_M 等 GGUF 量化版本详见《什么是大语言模型量化》、Flash Attention详见《什么是 Flash Attention》等技术组合使用共同压低大模型推理的成本与延迟。小结推测性解码用一个小而快的草稿模型替大而慢的主模型探路再用主模型一次性并行验收把串行的逐 token 生成改造成多 token 并行验证在保持输出质量的前提下换来约 23 倍的推理加速。它的工程要点可以概括为三句话草稿模型选主模型的蒸馏版本或 1/41/2 大小的变体语言模型用 3-4 个预测头、代码模型用 6-8 个预测头在计算开销、内存访问与预测准确率之间反复调优找到合适的推测深度。参考Fast Inference from Transformers via Speculative DecodingarXiv:2211.17192推测性解码的原始论文原文档 Reference 一节附有详细阅读链接Hitchhikers Guide to Speculative DecodingPyTorch 官方博客原文档 Reference 一节附有阅读链接本仓库关联阅读什么是 LLM 蒸馏技术、Transformer 的优化方案都有哪些、如何本地运行 GGUF 格式的 LLM 模型。赞分享文档教程技术博客大模型人工智能【免费下载链接】one-small-step这是一个简单的技术科普教程项目主要聚焦于解释一些有趣的前沿的技术概念和原理。每篇文章都力求在 5 分钟内阅读完成。项目地址https://gitcode.com/gh_mirrors/on/one-small-step点击查看免费下载相关推荐深入解析 corsair-dev/linkedin基于 Corsair 的 LinkedIn 集成插件OAuth 认证、8 大 API 域与 Provider 细节深入解析 corsair dev/linkedin 基于 Corsair 的 LinkedIn 集成插件OAuth 认证、8 大 API 域与 Provi预训练大模型人工智能基础模型微调模型评测本地部署MLX 投机解码实战用 T5-small 草稿模型加速 T5-XXL 文本生成Speculative DecodingMLX 投机解码实战用 T5 small 草稿模型加速 T5 XXL 文本生成Speculative Decoding 导读 本文围绕 llms/spec示例工程人工智能PaddleNLP 投机解码Speculative Decoding推理加速实战inference_with_reference 与 MTP 完整指南PaddleNLP 投机解码Speculative Decoding推理加速实战inference_with_reference 与 MTP 完整指南 投人工智能大模型预训练微调LoRARLHF强化学习分布式训练模型推理服务推理引擎模型量化模型压缩本地部署NLP上一篇告别图标管理噩梦Heroicons SVG精灵技术从零散引用到性能飞升下一篇Qwopus3.6-35B-A3B-Coder终极指南打造高效本地AI编码助手创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考