原贴链接

嗨，我刚涉足这个领域。在我用LM Studio加载我的第一个模型（Qwen2.5 Coder 14B Instruct Q4_K_M GGUF）之前，我从没想到上下文会这么占用显存。在我的Mac mini M2 Pro（32GB内存）上，将上下文大小从32K增加到64K几乎耗尽了所有内存。所以我想知道，你们默认是使用最大上下文大小来运行大语言模型吗？还是尽可能保持低的上下文大小？就我的使用场景（如模型所建议的编码）而言，我已经被Claude / Gemini的大上下文大小宠坏了。

讨论总结

原帖作者在本地运行LLM时遇到内存占用问题，从而引发对本地LLM上下文大小的讨论。评论者们纷纷分享自己在本地运行LLM时设置的上下文大小，从4 - 8K到128K不等，并且阐述了不同大小的上下文在不同任务中的适用性，同时还提到了相关的性能影响、内存影响等方面的内容，整个讨论充满技术交流的氛围。

主要观点

  1. 👍 大多数本地LLM在32K上下文时性能大幅下降
    • 支持理由：包括令牌质量和生成速度受影响，有研究显示12个LLM中的10个在32K上下文时性能减半
    • 反对声音：无
  2. 🔥 上下文大小取决于实际需求
    • 正方观点：不同任务需要不同的上下文大小，如处理整个PDF可能需要128K，正常使用16K可能就够了
    • 反方观点：无
  3. 💡 不默认使用最大上下文，除非必要
    • 支持理由：大的输入标记影响吞吐量，应优化输入标记长度
    • 反对声音：无
  4. 💡 设置更高上下文限制主要影响内存
    • 支持理由：实际解析提示和生成标记的成本受已占用上下文大小影响
    • 反对声音：无
  5. 💡 通常将本地LLM上下文保持在4 - 8k，只有特定任务才扩展
    • 支持理由：随着上下文尺寸增大，模型的质量会迅速下降
    • 反对声音：无

金句与有趣评论

  1. “😂 Most local LLMs are massively degraded by 32K context. Both token quality and generation speed.”
    • 亮点：直接指出32K上下文对本地LLM性能的影响，涵盖令牌质量和生成速度两个方面
  2. “🤔 You have to do more work to fit in only the relevant context but that’s the tradeoff with going local”
    • 亮点：强调在本地运行LLM时要权衡只包含相关上下文的工作和性能之间的关系
  3. “👀 Depends how much context you actually need.”
    • 亮点：简洁地表达了上下文大小取决于实际需求的观点
  4. “😂 I usually run around 16K context because I actually want around 16K context.”
    • 亮点：表明16K上下文符合自身需求的简单直接表述
  5. “🤔 Having large input tokens impacts the throughput, so it’s better to optimize the input tokens length.”
    • 亮点：阐述了大输入标记、吞吐量和优化输入标记长度之间的关系

情感分析

总体情感倾向为中立，主要分歧点较少。大多数评论者都是基于自己的经验和理解来分享关于本地LLM上下文大小的设置，没有明显的争论或者情感上的偏向。可能的原因是这是一个比较技术向的话题，大家更多地是在交流技术经验。

趋势与预测

  • 新兴话题：无（本次讨论主要围绕已有的观点和经验分享，未出现明显的新兴话题）
  • 潜在影响：对其他正在探索本地LLM运行最佳实践的用户有一定的参考价值，有助于他们根据自身需求合理设置上下文大小，提高模型运行效率并节省资源。

详细内容：

《关于本地 LLM 上下文大小的热门讨论》

在 Reddit 上，一篇题为“How large is your local LLM context?”的帖子引发了广泛关注。该帖子讲述了作者在使用 Mac mini M2 Pro（32GB RAM）加载第一个模型时，发现将上下文大小从 32K 增加到 64K 几乎耗尽了所有内存，并由此提出疑问：大家在运行 LLMs 时是默认使用最大上下文大小，还是尽量保持较小？此贴获得了众多的点赞和大量的评论。

讨论焦点主要集中在以下几个方面： 有人认为，大多数本地 LLMs 在 32K 上下文时就会大幅降级，包括令牌质量和生成速度，建议不要超过这个值，应努力只纳入相关上下文，这是使用本地模型的权衡。比如有人提到“对于像代码生成这样的精确任务，大上下文下的性能下降更明显”，还提供了相关研究的链接：https://arxiv.org/abs/2502.05167。 但也有人觉得更长的上下文意味着更好的质量，就像有人说“Karpathy 在https://youtu.be/7xTGNNLPyMI?t=6416解释过。直观地说，可以把它想象成发出错误令牌的概率。第一个令牌有 10%的错误概率，第二个有 0.1 * 0.1，第三个有 0.1 * 0.1 * 0.1，以此类推……这也是为什么‘思考’模型在响应前发出许多令牌会产生更好的结果。您链接的论文讨论了减少实际上下文从而降低质量的技术。” 还有观点指出，上下文长度与性能之间存在一个最佳点，可参考https://arxiv.org/abs/2502.01481。 不少人分享了自己的设置经验，有人一般将上下文设置为 16K，有人则坚持 4 - 8K 就能完成大多数任务，还有人会根据具体需求进行调整。

讨论中的共识在于，上下文大小的设置应根据实际需求和硬件资源来决定。特别有见地的观点是，不同的任务和模型架构可能对上下文大小的需求和适应程度不同。

通过这次讨论，我们可以更深入地了解本地 LLM 上下文大小设置的复杂性和多样性，为实际应用提供更多的参考和思考。