大语言模型在我们生活中越来越常用，如今我们用LLM做对话、写代码、解数学题的时候，不知道大家有没有过这样的困扰：明明模型思路很对，但生成内容要等半天——比如写一段复杂代码，要看着光标一个字符一个字符跳，做数学推理时，每一步推导都要卡一下？这背后其实是LLM“自回归生成”的天生局限：每次只能输出一个token，生成时间跟着文本长度线性增加。

更麻烦的是，现在LLM参数越来越大（动辄几百亿），但很多场景硬件条件有限，只能用消费级GPU（比如RTX 4090）部署，延迟敏感的应用（比如实时客服机器人）又要求秒级响应——这就把LLM的实际使用门槛抬得很高。

LLM实际部署的延迟敏感情况越来越严重，大家也对LLM推理加速的研究越来越深入。模型量化、算子优化、PD分离等技术演进，同时有一项叫投机解码的技术，也能帮助大模型推理提速。

投机解码由两个组件组成：一个快速的草稿模型用于预估多枚标记，和一个目标模型用于验证。草稿模型生成一串候选标记，随后由目标模型在一次前向计算中进行评估。被接受的标记保留，被拒绝的则触发重新采样。这样的并行验证能够在内存受限的操作中利用未充分使用的 GPU 资源，从而有望在每次推理步骤中产出更多标记。

今天要和大家分享的，正是腾讯 PCG 内服内容算法中心团队在投机解码技术上的创新研究：论文《FastMTP: Accelerating LLM Inference with Enhanced Multi-Token Prediction》。投机解码这个方法特别实在——它不用改主模型结构，只微调一个小模块，就能让LLM推理平均提速2.13倍，还完全不损失输出质量；而且方法和模型权重都开源了，拿过来就能用。

展示效果如下：

接下来我们从基础概念到落地细节，一步步把它讲清楚。

开源代码：https://github.com/Tencent-BAC/FastMTP

模型权重：https://huggingface.co/TencentBAC/FastMTP

论文链接：https://github.com/Tencent-BAC/FastMTP/blob/main/FastMTP_technical_report.pdf

一、先搞懂3个关键概念：为什么FastMTP能解决问题？

在聊FastMTP之前，我们得先理清它依赖的核心技术——这就像搭积木，先知道每块积木是干嘛的，才能明白最后搭出来的房子有多厉害。

1. 投机解码（Speculative Decoding）：“草稿+验证”的加速逻辑

大家写文章的时候，会不会先打个草稿，再逐句修改？推测解码就是LLM的“打草稿”策略：

• 找一个小而快的“草稿模型”（比如参数比主模型小一个量级），让它快速生成多个候选token（比如一次出3个）；
• 再让主模型“批量检查” 这些草稿token——如果对，就直接用；如果错了，就从错的地方开始重新生成。
• 关键优势：主模型不用逐个生成token了，一次能验证多个，相当于“批量处理”，速度自然快。

比如Leviathan等人2023年提出的经典方案，在内存有限的GPU上能把推理延迟降低30%以上。但这里有个问题：草稿模型的质量很关键——如果草稿总错，主模型还要回头改，反而浪费时间。

2. 多Token预测（MTP）：让模型“一次想多步”，但之前没用好

MTP是Meta在2024年提出的技术，初衷是让LLM训练更高效：

• 传统LLM训练时，每个位置只预测“下一个token”；MTP则让模型在每个位置同时预测“接下来n个token”（比如一次预测3个），用多个独立的输出头并行计算。
• 这样做的好处是：模型能提前“规划”，比如写代码时，预测到“def”后，还能提前想到后面的函数名和括号，训练时的监督信号更丰富。

后来DeepSeek-V3又优化了MTP，用“级联模块”保持逻辑连贯——每个模块基于前一个模块的输出预测下一个token，避免前后矛盾。现在Qwen3-Next、GLM-4.5这些顶级模型，训练时都加了MTP模块提升性能。

但最大的问题来了：MTP 范式在推理时效率较低！

