oMLX 内存守卫三档模式safe、balanced 与自定义 GB 上限的完整取舍指南【免费下载链接】omlxLLM inference server with continuous batching SSD caching for Apple Silicon — managed from the macOS menu bar项目地址: https://gitcode.com/GitHub_Trending/om/omlxoMLX 是一款运行在 Apple Silicon 上的 LLM 推理服务器其内置的**内存守卫Memory Guard**通过 safe、balanced、aggressive 和自定义 GB 上限四档策略实时保护你的 Mac 不被大模型推理拖垮。选错档位轻则频繁卸载模型重则触发 Metal 内存 panic本文用一张对照表讲清每档的真实参数、适用场景与取舍帮你快速做出正确选择。内存守卫到底在保护什么oMLX 跑在统一的 Apple Silicon 内存上GPUMetal分配会挤占系统 RAM。内存守卫的核心逻辑在 omlx/process_memory_enforcer.py 中最终上限 min(静态上限, 动态上限, Metal 上限)静态上限 总内存 − 档位预留预留值见下表防止绝对内存超压动态上限随系统状态每秒重算其他应用占内存时上限自动收缩Metal 上限来自 Apple 的max_recommended_working_set_size约 75% 内存或iogpu.wired_limit_mb内核值当内存使用越过软水位默认 85% 上限时守卫暂停新的 prefill 调度并卸载 LRU 模型越过硬水位95% 上限则中止在途任务。这样设计让大模型推理与浏览器、Docker 等共存时不触发 macOS 的 jetsam 强杀。三档模式参数对照表24GB 以上机型以下数据提取自 omlx/process_memory_enforcer.py 的档位表档位静态预留活跃内存回收比例软水位适用场景safe8 GB0.2保守85%与重度应用共存最不易抖动balanced默认6 GB0.5中等90%日常开发兼顾吞吐与稳定aggressive4 GB0.8激进依赖 swap92.5%独占机器跑大模型追求最大缓存24GB 以下小机型所有档位统一预留 4 GB避免小内存 Mac 连实用模型都装不下活跃内存回收比例是核心差异safe 只假设 macOS 能压缩 20% 的活跃页上限算得低但几乎不会与系统抢内存aggressive 假设 80% 可回收已进入 swap 区间上限最高但机器可能变卡自定义 GB 上限适合谁怎么用第四档custom直接把你填写的 GB 数值当作动态上限跳过 vm_stat 实时计算。它在 omlx/settings.py 中通过memory_guard_custom_ceiling_gb字段配置CLI 方式启动时传--memory-guard custom --memory-guard-gb 32参数定义见 omlx/cli.py管理面板在 Dashboard 的 Resource Management 区域切换档位并填写 GB 数见上方截图自定义档位仍然被静态上限总内存 − 2 GB和 Metal 上限双重钳制填得再大也不会 panic这一点让它比 safe/balanced 更适合我知道我的机器该给 oMLX 多少 GB的用户。⚠️ 注意--memory-guard off不能与--memory-guard-gb同时使用——自定义上限依赖守卫开启。如何快速选择按你的使用形态对号入座Mac 上还开着 Docker / 大型 IDE / 浏览器重度使用→ 选safe8 GB 预留 0.2 回收比例最保守宁可用内存少一点也不要整机卡顿日常开发、偶尔跑 70B 级别模型→ 直接用默认balanced1 GB 安全缓冲的折中设计覆盖绝大多数场景专用推理服务器比如 Studio Display 接的 Mac Studio 只跑 oMLX→aggressive让 KV 缓存和 SSD 热缓存尽量膨胀吞吐最大化多台机器统一配额、或需要与iogpu.wired_limit_mb精确对齐→custom GB 上限行为可预期、便于批量管理 切换档位即时生效enforcer 会自动重新计算上限并同步给调度器但管理面板显示 Restart needed 时仍需重启服务器让完整配置落盘。进阶为什么有时上限比你填的还低如果你填了 100 GB 却只看到 64 GB 可用看两个来源Metal 上限未设置iogpu.wired_limit_mb时上限被钳制在 Apple 推荐的约 75% 内存处。截图中红色横幅提示的sudo sysctl iogpu.wired_limit_mb...就是用来抬高这个内核上限的面板会自动给出建议值静态上限custom 档也要扣 2 GB 预留相关实现可查看_get_ceiling_breakdownomlx/process_memory_enforcer.py被拒绝的 prefill 错误信息会明确告诉你是哪一重约束在绑定并给出对应补救建议。小结你的诉求推荐档位稳定优先、多任务共存safe开箱即用、日常开发balanced默认独占机器、最大吞吐aggressive精确配额、可预期行为custom GB 上限内存守卫让 oMLX 在跑满内存与系统安全之间有了显式的调节阀。理解了 min(静态, 动态, Metal) 的三重上限公式后任何档位的实际行为对你都将是透明的。【免费下载链接】omlxLLM inference server with continuous batching SSD caching for Apple Silicon — managed from the macOS menu bar项目地址: https://gitcode.com/GitHub_Trending/om/omlx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 oMLX 内存守卫三档模式：safe、balanced 与自定义 GB 上限的完整取舍指南
oMLX 内存守卫三档模式safe、balanced 与自定义 GB 上限的完整取舍指南【免费下载链接】omlxLLM inference server with continuous batching SSD caching for Apple Silicon — managed from the macOS menu bar项目地址: https://gitcode.com/GitHub_Trending/om/omlxoMLX 是一款运行在 Apple Silicon 上的 LLM 推理服务器其内置的**内存守卫Memory Guard**通过 safe、balanced、aggressive 和自定义 GB 上限四档策略实时保护你的 Mac 不被大模型推理拖垮。选错档位轻则频繁卸载模型重则触发 Metal 内存 panic本文用一张对照表讲清每档的真实参数、适用场景与取舍帮你快速做出正确选择。内存守卫到底在保护什么oMLX 跑在统一的 Apple Silicon 内存上GPUMetal分配会挤占系统 RAM。内存守卫的核心逻辑在 omlx/process_memory_enforcer.py 中最终上限 min(静态上限, 动态上限, Metal 上限)静态上限 总内存 − 档位预留预留值见下表防止绝对内存超压动态上限随系统状态每秒重算其他应用占内存时上限自动收缩Metal 上限来自 Apple 的max_recommended_working_set_size约 75% 内存或iogpu.wired_limit_mb内核值当内存使用越过软水位默认 85% 上限时守卫暂停新的 prefill 调度并卸载 LRU 模型越过硬水位95% 上限则中止在途任务。这样设计让大模型推理与浏览器、Docker 等共存时不触发 macOS 的 jetsam 强杀。三档模式参数对照表24GB 以上机型以下数据提取自 omlx/process_memory_enforcer.py 的档位表档位静态预留活跃内存回收比例软水位适用场景safe8 GB0.2保守85%与重度应用共存最不易抖动balanced默认6 GB0.5中等90%日常开发兼顾吞吐与稳定aggressive4 GB0.8激进依赖 swap92.5%独占机器跑大模型追求最大缓存24GB 以下小机型所有档位统一预留 4 GB避免小内存 Mac 连实用模型都装不下活跃内存回收比例是核心差异safe 只假设 macOS 能压缩 20% 的活跃页上限算得低但几乎不会与系统抢内存aggressive 假设 80% 可回收已进入 swap 区间上限最高但机器可能变卡自定义 GB 上限适合谁怎么用第四档custom直接把你填写的 GB 数值当作动态上限跳过 vm_stat 实时计算。它在 omlx/settings.py 中通过memory_guard_custom_ceiling_gb字段配置CLI 方式启动时传--memory-guard custom --memory-guard-gb 32参数定义见 omlx/cli.py管理面板在 Dashboard 的 Resource Management 区域切换档位并填写 GB 数见上方截图自定义档位仍然被静态上限总内存 − 2 GB和 Metal 上限双重钳制填得再大也不会 panic这一点让它比 safe/balanced 更适合我知道我的机器该给 oMLX 多少 GB的用户。⚠️ 注意--memory-guard off不能与--memory-guard-gb同时使用——自定义上限依赖守卫开启。如何快速选择按你的使用形态对号入座Mac 上还开着 Docker / 大型 IDE / 浏览器重度使用→ 选safe8 GB 预留 0.2 回收比例最保守宁可用内存少一点也不要整机卡顿日常开发、偶尔跑 70B 级别模型→ 直接用默认balanced1 GB 安全缓冲的折中设计覆盖绝大多数场景专用推理服务器比如 Studio Display 接的 Mac Studio 只跑 oMLX→aggressive让 KV 缓存和 SSD 热缓存尽量膨胀吞吐最大化多台机器统一配额、或需要与iogpu.wired_limit_mb精确对齐→custom GB 上限行为可预期、便于批量管理 切换档位即时生效enforcer 会自动重新计算上限并同步给调度器但管理面板显示 Restart needed 时仍需重启服务器让完整配置落盘。进阶为什么有时上限比你填的还低如果你填了 100 GB 却只看到 64 GB 可用看两个来源Metal 上限未设置iogpu.wired_limit_mb时上限被钳制在 Apple 推荐的约 75% 内存处。截图中红色横幅提示的sudo sysctl iogpu.wired_limit_mb...就是用来抬高这个内核上限的面板会自动给出建议值静态上限custom 档也要扣 2 GB 预留相关实现可查看_get_ceiling_breakdownomlx/process_memory_enforcer.py被拒绝的 prefill 错误信息会明确告诉你是哪一重约束在绑定并给出对应补救建议。小结你的诉求推荐档位稳定优先、多任务共存safe开箱即用、日常开发balanced默认独占机器、最大吞吐aggressive精确配额、可预期行为custom GB 上限内存守卫让 oMLX 在跑满内存与系统安全之间有了显式的调节阀。理解了 min(静态, 动态, Metal) 的三重上限公式后任何档位的实际行为对你都将是透明的。【免费下载链接】omlxLLM inference server with continuous batching SSD caching for Apple Silicon — managed from the macOS menu bar项目地址: https://gitcode.com/GitHub_Trending/om/omlx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考