本地跑 LLM，Mac 内存到底要买多大？

苹果新款 Mac Studio 的统一内存上限来到了 512GB。媒体的叙事框架是：这把「桌面级跑得动前沿模型」变成了现实。这话大体没错，但它回答的其实不是大多数买 Mac 的人真正在问的问题。

他们真正在问的问题更窄、也更有用：按我想跑的模型来算，我到底需要买多少内存？ 统一内存是焊死在芯片封装上的。你只有一次机会回答这个问题，就在下单结账那一刻，而且要管这台机器一辈子。

好消息是，这是一道算术题，不是见仁见智的事。这篇文章就把这道算术题算清楚。

核心要点

• 两个数字决定一切。 内存容量决定模型能不能加载进去；内存带宽决定它生成文字的速度。这两者相互独立，一台机器完全可能一头强、一头弱。
• 权重估算 = 参数量 × 每参数字节数。 4-bit 量化下大约是每参数 0.55 字节，所以一个 70B 模型在算上下文之前大约需要 38GB。
• macOS 不会把全部 RAM 都让 GPU 用。 有一道未公开文档的上限，由 iogpu.wired_limit_mb 控制。在一台 32GB 的 Mac 上，你拿不到 32GB 给模型用。
• 苹果宣传的 AI 数字说的是「提示词处理」，不是「文本生成」。 这两者的瓶颈完全不同，措辞要仔细读。
• M5 Ultra 的容量并不是新东西。 M3 Ultra 早在 2025 年就已经给到 512GB 了。真正变化的是带宽：从 819GB/s 提升到 1.2TB/s。

两个数字

几乎所有糟糕的「买 Mac 跑 AI」决策，都是把这两个数字混为一谈造成的。

容量是一堵墙。 如果模型加上它的上下文放不进内存，它就是跑不起来。苹果芯片上没有那种离散 GPU 才有的「优雅降级」——离散 GPU 可以把数据溢出到系统内存，但在 Mac 上，统一内存本身就是系统内存，一旦你超出 macOS 愿意分给 GPU 的份额，你要么加载失败，要么退化成慢得多的方案。

带宽是一道限速。 生成一个 token，稠密模型要把它的整套权重从内存里读一遍。每个 token 都是如此。这意味着生成速度的理论上限就是「内存带宽 ÷ 模型大小」，GPU 核心再多也改变不了这个上限。

这就是为什么一台机器能装下一个 200GB 的模型、用起来却依然让人难以忍受；也是为什么一个小模型在一台配置一般的机器上反而能感觉如丝般顺滑。

容量：能装下什么

权重是最主要的开销，而且是可以预测的：

权重所需内存 ≈ 参数量 × 每参数字节数

每参数字节数取决于量化方式：

精度	每参数字节数	典型用途
FP16 / BF16	2.0	训练，追求最高保真度
8-bit (Q8)	~1.0	近乎无损的推理
4-bit (Q4_K_M)	~0.55	实践中的默认选择
3-bit	~0.42	质量损失明显

四比特 K-quant 一旦算上缩放元数据，平均值会略高于 4 bit，这也是为什么诚实的数字是 0.55 而不是 0.50。套用这个数字：

模型规模	4-bit	8-bit	FP16
8B	4.4 GB	8 GB	16 GB
14B	7.7 GB	14 GB	28 GB
32B	17.6 GB	32 GB	64 GB
70B	38.5 GB	70 GB	140 GB
120B	66 GB	120 GB	240 GB
235B	129 GB	235 GB	—
400B	220 GB	400 GB	—
671B	369 GB	671 GB	—

然后加上上下文

KV 缓存保存的是对话中每个 token 的注意力键值，它随上下文长度线性增长。它每个 token 的大小因架构差异很大——采用分组查询注意力（grouped-query attention）的模型在这一项上比老式设计便宜得多——但一个可用的估算范围是每 token 0.1MB 到 0.5MB。

在 32,000 tokens 的上下文下，这大约相当于在权重之外再加 3GB 到 16GB。到 128,000 tokens 时，它甚至可能超过模型本身。

这是「看起来应该能装下」结果却装不下的最常见原因。如果你打算喂给它长文档、或者进行很长的对话，就要明确为此预留空间，而不是只按权重大小去估算然后祈祷。

实用法则

你需要的内存 ≈ (权重) + (你所需上下文对应的 KV 缓存) + 2–3GB 开销

然后再拿这个数字去核对 macOS 实际会给你多少——那不是包装盒上写的那个数字。

