为什么 MTP 比标准解码更慢?
摘要
一位用户询问,为什么对于 Ornith 1.5 9B,llama.cpp 中的多 Token 预测(MTP)推测解码虽然草稿接受率高达 0.95,吞吐量却低于标准解码(约 15 tok/s,而标准解码约为 30 tok/s),并指出内存带宽和 GPU 利用率均减半。
我正在尝试使用最新版 llama.cpp 运行 Ornith 1.5 9B(我也勉强能运行 35B A3B,但我想要一个运行起来相对轻松的模型),使用的命令是:llama serve --flash-attn on --cache_type-k q8_0 --cache-type-v q8_0 --hf-repo ornith-ai/Ornith-1.5-9B-GGUF --spec-draft-p-min 0.9 --spec-type draft-mtp。这样得到的文本生成(TG)速度约为 15 tok/s,提示词处理(PP)速度约为 200 tok/s。然而,不使用 MTP 时,这两项速度都能达到两倍。我的草稿接受率很高,达到 0.95,平均长度为 2.27。顺便说一下,我用的是一张 8 GB 显存的 RTX 4060,不过我觉得这与问题无关。我注意到,使用 MTP 时,显存带宽利用率和 GPU 利用率都只有不使用 MTP 时的一半左右。
相似文章
llama.cpp MTP推测解码简化:2026年7月在密集模型上大获成功,MoE上表现平平
对llama.cpp中原生MTP推测解码的分析表明,像Qwen3.6-27B这样的密集模型获得了显著的加速(1.4倍至2.2倍),但在MoE架构上结果不尽人意,由于每步开销已经很低,收益微乎其微。
2倍 tok/s(在1块MI50上从19.4 tok/s提升到38.1 tok/s)尝试类似推测解码的假设……但不是用额外的侧模型,而是利用我可以同时运行多个计算,就好像内存里加载了两份Qwen3.6-27B一样——小量化不占用所有可用算力。
打包双推理(PTI)是一种通过单批解码中运行多个token序列来实现约2倍LLM吞吐量的技术,它利用了llama.cpp中的权重共享,无需草稿模型或额外VRAM。
MTP+GGML_CUDA_ENABLE_UNIFIED_MEMORY=1 - llama.cpp
一位用户在 llama.cpp 上使用 GGML_CUDA_ENABLE_UNIFIED_MEMORY=1 标志对令牌生成速度进行基准测试,比较启用和未启用 MTP(多令牌预测)时的性能。结果显示,在 RTX5090 上使用 Qwen3.6-27B 模型时,启用 MTP 后速度从 49 tok/s 显著提升至 64 tok/s。
如果你在好奇为什么Ornith 1.5 35B A3B MTP版本如此缓慢,原因在这里
Ornith 1.5 35B A3B模型的MTP张量似乎未被初始化,导致推测解码性能不佳。通过从Qwen3.6-35B-A3B移植训练好的头部,速度提升了29%。
LLaMA.cpp的多令牌预测(MTP)——Gemma 4速度提升40%
llama.cpp中新的多令牌预测(MTP)实现为Gemma 4模型带来了40%的速度提升,已在MacBook Pro M5Max上测试。文章提供了量化GGUF模型和补丁源代码的链接。