llama.cpp在消费级Ampere上推测解码对MoE没有净加速，换到vLLM+MTP却是+27.5%，同一个加速技术在两个引擎上效果相反，“这个功能有没有用”到底该信引擎还是信硬件？

同一项推测解码（Speculative Decoding）技术，在 llama.cpp + 消费级 Ampere + MoE 模型上测得的端到端加速接近于零，而在 vLLM + 多 Token 预测（MTP）路径上却报告了 +27.5% 的吞吐提升。把“功能有没有用”简化成“信引擎还是信硬件”是一个伪命题：加速比从来不是硬件的属性，也不是引擎的属性，而是引擎实现、硬件瓶颈位与负载形态三者的联合函数。本文的主线只有一句——先定位瓶颈位，再谈加速技术。

目 录

一、导语：一个被误读的对照实验

先把事实摆清楚。推测解码的基本形态是“草稿—验证”：用小模型或额外预测头快速生成若干候选 token，再由目标模型一次前向并行验证，接受前缀、拒绝后缀。Leviathan 等人（2023）与 Chen 等人（2023）分别独立形式化了这一框架，并证明在草稿质量足够时，输出分布与目标模型严格一致（无损加速）。这条性质是推测解码的全部理论卖点，也是它被广泛集成进推理引擎的原因。

但“无损”只保证正确性，不保证速度。速度增益取决于一个非常朴素的比值：被接受 token 数 除以 验证一次所付出的额外成本。当目标模型是 MoE（Mixture-of-Experts）结构时，这个比值会被显著扭曲——MoE 的单次前向成本并不随 batch 线性增长，专家路由带来的 gather/scatter 与负载不均衡会吃掉并行验证的红利。本文评述：很多“推测解码无效”的结论，实际上测的是“MoE 上的验证成本过高”，而不是“推测解码本身失效”。

于是出现了标题中的反差：llama.cpp 在消费级 Ampere（如 RTX 3090/4090，24GB 显存、约 936–1008 GB/s 带宽）上跑 MoE 模型，推测解码净加速接近 0；vLLM 配合 MTP 在数据中心级配置上报告 +27.5%。这两个数字并不矛盾，它们测的是不同的瓶颈位。笔者认为，把二者放在同一张表里比较“谁对谁错”，在方法论上是不成立的；正确的做法是把加速比拆成可归因的因子。

二、背景与问题定义：推测解码到底在优化什么

2.1 解码阶段的真实瓶颈：内存带宽，不是算力

自回归解码每生成一个 token，都要把全部权重从显存读一遍。对 7B 级稠密模型，单 token 需要读取约 14GB（FP16）权重；在 1 TB/s 带宽的卡上，理论下限约 14ms/token，而对应的矩阵乘算力需求远未饱和。这就是经典的“memory-bound”阶段。推测解码的聪明之处在于：既然一次前向已经要把权重读进来，那就顺便多验证几个 token，把“读权重的固定成本”摊薄到多个 token 上。

本文评述：这个逻辑成立的前提是“验证 k 个 token 的额外算力成本可忽略”。对稠密模型，k 较小（典型 3–5）时该前提基本成立；但对 MoE，情况变了——MoE 的激活专家集合随 token 变化，验证 k 个 token 意味着可能触发 k 组不同的专家，权重读取量不再是一次性的固定成本，而是随 k 增长。这是理解 llama.cpp 侧“零加速”的第一把钥匙。

2.2 两个引擎的架构差异：为什么不能直接对比

llama.cpp 的定位是“单机、跨平台、极致可移植”，其计算图以 ggml 为基础，针对消费级 GPU 的优化重点是量化内核（Q4_K_M、Q5_K_M 等）与低显存占用。它的批处理能力相对保守，连续批处理（continuous batching）的实现深度不及服务型引擎。vLLM 的定位是“高吞吐服务”，核心是 PagedAttention 的 KV 缓存分页管理与成熟的连续批处理调度，MTP 则是在模型侧引入多 token 预测头，把“草稿”内化进目标模型。

本文评述：把 llama.cpp 的推测解码与 vLLM 的 MTP 直接对比，等于拿“单请求、低并发、量化权重”的场景去比“多请求、高并发、可能张量并行”的场景。两者的 batch 形态根本不同，而推测解码的收益高度依赖 batch 形态——这是第二把钥匙，也是后文数据对照时必须先做的归一化。

2.3 问题重述：从“有没有用”到“在哪个瓶颈位有用”

