01 · 开箱点火：64GB 统一内存到底意味着什么
约 9 分钟驭光者首发于微信公众号「羲和Lab」
系列：mac mini 玩转本地大模型 · 第 1 篇 副标题：跑模型之前，先认识你的燃料
导读：64GB 是财富还是数字？本篇把统一内存从配置单上的一串字符，变成你心里的一本账——它决定你能跑多大的模型、跑多快、还剩多少。附 16 进程满载真机压力实测与三条"燃料盘点"命令。全文不装任何软件，动手从下一篇开始。
开始之前
- 适合谁：想在 Mac 上跑本地大模型的读者（不限 mini，Apple Silicon 通用；Windows/独立显卡读者可作对照阅读）
- 需要什么：读完 00 篇的配置（或等效环境）+ 一颗想搞明白原理的心
- 预计耗时：纯阅读 12 分钟；跟着敲命令再加 2 分钟
- 本篇实测环境：Mac mini M5 Pro 高配版（18 核 CPU / 20 核 GPU / 64GB / macOS 27.0），全部命令与输出真机验证（2026-09-23）
一、开篇：点火之前，先认识燃料
00 篇结尾我们埋了三颗种子：散热摆放、存储规划、断电自启。这一篇兑现前两颗——顺便把最核心的那份家底彻底盘清楚：64GB 统一内存。
对跑本地大模型的人来说，这串数字不是营销话术，是一切的边界。它决定你能跑多大的模型（容量）、跑多快（带宽）、同时开多长的对话（余量）。配置单上它是一行字，用起来它是一本账。
这一篇我们不上手装任何东西——先算账，再验机，然后选路线。账算明白了，下一篇装 Ollama 时你会知道每个数字为什么是那个数字。
二、统一内存 vs 显存：一堂必修课
2.1 先看传统 PC：两个水池
传统 PC 的内存世界是双池架构：内存条归 CPU 用，显存焊在显卡上归 GPU 用，两池物理隔离。跑大模型时，想要能用的速度，模型的全部参数就得住进显存——GPU 算得快，而它只看得见自己的显存。（CPU offload 可以把放不下的层挪到内存兜底，但速度断崖式下跌，实践上显存容量仍是第一门槛。）
这带来一个残酷规则：塞不下就是塞不下。一张 16GB 显存的显卡，跑不动需要 20GB 的模型，没有商量。买什么显卡、多大显存，就成了传统 DIY 大模型玩家的第一道门槛——也是最贵的一道。
2.2 Apple Silicon：一个大水池
Apple Silicon（M 系列芯片）把 CPU、GPU、神经网络引擎做进同一块芯片，让它们共享同一池统一内存（Unified Memory Architecture）。没有"内存条"和"显存"之分，只有一个大水池，谁需要谁舀水。
对跑模型意味着什么？"显存"变成了一个动态借用的概念：GPU 需要多少，就从 64GB 的池子里锁多少。你不需要为显存单独花钱、单独规划——这正是 Mac mini 跑大模型的吸引力来源。
2.3 真相一：64GB 不等于 64GB 显存
统一内存听起来像"全都能给 GPU 用"，但有两个限制必须先说清，否则期望会错位。
第一，没有"全部给你"的好事。 macOS 对 GPU 可用的内存设有推荐工作集上限（Metal 的 recommendedMaxWorkingSetSize，历史口径约为总内存的三分之二到四分之三，以当期系统为准）——不是硬性死线，但应用普遍遵循；我们实测 macOS 27 的 GPU 内存参数（sysctl iogpu 输出 dynamic_lwm: 1）也印证了动态管理策略：实际额度随整机负载浮动。再叠加系统自身占用——macOS 自己要住在这池子里，浏览器、编辑器、后台服务都在舀水。
第二，实践上要给系统留出生存空间。 macOS 加日常应用通常要吃 8-16GB。把这些扣掉，64GB 机器真正能稳定交给模型的，心里的账要按 42-48GB 区间来打（与上文工作集上限口径咬合）。留余量是纪律，不是玄学。
2.4 真相二：容量决定能不能跑，带宽决定跑多快
第二个常见误区是以为"内存够大就快"。其实大模型推理有个物理规律：每生成一个 token，GPU 都要把整个模型读一遍。所以内存充足时，生成速度首先受内存带宽约束——带宽就是这池水的"管道粗细"。
M5 Pro 的官方内存带宽是 307GB/s。给你一个量级参照：当前官网在售的 M6 基础款为 153~170GB/s（依内存配置；与 M5 Pro 不同代、不同档位，不可直接比较，仅作管道粗细的量级参照，来源：苹果官网技术规格页，2026-09-23 查询）。管道粗细差一倍，跑同一个大模型的速度量级就差一倍。
具体快到多少？粗算公式放在下一章的"运行账"里——先记住定性结论：容量决定能不能跑，带宽决定跑多快。
三、跑模型前要算的三笔账
现在正式开账本。三笔账算完，任何模型摆在你面前，你都能估出它在你机器上的命运。
3.1 体积账：模型文件有多大
速算公式：
模型文件大小 ≈ 参数量 × 量化位宽 ÷ 8（GB 口径，B 参数 × bit ÷ 8 = GB）
以 Q4 量化（4 bit，最常用的平衡档）为例：
| 模型规模 | 速算 | 文件大约 |
|---|---|---|
| 7B-Q4 | 7 × 4 ÷ 8 | ≈ 4GB |
| 32B-Q4 | 32 × 4 ÷ 8 | ≈ 16-18GB |
| 70B-Q4 | 70 × 4 ÷ 8 | ≈ 35-40GB |
误差说明：Q4 实际并非精确 4 bit（有效位宽约 4.5），GGUF 文件还带格式开销，各家模型的实际大小会在速算值上下浮动——速算用于建立量级感，精确数字以下载页标注为准。
顺手算磁盘账（00 篇种子二兑现）：模型是囤起来最凶的资产。7B 一个 4GB，70B 一个 40GB，再来三四个备选量化版本，256GB 的盘很快见底。建议现在就想好模型统一放哪个目录，量大时外接 SSD 专放模型。
3.2 运行账：跑起来实际吃多少
文件大小只是"体重"，跑起来的"食量"更大：
运行内存 ≈ 模型权重 + KV cache + 计算缓冲 + 框架开销
权重就是文件那 40GB；计算缓冲和框架开销零头不大；真正会随使用暴涨的是 KV cache——模型对对话上下文的记忆缓存，随上下文长度线性增长。
给个锚点（以 GQA 架构的 70B 级模型为参考，实际模型而异）：8k 上下文的 KV 约 2-3GB，拉到 32k 就要 10GB 上下。所以 64GB 跑 70B-Q4 的完整账本：权重 40GB + 上下文若干 + 系统占用——上下文建议从 8k-16k 起步，长文档场景再逐步试高（03 篇给公式细算）。
tok/s 理论粗算（承接二章带宽话题）：生成速度上限 ≈ 带宽 ÷ 模型体积。70B-Q4：307 ÷ 40 ≈ 7.7 token/s 理论值——实际会打折（框架开销、调度损耗），但量级是对的：70B 在这台机器上就是"能读但别催它写长文"的定位。7B-Q4 同理：307 ÷ 4 ≈ 77 理论值，实际二三十 token/s 起步——日常对话飞快。（理论粗算口径，02 篇装上模型实测对照。）
3.3 余量账：给系统留多少
macOS + 浏览器 + 聊天工具 + 编辑器，日常 8-16GB 起步。三账相加 ≤ 总内存才算"跑得动"；超了会怎样？swap 警告：系统把内存内容倒到 SSD 上换空间，速度雪崩式下跌，还加速 SSD 磨损。跑模型时看到风扇狂转但 token 龟速，第一反应就该查内存压力（活动监视器 → 内存 → 内存压力曲线，绿色才健康）；终端党一条命令看 swap 现状：sysctl vm.swapusage。
3.4 速查表：你的档位能跑什么
公式给你了，任何内存档位都能自己算。三个代表档位的对照（Q4 口径，"舒服跑"= 不触发 swap + 生成速度可接受 + 留 ≥10% 余量）：
| 内存档位 | 极限可加载（收紧上下文/关后台） | 舒服跑 | 建议起步上下文 |
|---|---|---|---|
| 16GB | 14B | 7B-8B | 4k-8k |
| 32GB | 32B | 14B-32B（32B 上下文收紧） | 8k |
| 64GB | 70B | 32B（甜点位）；70B 限低上下文单请求 | 70B ≤8k-16k / 32B 16k+ |
"极限可加载"不等于"舒服跑"——超过舒服档位会显著掉速甚至触发 swap，日常使用以"舒服跑"列为准。一句话总结这张表：64GB 的甜点是 32B-Q4——上下文余量充足、速度体面；70B 能加载，是"压轴菜"而不是"日常口粮"。
四、散热与噪音：短时压力实测
内存账算完，再看这台机器扛不扛得住长时负载。
我们在真机上做了一次可照做的压力实测（你可以直接复制这条命令）：
pmset -g therm; for i in {1..16}; do yes > /dev/null & done; sleep 150; pmset -g therm; kill $(jobs -p)
一条龙：先拍热状态基线 → 16 个进程把 CPU 吃满 150 秒 → 再拍热状态 → 清理（个别终端下 kill $(jobs -p) 会解析报错；若结束后仍见 yes 进程残留，兜底执行 pkill yes）。实测结果：前后两次 pmset -g therm 均未出现任何系统级警告——热警告、性能警告、CPU 功率状态三行全是 "No ... has been recorded"。如实说明：这条命令只反映警告记录，更细的降频与功耗曲线属于 powermetrics 专业采样的领域，本篇结论止步于"短时满载未触发警告"，02 篇再上仪器。配合官方参数（闲置噪音 5dBA 几乎不可闻、最大持续功率 155W、标称工作温度 10-35°C），M5 Pro mini 的 CPU 满载散热余量相当从容。
如实标注局限：这是 CPU 短时压力（150 秒，未达热稳态），不能直接推导 GPU 长时推理的表现——跑模型是 GPU 连续高负载几小时的场景，那堂课留到 02 篇装上模型后真枪实弹再测。
硬件层面最后一句提醒（00 篇种子一）：mini 底部进风、后部出风，底部留空隙、后方离墙一拳。散热的余量就是性能的余量。
五、工具链全景：三条路线怎么选
账算明白了，机器也验过了，下一个问题：用什么工具把模型跑起来？Mac 本地大模型目前有三条主流路线。
Ollama——命令行世界的宠儿。ollama run 一条命令拉模型开聊，生态最大、文档最全、社区最活跃，从入门到部署通吃。代价是要跟终端打交道。本系列主线（02 篇入门）。
LM Studio——图形界面党福音。点鼠标搜模型、下载、开聊，模型管理直观，内置 MLX 引擎加速。适合不想碰终端的读者（04 篇）。
MLX——Apple 原生框架，最贴近硬件的那条路。速度潜力最大、能做 LoRA 微调（05 篇），但面向开发者，门槛最高。
格式小知识：同一模型常有 GGUF 与 MLX 两种文件格式——前者是 ggml 社区的通用格式（Ollama/LM Studio 都吃），后者是 Apple 原生格式（MLX 专用，LM Studio 的 MLX 引擎也支持）。工具选型与格式绑定，下载模型时看清后缀。
决策树（可执行）：
- 敲命令行不犯怵、要生态和文档 → Ollama
- 只想点鼠标、图形界面管理一切 → LM Studio
- 要微调、想榨干硬件、本身是开发者 → MLX
- 都想试 → 递进着来，三者不互斥（本系列的路线就是 Ollama → LM Studio → MLX）
六、认识你的机器：第一次点火
最后，三条"燃料盘点"命令——这就是本篇的点火仪式。每条都标注了看哪一行，不用全懂：
sysctl hw.memsize
→ 看输出的那串大数字，÷1024³ 就是你的 GB 数。实测输出 68719476736 = 64GB 整，分毫不差。
system_profiler SPDisplaysDataType
→ 看 Total Number of Cores（GPU 核数）与 Metal Support（图形 API 代数）。实测输出 20 核 GPU / Metal 4。
sysctl iogpu
→ 看 dynamic_lwm——GPU 内存管理方式。实测输出 dynamic_lwm: 1，动态管理，对应二章真相一（该参数读数依 macOS 版本而异，本文口径为 macOS 27 实测）。
跑完这三条，这台机器的家底你心里就有数了：多少燃料、多粗的管道、怎么分配。下一篇，第一个模型正式住进盒子。
七、验收与预告
本篇验收，三个问题自查：
- 能用"参数量 × 位宽 ÷ 8"估算任一模型的内存占用吗？
- 知道自己内存档位"能加载"与"舒服跑"的边界在哪吗？
- 选定自己的工具路线了吗？
三个都能点头，燃料课毕业。
下一篇《02 · 第一个模型住进盒子：Ollama 入门》——装 Ollama、拉第一个模型、跑通第一次对话，顺便兑现 00 篇的第三颗种子：把模型装成常驻服务时，验证断电自启。本篇没装任何东西，动手，从下篇开始。
参考资料
- Apple 官网 Mac mini 技术规格（M5 Pro 带宽 307GB/s、M6 基础款 153-170GB/s、155W、5dBA；2026-09-23 查询）：https://www.apple.com.cn/mac-mini/specs/
- Apple Metal 统一内存工作集上限（recommendedMaxWorkingSetSize）：https://developer.apple.com/documentation/metal/mtldevice/recommendedmaxworkingsetsize
- Ollama 官网：https://ollama.com/
- LM Studio 官网：https://lmstudio.ai/
- MLX 项目：https://github.com/ml-explore/mlx
- 本系列 00 篇《点火之前：新 Mac mini 到手配置指南》（对账基准）
免责声明
本文内容仅供学习交流，所述方法需结合实际场景灵活运用。文中性能数字与理论估算是量级参考，实际表现因模型、版本与负载而异；官方参数以苹果官网当期页面为准。
本文由 AI 辅助创作，经人工审核编辑后发布。
本文首发于微信公众号「羲和Lab」，公众号内可留言交流
阅读公众号原文