为什么？因为之前的MTP是“多个独立模块”设计：要预测3个token，就得加载3个MTP模块，每个模块有自己的权重和缓存——内存占得多不说，调度起来特别复杂（比如要协调3个模块的计算顺序）。所以很多模型推理时，要么干脆不用MTP，要么只敢用第一个模块（只能多预测1个token），完全没发挥MTP“一次多步”的潜力。

3. EAGLE：让单MTP头也能“递归预测”的框架

EAGLE（高效语言模型外推算法）是SafeAILab提出的推测解码方案，它的核心贡献是：突破 “仅依赖词序列” 的局限，通过融合主模型的上下文特征，实现稳定的自回归草稿生成，为 “无需多模块即可生成多步草稿” 提供了关键思路。。

简单来说，EAGLE 的核心逻辑是：不用搭建多个独立模块，单个自回归模块就能通过 “递归复用” 生成连续草稿 token，且生成质量更稳定 —— 首次预测时，它会结合主模型处理输入后输出的上下文隐藏态与初始 token，确保草稿贴合主模型的语义逻辑；后续预测则复用自身上一步的输出隐藏态与前一草稿 token，一步步递归生成多步草稿。

而 FastMTP 中提到的 “EAGLE-style”，本质是借鉴 EAGLE “基于主模型上下文特征做自回归草稿” 的核心逻辑，并将其落地到 MTP 模块的设计中：它没有沿用 EAGLE 的 “Auto-regression Head”，而是将其改造为 “单共享权重 MTP 模块”—— 让这个 MTP 模块在递归生成草稿时，像 EAGLE 的自回归模块一样，第一步利用主模型的隐藏态与首验证 token 嵌入（捕捉主模型上下文），后续步骤复用自身前一步的隐藏态与草稿 token（保持递归连贯性）。这种适配既延续了 EAGLE“省内存、适配现有框架” 的优势，又通过后续的自蒸馏训练，解决了 “单 MTP 模块递归复用接受率低” 的问题，最终让单 MTP 模块成为高效的 “草稿生成器”，这也是 FastMTP 能实现推理提速的关键基础。

二、FastMTP的核心：怎么把MTP改造成“推理加速利器”？

FastMTP的思路特别直接：针对传统MTP在推理中的两个痛点（多模块内存开销大、递归预测不准），做两个关键优化，再用轻量级训练落地。

1. 架构：用“共享权重的单MTP头”替代“多独立模块”

传统MTP是“一个预测步一个模块”，FastMTP则是“所有预测步共用一个MTP模块”——不管要预测3个还是5个token，只用一个MTP模块反复计算。

这样做有两个核心好处：

• 省内存：不用加载多个模块，MTP模块的参数只有210.8M（基于MiMo-7B-RL），仅占主模型的3%不到；
• 逼模型学“长距离依赖” ：因为同一个模块要预测多步，模型必须记住前几步的预测结果（比如预测到“for i in range”后，还要记得后面该写循环体的缩进），自然能捕捉到更长的逻辑关联，草稿质量更高。

图 1：FastMTP 训练与推理策略示意图。该图分为上下两部分：顶部为训练阶段，灰色块代表主模型冻结模块，橙色块为共享权重的可训练 MTP 头，蓝色块展示用于自回归训练的移位输入 / 标签序列，清晰呈现 “单 MTP 头基于主模型隐藏态 + 移位 token 递归学习” 的训练逻辑；底部为推理阶段，绿色块为主模型生成的验证 token，粉色块为 MTP 头递归生成的草稿 token，紫色块为语言感知动态词汇压缩模块，直观体现 “草稿生成→并行验证” 的推理流程，可辅助理解 “共享单 MTP 头” 如何兼容现有框架

2. 训练：让MTP头“懂主模型的心思”，预测更准

训练的核心目标是：让MTP头生成的草稿，尽可能和主模型的输出一致（这样主模型验证时才会多接受）。FastMTP用了三个关键策略：

（1）训练机制：递归式学习，模拟推理场景

训练时，MTP头的输入是“主模型的隐藏状态+移位后的token”，递归式预测多步token：

