一个 llama.cpp PR 让 Q2_0 在 x86 CPU 上提速 3.0–3.6 倍，8B 解码从 2.39 升至 8.20 tok/s

Reddit r/LocalLLaMA 工具
llama-cpp q2-0 vnni x86 performance quantization

摘要

一个 llama.cpp 拉取请求为 Q2_0 × Q8_0 点积添加了 x86 VNNI 实现，在 Bonsai 模型上实现了 3.0–3.6 倍的纯 CPU 加速，内核级逐位精确，且 token 一致性达 99.2%。

我浏览了当前 llama.cpp 的 CPU PR，其中 #26348 很突出，因为这不是常见的 +5% 内核优化。它为 Q2_0 × Q8_0 点积添加了 x86 VNNI 实现，作者控制的纯 CPU 基准测试显示，从 1.7B 到 27B 的 Bonsai 模型吞吐量大约提高了 3–3.6 倍。 设置： - AMD EPYC 9645 - 8 个 CPU 核心 - 仅 CPU - GGML_NATIVE=ON - 启用 OpenMP - 禁用 BLAS - -t 8 -ngl 0 -fa off - 预热后运行 3 次 - group-64 Q2_0 Bonsai GGUFs 结果： 1.7B pp512: 14.07 → 50.47 tok/s (3.59x) tg128: 10.22 → 33.28 tok/s (3.26x) 4B pp512: 5.41 → 19.40 tok/s (3.59x) tg128: 4.45 → 13.36 tok/s (3.00x) 8B pp512: 2.82 → 10.26 tok/s (3.64x) tg128: 2.39 → 8.20 tok/s (3.43x) 27B pp128: 0.79 → 2.85 tok/s (3.59x) tg32: 0.72 → 2.37 tok/s (3.32x) 27B 的基线显然太慢，一次 pp128 推理几乎花了 3 分钟。 实际改动其实很小：现有 Q2_0 点积获得了一条使用 AVX-VNNI / AVX-512 VNNI 的路径，而不是依赖通用实现。这个改动所基于的 Prism 参考实现还暴露了普通消费级 Intel CPU 上的一个有趣问题。在 i5-13400 上，Q2_0 会静默地缺失快速路径，因为 12 至 14 代 Intel CPU 拥有 AVX-VNNI，但 AVX-512 被禁用（fused off）。没有任何提示告诉用户发生了这种情况，只会让人觉得 Q2_0 极其缓慢。 他们控制的 i5-13400 A/B 测试： Ternary-Bonsai-8B Q2_0 decode: 2.17 → 6.92 tok/s prompt eval: 2.7 → 8.6 tok/s 同样是大约 3.2 倍，得益于 VNNI 路径。 这里有一些重要的注意事项： - 上游 llama.cpp PR 仍处于开启状态，尚未合并 - 这特指 Q2_0，并不意味着 Q4/Q5 等也能免费获得 3 倍加速 - 上游主要基准测试是在 EPYC 上仅使用 8 核 - i5-13400 的结果来自 Prism 参考实现，而非精确的 group-64 上游 PR - 融合乘加（FMA）行为会带来微小的数值差异 在正确性方面，作者报告了 14,000 次随机对比在内核级别上逐位完全匹配。在困惑度冒烟测试中，两个版本在 99.216% ± 0.554% 的情况下选择了相同的 top token，KLD 差异非常小。 这正是我希望看到在普通消费级硬件上测试的 llama.cpp 优化类型，而不是又拿服务器 CPU 来测。如果你有 Alder/Raptor Lake 或 Zen 4/5 处理器，并且能编译该 PR 分支，请发布你的 llama-bench 前后对比结果。尤其关注笔记本电脑：3 倍加速是否能经受住功耗/内存带宽限制，还是在真实硬件上大幅缩水？
查看原文

相似文章

Llama.cpp PR 带来 8% 速度提升

Reddit r/LocalLLaMA

一个 llama.cpp PR 将采样从 CPU 移至 GPU，在 RTX 5090 上为 Qwen3.6-35B 推理带来 8% 的 token 速度提升，在 Tesla P40 上约为 4%。