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 占用FP324 字节约 28GB约 52GB约 188GBFP16/BF162 字节约 14GB约 26GB约 94GBINT81 字节约 7GB约 13GB约 47GBINT40.5 字节约 3.5GB约 6.5GB约 23.5GB这张表是理想值实际还要加上 KV Cache、激活值、框架开销通常要再留 20% 到 40% 的余量。所以一个 47B 的 MoE 模型用 INT4 量化光权重就 23.5GB加上 KV Cache32GB 内存的机器跑起来会非常紧张基本只能跑很短的上下文。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 为主速度快生态成熟只有核显内存 32GBCPU 为主内存够大能跑量化模型统一内存架构如 MacGPUCPU 共享内存即显存带宽是关键边缘设备带 NPU视生态而定算子支持是最大变数4. 32GB Mac mini 实战统一内存架构下的调优逻辑4.1 为什么 Mac 的统一内存对大模型特别友好Mac mini 的 M 系列芯片用的是统一内存架构Unified Memory ArchitectureCPU 和 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-8BQ4/Q5轻松流畅可开较长上下文13B-14BQ4可行流畅上下文适中30B-34BQ4勉强速度偏慢上下文要压缩47B MoEQ4很勉强权重就占 23GB上下文极短70BQ4不可行权重超 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 到 2GB14B 模型翻倍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 个 token14B 大概每秒 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 能力不用看任何人的脸色。 
长河君 · 2026/11/3 4:08:04 · 阅读 1.2k 本地大模型推理硬件真相：MoE显存、CPU/GPU/NPU分工与32GB Mac mini实战调优
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 占用FP324 字节约 28GB约 52GB约 188GBFP16/BF162 字节约 14GB约 26GB约 94GBINT81 字节约 7GB约 13GB约 47GBINT40.5 字节约 3.5GB约 6.5GB约 23.5GB这张表是理想值实际还要加上 KV Cache、激活值、框架开销通常要再留 20% 到 40% 的余量。所以一个 47B 的 MoE 模型用 INT4 量化光权重就 23.5GB加上 KV Cache32GB 内存的机器跑起来会非常紧张基本只能跑很短的上下文。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 为主速度快生态成熟只有核显内存 32GBCPU 为主内存够大能跑量化模型统一内存架构如 MacGPUCPU 共享内存即显存带宽是关键边缘设备带 NPU视生态而定算子支持是最大变数4. 32GB Mac mini 实战统一内存架构下的调优逻辑4.1 为什么 Mac 的统一内存对大模型特别友好Mac mini 的 M 系列芯片用的是统一内存架构Unified Memory ArchitectureCPU 和 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-8BQ4/Q5轻松流畅可开较长上下文13B-14BQ4可行流畅上下文适中30B-34BQ4勉强速度偏慢上下文要压缩47B MoEQ4很勉强权重就占 23GB上下文极短70BQ4不可行权重超 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 到 2GB14B 模型翻倍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 个 token14B 大概每秒 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 能力不用看任何人的脸色。