• 第一步（预测第1个草稿token）：用主模型处理输入序列t₁~tᵢ后得到的隐藏状态hᵢ，再加上“移位token tᵢ₊₁”（把序列往后挪一位，保证因果逻辑），预测出第一个草稿token t̂ᵢ₊₂；
• 第二步（预测第2个草稿token）：不用主模型了，直接用MTP头上一步输出的隐藏状态hᵢ₊₁，加上刚预测的t̂ᵢ₊₂，预测t̂ᵢ₊₃；
• 以此类推，直到预测完K个token（论文里K=3，是实验验证的最优值）。

这样训练出来的MTP头，和推理时的使用场景完全对齐——推理时也是这么递归生成草稿的，不会出现“训练和推理脱节”的问题。

（2）损失函数：让模型“先把近处的预测准”

预测越远的token，难度越大（比如预测第5个token，要依赖前4个的预测结果，错一步就全错）。所以FastMTP用了“指数衰减的加权交叉熵损失”：

其中权重 ，β设为0.6。

通俗说：预测第1个草稿token的权重最大（α₁≈0.51），第2个次之（α₂≈0.31），第3个最小（α₃≈0.18）。这样模型会优先保证近处token的预测 accuracy，再慢慢学远处的——训练更稳，不会因为远处预测难而整体崩溃。

图 2：不同 draft step 的 MTP 训练损失曲线。该图横轴为训练步数（0~2500），纵轴为损失值，三条曲线分别对应 MTP 头预测第 2 个 token（Next2 token）、第 3 个 token（Next3 token）、第 4 个 token（Next4 token）的损失变化。可观察到 “预测步数越远，损失越高” 的规律（Next4 token 损失始终高于 Next2 token），且所有曲线随训练步数逐步收敛，印证了 “指数衰减加权损失” 优先保证近程预测准确性的设计合理性

（3）训练数据：用主模型“自蒸馏”，对齐分布

最关键的一步：训练数据不是用公开数据集的“prompt+回答”，而是让主模型自己生成回答！

具体怎么做：

1. 从多个数据集（比如ShareGPT、FLAN v2、中文的COIG-CQIA）里选389.4K个prompt，覆盖英语/中文的对话、数学、编码、知识问答；
2. 让主模型（MiMo-7B-RL）用“温度0.6、top-k=20、top-p=0.95”的参数，为每个prompt生成回答，得到“prompt+主模型回答”的数据集；
3. 再做过滤：去重（用MinHash算法）、删截断的回答（比如推理步骤没写完的）、手动筛掉低质量样本，最后留下高质量数据。

为什么要这么做？因为MTP头是给主模型当“草稿员”的——只有草稿和主模型的输出风格、逻辑一致，主模型才会多接受。如果用外部数据集的回答，风格和主模型不一样，草稿再对也会被主模型拒绝。

（4）训练成本：单服务器1天搞定，特别轻量

训练配置特别亲民：

• 硬件：单台H20服务器；
• 优化器：AdamW（β₁=0.9，β₂=0.95），峰值学习率5e-5，批大小64；
• 周期：3个epoch，总耗时不到1天；
• 参数量：只微调MTP头（210.8M），主模型完全冻结——不用怕训坏主模型，也不用大算力。

训练效果很明显：MTP头的草稿接受率大幅提升（对比传统MTP复用策略）：

• 第1个草稿token：从70%升到81%；
• 第2个草稿token：从11%跳到56%；
• 第3个草稿token：从2%涨到36%——相当于之前几乎没法用的多步预测，现在能稳定发挥作用了。

图 3：不同 draft step 的接受率对比。该图以柱状图形式，在多轮对话（MT.）、编码（Code）、数学推理（Math）等 7 个任务中，对比了 vanilla MTP 与经自蒸馏微调的 FastMTP 在第 1（k=1）、2（k=2）、3（k=3）个 draft token 的接受率。例如数学推理任务中，FastMTP 的 k=3 接受率从 vanilla MTP 的 3% 提升至 50% 以上，直观印证 “自蒸馏训练让 MTP 头具备长程预测能力” 的效果

