用 Mac Studio 跑本地 LLM：36GB 和 96GB 能装下什么

用 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 留出余量。该值重启后恢复，建议逐步测试。