最近总有人问我同一句话32G内存的Mac mini M6跑大模型到底行不行这里的“行”往往包含三层意思能不能装上跑起来每秒能蹦几个字以及有了它之后还要不要买云端API。说白了就是三个字——算力、TPS、端云决策。我手上这台32G的Mac mini M6已经用了两个多月折腾过本地部署、量化、LoRA微调也接了不少项目的端云混合调用。今天不聊PPT参数直接聊我实测下来的算力真相、真实TPS以及我如何做端云决策。先给结论32G的Mac mini M6完全能跑大模型7B到14B量级体验不错32B量化后属于“能跑但你要有耐心”70B就别指望了至于快不快取决于你是看数字还是看体感而到底用本地还是云端本质是一个成本、隐私和模型能力的三角权衡没有标准答案但有清晰的判断框架。1. 算力真相32G的Mac mini M6到底强在哪、弱在哪1.1 统一内存才是关键“显存”决定一切很多人第一次听说Mac能跑大模型时一脸懵苹果连独立显卡都没有凭什么跟N卡比答案不在显卡而在内存架构。Mac mini M6用的是统一内存CPU和GPU共用同一块32G物理内存没有独立显存和系统内存之间的拷贝开销。对跑大模型来说这块32G内存就是“显存”模型加载进来后GPU核心直接从这块内存里读权重做计算。这点很重要因为大模型推理的根本约束从来不是算力FLOPS而是内存容量和内存带宽。N卡那边一块RTX 4090有24G显存A100有80GH100更是80G起步但都是独立显存显存不够就得把模型搬到内存甚至硬盘那就废了。Mac mini M6的32G统一内存虽然在容量上比不上A100但比绝大多数消费级显卡的24G大而且内存模型让16寸MacBook Pro那套“48G内存跑70B量化”的玩法也能落在这台小主机上。1.2 内存带宽才是真正卡脖子的地方容量决定了你能不能把模型装进内存带宽决定了你每秒能生成几个词。这里有一个硬道理大模型文本生成是内存带宽密集型任务解码阶段每生成一个token都要把整个模型的权重从内存里扫一遍。估算公式很简单模型体积按字节算 参数量 × 每参数字节数解码速度理论上限 ≈ 内存带宽 ÷ 模型体积拿7B模型Int4量化来说体积大约3.5GB如果内存带宽是200GB/s理论极限约57 token/s。但这是纯搬运上限实际还要算上注意力计算、KV cache读写、系统调度、Metal算子开销通常打六折甚至对折。所以7B量化在这个带宽下跑25~30 token/s已经是很好的成绩了。The first time I tried it, I was disappointed? 不是这其实符合物理规律。关键在于Mac mini M6的定位。苹果的产品线很有意思Mac mini标准版用的是不带Pro、不带Max后缀的M6芯片内存带宽远低于MacBook Pro上的Pro/Max版本。以M4系列为例基础款M4的内存带宽只有约120GB/sPro版本就到了273GB/sMax版本更高。M6如果沿用这个分层逻辑32G的Mac mini M6内存带宽大概率处在100GB/s出头到两百之间。这意味着什么意味着网上那些“MacBook Pro Max跑70B模型秒出字”的演示跟你的Mac mini M6关系不大。你买的是低带宽那个版本跑大模型时同样的模型你的瓶颈会被放得更明显。我用这台机器跑7B量化模型实际解码速度比我另一台M4 Pro芯片的MacBook Pro低了差不多一半这一点当初是真没想到。1.3 30秒算明白你到底能跑多大模型拿32G统一内存算一笔账。首先你得知道macOS系统、桌面、后台进程大概要占用3到5G内存你能实际自由支配的大约27G左右。模型体积用这个表格一对照就清楚了模型规模FP16每参数2字节INT8每参数1字节INT4每参数0.5字节3B~6G~3G~1.5G7B~14G~7G~3.5G14B~28G~14G~7G32B~64G~32G~16G70B~140G~70G~35G32G内存跑7B FP16毫无压力跑14B FP16就比较极限模型就得占28G再加上KV cache和系统内存就爆了跑14B Int4很舒服跑32B Int4勉强能放下16G模型加部分KV cache但速度已经掉到让人难受的档位70B Int4也要35G以上32G基本没戏除非用mmap让系统换页到SSD硬撑那速度会跌到生不如死。还要注意一个很多人忽略的东西KV cache。上下文窗口越长KV cache占用越大。比如上下文从2K涨到8KKV cache可能从几百MB涨到好几个G。所以32G机器跑14B模型建议把上下文控制在8K以内这也直接关系到后面要讲的TPS。结论32G Mac mini M6的舒适区是3B到14B模型20B以上就台得做量化压榨超过32B基本是给这台机器找罪受。2. 实测TPS别信宣传数字自己动手测一轮2.1 我用什么工具、怎么测才算真实TPStokens per second是大模型本地部署的灵魂指标也是各路评测最喜欢注水的数字。我实际的测试环境很简单Mac mini M632G内存系统保持在基本空闲状态。工具链主要用的是Ollama和llama.cpp两条线。Ollama适合日常快速体验版本号后面加--verbose就能看到详尽的性能数据llama.cpp则更适合深挖底层参数比如--ctx-size、--threads、--mlock直接调Metal线程数和内存锁页。最关键的测量原则不能只测生成阶段。一个完整的推理过程由prefill处理提示词和decode逐字生成两部分组成。很多软件自带的测速指标只统计decode隐藏prefill的耗时算出来的数字自然会虚高。我打个比方你就懂了你去餐厅吃饭点单等餐的时间不算只算吃完一碗面用了几分钟那这个餐厅的“出餐速度”看着当然快。但真实体感是从坐下到吃完一共多久。聊天场景里你的提示词往往是几百字prefill可能要花一两秒甚至更久这个时间难道不算进TPS里所以我测的是另一种口径固定一个提示词让模型生成固定长度的内容用wall-time总耗时除以生成的token数。这才能反映真实会话体验。2.2 我实测的典型数据下面是我在Mac mini M6 32G上用Ollama默认配置跑出的参考数据供你对照我依然说明一点不同版本、不同温度、不同上下文长度下结果会有明显浮动。模型与量化内存占用峰值decode速度token/s真实会话体验含prefill备注Llama 3.2 3B Q4_K_M~2.5G35~4528~35轻量对话、写代码补全很丝滑Qwen2.5 7B Q4_K_M~5.5G16~2212~18综合能力均衡日常主力Qwen2.5 14B Q4_K_M~9.5G8~116~9中文质量好能感受到明显拖拽感DeepSeek-R1-Distill-Qwen-14B Q4~10G7~105~8推理类任务不错但思考过程占上下文Llama 3.1 8B Q8~10G12~159~12精度更高内存占用翻倍3B模型爽是真的爽但这属于练手玩具级别7B是这台机器的甜点档位速度能接受能力对多数轻任务够用14B开始你能明显感觉到每个字都是计算出来的聊天会有一点“憋字”感但配合较短的提示词当个后台小助手没问题。至于32B量化模型我也试过在缩减上下文到2K以内、使用Int4量化时decode掉到4~6 token/s几乎就是断断续续挤牙膏。偶尔跑一跑可以日常用不推荐。2.3 参数怎么调才能跑出好TPS真实TPS不是写死的同一个模型不同设定下天差地别。我调参后最明显的三个点是第一是上下文长度。默认4K上下文和拉到16K上下文KV cache占用差好几倍decode速度能差20%以上。对轻量任务建议ctx-size设在8K以内不要无脑开大。第二是提示词长度。同样一次请求100字的提示词和5000字的提示词首token耗时完全不同长文总结场景直接教你做人。第三是量化档位。Q4到Q8对速度影响相对小大约10%~20%但对内存占用影响是翻倍的所以32G机器建议优先保容量选Q4除非模型小到无所谓。还有一点亲身感触不要同时开着多个大模型进程Ollama默认会驻留模型在内存里你上一个模型没释放就加载下一个内存马上爆掉系统开始疯狂换页那时TPS会从20掉到2你会以为机器坏了。3. 端云决策本地跑还是调API我的判断标准3.1 本地部署赢在哪里先说结论本地部署不是“穷人的救赎”而是“高频、隐私敏感、网络受限场景的正确解”。最核心是隐私。我手里有些项目涉及内部文档分析、未公开代码片段、客户数据这些内容如果整段贴给云端API就存在数据出境和供应商政策风险。本地跑大模型数据始终留在自己的内存和SSD里这一点是决定性优势。你的代码、你的商业计划、你的聊天记录不经过任何第三方服务器。第二是成本。云端API是典型的按量计费你用一次付一次钱。个人高频使用、或者跑长上下文批量任务时token费用会滚雪球。Mac mini M6一次性投入硬件成本之后电费几乎可以忽略实测满载也就几十瓦。我算过一笔账如果每天调用云端API跑200次中长文本任务一个月花销轻松超过这台Mac mini的月折旧成本。当然反过来如果你一天只调几次那本地部署纯属浪费。第三是可控与离线。本地模型不受服务商限流、接口变更、服务器故障影响断网也能用。我出差坐高铁时离线跑本地模型处理会议纪要周围人都在连线失败的时候这边还是照常干活。3.2 云端的优势也不能无视该承认得承认本地部署的模型天花板是明摆着的。32G的Mac mini M6最多只能跑好14B级别而云端有72B、上百B的MoE模型有更强的代码能力、数学推理能力和多模态支持。你要让本地14B模型写出一个干净的生产级函数也许可以但让它做复杂架构设计、长程推理还是差点意思。其次是并发。本地单机推理本质是单副本服务多个请求并发时会排队每个请求的TPS都会下降。团队五六个人同时用体验就会劣化。云端API天然是分布式的能扛高并发。我在团队协作场景里深有体会自己玩本地没问题一开周会同步用大家就都开始骂娘了。再一个就是维护成本。本地部署不仅要选模型、配量化还要自己管上下文窗口、OOM、版本升级。云端API一个url就完了迭代不用你操心。对很多非技术出身的使用者来说这一步之差其实是天壤之别。3.3 我的端云决策矩阵我总结了一张决策表基本覆盖了90%的使用场景场景推荐方案理由日常个人写作、脑暴、摘要本地7B~14B够用、免费、隐私代码补全/解释/重构本地7B~14B或云端代码模型本地胜在隐私云端胜在正确率长论文/书籍级长文档总结云端大模型本地上下文窗口有限prefill太慢团队批量数据处理云端API队列并发高、吞吐稳涉密/私有数据任何任务本地部署强制云端根本不在选项里低频率高质量写作云端便宜且能力强大模型微调测试本地做LoRA云端做全参32G只够轻量微调7B重活交给云GPU这里单独聊两句热词“大模型微调”和“微调实战”。32G的Mac mini M6能不能微调能但只能做LoRA。7B模型用QLoRA微调int4基座加上lora权重大约占6~10G内存在Mac上确实能跑通。我有一次在本地微调了一个7B代码风格的LoRA适配器整整跑了一夜效果中规中矩。但如果你要微调14B甚至更大模型或者想全参数微调本地基本不可行这时候必须把训练丢到云端GPU上去。所以我的端云决策里专门有一条推理可以本地训练大概率在云端混合模式才是常态。再说“算力约束下提升大语言模型能力的资源配置建模”听起来复杂落到实操就是一句话在有限算力预算下优先把内存带宽喂给合适的模型而不是盲目选大模型。很多人以为本地跑大模型就是“越大越好”实际上模型大到速度不可用反而不如小一号模型的实用收益高。这就是我在端云决策里反复强调的算力约束下最优解不是性能最大化而是性价比最大化。3.4 什么时候彻底放弃本地我列几个“别硬上”的警号任务必须依赖超长上下文比如一次读完整本书本地8K/16K上下文撑不住任务需要高并发服务比如面向几十个用户的机器人单机处理不过来任务对模型质量和稳定性要求极高比如生产级代码生成本地小模型容易翻车。这几种场景就别纠结32G Mac mini了。老老实实调API省心省力而且综合成本反而更低。4. 常见问题与排查心得4.1 常见问题速查表我在使用中收集了不少典型问题直接整理成一张表现象可能原因排查办法加载模型提示内存不足模型体积KV cache超了可用内存换更小模型或降低量化精度缩短上下文速度突然暴跌到1~2 token/s系统内存不足触发swap换页检查活动监视器释放内存确保宿主模型进程只留一个每次首字迟迟不出来提示词太长prefill耗时长精简提示词、任务拆分或换更大带宽机器/云端输出逻辑乱、质量差量化程度过高或模型太小7B以下别期望太高优先用Q4_K_M档位温度高导致降频Mac mini被动散热M6满载会降频放通风处长期任务注意环境温度Ollama测速比llama.cpp慢Ollama封装层和固定batch大小影响追求极限性能可直接用llama.cpp跑llama-server4.2 几条实操心得踩过的坑就别再踩了第一重视SSD速度。模型加载、冷启动阶段对SSD敏感别把模型放在外接机械硬盘或网络盘里。我一开始图省事把模型放在外接移动硬盘上导致启动速度慢得离谱后来挪到内置SSD冷启动时间从一分多钟降到十几秒。第二学会set model的释放。Ollama默认会保持模型驻留内存10分钟左右你跑完一个大模型不释放下一个模型进来很容易OOM。手动执行释放或用Keep Alive参数控制驻留时长能省一大笔内存压力。第三用llama.cpp而非Ollama压榨性能的情况下记得加参数--no-mmap配合--mlock。把模型权重锁在物理内存里防止部分换页到磁盘解码速度那叫一个扎实。第四如果你的机器突然变慢别急着怪模型——先看是不是后台在跑Time Machine备份或Spotlight索引。我有一次测速慢得离谱排查半天结果是Spotlight正在给一堆文件建立索引CPU和磁盘双双被打满。第五量化选择经验Q4_K_M对多数场景质量损失可控Q5_K_M质量更稳但内存占用多20%左右。如果你追求极致速度可以试Q2/Q3但质量会明显下降生成出来的句子可能像喝醉了。最后分享一个真实体会我在Mac mini M6上跑大模型最常用的组合是14B模型处理高质量中文任务、7B模型处理日常对话、小模型的轻任务跑3B。端云决策方面我的原则是“能本地就本地本地明显吃力就毫不犹豫用云端”。这台机器帮我把日常60%~70%的LLM诉求消化在了本地剩下30%需要大模型深度推理的场景我交给云端——既不心疼token费也不牺牲质量。32G的Mac mini M6不是一台“神级”算力服务器但它是一台非常合格的“端侧推理终端”。摆正它的位置你就知道怎么把它的每一滴带宽都榨干。
Mac mini M6 32G大模型实测：算力、TPS与端云决策全解析
最近总有人问我同一句话32G内存的Mac mini M6跑大模型到底行不行这里的“行”往往包含三层意思能不能装上跑起来每秒能蹦几个字以及有了它之后还要不要买云端API。说白了就是三个字——算力、TPS、端云决策。我手上这台32G的Mac mini M6已经用了两个多月折腾过本地部署、量化、LoRA微调也接了不少项目的端云混合调用。今天不聊PPT参数直接聊我实测下来的算力真相、真实TPS以及我如何做端云决策。先给结论32G的Mac mini M6完全能跑大模型7B到14B量级体验不错32B量化后属于“能跑但你要有耐心”70B就别指望了至于快不快取决于你是看数字还是看体感而到底用本地还是云端本质是一个成本、隐私和模型能力的三角权衡没有标准答案但有清晰的判断框架。1. 算力真相32G的Mac mini M6到底强在哪、弱在哪1.1 统一内存才是关键“显存”决定一切很多人第一次听说Mac能跑大模型时一脸懵苹果连独立显卡都没有凭什么跟N卡比答案不在显卡而在内存架构。Mac mini M6用的是统一内存CPU和GPU共用同一块32G物理内存没有独立显存和系统内存之间的拷贝开销。对跑大模型来说这块32G内存就是“显存”模型加载进来后GPU核心直接从这块内存里读权重做计算。这点很重要因为大模型推理的根本约束从来不是算力FLOPS而是内存容量和内存带宽。N卡那边一块RTX 4090有24G显存A100有80GH100更是80G起步但都是独立显存显存不够就得把模型搬到内存甚至硬盘那就废了。Mac mini M6的32G统一内存虽然在容量上比不上A100但比绝大多数消费级显卡的24G大而且内存模型让16寸MacBook Pro那套“48G内存跑70B量化”的玩法也能落在这台小主机上。1.2 内存带宽才是真正卡脖子的地方容量决定了你能不能把模型装进内存带宽决定了你每秒能生成几个词。这里有一个硬道理大模型文本生成是内存带宽密集型任务解码阶段每生成一个token都要把整个模型的权重从内存里扫一遍。估算公式很简单模型体积按字节算 参数量 × 每参数字节数解码速度理论上限 ≈ 内存带宽 ÷ 模型体积拿7B模型Int4量化来说体积大约3.5GB如果内存带宽是200GB/s理论极限约57 token/s。但这是纯搬运上限实际还要算上注意力计算、KV cache读写、系统调度、Metal算子开销通常打六折甚至对折。所以7B量化在这个带宽下跑25~30 token/s已经是很好的成绩了。The first time I tried it, I was disappointed? 不是这其实符合物理规律。关键在于Mac mini M6的定位。苹果的产品线很有意思Mac mini标准版用的是不带Pro、不带Max后缀的M6芯片内存带宽远低于MacBook Pro上的Pro/Max版本。以M4系列为例基础款M4的内存带宽只有约120GB/sPro版本就到了273GB/sMax版本更高。M6如果沿用这个分层逻辑32G的Mac mini M6内存带宽大概率处在100GB/s出头到两百之间。这意味着什么意味着网上那些“MacBook Pro Max跑70B模型秒出字”的演示跟你的Mac mini M6关系不大。你买的是低带宽那个版本跑大模型时同样的模型你的瓶颈会被放得更明显。我用这台机器跑7B量化模型实际解码速度比我另一台M4 Pro芯片的MacBook Pro低了差不多一半这一点当初是真没想到。1.3 30秒算明白你到底能跑多大模型拿32G统一内存算一笔账。首先你得知道macOS系统、桌面、后台进程大概要占用3到5G内存你能实际自由支配的大约27G左右。模型体积用这个表格一对照就清楚了模型规模FP16每参数2字节INT8每参数1字节INT4每参数0.5字节3B~6G~3G~1.5G7B~14G~7G~3.5G14B~28G~14G~7G32B~64G~32G~16G70B~140G~70G~35G32G内存跑7B FP16毫无压力跑14B FP16就比较极限模型就得占28G再加上KV cache和系统内存就爆了跑14B Int4很舒服跑32B Int4勉强能放下16G模型加部分KV cache但速度已经掉到让人难受的档位70B Int4也要35G以上32G基本没戏除非用mmap让系统换页到SSD硬撑那速度会跌到生不如死。还要注意一个很多人忽略的东西KV cache。上下文窗口越长KV cache占用越大。比如上下文从2K涨到8KKV cache可能从几百MB涨到好几个G。所以32G机器跑14B模型建议把上下文控制在8K以内这也直接关系到后面要讲的TPS。结论32G Mac mini M6的舒适区是3B到14B模型20B以上就台得做量化压榨超过32B基本是给这台机器找罪受。2. 实测TPS别信宣传数字自己动手测一轮2.1 我用什么工具、怎么测才算真实TPStokens per second是大模型本地部署的灵魂指标也是各路评测最喜欢注水的数字。我实际的测试环境很简单Mac mini M632G内存系统保持在基本空闲状态。工具链主要用的是Ollama和llama.cpp两条线。Ollama适合日常快速体验版本号后面加--verbose就能看到详尽的性能数据llama.cpp则更适合深挖底层参数比如--ctx-size、--threads、--mlock直接调Metal线程数和内存锁页。最关键的测量原则不能只测生成阶段。一个完整的推理过程由prefill处理提示词和decode逐字生成两部分组成。很多软件自带的测速指标只统计decode隐藏prefill的耗时算出来的数字自然会虚高。我打个比方你就懂了你去餐厅吃饭点单等餐的时间不算只算吃完一碗面用了几分钟那这个餐厅的“出餐速度”看着当然快。但真实体感是从坐下到吃完一共多久。聊天场景里你的提示词往往是几百字prefill可能要花一两秒甚至更久这个时间难道不算进TPS里所以我测的是另一种口径固定一个提示词让模型生成固定长度的内容用wall-time总耗时除以生成的token数。这才能反映真实会话体验。2.2 我实测的典型数据下面是我在Mac mini M6 32G上用Ollama默认配置跑出的参考数据供你对照我依然说明一点不同版本、不同温度、不同上下文长度下结果会有明显浮动。模型与量化内存占用峰值decode速度token/s真实会话体验含prefill备注Llama 3.2 3B Q4_K_M~2.5G35~4528~35轻量对话、写代码补全很丝滑Qwen2.5 7B Q4_K_M~5.5G16~2212~18综合能力均衡日常主力Qwen2.5 14B Q4_K_M~9.5G8~116~9中文质量好能感受到明显拖拽感DeepSeek-R1-Distill-Qwen-14B Q4~10G7~105~8推理类任务不错但思考过程占上下文Llama 3.1 8B Q8~10G12~159~12精度更高内存占用翻倍3B模型爽是真的爽但这属于练手玩具级别7B是这台机器的甜点档位速度能接受能力对多数轻任务够用14B开始你能明显感觉到每个字都是计算出来的聊天会有一点“憋字”感但配合较短的提示词当个后台小助手没问题。至于32B量化模型我也试过在缩减上下文到2K以内、使用Int4量化时decode掉到4~6 token/s几乎就是断断续续挤牙膏。偶尔跑一跑可以日常用不推荐。2.3 参数怎么调才能跑出好TPS真实TPS不是写死的同一个模型不同设定下天差地别。我调参后最明显的三个点是第一是上下文长度。默认4K上下文和拉到16K上下文KV cache占用差好几倍decode速度能差20%以上。对轻量任务建议ctx-size设在8K以内不要无脑开大。第二是提示词长度。同样一次请求100字的提示词和5000字的提示词首token耗时完全不同长文总结场景直接教你做人。第三是量化档位。Q4到Q8对速度影响相对小大约10%~20%但对内存占用影响是翻倍的所以32G机器建议优先保容量选Q4除非模型小到无所谓。还有一点亲身感触不要同时开着多个大模型进程Ollama默认会驻留模型在内存里你上一个模型没释放就加载下一个内存马上爆掉系统开始疯狂换页那时TPS会从20掉到2你会以为机器坏了。3. 端云决策本地跑还是调API我的判断标准3.1 本地部署赢在哪里先说结论本地部署不是“穷人的救赎”而是“高频、隐私敏感、网络受限场景的正确解”。最核心是隐私。我手里有些项目涉及内部文档分析、未公开代码片段、客户数据这些内容如果整段贴给云端API就存在数据出境和供应商政策风险。本地跑大模型数据始终留在自己的内存和SSD里这一点是决定性优势。你的代码、你的商业计划、你的聊天记录不经过任何第三方服务器。第二是成本。云端API是典型的按量计费你用一次付一次钱。个人高频使用、或者跑长上下文批量任务时token费用会滚雪球。Mac mini M6一次性投入硬件成本之后电费几乎可以忽略实测满载也就几十瓦。我算过一笔账如果每天调用云端API跑200次中长文本任务一个月花销轻松超过这台Mac mini的月折旧成本。当然反过来如果你一天只调几次那本地部署纯属浪费。第三是可控与离线。本地模型不受服务商限流、接口变更、服务器故障影响断网也能用。我出差坐高铁时离线跑本地模型处理会议纪要周围人都在连线失败的时候这边还是照常干活。3.2 云端的优势也不能无视该承认得承认本地部署的模型天花板是明摆着的。32G的Mac mini M6最多只能跑好14B级别而云端有72B、上百B的MoE模型有更强的代码能力、数学推理能力和多模态支持。你要让本地14B模型写出一个干净的生产级函数也许可以但让它做复杂架构设计、长程推理还是差点意思。其次是并发。本地单机推理本质是单副本服务多个请求并发时会排队每个请求的TPS都会下降。团队五六个人同时用体验就会劣化。云端API天然是分布式的能扛高并发。我在团队协作场景里深有体会自己玩本地没问题一开周会同步用大家就都开始骂娘了。再一个就是维护成本。本地部署不仅要选模型、配量化还要自己管上下文窗口、OOM、版本升级。云端API一个url就完了迭代不用你操心。对很多非技术出身的使用者来说这一步之差其实是天壤之别。3.3 我的端云决策矩阵我总结了一张决策表基本覆盖了90%的使用场景场景推荐方案理由日常个人写作、脑暴、摘要本地7B~14B够用、免费、隐私代码补全/解释/重构本地7B~14B或云端代码模型本地胜在隐私云端胜在正确率长论文/书籍级长文档总结云端大模型本地上下文窗口有限prefill太慢团队批量数据处理云端API队列并发高、吞吐稳涉密/私有数据任何任务本地部署强制云端根本不在选项里低频率高质量写作云端便宜且能力强大模型微调测试本地做LoRA云端做全参32G只够轻量微调7B重活交给云GPU这里单独聊两句热词“大模型微调”和“微调实战”。32G的Mac mini M6能不能微调能但只能做LoRA。7B模型用QLoRA微调int4基座加上lora权重大约占6~10G内存在Mac上确实能跑通。我有一次在本地微调了一个7B代码风格的LoRA适配器整整跑了一夜效果中规中矩。但如果你要微调14B甚至更大模型或者想全参数微调本地基本不可行这时候必须把训练丢到云端GPU上去。所以我的端云决策里专门有一条推理可以本地训练大概率在云端混合模式才是常态。再说“算力约束下提升大语言模型能力的资源配置建模”听起来复杂落到实操就是一句话在有限算力预算下优先把内存带宽喂给合适的模型而不是盲目选大模型。很多人以为本地跑大模型就是“越大越好”实际上模型大到速度不可用反而不如小一号模型的实用收益高。这就是我在端云决策里反复强调的算力约束下最优解不是性能最大化而是性价比最大化。3.4 什么时候彻底放弃本地我列几个“别硬上”的警号任务必须依赖超长上下文比如一次读完整本书本地8K/16K上下文撑不住任务需要高并发服务比如面向几十个用户的机器人单机处理不过来任务对模型质量和稳定性要求极高比如生产级代码生成本地小模型容易翻车。这几种场景就别纠结32G Mac mini了。老老实实调API省心省力而且综合成本反而更低。4. 常见问题与排查心得4.1 常见问题速查表我在使用中收集了不少典型问题直接整理成一张表现象可能原因排查办法加载模型提示内存不足模型体积KV cache超了可用内存换更小模型或降低量化精度缩短上下文速度突然暴跌到1~2 token/s系统内存不足触发swap换页检查活动监视器释放内存确保宿主模型进程只留一个每次首字迟迟不出来提示词太长prefill耗时长精简提示词、任务拆分或换更大带宽机器/云端输出逻辑乱、质量差量化程度过高或模型太小7B以下别期望太高优先用Q4_K_M档位温度高导致降频Mac mini被动散热M6满载会降频放通风处长期任务注意环境温度Ollama测速比llama.cpp慢Ollama封装层和固定batch大小影响追求极限性能可直接用llama.cpp跑llama-server4.2 几条实操心得踩过的坑就别再踩了第一重视SSD速度。模型加载、冷启动阶段对SSD敏感别把模型放在外接机械硬盘或网络盘里。我一开始图省事把模型放在外接移动硬盘上导致启动速度慢得离谱后来挪到内置SSD冷启动时间从一分多钟降到十几秒。第二学会set model的释放。Ollama默认会保持模型驻留内存10分钟左右你跑完一个大模型不释放下一个模型进来很容易OOM。手动执行释放或用Keep Alive参数控制驻留时长能省一大笔内存压力。第三用llama.cpp而非Ollama压榨性能的情况下记得加参数--no-mmap配合--mlock。把模型权重锁在物理内存里防止部分换页到磁盘解码速度那叫一个扎实。第四如果你的机器突然变慢别急着怪模型——先看是不是后台在跑Time Machine备份或Spotlight索引。我有一次测速慢得离谱排查半天结果是Spotlight正在给一堆文件建立索引CPU和磁盘双双被打满。第五量化选择经验Q4_K_M对多数场景质量损失可控Q5_K_M质量更稳但内存占用多20%左右。如果你追求极致速度可以试Q2/Q3但质量会明显下降生成出来的句子可能像喝醉了。最后分享一个真实体会我在Mac mini M6上跑大模型最常用的组合是14B模型处理高质量中文任务、7B模型处理日常对话、小模型的轻任务跑3B。端云决策方面我的原则是“能本地就本地本地明显吃力就毫不犹豫用云端”。这台机器帮我把日常60%~70%的LLM诉求消化在了本地剩下30%需要大模型深度推理的场景我交给云端——既不心疼token费也不牺牲质量。32G的Mac mini M6不是一台“神级”算力服务器但它是一台非常合格的“端侧推理终端”。摆正它的位置你就知道怎么把它的每一滴带宽都榨干。