没人提起的那道天花板

macOS 会为系统保留一部分统一内存，并限制 GPU 最多能「锁定」（wire）多少。控制这个开关的是一个 sysctl：

$ sysctl iogpu.wired_limit_mb
iogpu.wired_limit_mb: 0

0 代表自动。苹果没有公开自动模式具体怎么算，我也不打算凭空编一个公式——但社区的实测结果一致指向：大约是总内存的 65% 到 75%，机器越大，分到的比例也越高。

落到你可能会买的这些机型上，实际情况是：

安装内存	大致可分给 GPU 的量
16 GB	~10–12 GB
32 GB	~21–24 GB
64 GB	~42–48 GB
128 GB	~85–96 GB
512 GB	~340–384 GB

你可以手动调高这个上限，改动会立刻生效，但不会在重启后保留：

# 允许 GPU 在一台 32GB 的 Mac 上锁定 28GB
sudo sysctl iogpu.wired_limit_mb=28672

# 恢复自动模式
sudo sysctl iogpu.wired_limit_mb=0

调这个数字要小心。你多拿走的每一份内存，都是从操作系统和其他所有应用那里抢来的。把上限推得太靠近总量，你会遇到内存交换（swapping）、界面转圈圈（beachball），或者被系统强制杀掉进程（out-of-memory kill）——而在配备高速 SSD 的 Mac 上，内存压力下的交换本身也是一种持续的写入负载。如果你见过「系统的应用程序内存已用尽」这个弹窗，这就是导致它的原因之一。

一个合理的上限是「总内存减去 6–8GB」，留给 macOS 和你的其他应用。设定好之后，跑你的模型，同时在活动监视器（Activity Monitor）里观察内存压力。如果你经常看到内存压力飙升，我们的《Mac 内存管理指南》里有详细的排查方法。

带宽：答得有多快

这才是真正重要的估算，下面是它的具体算法：

每秒 token 数 ≈ (内存带宽 × 效率) ÷ 权重大小（字节）

「效率」这一项反映的是理论峰值带宽与推理引擎实际能达到的水平之间的差距——在苹果芯片上，配合一个优化良好的运行时，大约是 0.6 到 0.8。下面我用 0.7 来计算。

这些是根据公开带宽数字算出来的估算值，不是我实测跑出来的基准测试结果。 请把它们当作数量级正确、相对排序正确的参考，而不是精确测量值。实际数字会随运行时、量化方式、上下文长度和散热表现而变化。

稠密模型在 4-bit 下的生成速度：

	M6 (170GB/s)	M5 Pro (307GB/s)	M5 Max (614GB/s)	M5 Ultra (1.2TB/s)
8B (4.4GB)	~27 tok/s	~49 tok/s	~98 tok/s	~190 tok/s
32B (17.6GB)	~7 tok/s	~12 tok/s	~24 tok/s	~48 tok/s
70B (38.5GB)	装不下	~6 tok/s	~11 tok/s	~22 tok/s
120B (66GB)	装不下	装不下	~7 tok/s	~13 tok/s

作为参考：舒适的阅读速度大约是每秒 10 个 token。低于大约 5 个 token/s，大多数人就会放弃使用。

看 32B 那一行。这是同一个模型，从「勉强能忍」到「真正流畅」，整个区间都在变化——而它能不能装下这件事完全没变。这就是带宽而非容量在起作用，也是人们在挑「刚好能装下模型的最便宜机型」时最容易忘记的那根轴。

为什么 MoE 模型会改变答案

混合专家（Mixture-of-experts，MoE）模型打破了上面这条规则，而这正是 512GB 机器有意思的地方所在。

一个 MoE 模型内部存储着许多专家子网络，但每个 token 只激活其中一小部分。一个 235B 模型、激活参数为 22B，意味着它必须装下相当于 235B 参数的权重，但生成每个 token 时只需要读取大约相当于 22B 参数的权重。

所以：

• 容量由总参数量决定——4-bit 下是 129GB。
• 速度由激活参数量决定——表现得就像一个 22B 的稠密模型，在 M5 Ultra 上大约是 40 tok/s，而不是一个 235B 稠密模型才能有的约 9 tok/s。

这种不对称性，正是大型 MoE 模型能在苹果芯片上实用起来、而在消费级 GPU 上却做不到的原因：你需要的是容量，而苹果以一种别人做不到的方式、以这个价位卖给了你容量；同时你得到的速度，却对应着一个小得多的模型。

