Mac跑本地模型，内存该怎样估算

判断本地 LLM 能不能跑，光看模型文件有多大，很容易高估 Mac 的承载能力。作者在一台 16 GB 的 MacBook M5 上测试后提出：模型权重、上下文缓存、系统和应用，要一起算账。模型装得下，也可能因为内存竞争慢得难以日用。

这篇最有用的，是把「能加载」和「用得顺」分开讨论。不过，提供的原文缺少标题所说的完整容量表，实测数据也不完整，选配置时需要区分哪些是测量结果，哪些只是估算。

模型文件只有 8 GB，为什么还会卡

本地推理主要消耗三部分内存。

第一部分是权重。按 4-bit 量化，也就是 Q4、MLX 4-bit，作者给出的粗估是每十亿参数约 0.5 GB。实际示例中，8B 约 5 GB，14B 为 8–9 GB，32B 为 18–20 GB，70B 约 40 GB。这些是预算参考，不能当成精确文件大小。

第二部分是上下文的 KV cache。模型为了接着生成，会保存各层处理已有 token 的中间结果。文本越长，通常缓存越大。作者提醒，Ollama 和 LM Studio 会按配置的整个窗口预留内存，而不只是按实际发送的文本分配。

因此，只问几句短问题，却配置 128K 窗口，也可能占住大量暂时用不到的空间。

第三部分是 macOS 和其他应用。作者的 16 GB Mac 上，Metal 的 recommendedMaxWorkingSetSize 为 12.7 GB，约占总内存的四分之三。他据此采用预算规则：

权重 + 上下文缓存 ≤ Mac 内存的 ¾。

这是一条经验规则。可以通过 sysctl iogpu.wired_limit_mb 提高 GPU 内存限制，但留给应用的空间会缩小，系统也可能开始交换内存。提高限额并不会凭空增加可用资源。

长文档能塞进去，不代表能很快读完

作者的测试环境是 Apple M5、16 GB、Ollama 0.31 和 MLX builds。原文称测了三个模型，但所给内容只展开了 Qwen 4B 和 Gemma 12B 的部分结果，没有完整三模型数据。

测试分三档：150 词商务邮件配 4K 窗口，4.2K-token 文档约 10 页配 8K 窗口，18K-token 文档约 45 页配 32K 窗口。长文档任务要求提炼五个要点，回答最多 200 tokens，内存取自 ollama ps。

结果里有两件事值得分开看。

首先，新架构的缓存可能更省。32K 窗口给 Qwen 4B 增加约 1.4 GB，给 Gemma 12B 增加约 1.6 GB，折合每 token 约 50 KB。作者将其归因于 Qwen 3.5、Gemma 4 多数层使用有限窗口注意力。不过，提供的文本没有列出完整模型标识和配置，不能据此推断整个系列都一样。

其次，长文档的主要痛点可能是等待。Qwen 4B 处理短问题用 8 秒，处理约 45 页文档用 67 秒；Gemma 12B 处理同一长文档接近五分钟。作者据此描述，模型大三倍，读取慢约四倍，这是这组测试的观察。

同一模型也会受后台负载影响。Gemma 首次处理约 10 页文档时，作者同时在电脑上工作，耗时 169 秒、速度 4 tok/s；系统空闲后重跑，变成 57 秒、16 tok/s。

「模型能跑」和「工作时能顺畅地跑」，是两个验收标准。

上下文该怎么设，内存才不白花

经典架构的缓存成本更容易估算。作者以 Llama 3、Qwen 3 和多数 2025 年模型为例：每层缓存整个窗口，默认 16-bit KV cache 的每 token 成本为：

2 × layers × KV heads × head dim × 2 bytes

窗口长度再乘进去，才是总缓存量。作者依据 Hugging Face 的 config.json 计算，经典 Llama 8B 每 token 约需 128 KB；完整 128K 窗口下，经典模型的缓存可接近其 4-bit 权重大小，70B 的权重加缓存约需 80 GB。

省内存可以先做三件事：

• 按任务设置窗口，Ollama 调 num_ctx，LM Studio 调 Context Length，短对话不必默认开到 128K。
• 对 Ollama 中的 GGUF 模型，配置 OLLAMA_KV_CACHE_TYPE=q8_0，并启用 OLLAMA_FLASH_ATTENTION=1。作者称缓存可减半、质量影响较小，并据此估算 32B 配 128K 窗口可放进 64 GB。
• 长文档优先比较缓存结构，同时关闭不用的应用。16 GB 上，十几个浏览器标签页和 Xcode 都在竞争同一块统一内存。

这里的缓存压缩建议限定了 GGUF 路径，不能直接套到文中所有 MLX 构建上。

我的判断

这篇说得最对的，是把容量问题变成「权重、窗口、后台负载」的共同预算。对日常开着浏览器和编辑器的程序员，比单看参数量更实用。

但购买建议只能作起点。作者将 16 GB 定位于 4–12B 短文本助手，32 GB 定位于文档工作的合理起步配置，并称 14B 配 32K 窗口较宽裕；48–64 GB 面向 32B，96–128 GB 面向 70B 和大型 MoE。这些并非各档机器的逐一实测。

尤其是「32B 在日常任务上不再输给云端」，没有任务集、质量评分或云端模型对照，属于经验判断。相比只按参数量选模型，我更认可先按真实任务测试；相比直接加内存，先缩窗口也更容易验证收益。原文还没有拆分首字等待与生成耗时，不能只凭总秒数解释全部性能差异。

能拿来做什么

• 给本地助手设两个常用窗口配置，分别服务短对话和长文档，避免所有请求都按最大窗口预留内存。
• 在日常浏览器、编辑器都开着的状态下，拿真实文档跑一次，再在空闲状态复测，同时记录 ollama ps、总耗时和输出速度。
• 买 Mac 前先明确常用模型与文档长度，再用「权重 + 缓存 ≤ ¾ RAM」做初筛，把作者的容量分档当作候选范围。