原贴链接

嗨。我打算确定新的Qwen 32B Coder模型是否比我之前用作编码助手的72B非编码变体表现更好。为了评估这一点，我通过让这两个大型语言模型（LLM）解决最新的力扣（Leetcode）问题进行了案例研究。为了更全面地进行基准测试，我还将GPT - 4o纳入了比较。

免责声明：虽然这是关于解决力扣问题的，但这个基准测试很难算是一个编码基准测试。这些问题中呈现的场景在现实生活中很少遇到，并且在大多数情况下（大约99%），你不需要编写如此复杂的代码。如果要说的话，我会说这个基准测试70%是推理，30%是编码。

image
https://preview.redd.it/r0mu8wqexu0e1.png?width = 3703&format = png&auto = webp&s = 03c70f18dc8e1de15d728011896d85308981134e

模型和硬件详情：

  • 本地测试（不包括GPT - 4o）使用vLLM进行。
  • 我使用vLLM推荐的方法（使用llmcompressor包进行在线动态量化）将两个模型从FP16量化为FP8。
  • 两个模型都使用32,768 - 个token的上下文长度进行测试。
  • 32B编码模型在单个H100 GPU上运行，而72B模型利用两个启用了张量并行的H100 GPU（虽然它可以在一个GPU上运行，但我希望与32B测试用例具有相同的上下文长度）

方法：其实没有什么特别的方法。我只是简单地将问题描述和初始代码块复制粘贴到模型中，在需要的地方进行小的修正（比如修正像107而不是10^7这样的拼写错误）。我最初选择不自动化这个过程，因为我不确定这样做是否值得。然而，如果对这个基准测试感兴趣并且希望添加更多模型或进行定期测试（可能每周一次），我将来可能会自动化这个过程。所有测试都使用Python语言完成。

我在结果表中包含了自己的评分系统，但你可以自由应用自己的标准，因为原始数据是可用的。

需要考虑的点：

  • 大型语言模型（LLM）在困难的力扣问题上通常表现不佳；因此，我排除了“困难”类别的问题，除了最后一个，它用来强化我的观点。
  • 如果没有一个模型成功解决中等难度的问题，我就不会进入后续阶段（因为一些力扣问题是多阶段的）。
  • 结果可能仍然受到SSS的影响。
  • 再次强调，这不是一个纯粹的编码基准测试。解决力扣问题需要更多的推理能力而不是编码熟练程度。

编辑：在我解释系数的表格中有一个拼写错误。最后一个应该是“困难问题”

讨论总结

原帖对Qwen 32B Coder - Ins和72B - Ins以及GPT - 4o在Leetcode问题上进行性能对比研究。多数评论者对原帖表示认可，一些评论者希望扩展比较的模型范围，如将14B和7B的编码器加入比较。也有评论者对原帖中的测试方式、工具使用、测试精度等提出疑问，还有人分享了自己在相关模型使用中的不同体验，整体讨论氛围较为积极且充满技术探讨性。

主要观点

  1. 👍 原帖中的测试内容不错，是频道所需要的类型
    • 支持理由：原帖对不同模型在Leetcode问题上的性能比较有一定参考价值。
    • 反对声音：无。
  2. 🔥 如果相同技能能被新技术容纳，成年人不应再苦刷LeetCode
    • 正方观点：新技术（如LLMs）能力强大，LeetCode与实际工作联系少。
    • 反方观点：有人认为这是无稽之谈，LeetCode测试仍有一定意义。
  3. 💡 在特定任务方面，编码模型应该比通用模型表现更好
    • 解释：原帖是模型比较情境，编码模型在特定任务上可能更具优势。
  4. 👍 Qwen - Coder - 32B在代码理解基准测试中优于Qwen - 72B且比Mistral - Large - 123B略好
    • 支持理由：基于评论者自己的基准测试得出。
    • 反对声音：无。
  5. 👍 认可原帖分享结果并推荐一个可能表现较好的模型
    • 支持理由：原帖结果可靠，推荐的模型在其他测试中有较好表现。
    • 反对声音：无。

