博客 · AI
用 Mac Studio 跑本地 LLM：36GB 和 96GB 能装下什么
如何判断 36GB 或 96GB 的 Mac Studio 能跑哪些本地 LLM：权重与 KV 缓存计算、模型规模、GPU 内存上限，以及 MLX、llama.cpp 与 Ollama 的取舍。
用 Mac Studio 跑本地 LLM，几乎一切都由内存决定。本文介绍如何估算 36GB 和 96GB 各能装下什么，以及如何把每一档用足。
统一内存为何改变了计算方式
在 Apple silicon 上，CPU 和 GPU 共用一个统一内存池。用于 GPU 推理的模型和 macOS、其他应用放在同一块内存中。没有独立显卡和固定显存，所以真正的问题只有两个：GPU 能用多少内存，模型需要多少内存。
macOS 默认允许 GPU 锁定约三分之二到四分之三的统一内存。36GB 的 Mac Studio 大约是 24–27GB，96GB 的机器大约是 64–72GB。规划时以这些数字为准，而不是规格表上的总内存。
第 1 步：估算权重
模型权重占用约等于参数量乘以每个参数的字节数。4-bit 量化模型的经验值是每十亿参数 0.5–0.7GB，已包含量化系数和运行时缓冲的部分开销。
| 模型规模 | 4-bit（约） | 8-bit（约） |
|---|---|---|
| 8B | 4–6GB | 8–9GB |
| 14B | 7–10GB | 15–16GB |
| 32B | 16–22GB | 34–36GB |
| 70B | 35–49GB | 70–75GB |
这些是规划用的估算值。实际大小因量化格式而异，请以你要加载的模型文件大小为准。
第 2 步：加上上下文（KV 缓存）
第二部分开销是 KV 缓存，它随上下文长度增长。标准 Transformer 的估算公式：
每 token 的 KV 字节数 = 2 x 层数 x KV 头数 x 头维度 x 每个值的字节数以 Llama 3.1 70B 为例：80 层、8 个 KV 头、头维度 128，以 16-bit（2 字节）存储。计算得 2 x 80 x 8 x 128 x 2 = 327,680 字节，每 token 约 320KB。
- 8K token 上下文：约 2.5GB
- 32K token：约 10GB
- 128K token：约 40GB
Llama 3.1 8B 这样的小模型（32 层，KV 结构相同）每 token 约 128KB，32K token 约 4GB。结论是：长上下文占用的内存可能和一个中等规模的模型差不多。很多运行时支持把 KV 缓存量化为 8-bit，开销大约减半，质量损失很小。
36GB（Mac Studio M5 Max）能装下什么
默认情况下 GPU 约有 24–27GB 可用：
- 7–14B 模型轻松运行，8-bit 也没问题，还能留出长上下文或同时加载多个模型。
- 4-bit 的 30B 级模型是最佳区间。32B 稠密模型权重约 16–22GB，剩余空间可支持中等长度的上下文，通常为 8K 到 32K token，具体取决于模型的 KV 结构。
- 总参数约 30B 的混合专家（MoE）模型占用相近的内存，但生成速度比同规模稠密模型快，因为每个 token 只激活一部分参数。
- 70B 级模型装不舒服。即使用激进的 3-bit 量化，留给上下文和系统的空间也所剩无几。
96GB（Mac Studio M5 Ultra）能装下什么
默认情况下约有 64–72GB 可用：
- 4-bit 的 70B 级模型可以运行并支持较长上下文。权重约 40GB，加上 32K token 约 10GB，仍远在默认上限之内。
- 8-bit 的 30B 级模型轻松运行，适合更看重质量而非速度的场景。
- 同时常驻两三个中等模型，例如在同一个 API 后面挂一个编码模型、一个对话模型和一个嵌入模型。
- 总参数约 100B 的更大 MoE 模型在 4-bit 下可能勉强装下。请核对实际文件大小并预留余量。
- 8-bit 的 70B已达到或超过默认上限，不适合作为日常配置。
提高 GPU 内存上限
较新的 macOS 提供了一个设置，可以调整 GPU 能锁定的内存量：
# 36GB 机器：允许 GPU 使用约 28GB
sudo sysctl iogpu.wired_limit_mb=28672
# 96GB 机器：允许 GPU 使用约 80GB
sudo sysctl iogpu.wired_limit_mb=81920
# 恢复默认值
sudo sysctl iogpu.wired_limit_mb=0请谨慎使用。该值重启后会恢复，这是一道有用的保险。一定要给 macOS、SSH、远程桌面工具和其他服务留出几 GB。调得太高，系统会大量交换甚至失去响应，对远程机器来说可能意味着在恢复前无法访问。建议逐步调高，加载模型后观察 memory_pressure 和活动监视器，再确定最终数值。
MLX、llama.cpp 与 Ollama
三者在 Apple silicon 上都运行良好，适用场景不同。
| 运行时 | 适合 | 说明 |
|---|---|---|
| MLX / mlx-lm | Apple 原生性能、Python 工作流、LoRA 微调 | 使用 MLX 格式模型；社区有大量预先转换好的量化模型 |
| llama.cpp | 精细控制：上下文大小、KV 缓存类型、批处理、GGUF 文件 | Metal 后端；llama-server 提供 OpenAI 兼容 API |
| Ollama | 最快跑起一个 API | 基于 llama.cpp；模型管理简单，默认值合理 |
各自的入门命令：
# MLX
pip install mlx-lm
mlx_lm.generate --model mlx-community/Qwen2.5-32B-Instruct-4bit --prompt "Hello"
mlx_lm.server --model mlx-community/Qwen2.5-32B-Instruct-4bit --port 8080
# llama.cpp
brew install llama.cpp
llama-server -m ./model-Q4_K_M.gguf -c 16384 --port 8080
# Ollama
ollama run qwen2.5:32b最新选项请参考 GitHub 上的 MLX 和 GitHub 上的 llama.cpp。Ollama 服务化的详细步骤见在 Mac mini 服务器上运行 Ollama，同样适用于 Mac Studio。
吞吐量：大致预期
具体速度取决于芯片、模型、量化方式、运行时版本和上下文长度，请用自己的负载实测。不过规律是一致的：
- 模型越大，生成越慢。每生成一个 token 都要从内存读取激活的权重，所以 70B 稠密模型明显慢于 30B。
- MoE 模型感觉更快，因为每个 token 读取的权重比同总规模的稠密模型少。
- 提示词处理是另一项开销。长提示需要先处理完才会出现第一个 token，这对发送大量上下文的检索和编码工具很重要。
- 低比特量化通常更快，因为要读取的数据更少。
- 在 Mac Studio 上用 30B 级模型交互对话很流畅；70B 级模型也能用于对话和批处理，只是速度更慢。
36GB 还是 96GB
如果目标是 30B 级模型或多个小模型，选 36GB 的 Mac Studio M5 Max。如果需要 70B 级模型、长上下文或同时常驻多个模型，选 96GB 的 Mac Studio M5 Ultra。在 Hatmac 两者都是独享物理机，提供 6 个月或 12 个月租期：M5 Max 为 6 个月 $549/月、12 个月 $529/月，M5 Ultra 为 $1,199/月或 $999/月。如需更大内存可单独咨询。更多信息见 Mac Studio LLM 托管，或阅读更深入的 Apple silicon LLM 内存指南。
常见问题
36GB 的 Mac Studio 能跑 70B 模型吗？
不太行。4-bit 的 70B 模型仅权重就需要约 35–49GB，超过了 36GB 机器上 GPU 的默认可用量。
跑本地 LLM，Mac Studio 比 Mac mini 好在哪里？
主要在大模型上。16–24GB 的 Mac mini 适合 7–14B 模型；36GB 或 96GB 的 Mac Studio 可以运行 30B 和 70B 级模型。
修改 iogpu.wired_limit_mb 安全吗？
这是系统支持的设置，但要给 macOS 留出余量。该值重启后恢复，建议逐步测试。