因此本文不回答“推测解码有没有用”，而是回答三个可检验的子问题：其一，在给定硬件上，解码阶段的瓶颈位是带宽、算力还是调度开销？其二，目标模型的 MoE 结构如何改变验证成本随 k 的增长曲线？其三，引擎的批处理与内核实现如何放大或抵消前两者的影响？这三个问题各自有可测量的代理指标，下一节给出。

三、机制拆解：接受率、批形态、带宽与内核

3.1 第一层：接受率与期望加速的解析式

设草稿长度为 γ，逐位置接受率为 α，则单轮验证的期望接受 token 数可近似写为：

E[accepted] = (1 - α^(γ+1)) / (1 - α)      （α ≠ 1）
理论加速上限 ≈ E[accepted] / (1 + c_draft·γ / c_target)

其中 c_draft 与 c_target 分别是草稿与目标模型单 token 的相对成本。这个式子说明两件事：α 越高、γ 越大，分子越大；但分母里的草稿成本随 γ 线性增长。本文评述：很多工程报告只报 α 不报 c_draft，导致“接受率 70% 却没加速”的困惑。对 MoE 目标模型，c_target 本身不是常数，验证 k 个 token 的成本可能接近 k 倍而非 1 倍，分母被低估，加速自然落空。

3.2 第二层：MoE 验证成本的“专家散射”效应

MoE 层的前向包含路由（top-k gating）、按专家分组、gather/scatter 与合并。当验证一批 token 时，不同 token 路由到不同专家，GPU 需要为每个被激活的专家单独调度计算。若专家粒度细、激活分散，内核启动与显存访问的碎片化会显著抬高单次验证的固定开销。DeepSeek 系列与 Qwen-MoE 系列的开源实现都暴露过这一特性：小 batch 下 MoE 的效率低于同参数量稠密模型。

本文评述：这解释了为何在消费级单卡上，MoE + 推测解码容易“白忙”。草稿省下的那点串行步数，被验证阶段多触发的专家读取吃掉了。反过来，当 batch 足够大、专家激活被充分复用（同一专家服务多个 token）时，验证的边际成本下降，推测解码的收益才可能显现——这正是服务型引擎的用武之地。

3.3 第三层：批形态如何改写收益曲线

单请求场景下，解码是纯串行、纯带宽受限，推测解码的“摊薄权重读取”逻辑最纯粹。多请求并发下，连续批处理已经把权重读取摊薄到 batch 维度，此时推测解码的边际收益来自“减少调度轮次”而非“减少权重读取”，收益结构完全不同。vLLM 的连续批处理会把不同请求的解码步拼进同一批，推测解码带来的额外验证 token 会挤占 batch 容量，可能反而降低吞吐。

本文评述：+27.5% 这类数字必须连同并发度一起读。若测试是在中等并发、MTP 草稿与目标共享主干、且专家复用充分的前提下取得，那么它证明的是“在该批形态下 MTP 有效”，而非“推测解码普遍有效”。脱离并发度谈加速比，是当前工程报告里最普遍的失真来源。

3.4 第四层：内核实现与量化路径的隐性成本

llama.cpp 在消费级 Ampere 上大量使用量化权重（如 Q4_K_M），量化内核的解量化开销与推测解码的验证逻辑存在交互：验证多个 token 时，反量化后的权重需要被更多次复用，理论上有利；但若内核本身对小 batch 做了特化，验证 batch 变大反而触发非最优路径。此外，草稿模型若也走量化，其输出分布与目标模型存在偏差，接受率会被拉低。

本文评述：量化与推测解码的交互是被低估的变量。工程上应优先保证草稿与目标在同一数值精度体系下评估接受率，否则测得的 α 不可迁移。这一条在复现任何“加速比”报告时都应作为前置检查项。

四、关键数据与案例：两条路径的实测对照

4.1 数据来源与口径说明

本节数据分三类并明确标注：其一，来自公开论文与官方技术报告的数字（标注文献）；其二，来自公开仓库 issue、benchmark 脚本的社区实测（标注来源类型）；其三，为说明机制而构造的模拟数据（明确标注“模拟”）。所有对比均给出硬件、模型、量化、并发度四要素，缺一不可。读者应注意，社区实测的口径差异极大，直接横比有风险。

表 1　两条路径的工程画像对照（口径差异本身即为结论的一部分）。

4.2 案例一：消费级 Ampere 上的 MoE 推测解码为何归零

