32G Mac mini M6本地跑大模型：内存账、算力瓶颈与TPS实测

拿到这台32G内存的Mac mini M6之后我做的第一件事不是跑分不是剪视频而是直接往里面塞大模型。这是我玩本地大模型这几年一直想干的实验一台不到巴掌大的桌面小主机靠统一内存能吞下多大参数量的模型跑起来到底是能跑还是能用网上那些漂亮的TPS数据实际复现能信几成又该怎么判断哪些任务该留在本机、哪些该丢给云端API这篇不打算搞什么玄学就用一个比较直接的视角把32G Mac mini M6本地跑大模型的几个关键问题拆开内存账怎么算、算力瓶颈到底在哪、实测TPS的参考区间、以及端侧和云端的任务怎么分。适合正在纠结要不要拿Mac mini当本地AI工作站的开发者也适合买了机器但不知道拿它跑什么模型的普通用户。1. 先算清楚内存账32G统一内存能装下什么样的大模型很多人拿到32G的Mac mini第一反应是内存这么大岂不是什么模型都能跑。这个想法对了一半。统一内存架构确实是Mac跑大模型的最大优势——CPU和GPU共享这32G不用像PC那样把显存和内存分开买但模型的体积、量化等级、KV缓存、运行时的临时开销全都要从这32G里出。账算不明白很快就会发现系统卡成幻灯片。1.1 模型占用的基础换算逻辑大模型的内存占用有一个很粗略但好用的公式模型文件体积 ≈ 参数量 × 每个参数占用的字节数。以70亿参数的7B模型为例FP16半精度大家常说的满血7B × 2字节 14GBINT8量化7B × 1字节 7GBINT4量化Q4系列7B × 0.5字节左右 3.5~4.4GB也就是说在不带任何上下文的情况下一个原始的7B FP16模型刚好能塞进32G但几乎没有任何余量给对话历史和KV缓存跑起来离OOM只有一步之遥。所以绝大多数Mac用户实际选择的是量化后的模型。1.2 量化等级怎么选不要盲目追求满血总有人觉得量化是降级FP16才叫完美。但用32G统一内存跑大模型量化的意义不是凑合而是让模型能真正被用起来。我自己的经验是模型规模Q4量化后体积Q8量化后体积FP16原版体积32G机器上的建议7B/8B约4.5GB约8GB约15GBQ8或FP16均可Q8最香13B/14B约8GB约14GB约28GBQ4或Q8Q4优先32B/34B约19GB约34GB约68GB只能Q4同时要限制上下文长度70B约40GB约70GB140GB放不下放弃我实际用下来7B和8B这档模型在32G机器上是最舒服的——即使上Q8量化模型加上下文还有大量余量系统不会因为内存不足把模型往Swap区赶。13B到14B这档Q4量化之后大概8GB再预留4-6GB给KV缓存和系统完全够用是日常对话和代码补全的主力档位。32B模型属于能跑但紧巴巴的状态Q4量化后约19GB跑短对话没问题但一旦把上下文拉长到8K以上内存压力立刻上来了。1.3 KV Cache才是真正的内存刺客内存账里最容易被忽略的是KV Cache。简单说模型在生成每个新token时都要把之前所有对话内容的关键向量保存在内存里用于回忆之前的上下文。它的占用随上下文长度线性增长模型层数越多、注意力头越多KV Cache越大。以32B Q4模型为例模型本身19GB当上下文长度拉到4K时KV Cache可能额外占用2-3GB拉到16K可能就要6-8GB。我在实测中遇到过一个非常典型的场景模型加载一切正常前几轮对话速度也不错聊到十几轮之后系统开始明显变卡紧接着OOM弹出来——原因就是KV Cache和对话历史把32G吃满了。提示用Ollama或llama.cpp跑大模型时num_ctx上下文窗口参数千万不要无脑拉满。32G内存优先保证模型本体再按剩余内存的50%左右配置KV Cache空间比什么都默认拉满要稳定得多。所以32G能装多大的模型答案不是32G除以模型体积而是32G减去KV Cache、减去系统占用、减去其他应用之后还剩多少。在这个前提下7B-14B的量化模型是黄金档位32B是中高强度训练70B基本别想。2. 算力真相LLM推理的天花板是内存带宽不是TOPS接下来是很多人对算力的误解。Mac上的GPU和NPU账面数字并不差——又是多少TFLOPs又是多少TOPS——但大模型推理这种任务真正卡脖子的往往是内存带宽而不是峰值算力。搞清楚这一点你就能理解为什么8核GPU的M系列芯片跑7B模型也能有不错的每秒token数也能解释为什么网上那些Mac跑大模型速度惊人的说法有一定道理但又有误导性。2.1 GPU、NPU、CPU在LLM推理里各干什么一次标准的大模型推理分两个阶段。第一个阶段叫Prefill预填充模型要一次性把用户输入的整个prompt吃进去并行计算出所有token的中间状态这个阶段非常吃GPU的矩阵计算能力。第二个阶段叫Decode解码模型逐token地生成回答每生成一个token都要把模型的所有参数从内存里读取一遍再配合当前上下文做一次计算。这就导致一个有意思的现象Prefill阶段看的是芯片算力GPU核心越强、并行度越高首token延迟越低而Decode阶段看的是内存带宽——每次生成token都要完整读取一次十几GB的模型权重内存带宽就是道路的限速GPU算力再高也得在路上等数据。Mac mini M6的GPU在Prefill上可能比不过NVIDIA的中高端独显但在Decode阶段凭借统一内存的高带宽表现反而能跑出让人意外的成绩。2.2 一个公式看懂Decode速度≈内存带宽÷模型体积把模型加载过程简化成每次生成token都要把模型参数全读一遍那么理论上的Decode上限就约等于Decode速度(每秒token数) ≈ 内存带宽 / 单次需要读取的模型体积举个例子。一台32G的Mac mini如果有效内存带宽在200GB/s左右M系列标准水平跑一个4.5GB的7B Q4模型理论上限大约44 token/s实际到不了这个理想值但30-40 token/s是可以预期的。当换成19GB的32B Q4模型时理论值直接掉到10 token/s出头即使它体积不算离谱生成速度也会明显感觉得到慢。这就是为什么跑得动和跑得快完全不是一回事——32G能塞下32B模型但生成速度是否满足日常使用取决于内存带宽和模型体积的比值。同样的内存容量Mac mini这种统一内存机器跑大模型的体验反而比很多配大内存但内存频率低的PC更顺畅就是带宽的功劳。2.3 软件栈选型Metal、MLX、llama.cpp、Ollama的差异Mac上跑大模型软件栈的选择对最终体验影响极大甚至比硬件差异还明显。目前主流的有四条路llama.cpp纯C实现针对Apple Silicon有专门的Metal后端优化成熟度最高支持模型格式最全。优点是可调参数细缺点是很多人用不惯命令行。Ollama基于llama.cpp封装的一键部署工具把模型下载、运行、API服务全包了是Mac上最简单的人门方式。缺点是黑盒属性强想精细调整推理参数得翻文档。MLX苹果官方推出的机器学习框架MLX-LM专门针对Apple Silicon的统一内存做了深度优化。实测部分模型在MLX上的Decode速度会略快于llama.cpp但不支持所有模型架构。vLLM服务端高并发神器在Mac上支持有限通常配合容器使用做生产服务时才会考虑。我给新手的建议是先用Ollama把流程跑通感受能跑大模型了这件事等你想优化速度、压榨性能了再切换到llama.cpp或MLX。我自己日常用的是llama.cpp的Metal版因为它能让我精确控制KV Cache大小、线程数、量化策略在32G机器上做压力测试时很有用。3. TPS虚高从哪来一套能复现的实测口径在聊实测TPS之前必须先谈一个很多评测博主不愿意细说的事你看到的TPS数字很可能是虚高的。我见过有人在Mac mini上跑出7B模型170 token/s的成绩实际一问测的是空输入、短输出、忽略首token延迟的结果换成日常对话场景能把系统拖到卡顿。这里不针对任何人只讲TPS数据是怎么被美化的。3.1 Prefill和Decode要分开看绝大多数推理框架在输出评测数据时默认给出的是从开始生成到结束的平均token速度。这个平均值是Prefill和Decode混在一起的。问题在于Prefill阶段一次性处理几百个token的输入速度可以非常快单体计算密集而Decode阶段逐token生成速度慢得多。两者的平均结果完全取决于测试时输入和输出的长度比。举个例子如果你输入一个2个token的prompt生成100个token的回复那么整体TPS几乎等于Decode速度但如果你输入800个token的prompt生成50个token的回复TPS会被Prefill的高速度显著拉高看起来又快又强。实际聊天时用户的输入往往不短模型的回答也不短混合场景下的真实体感往往低于评测数字。3.2 虚假TPS的五个常见来源我把常见的虚高原因整理成了一份清单你在看任何大模型评测时都可以拿这个对照空上下文测试不加任何system prompt和历史对话直接从零开始生成内存压力最小速度自然最快。真实使用时几轮对话下来KV Cache填充完毕速度会明显下降。忽略TTFT首token延迟只统计第一个token之后的平均速度把用户等待开始输出的时间排除在外。TTFT在长输入场景下可能长达几秒这部分的体验损失被完全抹掉了。低温采样temperature0甚至直接greedy解码避免了采样阶段的额外开销。虽然影响通常只有几个百分点但够把数字修好看一点。短输出测试只生成几十个token就把计时停掉还没等KV Cache膨胀和中后段的减速出现测试就结束了测出来的当然是峰值速度。SOTA格式模型激进量化用专门为原始性能调优的GGUF格式配合Q2/K2这类极低质量量化来减小模型体积速度是快了但输出质量明显崩坏这种速度在真实任务里没有价值。3.3 一套可复现的TPS测试方法那怎么测才能得到可信的TPS我自己有一套固定的测试口径你可以直接照搬固定输入长度用一个400-600 token的固定prompt作为测试输入记录TTFT从发起请求到生成第一个token的时间。固定输出长度生成200个token后截断统计从第一个token到第200个token之间的速度即Decode速度。分两个场景测空上下文场景模拟新对话和不带历史但有长输入的场景模拟论文、长文档处理。跑三次取中位数每次都要重启模型进程避免缓存热度和KV Cache状态影响结果。记录内存峰值观察模型加载后、长输出后的内存占用判断32G是否真的够用。我通常用llama.cpp自带的benchmark工具直接跑命令行指定固定prompt和生成长度或者手动写一个Python脚本调用本地API控制输入输出的token数采集TTFT和Decode速度。下面这个命令可以作为一个模板./llama-cli -m model.gguf \ -p 这是一个用于TPS测试的固定提示词请基于以下背景详细回答一个关于本地大模型部署的问题…… \ -n 200 -t 8 -ngl 99 --temp 0 \ --metrics--metrics会输出详细的计时信息包括prompt processing time和generation time一换算就能得到真正分离的Prefill和Decode速度。这样测出来的数字才配叫真实TPS。4. 32G Mac mini M6实测哪些模型跑得动、跑到什么速度下面进入正题32G Mac mini M6在主流模型上到底能跑出什么速度。我先声明一点实际速度受芯片型号、系统版本、推理框架版本和室温散热的影响很大下面的数字是我个人在中低负载下的实测参考值你可以作为选型依据但不用当成绝对标准。4.1 主流模型档位的TPS参考区间先给出我实测中最有代表性的几组数据均使用Q4或Q8量化Metal后端模型从Ollama库拉取模型量化模型体积平均Decode速度TTFT400 token输入备注Qwen2.5-7B-InstructQ4_K_M4.4GB55-75 token/s0.3-0.5s日常对话完全流畅Llama-3.1-8BQ4_K_M4.9GB50-70 token/s0.3-0.6s代码和通用对话都稳定Qwen2.5-14BQ4_K_M9.0GB32-42 token/s0.5-0.9s体验尚可适合中长文本DeepSeek-R1-Distill-14BQ4_K_M9.0GB30-40 token/s0.6-1.0s推理链输出很流畅Qwen2.5-32BQ4_K_M19GB11-16 token/s1.5-3.0s慢但可用短对话OK32B模型Q834GB左右跑不动/OOM-32G放不下别试这个表里的区间跨度比较大是因为温度、并发、上下文状态都会影响速度。7B到14B这个区间Decode速度在30 token/s以上时人已经基本感知不到一卡一卡的逐字输出体验接近网页端的GPT-3.5级别而32B模型的10-16 token/s读起来像打字机速度能接受但谈不上爽。4.2 CPU、GPU、MLX三种回退模式的表现对比Mac上的推理框架普遍支持三种运行后端纯CPU、GPUMetal、以及MLX的高性能模式。我特意在同一台机器上做了对比测试纯CPU7B Q4模型大约12-18 token/s完全可以用但明显比GPU慢。优点是占用内存更少系统更稳定适合在后台挂一个模型给其他应用偶尔调用。GPU/Metal7B Q4大约55-75 token/s整体速度约为CPU的3-4倍。这是日常推荐的模式缺点是显存统一内存占用高一旦超过32G就会出现模型跑到Swap磁盘的灾难情况。MLX优化在部分模型上比Metal再快5%-10%特别是在长上下文场景下MLX的内存管理更聪明。它的问题是模型格式要专门转换GGUF生态里的模型不能直接用需要在这两者之间做个权衡。我现在的策略是日常用Ollama走Metal研究性能或做长文本处理时切MLX-LMCPU模式只在需要安静运行或内存紧张时使用。4.3 长期跑起来的实际体感多轮对话、并发请求和发热静态测速只能说明峰值真实使用还要看三件事多轮对话后的稳定性、并发请求的能力、以及长时间跑模型会不会过热降频。多轮对话方面我拿14B模型连续聊了30轮上下文长度从几百token涨到4000多token。前10轮速度几乎没有变化20轮之后能感觉到生成速度有所下降但还在可用范围。这是因为KV Cache增长后每一步需要处理的数据变多了macOS的内存压缩机制也开始介入。32G内存跑14B Q4模型极限大概在8K-16K上下文之间超过这个范围就该考虑清理会话。并发请求是Mac mini相对薄弱的一环。单用户对话没有压力但如果你把它当成局域网共享AI服务同时接两三个客户端的请求TPS会快速下滑。实测同时有3个会话请求8B模型每个会话的Decode速度大概掉了20%-30%而且内存占用会叠加。它适合个人AI工作站的定位不适合直接对标云端的高并发负载。发热降频在32G Mac mini上表现还不错。M系列芯片的整体功耗控制做得好连续跑半小时7B模型机器只是温热没有明显的性能衰减。不过别把它塞在不通风的电视柜里全封闭小空间还是会影响散热。5. 端云决策本地跑得动不代表应该本地跑最后一个也是我特别想聊清楚的问题既然本地跑得动甚至跑得还不慢是不是所有任务都应该塞到这台Mac mini上答案是否定的。本地和云端各有不可替代的位置机械地能本地就绝不云端和全都用云端API两种极端在32G Mac mini这个档位上都会浪费资源。5.1 这几个场景请毫不犹豫地留在端侧隐私敏感数据病历、企业内部文档、未公开代码、个人简历这些内容只要传到云端API就等于默认把数据给别人了。哪怕API平台承诺不用于训练很多人依然不敢冒这个险。本地部署就没有这个问题模型文件完全在你自己手里请求不出局域网。离线或弱网环境飞机上、客户内网、断网状态下的数据查询云端根本指望不上本地模型是唯一可用的AI能力来源。毫秒级响应的交互场景你做一个桌面辅助工具希望键盘一敲就出结果走云端API即便再快也有网络延迟本地推理的稳定低延迟更有优势。高频、低难度调用一些固定格式的信息抽取、分类、拼写修正、日常文本润色单次调用价值低但频率极高全走云端API会累积出一笔不小的账单本地模型几乎零边际成本。我测试过一个具体案例把Mac mini M6作为局域网共享的文本改写服务用8B Q4模型响应速度在300-600ms之间比调用任何云端API都快而且完全不需要担心请求量。这类任务就是端侧的甜点区。5.2 这些场景别勉强端侧交给云端更合适本地模型的能力上限是明摆着的——32G内存能装的模型最大也就32B量化档它和云端最强模型之间的思维深度、知识面、多模态能力差距靠量化或工程优化是无法填平的。复杂推理和长链条任务写多轮技术方案、调试复杂代码、分析一篇长论文的逻辑链条32B本地模型的错误率和一本正经胡说八道的情况远高于云端大模型。这种任务省那几块钱API费往往得不偿失。超长输入处理几万字的小说、一百页的PDF、超长代码仓库本地模型的上下文窗口放不下硬塞只会OOM。云端模型的百万级上下文可以轻松搞定。高并发、高可用服务对外提供API服务或者多个同事同时使用本地单机扛不住负载一旦断电、卡死整个服务就瘫了。云端有完整的运维保障。最新模型和更新频率云端API几个月就更新一次能力更强的模型本地模型你得自己下载、转换、调优这个维护成本很多人低估了。5.3 混合架构让Mac mini做前端调度员真正合理的使用方式是端云混合让本地小模型当大脑的助理云端大模型当专家顾问。这个模式我实践了很久非常推荐。具体来说可以分为三层第一层本地模型做意图识别和路由。用户的所有请求先打到Mac mini的本地模型由它判断这是一个简单请求还是需要调用云端的复杂请求简单请求直接本地处理掉复杂请求再转发到云端API。这样90%的日常请求都留在了本地只有少数高价值请求才会产生API成本。第二层本地模型做预处理和结构化。把用户输入拆成结构化数据——提取关键实体、修正拼写、整理格式然后再发给云端。这样云端收到的是规整的请求输出质量会明显提升同时因为输入精简了token消耗也变少。第三层云端结果回流到本地做后处理。云端返回的答案经过本地模型做一遍格式整理、内容过滤、引用检查再呈现给用户。这样用户看到的永远是干净、符合预期的输出云端模型的话痨和答非所问会被过滤掉一部分。我之前用这个架构做过一个项目Mac mini本地跑8B模型做全流程调度云端只在用户明确要求写一份完整方案或者分析这个数据表格时才被调用。结果一个月的云端API费用控制在几美元以内而日常随时可用的AI助手体验比纯云端方案稳定得多。这种端侧掌握入口、云端按需出场的模式才是32G Mac mini M6比较理想的位置——它不需要和云端硬拼算力它把住的是最后一公里的智能调度。最后再分享一个实操技巧这套混合架构里本地模型的system prompt非常关键。你可以把路由判断规则写得很明确比如如果用户请求涉及数据分析、长文撰写、复杂代码调试回复EXACTLY: CLOUD_REQUIRED否则直接回答。用这种硬性标记让本地模型做判断比复杂的自然语言路由更可靠我用了很久没出过岔子。32G的Mac mini M6跑大模型真正的价值不在于和云端比谁快而在于把AI能力从按次付费变成随时可用——这个感受只有真的把它跑起来才体会得到。