M1 Max压缩19GB内存背后：一个MLX调用解决的问题

你的量化交易后台跑了8小时，内存压缩飙到19GB，模型推理越来越慢。你以为是内存泄漏，准备重启——但真正的元凶藏在Apple Silicon的统一内存架构里。

异常现场：60GB内存用满，压缩内存占三分之一

那天下午，作者打开活动监视器时，M1 Max的64GB统一内存已经吃到60.74GB。压缩内存19.69GB，交换空间开始上涨。SwiftUI仪表盘卡死，Python后端进程显示占用44GB——而实际加载的Qwen 3.6 35B-A3B模型只有约35GB权重。

正常情况应该是这样：Python进程35-40GB，已连接内存（Wired）2-3GB，压缩内存低个位数，空闲+可回收内存15-20GB。

实际看到的：Python进程44GB，压缩内存19.69GB，交换空间1.57GB且持续增长，空闲内存只剩3GB。

作者的第一反应是内存泄漏。但关机重启就错了——问题远比这有趣。

硬件配置与运行负载

单机环境：M1 Max，64GB统一内存。单个Python进程持有MLX框架，加载Q8量化的35B-A3B MoE模型。约35GB用于Metal可访问内存中的模型权重，其余为FastAPI后端、十二个共享模型的专用智能体（通过优先级队列调度）、SQLite模拟交易账本，以及各类内容生成循环。

异常发生时，距离上次后端重启已运行近8小时。

压缩内存为何是信号而非病因

macOS内核内置内存压缩器，通过压缩进程已分配但非活跃访问的页面，维持工作集驻留。压缩内存增长通常意味着某处有大块"冷内存"——已分配但访问频率不足以视为活跃。

压缩比约2:1。19.69GB压缩内存暗示约40GB"应占内存"被挤压处理。

普通桌面场景下这完全透明且无害。但在运行35GB模型的机器上，这是危险信号：若模型权重在推理间隙被压缩，每次推理前都需解压页面才能供Metal使用。CPU周期空耗，延迟漂移，数小时后机器变得 sluggish 却难以定位根因。

核心问题浮现：为何模型权重在推理间隙会变为非活跃状态？

Apple Silicon Metal的隐藏机制

Apple Silicon上CPU与GPU共享物理内存，这是统一内存的优势。但"统一"不等于"所有内存被平等对待"。

Metal维护独立的内存堆（heaps）和缓冲区对象。当Python进程通过MLX加载模型权重时，这些权重存在于Metal设备内存中，对CPU端内存管理器可见但不由其直接管理。macOS的内存压缩器看到的是"进程持有的大块内存"，而非"GPU即将使用的模型权重"。

关键洞察：当MLX未主动标记内存区域为"对GPU活跃"时，macOS视其为可压缩候选。模型加载后的空闲期——智能体排队等待、无推理任务时——这些页面被压缩。下次推理触发时，系统 frantic 解压，Metal等待，延迟堆积。

作者描述的现象是渐进式的：非突然崩溃，而是"数小时内逐渐迟钝"。这正是压缩-解压循环的特征——每次惩罚很小，累积后致命。

排查路径：从怀疑到验证

作者排除了明显的嫌疑对象。FastAPI后端和SQLite的内存占用相对稳定，智能体队列的内存指纹也无异常增长。交换空间的使用是症状而非病因——当压缩无法维持工作集时，系统开始换页。

真正的线索在压缩内存的构成。活动监视器不直接展示哪些页面被压缩，但作者通过推理时间分布推断：首次推理后延迟正常，随运行时间延长，延迟方差增大，偶现卡顿。这与"冷启动"解压惩罚的模式吻合。

MLX的内存管理文档在此场景下显得模糊。框架抽象了Metal的底层细节，但抽象泄漏了——Python进程持有对Metal缓冲区的引用，却未向操作系统传达这些缓冲区的活跃性语义。

修复：一个从未使用的MLX API调用

解决方案是调用 mx.metal.set_memory_limit()，这是作者此前从未使用的MLX API。

该调用并非设置"限制"的字面意思，而是向Metal运行时显式声明：这些内存区域应被视为GPU工作集的一部分，减少被系统压缩器盯上的概率。更关键的是，它改变了MLX与Metal内存池的交互方式——从"分配后放任"转为"主动驻留管理"。

具体实施：在模型加载完成后、推理循环启动前，插入该调用并传入适当的内存阈值参数。作者未公开具体数值，但暗示与模型权重规模相关。

效果验证：修复后连续运行超过之前的8小时窗口，压缩内存维持在低个位数GB，活动监视器显示的模式回归正常。Python进程内存占用稳定在35-40GB区间，无交换空间增长，推理延迟方差显著收窄。

未解之谜与后续观察

作者坦承仍有不确定之处。set_memory_limit() 的确切语义在MLX文档中未充分阐明——它是硬性上限、软性提示，还是向Metal内存压力系统的信号？不同macOS版本的行为是否一致？长时间运行（24小时以上）后效果是否衰减？

另一个开放问题：该修复的普适性。作者的配置是特定组合——M1 Max、64GB内存、35B MoE模型、多智能体量化栈。更小模型或不同架构（纯Dense vs MoE）是否面临相同压力？M3系列的内存控制器改进是否缓解此问题？

作者提到正在观察的指标：压缩内存与总内存的比值、推理P99延迟随运行时间的漂移率、以及交换空间触发的频率。这些将成为后续调优的基准。

对MLX用户的实际建议

若你在Apple Silicon上运行大模型推理并观察到类似症状——运行数小时后延迟退化、压缩内存异常增长、无明显内存泄漏——检查是否显式配置了Metal内存管理。

MLX的默认行为假设短期推理任务，对长时间驻留服务优化不足。mx.metal.set_memory_limit() 的调用位置很关键：必须在模型加载后、首次推理前，否则Metal已按默认策略分配内存池。

监控指标应关注压缩内存而非仅看总占用。活动监视器的"压缩内存"列是早期预警系统，比交换空间触发更早暴露问题。

最后，作者的经验暗示MLX生态的一个更深层张力：框架设计偏向研究友好（快速实验、单次推理），而生产部署（长时间服务、延迟敏感）需要挖掘未文档化的API角落。这种差距在Apple Silicon的统一内存架构下被放大——硬件的灵活性遇到了软件抽象的粗糙边缘。