在 RTX 3090（24GB，936 GB/s）上跑 8×7B 级 MoE 的量化版本，权重常驻显存已接近上限，KV 缓存余量紧张。此时推测解码需要额外加载草稿模型或草稿头，进一步压缩 KV 空间，迫使引擎降低并发或缩短上下文。社区在 llama.cpp 仓库的相关讨论中多次提到，开启 draft 后显存占用上升、长上下文场景下反而变慢。本文评述：这是“资源约束型失效”，不是算法失效——加速技术的开销挤占了本就稀缺的显存带宽与容量。

更关键的是验证阶段的专家散射。MoE 在单请求、小 batch 下，每个 token 激活的专家集合不同，验证 γ 个 token 需要读取的专家权重集合是并集，读取量随 γ 增长。原本“一次前向摊薄权重读取”的红利被抵消。笔者据此判断：在消费级单卡 + 量化 MoE + 单请求的组合下，推测解码的期望收益本就接近零，实测归零是机制上的必然，而非实现缺陷。

4.3 案例二：vLLM + MTP 的 +27.5% 从哪来

MTP 的核心优势是草稿与目标共享主干，草稿成本 c_draft 远低于外挂小模型；同时 vLLM 的连续批处理让验证 token 与在途请求共享专家读取，MoE 的专家复用率上升，验证的边际成本下降。两者叠加，分母被压低、分子被抬高，+27.5% 在机制上是可解释的。需要强调的是，该数字对应的并发度、序列长度分布、模型规模在原始报告中均有明确设定，迁移到其他设定时不应直接套用。

本文评述：把 +27.5% 当作“推测解码的普遍增益”是误读，把它当作“vLLM 比 llama.cpp 强”同样是误读。它真正说明的是：当草稿成本被内化、专家复用被批处理放大时，推测解码的收益结构才成立。这恰好反证了第 3 节的分层框架——收益来自瓶颈位的改变，而非技术本身的“强弱”。

4.4 模拟数据：接受率与验证成本的敏感性分析

为量化四层因子的相对重要性，笔者构造一组敏感性模拟（模拟数据，非实测）：固定目标模型单步成本为 1，草稿相对成本 c_draft 取 0.05（MTP 型）与 0.25（外挂小模型型），MoE 验证成本系数 β 取 1.0（稠密）与 1.6（专家散射），接受率 α 从 0.4 扫到 0.9，γ 取 4。结果如下表。

表 2　净加速对 α 与 β 的敏感性（模拟数据，仅用于机制说明，不代表任何真实硬件实测）。

模拟给出的结论很直接：当 β=1.6（MoE 专家散射）且草稿成本较高（外挂型）时，即便 α 达到 0.75，净加速仍低于 1；只有当草稿成本被内化（MTP 型）且 α 足够高时，收益才稳定为正。这与第 4.2、4.3 节的实测方向一致，说明四层框架具备解释力。本文评述：模拟不能替代实测，但它能帮我们在上机之前判断“值不值得试”，这正是工程决策需要的。

五、可操作路径：五步归因法与选型决策树

5.1 第一步：先测瓶颈位，再谈加速

在开启任何推测解码之前，先做一次“解码基线画像”：固定输入长度与输出长度，测单 token 延迟、显存带宽利用率（可用 nvidia-smi dmon 或 Nsight 粗测）、SM 占用率。若带宽利用率已接近饱和而算力占用低，说明处于 memory-bound，推测解码有理论空间；若算力占用已高或调度开销占比大，推测解码的边际收益有限。这一步是后续所有判断的前提。

5.2 第二步：测接受率，且分场景测

接受率不是全局常数。代码补全、结构化输出、自然语言闲聊的 α 差异很大。建议按任务类型分别采样 200–500 条真实请求，统计逐位置接受率，并记录草稿长度 γ 的分布。若某类任务 α 长期低于 0.5，直接放弃该场景的推测解码，转而优化批处理或量化。本文评述：把 α 当作单一数字汇报，是很多“加速失败”复盘中最常见的疏漏。

5.3 第三步：量化验证成本，尤其是 MoE

对 MoE 模型，单独测“验证 γ 个 token 的前向耗时”随 γ 的变化曲线。若曲线斜率明显大于 1（相对单 token 前向），说明专家散射显著，应优先考虑增大 batch 以提升专家复用，或改用 MTP 型内置草稿降低 c_draft。这条曲线是判断“MoE 上推测解码是否划算”的最直接证据。

5.4 第四步：按批形态选引擎，而非按名气

