原贴链接

我想和其他人确认一下我对Qwen2.5 - Coder - 32B - Instruct在无量化且支持完整上下文大小情况下GPU内存使用量的计算是否正确。注：这个帖子是关于我的计算的，Qwen2.5只是作为一个例子。我不是要自己运行这个模型，因为就我目前有限的本地硬件设置而言，我很可能会使用API供应商或者使用较小的上下文大小并且量化。以下是我的计算依据：模型名为Qwen2.5 - Coder - 32B - Instruct，参数量为320亿，层数为64，头数为40，KV头数为8，每个头的维度为128，模型维度为5120，分组查询校正因子为0.2（KV头数/总头数），精度为bfloat16，无量化，完整上下文大小为131072，本地使用的批处理大小为1，操作系统为Linux（假设无额外内存开销，若为Windows则约20%）。首先，模型大小为64GB，KV缓存（16位）约为34.36GB，CUDA开销为1GB。所以GPU内存总共需要99.36GB，这意味着我们至少需要5个RTX 4090（每个24GB）才能以全精度和最大上下文长度自由运行这个模型。我的计算正确吗？来源信息：1. [https://kipp.ly/transformer - inference - arithmetic/](https://kipp.ly/transformer - inference - arithmetic/) 2. [https://ai.plainenglish.io/understanding - llama2 - kv - cache - grouped - query - attention - rotary - embedding - and - more - c17e5f49a6d7#1bc0](https://ai.plainenglish.io/understanding - llama2 - kv - cache - grouped - query - attention - rotary - embedding - and - more - c17e5f49a6d7#1bc0) 3. 模型卡片以及config.json：[https://huggingface.co/Qwen/Qwen2.5 - Coder - 32B - Instruct](https://huggingface.co/Qwen/Qwen2.5 - Coder - 32B - Instruct)

讨论总结

原帖主要是对Qwen2.5 - Coder - 32B - Instruct模型的GPU内存使用量计算进行确认，询问是否至少需要5个RTX 4090才能无限制运行该模型。评论中大家从不同角度给出建议，包括为减少硬件成本可采用4位运行并接受较短上下文大小、可使用Q8量化替代完整的fp16、偶尔使用时可选择openrouter等，还讨论了ChatGPT关于KV缓存计算结果的可靠性，总体氛围偏向技术交流和分享。

主要观点

  1. 👍 为减少硬件成本，可采用4位运行并接受较短上下文大小
    • 支持理由：能避免高额硬件成本
    • 反对声音：无
  2. 🔥 若无特殊用例，降低模型上下文长度是明智的
    • 正方观点：能减少硬件需求
    • 反方观点：无
  3. 💡 做计算理解硬件需求是有意义的
    • 解释：有助于了解运行模型所需的硬件条件
  4. 💡 建议使用Q8量化替代完整的fp16（32b参数时使用Q8量化损失很小）
    • 解释：在特定参数下损失小且能减少内存使用
  5. 💡 不应向ChatGPT寻求数学相关解决方案
    • 支持理由：ChatGPT看待标记与人类不同，可能产生计算或假设上的幻觉
    • 反对声音：比较方法是有用的

金句与有趣评论

  1. “😂 NickCanCode: If you are not running the model 7x24 non - stop but just doing some coding occasionally, maybe you can use openrouter. 1 mil tokens are just ~$0.2 and it is BF16.”
    • 亮点：提供了一种偶尔使用模型时的低成本替代方案。
  2. “🤔 pathfinder6709: I agree. Dropping the context size unless I have use cases for it or if I myself curated a long context length (multi turn convos or RAG - alike) dataset for fine tuning, then it is wise not to resort to full context length.”
    • 亮点：详细解释了在何种情况下降低上下文长度是明智的。
  3. “👀 Invectorgator: I’ve been playing with Qwen 72B (on Mac), for instance, and after an especially lengthy chat, it swapped languages on me and had to be coaxed back to English.”
    • 亮点：分享了模型在使用过程中出现的特殊情况。
  4. “🤔 pathfinder6709: I think we should refrain from asking ChatGPT for the solution, especially when it comes to maths right now because:”
    • 亮点：提出对ChatGPT解决数学问题能力的质疑。
  5. “😂 pathfinder6709: No worries, I was stupid in the creation of this post. I phrased the title and contents badly so now I don’t even get a single reply for my question asking about my calculations 😂”
    • 亮点：自嘲帖子标题和内容表述不佳。

情感分析

总体情感倾向是中性的。主要分歧点在于ChatGPT是否能用于数学计算相关的参考，可能的原因是对ChatGPT的能力认知不同，部分人认为它在数学计算方面存在缺陷，而部分人认为其计算方法仍有可对比之处。

趋势与预测

  • 新兴话题：探索更多量化方法在不同参数模型中的应用。
  • 潜在影响：有助于相关从业者更好地优化模型运行成本，提高模型运行效率。

详细内容：

标题：关于 Qwen2.5-Coder 32B 的 GPU 内存使用计算引发的热议

这则在 Reddit 上引起关注的帖子，主要探讨了 Qwen2.5-Coder 32B 在无量化和全上下文大小支持情况下的 GPU 内存使用计算。该帖获得了众多的浏览和不少的评论。

原帖作者计算出 GPU 内存总计约 99.36GB，认为至少需要 5 块 RTX 4090（每块 24GB）才能在全精度和最大上下文长度下自由运行该模型，并询问自己的计算是否正确。

讨论焦点主要集中在如何优化模型运行的硬件需求以及不同的处理策略。有人提出运行模型可以采用 4 位量化并缩短上下文大小。还有用户表示一些模型在上下文超过一定长度时可能会出现问题，比如自己在使用 Qwen 72B 时就遇到过语言切换的情况，并建议将上下文长度限制在 16k 或 32k 以下。

有人认为除非有特定用途或为精细调整专门策划了长上下文长度的数据集，否则降低上下文长度是明智的，且在推理时使用较少的上下文通常性能更好。也有人提到如果不是 7x24 不间断运行模型，只是偶尔进行编码工作，可以使用 openrouter，其 100 万令牌约 0.2 美元且是 BF16。

还有人建议考虑使用 Q8 量化而非全 fp16，并指出对于 320 亿参数的模型，损失很小，且不要追求全上下文。

有用户通过 ChatGPT 计算出 KV 缓存为 20GB，但也有人指出 ChatGPT 在数学计算方面可能存在错误，比如在计算每层的 KV 缓存时就可能有误。

通过这些讨论，核心问题在于如何在满足需求的前提下，更有效地配置硬件资源来运行此类大型模型，以及如何避免模型在处理长上下文时出现的问题。

总之，这次关于 Qwen2.5-Coder 32B 的 GPU 内存使用计算的讨论，为相关领域的探索提供了丰富的思路和多样的策略。