3. 推理优化：加“语言感知词汇压缩”，再省30%计算量

草稿生成时，MTP头要计算全量词汇（比如MiMo-7B-RL的词汇量是152K）的logits，这部分计算很耗时。FastMTP发现：不管是英文还是中文，高频token的占比都极高（比如英文里“the”“a”占比超10%，中文里“的”“是”占比超8%），低频token几乎用不上。

于是他们做了“语言感知的动态词汇压缩”：

• 先统计不同语言的高频token：英文用SlimPajama-627B corpus统计，选出32K高频词；中文用Chinese-DeepSeek-R1-Distill-110k-SFT统计，选出16K高频词（中文token更集中，压缩可以更激进）；
• 推理时，MTP头根据输入语境判断语言（比如输入是中文prompt，就用中文高频词表），只计算高频token的logits——全量152K词汇的计算，变成16K/32K的计算，开销直接降了70%+；
• 关键：验证阶段还是用全量词汇——确保主模型不会因为词汇压缩漏掉正确token，输出质量完全无损。

这个优化能让草稿生成速度再快16%——比如原来生成3个草稿token要10ms，现在只要8.4ms，而且接受率几乎没降（中文任务接受长度从2.551降到2.525，几乎可以忽略）。

三、推理流程：FastMTP是怎么“跑起来”的？

FastMTP的推理过程特别简单，就两步：“生成草稿”→“并行验证”，完全兼容现有框架（比如SGLang），不用改主模型代码。

我们以“输入序列t₁~tᵢ，要生成3个草稿token”为例，一步步看：

第一步：草稿生成（MTP头递归工作）

1. 主模型先算“第一个验证token”：主模型处理t₁~tᵢ，生成第一个确定的token t̂ᵢ₊₁（这一步和传统自回归一样，保证起点正确）；
2. MTP头生成第1个草稿token：拿主模型的最后一个隐藏状态，再加上“移位序列[t₂~tᵢ + t̂ᵢ₊₁]”的嵌入（把序列往后挪一位，保证因果），预测出t̂ᵢ₊₂；
3. MTP头生成第2个草稿token：用自己上一步输出的隐藏状态，加上t̂ᵢ₊₂的嵌入，预测出t̂ᵢ₊₃；
4. MTP头生成第3个草稿token：再用第二步的隐藏状态，加上t̂ᵢ₊₃的嵌入，预测出t̂ᵢ₊₄；
5. 最终得到草稿序列：t̂ᵢ₊₂~t̂ᵢ₊₄。

第二步：并行验证（主模型批量“检查”）

1. 主模型一次性计算所有草稿token的logits：把t₁~tᵢ + t̂ᵢ₊₁~t̂ᵢ₊₄输入主模型，并行算出tᵢ₊₂~tᵢ₊₄位置的logits；
2. 按“顺序接受”原则判断：从t̂ᵢ₊₂开始，逐个对比主模型预测的token——

• 如果t̂ᵢ₊₂和主模型一致，接受；再看t̂ᵢ₊₃；
• 如果t̂ᵢ₊₃和主模型不一致，就只接受t̂ᵢ₊₂，后面的t̂ᵢ₊₄直接丢掉；

整个过程中，主模型的输出和传统自回归完全一样——因为只要草稿和主模型预测不一致，就会回退，相当于主模型“最终拍板”，所以质量无损。

这种设计既避免了多模块带来的内存冗余（不用加载多个权重与缓存），又能自然适配 SGLang 等现有推理框架，为降低部署复杂度提供了基础。

四、实验结果：FastMTP到底有多快？

论文在7个主流任务上做了测试，覆盖对话、编码、数学、中文知识等场景，硬件用的是常用的NVIDIA A10 GPU（24GB显存，很多企业部署都用这个），确保结果有参考价值。

1. 核心指标：平均提速2.03倍，碾压传统MTP

我们直接看关键对比（K=3，即一次生成3个草稿token）：