这也是为什么「512GB 能跑前沿模型」这句话对，但不完整。它能以可用的速度跑稀疏的前沿模型。一个假想的 400B 稠密模型在 4-bit 下会占用 220GB，在 M5 Ultra 上大约只能生成每秒 4 个 token。它是能装下，但你不会喜欢用它。

提示词处理是另一回事

请精确地读一读苹果对新款 Mac mini 的宣传措辞：

相比 M4，LLM 提示词处理速度最高提升 4.8 倍 相比 M1，LLM 提示词处理速度最高提升 13.5 倍

提示词处理——也就是「预填充」（prefill）——是模型摄入你输入内容的阶段。你输入的每一个 token 都是并行处理的，这让它成为计算受限的过程：它随 GPU 吞吐能力扩展，也受益于现在每个 GPU 核心内置的 Neural Accelerator，以及 M6 上苹果首次配备的双 Neural Engine。

文本生成——也就是「解码」（decode）——则是一次处理一个 token，每次都需要完整扫过一遍权重。它是带宽受限的，再多的算力也解决不了这个问题。

苹果选择了拿计算受限的那一半来宣传。这并不算误导——那确实是这一代提升最大的部分。但这意味着，那些宣传数字描述的是这台机器读你那份 50 页文档有多快，而不是它写摘要有多快。

你该关心哪一个，取决于你的具体工作：

• 长输入、短输出——总结文档、分类、从代码库里提取信息——是预填充主导的场景。苹果的数字在这里适用。
• 短输入、长输出——写作、聊天、生成代码——是解码主导的场景。带宽才是你该看的数字。
• 长输入加长输出——面对大上下文的智能体（agentic）工作流——两者都需要，而且还需要额外的容量来装下 KV 缓存。

M5 Ultra 到底改变了什么

一些发布会相关报道给人的印象是，在桌面机上装下一个前沿模型是个新鲜事。其实不是，而搞清楚这一点，会改变已经拥有一台 Mac Studio 的人的升级决策。

	M3 Ultra (2025)	M5 Ultra (2026)
最大统一内存	512GB	512GB
内存带宽	819GB/s	1.2TB/s
GPU 核心	最多 80	最多 80
CPU 核心	32	最多 36

容量没有变化，GPU 核心数也没有变化。 带宽提升了约 1.47 倍，CPU 多了四个核心。

这与苹果自己给出的相对 M3 Ultra 的对比数字完全吻合——「多线程性能最高提升 1.3 倍」和「图形性能最高提升 1.8 倍」都是比较克制的数字，而苹果最大的宣传点「AI 峰值算力最高提升 4.3 倍」，靠的是现在内置在每个 GPU 核心里的 Neural Accelerator，而不是核心数量或核心规模的增加。

所以具体到本地推理这件事上：

• 生成速度大致随带宽同比提升——在同一个模型上大约是 1.4 倍左右。
• 提示词处理提升幅度大得多，与那个 4.3 倍的 AI 算力数字对应。
• 能加载什么没有变化。

如果你已经拥有一台 512GB 的 M3 Ultra Mac Studio，而你的瓶颈是「哪些模型能装得下」，那这一代并不能解决你的问题。如果你的瓶颈是「等长提示词处理完」，那它直接解决了这个问题。我们的《Mac Studio M4 Max 与 M3 Ultra 性能指南》详细介绍了上一代机型。

订购前还有一个值得知道的排期细节：512GB 配置不会在 9 月 22 日与其他机型一起首发，苹果给出的到货时间是 10 月下旬。

按你实际要做的事，该选哪台机器

16GB——不适合这件事

你大约能拿到 10–12GB 给 GPU 用。这只能在有限上下文下跑 8B 级别的 4-bit 模型，更大的就不行了。它适合跑自动补全类模型和小型本地助手，跑别的都会让你憋屈。到了 2026 年，16GB 是一台「顺带能跑跑 LLM，但主业是干别的」的机器。

32GB（M6 Mac mini 顶配，$1,299）——入门起点

大约能用到 21–24GB。这足以流畅跑 8B 和 14B 模型，也能在较短上下文下跑一个 4-bit 的 32B 模型，速度大约每秒 7 个 token。最后这个数字才是诚实的极限：能装下，但已经踩在「还算可以接受」的边缘上。

适合：本地编程助手、私密文档处理、熟悉相关工具链。如果本地跑模型是你买这台机器的理由之一，那从 16GB 加 400 美元升级到 32GB 就不是可选项，而是必需。

