TurboQuant 与 MTP：Qwen 本地推理加速实测

本周 r/LocalLLaMA 上最受关注的技术讨论集中在 TurboQuant 和 Multi-Token Prediction（MTP）的性能对比上。社区在两条高互动量帖子里展开了围绕量化质量和加速效率的深度辩论。

一条热度 559 的帖子报告了 llama.cpp 的一个分支版本为 Qwen 3.6 27B/35B 的 GGUF 模型添加了 MTP 和 TurboQuant 支持。在 MacBook Pro M5 Max 上，MTP 将吞吐量从 21 tok/s 提升到 34 tok/s，增幅约 62%，声称 MTP 接受率高达 90%。代码已开源在 AtomicBot-ai/atomic-llama-cpp-turboquant 仓库中。

但评论区迅速出现了质疑声音：多名用户指出之前提交到 llama.cpp 主分支的 TurboQuant PR 被拒绝了，原因是现有的 Q4 KV 量化旋转方案在多数场景下已经更快或有竞争力。一位技术用户明确表示 TurboQuant 实际上只在 Q3 级别才有意义——而那个级别下质量劣化已经是显著问题。有人甚至声称在实际使用中 TurboQuant 比 FP16、Q8 和 Q4 都慢，建议直接使用 MTP 而不加 TurboQuant 获取速度，用标准 Q4_1/Q4_0 获取上下文效率。

另一条热度 298 的帖子是对 TurboQuant 进行的 vLLM 基准研究，结论更为系统化：FP8 KV-cache 量化（通过 --kv-cache-dtype fp8）仍然是生产环境的最佳默认选择——它提供约 2 倍的 KV-cache 容量，精度损失可忽略，且可以利用硬件原生的 FP8 attention。而 TurboQuant 的 k8v4 变体在存储压缩上的额外收益有限（2.4× vs 2×），但延迟和吞吐量更差；4bit-nc 只在严重内存受限时才可接受；k3v4-nc/3bit-nc 会显著损害推理和长上下文精度。

研究还引用了一篇技术说明（arXiv:2604.19528），声称 TurboQuant 在大多数内积估计、最近邻搜索和 KV-cache 设置中都不如 RaBitQ，且多个 TurboQuant 的运行时和召回率结果无法通过已发布的实现复现。评论区的主流观点是 "4bit-nc 仅在显存严重受限时可以考虑"，甚至有用户表示连 FP8 的劣化都不值得接受，宁愿保持未量化的 KV cache。

另一边，与 TurboQuant 形成鲜明反差的是 MTP 的确定性收益。Daniel Han 报告称 Qwen 3.6 的 MTP GGUF 模型在 llama.cpp 新增 --spec-draft-p-min 0.75 参数后，加速比从两天前的 1.4 倍跃升至 1.8 倍。

@danielhanchen: "Qwen3.6 MTP Unsloth GGUFs now run 1.8x faster, increased from 1.4x just two days ago! This is due to llama.cpp adding --spec-draft-p-min 0.75! Also increase --spec-draft-n-max 2 to 6."

综合来看，社区正在形成这样的共识：MTP 带来的加速是可靠且明显的，而 TurboQuant 的质量/速度权衡仍然高度依赖使用场景和量化级别，不宜作为通用默认配置。

分类：🔓 开源项目

本作品采用《CC 协议》，转载必须注明作者和本文链接