金句与有趣评论

  1. “😂 infiniteContrast: Everyday i’m more and more surprised by how Qwen 32B Coder can be this good.”
    • 亮点：表达出对Qwen 32B Coder模型性能优秀的惊喜之情。
  2. “🤔 muchcharles: How new were those leetcode pproblems, were they in qwen’s training set?”
    • 亮点：对测试用的Leetcode问题的新颖性与模型训练集的关系提出疑问。
  3. “👀 LocoLanguageModel: 当我要求创建一个新方法并给出一些细节时，32b和72b似乎相当，并且32b更快，还留有更多的上下文空间，这很棒。”
    • 亮点：分享了在创建新方法时32b和72b模型的性能比较情况。
  4. “😂 Jesus, this is great. Did you manually do all of these when you say you "copy and pasted"?”
    • 亮点：对原帖作者手动进行模型对比测试的惊叹。
  5. “🤔 At this point, the question becomes what actually counts as "pure coding" and whether exclusively "pure coding" in an LLM would be any more useful than a syntax checker.”
    • 亮点：对原帖中提到的“纯编码”定义提出疑问并引发思考。

情感分析

总体情感倾向为正面，多数评论者认可原帖的测试内容。主要分歧点在于对LeetCode在如今技术背景下的作用，以及原帖测试中一些细节（如测试精度、测试方式等）的看法。可能的原因是评论者们来自不同的技术背景和使用场景，对模型性能评估有不同的侧重点。

趋势与预测

  • 新兴话题：对未涉及模型（如Sonet 3.5）的性能表现好奇、对特定模型（如14B模型）在相同指标下的表现期待。
  • 潜在影响：促使原帖作者或其他研究者进一步完善测试内容和范围，对AI模型在不同任务中的性能评估更加全面和细致，也可能影响相关人员在模型选择和使用上的决策。

详细内容：

标题：Qwen 32B Coder 与 72B 在 Leetcode 问题上的性能大比拼

在 Reddit 上，一篇关于 Qwen 32B Coder 模型和 72B 非编码模型在最新 Leetcode 问题上表现的帖子引发了热烈讨论。该帖获得了众多关注，评论数众多。

原帖作者通过让这两个模型以及 GPT-4o 解决最新 Leetcode 问题来进行比较，并附上了展示模型性能对比的柱状图和电子表格截图。作者还详细介绍了测试的细节，包括使用的硬件、量化方法、上下文长度等。

讨论焦点主要集中在以下几个方面：

  • 有人希望作者能将 14B、7B 等其他规模的模型纳入比较。
  • 有用户提出将模型与 Q4_K_M 进行对比，以探究不同量化方式的效果。
  • 一些人认为 Leetcode 问题与实际工作脱节，对于招聘中的 Leetcode 测试表示质疑。
  • 关于模型在不同量化方式下的性能表现，大家各抒己见。

比如，有用户分享道：“我最近发现，如果不是初级员工，表明对 Leetcode 测试的态度，有机会进入更实际的面试环节。但并非所有公司都如此。”

也有人认为：“好的软件构建涉及多个方面，LLMs 仅训练 Leetcode 无法帮助人们构建好软件，我们需要能在更高层面思考的模型。”

还有用户说：“当我要求创建一个新方法并给出细节时，32B 和 72B 表现相当，但 72B 在处理某些复杂需求时表现更好。”

讨论中的共识在于大家都对模型的性能和实际应用表现出浓厚兴趣。特别有见地的观点是指出 Leetcode 与实际工作场景的差异，以及对模型能否真正助力实际软件构建的思考。

此次讨论的核心问题在于：模型的性能差异究竟如何，以及 Leetcode 这类测试在实际工作和招聘中的合理性与实用性。