把一台32G内存的Mac mini M6放到桌上装个Ollama拉一个7B模型下来输入问题回车……很多人问的第一句话通常都是“快吗”紧接着就是“它到底能跑多大的模型”。这两个问题看似简单背后其实牵扯到算力、TPS和端云决策三个完全不同的层面。我这段时间用这台机器做了不少本地大模型实验先说结论它能跑而且日常使用完全能当一台LLM服务但有三个真相必须提前说清楚——容量决定你能不能跑带宽决定你跑多快而“TPS虚高”这个现象几乎能骗过所有只盯着评测数字看的人。这篇东西适合AI应用开发者、正在纠结要不要入手Mac mini做本地推理的人以及想把大模型服务塞进个人工作流的技术爱好者。1. 算力真相跑大模型先看带宽与容量再看TOPS1.1 为什么“AI算力TOPS”在大模型推理里参考意义不大每次发布新款Apple Silicon宣传页上都会出现一个好看的“每秒万亿次运算”数值M系列芯片的神经网络引擎数字逐年翻倍看起来很唬人。但真把大模型部署上去你会发现那个数字和体验之间的相关性远没有想象中那么强。核心原因在于大模型生成token是一个内存带宽密集任务不是算力密集任务。模型推理时每一层都要把权重从内存搬到计算单元和输入向量做矩阵乘再写回结果。生成一个token本质上等于把模型全部权重完整读一遍。读权重的速度取决于内存带宽而矩阵乘本身在现代芯片上相对快得多权重搬运才是真正的瓶颈。可以把这个过程类比成厨房出菜CPU/GPU是厨师内存是仓库内存带宽是传送带。厨师手艺再好传送带每小时只能运500斤食材出菜速度上限就是这500斤对应的菜量。TOPS代表厨师有多能切墩带宽代表食材进厨房的速度。在大模型推理场景里大多数人不是被厨师速度卡住的而是被传送带卡住的。另外还有一个生态层面的原因神经网络引擎虽然也算力很强但它只对Core ML优化过的算子友好llama.cpp、MLX、Ollama这些主流推理框架在Apple芯片上主要走GPU和CPU路线ANE几乎帮不上忙。所以你在评测里看到的M系列TOPS参数和实际跑LLM的体验之间隔着整整一个软件生态的距离。PC上N卡还有个类似的问题就是驱动模式是TCC还是WDDM会影响显存分配方式和计算性能Mac这边没有这层困扰统一内存天然归系统统一调度但“32G不是32G全部给模型”这件事反而是更隐蔽的坑。1.2 32G统一内存模型到底能吃到多少Apple Silicon的统一内存架构确实很先进CPU和GPU共享同一片物理内存避免了传统PC里“显卡显存不够、还要把数据拷回内存”的来回折腾。但这不意味着你在系统里看到的32GB全都能用来跑模型。macOS系统本身、后台进程、桌面窗口、浏览器标签页日常开机就要吃掉6到10GB。剩余的内存里GPU还要遵守一个“wired limit”限制大致上是系统给图形和计算任务划定的预留上限默认情况下32G机器可被GPU自由支配的部分通常在20到24GB左右。如果这台Mac mini是纯当推理服务器用不带显示器、不常开图形密集型应用可以通过调高iogpu.wired_limit_mb把更多内存划给计算任务用但如果是日常兼用办公这个参数最好不要乱动否则图形界面调度会非常难受。所以在32G机器上规划模型时我的经验是按下限估系统留10G模型和运行时的可用空间大概只有20到22G。这意味着什么看下面的速查表就清楚了。模型规模精度权重内存32G机器上实际体验7BINT4约3.5GB很舒适长上下文也从容8BINT4约4GB主力推荐日常首选8BINT8约8GB能跑质量更好但上下文别太长14BINT4约7GB能日常用属于质量与速度的甜点32BINT4约16GB能跑但速度一般上下文受限7BFP16约14GB勉强系统一忙就容易触发swap表格里只是权重占用的估算还有一个经常被忽略的大头是KV Cache。以Llama-3-8B这一类结构为例FP16精度下每生成一个tokenKV Cache大约要占128KB算下来8K上下文就是1GB32K上下文直接吃掉4GB。如果量化到8bit这个数字能砍一半左右。也就是说32G能跑多大的模型不只是“权重放不放得下”的问题还包括“你要给它留多长的对话上下文”。想跑大模型加超长上下文在32G上基本只能二选一。1.3 精度与算力需求FP32、FP16、INT8、INT4到底差多少聊精度之前先给一个最基础的换算关系后面所有估算都靠它。模型权重的内存占用等于参数量乘以每参数字节数FP32是4字节FP16/BF16是2字节INT8是1字节INT4是0.5字节。比如一个8B模型FP16下就是16GB权重INT8下是8GBINT4下是4GB。精度的选择直接影响两个东西速度和质量。速度方面因为推理是“读权重算一遍”权重越小每分钟能读的轮数就越多吞吐自然上来。同样带宽下INT4比FP16快四倍INT8比FP16快一倍。质量方面FP16几乎没有信息损失INT8在多数场景下损失不大INT4则要分模型看新版量化算法做出来的4bit模型很多任务上已经能和FP16打得有来有回但复杂推理、代码生成这类任务偶尔还是会出现细节上的退化。回到M6的带宽推算。Apple芯片的内存带宽规律一直是基础款大约100到200GB/sPro款翻倍到300GB/s左右Max款再翻倍。按这个演进规律M6基础款的带宽估个150GB/s上下、Pro款估个300GB/s上下应该不会偏太远具体以真机为准。基于这个带宽就能用公式直接估算理论TPS上限单流生成速度 ≈ 内存带宽 / (参数量 × 每参数字节数)以150GB/s为例8B INT4模型的理论上限是150 / (8 × 0.5) ≈ 37 token/s32B INT4是150 / (32 × 0.5) ≈ 9 token/s8B INT8则是150 / (8 × 1) ≈ 18 token/s。实际跑起来因为预填充、内存分配、系统调度这些开销能到理论值的八成左右就算很健康了。这就是为什么同款芯片、同尺寸模型有人晒出的TPS是另一个人的快一倍很可能只是精度、上下文长度和批处理参数不同而已。2. 真实TPS数字好看和好用是两回事2.1 “TPS虚高”是怎么来的大模型圈子里“TPS虚高”几乎是个默认现象了。你在论坛上看到有人晒出某模型在Mac上跑到每秒四五十个token自己也买了一台一模一样的结果实际用起来感觉完全不是那么回事。问题就出在测试方法和真实使用场景的严重脱节。最常见的虚高来源有几种。第一种是只报生成速度不报预填充速度。大模型的完整响应分为两个阶段读入你那一大段prompt做理解这叫预填充然后一个字一个字往外蹦这叫生成。预填充对长文档、长对话来说非常耗时但很多人测速时只测生成段甚至用极短的prompt跳过了大头。第二种是用低量化、小模型来测8B INT4和32B INT4本来就是两个世界跑出来的数字根本没有可比性。第三种是短回复测试模型只生成了几十个token首token延迟占总耗时的比重被摊得很薄端到端速度自然好看。还有一个更隐蔽的因素是热缓存和小批量。同样的prompt跑第二遍系统的页缓存、KV Cache、推理框架的算子缓存全都生效了速度比冷启动快很多而测试时只测单并发、单请求实际生产环境里一旦多路请求同时打进来单流TPS会明显下降网格抖动也会让体感变得更差。所以“TPS虚高”的本质是拿实验室里最理想的单点数字去对标真实工作负载里的综合体验中间差的这30%到50%就是这届评测最容易骗人的地方。2.2 一套靠谱的测速方法既然要聊真实TPS就得有一套能复现的测法。我的原则是区分三个指标预填充速度、生成速度、端到端TPS。三个分开测别混在一起算。llama.cpp编译出来的二进制里自带一个llama-bench工具可以快速得到标准的prefill和token generation数据。比如跑一个8B模型可以这么测./llama-bench -m qwen2.5-8b-Q4_K_M.gguf -p 512 -n 256 -t 8输出里的pp512就是处理512个token prompt的预填充速度tg256就是生成256个token的生成速度。这两个数字能直观反映芯片带宽和框架优化水平。但工具数字只能说明硬件表现真实的端到端体验还需要模拟实际使用场景测。我更建议直接跑一个真实任务准备一段500到1000字的实际业务文本让模型先读文本再输出一段200字以上的回复然后用时间戳把整个过程包起来看全流程的token数除以总耗时。这个数字才是你每天写代码、做摘要、跑Agent时真正体会到的速度。把服务跑起来之后用Ollama的API计时也是个实用办法time curl -s http://127.0.0.1:11434/api/generate \ -H Content-Type: application/json \ -d {model:qwen2.5:8b,prompt:请总结下面这段文字...,max_tokens:300}从返回体里把eval_count字段拿出来结合time命令输出的总耗时就能算出一个端到端的生成TPS。这种做法测出来的数字会比跑分工具更贴近“我实际用起来到底什么感觉”。同时还要把任务叠加测几次比如连续发3个并发请求看单流下降幅度这才是真实工作负荷。2.3 32G M6上各档模型的TPS参考区间与体验建议基于内存带宽公式和前代M系列实测规律32G Mac mini M6上跑各档模型大致的参考区间如下。注意这些是估算区间不是硬指标拿到真机后建议按上面的方法自己测一遍再作决定。模型量化预估单流TPS体验定位7BINT430~50 token/s流畅主力日常问答、RAG、代码补全8BINT425~45 token/s主流选择质量与速度平衡8BINT815~25 token/s质量优先速度还能接受14BINT415~25 token/s较舒服适合认真干活32BINT46~12 token/s能跑但只适合离线批处理这里有个很实际的经验不要只看峰值TPS还要看上下文长度对TPS的拉低作用。32G机器上跑32B INT4权重占了16GB系统剩下十几GB上下文一拉长KV Cache内存吃紧框架就会开始和系统抢内存TPS会比表里的参考值掉得更厉害。相比之下8B INT4在32G上是真正的舒适区权重小、缓存宽裕就算开到32K上下文也能稳住速度。3. 实操在32G Mac mini M6上把模型跑顺手3.1 选型与安装MLX还是Ollama还是llama.cpp在Mac上跑大模型主流方案就三套Ollama、MLX生态和llama.cpp。它们不是互斥关系我自己的机器上三套都装了按场景切换。Ollama胜在零门槛安装完一条命令拉模型自带OpenAI兼容API非常适合快速搭建个人助手服务。它的底层调用的就是llama.cpp的推理引擎所以很多参数在服务端也能调。MLX是Apple官方维护的机器学习框架对Apple Silicon的算子优化是全家桶里最彻底的跑模型的速度通常比llama.cpp在同等条件下再快个百分之十到二十尤其是批处理场景更明显。缺点是需要懂一点Python生态相对集中在开源模型转换这一块。llama.cpp则是最灵活、最底层的选择能精确控制KV Cache量化、批大小、线程数这些参数适合排查问题。我的建议是第一次上手直接装Ollama体验本地大模型。有进阶需求后再用MLX跑跑你手头最常用的模型比较一下两者速度差距。最后如果你想深入调优再拿llama.cpp做对照组。安装基本是这些命令# Ollama curl -fsSL https://ollama.com/install.sh | sh ollama pull qwen2.5:8b # MLX pip install mlx mlx-lm python -m mlx_lm.generate --model mlx-community/Qwen2.5-8B-4bit --prompt 你好 # llama.cpp brew install llama.cpp3.2 让模型用得更快的内存设置很多人装上Ollama后没做什么设置跑大模型就总感觉内存吃紧、速度不稳。实际上有些关键参数值得手动调一调。第一个是上下文长度。Ollama默认的上下文窗口通常只有2048或4096对长文档任务根本不够。可以在启动服务前设置OLLAMA_CONTEXT_LENGTH16384这样的环境变量或者运行时用num_ctx参数指定。上下文越长内存占用越大速度也会略微下降所以别无脑开大按你实际需求来。第二个是KV Cache量化。如果用的是llama.cpp直接推理可以在启动参数里加-ctk q8_0 -ctv q8_0把KV Cache压到8bit对长上下文场景内存能省一半质量损失几乎感知不到。Ollama新版部分模型也支持KV量化但兼容性不如llama.cpp直接。第三个是GPU内存上限。刚才说过32G机器实际给模型的就是二十几G如果把它当无头推理服务器用可以通过sysctl调高GPU wired limit让系统为计算任务预留更多内存。但注意这个操作会让图形响应变钝日常办公的机器别试。还有一个容易被忽视的点后台占用。很多人的Mac mini是主力开发机Xcode、Docker、浏览器、IM全开着再跑一个8B模型内存早就见红了。跑大模型前先用htop和vm_stat看看剩余可用内存内存压力如果长期处于黄色或红色别怪机器慢先把后台清一清效果立竿见影。3.3 一个完整示例把8B模型跑成个人知识库接口把以上设置落到一个真实场景里整个流程会清晰很多。假设我想让这台32G机器承接一个“内部知识库问答”服务每天处理几十次长文档摘要请求。第一步拉一个8B级别模型。我用qwen2.5:8b4bit量化版权重占4到5G给系统和上下文留出很大余量。第二步设置上下文长度为16K重启Ollama服务这样单次能吞下万字左右的文档超出部分做切分。第三步写一个简单的Python脚本把文档按段落切块后做向量检索将命中片段拼进prompt再调用本地的OpenAI兼容接口完成问答。第四步用上一节的方法做端到端计时观察不同文档长度下的真实TPS和内存占用。这套流程跑下来我的经验是8B INT4在32G机器上面对16K上下文、几百行代码或万字文档的摘要需求单次响应普遍在十秒内完成TPS基本稳定在20到35之间。完全够个人和五六个同事一起使用。如果你想进一步压榨这台机器的价值还可以尝试用MLX做LoRA微调。32G内存对7B/8B模型做LoRA是可行的4bit基础模型叠加低秩适配器峰值内存能控制在十几GB以内微调完的适配器只有几百MB可以针对自己业务场景做轻量定制。但全参数微调就别想了那是64G甚至128G机器才该考虑的方案。3.4 跑不到想要的速度时的排查顺序如果发现速度明显低于预期按这个顺序排查能省下大量瞎折腾的时间。现象可能原因处理思路TPS只有别人晒的一半模型量化不同或上下文过长确认INT4模型、缩短上下文首token很慢prompt太长、预填充消耗大切分输入或压缩prompt跑到一半突然卡顿内存压力触发swap检查后台进程、降模型档位并发请求全卡死单机算力上限到了限制并发队列控制请求频率风扇呼呼响但速度低长时间推理降频检查机器散热环境清理积灰首token慢这个点要单独说说。很多人只关心生成速度忽略了预填充。当你丢给模型一篇八千字的文档让它写总结时模型要先把这个文档全部“读”一遍这个阶段走的是矩阵运算对带宽和算力需求都很高。不同框架的预填充优化差异非常大llama.cpp在这一块的调度做得相对好。如果经常处理长文档建议对比一下Ollama和MLX的预填充速度选择更适合的那套方案。4. 端云决策本地有本地的好云端有云端的强4.1 成本账一次性投入还是按token付费跑本地大模型的人多少都算过一笔账买这台机器花了一万多到底值不值回票价这个问题不能只看硬件价格要看你的使用强度和使用周期。本地端的成本分两部分。一是设备折旧一台32G Mac mini按三四年使用周期摊下来每天十几到二十几块。二是电费Mac mini满载大概五十瓦上下真按24小时挂机算一年电费也就两百多块比想象中低很多。所以本地端一年的隐性开销大约在几百到一千里徘徊大头还是设备折旧。云端端的成本就比较灵活了。不同大模型API的价格差异极大便宜的国产模型每百万token只要几块钱旗舰海外模型可能要到几十甚至上百美元。我们不讨论具体价格直接给判断逻辑你的单日token消耗量乘以API单价再乘以365天如果这个数明显高于设备的年折旧成本那本地端就是划算的。反过来如果你一天只调几百次API每次回复才几百个token一个月算下来几十块钱那还真没必要额外添置一台专用设备。以我的实际用量看纯开发时偶尔调用API和纯生产环境跑批处理是两种完全不同的账单前者一年可能就几百块后端一跑起来一个月几千块的token费用都是正常的。所以“买32G到底值不值”这个问题本质上取决于你是否把本地机器用成了“跑批处理的常驻工人”而不是偶尔玩一玩。4.2 延迟、隐私与可控性成本之外端云选择的另外三个维度是延迟、隐私和可控性。延迟层面本地模型最大的优势是首token延迟稳定因为所有计算都在本机完成没有网络RTT没有排队。API服务的首token延迟波动很大高峰期几百毫秒甚至几秒都正常但云端集群的并发吞吐是本地完全没法比的你本机跑8B模型两三个并发就差不多到极限了云端卡池同时处理几十个请求毫无压力。所以“延迟低”和“吞吐高”这两件事在端云两侧是分开的单请求体验本地好多请求总吞吐云端强。隐私层面就不需要多解释了。代码、病历、财务数据、未公开的论文这些东西送进第三方API即使服务方承诺不用于训练心理上也很难踏实。本地模型哪怕能力弱一点数据不出主机这个特性就足够让它成为很多场景的必选。可控性则是另一个容易被忽略的点本地模型可以随意改system prompt、切量化档位、做LoRA微调甚至改采样参数到离谱的程度都没人管你云端API的审核、限流和使用条款随时可能影响你的工作流。4.3 决策清单什么任务留在本地什么任务必须上云在32G Mac mini M6这个配置上端云决策可以整理成一份很实用的清单。本地优先的任务高频低延迟交互比如Copilot类的代码补全、聊天机器人隐私敏感数据处理比如内部文档摘要、脱敏日志分析离线环境下的固定模板生成以及你需要反复修改prompt、微调模型、实验各种采样参数的研究任务。这些任务用云端API要么延迟不可控要么隐私不放心要么成本按量算下来太贵。云端优先的任务超大参数模型才能搞定的复杂推理和长链Agent任务需要最新知识更新的问答高并发批量处理比如几千条客服对话的自动分类、大量文章的批量改写以及云端生态更成熟的多模态和工具调用场景。这类任务本地跑既慢又不稳硬扛只会两头受气。更理想的做法是混合架构。我现在的模式是本地8B模型作为第一层接收高频和敏感请求遇到本地模型置信度偏低、任务超出它的能力边界、或者并发量超过两台本地机器处理极限时再自动转发到云端大模型。这个降级逻辑在代码里只需要几行判断比如看请求类型、看上下文长度、看本地服务超时时间。很多Agent框架原生支持多模型路由配起来也不麻烦。这样既能享受本地隐私和低延迟又保留云端灵活兜底的能力。5. 常见问题与避坑记录5.1 为什么我的TPS只有别人晒的一半这个问题在社区里出现频率极高根源几乎都在配置差异上。先核对模型文件是不是同一个同一家族模型INT4、INT8、FP16三个版本的速度可以差出四倍。再核对上下文长度别人开4K你开32KKV Cache对内存的占用会导致框架启动内存压缩速度会明显下降。然后是运行环境别人的“裸机测试”可能是刚开机、后台干净你的机器挂着开发环境后台一直在占用CPU和内存带宽。最后才是芯片本身的差异——M6基础款和M6 Pro款的带宽差了一倍同款模型在Pro上跑出两倍TPS一点都不奇怪。5.2 跑着跑着内存满了、系统卡死怎么办这是在做本地模型初期最容易踩的坑。系统内存压力一旦变红macOS就会疯狂压缩内存或启用swap整个机器流畅度迅速崩盘。解决办法有三个方向第一把模型档位降一档从14B降到8B体验改善是立竿见影的第二缩短上下文窗口不要贪心长对话第三设置Ollama或llama.cpp的模型卸载策略用完立刻释放内存别让多个模型同时常驻。如果确认是系统内存分配问题可以观察vm_stat里的cow_faults和swap使用情况频繁的swap说明内存真的不够用了这时候再有优化技巧也救不回来只能减模型或加内存。5.3 Mac mini的散热对长时推理的影响Mac mini并不是无风扇设备它内部有主动散热风扇但小机箱压大算力时温度会比较高。跑那些动辄十几分钟到几十分钟的长文本批处理任务时芯片温度爬高后会有降频保护TPS会从峰值往下掉一截。这不是bug是硬件的自我保护机制。要延缓解这个问题物理放桌上的话给Mac mini留出足够的通风空间不要塞在密闭柜子里软件层面可以把线程数调低一点或者拉长请求间隔让芯片有余力喘气。如果是7×24小时挂机做批处理建议观察一下核心温度和功耗找到长期稳定运行的工作点而不是盯着开跑前两分钟的峰值性能。5.4 如何判断哪些模型真的能长期留在32G里32G机器的模型管理其实是个取舍题。根据我的经验最多常驻两个模型就差不多了一个8B INT4做日常主力一个14B INT4或32B INT4做精度要求更高的离线任务。如果还想放一个视觉模型那主力就得让位给7B。判断标准很简单先估算权重占用再按最常使用的上下文长度估算KV Cache两项之和加系统余量不超过25G就算健康一旦超过27G长期运行一定会出问题。另外值得记住的是Ollama和MLX都支持按需加载模型不用的时候权重不占显存但“按需”在首次调用时会有一次冷启动延迟几秒到十几秒不等。如果你追求随时响应就得让模型常驻内存如果你更看重多模型切换那就接受冷启动延迟两者不可兼得。最后再分享一个我个人的体会这台32G的Mac mini跑大模型最正确的打开方式不是把它当日常办公电脑而是当成一台安静扔在角落、7×24小时开机的本地推理服务器。给它接上知识库、Agent框架和自动化脚本平时根本不用走过去碰它需要时随时通过局域网API调用。有了这种“常驻服务”的使用心态之后你才会真正理解为什么说本地模型最重要的是可用内存和带宽而不是GPU的广告纸面数字。