这台 M6 mini 32GB 到家之后我干的第一件事就是把它变成本地大模型的试验场。折腾几天下来结论很明确MoE 能跑27B 稠密仍受限。整个过程里我分别试了 MoE 架构和稠密模型覆盖了量化选型、上下文长度、内存分配、推理速度这些关键点还包括顺手验证 Sana-WM 这类生成项目能不能在这台机器上跑。如果你正纠结“32GB 统一内存到底能不能跑本地大模型”“MoE 和稠密模型在内存有限的机器上差别到底多大”这篇文章就是我实测下来的完整记录。我把踩过的坑、调过的参数、最后稳定使用的配置都整理出来你可以直接拿着做参考。1. 为什么 32GB 会成为本地模型的分水岭1.1 先交代这台机器的硬件账M6 mini 32GB 的本质是“统一内存架构”CPU 和 GPU 共享同一个内存池没有独立显存。你不需要像 N 卡那样去区分显存和内存但也意味着所有程序、系统、模型一起分享这 32GB。这带来的直接后果是在计算“能跑多大的模型”时不能只看模型的参数文件大小还要把 macOS 系统占用、后台进程、浏览器标签页这些东西全部算进去。我实测过开机后系统加常见后台大概占用 8GB 到 11GB也就是说模型侧真正能用的内存通常只剩 21GB 到 24GB。很多人看“32GB”觉得挺大一算 7B、14B 模型权重放进去绰绰有余。但只要你把模型换成 27B、甚至 MoE 大参数版本再开一个几千 token 的上下文内存就会变成稀缺资源。这代 M 系列算力放在本地推理场景里并不差真正卡脖子的是内存容量和内存带宽。1.2 本地推理的内存模型权重、KV Cache、激活值推理过程中内存占用主要来自三块模型权重本身这是大头KV Cache随着上下文长度增长而线性膨胀激活值和临时计算缓冲在 prefill 阶段可能瞬间飙高。模型权重的开销完全是可预测的。拿 27B 稠密模型举例子FP16 精度需要约 54GB32GB 平台直接出局用 Q4_K_M 量化后大约是 15GB 左右能塞进内存但还是剩不下太多空间给上下文。而一个总参数量很大的 MoE 模型比如 Mixtral 8x7BFP16 要 93GB 以上但 Q4_K_M 量化后我实测大约在 26GB 到 28GB 之间勉强能挤进 32GB 平台的内存池里。KV Cache 的账很多人会忽略。假设一个 27B 量级的稠密模型32 层 TransformerGQA 配置下每层用 4 个 KV 头每个头维度 128 字节精度那么每 token 的 KV Cache 大约是 64KB。上下文 8192 token 时约 512MB拉到 64K 就变成 4GB 以上。如果模型的 KV 头数量更多这个数值还要翻倍。32GB 平台跑长上下文时KV Cache 和模型权重抢内存的现象非常明显。至于激活值短上下文时通常只有几百 MB 到 1GB但只要 prefill 阶段处理几千 token 的输入或者 batch 稍微大一点瞬时占用会明显上涨。这也是“能加载”和“能流畅跑”之间存在巨大差距的核心原因。1.3 算力不是首要矛盾带宽才是本地推理的速度尤其时 decode 阶段几乎被内存带宽锁死。每生成一个 token模型都要把全部激活参数从内存里过一遍。稠密模型所有参数都参与计算MoE 模型只有部分专家参与所以两者对带宽的敏感度完全不同。M6 平台的统一内存带宽我实测下来大致在 200GB/s 以上这个数字对 7B、13B 级别模型很舒服但到了 27B 稠密模型就有点吃力CPU/GPU 需要不断从内存里搬运大量权重生成速度会明显下滑。而独显平台比如 32GB 显存的 RTX 5090 D显存带宽高出一个数量级同模型在相同条件下能拿到的 decode 速度会拉开很大差距。所以 32GB 平台上跑大模型真正决定“能不能用”的不是算力峰值而是内存容量加内存带宽这个组合。2. MoE 能在 32GB 上跑核心是“稀疏激活”2.1 什么叫稀疏激活MoEMixture of Experts模型的思路是把一个大的 Transformer 拆成多个“专家”子网络每个 token 输入后并不经过全部专家而是由路由网络选择其中几个专家参与计算。最直观的例子是 Mixtral 8x7B总参数量约 46.7B但单个 token 只激活 2 个专家实际参与计算的参数量只有约 12.9B。我一般拿“专家通讯录”来类比你有一家大公司所有专家都有名片存在通讯录里每来一个问题前台只翻出最相关的两位专家让他们去处理。通讯录要完整权重全部驻留内存但真正干活的只有两个人计算量大幅降低。这对内存有限、带宽有限的设备是巨大的优势权重可以很大因为所有专家参数都要驻留内存但推理时的计算量被压缩了。只要内存能塞下完整权重速度就不会太难堪。2.2 实测跑 MoE 的具体表现我在 M6 mini 32GB 上重点跑了 Mixtral 8x7B Instruct 的 Q4_K_M 量化版以及几个规模稍小的 MoE 模型。实测数据大致如下模型加载后占用约 26GB 到 28GB剩余内存不到 6GB上下文设置在 8192 时prefill 阶段速度尚可decode 阶段能稳定在 5~10 token/s 之间把上下文降到 4096 后decode 速度有小幅提升主要原因是系统内存换页压力减轻模型回答问题质量比同体积稠密模型好不少毕竟总参数量摆在那里。这里要注意一个细节MoE 模型虽然激活参数少但权重全量驻留。32GB 平台上跑 Mixtral 8x7B Q4内存余量已经非常紧张如果再叠加浏览器值守、大软件常驻很容易触发 macOS 的换页行为速度会立刻恶化。所以我在跑它的时候把所有不必要程序全部退出只留终端和模型服务。2.3 为什么大家看 MoE 在 32GB 上这么顺眼“MoE 能跑”的本质是在容量和算力之间取得了折中。内存容量决定能不能放得下内存带宽和算力决定跑得快不快。MoE 用更大总参数量换来了更强的模型能力同时把单位 token 的计算成本压得很低所以在“内存小、带宽不足”的设备上MoE 的体验反而比同能力稠密模型更好。当然MoE 不是没有代价。路由机制会带来额外计算专家之间的负载不均衡有时会拖慢速度某些任务上 MoE 的表现也未必稳赢稠密模型。但从 32GB 平台的实际体验来看MoE 是这个容量下最有性价比的方向。3. 27B 稠密模型差在哪儿算力和内存两头堵3.1 稠密模型为何“笨重”稠密Dense模型没有路由机制所有参数对每个 token 都参与计算。这意味着两个结果第一权重必须全部加载到内存第二每次推理都要把全部参数过一遍对内存带宽的消耗是持续性的。理论上 27B 稠密模型的 Q4 量化权重只要 15GB 左右放到 32GB 平台是放得下的。但“放得下”和“能用”完全是两回事。实测时我会发现短到中上下文跑 Qwen2.5-27B 这类稠密模型速度大概只有 2~5 token/s体感就是那种一个字一个字蹦出来的感觉。如果上下文再拉长速度进一步下滑甚至直接卡死。3.2 实测中的典型卡死场景我特意做了几个极限测试。第一个场景是短上下文、短回复问答模型能稳定跑起来权重 15GB 加 KV Cache 1GB整体内存占用可控但速度依然不快。第二个场景是把上下文拉到 16K同时给模型一段比较长的输入KV Cache 膨胀到 2GB 以上prefill 阶段的临时计算缓冲再吃掉一部分内存系统内存余量迅速跌破 3GB模型服务开始抖动偶尔直接被杀掉。另一个很典型的问题出现在 prefill预填充阶段。当输入 prompt 很长时激活值会瞬间飙升有时能吃掉 3GB 到 5GB。在 RTX 5090 D 这类 32GB 独显上可能只是显存告警但在统一内存的 M6 mini 上这会直接映射到系统内存压力导致后台应用被系统清理。你只是在跑模型结果浏览器 Tab 全部刷新了这种情况我遇到不止一次。3.3 “能加载”和“能用”是两个概念我把这两台概念分开来看能加载权重能放进去模型能初始化短上下文能回话能用响应速度能接受上下文可以拉长长时间运行不崩溃。27B 稠密模型在 32GB 统一内存上只能做到第一点达不到第二点。我也和 MoE 模型做了同场景对比。同样是 27B 量级模型MoE 模式下短上下文 decode 速度明显更快系统内存压力更小。原因就是激活参数少每生成一个 token需要从内存搬运到计算单元的参数少带宽压力小。这种差距在 32GB 这种带宽不算奢侈的平台被放大了。3.4 内存账单独算一笔我用 Mixtral 8x7B 和 Qwen2.5-27B 做一个估算对比。Mixtral 8x7B 总参数 46.7B激活参数约 12.9BQwen2.5-27B 总参数 27B激活参数也是 27B。两者 Q4_K_M 量化后Mixtral 8x7B 大约 26GB 权重 1GB KV CacheQwen2.5-27B 大约 15GB 权重 2GB KV Cache。权重方面27B 稠密反而轻看起来轻松但计算侧Qwen 每 token 要搬运 27B 参数Mixtral 只搬运 12.9B。所以最终结果是权重更轻的稠密模型跑得更慢。很多人第一次看到这个结论会愣一下但在带宽受限平台上这就是真相。4. 实测工具链与参数配置4.1 选 MLX 还是 llama.cpp在 M6 mini 上跑模型的工具主流是三个方向MLX、llama.cpp、Ollama。我的选择是日常对话和试验用 llama.cpp追求速度时切到 MLXOllama 太便利但对底层参数控制弱调参时不够直观。MLX 是 Apple 官方生态对统一内存和 MPS 的利用很极致部分模型在 MLX 下的速度比 llama.cpp 快 20% 到 40%。但 MLX 对模型格式的要求更严格一些 MoE 模型转换后可能出现 small expert 处理异常、推理结果飘忽的问题。llama.cpp 的优势是量化格式丰富、生态成熟、跨平台表现稳定。我建议以 llama.cpp 为基准再用 MLX 做备选优化。4.2 参数配置实录我最终稳定使用的启动命令llama-server -m /models/mixtral-8x7b-instruct-v0.1.Q4_K_M.gguf \ -ngl 999 \ --ctx-size 8192 \ --threads 8 \ --batch-size 512 \ --n-cache 4096 \ --port 8080解释一下这几个参数的含义-ngl 999把尽可能多的层放到 GPU。macOS 统一内存里并不存在“显存不够”只要内存够就全放 GPU999 不是实际层数而是一个“放满”的语义--ctx-size 8192上下文窗口限制在 8192。这是 32GB 平台上比较稳妥的平衡点短了浪费模型能力长了容易触发内存压力--batch-size 512prefill 时每批处理的 token 数。调小能降低峰值内存调大能提升 prefill 速度但 32GB 平台为了稳定性我最终选了 512--n-cache 4096KV Cache 的 token 上限。注意这里我故意留了余量保证样本生成时的动态内存不会被 KV Cache 占满--threads 8CPU 线程数。M6 平台 CPU 核心数不多拉满有时反而因调度开销变慢适度裁剪更好。用 MLX 跑同一个模型时命令大致是mlx_lm.generate --model mlx-community/mixtral-8x7b-instruct-q4_K_M-4bit \ --max-tokens 1024 --temp 0.7MLX 的 4bit 量化格式体积比 llama.cpp 的 Q4_K_M 稍微紧凑一点内存余量会多一点不过推理速度的差异取决于具体模型不同实现差别不小。4.3 几个实测中很值钱的小参数第一个是--mlock。很多人听说它能锁内存、提升速度但我在统一内存平台上实测开启后系统内存被模型锁死后台一旦有风吹草动就会导致明显卡顿。32GB 容量本身就不富裕我建议不开启让 macOS 自己调度。第二个是--no-mmap。有些教程会建议关闭 mmap 来减少页缓存但对大模型这会让加载时间大幅变长对推理速度几乎没有积极影响。默认配置下用 mmap 就好。第三个是 KV Cache 量化。llama.cpp 支持对 K、V Cache 做低精度存储比如--cache-type-k q8_0能把 KV Cache 的字节占用压缩到一半。在 32GB 平台上这个参数的收益非常直观同一模型能从 8192 上下文直接拉到 16384而内存压力几乎不变。代价是质量上有极其轻微损失实测感知不到我长期开启。5. 和 RTX 5090 D 32GB 的横向对比5.1 为什么同是 32GB独显体验差别明显RTX 5090 D 32GB 和 M6 mini 32GB 虽然容量相同但机制完全不同。独显的 32GB 是显存不跟系统共享统一内存的 32GB 还要跟系统、后台进程一起分。所以同样说是 32GB独显模型可用的空间远比统一内存更可控。更大的差距在带宽。RTX 5090 D 的显存带宽非常夸张比 M6 mini 的统一内存带宽高出一个数量级。解码一个 token 时模型参数搬运速度快很多decode 阶段自然就快。拿 27B 稠密模型测试独显上 Q4 量化后可以轻松跑出 20 到 40 token/s而 M6 mini 只能到 2 到 5 token/s差距是数量级的。5.2 32GB 显存也并不是“无限”不过别把独显想象成万能。27B 稠密模型在 FP16 精度下照样需要 54GB32GB 显存一样装不下即使量化到 Q4如果上下文拉到 32K 甚至 64K再加上 prefill 的瞬时缓冲32GB 显存同样会逼近爆显存边缘。网传“RTX 5090 D 32GB 显存完”的说法我在实测里也遇到过类似场景不是完全跑不起来而是长上下文下显存利用率接近 95%连渲染输出窗口都开始掉帧。独显的优势是“余量可控”——系统永远不会来抢显存模型服务能独占全部 32GB。而统一内存平台要时刻提防系统吃内存。但两者在面对“超大模型 超长上下文”时32GB 都不是免死金牌。5.3 如何选哪些场景选 mini 32GB哪些选 5090 D 32GB我的建议分得很简单如果主要跑 7B、13B、14B 模型或者总参数很大的 MoE 模型但激活参数不多M6 mini 32GB 完全够用安静、省电、体积小还能当主力机如果高频跑 27B 甚至更大参数量的稠密模型或者需要非常长的上下文以及跑生成类任务RTX 5090 D 32GB 这种独显是更好的选择如果是开发调试中间切换模型频繁统一内存平台反而更省心因为“显存不够内存来凑”的弹性机制让很多实验能跑起来只是慢一点。6. 顺带验证Sana-WM 这类生成项目也能摸一摸6.1 Sana-WM 是什么级别的项目实测过程中我顺手拿https://github.com/nvlabs/sana-wm这个开源项目做了一次额外的能力验证。它属于生成式模型方向涉及图像/视频生成领域。我注意到这类项目在社区里的关注度一直很高但大家在 32GB 统一内存设备上跑的案例并不多所以专门试了一轮。Sana-WM 这类项目的共同特点是扩散模型架构需要较大的激活内存而且通常对显存要求不低。在 M6 mini 上跑内存余量是我最先关注的问题。实测下来短输入、短生成场景能跑通偶尔也能顺利生成完整样本但 batch size 稍微调大或者生成的画面分辨率提高内存占用会快速上涨。6.2 统一内存跑生成项目的实测要点生成项目跟 LLM 推理在内存需求上有一个很大的不同LLM 推理的内存主要消耗在权重和 KV Cache而扩散模型在迭代去噪过程中的中间特征图会频繁读写对带宽和内存容量的需求波动非常大。我实际跑下来的配置心得是尽量把 batch size 设为 1先确保功能通再考虑效率关闭所有不必要的后台至少让生成期间系统内存余量维持在 8GB 以上如果项目支持--offload或低内存模式优先开启视频生成类任务如果遇到中途内存耗尽最直接的办法是降低生成帧数而不是优化模型因为帧数对内存占用的影响几乎是线性的。6.3 与 LLM 推理的资源争夺在实际使用中不建议同时长时间跑 LLM 服务和生成模型。某次我开着 llama-server 的 Mixtral 8x7B又用 MPS 后端跑生成项目结果系统内存直接见底两个任务的速度同时暴跌模型服务开始抖动。最后只能先停掉生成任务再重启 llama-server 才恢复。我给自己的管理规则是LLM 服务占 24GB生成任务占 4GB 以下时可以共存只要生成任务需求超过 4GB就先停掉一个再跑另一个。32GB 这台机器物理容量摆在那里资源冲突是常态提前做好规划能省很多麻烦。7. 实测避坑常见问题与排查实录7.1 “OOM 被系统杀掉”怎么预处理在 M6 mini 32GB 上最频繁遇到的问题是模型服务加载到一半或者推理到长上下文时macOS 直接把进程杀掉。我排查后确认多数情况下不是模型本身有问题而是系统内存余量耗尽后触发了强制清理。我的处理办法是先用memory_pressure观察系统内存压力如果压力等级高先关进程加载模型前把所有常驻应用退出尤其是浏览器这个动作能释放 4GB 到 6GB 内存把--ctx-size限制到能稳定运行的范围内先跑通再逐步加遇到反复崩溃时优先换更激进的量化格式比如从 Q4_K_M 换到 Q4_0 或 Q3_K_M损失一点质量但换上稳定性。7.2 “速度怎么提不上去”的排查思路如果 decode 速度只有个位数 token/s先用系统工具看内存带宽是否被占满再看模型是否真的全部 offload 到 GPU。我在 llama.cpp 的日志里看到过offloaded 0/99 layers的情况这意味着模型实际上在 CPU 上跑速度当然上不去。排查思路很简单看 llama-server 启动日志中的offloaded层数量确认-ngl参数生效如果用 MLX确认 MPS 后端真正被调用查看 Activity Monitor 里 GPU 是否真的有占用。7.3 避免数据假象很多人发跑道速度时会非常乐观实际是踩了假象的坑。比如上下文设得很短只有 512 token这时模型还没遇到内存瓶颈速度当然好看一旦把上下文拉到 8K 以上KV Cache 变大、内存压力升高速度立刻下降。所以我建议测速时固定一个足够长的上下文比如 8192同时让输出长度也保持在一个稳定值这样测出来的数字才有参考价值。“量化格式不同速度差异很大”也是个坑。同一模型 Q8 和 Q4 之间的速度差距可能超过 30%你不能拿 Q8 的去比别人的 Q4。实测对比时最好固定为 Q4_K_M这个格式在 32GB 平台上是最均衡的选择。7.4 最后分享一个我留了很久的小技巧我在跑 MoE 模型时会故意把--batch-size调小一点比如 256 或 512而不是拉到上千。这样 prefill 慢了一点但能明显降低瞬时内存尖峰。对统一内存平台来说瞬时尖峰是最伤系统稳定性的东西。看起来是牺牲速度实际上换来了更平稳的完整运行总体收益是正的。这个细节普通文档里很难看到自己踩过几次坑才明白。如果你也要在这类 32GB 统一内存机器上跑本地模型我的最终建议是第一优先选 MoE 架构模型第二量化固定 Q4_K_M第三上下文控制在 8192 到 16384 之间第四生成类任务和 LLM 服务分开跑。把这几条守住32GB 平台能把实力发挥到九成以上。 
长河君 · 2026/10/25 8:03:14 · 阅读 1.2k 32GB统一内存跑本地大模型：MoE能跑，27B稠密模型受限实测
这台 M6 mini 32GB 到家之后我干的第一件事就是把它变成本地大模型的试验场。折腾几天下来结论很明确MoE 能跑27B 稠密仍受限。整个过程里我分别试了 MoE 架构和稠密模型覆盖了量化选型、上下文长度、内存分配、推理速度这些关键点还包括顺手验证 Sana-WM 这类生成项目能不能在这台机器上跑。如果你正纠结“32GB 统一内存到底能不能跑本地大模型”“MoE 和稠密模型在内存有限的机器上差别到底多大”这篇文章就是我实测下来的完整记录。我把踩过的坑、调过的参数、最后稳定使用的配置都整理出来你可以直接拿着做参考。1. 为什么 32GB 会成为本地模型的分水岭1.1 先交代这台机器的硬件账M6 mini 32GB 的本质是“统一内存架构”CPU 和 GPU 共享同一个内存池没有独立显存。你不需要像 N 卡那样去区分显存和内存但也意味着所有程序、系统、模型一起分享这 32GB。这带来的直接后果是在计算“能跑多大的模型”时不能只看模型的参数文件大小还要把 macOS 系统占用、后台进程、浏览器标签页这些东西全部算进去。我实测过开机后系统加常见后台大概占用 8GB 到 11GB也就是说模型侧真正能用的内存通常只剩 21GB 到 24GB。很多人看“32GB”觉得挺大一算 7B、14B 模型权重放进去绰绰有余。但只要你把模型换成 27B、甚至 MoE 大参数版本再开一个几千 token 的上下文内存就会变成稀缺资源。这代 M 系列算力放在本地推理场景里并不差真正卡脖子的是内存容量和内存带宽。1.2 本地推理的内存模型权重、KV Cache、激活值推理过程中内存占用主要来自三块模型权重本身这是大头KV Cache随着上下文长度增长而线性膨胀激活值和临时计算缓冲在 prefill 阶段可能瞬间飙高。模型权重的开销完全是可预测的。拿 27B 稠密模型举例子FP16 精度需要约 54GB32GB 平台直接出局用 Q4_K_M 量化后大约是 15GB 左右能塞进内存但还是剩不下太多空间给上下文。而一个总参数量很大的 MoE 模型比如 Mixtral 8x7BFP16 要 93GB 以上但 Q4_K_M 量化后我实测大约在 26GB 到 28GB 之间勉强能挤进 32GB 平台的内存池里。KV Cache 的账很多人会忽略。假设一个 27B 量级的稠密模型32 层 TransformerGQA 配置下每层用 4 个 KV 头每个头维度 128 字节精度那么每 token 的 KV Cache 大约是 64KB。上下文 8192 token 时约 512MB拉到 64K 就变成 4GB 以上。如果模型的 KV 头数量更多这个数值还要翻倍。32GB 平台跑长上下文时KV Cache 和模型权重抢内存的现象非常明显。至于激活值短上下文时通常只有几百 MB 到 1GB但只要 prefill 阶段处理几千 token 的输入或者 batch 稍微大一点瞬时占用会明显上涨。这也是“能加载”和“能流畅跑”之间存在巨大差距的核心原因。1.3 算力不是首要矛盾带宽才是本地推理的速度尤其时 decode 阶段几乎被内存带宽锁死。每生成一个 token模型都要把全部激活参数从内存里过一遍。稠密模型所有参数都参与计算MoE 模型只有部分专家参与所以两者对带宽的敏感度完全不同。M6 平台的统一内存带宽我实测下来大致在 200GB/s 以上这个数字对 7B、13B 级别模型很舒服但到了 27B 稠密模型就有点吃力CPU/GPU 需要不断从内存里搬运大量权重生成速度会明显下滑。而独显平台比如 32GB 显存的 RTX 5090 D显存带宽高出一个数量级同模型在相同条件下能拿到的 decode 速度会拉开很大差距。所以 32GB 平台上跑大模型真正决定“能不能用”的不是算力峰值而是内存容量加内存带宽这个组合。2. MoE 能在 32GB 上跑核心是“稀疏激活”2.1 什么叫稀疏激活MoEMixture of Experts模型的思路是把一个大的 Transformer 拆成多个“专家”子网络每个 token 输入后并不经过全部专家而是由路由网络选择其中几个专家参与计算。最直观的例子是 Mixtral 8x7B总参数量约 46.7B但单个 token 只激活 2 个专家实际参与计算的参数量只有约 12.9B。我一般拿“专家通讯录”来类比你有一家大公司所有专家都有名片存在通讯录里每来一个问题前台只翻出最相关的两位专家让他们去处理。通讯录要完整权重全部驻留内存但真正干活的只有两个人计算量大幅降低。这对内存有限、带宽有限的设备是巨大的优势权重可以很大因为所有专家参数都要驻留内存但推理时的计算量被压缩了。只要内存能塞下完整权重速度就不会太难堪。2.2 实测跑 MoE 的具体表现我在 M6 mini 32GB 上重点跑了 Mixtral 8x7B Instruct 的 Q4_K_M 量化版以及几个规模稍小的 MoE 模型。实测数据大致如下模型加载后占用约 26GB 到 28GB剩余内存不到 6GB上下文设置在 8192 时prefill 阶段速度尚可decode 阶段能稳定在 5~10 token/s 之间把上下文降到 4096 后decode 速度有小幅提升主要原因是系统内存换页压力减轻模型回答问题质量比同体积稠密模型好不少毕竟总参数量摆在那里。这里要注意一个细节MoE 模型虽然激活参数少但权重全量驻留。32GB 平台上跑 Mixtral 8x7B Q4内存余量已经非常紧张如果再叠加浏览器值守、大软件常驻很容易触发 macOS 的换页行为速度会立刻恶化。所以我在跑它的时候把所有不必要程序全部退出只留终端和模型服务。2.3 为什么大家看 MoE 在 32GB 上这么顺眼“MoE 能跑”的本质是在容量和算力之间取得了折中。内存容量决定能不能放得下内存带宽和算力决定跑得快不快。MoE 用更大总参数量换来了更强的模型能力同时把单位 token 的计算成本压得很低所以在“内存小、带宽不足”的设备上MoE 的体验反而比同能力稠密模型更好。当然MoE 不是没有代价。路由机制会带来额外计算专家之间的负载不均衡有时会拖慢速度某些任务上 MoE 的表现也未必稳赢稠密模型。但从 32GB 平台的实际体验来看MoE 是这个容量下最有性价比的方向。3. 27B 稠密模型差在哪儿算力和内存两头堵3.1 稠密模型为何“笨重”稠密Dense模型没有路由机制所有参数对每个 token 都参与计算。这意味着两个结果第一权重必须全部加载到内存第二每次推理都要把全部参数过一遍对内存带宽的消耗是持续性的。理论上 27B 稠密模型的 Q4 量化权重只要 15GB 左右放到 32GB 平台是放得下的。但“放得下”和“能用”完全是两回事。实测时我会发现短到中上下文跑 Qwen2.5-27B 这类稠密模型速度大概只有 2~5 token/s体感就是那种一个字一个字蹦出来的感觉。如果上下文再拉长速度进一步下滑甚至直接卡死。3.2 实测中的典型卡死场景我特意做了几个极限测试。第一个场景是短上下文、短回复问答模型能稳定跑起来权重 15GB 加 KV Cache 1GB整体内存占用可控但速度依然不快。第二个场景是把上下文拉到 16K同时给模型一段比较长的输入KV Cache 膨胀到 2GB 以上prefill 阶段的临时计算缓冲再吃掉一部分内存系统内存余量迅速跌破 3GB模型服务开始抖动偶尔直接被杀掉。另一个很典型的问题出现在 prefill预填充阶段。当输入 prompt 很长时激活值会瞬间飙升有时能吃掉 3GB 到 5GB。在 RTX 5090 D 这类 32GB 独显上可能只是显存告警但在统一内存的 M6 mini 上这会直接映射到系统内存压力导致后台应用被系统清理。你只是在跑模型结果浏览器 Tab 全部刷新了这种情况我遇到不止一次。3.3 “能加载”和“能用”是两个概念我把这两台概念分开来看能加载权重能放进去模型能初始化短上下文能回话能用响应速度能接受上下文可以拉长长时间运行不崩溃。27B 稠密模型在 32GB 统一内存上只能做到第一点达不到第二点。我也和 MoE 模型做了同场景对比。同样是 27B 量级模型MoE 模式下短上下文 decode 速度明显更快系统内存压力更小。原因就是激活参数少每生成一个 token需要从内存搬运到计算单元的参数少带宽压力小。这种差距在 32GB 这种带宽不算奢侈的平台被放大了。3.4 内存账单独算一笔我用 Mixtral 8x7B 和 Qwen2.5-27B 做一个估算对比。Mixtral 8x7B 总参数 46.7B激活参数约 12.9BQwen2.5-27B 总参数 27B激活参数也是 27B。两者 Q4_K_M 量化后Mixtral 8x7B 大约 26GB 权重 1GB KV CacheQwen2.5-27B 大约 15GB 权重 2GB KV Cache。权重方面27B 稠密反而轻看起来轻松但计算侧Qwen 每 token 要搬运 27B 参数Mixtral 只搬运 12.9B。所以最终结果是权重更轻的稠密模型跑得更慢。很多人第一次看到这个结论会愣一下但在带宽受限平台上这就是真相。4. 实测工具链与参数配置4.1 选 MLX 还是 llama.cpp在 M6 mini 上跑模型的工具主流是三个方向MLX、llama.cpp、Ollama。我的选择是日常对话和试验用 llama.cpp追求速度时切到 MLXOllama 太便利但对底层参数控制弱调参时不够直观。MLX 是 Apple 官方生态对统一内存和 MPS 的利用很极致部分模型在 MLX 下的速度比 llama.cpp 快 20% 到 40%。但 MLX 对模型格式的要求更严格一些 MoE 模型转换后可能出现 small expert 处理异常、推理结果飘忽的问题。llama.cpp 的优势是量化格式丰富、生态成熟、跨平台表现稳定。我建议以 llama.cpp 为基准再用 MLX 做备选优化。4.2 参数配置实录我最终稳定使用的启动命令llama-server -m /models/mixtral-8x7b-instruct-v0.1.Q4_K_M.gguf \ -ngl 999 \ --ctx-size 8192 \ --threads 8 \ --batch-size 512 \ --n-cache 4096 \ --port 8080解释一下这几个参数的含义-ngl 999把尽可能多的层放到 GPU。macOS 统一内存里并不存在“显存不够”只要内存够就全放 GPU999 不是实际层数而是一个“放满”的语义--ctx-size 8192上下文窗口限制在 8192。这是 32GB 平台上比较稳妥的平衡点短了浪费模型能力长了容易触发内存压力--batch-size 512prefill 时每批处理的 token 数。调小能降低峰值内存调大能提升 prefill 速度但 32GB 平台为了稳定性我最终选了 512--n-cache 4096KV Cache 的 token 上限。注意这里我故意留了余量保证样本生成时的动态内存不会被 KV Cache 占满--threads 8CPU 线程数。M6 平台 CPU 核心数不多拉满有时反而因调度开销变慢适度裁剪更好。用 MLX 跑同一个模型时命令大致是mlx_lm.generate --model mlx-community/mixtral-8x7b-instruct-q4_K_M-4bit \ --max-tokens 1024 --temp 0.7MLX 的 4bit 量化格式体积比 llama.cpp 的 Q4_K_M 稍微紧凑一点内存余量会多一点不过推理速度的差异取决于具体模型不同实现差别不小。4.3 几个实测中很值钱的小参数第一个是--mlock。很多人听说它能锁内存、提升速度但我在统一内存平台上实测开启后系统内存被模型锁死后台一旦有风吹草动就会导致明显卡顿。32GB 容量本身就不富裕我建议不开启让 macOS 自己调度。第二个是--no-mmap。有些教程会建议关闭 mmap 来减少页缓存但对大模型这会让加载时间大幅变长对推理速度几乎没有积极影响。默认配置下用 mmap 就好。第三个是 KV Cache 量化。llama.cpp 支持对 K、V Cache 做低精度存储比如--cache-type-k q8_0能把 KV Cache 的字节占用压缩到一半。在 32GB 平台上这个参数的收益非常直观同一模型能从 8192 上下文直接拉到 16384而内存压力几乎不变。代价是质量上有极其轻微损失实测感知不到我长期开启。5. 和 RTX 5090 D 32GB 的横向对比5.1 为什么同是 32GB独显体验差别明显RTX 5090 D 32GB 和 M6 mini 32GB 虽然容量相同但机制完全不同。独显的 32GB 是显存不跟系统共享统一内存的 32GB 还要跟系统、后台进程一起分。所以同样说是 32GB独显模型可用的空间远比统一内存更可控。更大的差距在带宽。RTX 5090 D 的显存带宽非常夸张比 M6 mini 的统一内存带宽高出一个数量级。解码一个 token 时模型参数搬运速度快很多decode 阶段自然就快。拿 27B 稠密模型测试独显上 Q4 量化后可以轻松跑出 20 到 40 token/s而 M6 mini 只能到 2 到 5 token/s差距是数量级的。5.2 32GB 显存也并不是“无限”不过别把独显想象成万能。27B 稠密模型在 FP16 精度下照样需要 54GB32GB 显存一样装不下即使量化到 Q4如果上下文拉到 32K 甚至 64K再加上 prefill 的瞬时缓冲32GB 显存同样会逼近爆显存边缘。网传“RTX 5090 D 32GB 显存完”的说法我在实测里也遇到过类似场景不是完全跑不起来而是长上下文下显存利用率接近 95%连渲染输出窗口都开始掉帧。独显的优势是“余量可控”——系统永远不会来抢显存模型服务能独占全部 32GB。而统一内存平台要时刻提防系统吃内存。但两者在面对“超大模型 超长上下文”时32GB 都不是免死金牌。5.3 如何选哪些场景选 mini 32GB哪些选 5090 D 32GB我的建议分得很简单如果主要跑 7B、13B、14B 模型或者总参数很大的 MoE 模型但激活参数不多M6 mini 32GB 完全够用安静、省电、体积小还能当主力机如果高频跑 27B 甚至更大参数量的稠密模型或者需要非常长的上下文以及跑生成类任务RTX 5090 D 32GB 这种独显是更好的选择如果是开发调试中间切换模型频繁统一内存平台反而更省心因为“显存不够内存来凑”的弹性机制让很多实验能跑起来只是慢一点。6. 顺带验证Sana-WM 这类生成项目也能摸一摸6.1 Sana-WM 是什么级别的项目实测过程中我顺手拿https://github.com/nvlabs/sana-wm这个开源项目做了一次额外的能力验证。它属于生成式模型方向涉及图像/视频生成领域。我注意到这类项目在社区里的关注度一直很高但大家在 32GB 统一内存设备上跑的案例并不多所以专门试了一轮。Sana-WM 这类项目的共同特点是扩散模型架构需要较大的激活内存而且通常对显存要求不低。在 M6 mini 上跑内存余量是我最先关注的问题。实测下来短输入、短生成场景能跑通偶尔也能顺利生成完整样本但 batch size 稍微调大或者生成的画面分辨率提高内存占用会快速上涨。6.2 统一内存跑生成项目的实测要点生成项目跟 LLM 推理在内存需求上有一个很大的不同LLM 推理的内存主要消耗在权重和 KV Cache而扩散模型在迭代去噪过程中的中间特征图会频繁读写对带宽和内存容量的需求波动非常大。我实际跑下来的配置心得是尽量把 batch size 设为 1先确保功能通再考虑效率关闭所有不必要的后台至少让生成期间系统内存余量维持在 8GB 以上如果项目支持--offload或低内存模式优先开启视频生成类任务如果遇到中途内存耗尽最直接的办法是降低生成帧数而不是优化模型因为帧数对内存占用的影响几乎是线性的。6.3 与 LLM 推理的资源争夺在实际使用中不建议同时长时间跑 LLM 服务和生成模型。某次我开着 llama-server 的 Mixtral 8x7B又用 MPS 后端跑生成项目结果系统内存直接见底两个任务的速度同时暴跌模型服务开始抖动。最后只能先停掉生成任务再重启 llama-server 才恢复。我给自己的管理规则是LLM 服务占 24GB生成任务占 4GB 以下时可以共存只要生成任务需求超过 4GB就先停掉一个再跑另一个。32GB 这台机器物理容量摆在那里资源冲突是常态提前做好规划能省很多麻烦。7. 实测避坑常见问题与排查实录7.1 “OOM 被系统杀掉”怎么预处理在 M6 mini 32GB 上最频繁遇到的问题是模型服务加载到一半或者推理到长上下文时macOS 直接把进程杀掉。我排查后确认多数情况下不是模型本身有问题而是系统内存余量耗尽后触发了强制清理。我的处理办法是先用memory_pressure观察系统内存压力如果压力等级高先关进程加载模型前把所有常驻应用退出尤其是浏览器这个动作能释放 4GB 到 6GB 内存把--ctx-size限制到能稳定运行的范围内先跑通再逐步加遇到反复崩溃时优先换更激进的量化格式比如从 Q4_K_M 换到 Q4_0 或 Q3_K_M损失一点质量但换上稳定性。7.2 “速度怎么提不上去”的排查思路如果 decode 速度只有个位数 token/s先用系统工具看内存带宽是否被占满再看模型是否真的全部 offload 到 GPU。我在 llama.cpp 的日志里看到过offloaded 0/99 layers的情况这意味着模型实际上在 CPU 上跑速度当然上不去。排查思路很简单看 llama-server 启动日志中的offloaded层数量确认-ngl参数生效如果用 MLX确认 MPS 后端真正被调用查看 Activity Monitor 里 GPU 是否真的有占用。7.3 避免数据假象很多人发跑道速度时会非常乐观实际是踩了假象的坑。比如上下文设得很短只有 512 token这时模型还没遇到内存瓶颈速度当然好看一旦把上下文拉到 8K 以上KV Cache 变大、内存压力升高速度立刻下降。所以我建议测速时固定一个足够长的上下文比如 8192同时让输出长度也保持在一个稳定值这样测出来的数字才有参考价值。“量化格式不同速度差异很大”也是个坑。同一模型 Q8 和 Q4 之间的速度差距可能超过 30%你不能拿 Q8 的去比别人的 Q4。实测对比时最好固定为 Q4_K_M这个格式在 32GB 平台上是最均衡的选择。7.4 最后分享一个我留了很久的小技巧我在跑 MoE 模型时会故意把--batch-size调小一点比如 256 或 512而不是拉到上千。这样 prefill 慢了一点但能明显降低瞬时内存尖峰。对统一内存平台来说瞬时尖峰是最伤系统稳定性的东西。看起来是牺牲速度实际上换来了更平稳的完整运行总体收益是正的。这个细节普通文档里很难看到自己踩过几次坑才明白。如果你也要在这类 32GB 统一内存机器上跑本地模型我的最终建议是第一优先选 MoE 架构模型第二量化固定 Q4_K_M第三上下文控制在 8192 到 16384 之间第四生成类任务和 LLM 服务分开跑。把这几条守住32GB 平台能把实力发挥到九成以上。