单机、单用户、显存紧张：llama.cpp 的量化与可移植性仍是首选，但不要指望推测解码带来显著增益，除非模型是稠密且 α 很高。多用户、服务化、可接受多卡：vLLM 的连续批处理 + MTP 组合更可能兑现收益。决策树可简化为：并发度低 → 优先降延迟的其他手段；并发度高 → 优先验证 MTP 的收益曲线。

5.5 第五步：小步灰度，用 A/B 而非单点结论

上线前用真实流量做 A/B：同一批请求分别走开启/关闭推测解码，比较 P50/P99 延迟与吞吐，而非只看平均值。注意控制变量——量化版本、上下文长度分布、并发度必须一致。任何“+X%”的结论都应附带这四个控制变量，否则不可复现。本文评述：可复现性本身就是工程结论可信度的一部分。

六、对比与局限：加速技术的边界条件

6.1 推测解码 vs. 其他解码加速手段

与量化、KV 缓存压缩、连续批处理相比，推测解码的独特之处是“无损且正交”——它不改变输出分布，可与量化叠加。但它的收益上限受 α 约束，而 α 又受任务与草稿质量约束。本文评述：把推测解码当作“默认开启”的开关是危险的；它更像一个需要逐场景标定的增益模块，标定成本本身就是采用成本的一部分。

6.2 方法论的局限

本文的对照建立在公开报告与社区实测之上，缺少统一硬件、统一负载的受控实验，这是最大的局限。模拟数据只能说明机制方向，不能替代实测。此外，MoE 的专家散射程度与具体模型结构、专家数量、路由策略强相关，本文的 β 取值仅为示意。读者在复现时应以自测曲线为准。

6.3 何时应当放弃推测解码

三类情形建议直接放弃：其一，α 长期低于 0.5 的任务；其二，显存已接近上限、KV 缓存余量不足以支撑草稿的场景；其三，MoE 验证成本曲线斜率显著大于 1 且无法通过增大 batch 摊薄的单机部署。放弃不是否定技术，而是承认瓶颈位不在它该在的地方。

七、结论与展望：从“功能开关”到“瓶颈位工程”

回到标题的问题：“这个功能有没有用”该信引擎还是信硬件？答案是都不该单独信。应当信的是对瓶颈位的测量。llama.cpp 的零加速与 vLLM 的 +27.5% 并不冲突，它们分别刻画了“资源约束 + 专家散射”与“草稿内化 + 批处理复用”两种截然不同的成本结构。把加速比视为引擎×硬件×负载的三元函数，是本文试图确立的分析主线。

展望来看，三个方向值得关注：其一，MoE 专用的草稿策略，例如按专家亲和性选择草稿路径，降低验证并集；其二，MTP 类内置草稿在开源模型中的普及，把 c_draft 压到接近零；其三，面向消费级硬件的显存感知调度，让推测解码在 24GB 级卡上也能留出 KV 余量。本文评述：这些方向的共同点，都是把优化对象从“算法”转向“瓶颈位”，这也是工程实践与论文叙事最需要对齐的地方。

最后给出一条可执行的原则：任何加速技术的采用，都应先回答“当前瓶颈在哪”，再回答“它能改变哪个瓶颈”，最后才问“能快多少”。顺序颠倒，就会得到互相矛盾的数字，以及关于“该信谁”的无谓争论。

主要参考文献与声明

1. Leviathan Y, Kalman M, Matias Y. Fast Inference from Transformers via Speculative Decoding. ICML, 2023.
2. Chen C, Borgeaud S, Irving G, et al. Accelerating Large Language Model Decoding with Speculative Sampling. arXiv:2302.01318, 2023.
3. DeepSeek-AI. DeepSeek-V3 Technical Report. arXiv:2412.19437, 2024.
4. Qwen Team. Qwen1.5-MoE: Matching 7B Model Performance with 1/3 Activated Parameters. 2024.
5. Kwon W, Li Z, Zhuang S, et al. Efficient Memory Management for Large Language Model Serving with PagedAttention. SOSP, 2023.
6. vLLM Project. Speculative Decoding and Multi-Token Prediction Documentation. 2024–2025.
7. ggml-org. llama.cpp: LLM Inference in C/C++（含 speculative decoding 讨论与脚本）. GitHub, 2023–2025.
8. Xia H, Li Z, Yang Y, et al. Speculative Decoding: Exploiting Convergence Characteristics to Boost Inference Efficiency. EMNLP, 2023.