1. 为什么"本地跑大模型"这件事，硬件账本和你想的不一样
很多人第一次动了"在自己机器上跑大模型"的念头，脑子里浮现的画面大概是：买张旗舰显卡，插上，装个推理框架，然后就能像用在线服务一样流畅对话。真上手之后才发现，事情完全不是这么回事——显存不够、内存爆掉、CPU 风扇狂转、NPU 明明在参数表上写着却根本用不上。我自己从一张 8GB 显存的老卡一路折腾到 32GB 统一内存的 Mac mini，中间踩的坑足够写一本小册子。
这篇东西想聊的核心，是本地大模型推理的硬件真相：MoE 架构到底吃不吃显存、CPU/GPU/NPU 三种算力各自扮演什么角色、为什么很多框架对 NPU 视而不见，以及一台 32GB 内存的 Mac mini 到底能跑到什么程度、怎么调才能榨出它的全部潜力。关键词里的 MoE、CPU、GPU、NPU、Mac mini，基本就是这条链路上的五个关键节点，我会一个一个拆开讲。
适合谁看？如果你正在纠结"要不要为了跑大模型换硬件"、"手里的设备能不能凑合跑"、"为什么我的 NPU 用不上"，或者你已经有一台 Mac mini 但觉得速度不理想，那这篇应该能帮你省下不少试错时间。我不打算堆一堆跑分数字吓人，而是想把每个硬件选择背后的逻辑讲清楚，让你能根据自己的实际情况做判断。
先说一个反直觉的结论：在本地推理这个场景里，显存容量往往比算力峰值更重要，内存带宽往往比核心数量更关键。这句话贯穿全文，后面所有讨论基本都围绕它展开。
2. MoE 架构的显存账：稀疏激活不等于省显存
2.1 MoE 到底"稀疏"在哪里
MoE，也就是混合专家（Mixture of Experts），这两年几乎成了大模型的标配架构。它的核心思想是把一个大网络拆成很多个"专家"子网络，每次前向传播时，只激活其中一小部分专家来处理当前 token。比如一个模型有 8 个专家，每个 token 只路由到其中 2 个，那计算量理论上就只有全量激活的 1/4。
这里有个特别容易混淆的点，也是热词里反复出现的疑问："MoE 架构要全部参数进显存吗？"答案是——要，而且必须全部进显存（或至少全部可被快速访问）。稀疏的是"计算"，不是"存储"。所有专家的权重都得放在那里待命，因为路由器（Router）随时可能把某个 token 分发给任意一个专家。你没法预知下一个 token 会用到哪个专家，所以不能只加载一部分。
这就导致一个尴尬的现实：一个总参数量 47B 的 MoE 模型，虽然每次推理只激活 13B 左右的参数，但显存占用依然要按 47B 来算。很多人看到"激活参数 13B"就以为 16GB 显存能跑，结果加载直接失败，就是这个原因。
2.2 参数量、精度与显存占用的换算
要把显存账算清楚，得先记住一个基础换算关系。模型权重占用的显存大致等于：
显存占用（GB） ≈ 参数量（B）× 每参数字节数
不同精度下每参数的字节数差别很大：
| 精度格式 | 每参数字节 | 7B 模型占用 | 13B 模型占用 | 47B MoE 占用 |
|---|---|---|---|---|
| FP32 | 4 字节 | 约 28GB | 约 52GB | 约 188GB |
| FP16/BF16 | 2 字节 | 约 14GB | 约 26GB | 约 94GB |
| INT8 | 1 字节 | 约 7GB | 约 13GB | 约 47GB |
| INT4 | 0.5 字节 | 约 3.5GB | 约 6.5GB | 约 23.5GB |
这张表是理想值，实际还要加上 KV Cache、激活值、框架开销，通常要再留 20% 到 40% 的余量。所以一个 47B 的 MoE 模型用 INT4 量化，光权重就 23.5GB，加上 KV Cache，32GB 内存的机器跑起来会非常紧张，基本只能跑很短的上下文。
2.3 量化是本地推理的救命稻草
既然全量参数必须驻留，那降低每个参数的字节数就成了唯一出路。这就是量化（Quantization）存在的意义。INT4 量化能把显存需求压到 FP16 的四分之一，代价是精度损失。实测下来，主流的 4-bit 量化（比如 Q4_K_M 这类方案）在对话、总结、代码补全这些任务上，和原始精度的差距普通用户基本感知不到，只有在数学推理、长链条逻辑这种对数值敏感的任务上才会明显掉点。
我自己的经验是：7B 到 14B 的模型，Q4 量化是甜点区；再往上到 30B 以上，Q4 已经是能跑动的极限，再压到 Q3、Q2 就会出现明显的胡言乱语。所以选模型的时候，先看量化后的体积，再看你的硬件能不能装下，最后才考虑速度。
2.4 MoE 的负载均衡问题为什么影响你的体验
热词里出现了"MoE 负载均衡代码"，这其实是个训练侧的概念，但它会间接影响推理体验。MoE 训练时如果路由器总是把 token 分给少数几个专家，就会出现"专家旱的旱死、涝的涝死"，导致部分专家训练不充分。为了解决这个问题，训练时会加一个负载均衡损失（Load Balancing Loss），强制 token 更均匀地分配到各专家。
对推理端来说，这意味着不同 token 激活的专家组合是动态变化的，显存访问模式很不规则。这恰恰是 MoE 在本地设备上跑起来"忽快忽慢"的原因之一——某些 token 恰好命中缓存友好的专家组合就快，命中分散的组合就慢。这也是为什么 MoE 模型对内存带宽特别敏感，后面讲 Mac mini 的时候会再展开。
3. CPU、GPU、NPU：三种算力在本地推理里各干什么活
3.1 CPU：被低估的"兜底选手"
一提本地跑大模型，很多人第一反应是"必须上 GPU"。但实际上，CPU 推理一直是个被低估的选项。原因很简单：CPU 的优势是内存容量大、通用性强，劣势是算力密度低、内存带宽有限。
CPU 推理的典型场景是：模型量化后体积能塞进系统内存，但塞不进显存，或者干脆没有独立显卡。这时候用 CPU 跑，速度慢但能跑起来。我实测过在一台普通笔记本上用 CPU 跑 7B 的 Q4 模型，大概每秒 3 到 5 个 token，日常问答勉强能用，但长文本生成就很煎熬了。
CPU 推理的性能瓶颈主要在内存带宽。大模型推理是典型的"内存墙"问题——每生成一个 token，都要把大量权重从内存搬到计算单元，计算本身反而很快。所以 CPU 的核心数不是越多越好，内存通道数和带宽才是关键。这也是为什么一些服务器 CPU 虽然单核性能一般，但跑大模型反而比消费级 CPU 快，因为它们有更多内存通道。
3.2 GPU：算力猛兽，但显存是天花板
GPU 在本地推理里的地位不用多说，矩阵运算天生适合它的并行架构。但 GPU 有个致命短板：显存容量和价格严重不成比例。一张 24GB 显存的消费级显卡，价格能买好几台 32GB 内存的迷你主机。
GPU 推理的关键指标有三个：显存容量、显存带宽、算力（TFLOPS）。三者里，显存容量决定"能不能跑"，显存带宽决定"跑多快"，算力决定"上限在哪"。很多人只盯着算力买卡，结果发现模型根本装不下，或者装下了但上下文一长就爆显存。
还有个容易被忽略的点：GPU 推理时，模型权重、KV Cache、激活值都要占显存。KV Cache 会随着上下文长度线性增长，一个 8K 上下文的对话，KV Cache 可能就吃掉好几个 GB。所以买卡的时候，显存容量要按"模型权重 + 预留 KV Cache + 框架开销"来算，不能只看模型体积。
3.3 NPU：参数表上的明星，实际用起来的难题
NPU（神经网络处理单元）是这几年移动端和边缘设备的热门配置，手机 SoC、瑞芯微 RK3588 这类开发板、还有各种 AI PC 都在强调自己的 NPU 算力。但热词里那句"ollama 为什么不支持 NPU"道出了很多人的困惑：NPU 明明是为 AI 设计的，为什么主流推理框架反而不用它？
原因有几个层面。第一，NPU 的编程模型和生态高度碎片化。每个厂商的 NPU 都有自己的指令集、算子库和编译工具链，不像 CUDA 那样有统一的生态。你想让一个模型跑在 NPU 上，往往需要把模型转换成厂商特定的格式，还要确保所有算子都被支持，一旦遇到不支持的算子就得回退到 CPU，性能直接崩掉。
第二，NPU 通常为特定精度和特定算子优化。很多 NPU 主打 INT8 甚至 INT4 推理，对 FP16 支持有限，而大模型的量化和 NPU 的量化要求经常对不上。你辛苦量化好的模型，NPU 可能不认。
第三，NPU 的显存（或共享内存）通常很小。手机 NPU、边缘 NPU 大多只有几 GB 的可用内存，跑个几 B 的小模型还行，跑 7B 以上就力不从心了。
所以现实是：NPU 在特定场景（比如手机上的图像处理、语音识别）表现很好，但在通用大模型推理上，生态成熟度和灵活性远不如 GPU 和 CPU。这也是为什么很多框架干脆不支持 NPU——投入产出比不划算。
3.4 三种算力的协作与取舍
实际部署时，这三种算力经常是混合使用的。比如：
- GPU 跑主模型，CPU 跑预处理和后处理：这是最常见的组合，GPU 专注矩阵运算，CPU 处理 tokenization、采样这些逻辑。
- CPU + GPU 分层加载：显存不够时，把一部分层放在 GPU，一部分放在 CPU，推理时来回搬运。速度会掉，但能跑起来。
- NPU 跑小模型，GPU/CPU 跑大模型：比如用 NPU 跑嵌入模型或语音模型，主对话模型交给 GPU。
选择哪种组合，取决于你的硬件配置和性能要求。下面这张表可以帮你快速判断：
| 场景 | 推荐算力 | 理由 |
|---|---|---|
| 有 16GB+ 显存的独显 | GPU 为主 | 速度快，生态成熟 |
| 只有核显，内存 32GB+ | CPU 为主 | 内存够大，能跑量化模型 |
| 统一内存架构（如 Mac） | GPU+CPU 共享 | 内存即显存，带宽是关键 |
| 边缘设备带 NPU | 视生态而定 | 算子支持是最大变数 |
4. 32GB Mac mini 实战：统一内存架构下的调优逻辑
4.1 为什么 Mac 的统一内存对大模型特别友好
Mac mini 的 M 系列芯片用的是统一内存架构（Unified Memory Architecture），CPU 和 GPU 共享同一块物理内存，没有传统意义上"显存"和"内存"的区分。这对大模型推理来说是个巨大的优势：你不需要把模型从内存搬到显存，GPU 可以直接访问全部内存。
这意味着什么？一台 32GB 内存的 Mac mini，理论上 GPU 可以动用接近 32GB 的空间来跑模型（实际可用会少一些，系统和其他程序要占一部分）。对比之下，一张 8GB 显存的显卡，模型超过 8GB 就得想办法分层或者量化到很小。所以在"能跑多大的模型"这件事上，大内存的 Mac 反而比小显存的独显更有优势。
但统一内存也有代价：内存带宽是共享的，CPU 和 GPU 抢带宽。M 系列芯片的内存带宽虽然不低（不同型号从 100GB/s 到 400GB/s 不等），但和高端独显的显存带宽（动辄 500GB/s 以上）比还是有差距。而大模型推理恰恰是带宽敏感型任务，所以 Mac 的推理速度通常不如同价位的独显方案，但胜在能跑更大的模型。
4.2 32GB 到底能跑多大的模型
这是最实际的问题。基于我自己的实测和社区反馈，32GB 统一内存的 Mac mini 大致能跑这些规模的模型：
| 模型规模 | 量化精度 | 可行性 | 体验 |
|---|---|---|---|
| 7B-8B | Q4/Q5 | 轻松 | 流畅，可开较长上下文 |
| 13B-14B | Q4 | 可行 | 流畅，上下文适中 |
| 30B-34B | Q4 | 勉强 | 速度偏慢，上下文要压缩 |
| 47B MoE | Q4 | 很勉强 | 权重就占 23GB+，上下文极短 |
| 70B | Q4 | 不可行 | 权重超 35GB，装不下 |
结论很清晰：32GB Mac mini 的甜点区是 7B 到 14B 的 Q4 模型。这个区间里，模型能力足够应付日常问答、写作辅助、代码补全，速度也能接受。想跑 30B 以上，要么接受慢速，要么加钱上更大内存的型号。
4.3 内存分配：给 GPU 留多少才合适
Mac 上有个关键设置叫"GPU 内存分配"或者"显存限制"，不同系统和框架的叫法不一样。默认情况下，系统会给 GPU 分配一个相对保守的内存额度，剩下的留给系统和 CPU。但跑大模型时，你往往需要手动调高这个额度。
我的经验是：如果主要用 GPU 推理，把 GPU 可用内存调到总内存的 70% 到 75%。32GB 的话，大概给 GPU 留 22GB 到 24GB。留太多会导致系统卡顿甚至崩溃，留太少模型装不下。这个值需要根据你实际跑的模型大小微调，跑 7B 模型可以留少一点，跑 14B 就要留多一点。
调整方式因框架而异。有些推理框架有启动参数可以直接指定，有些需要在系统层面配置。建议先用默认值跑一次，观察内存占用，再逐步调整。
4.4 上下文长度与 KV Cache 的权衡
上下文长度是另一个吃内存的大户。KV Cache 的大小和上下文长度、模型层数、注意力头数都相关，粗略估算的话，一个 7B 模型在 8K 上下文下的 KV Cache 大概占 1GB 到 2GB，14B 模型翻倍，30B 以上就更夸张。
在 32GB 的机器上，我的建议是：日常使用把上下文控制在 4K 到 8K，需要处理长文档时再临时调高。因为上下文一长，不仅 KV Cache 占用增加，推理速度也会下降（注意力计算量随上下文长度平方增长）。很多人抱怨 Mac 跑大模型慢，其实是因为默认开了很长的上下文，白白浪费了内存和算力。
4.5 实测调优的几个关键动作
把上面这些串起来，我在 32GB Mac mini 上的调优流程大致是这样的：
- 选模型：优先选 7B 到 14B 的 Q4 量化版本，确认文件体积在 5GB 到 10GB 之间。
- 调内存分配：把 GPU 可用内存设到 22GB 左右，给系统留足余量。
- 控上下文：默认 4K，需要时再往上调，别一上来就拉满。
- 关后台：跑推理时关掉浏览器、视频播放这些吃内存的程序，统一内存是共享的，后台程序会直接抢走 GPU 能用的额度。
- 观察温度：Mac mini 散热一般，长时间推理会降频，速度会掉。如果发现跑一会儿就变慢，考虑加个散热底座或者控制单次推理时长。
这套流程下来，7B 模型能跑到每秒 20 到 30 个 token，14B 大概每秒 10 到 15 个 token，日常使用完全够用。
5. 那些没人明说但一定会踩的坑
5.1 "激活参数"和"总参数"的认知陷阱
前面提过，但值得再强调一次。MoE 模型的宣传材料特别喜欢强调"激活参数只有 XX B"，让人误以为硬件需求也按激活参数算。实际上显存需求永远按总参数算。我见过太多人买了 16GB 显存的卡，兴冲冲去下 47B 的 MoE 模型，结果加载直接报显存不足。记住：稀疏的是计算，不是存储。
5.2 NPU 算力数字的水分
厂商宣传 NPU 时喜欢用 TOPS（每秒万亿次操作）这个单位，动辄几十上百 TOPS，看起来比 GPU 还猛。但这些数字通常是在特定精度（比如 INT8）、特定算子、理想条件下的峰值，实际跑大模型时根本达不到。而且如前所述，算子支持不全、量化格式不匹配、内存不够，任何一个问题都能让 NPU 的实际表现远低于标称值。看到 NPU 算力数字，先问一句：支持哪些算子？内存多大？生态怎么样？
5.3 内存带宽才是隐藏的瓶颈
很多人选硬件只看算力和容量，忽略带宽。但大模型推理是带宽敏感型任务，每生成一个 token 都要搬运大量权重。带宽不够，算力再强也是干等着。这也是为什么同样跑 7B 模型，有的机器快有的机器慢，差距往往不在算力而在带宽。选硬件时，内存/显存带宽的重要性不亚于容量。
5.4 量化不是越低越好
为了塞进有限的硬件，很多人倾向于选最低的量化精度。但量化是有代价的，Q2、Q3 这种极端量化会让模型输出质量明显下降，出现重复、逻辑混乱、答非所问。我的建议是：在能装下的前提下，尽量选高一点的精度。宁可跑小一点的模型用 Q5，也不要跑大模型用 Q2。
5.5 框架选择比硬件更影响体验
同一个模型，用不同的推理框架跑，速度和稳定性可能差很多。有的框架对 Mac 的统一内存优化好，有的对 CUDA 优化好，有的对 CPU 优化好。选框架时，先看它对你硬件的支持程度，再看社区活跃度。一个活跃的社区意味着遇到问题能搜到答案，这比多几个百分点的性能重要得多。
6. 从硬件选型到落地：一套可复用的决策路径
6.1 先明确你要跑什么
硬件选型的第一步不是看参数，而是明确需求。问自己几个问题：
- 我要跑的模型最大是多少 B？
- 我需要多长的上下文？
- 我对速度的要求是什么（实时对话还是离线批处理）？
- 我的预算是多少？
把这几个问题回答清楚，硬件范围基本就定了。比如"我要跑 14B 模型、8K 上下文、实时对话、预算五千"，那 32GB 内存的 Mac mini 或者 16GB 显存的独显方案都在考虑范围内，再根据其他因素取舍。
6.2 容量优先，带宽其次，算力最后
这是我总结的选型优先级。先确保容量够装下模型和 KV Cache，再看带宽能不能支撑可接受的速度，最后才看算力峰值。很多人反着来，先看算力买卡，结果容量不够，白搭。
6.3 留出升级和扩展的余地
本地大模型这个领域变化很快，今天能跑的模型明天可能就不够看了。选硬件时尽量留点余量，内存能大则大，因为内存通常没法后期加装（尤其是 Mac 和笔记本）。宁可现在多花点钱买大内存，也不要半年后因为装不下新模型而换整机。
6.4 软件栈的适配成本要算进去
硬件买回来只是开始，软件栈的适配才是长期成本。CUDA 生态成熟，遇到问题好解决；Mac 的 Metal 生态这几年进步很大，主流框架基本都支持；NPU 的生态就参差不齐了，可能要为每个模型单独折腾。选硬件时，把软件生态的成熟度也算进去，能省下大量时间。
7. 我自己的几点体会
折腾本地大模型这一年多，最大的感受是：硬件参数只是起点，真正的体验取决于软硬件的匹配程度和你对工作负载的理解。一台参数漂亮的机器，如果模型装不下、框架不支持、散热压不住，体验可能还不如一台配置普通但调优到位的机器。
32GB Mac mini 给我的最大惊喜不是速度，而是"省心"——统一内存架构让内存管理简单了很多，不用担心显存爆掉，主流框架对 Metal 的支持也越来越好。它的短板也很明确：带宽有限，跑大模型速度上不去；散热一般，长时间高负载会降频。但作为一台日常能跑 7B 到 14B 模型的开发机，它在这个价位上很难找到对手。
最后分享一个小心得：别一上来就追求跑最大的模型。先用一个 7B 的 Q4 模型把整条链路跑通，熟悉框架、调优参数、观察资源占用，等这些都摸清楚了，再逐步往上加模型规模。这样每一步都有反馈，遇到问题也知道是哪一环出的错。直接上大模型，一旦跑不起来，你连问题出在哪都判断不了。
本地推理这条路，硬件是门槛，调优是功夫，耐心是前提。把这三样凑齐了，你就能在自己的机器上拥有一套完全可控的 AI 能力，不用看任何人的脸色。