64GB（M5 Pro Mac mini，$1,699 起）——大多数人的甜点区

大约能用到 42–48GB，带宽 307GB/s。一个 4-bit 的 70B 模型能装下，还留有真正可用的上下文空间，生成速度大约每秒 6 个 token——适合批处理任务，作为交互式聊天则偏慢。一个 32B 模型能跑到大约每秒 12 个 token，这个速度是舒适的。

大多数认真使用本地模型的场景都会落在这个档位，这也是我会推荐给大多数人的配置。它还带来了 M6 mini 所没有的雷雳 5（Thunderbolt 5）。

128GB（M5 Max Mac Studio，$2,499 起）——专业级

大约能用到 85–96GB，带宽 614GB/s。4-bit 的 70B 模型能跑到大约每秒 11 个 token，交互体验相当舒适。120B 级别的模型能装下。中等规模的 MoE 模型开始变得实用。

这个配置适合那些工作日常就依赖本地推理的人——同一个模型上，它的带宽大致是 M5 Pro 生成速度的两倍。

512GB（M5 Ultra Mac Studio，$5,499 起，顶配超过 $18,000）——别处买不到的容量

大约能用到 340–384GB，带宽 1.2TB/s。这能装下 4-bit 的 400B 级 MoE 模型，并以其激活参数量对应的速度生成文本——这是目前这个价位没有其他桌面产品能做到的具体优势。

如果你受限于容量、而且没有别的办法能解决，那就买这个。如果你要跑的模型在 128GB 里就能装下，那 Ultra 买到的其实是速度，而速度你原本可以花更少的钱买到。

如果你不打算买新 Mac

一台内存够用的现有 M1/M2/M3/M4 Mac，跑本地模型完全没问题——Pro 和 Max 档位的带宽已经好几代都表现不错了。查一下你自己机器的数字：

# 总内存（GB）
echo "$(( $(sysctl -n hw.memsize) / 1073741824 )) GB"

# 芯片型号与当前 GPU 锁定上限
sysctl -n machdep.cpu.brand_string
sysctl iogpu.wired_limit_mb

然后套用上面的表格。一台带宽 400GB/s 的 64GB M1 Max，一直以来都是一台相当不错的本地推理机器。

一个完整的实战例子

抽象的表格看着容易点头认同，做起来却难以落地。下面把这套推理方法套用到一个具体案例上。

需求： 一个私密的编程助手，需要读取一个中等规模的代码库，保持 32,000 tokens 的上下文，并进行交互式问答。你想要一个 32B 级别的模型，因为更小的模型在代码理解上明显更差。

第一步——权重。 32B 在 4-bit 下：32 × 0.55 = 17.6GB。

第二步——上下文。 对一个采用分组查询注意力的现代模型，32,000 tokens 大约按每 token 0.2MB 计算：约 6.4GB。这一项正是人们最容易忘记的，而它在这里已经超过权重大小的三分之一。

第三步——开销。 运行时、Metal 缓冲区、分词器：2–3GB。

总计：大约需要 26–27GB 锁定给 GPU 使用。

第四步——换算成需要安装的内存。 按自动上限约 70% 来算，27GB 的锁定需求需要安装大约 38GB 内存。而一台 32GB 的 Mac 自动只能给你 21–24GB——不够用。你可以把 iogpu.wired_limit_mb 在一台 32GB 机器上调高到 27GB，这样留给 macOS 和其他一切的只有 5GB。这在没有其他程序运行时能凑合用，一旦你打开个浏览器就会崩溃。

结论：需要安装 64GB。 对应的是 M5 Pro Mac mini，而不是 M6。

第五步——核对速度。 307GB/s × 0.7 ÷ 17.6GB ≈ 每秒 12 个 token。交互使用很舒适。

现在只改一个变量。其他条件不变，把上下文改成 128,000 tokens：KV 缓存会涨到大约 25GB，总需求约 45GB，需要安装的内存最低要 64GB（且必须调高锁定上限）——想要舒适的话则要 128GB。仅仅一个设置的改动，就把答案往上推了整整一个产品档位。

这就是完整的方法：权重、上下文、开销，除以那道上限，再拿带宽去核对权重大小。

不同运行时表现不一样

上面这些算法描述的是硬件本身。你实际观察到的表现取决于软件，而且差异大到足以改变购买决策。

