原贴链接

嗨，使用3个P40设备的伙伴们。我构建了最新的llama.cpp以利用llama - server上的推测解码功能。我正在运行qwen2.5_instruct 32b_q8模型以及qwen2.5_instruct 3b_q8作为草稿模型（抱歉，昨晚我的路由器坏了，所以我没有正在运行的确切命令行）。但我也开启了Flash Attention并设置为split - mode row。所有层都卸载到GPU上，上下文设置为90000。我注意到在使用草稿模型时，当提示约为2000个令牌时，速度从每秒约12个令牌下降到9个。我尝试了草稿模型最大和最小值的不同设置（例如最大为16，最小为3）。我还没有找到一个能达到不使用草稿模型时性能的设置。我不想在这上面投入太多时间，因为以前的性能已能满足我的需求。只是想知道大家在使用P40设备进行llama.cpp推测解码方面的经验。我原本预期模型与草稿模型10:1的比例会带来一些速度提升。如果有人有一个好的命令来对有和没有推测解码的llama - server进行基准测试，请告诉我。谢谢。

讨论总结

原帖围绕3个P40运行llama.cpp时，在推测性解码下是否有速度提升展开讨论。评论者们从不同角度给出回应，包括分享自己的设备使用经验、给出优化建议、进行相关的基准测试结果分享，整体氛围积极，大家都在努力为原帖作者解答疑惑或者提供有用的信息。

主要观点

  1. 👍 尝试默认split - mode和0.5b模型来优化性能
    • 支持理由：原帖作者在使用P40运行llama.cpp时遇到性能问题，这可能有助于解决。
    • 反对声音：无。
  2. 🔥 不同大小的Qwen 2.5模型使用不同词汇集
    • 正方观点：这是通过实际使用和研究得出的结果。
    • 反方观点：无。
  3. 💡 在P40上使用推测性解码有10 - 14%的速度提升
    • 解释：这是segmond根据自己的经验得出的结论，直接回答了原帖的问题。
  4. 💡 1个P40在特定设置下（温度设置为0.1，使用0.5b草稿模型处理简单查询）有令牌处理速度的大幅提升
    • 解释：TheTerrasque通过自己的测试发现这一现象。
  5. 💡 量化缓存会降低性能
    • 解释：有评论者通过测试发现使用--cache - type - [k/v]量化缓存会大幅降低性能。

金句与有趣评论

  1. “😂 Maybe try with default split - mode and 0.5b model.”
    • 亮点：这是AdamDhahabi针对原帖性能问题给出的一个简洁直接的建议。
  2. “🤔 Eisenstein: I ran some benchmarks using Llama 3.1/3.2 with Koboldcpp 1.79.1 which uses a different speculative decoding implementation than llamacpp (how different, I don’t know), and I saw significant improvements in generation time.”
    • 亮点：Eisenstein分享了不同实现下的基准测试结果，为讨论提供了新的参考。
  3. “👀 TheTerrasque：I only have 1xP40, but setting temperature to 0.1 (using 0.5b draft model) turned tokens per second on fairly simple queries (like "make snake in python") from 12 to 25 - 55 tokens per second.”
    • 亮点：这个评论揭示了温度设置对令牌处理速度的显著影响，是比较意外的发现。
  4. “💡 segmond: I see about 10 - 14% speed up with speculative decoding on p40’s.”
    • 亮点：直接回答了原帖关于速度提升的疑问。
  5. “🤔 作为追问问题，对于草稿模型哪些量化是“最快”的呢？”
    • 亮点：提出了一个新的思考方向，引发更多关于草稿模型性能优化的讨论。

情感分析

总体情感倾向是积极的，大家都在积极分享经验、提供建议和回答问题。主要分歧点较少，可能是因为这个话题相对比较技术向，大家基于自己的测试和研究成果进行交流，比较理性。

趋势与预测

  • 新兴话题：关于草稿模型最快的量化方式的讨论可能会引发后续讨论。
  • 潜在影响：如果能确定更优的量化方式、配置等，对于使用P40运行llama.cpp等相关场景的性能提升有实际的指导意义，可能提高相关技术在该领域的应用效率。

详细内容：

标题：关于在 3x P40 上运行 llama.cpp 与推测解码的热门讨论

最近，Reddit 上有一个关于在 3x P40 上运行 llama.cpp 并利用推测解码的热门帖子引起了广泛关注。该帖子获得了众多点赞和大量评论。

原帖作者称自己构建了最新的 llama.cpp 以利用推测解码，在运行 qwen2.5_instruct 32b_q8 作为模型和 qwen2.5_instruct 3b_q8 作为草案模型时，发现使用草案模型后，速度从约 12 个令牌/秒（提示约 2000 个令牌时）降至 9 个。作者尝试了不同的草案模型设置，但未找到能达到不使用草案模型时性能的设置，并询问大家在 P40 上使用推测解码的经验，还希望有人能提供一个好的基准测试命令。

讨论焦点主要集中在不同用户分享的提升性能的方法和个人经验。有人提出可以尝试默认的分割模式和 0.5b 模型，并且指出 KV 缓存量化可能影响速度。还有用户提到不同大小的 Qwen 2.5 模型使用不同的词汇集。

有用户分享道：“我使用 Qwen2.5 32B Q4KM 主模型和 1.5B Q4KM 草案模型，在单个 P40 上获得了超过 30%的性能提升。”还有用户表示自己做了大量测试，写道：“我使用 llama-swap 定义不同的配置，并使用循环和 curl 测试变化。我在迭代时还去喝了杯咖啡。”

对于不同配置的效果，有人认为温度设置为 0.1 时，简单查询的每秒令牌数从 12 提升到 25 - 55 个。也有人指出 Q4_0 是 P40 上最快的量化方式。

讨论中的共识在于通过不同的设置和测试，能够在一定程度上提升 llama.cpp 在 P40 上的性能，但具体效果因使用情况和配置而异。

特别有见地的观点如使用不同的模型组合和参数设置能够带来显著的性能提升，丰富了整个讨论。

总之，这次关于在 3x P40 上运行 llama.cpp 与推测解码的讨论为大家提供了丰富的经验和方法，但仍需要根据自身情况进行测试和优化。