128G统一内存，听起来是本地模型玩家的终极配置。可真跑到5个模型常驻内存的工作流时，我发现内存自由完全是相对的。我日常要同时养活代码补全、RAG嵌入、语音转写、对话主模型、待评估新模型这5个角色，最早是每个模型一个终端窗口，手动启动、手动切换，内存告急时还得想清楚先杀哪个。后来实在忍不了，花了两周写了个模型管理器，统一负责加载、卸载、排队和健康检查。跑通之后整体很稳，但过程一点也不顺利，前前后后踩了七个坑，其中有两个差点把系统整到卡死。这篇文章把设计思路、踩坑过程和最终参数完整记录下来，如果你也在统一内存机器上折腾多模型部署，大概率能用上。
1. 为什么统一内存改变了多模型管理的玩法
1.1 统一内存到底“统一”了什么
在M系列芯片上，CPU和GPU共享同一块物理内存，GPU没有独立显存，靠统一内存池直接访问权重数据。这和传统PC那种“显存8G、内存32G”的分离架构完全不同，模型不需要从内存拷贝到显存，而是直接映射到GPU可访问的地址空间。
这个架构带来的直接好处是：一个7B模型fp16权重约14GB，在传统机器上你可能要先加载到内存，再花几十秒拷贝进显存，显存不够还得换量化版；而在统一内存机器上，加载就是内存映射，模型权重放那儿，GPU直接读。
代价也很明显：所有模型共用同一个池子，你加载得越多，系统内存压力越大。macOS会启动压缩和换页策略，一旦swap占用上来，整个系统包括鼠标、键盘都会跟着卡。所以哪怕128G看起来很大，5个模型同时常驻，如果不做管理的，吃到90GB以上非常正常，系统就开始进入“勉强可用”状态。
1.2 内存账到底怎么算
我一开始犯过一个错误：以为5个模型权重加起来小于128G就行。实际上每个模型在推理时还要额外占用显存缓冲区，包括KV cache、激活值、临时张量。一个7B模型fp16权重14GB，实测峰值占用通常在17~19GB；4bit量化版权重约5GB，峰值要到7~8GB。Embedding模型小，但多个微服务进程叠加后也有几GB。
我用一套5模型组合做了个预算表：
| 模型 | 用途 | 权重形式 | 常驻内存预算 |
|---|---|---|---|
| Code模型 | 代码补全 | 7B 4bit量化 | 8GB |
| Embedding模型 | RAG向量化 | bge-m3 | 2GB |
| 语音转写 | ASR | whisper-large-v3 4bit | 4GB |
| 对话主模型 | Agent主力 | 14B 4bit量化 | 12GB |
| 待评估模型 | 新模型对比 | 7B fp16 | 17GB |
合计大约43GB，加上系统本身占用、浏览器、开发工具等，差不多53GB，看起来离128G还有很大余量。但实际跑起来，只要你启动多个worker、各自带缓存和历史上下文，很容易突破80GB。原因主要有三个：多次加载同一模型不释放旧副本、推理完的缓存不回收、多个worker之间缺乏全局内存感知。
1.3 5个模型同时在线到底是不是伪需求
有人会问，为什么不按需启动，用哪个启哪个？真实工作流里这话不成立。白天写代码时code模型和embedding模型会交替命中；开会录音转写可能和RAG检索同时发生；对话主模型又是Agent的入口。如果你把每个模型的启动时间都按分钟算，用户体验根本没法接受。
我做过粗略统计：一个7B fp16模型冷启动需要40秒左右，4bit量化版快一点也要25秒；whisper-large冷启动需要20秒。如果每次调用都等冷启动，工作流基本没法用。所以管理的核心目标不是“按需启动”，而是“让常驻模型稳定活着，并在内存不足时按策略取舍”，这才是管理器存在的真正理由。
2. 管理器整体设计：不是API网关，是资源调度器
2.1 架构选型：多进程隔离远比单进程优雅
我第一版管理器为了省事，把所有模型塞进同一个Python进程，通过轮询加载和卸载。结果遇到一个很现实的问题：transformers、whisper、sentence-transformers这些库各自持有全局状态，GIL让并发推理卡得一塌糊涂，而且一个模型的缓存无法独立释放。
后来我改成了完全不同的架构：每个模型一个独立worker进程，管理器（supervisor）只负责拉起、监控、杀进程和转发请求。worker之间零共享，一个模型崩溃不会波及别人；要释放内存时，直接kill进程是最硬核也最可靠的手段。这个架构的选择依据很简单：统一内存是操作系统级的资源池，多进程反而是更安全的隔离方式，因为每个worker的RSS可以被精确计算和回收。
设计结构大致如下：
- supervisor：HTTP服务，负责接收用户请求、路由模型、维护状态机
- agent：每个worker内部有一个轻量agent，负责加载模型、推理、上报心跳和内存占用
- 共享存储：一个SQLite数据库记录请求日志、模型状态、内存指标
2.2 调度策略：配额、冷却、优先级三层控制
管理器的调度不是简单的“谁最近没用就卸载谁”，我做了三层策略：
第一层是配额层。每个模型有独立的最大允许内存，例如code模型不超过10GB，对话主模型不超过15GB。worker如果超过配额，agent会主动触发进程内清理或重启，避免它把池子吃光。
第二层是冷却层。模型连续空闲超过一定时间（默认5分钟）会被标记为可卸载状态，但不会立即卸载，只有内存压力达到阈值时才真正卸载，避免模型颠簸。
第三层是优先级层。每个模型有固定优先级，比如对话主模型优先级最高，待评估模型优先级最低。当新请求需要加载一个未就绪模型但内存不足时，管理器从低优先级、冷却时间最长的模型开始挑“牺牲者”。
2.3 健康检查与状态机设计
每个worker有五个状态：idle、loading、ready、busy、unloading。状态流转必须严格，比如busy状态下不能接收卸载指令，loading状态下不能重复加载。我遇到的最大坑是busy状态卡死，worker推理一个长上下文请求，30秒还没返回，健康检查直接判定超时并kill进程，结果请求丢失、状态卡在busy。
最终我改成双通道健康检查：控制面和业务面分离。控制面探针只检查worker进程是否存活，业务面探针专门测推理响应，两个通道的超时独立设置。这样即使业务慢，控制面也不会误杀进程。
3. 七个坑逐个拆解，每一个都是换来的经验
3.1 坑一：模型对象被全局引用，卸载函数白写
这是最常见也最隐蔽的坑。我在agent里写了很标准的unload代码：先del model，再torch.mps.empty_cache()，最后gc.collect()。但内存就是不降。查了半天发现，模型对象被一个全局服务注册表（用来做metrics采集）持有引用，del根本不会触发析构。
后来我用gc.get_referrers(model)找到了所有持有者，把那类引用改成弱引用，卸载才真正生效。教训是：写出unload之后，至少要检查一遍“谁还持有这个model的引用”，不能只看卸载函数本身。
3.2 坑二：PyTorch的MPS缓存不吃“卸载”这一套
卸载函数本身没问题之后，我发现另一个现象：worker进程还在跑，卸载后内存只降了一点，大部分显存池被MPS的缓存分配器锁住了。PyTorch在MPS后端会维护一块巨大的缓存，释放张量后，内存块不会立刻还给系统，而是留在进程内复用。
PyTorch官方给了torch.mps.empty_cache()，但它只清空缓存，有时候Metal驱动还有自己的延迟回收机制。最稳妥的方案其实没什么技巧：直接杀worker进程，让操作系统把整个进程的内存收回去。所以我的管理器里，卸载操作默认走“优雅退出→超时强杀”的路径，而不是试图在进程内清理。
3.3 坑三：多模型并发推理把Metal后端干挂了
有几天系统特别奇怪，界面不卡，内存也没爆，但推理请求发出去后十几秒没有响应。排查后发现是并发推理的问题：MPS后端内部有资源锁，多个进程同时向Metal提交计算任务时，会互相阻塞甚至引发死锁。
我没去硬碰Metal的并发限制，而是给管理器加了一个全局推理信号量，同一时刻只允许一个worker执行推理，其余排队等待。这个设计牺牲了并发能力，但换来了稳定性。实测两个模型同时推理时，总吞吐反而下降60%，排队反而更快。
3.4 坑四：内存压力爆表，整个macOS开始swapping
一天下午我正开着5个模型跑批测，突然发现鼠标都开始飘，活动监视器里内存压力变成红色。查看vm.swapusage发现swap已经占了几十G。原因是我把内存阈值设得太晚，等可用内存只剩十几G才开始卸载，macOS早就进入了高度压缩模式，系统几乎来不及响应。
macOS有一个memory_pressure机制，它会提前触发compressor和swap，而不是等物理内存完全耗尽。所以管理器的阈值必须远低于物理内存总量。我最终把“触发卸载”的阈值设置在物理内存的70%左右，128G机器就是89GB触发第一波冷却，80GB触发强制淘汰。这样留足了缓冲给系统自己用，UI再也没卡过。
3.5 坑五：冷热切换策略导致模型颠簸
刚开始我用的策略很简单：内存压力上来后，把最久未使用的模型卸载掉。听起来很合理，实际跑起来发现一个致命问题：如果正在用的模型刚好有两个交替请求，LRU会让两个大模型互相淘汰，每一个请求都要重新加载，响应时间从2秒变成20秒，整个工作流彻底没法用。
我开始给加载成本加权重，在判断是否卸载时不再只看最后使用时间，而是估算“卸载后下一次加载需要多少秒和多少内存”。后来又试了给内存压力信号做滑动窗口滤波，取过去两分钟的加权平均，避免瞬时的内存抖动触发误判。这一套组合拳下来，颠簸问题才算解决，5个模型的响应时间都稳定了下来。
3.6 坑六：进程通信超时设置太短，启动一次断一次
管理器刚上线时，worker加载模型需要30秒，但我在supervisor里设置的启动超时是10秒。结果就是：worker加载到一半被判定“启动失败”，supervisor kill掉重启，又一次加载到一半被杀，循环往复。
这个问题的本质是我把“启动就绪”误当成“业务响应”来监控。正确的做法是：worker加载过程中主动上报loading状态，supervisor收到状态就说明还活着，不需要设死板超时。后期我把超时机制改成两段式：启动阶段只看heartbeat，只要worker在报loading就不杀；加载完成后才切换到业务响应监控。另外推理侧的超时也独立开，长上下文请求可以占用更长时间，避免被健康检查误杀。
3.7 坑七：5个模型依赖共享同一个环境，库版本互踩
这是最让人崩溃的一个坑。embedding模型用的是sentence-transformers，语音转写用whisper，对话模型用transformers，三个模型对tokenizers这个包的版本要求都不一样。pip install的时候看起来很顺利，跑起来却是各种AttributeError，改一个依赖另一个模型就挂。
最终方案是为每个worker创建独立虚拟环境，管理器在启动worker时指定python解释器路径。磁盘空间多花了几GB，但依赖互相污染的问题彻底消失。还有一个隐藏变体：环境变量也会串。比如PYTORCH_ENABLE_MPS_FALLBACK在一个模型里设了，所有worker都继承，导致某些张量操作悄悄落到CPU上，速度直接下降几倍。这类全局变量必须在每个worker的启动配置里单独控制。
4. 监控与指标：没有数据，你根本不知道坑在哪
4.1 四个必看指标
排坑过程中我发现，管理器没有数据支撑就等于盲人摸象，最终我固定采集四个核心指标：
- 系统内存压力：memory_pressure -Q，查看当前压力的sampled value，可以区分绿色、黄色、红色
- swap占用：vm.swapusage 里的 swap_used，只要这个数持续增长，说明已经进入换页状态
- 每个worker进程的真实RSS：ps -o rss 按进程区分，能看出是谁在吃内存
- Metal分配情况：活动监视器或sudo purging看缓存清理效果，但purging不能救进程内缓存
我还把四个指标汇总成一条命令，每周定时截图对比：
ps aux | grep -E "worker|supervisor" | awk '{print $2, $6/1024"MB", $11, $12}' \ && vm.swapusage && memory_pressure -Q这条命令三十秒跑一次，配合日志可以看到内存增长的曲线，特别是谁在缓慢泄漏、谁在突然暴涨，一目了然。
4.2 日志应该记什么
我最早只记录请求成功失败，排坑时发现信息完全不够。改进后的日志格式每一条请求至少包含五个字段：请求ID、模型名、阶段（loading/infer/preempt）、耗时毫秒、内存增量。为了完整回溯模型颠簸，还单独记了一条“淘汰决策”日志，内容包括候选模型、决策原因、当前内存压力、淘汰后释放了多少内存。
有了这些日志之后，问题定位速度快很多。有一次看到某个worker的RSS在每次推理后都涨200MB且不回落，顺着日志找到是某版本transformers的past_key_values缓存没释放，升级版本解决。这种问题纯靠猜方案，没有日志基本无从下手。
4.3 告警设临界值要提前，而不是等系统卡死
我设了三个告警级别：内存压力达到75%时，管理员会收到提醒；达到85%时，管理器自动执行强制淘汰策略，优先卸载最低优先级模型；达到90%时，停止接收新的非核心请求，只保留对话主模型和embedding服务。这个阶梯式设计保证了系统能始终留有一定余量。
5. 实测效果与调参心得
5.1 稳定运行后的资源占用情况
经过几轮调整，5个模型可以稳定同时在线，内存占用如下：
| 进程 | 常驻RSS | 峰值RSS | 备注 |
|---|---|---|---|
| code worker | 6.2GB | 8.3GB | 4bit量化，代码补全 |
| embedding worker | 1.8GB | 2.4GB | bge-m3 |
| ASR worker | 3.5GB | 4.7GB | whisper-large-v3 4bit |
| main worker | 11.5GB | 15.1GB | 14B 4bit量化 |
| eval worker | 14.5GB | 17.8GB | 7B fp16 |
| supervisor+系统 | 9.0GB | 11.0GB | 管理器、日志、系统服务 |
日常运行总占用约46.5GB，压力测试时峰值接近66GB，距离128G的物理上限还有充足余量，即使同时开浏览器和其他开发工具，内存压力也始终维持在绿色区间。
5.2 关键参数参考值
我整理了一份当前正在使用的参数表，不一定适合所有人，但可以作为起始参考：
| 参数项 | 数值 | 说明 |
|---|---|---|
| 触发淘汰内存阈值 | 物理内存72% | 128G机器约89GB |
| 强制淘汰阈值 | 物理内存80% | 128G机器约102GB |
| 空闲冷却时间 | 5分钟 | 低于这个值不卸载 |
| 推理并发数 | 1 | 全局信号量，避免Metal冲突 |
| 幂等重启次数 | 3次 | 超过3次进入双端隔离排查 |
| 启动探针超时 | 加载预估时间1.5倍 | 只看心跳，不看业务响应 |
| 长上下文推理超时 | 120秒 | 单独设置，独立于心跳探针 |
| 滑动窗口滤波 | 120秒均值 | 用于稳定内存压力输入信号 |
5.3 还想继续压榨空间的方向
管理器跑稳之后，我开始想下一个优化方向。第一个方向是把所有模型尽量统一到同一基座（比如都基于Qwen架构），然后通过mmap共享权重页，两个模型如果共用某几层，物理内存里只存一份。第二个方向是把待评估模型改成更小的蒸馏版本，跑初步对比评估时不至于占掉14GB。第三个方向是研究MLX框架的加载方式，有些模型用MLX后加载速度更快、峰值内存更低。
写在最后的一些体会
跑完这个项目，我最深的感受是：管理器最值钱的部分不是调度算法，而是它给每个模型建立了“账单”。哪个模型天天吃内存、哪个模型每次推理都会产生额外开销、哪次淘汰决策是错误判断，这些数据记录下来之后，你对整个系统的理解会完全不一样。以前我凭感觉调内存，现在全是看数字说话。最后分享一个小技巧：如果你的多个模型都基于同一个基座，先加载基座权重，再加载各自的LoRA或者局部权重，内存占用可以压到很夸张的程度，128G跑六七个模型也不是不可能。