MLX 是苹果自己的数组框架，专为统一内存设计。因为苹果芯片上根本不存在「CPU 内存」和「GPU 内存」的区分，它不需要在两者之间做拷贝，通常也是 Mac 上内存效率最高的选择。如果你专门为本地推理而买硬件，基于 MLX 的工具链是最能把硬件性能发挥出来的那一个。

llama.cpp 以及基于它构建的各种工具，是可移植性最好的选择，Metal 支持也很出色。它的量化格式——也就是上面表格所依据的 Q4_K_M 系列——事实上已经是行业标准，它的内存行为也是可预测、有据可查的。

Ollama 在 llama.cpp 外面包了一层模型管理。它很方便，但要知道的一点是：它会在使用完之后，让模型在内存里驻留一段可配置的时间。如果你已经接近上限，一小时前用完的模型可能仍然占着内存——这是「昨天还能跑今天就不行了」的一个常见原因。

LM Studio 是图形界面选项，而且对内存情况很诚实，在你真正加载模型之前就会告诉你能不能装得下。这是一个不用做算术、也能培养出对这些数字的直觉的好办法。

不管你用哪一个，有两个行为都值得留意：

1. KV 缓存是否预分配。 有些运行时在加载时就预留整个上下文窗口的空间，有些则随对话增长逐步分配。预分配意味着一个原本实际能跑起来的模型，反而会加载失败。如果一个模型在 128K 上下文下加载失败、在 8K 下却能加载，原因就在这里——修复方法是调低配置的上下文长度，而不是换一个更小的模型。
2. 未使用的模型是否会被卸载。 在断定你的机器内存不够之前，先检查一下运行时的「保活」（keep-alive）设置。

不花钱买内存也能腾出空间

在为多一档内存多花 400 美元之前，有几种技巧可以改变这道算术题的结果。

量化得更狠一点。 从 8-bit 降到 4-bit，能把内存需求砍半，而质量损失有限。这几乎总是比「换成更小的模型、但保持更高精度」更划算的取舍——一个 4-bit 的 32B 模型，通常会比一个 8-bit 的 14B 模型表现更好，而占用的内存相近。

量化 KV 缓存。 大多数运行时能把 KV 缓存存成 8-bit 甚至更低精度。在长上下文场景下，缓存的大小已经能和权重相当，这是能省下最多空间的一招，而质量代价很小。

把上下文设置到刚好够用。 一个 128K 的上下文窗口，就算你实际只用了 4,000 tokens，在会预分配的运行时里也是全价支付的。把上下文配置成你实际会用到的大小。

优先选择 MoE 模型。 正如前面提到的，混合专家模型能让你以小模型的生成速度，享受大模型的质量。代价是容量，而这恰恰是 Mac 相比其他方案更充裕的资源。

使用投机解码（speculative decoding）。 一个小型的草稿模型先提出若干个候选 token，大模型再一次性并行验证它们。因为验证过程是并行的，这直接针对带宽瓶颈发力，能显著提高每秒 token 数——代价是要在内存里额外常驻一个小模型。在带宽受限、但容量还有富余的机器上，这是一笔划算的交易。

该关的都关掉。 听起来很显然，但出人意料地经常就是答案。开着一堆标签页的浏览器、虚拟机、视频剪辑软件，都在争抢同一个内存池。这里没有独立的显存可以退而求其次。

常见问题排查

模型加载成功，但生成速度极慢

问题：你已经超出了 macOS 愿意分给 GPU 的量，工作负载正在溢出到交换空间。表现症状是首个 token 要等很久，生成过程卡顿而不是均匀流畅地输出。

解决方法：在生成过程中查看活动监视器里的内存压力。如果是黄色或红色，就使用更小的量化精度、缩短上下文窗口，或者调高 iogpu.wired_limit_mb——但至少要给系统留 6–8GB。如果内存压力是绿色、速度却依然很慢，那你就是单纯受限于带宽，解决方法是换一个更小的模型。

「系统的应用程序内存已用尽」

问题：通常是锁定上限设置得太激进，或者是一场长会话中上下文越涨越大导致的。

解决方法：用 sudo sysctl iogpu.wired_limit_mb=0 重置，然后重启推理进程。如果系统仍然不正常就重启电脑——反正这个设置本来就不是持久生效的，重启无论如何都会清空它。相关成因在我们的《内存泄漏排查指南》里有更详细的介绍。

算下来应该能装下，实际却加载失败

问题：你只按权重大小估算，忘了算 KV 缓存，或者你用的运行时是一次性预分配整个上下文空间、而不是按需增长的。

