原贴链接

嗨，大家好。我很好奇你们是否有使用推测解码的任何指标和/或定性结果可以分享。我的配置：6个NVIDIA RTX A4000。几个月来我一直在试用初稿模型。我日常使用的是Mistral Large 2407 4bpw，以Mistral 7b v0.3 4bpw作为初稿并启用了张量并行。我目前正在试用Llama3.3 70B 6bpw，以Llama 3.2 3B 8bpw作为初稿并启用了张量并行。到目前为止，与Llama3.3 70B带初稿模型相比，我更喜欢我的带初稿模型的Mistral Large。速度相当，最高可达约20t/s。这里有一些性能指标。我正在使用一个简单的bash脚本（https://github.com/strikeoncmputrz/LLM_Scripts/blob/main/TabbyAPI_Utils/load - model.sh）来与TabbyAPI交互。表格展示了不同模型（Llama3.3、Mistral Large）的参数、量化、上下文窗口、专家、显存、内存、最大t/s、命令等信息。

讨论总结

原帖作者分享了在特定硬件（6个NVIDIA RTX A4000s）下使用不同模型（Mistral和Llama）在推测解码时的性能指标，包括速度、显存占用等。评论者们从多个方面进行了讨论，如需要无推测解码的数字进行对比、对特定GPU上模型速度的疑惑、模型使用中的问题（如json schema破坏推测解码）、硬件平台相关（运行模型的平台、电源供应器）以及Tabby的稳定性等，整体氛围是基于技术层面的探讨与交流。

主要观点

  1. 👍 需要无推测解码的数字来对比性能
    • 支持理由：原帖仅给出推测解码下的性能指标，无此数字难以全面准确评估模型性能。
    • 反对声音：无。
  2. 🔥 对原帖作者在特定GPU上Mistral - large速度慢表示疑惑并推荐新的草稿模型
    • 正方观点：在4个3090上能达到近40t/s，原帖作者在更强大的GPU上却小于25t/s，所以推荐尝试新的草稿模型。
    • 反方观点：无。
  3. 💡 json schema破坏推测解码并导致切换到llama.cpp（尽管提示评估更慢）
    • 支持理由：个人使用中发现json schema会破坏推测解码，所以进行切换。
    • 反对声音：无。
  4. 😎 多种因素影响模型速度
    • 支持理由：如小模型不适合任务、填充上下文、张量并行等情况都会影响速度。
    • 反对声音：无。
  5. 🤔 A4000s比3090s速度慢但有其他优势
    • 支持理由：指出A4000s虽然速度慢，但便宜且耗电少。
    • 反对声音：无。

金句与有趣评论

  1. “😂 we need numbers without speculative decoding to be able to compare”
    • 亮点：直接指出原帖在性能对比上的不足，简单明了。
  2. “🤔 Why are you only getting < 25t/s on Mistral - large with a draft model on such powerful GPUs when can get almost 40t/s with it on 4x3090’s?”
    • 亮点：通过对比引发对原帖中模型速度的疑惑，吸引他人关注。
  3. “👀 I am using json schema a lot. But sadly it breaks speculative decoding.”
    • 亮点：分享自己使用中的技术问题，为讨论提供新的话题点。
  4. “😉 P.S. Try llama3.2 - 3b for your llama3.3 draft model :)”
    • 亮点：针对原帖作者的情况给出具体的推荐，具有一定的实用性。
  5. “💪 Super stable. I run it 24/7 as a systemd service.”
    • 亮点：与其他关于Tabby不稳定的讨论形成对比，展示不同的使用体验。

情感分析

总体情感倾向为中性，主要是技术交流与探讨。分歧点在于对原帖中性能指标完整性的看法以及在不同硬件上模型速度的差异等，可能的原因是大家从不同的使用场景和技术经验出发，并且原帖给出的信息引发了大家从不同角度进行思考与讨论。

趋势与预测

  • 新兴话题：可能会进一步探讨Tabby中模型独立使用的方式以及如何更好地优化模型速度。
  • 潜在影响：对使用TabbyAPI和相关模型的用户在性能优化、稳定性提升等方面有一定的参考意义，有助于改进使用方式和提高效率。