哪款 Mac 跑哪个 LLM 最快？实测数据告诉你

为什么 Mac 跑 LLM 的速度差异这么大？

最近 Hacker News 上出现了一个引发热议的项目：Which Mac runs which LLM, and how fast。作者做了一件很多人想做但没时间做的事——把不同型号的 Mac 放在同一套基准下，测试它们运行各类本地大语言模型的实际速度。

苹果 Silicon 芯片的统一内存架构让 Mac 成为运行本地 LLM 的热门选择，但「能跑」和「跑得快」之间差距巨大。同一个 7B 模型，在 M1 基础款和 M3 Max 上的体验可能相差数倍。这个项目试图用数据回答一个非常具体的问题：你手上的 Mac，到底适合跑多大的模型？

测试方法与核心发现

统一基准下的横向对比

该项目的价值在于控制变量。不同 Mac 的内存带宽、GPU 核心数、神经引擎规格各不相同，而这些因素都会直接影响 token 生成速度。作者将模型规模、量化精度和推理框架固定，只改变硬件变量，从而得到可比较的结论。

从社区讨论来看，测试覆盖了从基础款 M 系列到高配 Max 芯片的多档机型，模型则涵盖常见的 7B、13B 乃至更大参数的开源模型。这种矩阵式测试比零散的个人跑分更有参考价值。

内存带宽比算力更关键

LLM 推理是典型的内存带宽瓶颈型任务。生成每个 token 都需要把模型权重从内存搬运到计算单元，因此带宽越高，速度越快。这解释了为什么 M3 Max 的表现往往远超 M3——两者 GPU 核心数差距并没有带宽差距那么悬殊。

Hacker News 评论区有开发者指出，对本地推理而言，内存容量决定「能不能跑」，内存带宽决定「跑多快」。这个判断与测试结果的方向基本吻合，也是选购 Mac 做本地 AI 开发时最该关注的参数。

内存带宽指处理器从内存读取数据的最大速率，通常以 GB/s 计量。LLM 自回归生成时，每产生一个 token 都要完整遍历一次模型权重，计算量相对于数据搬运量很小，因此吞吐几乎正比于带宽而非峰值算力。M3 基础款带宽约 100 GB/s，而 M3 Max 可达 300–400 GB/s，这一差距直接映射到 token/s 上。这也是 CPU 推理在部分小模型上并不逊色于 GPU 的原因——瓶颈始终在内存而非计算单元。评估 Mac 是否适合本地推理，应优先看芯片型号对应的带宽档位，而不是只数 GPU 核心数。

统一内存架构（Unified Memory Architecture, UMA） 是 Apple Silicon 的核心设计：CPU、GPU 与神经引擎共享同一块物理内存，无需通过 PCIe 在显存与系统内存之间拷贝数据。对 LLM 推理而言，这意味着模型权重只需加载一次即可被 GPU 直接访问，避免了独立显卡常见的显存不足问题。代价是内存总量固定且不可升级，因此选购时内存容量成为一次性决策。这也解释了为何 Mac 的「可用显存」约等于整机内存，而同价位 PC 独显往往只有 8–16 GB 显存。

对开发者和普通用户的实用建议

如果你正在考虑用 Mac 跑本地模型，可以从三个维度决策。

预算优先：基础款 M 系列适合跑 7B 级别的量化模型，日常问答和简单代码补全够用，但别指望流畅运行更大的模型。

效率优先：Max 系列的高带宽优势在长上下文和较大模型上体现明显，适合需要频繁调用本地模型的开发者。

容量优先：如果目标是跑 30B 以上的模型，内存容量是硬门槛，带宽再高也弥补不了装不下的问题。

有意思的是，量化技术正在快速降低硬件门槛。4-bit 量化让不少模型的内存占用减半，这使得中端 Mac 的实际可用范围比一年前宽了不少。

量化（Quantization） 是把模型权重从 16-bit 浮点压缩到 8-bit、4-bit 甚至更低精度的技术。以 4-bit 为例，一个 7B 模型的内存占用可从约 14 GB 降至 4 GB 左右，使基础款 Mac 也能加载。常见格式包括 GGUF（配合 llama.cpp、Ollama）和 GPTQ/AWQ（配合 GPU 推理框架）。量化会带来一定的精度损失，通常在 4-bit 下 perplexity 上升有限，但过低比特会明显影响推理与代码任务表现。选择量化等级时，应在「装得下」与「答得准」之间权衡，而非一味追求最小体积。

本地推理的边界在哪里

这个项目的讨论也暴露了本地 LLM 的现实局限。即便是顶配 Mac，在超大模型上的速度仍无法与云端 GPU 集群相比，本地推理的优势在于隐私、离线可用和零边际成本，而非绝对性能。

社区中也有观点认为，随着模型蒸馏和小型化技术的进步，未来中端硬件的本地体验会持续改善。对于注重数据隐私的个人开发者和中小企业，Mac 本地部署仍然是一条值得认真评估的路线。

这个 Show HN 项目本身并不复杂，但它把散落各处的经验变成了可查的数据表，这正是开发者社区最需要的贡献方式。

Token 生成速度通常分为两个指标：prefill（预填充）阶段处理整段提示词，属于计算密集型，受算力影响较大；decode（解码）阶段逐 token 生成，属于内存带宽密集型。用户感知的「打字速度」主要是 decode 速率，一般以 token/s 表示。经验上，20 token/s 以上接近阅读速度，可流畅交互；低于 5 token/s 则明显卡顿。长上下文场景会放大 prefill 开销，这也是高带宽与大内存机型优势更明显的原因。评估基准数据时，应区分这两个阶段，避免用单一数字概括整体体验。