解决方法：在运行时的设置里调低上下文长度，再试一次。如果 32K 上下文能加载、128K 不能，这就证实了上面的判断——而「容量」那一节里的算法能告诉你，你想要的上下文究竟需要多少内存。

长会话中 Mac 发热并变慢

问题：持续的推理负载，同时给 GPU 和内存带来持续的压力。笔记本电脑会降频，台式机基本不会。

解决方法：这正是这类工作负载下、Mac mini 或 Mac Studio 相对 MacBook 的一个实际优势——持续的散热余量。如果你用的是笔记本，可以参考我们的《MacBook Pro M5 散热降频指南》。

提示词处理很快，生成却很慢

问题：这不是故障，是这套硬件本该有的样子。

解决方法：参见上面「预填充与解码」那一节。如果你需要的是生成速度，解决办法按代价从低到高依次是：换更小的模型、用更激进的量化方式、换一个激活参数量小的 MoE 模型，或者增加带宽。

常见问题

我要跑一个 70B 模型，需要多少内存？

在 4-bit 量化下，权重大约是 38.5GB。加上上下文和开销，现实中你应该以安装 64GB 作为最低标准，因为 macOS 只会把大约 42–48GB 分给 GPU。一旦算上任何有意义的上下文，安装 48GB 就会显得太紧张。

2026 年，16GB 够用来跑本地 AI 吗？

对于短上下文下的 4-bit 8B 模型来说，够用。更大的模型就不行了。如果本地模型是你买这台机器的理由之一，把 32GB 当作底线，把 64GB 当作目标。

Neural Engine 会加速本地 LLM 吗？

它对提示词处理有贡献，苹果「LLM 提示词处理最高提速 4.8 倍」这个数字正是由此而来，M6 上双 16 核 Neural Engine 也确实是一次实质性提升。但它不会改变 token 生成上的带宽限制。Mac 上大多数主流的本地推理运行时，主要依靠的是通过 Metal 调用的 GPU。

我该买 512GB 的 Mac Studio 吗？

只有在你受限于容量的情况下才值得买。如果你实际会跑的模型在 128GB 里就能装下，M5 Max Mac Studio 能以三分之一的价格做同样的事。另外要注意，512GB 版本要到 10 月下旬才发货，而顶配机型的价格会来到 $18,299。

以后能加内存吗？

不能。在每一款苹果芯片 Mac 上，统一内存都是芯片封装的一部分。这是所有规格里最值得多花钱往高了买的一项，因为它是唯一一项你以后永远无法回头修改的。

在这件事上，Mac 比配独立显卡的 PC 更好吗？

各有取舍。独立显卡的内存带宽要高得多，但内存容量小得多——消费级显卡的容量上限，远低于 Mac Studio 能给到的水平。在单位价格的容量和功耗上，Mac 赢得很彻底；但对于那些小到能塞进显存里的模型，在原始吞吐量上会输给独立显卡。如果你要跑的模型很大，Mac 往往是唯一能单机搞定的方案；如果模型很小，GPU 会更快。

量化会损害质量吗？

对大多数用途而言，8-bit 已经接近无损。4-bit 的 K-quant 是实践中的默认选择，对大多数任务来说质量下降有限。低于 4-bit，质量下降就会变得明显。参照上面的内存表格，从 8-bit 降到 4-bit 大致能把内存需求砍半——这通常比换成更小的模型是更划算的取舍。

结语

512GB 这个头条数字是真的，对少数人来说，它确实是决定性的因素。但对其他所有人来说，这篇文章真正有用的部分，是三行算术：权重等于参数量乘以每参数字节数；上下文在此之外，每个 token 再加 0.1–0.5MB；而 macOS 只会把你买到的内存中大约 65% 到 75% 分给 GPU。

拿这几个数字去核对你实际打算使用的模型，答案通常会落在 64GB 上。然后再核对第二个数字——带宽——因为它决定了「装得下的模型」是不是一个你会持续用下去的模型。一个 32B 模型在每秒 7 个 token 和同一个模型在每秒 24 个 token 之间的差距，就是「一个演示」和「一个真正好用的工具」之间的差距，而再多的容量也弥补不了这个差距。

不管你最终选哪一款，都请慎重选择。它是焊死的。

相关阅读：Mac mini M6 与 Mac Studio M5 Ultra：到底改变了什么，Mac 上的本地 AI 应用会怎么处理你的数据，以及2026 年 Mac 内存价格正在上涨。