原贴链接

大家好。我受到了u/No - Statement - 0001的这篇帖子（https://www.reddit.com/r/LocalLLaMA/comments/1h5uq43/llamacpp_bug_fixed_speculative_decoding_is_30/）的很大启发（llama.cpp漏洞修复！推测解码速度提高30%，上下文大小变为2倍：r/LocalLLaMA）。我也有一块RTX 3090，并且从几天前开始就正好在使用相同的模型（对于开源来说很棒的模型）。之前，我的机器上每秒大约能得到35个令牌。按照那篇帖子中的建议操作后，在预热后平均每秒能得到约50个令牌。这是使用Qwen2.5 - Coder - 32B和0.5B模型进行草稿（drafing，此处应为drafting）。这是不错的性能，但老实说，我期望的更高。以下是我采取的步骤：1. 直接从仓库拉取LLama.cpp - 我猜是主分支。2. 使用以下命令从源代码编译LLama.cpp：* cmake - B build - DGGML_CUDA = ON - DGGML_CUDA_FA_ALL_QUANTS = ON（为了启用CUDA并包含KV缓存的所有量化类型https://github.com/ggerganov/llama.cpp/blob/master/docs/build.md）* cmake – build build – config Release。3. 大约2个小时左右后，llama - serve构建完成。完成这些之后，我一直在使用以下参数运行：./llama - server * – flash - attn * – slots * – model /models/qwen2.5 - coder - 32b - instruct - q4_k_m.gguf * – device CUDA0 * – model - draft /models/qwen2.5 - coder - 0.5b - instruct - q8_0.gguf * - ngld 99 * – draft - max 16 * – draft - min 4 * – draft - p - min 0.4 * – device - draft CUDA0 * – ctx - size 20000 * – cache - type - k q8_0 * – cache - type - v q8_0 * – n - gpu - layers 65。我的系统运行的是Ubuntu 20.04（版本旧是有原因的）x64，我的3090插在PCI - E 3.0 16x插槽上。最后，这块GPU也作为操作系统的主GPU运行。这会限制它的速度吗？有什么办法可以调整设置来提高性能吗？我应该考虑哪些编译标志？更新：我将Ubuntu的主GPU换成了我也安装了的3060 TI。现在，3090上只运行着一个4mb的xorg进程 - 并且Gnome Shell进程在3060 TI上运行。性能没有任何变化。

讨论总结

原帖作者在RTX 3090上运行Llama.cpp时，虽按照之前帖子建议调整后性能有提升但未达预期，于是寻求进一步提高性能的方法。评论者们从不同角度给出建议，如模型选择、编译设置、草稿模型参数调整等，也有评论者分享自己在不同设备上的性能测试情况，包括性能未提升或下降的情况，大家都围绕提高Llama.cpp性能这一主题展开讨论。

主要观点

  1. 👍 尝试Q8的1.5b模型可能提高接受率。
    • 支持理由：可能与模型特性及提示内容相关。
    • 反对声音：无。
  2. 🔥 编译慢可能与MAKEFLAGS未设置 -j有关。
    • 正方观点：如果编译时间慢，很可能是此原因。
    • 反方观点：无。
  3. 💡 推测解码在某些情况下会使性能变差。
    • 解释：如评论者Eugr在自己的设备上测试发现性能下降。
  4. 💡 高令牌数依赖于草稿模型和主模型的匹配情况。
    • 解释：由评论者No - Statement - 0001提出，两者匹配度对性能有很大影响。
  5. 💡 将草稿模型从Q8改为Q4可提高推测速度。
    • 解释：评论者亲测在自己的双GPU配置下有速度提升。

金句与有趣评论

  1. “😂 Try the 1.5b model in Q8, it should give you a significant boost to the acceptance rate - depending on what you’re prompting for.”
    • 亮点：提出了可能提高性能的具体模型选择及影响因素。
  2. “🤔 如果编译时间慢，很可能是MAKEFLAGS中没有设置 -j。”
    • 亮点：指出编译慢可能的原因，给遇到类似问题的人提供思路。
  3. “👀 Eugr: In my case, the performance actually got worse when trying spec decoding.”
    • 亮点：提供了与其他评论不同的情况，即推测解码会使性能下降。
  4. “💡 Try my [run - benchmark.sh](https://github.com/mostlygeek/llama - swap/blob/main/examples/benchmark - snakegame/run - benchmark.sh) script and share your numbers.”
    • 亮点：为原帖主提供了测试性能的脚本建议。
  5. “👍 You could use tabbyapi and the exl2 versions of the models to get faster performance than a gguf”
    • 亮点：提出了一种提高性能的新方法。

情感分析

总体情感倾向积极，大家都在积极提供建议和分享自己的经验。主要分歧点在于不同设备和设置下性能提升或下降的情况不同，可能是由于设备硬件差异、模型参数设置不同以及编译环境的不同等原因造成的。

趋势与预测

  • 新兴话题：使用tabbyapi以及模型的exl2版本提高性能可能会引发后续讨论。
  • 潜在影响：如果找到有效的性能提升方法，将对使用Llama.cpp的用户有很大帮助，可能提高相关应用的运行效率，推动类似开源项目的优化和发展。

详细内容：

标题：关于优化 Llama.cpp 以实现最大令牌/秒数及相关讨论

在 Reddit 上，一篇题为“Tweaking Llama.cpp for maximum tokens/sec w/ speculative decoding”的帖子引发了热烈讨论。该帖获得了众多关注，评论众多。

原帖作者表示受到了 u/No-Statement-0001 的相关帖子启发，自己拥有 RTX 3090 并使用相同模型，之前机器每秒约 35 个令牌，按照那篇帖子的建议操作后，现在平均每秒能获得约 50 个令牌。作者详细介绍了采取的步骤，包括从 repo 直接拉取 Llama.cpp、使用特定命令编译、设置一系列参数等，并提出了自己的疑问，如系统中 3090 作为主 GPU 是否限制速度，如何调整设置以进一步提高性能，是否有应考虑的编译器标志等。

讨论焦点主要集中在以下几个方面： 有人建议尝试 1.5b 模型，降低“–draft-min”至 1 ，“–draft-max”至 8，并认为根据主模型速度，高质量草稿可能比快速草稿更可取。 有人提到如果编译时间慢，可在“MAKEFLAGS”中设置“-j”，或安装“ccache”加快未来编译速度。 有人分享了自己使用不同参数和模型的测试结果。比如，No-Statement-0001 重新运行基准测试，发现不同参数设置下 Python、typescript 和 swift 的表现有所不同。 也有人表示在自己的情况中，尝试特殊解码后性能反而变差了。 还有人分享自己在特定平台上的测试经历和结果。

其中，有人指出在 Windows 11 24H2 WSL 中使用 Ubuntu 24.04 LTS 和 RTX4090 测试的情况，尝试了不同模型和参数，结果并不理想。也有人表示在苹果芯片上未获得任何速度提升。

总体而言，关于如何优化 Llama.cpp 以提高性能，大家众说纷纭，尚无统一结论。但这些讨论为探索提高性能的方法提供了丰富的思路和参考。未来是否能找到更有效的优化方案，让我们拭目以待。