12G 本地推理生产线 ② 三维 OOM 账本：host RAM、VRAM、磁盘三道账怎么列

本地跑大 MoE，OOM 不是"一种事"，是三个维度各自独立的三种死法。SC117 IQ3_S（expert arena 46.84G）在我这台机器上，一个下午把三种全摸了一遍。这篇把三维账本一次列清。

死结一：host RAM —— “引擎进程被内核杀掉”

现象：引擎刚把专家权重全部 pin 进内存，the engine stopped unexpectedly (exit code -9)，回答丢失，任务全废。

取证（dmesg 无权限时走这里）：

grep "Out of memory" /var/log/kern.log   # 内核 OOM killer 记录
free -h && swapon --show                  # 当前内存 / swap 状态

账本：IQ3_S 的 46.84G expert arena 全量 pin + 系统本身 + 桌面 → 超过 62G 物理内存，内核 OOM killer 出手（引擎自设 oom_score_adj 200，优先被杀——这是引擎的自我牺牲设计，别误读成"引擎有 bug"）。

修法：--mmap-experts + --resident-budget-gib 32。语义：热度最高的 32G 专家 pin 在内存，其余走文件 mmap 按需读。改完 RAM 账 = 32G pinned + 1.8G（131K 全量 KV）+ 系统 8–10G ≈ 42–46G / 62G，过。实测稳定 46–48G。

死结二：VRAM —— “专家缓存 0 slots，引擎拒启”

现象（最迷惑的一种）：引擎日志自己报：

expert cache auto: 1.03 GiB free, 1728 MiB reserved (+86 MiB for the draft head) -> 0 slots
no VRAM is left for the expert cache: it needs at least 326 slots (827 MiB)

账本：VRAM 12G 的分配顺序 = 会话 KV + 基础占用 + 预留池（--vram-reserve-mib，verify arena 与 draft head 从这里面出）+ 专家缓存（auto = 剩下多少装多少）。四项加起来不够 326 slots 的下限（827 MiB），引擎直接拒绝启动——这比 OOM 温和，它宁可不开。

修法（引擎日志里给的 To make room 清单，按代价从小到大）：

1. 关掉其他占 GPU 的程序（本卡桌面基线 ≈ 2.3–2.4G，超了就是脏环境，见第 3 篇）
2. 降 --max-context（131K 的会话 KV 占 ~595 MiB，降 32K 直接省一半以上）
3. --kv q4_0（KV 再省一半，质量代价，写作场景慎用）
4. 换更小的 --vram-reserve-mib（300 就够小卡；但 verify 池会被掏空，见第 3 篇 的 #496 教训）
5. 图片走 CPU（vision.gpu false）
6. draft 子集换英文（省 86 MiB draft head）

一次只动一个杠杆，每动一次重算账本。

死结三：磁盘 —— “能跑，但慢到没法用”

mmap 方案下，冷专家从模型文件按需读。文件 tier 的账（实测 131K 版第 4 请求）：

file tier I/O this request: the OS read 625.4 MB from storage (4,811 major faults)
                            for 1,936.9 MB of expert blobs

现象特征：不崩、不拒启，只是速度从 45+ t/s 掉到 30 t/s 档，命中率跌到 18–26%。这类"软 OOM"最难诊断——一切看起来都正常，就是慢。

修法：提高 --resident-budget-gib（让更多专家常驻内存，减少文件读）或优化 profile（--expert-profile 排序让热点专家优先入缓存）。注意 RAM 账本联动：预算每 +8G，host RAM 峰值 +8G，62G 机器的 55G 安全线是硬顶。

三维账本速查表

排障铁律：三个维度的数字（free -h、nvidia-smi、引擎日志 I/O 行）互相不可替代——33.02 GiB= 专家加载量、660 experts 0.90 GiB= 专家缓存、arena 1.43 GiB= 打包 arena，不同对象，别互相凑数判断"泄漏"。下一篇：显存调优深水区。