原贴链接

下载了https://huggingface.co/huihui-ai/Llama-3.2-3B-Instruct-abliterated。按照常规方式用convert_hf_to_gguf.py进行转换。当我尝试在单个P40上运行它时，出现内存分配错误。如果允许使用两个P40，它可以加载并运行，但分别消耗18200和17542 MB。作为对比，我可以在16GB显存中加载Daredevil - 8B - abliterated（16位）。一个8B的模型需要16GB显存，但一个大小约为其三分之一的模型却需要更多的显存？我尝试量化到8位，但它仍然消耗24GB显存。是我遗漏了一些基本的东西 - 3.2是否需要更多资源 - 还是有什么问题？

讨论总结

原帖作者提到Llama - 3.2 - 3B - Instruct - abliterated模型在运行时出现VRAM使用异常，包括在单个P40上出现内存分配错误，两个P40运行时消耗大量VRAM且比8B模型还多等问题。评论者们从不同角度进行分析，包括从技术方面探讨可能与上下文大小、模型格式有关，还有可能是资源未释放等情况，也给出了一些如降低上下文大小、重启机器、运行命令释放资源等建议。整体讨论氛围较为理性，大家都在积极尝试为原帖作者的问题找出原因和解决方案。

主要观点

  1. 👍 使用较低的上下文大小
    • 支持理由：上下文增加会使用大量内存，特别是超过1000 - 4000这个范围时，可减少VRAM使用量
    • 反对声音：无
  2. 🔥 模型VRAM消耗过大可能与默认128k上下文有关，但即便如此也不应消耗35GB VRAM
    • 正方观点：默认128k上下文会占用较多内存，原帖模型VRAM消耗过大可能与其有关
    • 反方观点：无
  3. 💡 可能存在VRAM被占用未释放的情况
    • 解释：有类似情况即llama.cpp的另一个实例分配了VRAM但没有释放，可通过重启机器和监控来验证
  4. 💡 运行“fuser -k /dev/nvidia”命令可释放内存*
    • 解释：可能存在与nvidia相关的进程未释放资源，运行此命令可以杀死相关进程从而释放所有内存
  5. 💡 减少上下文大小可以解决VRAM占用量过大的问题
    • 解释：128k的上下文大小需要32GB的RAM（对于浮点数），减少上下文大小所需内存会大大减少

金句与有趣评论

  1. “😂 Use a lower context size like 4096.”
    • 亮点：简洁地给出可能解决VRAM使用过多的方案
  2. “🤔 It should still not be 35GB VRAM”
    • 亮点：对模型消耗35GB VRAM表示质疑，即便有一些可能导致消耗大的因素存在也不应如此
  3. “👀 Likely a breakout attempt.”
    • 亮点：对模型VRAM使用异常给出一种新奇的猜测性解释
  4. “😎 You can try running fuser -k /dev/nvidia* to kill processes associated with nvidia if something is not getting freed.”
    • 亮点：提供了一个具体的解决VRAM使用异常的命令操作
  5. “🤓 16k context (an 8th of 128k) needs 64 ( 8^2 ) times less (512MB).”
    • 亮点：通过具体的数据对比说明减少上下文大小对内存需求的影响

情感分析

总体情感倾向是积极解决问题的态度。主要分歧点在于模型VRAM消耗过大的真正原因，是与上下文大小有关、模型本身的特性、未释放资源还是其他情况。可能的原因是模型运行涉及多种技术因素，不同的人从自己熟悉的角度去分析问题。

趋势与预测

  • 新兴话题：可能会进一步探讨如何更好地优化模型运行时的资源占用，特别是针对不同的模型格式和参数设置。
  • 潜在影响：如果能找到问题的真正原因和解决方案，有助于提高该模型及类似模型在VRAM使用上的效率，对模型运行相关的技术领域有一定的推动作用。

详细内容：

标题：Llama-3.2-3B-Instruct-abliterated 惊人的 35GB VRAM 消耗引热议

最近，Reddit 上一篇关于“Llama-3.2-3B-Instruct-abliterated 使用 35GB VRAM”的帖子引发了众多关注。该帖子详细描述了下载并转换相关模型后，在运行时出现的内存分配错误问题。即使允许访问两个 P40，其 VRAM 消耗分别高达 18200 和 17542 MB。相比之下，8B 模型只需 16GB 的 VRAM，而这个规模约为其三分之一的模型却需要更多的 VRAM。尝试量化到 8 位，仍消耗 24GB 的 VRAM，发帖人不禁疑惑是不是自己遗漏了关键环节，或者模型本身存在问题。此帖获得了大量点赞和众多评论。

在讨论中，主要观点如下： 有人提出使用较低的上下文大小，如 4096，因为上下文增加会大量消耗 RAM 资源。 有人质疑是否默认设置为 128k 上下文。 有人分享自己的类似经历，称在另一个实例中，llama.cpp 分配了 VRAM 但未释放，建议重启机器并通过相关方式监测 VRAM 使用率。 有人认为这可能是一种突破尝试，开玩笑说 3b 模型试图挖掘加密货币来给自己买服务器。 有人指出对于使用 llama-cpp-python 作为后台进程/线程的应用，这种情况经常发生，可能是 llama-cpp 未能正确关闭，成为僵尸进程。 有人建议可以尝试运行特定命令来杀死与 nvidia 相关的进程以释放内存。 有人认为要确保根据工作负载使用适当的上下文大小，并对 k/v 缓存进行量化。

讨论中的共识在于，需要关注上下文大小的设置以及相关的量化操作，以优化 VRAM 的使用。特别有见地的观点是对于模型内存消耗异常原因的深入分析，丰富了整个讨论。但对于究竟是模型本身的问题还是设置不当导致的高消耗，仍存在争议。

通过这次讨论，大家对于解决模型的 VRAM 高消耗问题有了更多的思路和方向，但仍需要进一步探索和实践。