我最近被人问得最多的一个问题不是“哪个大模型最强”而是“我这台电脑到底能跑多大模型”。尤其当大家开始把 Ollama 装进 Mac mini、迷你主机甚至两年前的笔记本之后显存焦虑突然就上来了32GB 内存的 Mac mini能跑 70B 级别的模型吗CPU 和 GPU 到底谁在干活网上都在说 MoE 架构它是不是非得把所有参数都塞进显存这篇文章不堆跑分数据也不列炫技参数就纯粹从硬件资源的角度把本地大模型的几条核心逻辑拆开讲清楚顺便把我自己在 32GB Mac mini 上的调优过程完整复现一遍。1. 跑本地大模型之前先把“资源焦虑”算清楚很多人一听“70B 模型”就觉得没戏其实这里面的误会非常大。70B 指的是参数量也就是模型里有多少个计算单元但它不等于你必须要准备 70GB 显存。第一个需要搞清楚的概念是模型在推理时占用的内存主要由“权重文件体积 KV Cache 推理框架开销”三部分组成而权重文件体积取决于“参数量 × 每个参数占用的字节数”。1.1 量化模型能塞进内存的头号功臣现在绝大多数本地部署跑的都是量化版模型。拿 70B 模型来说精度每参数字节数70B 权重体积感受FP16半精度2 字节约 140GB消费级完全没戏INT81 字节约 70GB服务器级别才压得进去INT4 / 4-bit 量化0.5 字节左右约 35GB高配个人电脑可以尝试这就是量化存在的原因。默认 Ollama 拉下来的模型通常是 Q4_K_M属于 4-bit 量化精度损失在可接受范围内换来的是体积直接砍掉四分之三。35GB 的权重体积听起来还是很大但注意这是 70B 级别的模型。如果你跑的是 7B、8B 模型Q4 量化后只有 4~5GB一台 16GB 内存的轻薄本都能轻松运行。所以先说结论能不能跑先看量化后权重体积能不能放得进内存而不是先看“多少 B”这个听起来吓人的数字。1.2 三分法权重、KV Cache、框架开销各占多少很多用户只盯着权重体积结果一跑起来发现内存爆了问题多半出在 KV Cache 上。KV Cache 是模型在生成过程中缓存的历史上下文计算结果的临时数据它的大小由“上下文长度 × 层数 × 注意力头数 × 精度”决定。一个大概的估算方式在 4-bit 量化下7B 模型的权重约 4.5GB但如果你把上下文长度拉到 32KKV Cache 可能会额外吃掉 4~6GB 内存。这就是为什么同一台机器跑同一个模型有人觉得流畅有人卡死——很可能只是上下文长度设置不同。我自己的经验算法是实际内存占用 ≈ 权重体积 × 1.2 上下文长度对应的 Cache 开销而且永远要给自己留出 20% 的余量因为操作系统和推理框架本身也需要内存。比如 32GB 的统一内存实际安全可用的大模型字节容量我会控制在 22GB 左右剩下的留给 macOS 系统、其他应用以及临时峰值。2. MoE 不是魔法但它的内存逻辑和你想得不一样MoEMixture of Experts混合专家是现在很多大模型选择的结构DeepSeek-V2、Qwen1.5-MoE、Miramba 之类的模型都用这种架构。市面上的讨论经常把它神化了好像用了 MoE 就能让一个超大模型在你的小内存电脑上健步如飞。真相是什么我来拆一下。2.1 “总参数”和“激活参数”是完全不同的两个概念MoE 模型把整个网络分成了若干个“专家”Expert模块每个 token一句话被切分的片段进来后通过一个路由网络Router选择其中一小部分专家干活而不是让所有参数都参与计算。这里产生了两个关键参数总参数模型文件里实际包含的所有权重决定了磁盘和内存占用。激活参数每次处理一个 token 时真正参与计算的参数决定了计算速度和延迟。举几个典型例子模型总参数激活参数说明Mixtral 8x7B约 46.7B约 12.9B8 个专家里选 2 个Qwen1.5-MoE-A2.7B约 14.3B约 2.7B极致的参数效率DeepSeek-V2约 236B约 21B服务端大模型典型代表2.2 所有权重要全部加载但计算只挑一部分这里必须泼一盆冷水MoE 模型推理时权重仍然需要完整加载到内存/显存里。不能像某些人想象的那样“只把被激活的专家加载进来其他专家留在硬盘上随用随取”。原因有两点第一路由网络选择专家是在推理过程中动态发生的不同 token 可能会激活不同的专家组合。如果每次都要从硬盘加载权重延迟会大到完全不可用——内存带宽不是用来做这种事儿的。第二虽然只有一部分专家在“算”但模型的那层共享参数、Attention 部分的权重、以及路由判断本身都需要常驻内存。那 MoE 的优势到底在哪里在于当参数总量上升时MoE 可以只增加一小部分计算开销。一个 70B 的 Dense 模型每次推理要算全部 70B 参数一个总参数 100B 的 MoE 模型如果激活参数只有 20B那它的单次推理计算量还不到前者的一半。所以你才会看到消费级硬件上大家更愿意尝试 MoE 模型——同样的内存占用上限里总参数可以更大模型的“知识面”更广而算起来又不至于慢到不可用。这里给我的实战启发是选模型时不要只看总参数更要看激活参数和显存/内存需求。如果你的内存有限优先选激活参数更小的 MoE 模型而不是参数更大的 Dense 模型。反直觉的地方在于“模型更大”和“你需要的内存更大”这两件事在 MoE 身上并不是严格绑定的。3. CPU、GPU、NPU 在同一台机器上会怎么配合另一个常见的困惑是本地部署时到底是谁在干活我在群里看过很多人贴出“我在纯 CPU 上跑大模型”的截图也有人想尽办法让 Mac 上的 NPU 参与。这里头有三个不同的算力角色分管不同的事情搞清楚了就不会被各种玄学说法带着走。3.1 三种算力的长板和短板计算单元长板短板在大模型推理里主要干什么CPU内存容量大逻辑调度灵活矩阵运算效率低数据调度、算子支持、小规模模型推理GPU大规模并行矩阵运算效率最高显存容量受限Attention、前馈网络这类核心矩阵计算NPU能耗比极高特定算子效率高通用性差生态适配慢特定算子的硬件加速目前还不能完全接管 LLM 推理这里要特别说明一下 Apple Silicon 的情况。M 系列芯片用的是统一内存架构CPU、GPU、NPU 共享同一块内存这既是优势也是劣势优势在于 GPU 可以访问全部 32GB不像传统显卡那样被板载显存限制死劣势在于这个“全部内存”也同时服务于系统和其他应用不能像独显那样把一整块显存独占了。我的实测感受是在 Mac mini 上跑 Ollama默认情况下大部分矩阵运算会交给 GPUCPU 负责一些并行度不高的算子NPU 暂时只起辅助作用。别指望 NPU 能扭转乾坤——目前的推理框架对 Apple NPUANE的利用还停留在特定算子路线不如 CUDA 那样成熟真正决定体验的是内存带宽和模型量化质量。3.2 内存带宽才是 Apple Silicon 推理的真正瓶颈这个点很关键。大模型推理本质上是一个“饿死”计算单元的过程——它在不停地从内存里读权重数据喂给计算单元。所以内存带宽越大token 生成越快。对比一下设备内存带宽8B Q4 模型理论生成速度参考入门级笔记本内存50~80GB/s10~20 token/sM 系列基础款100~200GB/s20~40 token/sM 系列 Pro/Max200~400GB/s40~80 token/s高端独显600~1000GB/s80~150 token/s这就是为什么同样跑 8B 模型有人觉得“秒出”有人觉得“转圈半天”——说到底是在吃内存带宽的红利。如果你想买设备跑本地模型先看内存带宽再谈显存大小顺序别反了。4. 32GB Mac mini 的调优路线从能跑到跑得舒服我是 32GB 内存 Mac mini 的长期用户。坦白说这个配置处在“能跑很多模型但需要动脑子优化”的甜蜜区间。我的完整调优路径如下每一步都踩过坑直接给你们可复现的操作。4.1 基础环境Ollama 和模型怎么选我选 Ollama 做部署工具理由很简单安装简单、命令行干净、模型管理方便。安装命令也没几步# 安装 Ollama curl -fsSL https://ollama.com/install.sh | sh # 查看本地已拉取的模型 ollama list # 拉取一个 8B 模型 ollama pull qwen3:8b # 拉取一个 MoE 模型 ollama pull qwen3:30b-a3b选模型时我给自己定了一条线权重体积不要超过 20GB给系统留约 10GB给 KV Cache 留约 2GB 以上这样 32GB 内存才安全。按这条线8B/14B 的 Q4 量化模型随便跑30B 级别的 MoE 模型激活参数约 3B也能跑得很稳。4.2 几个真正影响体验的调优参数ollama 默认跑起来没问题但想跑得舒服一定要自己动手调几个参数第一是量化级别。默认 Q4_K_M 是精度和体积的平衡点。如果你内存有富余可以试试 Q8_0清晰度有可感知的提升如果内存紧张老老实实 Q4_K_M别硬上高精度。第二是上下文长度。这是最容易忽略的大坑。直接用命令行设置# 设置上下文长度为 8192明显增加内存占用 OLLAMA_CONTEXT_LENGTH8192 ollama run qwen3:8b # 如果只做日常问答4096 就够用 OLLAMA_CONTEXT_LENGTH4096 ollama run qwen3:8b实测下来8B Q4 模型在 32GB 内存上上下文从 4096 拉到 32K内存占用会从大约 5GB 飙到 12GB 以上。如果没有长文档需求别盲目追求大上下文。第三是并发参数。个人使用通常不需要并发但如果你在电脑上跑一个团队共享的模型服务# 允许同时处理 4 个请求适合小团队内部使用 OLLAMA_NUM_PARALLEL4 OLLAMA_MAX_LOADED_MODELS1 ollama serve并发上去了每个请求的速度会有所下降但整体吞吐高了很多。给团队用的时候这个参数要反复测试找到“单请求可接受延迟”和“总吞吐量”的平衡点。第四是保持模型常驻。模型从冷启动加载到内存大概需要十几秒甚至更久如果因为内存压力被系统卸载了下个请求又要重来。用 keep_alive 参数让模型在内存里待命# 保持模型加载 30 分钟 ollama run qwen3:8b --keepalive 30m调完这四个参数后我的 32GB Mac mini 跑 8B 模型能达到体感“接近即时响应”跑 30B 级 MoE 模型稳定在 20~30 token/s 左右日常问答完全够用。4.3 我踩过的两个坑提前给你们排掉第一个坑外接硬盘跑模型的温度灾难。我一开始图省事把 Ollama 的模型目录软链到外接 SSD 上结果推理速度直接垮掉一大截。原因很简单外接磁盘的 IO 延迟和带宽比内置 SSD 差而且长时间满负载读写会让硬盘发热掉速。Mac mini 的内置 SSD 足够快不用为了省内置空间把模型放到外接盘上尤其是那种不带供电的小型便携盘。第二个坑把 RTX 4090 的预期带到了 Mac 上。我有几年用 N 卡跑 CUDA 的习惯刚开始用 Mac 跑模型时总觉得“显卡不行”。后来才意识到Mac mini 的优势不在于峰值算力而在于统一内存能装下更大的模型。调优的思路应该是在 32GB 总内存这个框里选择内存占用可接受的模型然后充分吃满内存带宽——而不是一味追求高算力换来的高 token/s。5. 从个人到 200 人团队预算和硬件的分水岭很多人在搜这个问题搭建一个 200 人用的本地大模型到底要多少钱这个问题必须从“并发”两个字来拆解。5.1 人数不是关键同时在线请求量才是200 人的团队如果只是“200 个账号都能访问”那本质和 20 个人的团队没有区别因为真实场景下同时发起请求的可能只有几个到十几个。但如果要求 200 人同时流畅提问那就完全是另一个量级了。在做预算前先回答三个问题高峰期预计同时有多少个请求每个请求期望多快拿到结果模型规模和上下文要求是什么假设 200 人的团队高峰期同时在线约 30~50 人真实并发请求大约 5~10 个。这个量级一台高性能单机其实就能扛下来。5.2 三层方案和大致成本范围方案等级硬件配置适合规模参考预算范围入门单机64GB 内存的 Mac mini / 迷你工作站内部工具5~10 人并发1~2 万元进阶单机128GB 内存 Mac Studio 或双卡工作站20~30 人日常并发3~5 万元服务器级2~4 张 A6000/A100 或 4090 节点集群企业级大规模使用10 万元以上注意这里报的是硬件成本不含人力、机房和运维。用小团队起步的话我建议从“进阶单机”开始因为 128GB 统一内存能让你直接跑 70B 级别量化模型同时保持 20 人左右的稳定并发这对绝大多数内部提效场景都是足够的。如果团队只是做文档问答这类轻量任务甚至 64GB 内存的单机方案就能跑得不错。核心逻辑是一条曲线个人用买的是一张舒适的椅子团队用买的是一张能坐很多人的长桌。个人 32GB 就能玩得很开心团队从零到一选择“单机大内存”往往比“多机小显存”更省心。6. 调优的本质先跑起来再花钱回到标题那句话——本地大模型硬件真相。说白了硬件只是门槛不是天花板。我对这个领域最深的体会是太多人把时间花在“纠结配置够不够”上而不是“跑通一个”上。以 32GB Mac mini 为参考哪怕你的设备内存更小也可以从不大于 7B 的量化模型开始调低上下文长度先把流程跑通观察内存占用曲线再逐步尝试更大规模的模型。如果你能忍受 CPU 推理的慢速甚至 16GB 内存的老笔记本也能作为入门环境。关键是理解三件事内存决定你能跑什么模型带宽决定跑得多快算力决定模型输出多流畅。MoE 不等于“省内存”它是“总参数换知识广度激活参数换推理速度”的一种交易。没有通用的最佳配置只有最适合你场景的配置。另外有一个我实操中养成的小习惯每次换模型或调参之前先在命令行清空当前统计跑同一个 prompt 三次记录 token/s 和内存峰值再对比调整后的数据。这样每次改动是“有效优化”还是“自我感动”一测便知。别凭感觉调数据虽然枯燥但它不会骗你。