本地大模型这几年最火的三个词，基本绕不开 MoE、CPU/GPU/NPU 和 Mac mini。但真正动手部署过的人心里都有数：网上关于这三件事的说法，一半是半懂不懂的人在传。比如“MoE 模型体量太大，32GB 显存别想碰”“NPU 马上要取代显卡”“Mac mini 跑大模型纯属摆拍”……这些论断要么只说对了一半，要么完全把因果关系想反了。今天这篇文章，我就把本地大模型硬件层面的实测结论、带宽计算方式和几个真正有效的调优点摊开讲清楚。适合三种人看：想买设备跑本地模型但预算有限的人、已经在用 Ollama/LM Studio 但速度始终不理想的人，以及那些负责给团队搭本地大模型服务、需要给老板解释“钱花哪了”的人。
1. 先把“吃硬件”这件事说透：大模型推理到底在跑什么
很多人一上来就纠结“CPU 算力多少”“TOPS 多高”，但本地大模型推理的性能瓶颈，绝大多数情况下根本不是算力，而是内存带宽。这个认知如果不建立，后面所有选择都会跑偏。
1.1 推理的两阶段：Prefill 和 Decode
大模型生成回答的过程可以拆成两个阶段。
第一阶段叫 Prefill（预填充），也就是你输入 prompt 之后，模型要一次性把整段输入都“读”进去做并行计算。这个阶段是计算密集型的，GPU 的浮点算力、CPU 的 AVX512 指令集、Mac 的矩阵加速单元，在这个阶段能拉开明显差距。
第二阶段叫 Decode（解码），模型一个 token 一个 token 地往外蹦。真正用起来的时候，你会发现大部分时间都耗在这里。这个阶段每个 token 做的计算其实很少，但因为每生成一个 token 都要把整个模型权重从头到尾读一遍，所以它变成了纯粹的内存密集型操作。谁的内存带宽高，谁生成得更快。
用一句话概括：Prefill 看算力，Decode 看带宽。日常聊天、写文章这种场景，90% 的等待时间都在 Decode 上，所以带宽的重要性被绝大多数人低估了。
1.2 一个估算公式和一张对比表
圈子里有个经验公式，能大致估算本地推理的 Decode 速度：
每秒生成 token 数 ≈ 内存带宽（GB/s）÷ 模型权重体积（GB）× 0.5~0.6
比如说一个 7B 模型用 4-bit 量化后大约是 4.4GB。如果设备带宽是 120GB/s，理论极限大约 27 token/s，实际打五到六折，大概能跑到 15~18 token/s；如果设备带宽只有 50GB/s，那就只有 6~8 token/s，用起来会明显觉得“一个字一个字往外蹦”。
我把常见四类设备的带宽和特点放在一张表里，这张表基本就可以当成选购指南用：
| 设备类型 | 典型代表 | 有效带宽范围 | 显存/内存容量 | 运行 7B Q4 估算速度 |
|---|---|---|---|---|
| 普通 CPU 平台 | 双通道 DDR4-3200 / DDR5-4800 | 40~80 GB/s | 受主板内存限制 | 5~10 token/s |
| 消费级 GPU | RTX 4060 Laptop（8GB GDDR6） | 约 256 GB/s | 8~16GB 显存 | 40~60 token/s |
| 高端 GPU | RTX 4090 / 3090 | 800~1000 GB/s | 24GB 显存 | 100 token/s 以上 |
| Apple 统一内存 | 32GB Mac mini（M4 芯片） | 约 120 GB/s | 可共享给 GPU | 15~20 token/s |
| NPU | 各类笔记本 NPU、SoC NPU | 通常 10~50 GB/s | 共享内存，受限 | 不适用于通用 LLM |
这里面最反直觉的一条就是：8GB 显存的笔记本显卡，跑 7B 模型的速度能吊打 32GB 的 Mac mini。因为游戏显卡的 GDDR6 显存带宽是普通系统内存的好几倍。Mac mini 能打的点在于容量而不是速度，这个后面专门讲。
2. MoE 架构的真相：不是“参数太多放不下”，而是“带宽不够用”
“MoE 架构要全部参数进显存吗”这个问题，我几乎每周都被问一次。先说结论：加载模型的时候，是的，所有专家权重都需要住进内存里；但推理计算的时候，不是，每个 token 只会激活少数几个专家。这两句话之间的差异，决定了 MoE 在大规模集群上很香、在消费级设备上却很尴尬。
2.1 总参数 vs 激活参数：MoE 省的是算力，不省内存
MoE（Mixture of Experts，混合专家）模型的思路是：把原来一层里巨大的前馈网络拆成很多个“专家”子网络，每次推理只让其中少数几个专家干活，由路由网络（Router）根据输入决定谁上。
以最出名的 Mixtral 8x7B 为例：总参数约 47B，但每个 token 只会激活约 13B 参数。从算力角度看，它比同体量的 47B 稠密模型便宜得多，甚至比 13B 稠密模型还快，因为解码时只需要计算被激活的专家。这就是 MoE 在云端被追捧的原因——用更少的 FLOPs 换取更大的模型容量。
但问题在于：你依然需要把 47B 全部权重放到内存或显存里才能运行。就像一家大公司虽然每次只让几个部门干活，但工位必须给所有人都留着。Mixtral 8x7B 用 4-bit 量化后大约 26GB，这个体积已经超过了绝大多数消费级显卡的 24GB 显存，普通 16GB 内存的电脑更不用说，加上系统和上下文就直接爆了。
2.2 那能不能只把用到的专家放显存？——Expert Offloading 的现实
既然每次只激活两个专家，理论上确实是“可以把不活跃的专家放在内存里，用到了再从内存调进显存”。这种方案叫 Expert Offloading，在 llama.cpp 和部分推理引擎里已经探索过了。结果很现实：能跑，但速度难看。
原因很简单，Expert Offloading 的本质是用速度换容量。每处理几个 token，如果路由到不同的专家，就需要把新专家从系统内存搬运到显存，这个搬运过程本身也在吃带宽。搬运一次动辄几十上百 MB，来回几次，就把带宽优势全赔进去了。实测下来，Mixtral 8x7B 在 16GB 内存 + 8GB 显存的笔记本上做这类方案，速度往往只有 1~2 token/s，基本属于“能看出是中文，但要等”的状态。
所以你的选择只有两个：要么上一块能装下整个模型的卡——24GB 显存起步；要么干脆不要碰桌面级 MoE，老老实实选 7B、14B 的稠密模型。对个人用户来说，这就是 MoE 的真实位置：属于云端和团队服务，不属于个人笔记本。
2.3 MoE 在小设备上还有机会吗：小 MoE 和 CPU 推理
不是说小设备完全和 MoE 无缘。通义千问有一版 Qwen1.5-MoE-A2.7B，总参数 14.3B、激活参数仅 2.7B，量化后大约 8GB 左右，32GB 内存的设备就能装下。这种“小 MoE”在消费级设备上比同容量的稠密模型有一点速度优势，跑起来的感觉和稠密 7B 差不多，但知识上限更高。
但我不建议普通用户把希望寄托在这类实验性模型上。原因一是生态不成熟，二是很多 MoE 模型的量化支持、推理内核优化都落后于主流稠密模型。我实测过同一个设备上跑 Qwen1.5-MoE 和 Qwen2.5-7B，后者在 Ollama 里的兼容性和速度都明显更省心。结论很朴素：消费级硬件上，贪图 MoE 的“先进感”不如选一个优化成熟的稠密模型。
至于搜“moe 负载均衡代码”想自己折腾训练或分布式推理的朋友，我劝一句：那是要在大规模集群上解决“专家过热”问题的，单个消费级设备上没有这个烦恼，也没有必要研究。这块知识的门槛不在代码，而在集群和网络架构，个人项目直接跳过即可。
3. CPU、GPU、NPU 三条路线：谁适合跑本地模型
聊完 MoE，我们把 CPU/GPU/NPU 三条路分别过一遍。每个方案的真实场景、性能上限和陷阱我都踩过，挑重点说。
3.1 CPU 路线：能跑，但不一定跑得快
CPU 跑大模型的优势只有一条：不需要买任何新硬件，手上有什么用什么。笔记本也好、老台式机也好，内存加到 32GB 以上，装个 Ollama 就能跑 7B 模型。
但 CPU 路线的瓶颈极其清晰。普通台式机的双通道内存带宽上限就摆在那里，DDR4-3200 大约 50GB/s，DDR5-5600 大约 90GB/s。按照前面那个估算公式，7B 量化模型的极限速度也就是 6~15 token/s 之间，这还是理想情况，实际因为系统还要占用内存带宽，还会再打折。
我见过很多人拿公司配发的办公笔记本跑大模型，跑通没问题，但用起来像拨号上网。如果只是偶尔做做文本分类、跑个 embedding，或者用 RapidOCR 这种轻量任务，CPU 完全够用。但你要拿它来对话、写代码、做知识库问答，那个等待体验会让人直接失去耐心。顺带一提，我经常看到有人问“RapidOCR 太吃 CPU 怎么办”，这个库在小尺寸图片上 CPU 跑还算凑合，但遇到批量高清图，CPU 推理真的会被拖死，换 GPU 版或者用并行进程分开跑是更现实的办法。把它的任务丢给 GPU，CPU 就能腾出来给其他的模型推理用。
3.2 GPU 路线：先看显存，再看带宽，最后看算力
GPU 的三层关系用一句话概括：显存决定能不能跑，带宽决定快不快，算力决定 prompt 处理猛不猛。
对本地部署来说，显存容量是第一硬指标。8GB 显存的笔记本显卡（比如 RTX 4060 Laptop GPU）严格来说只能舒适运行 7B~8B 的量化模型；14B 模型量化后大约 8~9GB，勉强能塞进去但在上下文拉长之后随时可能爆显存，只能开部分 offload，速度反而暴跌。32B 的模型在 8GB 显存上基本不用想。
所以我给身边人的建议一直是：预算够就上 24GB 显存的卡，成年人不要和自己的上下文长度过不去。而现实是很多人的电脑是“Intel UHD Graphics + NVIDIA GeForce RTX 4060 Laptop GPU”这种双显卡配置——核显负责屏幕显示，独显负责计算。问题来了：这种混合架构下，PyTorch、ComfyUI 或者 Ollama 偶尔会把任务默认甩给核显，导致性能暴跌。我的处理办法是去 Windows 的“设置 → 系统 → 屏幕 → 图形”，把对应程序手动指定为“高性能显卡”，或者在 NVIDIA 控制面板里把 CUDA 设备强行绑定到独显。这点稍后细说。
带宽方面，RTX 4060 Laptop 大约 256GB/s 的显存带宽，跑 7B Q4 模型能到 40 token/s 以上，体验是“完整句子直接甩出来”。如果你问的是桌面级 4090，24GB 显存加 1000GB/s 的带宽，那就是另一个世界了——14B 模型能跑到 100 token/s 以上。如果你要在大模型上投入，优先加钱买显存容量，其次是带宽，最后才是流处理器数量。
3.3 NPU 路线：为什么 Ollama 不支持 NPU，以及 NPU 到底有什么用
现在很多新笔记本把 NPU（神经网络处理单元）当卖点，特别是 Intel Core Ultra、AMD Ryzen AI 那批芯片。但搜“Ollama 为什么不支持 NPU”的人特别多，答案不是厂商偷懒，而是架构和场景压根不匹配。
首先，NPU 的 TOPS 数值看着唬人，但它衡量的通常是结构化卷积和矩阵乘法的吞吐，频繁依赖权重重载、分支路由和动态形状的 Transformer 解码任务，并不适合 NPU 的流水线。其次，NPU 的内存访问能力受限于 SoC 设计，带宽和容量都远不如独立显卡，而大模型 Decode 恰恰最吃带宽，等于让游泳冠军上岸跑马拉松，满身力气使不出来。最后，NPU 的算子库、编译器和驱动各家各一套，Ollama 背后的 llama.cpp 生态优先支持的是 CUDA、Metal、Vulkan 这些通用后端，NPU 的碎片化严重，投入产出比极低。
那 NPU 是不是废物？不是，它的真正战场是持续在线、功耗敏感、小体量模型的任务。比如笔记本摄像头背景虚化、语音唤醒、实时降噪、小规模的手势识别，这些任务功耗和设备发热很敏感，NPU 让电池损耗更低。至于拿 ComfyUI 去调 Intel NPU 跑图像模型，目前只有极少数的 OpenVINO 实验性支持，体验远不如直接用 GPU。我的建议很直接：如果你买电脑的初衷包括本地跑大模型，完全不用为 NPU 这个标签多付一分钱。
3.4 同模型、不同设备的速度对照
这几条路线到底差多少？我拿 Qwen2.5-7B（Q4_K_M，约 4.4GB）做个常见设备对照，方便你对号入座：
| 运行环境 | 有效带宽参考 | Decode 速度实测感受 |
|---|---|---|
| 双通道 DDR4 台式机 | ~50 GB/s | 6~8 token/s，能接受但明显拖沓 |
| 32GB Mac mini（M4） | ~120 GB/s | 15~20 token/s，日常聊天可用 |
| RTX 4060 Laptop GPU | ~256 GB/s | 45~60 token/s，流畅 |
| RTX 4090 | ~1000 GB/s | 100+ token/s，飞一样 |
这里的速度是“客厅算法”，实际还会受到模型量化格式、上下文长度、系统负载等因素影响，但横向对比的结论不会变。GPU 在速度上的优势是不可替代的，Mac 统一内存则胜在大容量和静音低功耗。
4. 32GB Mac mini 实战调优：从装环境到压榨最后一点性能
很多朋友入手了 32GB Mac mini，满心欢喜装好 Ollama，一跑却发现速度没想象中那么神，于是怀疑自己买错了。实际上 Mac mini 不是不行，而是默认配置太浪费潜力了。我拿这台机器实测了半年，把调优过程完整分享出来。
4.1 为什么 Mac mini 值得聊：统一内存和 Metal 是两板斧
Mac mini 的底层逻辑和传统 PC 完全不同。Windows 平台上是 CPU 内存和显卡显存物理隔离，数据搬运要跨 PCIe 总线；而 Apple Silicon 用的是统一内存架构（Unified Memory），CPU 和 GPU 共享同一块物理内存，模型加载不需要拷贝，GPU 能直接访问完整容量。对于“大模型要住进显存”这个需求来说，物理隔离的那道墙没了。
我实测 32GB Mac mini（M4）跑 14B 的 Qwen2.5（Q4_K_M，约 9GB），解码速度在 10~14 token/s 之间浮动，跑 7B 则稳定在 16~20 token/s。作为对比，32GB 普通内存的 x86 笔记本跑同样模型要慢一倍左右，因为它的“显卡”还要通过共享内存的方式去抢系统带宽。所以同样标 32GB 内存，Mac 跑本地模型的体验上限要高得多。
4.2 选模型和量化格式：别拿 Q8 巨兽折磨小内存
在 32GB 机器上，我最推荐的组合是14B 模型 + Q4_K_M 量化，顺手流畅，知识密度也比 7B 高一截。32B 模型（量化后约 18~20GB）虽然装得下，但在 M4 这颗芯片的 120GB/s 带宽下只有 4~6 token/s，用来做凌晨批量任务可以，日常对话会让人暴躁。
量化的选择上，我一般在 Ollama 里默认 Q4_K_M。它比 Q5、Q8 小很多，但质量损失对绝大多数使用场景不可感知。千万别为了“原汁原味”去选 Q8 版本，那个体积换来的分数提升非常有限，速度却会直接砍半。本地部署的第一原则是：让模型跑起来，而不是让模型完美地、慢吞吞地跑起来。
4.3 上下文长度和 KV Cache：32GB 也不是无限大
一个大坑是上下文长度。很多人喜欢一股脑把 context length 拉满，然后发现速度骤降甚至直接卡死，根本原因是KV Cache 也在吞内存。它随上下文长度线性增长，不同模型的增长速率不同，但一个 14B 模型开 32K 上下文，KV Cache 吃 2~3GB 内存很正常。加上模型权重，32GB 很快就见底了。
我的经验是：日常使用把上下文设置在 8K~16K 就够，到需要处理长文档的特定任务再临时拉长。另外 macOS 在内存吃紧时会启动 swap，一旦开始用硬盘换页，速度就会从“慢”变成“没法用”。你可以用活动监视器里的“内存压力”图确认这一点。
Ollama 有几个环境变量值得记住：
OLLAMA_CONTEXT_LENGTH：控制默认上下文长度，我一般设16384。OLLAMA_KV_CACHE：不同版本支持不同策略，最新版可以设为q8_0对 KV Cache 做量化，能省下相当可观的内存。OLLAMA_MAX_LOADED_MODELS=1：避免同时加载多个模型互相挤占内存。
4.4 显存占用上限：一个被忽略的 sysctl 参数
Apple Silicon 上，GPU 能拿到的“显存”并不是无限大，系统有一个上限机制。默认情况下模型加载到一半可能报Metal device out of memory，但升级内存又犯不着。和 NVIDIA 平台的nvidia-smi查显存类似，Mac 上可以执行：
sudo sysctl iogpu.wired_limit_mb=24576这个命令把 GPU 的可锁定内存上限提高到 24GB，给模型留出足够空间。注意这个值和系统内存是共享的，不要直接拉到满，否则系统自身的内存都不够了。我一般留 6~8GB 给 macOS 自己和常用软件。改完之后重启或重新加载模型才会完全生效，而且它会在重启后恢复默认，需要的话得写进启动脚本。
4.5 实测调优：同样的机器、不一样的体验
我把“默认状态”和“调优状态”做了个直观对比，跑的是 14B Qwen2.5 Q4：
| 配置项 | 默认状态 | 调优状态 |
|---|---|---|
| 上下文长度 | 4096 | 16384（按需开） |
| KV Cache | FP16 | q8_0 |
| GPU 可用内存上限 | 默认 | 24GB |
| 内存压力 | 偶尔变黄 | 稳定绿色 |
| 长文档问答 | 中途卡顿/截断 | 流畅完成 |
这套组合折腾完，同一台 32GB Mac mini 跑 14B 模型的实用度提升非常明显，特别是配合本地知识库（Ollama + embedding 模型 + 向量库）做 RAG 问答时，长上下文的稳定性决定了整个系统能不能用。
5. 本地部署常见问题与排查实录
本地部署的坑说多不多，说少不少，都是有规律可循的。我把这一年里被问得最多的几类问题整理成速查表，每个都附上实际排查思路。
5.1 双显卡笔记本：模型被核显“劫持”了怎么办
Windows 笔记本同时挂着 Intel UHD Graphics 和 NVIDIA RTX 4060 Laptop GPU 的太多见了。症状是跑模型时 GPU 利用率几乎为 0，速度却很慢，任务管理器里 Intel 核显却在悄悄发力。
排查顺序是这样的：
- 在 Windows“设置 → 系统 → 屏幕 → 图形”里，把 Ollama、Python、ComfyUI 手动指定为“高性能（独显）”。
- 打开 NVIDIA 控制面板，在“管理 3D 设置”里把 CUDA-GPU 指定为 RTX 4060 Laptop GPU。
- 如果 PyTorch 仍然装了 CUDA 但
torch.cuda.get_device_name()显示不对，检查nvidia-smi驱动是否正常，必要时更新驱动。
大多数情况下，前两步就能解决。
5.2 ComfyUI 插件冲突和 Chrome GPU 加速异常
ComfyUI 桌面版装 Crystools 这类监控插件时报冲突，通常不是插件本身坏了，而是版本和 ComfyUI 内核不匹配。处理办法很直接：确认 CPU 型号和 CUDA 版本，然后卸载插件重新安装最新版，或回滚到该插件 README 里写明的兼容 ComfyUI 版本。如果还不行，启动 ComfyUI 时加--disable-crystools先跑起来，再单独研究插件版本。
Chrome 提示 “GPU not support acceleration” 或者开了 GPU 加速但没效果，多数情况是浏览器对某种独显/驱动的适配问题。尝试在地址栏输入chrome://flags，把 “Use ANGLE” 改回默认或选择 OpenGL，很多笔记本能直接解决。这个不影响大模型部署，但会让你心情变好。
5.3 PyTorch GPU 装不上、Termux GPU 加速的真相
PyTorch 装完发现跑的还是 CPU，九成问题是安装源不对。正确姿势是去 PyTorch 官网选好自己 CUDA 版本对应的安装命令，类似：
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121装完后在 Python 里验证两行：
import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))如果第一行返回 False，不是 PyTorch 的问题，是驱动版本太低，先升级 NVIDIA 驱动。
至于 Termux 里搞 GPU 加速，老实说这是个很偏门的方向。Android 设备上 Termux 能用 Vulkan 后端跑 llama.cpp 的移植版，部分旗舰 SoC 能跑通 7B 模型，但速度、散热和驱动完整度都不稳定。图新鲜可以试试，真要当生产力工具，老老实实上 PC 或 Mac。顺带说，经常有人问 RK3588 能不能靠“升级 NPU”来跑大模型，答案是没法升级，NPU 是封装在 SoC 里的，外部只能加 USB 加速卡，整体性价比极低，玩板子可以，别当正事。
5.4 FunASR、RapidOCR 这类模型为什么吃 CPU 吃到爆
语音识别模型 FunASR、OCR 的 RapidOCR 这些场景，很多人部署时发现 CPU 占用拉满但速度还是很慢，于是怀疑代码写得有问题。其实答案很简单：这些模型默认跑在 CPU 上，而它们虽然参数量不大，但内部计算密集度很高，CPU 要同时处理 prefill 和 decode 的混合负载，自然吃力。
解决办法是给 PyTorch 装好 CUDA 环境后，显式地把模型推到 GPU：
model = model.to("cuda")同理，部署本地知识库时 embedding 模型也可以全部放 GPU，把 CPU 腾出来给主模型。千万别让 embedding、OCR、语音识别三个模型同时在 CPU 上抢饭吃，这个教训我体会很深，整个系统会像死机一样迟钝。
6. 用得起更要管得起：多人场景下的成本与运维真相
关于“花了二三十万买硬件部署本地大模型会有多少运维工作量”和“搭建一个 200 人用的本地大模型需要多少钱”，我直接说结论：硬件购买只是一次性成本，真正的开支大头是运维的人工成本和持续的服务质量维护。
6.1 二三十万的部署：能力上限和时间账单
二三十万的预算在企业采购里大概能买到 4 张 24GB 显存的 Pro 级显卡（比如 RTX 6000 Ada 或 A6000 级别）加一台像样的双路 CPU 服务器，挂上大容量 SSD 和企业级 UPS。这个规模能跑什么？一个 70B 模型的 int8 量化版本，或者几个不同规格的 7B~32B 模型并行服务 200~300 人的团队，看并发需求而定。
但接下来才是重点：部署只是开始，之后每个月都要面对 CUDA 驱动和推理引擎的升级、模型版本更新、向量库备份、日志监控、容器资源调整、偶尔的显卡风扇异响和掉驱动。更别提多人并发时出现 OOM、单用户长上下文把显存占满拖垮全体、半夜模型进程崩了没人管这些每天都在发生的事情。我见过太多团队，采购时信心满满，三个月后开始后悔没买云服务。二三十万的硬件，如果不配一个懂行的运维，等于买回来一个需要全职伺候的新同事。
6.2 200 人团队的真实需求估算
200 人的团队，重点不是“200 人”，而是“高峰并发有多少”。绝大多数团队真正同时在线发起请求的人不会超过 10~20 个。按 20 个并发计算，跑一个 13B 量化模型，配合 vLLM 的 continuous batching，24GB 显存起步、双卡更稳，预算大约在 4~8 万之间就能拥有不错的体验。
如果要不限规模的并发，或者跑更大的模型，那就不是买几块显卡的问题了，而是要引入推理集群、负载均衡和 GPU 池化调度，预算直接指数级上升。对 95% 的内部知识库场景，一台 48GB 或 64GB 显存的机器就够开始干事了。别一开始就奔着“大”去，先问自己，团队是不是真的有那么多人每天在用。
6.3 监控不是可选项：Prometheus + Grafana 盯 GPU/NPU
二三十万的硬件不配监控，等于闭眼开车。NVIDIA GPU 有现成的 DCGM Exporter，可以无缝接入 Prometheus，把显存占用、利用率、温度、功耗全部暴露成指标，再扔给 Grafana 做面板。NPU 资源也有对应 exporter（昇腾 NPU、部分 SoC NPU 都有配套方案），虽然起步麻烦一点，但监控逻辑一致。
我自己的实践是三层监控：第一层看 GPU/NPU 的核心指标，第二层看推理服务的请求队列长度和延迟，第三层看模型版本和上下文长度分布。这样模型服务出问题时，能快速定位是显卡坏了、显存不够，还是某个用户拖了个超长文本进来。
最后再分享一个经验
设备购买这件事，我用一句话总结：买之前先算带宽，算完带宽再算容量，算完容量再算价格，最后把运维成本翻一倍当成真实预算。我自己吃过最大的亏，就是当年只看“能不能装下”就下单了一块 8GB 显存的卡，结果模型装得下、跑起来磕磕绊绊，最后只能卖掉换 24GB。而 32GB Mac mini 则是我一直留着用的机器，它不强在速度，强在“安静地、稳定地、大容量地”把模型跑完——适合个人和轻量团队，但追求高速并发还是老老实实上 NVIDIA GPU 平台。希望这篇从 MoE 到 CPU/GPU/NPU 再到 Mac mini 调优的文章，能帮你把每一分钱都花在刀刃上。
