原贴链接

我有48GB的VRAM，Q4_K_M模型使用q4_0值缓存量化与128k上下文适配。我需要给llama.cpp哪些参数才能将上下文从32k正确扩展到128k呢？[这篇unsloth博客文章](https://docs.unsloth.ai/basics/tutorials - how - to - fine - tune - and - run - llms/tutorial - how - to - run - qwq - 32b - effectively)提到他们如何尝试设置一些–override - kv选项，但据我理解那是为了解决重复问题，他们后来用–sampler参数解决了。以下是我尝试仿照unsloth建议设置的参数（增加了yarn rope缩放）。使用博客文章中的“用Python创建一个Flappy Bird游戏….”提示，QwQ思考了很长时间并输出了一个可用的flappy bird pygame脚本（约150行），但思考了约20000个token之后才输出。我是否应该以不同方式设置各种–yarn - *参数呢？我注意到llama.cpp记录“qwen2.context_length u32 = 131072”和“n_ctx_train = 131072”，据我所知这是错误的。另外，有人能建议一个长上下文测试提示来测试上下文扩展是否正常工作吗？具体给出了执行llama - cli的相关参数。

讨论总结

原帖作者想知道在特定条件下将llama.cpp的上下文从32k扩展到128k需要哪些参数，还寻求长上下文测试提示。评论者们从不同角度进行回应，有分享测试结果的，有对原帖复杂参数设置表示疑惑并提出简化设想的，有阐述模型在32k以上可能出现的失控、性能下降等问题的，也有给出技术建议或推荐替代方案的，整体氛围是围绕技术问题展开的理性交流。

主要观点

  1. 👍 提供测试运行得到的游戏内容并给出游戏查看链接
    • 支持理由：可能想给大家展示测试运行结果，分享有趣成果。
    • 反对声音：无（未涉及原帖技术参数相关讨论）
  2. 🔥 模型在32k以上容易失控，越大越能保持正常
    • 正方观点：可能基于自己的经验和观察，在大设备上运行的情况。
    • 反方观点：无（未发现明显反驳）
  3. 💡 推荐使用LM studio解决原帖提到的问题
    • 解释：认为LM studio能处理llama.cpp相关问题并可用于API。
  4. 💡 建议使用 - c 0以利用模型全语境，量化V - cache应至少使用q8_0，K - cache在q4_0基本可行
    • 解释：针对原帖llama.cpp参数问题给出具体建议。
  5. 💡 不认可q4_0值的缓存量化，q8缓存会损害模型质量输出
    • 解释：以故事变短变平淡为例阐述缓存量化对模型输出的影响。

金句与有趣评论

  1. “😂 H3PO：In case anyone is interested, this is the game it produced in my test run (sampler seed: 1546878455)”
    • 亮点：提供了测试运行得到的游戏相关信息。
  2. “🤔 getmevodka：most times the models go haywire somewhere beyond 32k anyways since by then its very much context to stay consistent to for them.”
    • 亮点：对模型在32k以上的情况提出自己的看法。
  3. “👀 DrVonSinistro：From graphs I’ve seen and tests I did, model score/power get decimated after 32k ctx.”
    • 亮点：通过自己的测试和看到的图表得出关于模型性能的观点。
  4. “🤔 Just use LM studio. It takes care of all these issues and It can start a server too for API use.”
    • 亮点：简洁地给出替代方案解决原帖问题。
  5. “👀 Cache q4_0 is a very bad idea…even q8 is hurting model quality output.”
    • 亮点：对缓存量化提出不同意见并给出理由。

情感分析

总体情感倾向比较中性，大家主要是在理性探讨技术问题。主要分歧点在于对不同参数设置的看法，例如q4_0缓存量化是否可行，以及模型在32k以上上下文扩展时的性能表现等。可能的原因是大家基于自己的经验、测试或者对技术原理的理解有所不同。

趋势与预测

  • 新兴话题：关于llama - cli中YaRN设置的探讨可能会继续深入。
  • 潜在影响：如果在参数设置、模型性能等方面有新的发现或共识，可能会对使用llama.cpp相关的开发、研究或应用产生影响，例如提高模型运行效率或者改善输出质量等。

详细内容：

标题：关于 QwQ-32B 模型 128k 扩展上下文的 llama.cpp 参数讨论

在 Reddit 上，有一个关于为拥有 48GB VRAM 的 QwQ-32B 模型使用 llama.cpp 正确扩展上下文从 32k 到 128k 的热门讨论。此帖获得了众多关注，引发了激烈的交流。原帖作者提出了自己的尝试和困惑，还提供了相关的链接https://docs.unsloth.ai/basics/tutorials-how-to-fine-tune-and-run-llms/tutorial-how-to-run-qwq-32b-effectively。文章将要探讨的核心问题是如何正确设置 llama.cpp 的参数以实现有效的上下文扩展。

在讨论中，观点纷呈。有人分享道：“在我的测试运行中，这是它生成的游戏https://pastebin.pl/view/fd13dbd5”。有人认为可以直接使用“-ctx-size 131072”，而不需要所有的“yarn”相关设置。也有人提到 SGLang 对于“yarn”支持存在问题。还有人表示，Qwen 团队确认 128k 上下文应使用“yarn”，但之后又有修改。

有用户表示大多数时候模型在超过 32k 后会变得不稳定，认为模型越大越能保持稳定。也有人提到不同的运行环境和缓存设置对效果的影响，如有人建议使用 LM studio，有人认为“Cache q4_0 是个很糟糕的主意”。

讨论中的共识在于大家都在努力寻找实现模型稳定和高效运行的方法。特别有见地的观点是关于不同运行环境和参数设置的具体分析，丰富了对这一问题的探讨。