简单说：原来每秒生成31个token，用FastMTP能到64个，快了一倍多；而传统MTP只快了21%，差距特别明显。

2. 不同任务的表现：数学、编码提速最猛

图 4：不同方法在各子任务的加速比对比。该图为分组柱状图，横轴为 7 个任务（多轮对话、编码、数学推理等），纵轴为加速比，不同颜色柱体分别代表 vanilla MTP、Fixed-data FT MTP、Self-data FT MTP、Self-data FT MTP (+FR)（完整 FastMTP）。例如数学推理任务中，FastMTP 加速比达 2.5x，编码任务达 2.25x，清晰呈现 “结构化任务（数学、编码）提速更显著” 的特点

FastMTP在不同任务上的加速比不一样，正好能反映它的优势场景：

可以看到：越有规律、越结构化的任务，FastMTP提速越明显——这正好覆盖了LLM的核心应用场景（比如数学辅助、代码生成）。

3. 关键细节验证：为什么K=3是最优？

论文还测试了不同草稿长度K（1~7）的效果，发现一个重要结论：K=3时速度最快，再大反而变慢。

原因很简单：

• K=1：只能生成1个草稿token，主模型还是要频繁前向，速度提不上去；
• K=3：MTP头预测前3个token的接受率还很高（81%→56%→36%），主模型验证效率高；
• K=4及以上：第4个草稿token的接受率降到20%以下，主模型要频繁回退，反而浪费计算时间（比如生成4个草稿，只接受2个，相当于白算了2个）。

这也给我们部署提了个醒：不用盲目调大K，设为3就是最优选择，省时又省力。

图 5：不同 draft 步数 K 的解码速度与接受长度。该图包含双纵轴：左侧纵轴为解码速度（token/s，0~160），右侧纵轴为接受长度（τ，0~3.5），横轴为 draft 步数 K（0~7）。两条曲线分别对应 FastMTP（Self-data FT MTP）与 vanilla MTP：FastMTP 在 K=3 时达到速度峰值（约 140 token/s）和接受长度峰值（约 3.2），K≥4 后速度因 “草稿接受率下降、计算开销增加” 开始回落，直接印证 “K=3 为最优 draft 长度” 的结论

五、落地建议：怎么用FastMTP？

FastMTP的最大优势就是“好落地”——不用改主模型，不用大算力，跟着官方教程走，半天就能跑起来。

1. 环境准备

• 模型：基于MiMo-7B-RL，官方已经开源了FastMTP的checkpoint（Hugging Face链接：https://huggingface.co/TencentBAC/FastMTP）；
• 框架：支持SGLang（推理效率高）、PyTorch，官方给了完整的推理脚本；
• 硬件：最低要求24GB显存（比如RTX 4090、A10），不用H100也能跑。

2. 关键参数调优

• 草稿长度K：直接设为3（实验验证的最优值）；
• 词汇压缩：英文用32K高频词，中文用16K高频词（官方已经提供了预计算的词表）；
• 接受准则：用论文的“严格接受”（只要和主模型不一致就回退），保证质量无损。

3. 适用场景

• 优先用在：数学推理、代码生成、长文本摘要（结构化强，提速明显）；
• 谨慎用在：创意写作（文本无规律，预测准度低）。

六、总结与展望

FastMTP的思路特别值得借鉴：它没有追求复杂的模型结构创新，而是针对“传统MTP在推理中被浪费”这个痛点，用“共享权重单头+自蒸馏训练+词汇压缩”三个简单有效的优化，就实现了“速度翻倍+质量无损”。

对于开发者来说，这意味着：

• 用消费级GPU也能部署高性能LLM（比如RTX 4090跑MiMo-7B-RL，生成1000 token从32秒降到16秒）；
• 不用重构现有推理框架，直接集成FastMTP模块就行，成本低。

未来FastMTP还有很大潜力：比如支持更大的模型（70B参数的LLM）、和量化技术结合（INT4量化+FastMTP，速度可能再提50%）、适配多模态模型（比如生成图片描述时，也能多token预测）。