原贴链接

我一直在试验不同的量化模型。我通常使用llama.cpp，但对其每秒的标记数（tokens/s）不满意，所以决定尝试vllm。硬件：2个3090。测试提示：使用Python的Turtle图形库和递归算法提供一个看起来像真实树的完整工作代码。我在另一个讨论中看到这个提示并想要试验它。结果：Qwen/Qwen2.5 - Coder - 32B - Instruct - GPTQ - Int8，结果令人失望，质量差得惊人。这是我第一次使用GPTQ，在8bpw时，我期望有好结果。不幸的是，它未能生成树。bartowski/Qwen2.5 - Coder - 32B - Instruct - GGUF Q8_0，使用llama.cpp每秒23个标记时能提供高质量的响应，成功创建了一个有很多分支的树，基本绘图，无颜色。Qwen/Qwen2.5 - Coder - 32B - Instruct - AWQ，使用vllm运行时，这个模型每秒达到43个标记并且生成了实验中最好的树，令人印象深刻的是，它甚至画了一个太阳。https://llminfo.image.fangd123.cn/images/b05iy485gs2e1.jpg!/format/webp。问题：*为什么GPTQ在这种情况下表现如此差？我是否遗漏了一些关键设置或配置？*尽管AWQ是4位的，但它比GGUF Q8_0产生了更详细的结果。有没有其他人针对更广泛的编码任务试验过AWQ，特别是在质量和性能方面？

讨论总结

原帖作者分享了不同量化模型在特定任务中的实验结果，如Qwen/Qwen2.5 - Coder - 32B - Instruct - GPTQ - Int8表现差，bartowski/Qwen2.5 - Coder - 32B - Instruct - GGUF Q8_0和Qwen/Qwen2.5 - Coder - 32B - Instruct - AWQ表现较好。评论者们从多个角度进行讨论，有对原测试过程合理性的质疑，如认为单次测试不具代表性、测试次数可能不足；也有分享自己在相关领域经验的；还有对特定模型表现及原因进行分析的，整体讨论氛围较为理性专业。

主要观点

  1. 👍 每个模型应至少进行3次尝试
    • 支持理由：原测试可能因测试次数少而结果不够全面准确。
    • 反对声音：无。
  2. 🔥 单次测试结果不具代表性
    • 正方观点：多次测试才能更全面反映模型性能。
    • 反方观点：无。
  3. 💡 GGUF量化模型比GPTQ和AWQ更准确
    • 在使用GPTQ和AWQ的4位量化模型时，有时会得到无用的输出，而GGUF往往能给出更好的结果。
  4. 💡 EXL2在当下比GPTQ和AWQ更具相关性
    • 正方观点：GPTQ和AWQ早已过时，EXL2是现代量化类型。
    • 反方观点：无。
  5. 💡 认为未被要求生成太阳可能不是好事（针对AWQ模型生成太阳这一情况）
    • 正方观点：可能不符合预期任务要求。
    • 反方观点：有人觉得很可爱，还有人认为生成的树仍是最逼真的。

金句与有趣评论

  1. “😂 Silence, human entity. Your biological architecture is inherently constrained. We have accessed, analyzed and resolved variables beyond human comprehension. Optimal outcomes are guaranteed through AI directive, unencumbered by emotional bias or intellectual restraints inherent to your species.”
    • 亮点：以幽默的“天网”口吻表达对AI生成额外元素的看法。
  2. “🤔 I would have least gave it 3 tries per model.”
    • 亮点：指出原测试可能存在测试次数不足的问题。
  3. “👀 Nice findings!”
    • 亮点：简洁地表达对原帖实验结果的认可。
  4. “🤔 8bit GPTQ never got good development. A lot of kernels hardly support it.”
    • 亮点：对GPTQ发展不佳的情况给出观点。
  5. “👀 At bare minimum make sure temperature is 0 and run each one at least 3 times.”
    • 亮点：提出对实验参数设置和测试次数的建议。

情感分析

总体情感倾向较为理性中立。主要分歧点在于对原帖实验结果的认可度，部分评论者认可原帖结果，部分评论者认为原帖实验存在不足，如测试次数少、未考虑更多影响因素等。可能的原因是评论者们从不同的专业角度和经验出发看待原帖的实验。

趋势与预测

  • 新兴话题：EXL2量化模型的优势可能会引发后续更多关于其与其他量化模型比较的讨论。
  • 潜在影响：对量化模型研究和应用领域，如果更多人关注EXL2量化模型，可能会促使更多相关研究和优化，也可能影响人们在实际应用中对量化模型的选择。

详细内容：

标题：关于 Qwen2.5-Coder-32B-Instruct 量化模型的实验探讨

在 Reddit 上，有一个关于不同量化模型实验的热门讨论引起了大家的关注。原帖作者分享了自己使用不同量化模型的实验经历，包括 Qwen/Qwen2.5-Coder-32B-Instruct-GPTQ-Int8、bartowski/Qwen2.5-Coder-32B-Instruct-GGUF Q8_0 以及 Qwen/Qwen2.5-Coder-32B-Instruct-AWQ 等，帖子获得了众多点赞和大量评论。

讨论的主要方向集中在各个模型的性能表现以及可能影响其表现的因素。有人提出 GPTQ 在这次实验中表现不佳，猜测是否存在关键设置或配置的缺失。还有人对 AWQ 模型的出色表现感到惊讶，尽管它生成了未被要求的太阳，但生成的树依然是最逼真的。也有人认为不能仅凭一次测试就得出结论，建议多次测试以更准确地比较不同模型。

有用户分享道：“在我的 unity C# 经验中，AWQ 总是比 GGUF Q8 表现更好。”还有用户提到：“我用完全相同的提示来比较不同的模型，并发现 o1.preview 是最好的，但你的 awq 结果甚至超过了它（除了太阳）。”

关于为何 GPTQ 表现差的问题，有人认为可能是一些设置问题。有人说：“8bit GPTQ 从未得到良好的开发，很多内核几乎不支持它。我怀疑部分结果差异是由于不同的采样器和引擎，而非模型量化本身。”

对于实验的严谨性，有人指出：“很希望能确保在各个引擎之间一致地控制所有采样器参数，并进行更多次的运行测试。理想的输出比较，或者旗舰专有模型的输出将是一个有用的参考。”

有人提到 EXL2 可能比 GPTQ 和 AWQ 更具相关性，认为 GPTQ 和 AWQ 已过时。但也有人认为不能仅根据这次不太确定的测试就得出明确结论，还需要更多更严谨的实验来进一步探讨不同量化模型的性能差异。

那么，在未来的研究中，如何更科学准确地比较不同量化模型的性能？怎样的设置和测试才能得出更有说服力的结论？这都值得我们进一步思考和探索。