原贴链接

我看到不少人在讨论使用Mistral - 7B - Instruct - v0.3作为草稿模型来加速Mistral Large的推理，但有没有人实际对性能进行过基准测试呢？（另外，Bartowski的量化模型由于标记不匹配不能作为草稿模型。我看到有人说有解决办法，但没有关于如何实际操作该解决办法的说明，如果能在这方面提供帮助将非常感激！）我还对草稿速度和验证速度之间的权衡感到好奇。我的显存（VRAM）远不足以将Mistral Large卸载到GPU，我可能只能卸载30%的层。有人知道我是将草稿模型卸载到GPU并为此牺牲大型模型的几层更好，还是因为量化的7B模型在CPU上运行已经很快了，所以将草稿模型保留在CPU上，并尽可能多地将Mistral Large保留在显存中更好呢？我对推测性解码相当陌生，所以你们能提供的任何见解或分享的个人经验都会很有帮助。编辑：应该说明一下，我这里特指llama.cpp，以及最近给llama - server添加推测性解码的更新。我知道exllama的推测性解码支持，并且在那个后端标记不匹配似乎已经被修复。

讨论总结

该讨论主题为Mistral Large的推测解码。大家主要从草稿模型的使用、性能测试、速度提升、资源分配等方面展开讨论。其中包括不同量化的草稿模型在速度和接受率之间的权衡，不同模型（如Qwen）中最佳的草稿模型大小，不同配置下的模型速度，温度调整对推测性解码的影响，以及分布式操作的可行性等内容，整体讨论氛围比较和谐，都是基于技术分享各自的经验和见解。

主要观点

  1. 👍 在Mistral中使用低量化的草稿模型可节省显存。
    • 支持理由：低量化的草稿模型质量不影响输出，使用低量化可节省显存。
    • 反对声音：无
  2. 🔥 不同量化的草稿模型在速度和接受率之间有权衡。
    • 正方观点：不同用例需要尝试不同大小和量化的草稿模型，小草稿模型速度和接受率有平衡关系。
    • 反方观点：无
  3. 💡 在Qwen模型里1.5B作为草稿模型可达到速度和准确性的最佳平衡。
    • 解释：在Qwen模型中，0.5B虽然速度快但准确性差，1.5B在速度和准确性上平衡最佳。
  4. 💡 在特定硬件条件下使用Mistral Large时，有无草稿模型的处理速度不同。
    • 解释：如在exl2特定硬件下，无草稿模型每秒处理10 - 12个token，有草稿模型约为20个token。
  5. 💡 要得到可工作的预测标记数量需要降低温度或用确定性采样器。
    • 解释：有人测试发现，在特定情况下降低温度或用确定性采样器可得到更多预测标记数量。

金句与有趣评论

  1. “😂 Lissanro：The specific draft model I am using is [https://huggingface.co/turboderp/Mistral - 7B - instruct - v0.3 - exl2/tree/2.8bpw] \- I did not notice better speeds with higher quants, and the draft model quality does not affect the output anyway, this is why I am using such a low quant to save VRAM.”
    • 亮点：直接指出使用特定草稿模型时高量化未带来更好速度，低量化可节省显存的原因。
  2. “🤔 DeltaSqueezer：I’ll add that sometimes you need to experiment with different sizes/quants for your use cases as there’s a tradeoff between speed of a smaller draft model vs the acceptance rate.”
    • 亮点：强调了针对不同用例需尝试不同大小和量化的草稿模型的必要性。
  3. “👀 Mart - McUH：I did it with CPU offload though (which is probably not intended use case) and then it was not worth it.”
    • 亮点：分享了在CPU卸载情况下进行相关操作的经验及结论。
  4. “🤔 Mart - McUH：In my case (but that was roleplay text generation) temperature played huge role with speculative decoding.”
    • 亮点：说明在角色扮演文本生成场景中温度对推测性解码有很大作用。
  5. “👀 supert：在exl2我使用Mistral Large在2或3个A6000s且PCIe3为6.5或3.5(?)bpw，没有草稿模型我得到10 - 12t/s，有草稿模型得到约20t/s。”
    • 亮点：给出了特定硬件条件下有无草稿模型时的处理速度数据。

情感分析

总体情感倾向比较积极和理性，大家都是在分享自己的经验和见解，没有明显的争执。主要分歧点较少，可能存在于一些技术细节上，例如不同人在不同场景下（如Qwen模型和Mistral模型）对草稿模型大小的选择，以及温度调整在不同场景下的作用等。这些分歧主要是由于不同的使用场景、硬件条件和个人经验导致的。

趋势与预测

  • 新兴话题：分布式操作在Mistral Large相关操作中的应用可能会引发后续讨论，尤其是在资源分配和设备利用方面。
  • 潜在影响：如果能在分布式操作方面取得突破，可能会提高Mistral Large在不同硬件条件下的使用效率，对于相关的文本生成和推理任务等领域可能会有积极的推动作用。

详细内容：

标题：关于 Mistral Large 的推测解码热门讨论

最近，在 Reddit 上有一个关于使用 Mistral-7B-Instruct-v0.3 作为 Mistral Large 加速推理模型的热门讨论。原帖作者对是否有人实际测试过性能、如何解决某些技术问题，以及在资源有限情况下如何优化模型配置等提出了疑问，该帖子获得了众多关注和大量的评论。

讨论的焦点主要集中在以下几个方面： 有人分享说 Lissanro 报告在 EXL2 上使用 Mistral Large 配合草案模型有良好的加速效果。比如，Lissanro 使用特定的草案模型https://huggingface.co/turboderp/Mistral-7B-instruct-v0.3-exl2/tree/2.8bpw，并表示草案模型质量不影响输出，低量化可节省 VRAM。DeltaSqueezer 补充说有时需要根据使用情况试验不同大小和量化的模型，因为在较小草案模型的速度和接受率之间存在权衡。 Terrible-Mongoose-84 分享了自己使用 exl2 的经历，在不同任务中速度有所不同，且上下文填充量会影响速度。 DinoAmino 讲述了使用 vLLM 和 INT8 量化的体验，提到输出不同和对准确性的担忧。 Mart-McUH 称在特定任务中温度对推测解码速度影响巨大，温度较低时接受和速度会提高。Lissanro 则表示应该找时间试验低温是否能提高速度。 u/Durian881 好奇以分布式方式进行是否可行。 supert 表示使用草案模型能提高速度，但 tabbyAPI 会出现锁定问题。

在讨论中，大家的共识是推测解码在一定程度上能提高性能，但在具体应用中需要根据任务和硬件条件进行各种优化和试验。特别有见地的观点如 Mart-McUH 对温度影响的详细阐述，丰富了对推测解码性能影响因素的理解。

总的来说，这次关于 Mistral Large 推测解码的讨论展现了技术探索中的多样性和复杂性，为相关研究和应用提供了有价值的参考。但仍需更多的实践和研究来找到最优化的解决方案。