若你同时在做检索增强，请先看《Mac 本地 RAG 决策矩阵》，避免索引阶段的 embedding 峰值与对话推理抢同一内存包络。痛点速记：① 同时拉大 num_ctx 与并行聊天，KV 常驻近似成倍放大；② 只盯 GGUF 磁盘体积，忽略 decode 阶段权重与 KV 的带宽形态；③ Ollama 静默升级后延迟突变，却没有模型与守护进程版本台账。平台与节点背景见首页；需要专用机器跑通宵压测或基准扫参，可打开购买页免登录比对各区域方案。
硬件边界
Mac mini M4 使用统一内存：GPU、CPU、NPU 共享同一物理池，拷贝成本低，但上下文、KV 缓存与批处理峰值同属一笔预算。线上压力大致随「同时在飞的 token 量」上升：更长提示、更宽 batch、更多并发会话，都会改变 KV 张量的驻留形态与 Metal 核的占空比。苹果公布的内存带宽是芯片级指标；对本地 LLM 更关键的是持续 decode 能否稳定喂满算力——若活动监视器里内存压力已黄/红而 token 仍在勉强吐出，通常已过膝点：先降量化档、缩短上下文或减并行，再折腾 flash-attn 构建。
Mini 体积下热设计真实存在：短时榜单截图不如连续十分钟稳态验收。风扇变响往往早于你感知到的吞吐下滑，把「桌面常开应用 + 目标并发」一起压进去才算数。
GGUF/量化选型
GGUF 仍是 llama.cpp 生态事实标准；Ollama 底层亦消费兼容权重。2026 年多语种与代码场景里，Q4_K_M 与 Q5_K_M 仍是默认甜点：主观质量接近半精度而显著压低每 token 带宽。IQ 系列在极限省字节上更狠，但务必用自家 eval 集过一遍——工具调用 JSON、长表格往往先露馅。MoE 要按「激活参数量」理解峰值，路由仍可能把专家块顶进缓存；务必将模型修订、量化名、chat 模板与启动命令写进 runbook，避免「昨天还能跑」类玄学。
# llama.cpp 骨架示例（路径与构建参数请按本机调整）
./llama-cli -m ./models/model.Q4_K_M.gguf -c 8192 -b 512 -ngl 99并发与批大小
llama.cpp 直接暴露旋钮：上下文 -c / --ctx-size，批 -b / --batch-size（及可用的 -ub），Metal 层 offload 用 -ngl。提高 batch 利于预填吞吐，但会抬高首包前 RSS；过小则 GPU 吃不饱。推荐落地顺序如下。
1. 冻结上下文目标。 按业务硬上限设 num_ctx，并在客户端再设一道 prompt token 硬帽。
2. 扫 batch 曲线。 在 {128,256,512,1024} 上测首 token 与峰值内存，选增益开始变平的拐点。
3. 写死启动快照。 记录完整命令行或 Modelfile，含 llama.cpp commit 或 Ollama 应用版本。
4. 十分钟浸泡。 用目标并发与真实桌面负载压测，记录 RSS、swap 与 tokens/s。
5. 定义回滚。 内存压力超阈 60 秒即自动降档量化或缩短 ctx，避免人工半夜救火。
Ollama 侧重运维体验：在 Modelfile 里写 PARAMETER num_ctx、num_batch、num_gpu（版本支持时），用 OLLAMA_NUM_PARALLEL 控制并行；每路并行≈复制一份 KV 预算，API 突发时宁可客户端排队也不要让守护进程超卖统一内存。
| 关注点 | llama.cpp（CLI / server） | Ollama（守护进程 + API） | M4 / 统一内存提示 |
|---|---|---|---|
| 上下文窗口 | -c / --ctx-size；支持 YaRN 时另配映射 |
PARAMETER num_ctx 或拉取默认 |
ctx 变长，KV 字节近似线性涨；盯内存压力而非仅 GGUF 体积 |
| 预填 / micro-batch | -b / --batch-size、-ub |
PARAMETER num_batch，可能受模型默认限制 |
增大 batch 换首包，直到 RSS 触顶前收手 |
| GPU 卸载 | -ngl 指定层数上 Metal |
多数自动；部分构建可 hint num_gpu |
部分卸载省 RAM 但可能搬家瓶颈；以端到端 tokens/s 为准 |
| 并发会话 | 多进程多端口，各自一份 KV | OLLAMA_NUM_PARALLEL + 客户端队列 |
五用户各 32k ctx 在纸面上极贵；优先队列或第二台机器 |
| 带宽代理信号 | tokens/s 与内存压力对照；新构建可减少 KV 流量 | 信号相同，旋钮更少、版本影响更大 | GPU 有空隙而 decode 卡，先怀疑带宽与 batch 匹配 |
本地推理上线清单（可贴显示器旁）
- 模型台账：GGUF 文件名、量化、SHA-256、tokenizer 模板、运行时版本。
- 内存包络：冷启动、首请求、十分钟浸泡下的峰值 RSS 与 swap。
- 上下文策略：dev/stage/prod 各自硬上限
num_ctx。 - Batch 结论：胜出的
-b/num_batch与预填 p95。 - 降级路径：压力持续超阈时自动换小量化或短 ctx。
- 可观测：提示/生成 token 与错误带时间戳，日志轮转在
~/Library/Logs或服务目录。
可引用速记（写进评审纪要）：① 统一内存下 KV 随 ctx 近似线性扩张；② Q4_K_M / Q5_K_M 仍是默认性价比档；③ 并行会话等价于在单卡上叠多套 KV 预算。
稳定性 FAQ
生成几分钟后吞吐崩盘？ 多为热滚动均值、后台压缩或 Spotlight / 时间机器 / Xcode 索引争用。减并行、关干扰任务，用十分钟曲线复现。
Ollama 升级后谁动了我延迟？ 守护进程与 blob 同步变；生产请钉版本，必要时内网镜像只读存储。
batch 越大越好吗？ 否；过膝后收益有限且混合长度 prompt 易 OOM。有界 batch + 超长 system 提示客户端分块更稳。
要关 Metal 排错吗？ 仅短时 bisect 数值或模板问题；CPU 路径不能当容量规划依据。
多人共用一台 Mac？ 统一内存下「五人各长 ctx」极贵；交互序列化、排队，或租第二节点再堆上下文。
小结：把上下文、批大小、量化与并行看作一根杠杆上的四个把手；用稳态而不是秒级截图做验收，台账与降级写进 runbook，并让重索引与对话服务错峰——这与前文 RAG 矩阵里的「内存峰值纪律」是同一套工程习惯。