原贴链接

受[https://www.reddit.com/r/LocalLLaMA/comments/1flqwzw/qwen25_14b_gguf_quantization_evaluation_results/]启发，我决定在这些Qwen 2.5变体之间运行相同的MMLU - pro基准测试，以确定在我的GPU上执行小型编码任务时哪个模型效果最佳。我的6750xt有12GB显存，我想比较哪个模型能给我带来最好的结果/性价比。使用koboldcpp ROCM作为后端。|模型|大小|完成基准测试时间|结果| | - | - | - | - | |Replete - LLM - V2.5 - Qwen - 14b - Q5_K_M|10.2GB|4小时52秒|63.66| |Qwen2.5 - Coder - 7B - Instruct - Q8_0|8GB|40分钟56秒|41.44| |qwen2.5 - 7b - ins - v3 - Q8_0|8GB|1小时12分钟35秒|52.44|。看来在这种情况下，参数越多越好的普遍共识也是适用的。在测试过程中我发现一个有趣的现象，很多时候模型会不停地胡言乱语，直到达到2048个最大输出标记。例如：the answer is (F)会一直重复直到达到最大值。我想如果模型不出现这种情况，完成基准测试的时间会更短，但我想也只能这样了。我原本计划测试更多模型（gemma，phi，llama 3.1，mistral等）来比较它们的表现，但考虑到需要投入的时间，我就做到这儿了。欢迎大家分享对这些结果的看法。配置文件

讨论总结

原帖作者对Qwen 2.5不同变体进行MMLU - pro基准测试，对比它们在小编码任务中的表现，分享了测试结果，包括不同模型的大小、完成测试时间和结果等。评论者从不同角度进行讨论，有从测试方法角度建议原帖作者采用特定批处理方法的，有分享自己比较Qwen 2.5不同参数版本结果的，还有针对原帖中模型“rambling”现象给出解释并提出建议的，也有对模型量化表示关注和好奇的，整体氛围积极且充满技术交流。

主要观点

  1. 👍 原帖测试模型时应采用特定批处理方法
    • 支持理由：原帖测试得出的时间结果差，采用这些方法可改善
    • 反对声音：无
  2. 🔥 比较Qwen2.5不同参数版本后发现参数越大编码能力越强
    • 正方观点：通过自己的比较实验得出该结论
    • 反方观点：无
  3. 💡 AMD设备上GPU内存不足会导致模型“rambling”
    • 解释：根据自身经验及对AMD设备的了解得出该结论，同时给出了减少上下文或使用更小量化的建议
  4. 💡 原帖中的性能表现不佳
    • 解释：评论者在3060 12Gb卡上得到了更好的结果，以此说明原帖性能差
  5. 💡 好奇大模型在低比特时具有哪些优势
    • 解释：对模型量化技术方面感兴趣，看到帖子中同一模型的4位和2位比较后产生好奇

金句与有趣评论

  1. “😂 我认为你需要使用vllm、aphrodite - engine、mlc - llm或其他批处理方法来测试模型。”
    • 亮点：直接指出原帖测试方法的改进方向
  2. “🤔 我自己比较了Qwen2.5 7b coder、14b instruct、32b instruct和72b instruct，给它们相同的编码任务，我也注意到，仅仅通过增加参数大小，模型在编码方面就变得更好了。”
    • 亮点：分享自己的测试经验得出关于Qwen2.5参数与编码能力关系的结论
  3. “👀 The rambling typically happens on AMD when the GPU runs out of memory.”
    • 亮点：对原帖中模型“rambling”现象给出可能的原因解释

情感分析

总体情感倾向是积极的，大家主要在进行技术交流和分享。主要分歧点较少，只是在原帖测试结果的好坏上有不同看法，可能是因为大家使用的设备、测试方法等不同导致对结果有不同评价。

趋势与预测

  • 新兴话题：模型在低比特时的优势情况可能会引发后续讨论。
  • 潜在影响：如果关于模型量化、性能优化等讨论深入，可能会对相关人工智能模型的使用和发展产生积极影响。

详细内容：

《关于 Qwen 2.5 不同变体的基准测试讨论》

在 Reddit 上，有一篇关于 Qwen 2.5 不同变体基准测试的帖子引发了热烈讨论。该帖子旨在比较这些变体在小型编码任务中的表现，作者在 6750xt 显卡（具有 12GB VRAM）上使用 [koboldcpp ROCM]作为后端进行了测试，并提供了详细的测试结果。帖子获得了众多关注，评论数众多。

测试结果显示，在模型大小、完成基准测试的时间和最终结果等方面存在差异。比如，Replete-LLM-V2.5-Qwen-14b-Q5_K_M 为 10.2GB，耗时 4 小时 52 秒，结果为 63.66；Qwen2.5-Coder-7B-Instruct-Q8_0 为 8GB，耗时 40 分钟 56 秒，结果为 41.44；qwen2.5-7b-ins-v3-Q8_0 为 8GB，耗时 1 小时 12 分钟 35 秒，结果为 52.44。作者发现测试中模型有时会不停地胡言乱语直到达到最大 2048 输出令牌。

讨论的焦点主要集中在以下几个方面： 有人认为需要使用 vllm、aphrodite - engine、mlc - llm 或其他批处理方法来测试模型，以改善测试时间。但也有人表示 kobold 简单易用，不希望处理复杂的安装过程。还有人指出在 AMD 上，当 GPU 内存不足时会出现胡言乱语的情况，应减少上下文或使用更小的量化。

有人分享道：“我自己前几天比较了 Qwen2.5 7b coder、14b instruct、32b instruct 和 72b instruct，通过给它们相同的编码任务，我也注意到仅仅增加参数大小，模型的编码能力就会变得更好。”

也有人提出：“从信息论的角度来看，我高度怀疑这是可能的。我们已经很擅长对模型进行量化。大多数模型在低于 4 位时开始表现得非常糟糕。似乎这是某种最优的信息密度/熵，可能不容易解决。”

讨论中的共识是更多的参数通常意味着模型表现更好。特别有见地的观点是关于不同量化方式对模型性能的影响以及在不同硬件上的表现差异。

总的来说，这次关于 Qwen 2.5 不同变体的基准测试讨论为我们深入了解模型性能和优化方法提供了丰富的思路和参考。