原贴链接

如标题所说，从两天前开始尝试新的QwQ - 32B（https://huggingface.co/Qwen/QwQ - 32B - GGUF），但我根本无法从它得到任何实际的代码。它一直在思考，永远停不下来，可能会遇到像上下文或者最大标记数之类的限制，并且在得到任何实际结果之前就停止了。我在CPU上运行它，温度设为0.7，Top P为0.95，最大标记数（num_predict）为12000，上下文为2048 - 8192。有谁用它来做编码吗？编辑：刚发现我弄错了，最大标记数（num_predict）是12000。编辑：更多信息，我正在Docker Open Web UI和Ollama - 版本0.5.13中运行。编辑：有趣的是，在思考过程中有有用的代码，但它在思考部分，而且和模型的表述混在一起。编辑：是Q5_K_M模型。编辑：据Docker容器报告，使用这些设置的模型正在使用30GB内存。更新：在用户u/syraccc的建议之后，我使用了来自这里（https://www.reddit.com/r/LocalLLaMA/comments/1j4v3fi/prompts_for_qwq32b/）的“低推理努力”提示，现在QwQ开始回答了，仍然思考很多，也许比之前少了，代码质量还不错。我使用的提示来自于我已经用在线模型完成的项目，目前我只是使用相同的提示来测试本地QwQ的质量，因为不管怎样，在只有1t/s的CPU上它相当没用。

讨论总结

该讨论围绕QwQ - 32B模型在本地ollama上运行无法得到有效代码结果展开。参与者分享了各自的使用经验、遇到的问题、提出的解决方案以及对模型性能的看法，涉及到标记数设置、上下文长度、硬件要求等多方面因素，整体氛围积极且富有技术交流性。

主要观点

  1. 👍 QwQ - 32B模型对部分人来说运行正常
    • 支持理由：如评论者称在MacBook、Mac mini、Windows系统下运行效果良好等。
    • 反对声音：部分人遇到模型一直思考无实际结果的情况。
  2. 🔥 原帖作者设置的最大标记数可能过小不适合编码
    • 正方观点：模型用于编码时每次回复通常需要10000 - 15000个标记，12000个标记可能过小。
    • 反方观点：无（未发现明显反对意见）。
  3. 💡 QwQ - 32B模型8k最大上下文无用
    • 解释：对于稍详细但较短的提示，它经常会超过10k个标记。
  4. 💡 QwQ - 32B生成较好答案需4倍标记和更多时间
    • 解释：相比Qwen2.5，它需要更多标记，所以花费时间也更多。
  5. 💡 不同设备运行该模型效果不同
    • 解释：如在MacBook、本地ollama、Windows系统下的不同运行情况。

金句与有趣评论

  1. “😂 It works fine for me.”
    • 亮点：表明模型在该评论者的使用环境下正常运行，与原帖作者形成对比。
  2. “🤔 But you max tokens is way way too small.”
    • 亮点：指出原帖作者可能存在的设置问题。
  3. “👀 8k max context is useless for this model.”
    • 亮点：对模型的上下文设置给出否定评价。
  4. “🤔 It will come up with a better answer than Qwen2.5, but it will require 4x the tokens (so even more than 4x the time) to pull it off.”
    • 亮点：解释了QwQ - 32B模型在获取较好答案时的资源消耗情况。
  5. “😂 It works really well on my MacBook.”
    • 亮点：再次体现模型在不同设备上的不同运行效果。

情感分析

总体情感倾向为中性且偏积极。大部分评论者都是在理性地分享自己的使用经验、分析问题并提出建议，分歧点主要在于QwQ - 32B模型在不同设备和设置下的运行效果，可能是由于硬件条件、使用环境、个人需求等因素导致的。

趋势与预测

  • 新兴话题：探索让Ollama更高效使用上下文以及是否能量化上下文的方法。
  • 潜在影响：有助于其他有类似问题的用户优化QwQ - 32B模型的使用，提高模型在本地运行的效率，也为模型开发者提供优化方向。

详细内容：

标题：关于 QwQ-32B 在本地 ollama 上表现的热门讨论

这篇帖子探讨了在本地 ollama 上使用 QwQ-32B 模型时遇到的问题。原帖发布于两天前https://huggingface.co/Qwen/QwQ-32B-GGUF ，作者表示无法从中获得实际代码，模型思考不停且可能达到诸如上下文或最大令牌等限制而停止，在 CPU 上运行，设置了温度 0.7、Top P 0.95、最大令牌 12000、上下文 2048 - 8192 等参数。此帖获得了众多关注，引发了广泛讨论。

讨论焦点与观点分析： 有人表示该模型对自己来说运行良好，但指出作者设置的最大令牌过小，对于编码任务，此模型通常每回复需要 10000 至 15000 个令牌。有人分享自己使用其他模型的经历，比如 reka 模型和 noushermes 版本的 mistral 2501 。有人提到若上下文滑动，QwQ:32b 会一直思考，不太适合该模型。有人认为使用该模型时应根据情况调整上下文窗口，比如设置为 16k - 32k 。有人在 Mac 上使用该模型效果良好，并分享了自己的设置和经验。还有人表示降低温度到 0.1 有效果。

共识方面，大家普遍认为该模型对上下文和最大令牌的设置要求较高。特别有见地的观点如，有人认为这是一种权衡，需要考虑时间、上下文和智能之间的平衡。

总的来说，关于 QwQ-32B 在本地 ollama 上的使用，大家各抒己见，分享了不同的设置和使用体验。