原贴链接

qwen - 2.5 - coder - 32B在单个3090上的性能从每秒34.79个令牌提升到51.31个令牌。多种模型有25% - 40%的性能提升。qwen - coder - 32B在不同GPU下的性能差异（列出了P40、3xP40、3090下之前和之后的每秒令牌数以及速度提升倍数）。使用nemotron - 70B和llama - 3.2 - 1B作为草稿模型在3xP40上也有速度提升，从每秒9.8个令牌提升到12.27个令牌（1.25倍提升）。参考链接：https://github.com/ggerganov/llama.cpp/pull/10455

讨论总结

该讨论围绕llama.cpp服务器中投机解码带来的速度提升展开。大家分享了在不同硬件、不同模型下的测试结果和体验，也提出了很多关于技术原理、适用范围、性能影响因素等方面的疑问，还有人对相关技术的发展提出期望，如增加对多模态的支持等，整体氛围积极且充满技术探讨氛围。

主要观点

  1. 👍 对llama.cpp服务器速度提升感到兴奋
    • 支持理由：如qwen - 2.5 - coder - 32B性能提升明显等数据支撑，以及能为相关应用升级带来便利。
    • 反对声音：无。
  2. 🔥 GGUF与exl2的速度比较存疑
    • 正方观点：有用户给出不同模型在不同GPU下的速度数据表明两者有差异。
    • 反方观点：也有用户指出之前测试可能存在未开启投机解码等影响结果的情况。
  3. 💡 推测解码在Apple Silicon上速度未提升反而下降
    • 解释：可能是Apple Silicon不受内存限制，以及推测解码本身存在缺陷等原因。
  4. 👍 对EXL2表示积极态度
    • 支持理由：未提及。
    • 反对声音：无。
  5. 🔥 利用性能提升需同时运行主模型和“草稿”模型
    • 正方观点：两个模型能同时放入显存可看到性能提升等原理说明。
    • 反方观点：无。

金句与有趣评论

  1. “segmond: woot woot, as you all can see by my flair. I’m team llama.cpp”
    • 亮点：表达对llama.cpp的强烈支持。
  2. “No - Statement - 0001: I was frustrated waiting for the ollama team to implement capabilities that llama.cpp’s server already supported.”
    • 亮点：体现出对ollama团队未实现llama.cpp已支持功能的不满。
  3. “Sky_Linx：I just gave it a go, and it seems a bit slower on Apple Silicon compared to the other setup.”
    • 亮点：提出与速度提升相反的测试结果，引发后续讨论。
  4. “CoUsT：Can someone briefly explain how do you "speculate" on the next tokens/words?”
    • 亮点：反映出很多用户对推测解码原理的疑惑。
  5. “Mart - McUH：How about token distribution though? I can see this being useful if you do deterministic (eg TOPK = 1) sampler. But I would be worried that when we want variety, then the small (draft model) would suggest tokens which might still pass (in large model with preferred sampler) but would normally be low probability and now they might become top choices (because small model prefers them and does not predict the actual top choices of large model).”
    • 亮点：深入思考了新机制下标记分布可能存在的问题。

情感分析

总体情感倾向是积极的，大家对llama.cpp服务器中投机解码带来的速度提升基本持正面态度。主要分歧点在于一些技术问题，如GGUF与exl2的速度比较、推测解码在某些硬件上速度未提升等。可能的原因是不同用户的测试环境、使用的模型以及对技术的理解程度不同。

趋势与预测

  • 新兴话题：如模型配对情况、理想草稿模型大小等新话题可能引发后续讨论。
  • 潜在影响：如果相关技术不断发展完善，可能会对自然语言处理领域的模型推理速度、资源利用效率等方面产生积极影响，推动相关应用的发展。

详细内容：

标题：Llama.cpp 中引入推测解码带来显著性能提升，引发热烈讨论

近日，Reddit 上一则关于“Speculative decoding just landed in llama.cpp’s server with 25% to 60% speed improvements”的帖子引起了广泛关注。该帖子指出，qwen-2.5-coder-32B 在单张 3090 显卡上的性能从 34.79 令牌/秒提升到了 51.31 令牌/秒，不同模型均有 25%至 40%的性能提升，并提供了详细的性能对比数据。此帖获得了极高的关注度，引发了众多用户的热烈讨论。

讨论的焦点主要集中在推测解码的工作原理、适用场景、对不同硬件和模型的影响，以及可能存在的问题等方面。

有人认为，推测解码的优势在于充分利用 GPU 的并行处理能力。比如，小型模型能够快速生成多个令牌，大型模型则同时对这些令牌进行验证和处理，从而提高处理速度。

但也有人提出疑问，如“如何对下一个令牌进行推测？”“这种方式是否会降低大型模型的计算量？”

在个人经历和案例分享方面，有人表示在苹果硅上的测试结果不太理想，而另一些人在不同的硬件配置和模型组合下取得了显著的速度提升。例如，[CockBrother] 在不同的模型和硬件组合下，性能提升幅度从 82%到 359%不等。

关于推测解码的适用性，有人指出在内存带宽受限的情况下效果较好，而在苹果硅等并非严重依赖内存带宽的硬件上可能效果不明显。

对于不同模型的配合，有人认为小型草案模型需要与大型主模型有一定的相似性，否则效果不明显。

同时，也有人探讨了推测解码对 VRAM 使用、模型量化以及多 GPU 配置的影响。

总之，关于 Llama.cpp 中的推测解码，讨论展现了其在提高性能方面的潜力，但也存在一些尚待解决的问题和需要进一步探索的方面。