原贴链接

如果你正在使用64GB内存的Mac，并且总是发现70b模型响应缓慢，这是因为MacOS在进行一些奇怪的操作，从VRAM中卸载模型。

即使你已经指定了OLLAMA_KEEP_ALIVE = -1，这种情况也会发生。

更令人费解的是，即使你没有启用任何交换空间，这种情况也会发生。MacOS只是将模型从虚拟VRAM分区卸载到RAM分区，并可能进行了一些压缩操作以在RAM中缓存它。然而，由于模型的大小巨大，你仍然需要几秒钟的时间将模型重新加载到实际的VRAM中。

我的猜测是，因为模型占用了41GB的VRAM，这超出了系统对64GB Mac的偏好。尽管系统没有硬性的VRAM限制，但它试图非常积极地减少其使用。你会注意到，每次你向AI提问时，内存使用量很快就会达到50-60GB左右（假设你还在运行其他程序）。但之后它会下降，每秒几百兆字节。再次强调，即使你已经指定了keep-alive为-1，并且OLLAMA报告模型应该永远存在。

幸运的是，我改变了对OLLAMA的指责，开始怀疑可能是MacOS的内存管理系统的问题，因为众所周知，它在VRAM方面总是相当古怪。

感谢这篇帖子以及u/farkinga，现在70b模型的响应速度可以相当快 https://www.reddit.com/r/LocalLLaMA/comments/186phti/m1m2m3_increase_vram_allocation_with_sudo_sysctl/

基本上，你给系统更多的VRAM，系统就不会在你上次对话后立即尝试卸载和压缩它。我给我的系统分配了慷慨的51200MB，相当于大约50GB。

sudo sysctl iogpu.wired_limit_mb=51200

这似乎完全阻止了系统从VRAM中卸载和压缩模型，即使我同时运行llama3.1 8b和70b。我还需要测试当系统内存负载很高时会发生什么，但通过检查活动管理器，它认为我只使用了20GB的内存，所以理论上，当内存负载高时，它只会放弃模型，而不会导致计算机崩溃。

你还可以通过修改sysctl的plist文件使其持久化和自动化。

再次感谢社区 :)

讨论总结

本次讨论主要集中在MacOS系统在处理大型模型时VRAM的管理问题上。用户反映在使用64GB RAM的Mac电脑上，70B模型响应速度慢，原因是MacOS会主动将模型从VRAM卸载到RAM中，即使没有启用交换空间。通过增加VRAM分配，可以避免系统频繁卸载和压缩模型，从而优化响应速度。社区提供的解决方案得到了广泛认可，用户通过修改sysctl配置，实现了持久化增加VRAM分配。讨论中还涉及了对wired memory的理解和MacOS内存管理系统的探讨。

主要观点

  1. 👍 增加VRAM分配可以优化响应速度
    • 支持理由：通过增加VRAM分配，可以避免系统频繁卸载和压缩模型，从而优化响应速度。
    • 反对声音：暂无明确反对意见。
  2. 🔥 MacOS的内存管理系统对VRAM的处理存在问题
    • 正方观点：MacOS会主动将模型从VRAM卸载到RAM中，即使没有启用交换空间。
    • 反方观点：暂无明确反方观点。
  3. 💡 社区提供的解决方案有效
    • 解释：用户通过修改sysctl配置，实现了持久化增加VRAM分配，解决了响应速度慢的问题。

金句与有趣评论

  1. “😂 通过增加VRAM分配，可以完全防止系统从VRAM中卸载和压缩模型。”
    • 亮点：简洁明了地总结了增加VRAM分配的效果。
  2. “🤔 MacOS的内存管理系统对VRAM的处理可能存在一些问题。”
    • 亮点：指出了MacOS内存管理系统的潜在问题。
  3. “👀 社区提供的解决方案对改善系统性能有积极作用。”
    • 亮点：强调了社区解决方案的积极影响。

情感分析

讨论的总体情感倾向较为积极，主要集中在寻找和实施解决方案上。用户对社区提供的解决方案表示感谢，并对MacOS内存管理系统的探讨表现出浓厚的兴趣。主要分歧点在于对wired memory的理解，部分用户认为这是系统内存管理的关键问题。

趋势与预测

  • 新兴话题：对MacOS内存管理系统的深入探讨和优化。
  • 潜在影响：优化后的系统性能可能会吸引更多用户关注和采用，对相关技术社区产生积极影响。

详细内容：

标题：解决 Mac 上 64GB 内存响应速度慢的问题引发的热议

在 Reddit 上，一篇关于解决 64GB 内存的 Mac 设备响应速度慢问题的帖子引发了广泛关注。该帖子指出，使用 64GB 内存的 Mac 运行 70b 模型时响应缓慢，原因是 MacOS 会进行一些奇怪操作，将模型从 VRAM 中卸载。即便指定 OLLAMA_KEEP_ALIVE = -1，无启用交换功能，MacOS 仍会将模型从虚拟 VRAM 分区卸载到 RAM 分区并进行压缩缓存。此帖获得了众多点赞和大量评论。

讨论焦点主要集中在 MacOS 的内存管理系统以及如何优化模型的加载和响应速度。有人表示自己的 32GB 内存的 Mac 也存在类似问题，并打算尝试给出的方法。还有人指出，在 32GB 内存的 Mac 上，默认的限制约为 21GB，并提醒要为 MacOS 留出至少 8GB 以确保安全。有人分享自己在 32GB 的 Mac 上设置 31GB 有线限制，通过 SSH 登录而非使用 GUI 登录时，甚至不会进行交换。

有人提到，有线内存是不能被交换出的内存，被锁定在 RAM 中，且任何应用都可以使用有线内存，在 Mac 上没有 VRAM 和 RAM 的区别，都是 RAM，GPU 只是另一个可以使用有线内存的应用。

关于是否应该使用 llama.cpp 进行测试，有人认为 Ollama 是基于 llama.cpp 构建的，情况不应有太大不同，但也有人指出很多人在使用 Ollama 时遇到问题，而在 llama.cpp 中却没有相关报告。有人认为 Llama.cpp 对有线内存的处理是正确的，Ollama 也正确处理了，但在 Mac 平台上存在系统对内存压缩和交换过于敏感的问题。对于 M1 Max 64Gb 能否通过增加有线限制提高 70B 模型的每秒令牌数，有人表示不会有提升，此操作只是防止模型从 VRAM 重新加载，保证约 2 - 3 秒的响应时间。

在这场讨论中，对于 MacOS 内存管理机制的理解和优化方式存在不同观点，但大家都在积极探讨以寻求更优的解决方案。