本地大模型硬件选型指南：从MoE架构到32GB Mac mini实战调优

这两年我身边越来越多朋友开始问一句话到底什么样的电脑才能把本地大模型跑得又快又不卡问的人里有做知识库的、写代码的、搞内容创作的也有纯粹想在公司内部搭一套“不联网也能用”的模型服务的。但市面上的说法实在太乱了——有人告诉你必须上 4 张卡有人又拿着一台 Mac mini 说跑得飞起。作为从 Llama 2 时代一路折腾到 MoE 模型的人我想把本地大模型硬件这件事彻底讲清楚MoE 到底是什么玩意儿、CPU/GPU/NPU 各自能干什么、32GB 内存的 Mac mini 到底够不够用、以及怎么把它调到头。这篇不是参数堆砌是我自己踩坑后的实战笔记。适合准备入坑本地大模型、正在纠结买什么硬件的朋友也适合手里已经有 32GB Mac mini、想榨干它性能的同学。看完你至少能回答三个问题8GB 显存为什么跑不动 70B 模型、MoE 为什么又慢又快、以及 Mac 的 NPU 为什么现在还用不上。1. 本地大模型到底在拼什么先看懂算力需求的金三角很多新手第一次跑本地大模型第一反应是“我 CPU 是不是不行”然后疯狂看核心数、主频。但实测下来你会发现CPU 跑大模型的瓶颈往往不在计算核心而在内存带宽和容量。要理解这个问题得先把本地大模型消耗的资源拆成三块内存容量、内存带宽、计算单元的算力。这三者形成一个“金三角”缺哪块都会拖后腿。1.1 显存/内存是第一道门槛大模型推理的第一步是把模型的权重完整加载进内存。注意是完整加载不能像普通程序那样按需读取。为什么因为每次生成一个 token都需要把模型里所有相关参数读一遍做矩阵乘法如果权重放在磁盘上用那速度慢到没法用。一个模型到底要占多少内存有个非常简单的估算公式参数量 × 每参数字节数。FP32 精度下每参数占 4 字节FP16/BF16 占 2 字节INT8 占 1 字节INT4 占约 0.5 字节。所以一个 7B 参数的模型FP16 精度要 14GB 左右如果量化成 INT4只要 3.5GB 左右。这也是为什么 8GB 显存勉强能跑量化后的 7B 模型但跑不了 FP16 的 13B 模型的根本原因。由此可以理解为什么带 32GB 统一内存的 Mac mini 有底气你可以同时放一个 20GB 的 MoE 模型和 8GB 的上下文数据这是传统 8GB 显存显卡做不到的。但要注意系统本身也要吃内存macOS 大概会占用 4-6GB所以 32GB 实际能用的只有 26GB 左右算的时候留点余量。1.2 带宽决定了每秒能吐多少字内存容量解决了“装不装得下”的问题带宽解决“跑得多快”的问题。大模型生成 token 的过程本质上是反复把全部权重从内存搬到计算单元里去算一遍。每生成一个 token 都要扫一遍整个模型所以推理速度的上限几乎被内存带宽锁死。拿 7B INT4 模型来说权重约 4GB。如果内存带宽是 20GB/s普通 DDR4 双通道水平理论最高也就每秒 5 个 token实际还得打折。但如果是 120GB/s 带宽的 M4 芯片理论能到 30 token/s 左右体验就完全不一样了。这解释了那个反直觉的现象Mac 跑大模型比很多游戏本还快不是 Mac 的 GPU 多强而是统一内存带宽高。这里有个近似公式可以算个大概token/s ≈ 内存带宽 / 模型权重大小。虽然实际还要考虑计算时间、系统延迟、上下文处理等因素但拿来做个选型预判已经足够。举个例子32GB Mac mini 的带宽如果是 120GB/s跑 4GB 的量化 8B 模型理论上限约 30 token/s实际 20-25 之间都很正常。1.3 计算单元决定单次推理能跑多快内存带宽决定了“吞吐上限”但计算单元决定了单个矩阵乘法到底能算多快。GPU 之所以是大模型推理的主力是因为它有很多核心并行做浮点运算算力远超 CPU。但在推理场景尤其是小 batch 生成时计算并非绝对瓶颈因为每一步都要等权重从内存里搬运过来。所以经常出现“GPU 利用率不高但速度也不算慢”的现象。不过在 decode 阶段如果模型很大、算子没优化到位计算也会成为瓶颈。比如跑 FP16 的 70B 模型即使用 A100每一步的浮点运算量也不小GPU 核心会明显拉高占用。另一个不可忽视的是负责矩阵乘法的 Tensor Core/CUDA Core 数量Apple Silicon 的 GPU 虽然算力不差但没有专门的 Tensor Core跑大模型时只能靠通用型 FP16/INT8 算力兜底好在 Metal 的底层优化还不错。三种资源的实际关系可以用一个场景描述模型从内存搬到计算单元需要花时间。如果搬运时间远大于计算时间那就是“带宽瓶颈”如果计算时间远大于搬运时间那就是“算力瓶颈”。本地跑 7B-32B 范围的模型带宽瓶颈居多这也是为什么优化目标往往是提升有效带宽。2. MoE 架构为什么改变硬件取舍说到本地大模型绕不开 MoEMixture of Experts混合专家。这两年热门的模型很多都是 MoE 结构。它对硬件的冲击非常大——你可能看到一个模型有 70B 参数以为必须超大显存才能跑但实测 32GB 的电脑居然能跑得挺快。原因就藏在 MoE 的工作方式里。2.1 MoE 拆解路由机制与专家网络MoE 的核心思路是把一个大模型拆成很多个“专家子网络”然后加一个“路由器”。处理每个 token 时路由器决定哪些专家参与计算而不是让所有参数都参与。传统稠密模型处理每个 token 时全部参数都要参与计算所以参数量越大单次推理越慢。而 MoE 模型参数量虽然很大但真正被激活的参数只是一小部分推理成本取决于“激活参数量”而不是“总参数量”。举个例子经典的 Mixtral 8x7B 总参数约 47B但推理时每个 token 只会激活 2 个专家激活参数量约 13B。所以它在计算量上接近一个 13B 稠密模型速度却有着接近 47B 模型的能力上限。这就是 MoE 最大的诱惑用更少的算力换更大的能力空间。对硬件选择的影响立竿见影计算压力下降了但内存压力没有下降。因为即使不用某个专家它的权重也必须被加载到内存中保证路由器随时可以调用。所以你要准备的内存容量依然要按照“总参数量”来算。这就导致 MoE 模型在普通电脑上呈现一种奇特的姿态装得下但内存会被占得很满。2.2 MoE 模型内存特性为什么显存焦虑更重仅拿 Mixtral 8x7B 来说FP16 精度要吃掉约 90GB 内存这个容量几乎劝退所有消费级设备。但经过 INT4 量化后它大约只需要 26GB 内存这样 32GB 的 Mac mini 才能勉强塞进去。这也解释了为什么量化成了本地跑大模型玩家的“第一技术”——没有量化Mixtral 这类 MoE 根本无法平民化。另一个需要注意的细节是 MoE 模型的 KV Cache 和共享部分。有些 MoE 模型为了节省内存会设计共享专家或者共享层导致量化后的体积没那么好估算。实战中我都是直接看 Ollama/llama.cpp 下载时显示的模型体积以那个为准做内存规划宁可多留 2-3GB 余量也不要满打满算因为 Mac 统一内存一旦吃满就会疯狂走 swap卡顿到你怀疑人生。韩系和国内不少团队做的 MoE 模型如 Qwen 系列的大规模版本也有类似特性。如果你手头只有 16GB 内存我只推荐跑 Qwen 7B/14B 这一档跑 MoE 大概率要卡。若真想体验 MoE最低建议 32GB 起步否则时间都耗在内存交换上根本没有体验可言。2.3 为什么 MoE 在 Apple Silicon 上反而有优势传统 N 卡 GPU 有 8GB/16GB/24GB 显存跑大模型第一步看显存够不够不够就得换卡Money 一票否决。而 Apple Silicon 的 MacCPU 和 GPU 共用同一块内存模型无论被 CPU 还是 GPU 访问走的都是同样的内存空间。这给 MoE 提供了天然土壤26GB 的量化模型放进统一内存里GPU 可以直接访问。另外 Mac 的内存带宽很高M 系列芯片的带宽从 100GB/s 到 800GB/s 不等比普通 DDR4 内存高出一大截甚至接近入门级独立显卡的 GDDR6 显存带宽。MoE 模型在推理时虽然要扫描全部权重但只计算局部专家如果带宽够高扫描权重造成的延迟就会被压低推理速度反而能接受。但这不意味着 Mac 是 MoE 万能机。如果模型太大比如某些 100B 的 MoE 模型32GB 内存依然装不下加钱上 64GB 或 128GB Mac Studio 又是一笔大开销。只能说在消费级预算内Mac 的统一内存在 MoE 场景下比同价位 N 卡加主板组合更灵活但别指望它能挑战多卡服务器。3. CPU、GPU、NPU三种算力的分工与取舍聊硬件绕不开平台。CPU、GPU、NPU 这三者到底什么关系很多人买个带 NPU 的笔记本以为能本地跑大模型结果一问发现根本用不上。这里我直接说结论现阶段本地大模型的主力算力还是 GPUCPU 是兜底NPU 基本是摆设。下面展开讲。3.1 CPU 推理能吃但慢什么情况下能打CPU 推理不是不行只是慢。llama.cpp 本身就有纯 CPU 版本跑起来也是可以的。比如在上古 Intel 机器上跑 7B 量化模型速度大概 3-6 token/s勉强能看文字但远谈不上流畅。CPU 的优点是内存容量大、便宜可以加载超大模型缺点是内存带宽和计算并行度普遍不够适合“能跑起来就行”的场景比如服务器内存极大的情况。还有一个容易被忽略的 CPU 场景Mac 上的 GPU 不够用时llama.cpp 会把一部分层放在 CPU 上计算利用的是 Apple Silicon 的高性能核心。这就引入了“GPU 层数”这个概念后面调优部分我会细说。CPU 推理还有个好处是兼容性极好任何架构都能跑不用装驱动所以很多开发者在 Docker 容器里测试模型反而用 CPU 版本更省心。不过如果你追求交互体验CPU 只是过渡选择。在本地起一个 8B 模型CPU 推理和 GPU 推理的差距可能达到 5 到 10 倍。像 Mac mini 这种芯片Metal GPU 能利用统一内存加分CPU 反而帮不上什么忙除非你手动把模型切成多层让 CPU 协同处理。3.2 GPU 推理目前的主流但不是唯一答案GPU 之所以是主流原因是它天生为大规模并行计算设计而且生态完善——CUDA 的 cuBLAS、TensorRT、vLLM几乎把所有底层优化都做完了。你装好驱动模型跑起来就是比 CPU 快一大截。N 卡的优势还有 FlashAttention、KV Cache 量化等高级特性这在长上下文中能给明显提速。但 GPU 本地推理有个致命限制显存容量严重约束模型体积。8GB 显存显卡只能跑量化 8B 级别16GB 能跑 14B 和部分 32B 量化想跑 70B 就得 24GB 以上显存而对应显卡价格已经上天。这也是很多玩家转投 Apple Silicon 的原因一块 N 卡 16GB 显存的价格足以买一台 32GB 内存的 Mac mini。Intel 核显、AMD 核显也都能做通用计算但在 macOS 和 Linux 上支持不一驱动和堆栈都不成熟通常只是“能跑”而不是“好用”。我个人的建议是如果你有 24GB 以上的 N 卡优先走 N 卡如果没有Mac 的 Metal 路线反而是性价比和效率综合最好的选择。另外AMD 卡在 ROCm 下也能跑但你要做好折腾的心理准备。3.3 NPU看起来很美实际能用的场景还很窄NPU神经网络处理单元被厂商吹了很多年从手机到 PC 都有专门加速 AI 推断。理论上 NPU 算力效率高、功耗低特别适合端侧模型。但现实是本地的 LLM 推理目前几乎用不上 NPU原因有三点第一主流推理框架llama.cpp、Ollama、vLLM大多没有为各厂商 NPU 做适配。llama.cpp 有 Apple Core ML 分支但主要走的还是 ANEApple Neural Engine加速某些算子并非完整模型推理。第二NPU 的内存和可寻址空间受限很多 NPU 无法直接访问系统全部内存十几 GB 乃至几十 GB 的模型根本放不下。第三驱动和工具链碎片化严重Intel、AMD、高通、Apple 各有各的 SDK跨平台基本没法用。所以现阶段面对 NPU 问题我的态度比较务实先当作“锦上添花”的功能。有些场景下 NPU 确实能跑通小的语音识别或视觉模型但把它作为本地大模型的算力主力还早得很。如果你买笔记本只是看重 NPU 想跑大模型那还不如加钱加内存或者考虑 Apple Silicon 的 GPU 路线。3.4 三平台对比一张表看清楚维度CPUGPUNVIDIAGPUApple MetalNPU推理速度慢极快较快小模型快大模型受限内存容量大受显存限制统一内存较大很小生态支持全平台极强CUDA中等Metal很弱功耗较高高均衡低适用模型7B-13B 量化8B-70B 视显存8B-32B 视统一内存小模型为主调优难度低高驱动/参数中高当前推荐度兜底硬核首选性价比选观望这张表不是绝对答案但它能帮你建立预期不要把所有希望押在 NPU 上也不要被“必须 4090 才能跑大模型”的说法吓住。到目前为止N 卡仍然是生态最完整的平台但对预算有限、想把模型放在手边随时跑的玩家Mac 的 Metal 路线非常值得认真考虑。4. 32GB Mac mini 实战选型、部署与调优说了这么多理论终于到实践环节。我自己用的是 32GB 的 M4 Mac mini日常跑 Ollama llama.cpp配合知识库脚本做 RAG。整个过程踩了不少坑也有很多优化经验。这一节我把选型思路、部署流程、调优参数全部写清楚。4.1 为什么是 32GB Mac mini硬件选型的心路历程先回答大家最常问的问题Mac mini 到底选 M4 还是 M4 Pro内存 16GB、24GB 还是 32GB硬盘 256GB 还是 512GB我推荐的内存起步线是 32GB。理由很实在16GB 的 Mac 跑 8B 量化模型尚可但稍微开个浏览器、开个 IDE内存就紧张更别想跑 Mixtral 8x7B 这种接近 26GB 的 MoE 模型。32GB 属于“够用但不算浪费”的甜点档系统占掉 5GB 左右还能给模型留 24-26GB。这个容量刚好吃下 8B/14B 量化模型也能勉强跑 24-32B 级别量化模型可玩范围最大。具体到 Mac mini 型号M4 的基础带宽是 120GB/s跑 8B INT4 模型已经能有 20-30 token/s日常使用完全没有问题。M4 Pro 内存带宽提升到 273GB/s跑大模型时会明显更快但价格也贵了一截。如果你预算充足M4 Pro 是更好的体验预算有限M4 32GB 先用起来也完全不亏。硬盘方面我建议至少 512GB因为一个大模型动辄 4-8GB多个模型叠加起来很吃空间256GB 很快就会见底。4.2 环境准备从零装好 Ollama 和 llama.cpp部署方面我用的是 Ollama 作为主要工具因为对新手友好一条命令就能拉模型、跑服务。安装方式非常简单brew install ollama ollama serve服务起来后拉取模型并运行ollama pull qwen2.5:7b-instruct-q4_K_M ollama run qwen2.5:7b-instruct-q4_K_M如果你想要更底层的控制建议再编译一份 llama.cpp。在 Mac 上可以直接用 Homebrew 安装brew install llama.cpp llama-cli -m 你的模型路径 -p 你好 -n 128但注意Homebrew 版本的 llama.cpp 不一定启用了 Metal 加速。建议直接从源码构建确保开启 Metalgit clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DLLAMA_METALON cmake --build build --config Release -j编译完用./build/bin/llama-cli测试日志里会看到类似ggml_metal_init的提示说明 Metal 后端已经加载。这里有个小坑如果系统提示缺少 Xcode Command Line Tools先安装它否则编译不过。Ollama 的模型目录也可以通过环境变量放在别的磁盘比如export OLLAMA_MODELS/Volumes/外置盘/models这样能节省内置 SSD 空间而且外置 SSD 对推理速度影响不大因为模型加载后会常驻内存。4.3 模型选型量化、MoE 与上下文窗口的权衡选模型是整个调优链条里最关键的一环。选大了内存不够选小了能力不足。我按照 32GB 内存画了一个适用范围7B-8B 量化模型4-6GB日常对话、代码补全、RAG 文档问答速度最快。14B 量化模型8-10GB质量更好适合角色扮演、内容生成但响应略慢。24B-32B 量化模型15-20GB接近商用模型水平内存足够速度能接受。MoE 模型如 Mixtral 8x7B 量化约 26GB能力上限高但内存占用极满速度会受到影响需要谨慎评估。说到 MoE你需要知道一件事MoE 模型不能只看“激活参数量”内存规划还是要按完整参数走。很多人一看 Mixtral 8x7B 号称推理只激活 13B 参数就以为 16GB 内存能跑结果模型加载直接 OOM。实际上Ollama 会把模型负责的部分全部加载进内存MoE 的总参数不会因为路由机制而减少。所以在 32GB Mac mini 上我建议优先权衡 MoE 模型的可用内存剩余量如果剩余太少导致 swap反而比跑一个稍小一点的稠密模型更慢。上下文窗口Context Window也是一个关键参数。Ollama 默认的num_ctx是 4096也就是模型最多只能记住 4096 个 token 的上下文。做 RAG 时需要设置到 8192 甚至 16384。上下文窗口越大KV Cache 占用的内存也越多而且随着 token 数增长呈线性膨胀。所以别盲目开大要按实际需求来。一个实用的做法是先跑默认 4096看速度。如果 RAG 匹配片段偏多再逐步升到 8192、16384观察内存和速度变化找到自己的临界点。我自己的习惯是 7B 模型开到 819214B 模型保持 4096 到 8192 之间MoE 模型只开 4096避免内存爆掉。4.4 调优参数那些值得手调的配置项Ollama 在交互模式下可以用/set命令临时调整参数也可以写在 Modelfile 里固化下来。我最常用的几个参数num_ctx上下文长度影响 KV Cache 内存和首 token 延迟。num_gpu在 llama.cpp 里指 GPU 层数Ollama 中通常自动判断但你可以通过环境变量或 API 指定。temperature生成随机性默认 0.8做代码或文档问答时我会调低到 0.2-0.4。top_p核采样默认 0.9控制候选词范围。repeat_penalty重复惩罚默认 1.1对长文本生成重要过大会让输出变得机械。以 llama.cpp 为例手动指定 GPU 层数和线程llama-cli -m 模型.gguf -ngl 99 -t 8 -c 8192 -p 你好-ngl 99表示尽量把所有层都放到 GPU 上。如果内存吃紧或者模型太大可以逐层减少比如-ngl 60让部分层留在 CPU 上。-t 8是 CPU 线程数其实在 Metal 加速为主时影响有限但可以分摊部分算子。还一个容易被忽略的参数是--flash-attn。llama.cpp 支持 Flash Attention能大幅减少长上下文的内存占用并提升速度。开启方式llama-cli -m 模型.gguf -ngl 99 -c 16384 --flash-attn -p 你好实测在 macOS 上Flash Attention 对长上下文的显存占用优化非常明显尤其是在做知识库问答时把上下文从 4096 加到 16384内存增量比我预想的小很多。Ollama 如果要持久化设置可以在 Modelfile 里写FROM qwen2.5:7b-instruct-q4_K_M PARAMETER num_ctx 8192 PARAMETER temperature 0.3 PARAMETER top_p 0.9 PARAMETER repeat_penalty 1.1然后用ollama create mymodel -f Modelfile创建自定义模型。这样每次调用都是同样的参数不用在 API 里反复传。5. 实测数据与调优过程记录理论讲完了给点真实数据。下面这些数据是我在 32GB M4 Mac mini 上的实测采用的工具是 Ollama 和 llama.cpp 的 Metal 后端。数据会受系统负载、模型版本、上下文长度影响但作为参考足够。5.1 基准体验不同模型的 token/s 表现模型量化内存占用上下文实测速度体感Llama 3.1 8B InstructQ4_K_M~5GB409622-28 token/s流畅Qwen 2.5 7B InstructQ4_K_M~4.5GB819224-30 token/s流畅Mistral 7B InstructQ4_K_M~4.3GB819225-31 token/s流畅Qwen 2.5 14B InstructQ4_K_M~9GB819214-18 token/s尚可Mixtral 8x7B InstructQ4_K_M~26GB40968-12 token/s偏慢速度只是第一印象真正影响体验的是“首 token 延迟”。很多新手只盯着生成速度结果实际使用发现问一个问题要好几十秒才吐出第一个字。原因往往是上下文太长模型要先把历史输入全部走一遍预填充prefill这个过程很吃计算资源。预填充阶段和生成阶段是两种完全不同的负载。预填充阶段要把整个用户问句以及检索出来的文档一次性跑完算力需求高生成阶段则是逐 token 递归生成带宽瓶颈明显。如果上下文里有几千 token 的 RAG 片段首 token 延迟会非常明显。优化方向是尽可能精简检索结果、控制上下文长度。碎片化的文档不如精选的几段这点我在做知识库时深有体会。5.2 实测在 32GB 内存上跑 MoE 的调优记录我把 Mixtral 8x7B Q4_K_M 放到 Mac mini 上跑过程并不顺利刚启动时内存占用直接飙到 26GB系统开始明显变卡。我做的第一件事是切到 llama.cpp 并设置-ngl 100让所有层都走 GPU。结果速度还是只有 8-12 token/s比 7B 模型慢了接近一半。究其原因Mixtral 虽然激活参数只有约 13B但完整权重依然有 26GB每生成一个 token 都要扫一遍这 26GB都挤在 120GB/s 带宽上速度上不去。为了保住可用性我把num_ctx从 8192 压回 4096关闭不需要的日志并用powermetrics监控内存压力。再跑一遍内存占用降到 24GB 左右速度略微提升到 10-13 token/s。但要提醒的是系统有时候仍会开始用 swap一旦发生整个体验会断崖式下跌。后来我发现一个比较实用的技巧关掉 Mac 上无关的 App把内存压力降下去。如果开了 Chrome 一堆标签页32GB 立刻少 6-8GB。跑大模型前我都会把环境清理干净。这个方法听起来很土但反而比任何软件调优都有效。如果你觉得某次推理特别慢先看看内存压力是不是黄色的这是 macOS 的监控指标。5.3 长上下文与 RAG 场景实测内存增长究竟有多快我在公司内部做了一个简易 RAG 知识库用的是 Qwen 2.5 7B 量化版向量库用的轻量方案。先把 2000 字文档切片、向量化然后让模型根据检索结果回答。调优前我把num_ctx设成 16384结果是内存占用比 4096 时多了大约 2.5GB而且首 token 延迟显著上升。后来我反思问题不在模型而是塞进去太多无关片段。把检索的 top-k 从 8 降到 3保证上下文在 3000 token 以内首 token 延迟压缩了一半还多输出质量也没明显下降。所以对 RAG 场景真正的大头不是模型本身而是你给模型塞了多少上下文。上下文越长KV Cache 越大预填充时间越长内存占用越高。记住一个原则上下文容量是拿来用的不是拿来浪费的。如果你是做文档问答检索后再做一次相关性排序比盲目把片段堆给模型更高效。这个优化思路在低内存设备上尤其重要因为它能同时改善延迟、内存和输出质量三项指标。6. 常见问题与排查技巧实录本地跑大模型哪有不出问题的。我把过去大半年遇到的典型问题整理成一张速查表并补充了排查思路和解决方法希望对大家有用。6.1 内存不足、系统卡顿、频繁 swap这是 16GB 和 24GB 设备最容易遇到的问题32GB 有时也会碰上。现象是模型刚加载完系统就进入“幻灯片”模式打开应用都要转圈。排查方法很简单在“活动监视器”里看内存压力和 swap used如果内存压力曲线变黄/变红说明内存不够。如果 swap used 持续大于几个 GB说明系统正在疯狂写虚拟内存。解决方案按优先级排列降低模型档位比如从 14B 降到 8B。降低num_ctx减少 KV Cache 占用。开--flash-attn优化长上下文内存。关闭无关应用清出可用内存。用外置 SSD 扩充模型存储但注意这不解决内存压力。我建议至少保留 2-4GB 的可用内存余量避免系统频繁 swap。如果跑大模型是你的常态内存容量真的比 CPU 核心数更重要别省这笔钱。6.2 GPU 利用率上不去速度反而慢有些朋友看到 Ollama 日志显示自己在用 Metal但 GPU 利用率只有 30% 左右速度也没想象中快。这种现象在小模型上尤其明显原因通常是模型太小权重搬运时间占比高GPU 核心大部分时间在等数据再加上上下文预填充阶段的计算量不大GPU 利用率自然不高。另一种可能是模型层数分配不合理。llama.cpp 里可以通过-ngl指定 GPU 层数如果默认值过低很多层会被放到 CPU 上跑速度自然拉胯。我建议直接用-ngl 999把所有层丢给 GPU观察速度变化。如果内存不够再调低比如-ngl 60。还有一种情况是 macOS 的节能策略介入。笔记本会限制 GPU 频率M系列 Mac mini 好一些但长时间满载也会降频。如果发现刚启动时高速过一会儿稳定变慢可以检查 CPU/GPU 温度。把机器放在通风良好的位置或者用工具主动控制风扇都能减少降频的影响。6.3 模型加载慢、输出质量差、上下文截断模型加载慢是正常现象因为要把几个 GB 的权重从 SSD 读进内存。Ollama 有个keep_alive参数设定模型在内存中驻留的时间避免频繁卸载和重新加载。API 调用时可以设置ollama run model --keepalive 30m或者用环境变量全局配置。这样在连续对话时第二次请求会比第一次快很多。输出质量差要先排查上下文截断。当你设置的num_ctx小于用户输入和历史的实际长度时模型看不到完整输入回答自然乱七八糟。这种情况可以把上下文调大但也别无限调大否则内存和首 token 延迟都会崩。另外temperature 过高也会导致答非所问做严肃任务时调低到 0.1-0.3 更稳。还有个小技巧遇到输出重复时不要只调 repeat_penalty先看看是不是模型已经陷入死循环。有些情况下调低 top_p 到 0.8 左右会立竿见影。如果问题依旧换一个指令模板更合适的模型可能是正解。6.4 关于“为什么不用 NVIDIA”的几句实话每次聊 Mac 跑大模型都会有人跳出来说你有一张 4090速度秒杀 Mac。这话在大模型推理上确实有一定道理但需要澄清的是4090 有 24GB 显存价格却在 1.2 万以上而且你要给它配一套高功率电源和散热。相比之下32GB 的 Mac mini 整体成本更低、功耗更低还能兼顾日常办公。它赢的不是极致速度而是“均衡”。N 卡的优势在生态二字CUDA 架构养活了无数优化库FlashAttention、vLLM、TensorRT 都是 N 卡玩家先享受。如果你的目标是把本地大模型做成高并发服务N 卡是目前唯一靠谱的选择。但如果你只是自己用、写写代码、做做知识库问答Mac mini 不但能完成还能让你省下精力去调优模型而不是折腾驱动。我个人的结论是追求极致同显存性能选 NVIDIA追求综合体验和高内存性价比选 Apple Silicon。两者各有各的适用场景没必要非得分出高下。真要说遗憾就是 Apple 的 GPU 没有像 CUDA 那样的统一底层生态很多新特性都要等 llama.cpp 社区适配这算 Mac 路线最大的不确定因素。最后再分享一个小技巧说了这么多最后给想入手的人一个最实用的建议先别急着买顶配也不要一上来就下载 70B 模型。先用你现在的电脑跑一个 7B 量化模型体验一下 Ollama 的部署流程再用 14B 试试对比找到“速度 vs 质量”的临界点。然后你才会真正理解自己需要多大内存、多少带宽而不是被参数表牵着走。我自己跑了大半年本地大模型最大的体会是硬件永远在变架构也在变但“内存容量决定能不能跑内存带宽决定跑多快计算单元决定能跑多大”这条规律短期内不会变。与其纠结某个型号的跑分不如想清楚你要跑什么模型、跑多久、跑多少并发。只要这三件事想明白了哪怕配置不是顶格也能把体验调到一个够用的水平。