Mac 本地大模型务实指南：能跑什么、跑得怎样、什么时候别折腾

先说结论：在 Apple Silicon 上跑本地大模型，内存容量决定上限，内存带宽决定体验。M4 基础款 120GB/s、M4 Pro 273GB/s、M4 Max 410-546GB/s，统一内存架构让 GPU 可以直接吃系统内存，这是 Mac 跑 LLM 最大的底气。但代价也直白：你买机器时没加内存，后期没有任何补救办法；而带宽买低了，同样大小的模型速度直接差一倍以上。

这篇文章不吹"本地替代 ChatGPT"的牛皮。我手上有 M4 Pro 24GB、M4 Max 48GB 和一台 M3 Max 96GB 工作室机器，过去半年几乎所有主流开源模型都实跑过。下面按"钱花出去能得到什么"的顺序讲。

一、内存档位决策表：能跑什么、跑得怎样

规则先讲清楚：macOS 默认只允许 GPU 用约 65-75% 的系统内存（Metal 的 recommendedMaxWorkingSetSize），剩下的要留给系统、浏览器和你那 40 个 Chrome 标签。所以可用显存 ≈ 总内存 × 0.7，再扣掉 2-3GB 的桌面开销。

解释一下"tok/s 多少算够用"：人类阅读速度大约每秒 5-10 个英文单词，对应约 8-15 tok/s。所以15 tok/s 以上生成比阅读快，体验流畅；8-15 tok/s 是"看着它写"的及格线；5 tok/s 以下你只能切出去干别的等它写完。这就是为什么表里 32B q4 的 8-11 tok/s 我标为"质的台阶"——它是本地能舒适聊天的最大模型，而 70B 掉到 4 tok/s 就跨过了"能用"和"能跑"的分界线。

几点实测细节：

1. 表中速度基于 M4 系内存带宽（Pro 约 273GB/s，Max 约 410GB/s+）的实测区间。Tok/s 和带宽几乎线性相关，所以 Max 跑 14B 能到 22-28，而 M4 基础款（120GB/s）跑同样模型会掉到 12-16。
2. Prompt 处理（预填充）比生成快 5-10 倍，但首次加载模型要 3-10 秒，长上下文 KV cache 会额外吃内存——14B 模型开 32K context 时 KV cache 能再吃 2-4GB。
3. 24GB 档跑 14B 时如果同时开 Xcode + 浏览器，会开始 swap，tok/s 直接腰斩。这就是表里"约 15-20"的下限来源。
4. 想自己验证表里的数字很简单：ollama run 之后随便发一个长问题，回复结束后终端会打印 eval rate: XX.XX tokens/s，那就是本机真实生成速度。每个模型、每台机器都值得亲手跑一遍，别信任何人的表格包括我这张。

二、量化等级讲透：体积、质量、怎么选

GGUF 的量化命名看着乱，其实规律就一条：位数越低，体积越小，质量越差。背后的原理一句话：把 fp16 的 16 位浮点权重用更少的位数近似表示，q4_K_M 的 "K" 表示分块量化（block-wise，每 128 或 256 个权重共享一个缩放系数），"M" 表示 medium，在同位数里选了偏质量的混合策略——所以 q4_K_M 比老的 q4_0 质量明显好，体积只大一点，这也是为什么 GGUF 时代 q4_0 已经被淘汰。在 Hugging Face 的模型页上你还会看到 IQ4_XS、Q5_K_S 这类变种，记住"S/M/L"后缀代表同位数下的小/中/大体积取舍，日常不用管，盯住 q4_K_M 和 q8_0 两个锚点就够了。

以 Llama 3.1 8B 为例（fp16 约 16GB）：

另一组参考锚点：7B 模型 fp16 约 14GB → q8_0 约 7.2GB → q4_K_M 约 4.1GB；14B 则 fp16 约 28GB → q8 约 15GB → q4_K_M 约 9GB。记住这两个锚点，任何新模型看到参数规模就能心算出大概要多少内存。

简化记忆：q8 约为 fp16 的一半，q4_K_M 约为 25-30%。8B 模型 fp16 16GB → q8 8.5GB → q4_K_M 4.9GB，这个比例在所有规模的模型上都成立，可以拿来做内存估算。

选择策略：

• 7B/8B 级别：内存够就 q8_0。这个规模模型本身能力有限，别让量化再砍一刀。24GB 机器跑 8B q8 才 8.5GB，毫无压力。
• 14B 级别：q4_K_M 是甜点，q6_K 是追求。9GB vs 11.5GB，24GB 档两者都跑得动，但 q6_K 留给系统的余量更紧。
• 32B 级别：q4_K_M（约 20GB）是分水岭——48GB 机器舒适，32GB 机器得降 q3_K_M（约 15GB），代价是质量明显下降。
• 70B 级别：只有 q2_K 能塞进 64GB，而 q2 对 70B 的伤害比对小模型更大（LLM.int8() 论文里的涌现异常值在小模型上更集中，但 70B q2 实测长文连贯性崩得很快）。结论：70B 要么 q4 + 96GB 起步，要么不跑。

三、三个场景的实测结论

先交代测试方法，免得数字看起来是拍脑袋：所有写作和编码测试都在 M4 Pro 24GB 上跑，Ollama 默认参数（仅 temperature 按场景调），模型均为 q4_K_M 版本，每轮测试前重启服务避免 KV cache 残留。吞吐数字取三轮生成的平均值，场景覆盖中英双语。

写作：qwen2.5:14b 明显好于 7b，中文差距比英文更大

我拿同一段产品文案任务（"给降噪耳机写 200 字小红书文案"）跑了五轮盲测：

• qwen2.5:7b-instruct-q4_K_M：英文段落实测可用率约七成，结构完整但用词模板化（"game-changer"出现三次）。中文段落问题明显：爱堆排比句，"不仅仅是……更是……"出现频率高得反常，且 200 字要求经常写成 350 字，指令跟随弱。
• qwen2.5:14b-instruct-q4_K_M：中文质量跨了一个台阶，排比病基本消失，字数控制五轮全对。英文差距反而小——7B 在英文语料上的训练充分，量化后还能撑。

结论：写作任务至少 14B，中文场景下 14B 与 7B 的差距比英文大一档。 24GB 档的机器，写作主力就是 qwen2.5:14b-q4_K_M，没有第二个答案。还有一个反直觉的发现：温度参数在本地小模型上比云端更敏感，写作场景把 temperature 从默认 0.8 降到 0.6，排比病和跑题率都会明显改善，这是不花一分钱的质量提升。

编码：coder:7b 够用，32b 真香但要算账

• qwen2.5-coder:7b-q4_K_M（4.7GB）：补全和单函数生成相当可靠，HumanEval 级别的题目通过率体感在七成以上。接 Continue.dev 或 Cline 做 IDE 补全，延迟低（25+ tok/s），日常写业务代码完全够。短板在"需要记住框架细节"的场景：让它写一个完整的 FastAPI 路由，偶尔会把 Depends 的用法编出一个不存在的参数——7B 对 API 记忆的可靠度就是这样，生成的代码必须跑一遍再信。
• qwen2.5-coder:14b-q4_K_M（9GB）：跨文件重构、理解上下文里的接口定义，明显比 7B 稳。24GB 档的最佳编码配置。我的日常组合就是：IDE 里用 7B 做行内补全（快），重型生成任务切 14B（稳），两个模型加起来才 14GB，共存无压力。
• qwen2.5-coder:32b-q4_K_M（19.9GB）：质量接近云端二线水平，复杂算法题和架构级重构都能打。但在 32GB 机器上你只能跑 q3_K_M，质量掉回 14B q4 附近，还多占了 6GB——这就是 32GB 用户的权衡：32B q3 和 14B q6 质量相当，后者更快更省，除非上 48GB，否则别硬上 32B。
• 还有一个被低估的用法：用本地 coder 模型做离线代码审查。把不想上传的私有代码喂给 14B/32B，让它找 bug、写单测、生成文档——这是本地模型在编码场景里最不可替代的价值，因为代码隐私恰恰是很多人不敢用云端 API 的原因。

推理：deepseek-r1 蒸馏版，名字带 R1 但不是 R1

这一点必须泼冷水。Ollama 上的 deepseek-r1:7b / 14b / 32b 全部是蒸馏版——用 R1 生成的推理数据微调 Qwen2.5 或 Llama 得到的，不是那个 671B 的 R1 本体。

实测水平：

• deepseek-r1:14b-qwen-distill-q4_K_M：数学竞赛题（AIME 风格）能做对三到四成，比同尺寸普通模型强一截，思维链确实在"思考"。但简单问题也会先输出 500 token 的思考再回答，日常问答体验啰嗦。
• deepseek-r1:32b-distill：这是 Mac 上"本地推理"的实际天花板，48GB 机器跑 q4 能到 9-11 tok/s，多步数学和逻辑题的正确率明显又上一档。但同样别神化——它偶尔会在思维链里把早期算对的东西改错，一个简单的两位数乘法都能在思考过程中翻车。
• deepseek-r1:7b-distill：推理格式学了个壳，思维链经常自我重复、原地打转，最后答案照样错。7B 蒸馏不推荐。
• 真实定位：蒸馏版是"同尺寸里推理特化"，不是"小号 R1"。需要真 R1 级别的推理，671B 的 q4 也要 400GB+ 内存，Mac 上想都别想（M3 Ultra 512GB 另说，那是另一个价格宇宙）。
• 使用建议：把蒸馏版当"专项工具"而非日常助手。数学题、逻辑谜题开它；写邮件、改文案别用它，思维链会先浪费你 30 秒。另外它的 KV cache 增长比普通模型快得多，一轮对话轻松吃掉几千 token 的上下文，14B 蒸馏版开 32K context 时内存压力堪比 32B 普通模型。

四、Ollama 之外的选项

Ollama 是默认答案，但不是唯一答案：

我的实际用法：Ollama 跑服务和 API，LM Studio 用来试新模型和调参，定型后再回 Ollama。两头的模型库分开存，NAS 或者外置盘上留一份 GGUF 备份。

关于 MLX 再多说两句，因为它对 Mac 用户是真有优势：llama.cpp 走的是通用 GPU 计算路径，而 MLX 是 Apple 为自家芯片写的框架，内存布局针对统一内存做过优化。实测同一个 14B 模型，MLX 4bit 版本在 M4 Pro 上比 Ollama 的 q4_K_M 快 15% 左右，预填充（吃长 prompt）差距能到 25%。代价是 Hugging Face 上要专门找 "mlx-community" 前缀的模型，量化档位没有 GGUF 那么全。如果你是 Python 技术栈、想在脚本里直接 import 调用而不起服务，mlx-lm 是目前 Mac 上最优雅的路径。

五、上下文长度：最容易被忽略的隐形内存杀手

很多人按"模型文件多大"算内存，然后在长对话里翻车——因为他们忘了 KV cache。模型生成每个 token 都要记住之前所有 token 的注意力中间结果，这部分内存随上下文长度线性增长。

实测量级：7B 模型开 32K context，KV cache 约 2GB；14B 约 3-4GB；32B 能到 8GB+。Ollama 默认只开 4K context（很保守），LM Studio 默认 4-8K。一旦你把 context 调到 32K 去分析长文档，24GB 机器上 14B 模型从"从容"直接变成"swap 边缘"。

务实建议：

• 日常聊天和代码补全，4-8K context 足够，别开大。
• 真需要长文档分析，先问自己：本地 14B 对 30 页文档的理解力，真的比把文档切片后喂给云端强模型好？多数情况下答案是否定的。长上下文恰恰是本地模型最弱的战场，小模型的长文注意力质量本来就差，别为它牺牲内存。
• RAG（检索增强）才是本地长文档的正解：文档切块、embedding 存向量库、只把相关段落塞进 4K context。embedding 模型（如 nomic-embed-text）才 274MB，随便跑。

六、功耗与散热：笔记本用户的现实

Apple Silicon 跑 LLM 的功耗比想象中温和，但有几个硬约束：

• M4 基础款 GPU 满载约 25-40W，M4 Pro 30-50W，M4 Max 能到 60W+。LLM 推理是内存带宽密集型，GPU 计算单元没跑满，实际功耗比游戏低。作为对照：同样跑 14B 模型，MacBook Pro 整机功耗约 45W，而一张 RTX 4090 单独就能吃 300W+。如果按一天推理 8 小时、电费每度 1 元算，Mac 一个月的 LLM 电费大约 10 块钱——功耗从来不是 Mac 跑本地模型的成本项，时间才是。
• 笔记本长期推理必须插电。电池模式下 macOS 会限制持续性能，我实测 MacBook Pro 14" M4 Pro 电池模式连续推理 10 分钟后 tok/s 掉约 15%。
• 散热决定满速时长。MacBook Air 无风扇，14B 模型连续生成 5 分钟后开始降频，tok/s 从 18 掉到 14 左右；MacBook Pro 和 Mac Studio 有主动散热，可以一直满速。想 7×24 挂机跑推理，买 Studio 或者 mini，别指望 Air。
• 内存带宽共享：推理时如果同时做视频剪辑或虚拟机，两边都会变慢，LLM 会饿死在带宽上。
• 磁盘 I/O 也值得一提：32B 模型 20GB，从 SSD 加载要 5-15 秒，所以别频繁切换模型。挑两三个主力模型常驻，比换来换去省心得多。

七、什么时候就该放弃本地，老老实实调 API

折腾精神可贵，但边界要清醒：

1. 7B 以下模型日常胡言乱语。事实性问答、需要准确数字的任务（"这个库的最新版本号""这条法规的具体条款"），小模型幻觉率高到不可用，只能当润色和改写工具。
2. 14B 以下推理幻觉多。多步逻辑、复杂数学题，本地小模型的错误是"自信地错"，没有人工复核不能进生产。
3. 70B 全能跑但 4 tok/s 没法用。96GB 机器上 llama3.3:70b-q4_K_M 实测 3-5 tok/s，一句话要等十几秒，只能离线跑批（比如夜间批量打标），交互场景彻底没戏。
4. 具体边界：任务涉及最新事实、精确引用、复杂多跳推理、超过 8K 上下文的代码库分析、多模态（看图、读 PDF 排版）、以及任何"错了要赔钱"的场景——直接调 GPT-5 / Claude / DeepSeek API，一次调用几分钱，别跟自己的电费和时间过不去。还有个隐形成本常被忽略：本地模型答错一次，你要么重跑要么返工，云端强模型一次答对，综合时间成本反而更低。

一个自测清单，写文档前先跑一遍再决定走不走本地：

• 任务里有没有"必须准确的实体"（版本号、人名、法条、价格）？有 → 云端 + 联网。
• 输出错了会不会造成返工或误导他人？会 → 云端强模型，或者本地生成后必过人工审。
• 是不是反复调用的流水线一环（比如每天批处理 500 篇摘要）？是 → 本地，零边际成本优势碾压。
• 数据能不能离开这台机器？不能 → 本地是唯一选项，此时哪怕 7B 也比"不能用云"强，但必须加人工复核。

本地模型的真实价值在三件事：隐私（数据不出机）、离线可用、无限调用不心疼。写作草稿、代码补全、文档摘要、敏感数据处理——这些场景本地 14B 完全胜任，且零边际成本。拿摘要场景算笔账：一篇 3000 字的中文文章摘要，本地 14B 生成约 15 秒，成本为零；云端 API 一次约几分钱。一天十篇以内云端无所谓，但如果你要处理整个笔记库的几千篇历史文档，本地就是唯一务实的选择。

八、最小入门方案（10 分钟跑起来）

# 1. 安装（Apple Silicon Mac，需先装 Homebrew）
brew install ollama

# 2. 启动服务（装完后 ollama serve 会自动后台运行，或手动执行）
ollama serve

# 3. 拉取模型——24GB+ 用户直接上这个，16GB 换 qwen2.5:3b
ollama pull qwen2.5:7b-instruct-q4_K_M

# 4. 跑起来聊天
ollama run qwen2.5:7b-instruct-q4_K_M

集成到自己的脚本，Ollama 提供 OpenAI 兼容 API，curl 一行：

curl http://localhost:11434/api/generate -d '{
  "model": "qwen2.5:7b-instruct-q4_K_M",
  "prompt": "用一句话解释什么是量化",
  "stream": false
}'

Python 侧走 OpenAI SDK 无缝切换：

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",  # Ollama 的 OpenAI 兼容端点
    api_key="ollama",                       # 本地不需要真实 key，占位即可
)

resp = client.chat.completions.create(
    model="qwen2.5:7b-instruct-q4_K_M",
    messages=[{"role": "user", "content": "把这段话改得更口语化：……"}],
    temperature=0.7,
)
print(resp.choices[0].message.content)

这套代码和调云端 API 完全一样——意味着你可以写一个开关，隐私任务走本地，重任务走云端，这是我认为 Mac 本地大模型最务实的终局形态。再补一个实用细节：Ollama 服务默认只监听本机 11434 端口，想让局域网里其他设备（比如 iPad 或另一台电脑）调用，设环境变量 OLLAMA_HOST=0.0.0.0 再启动即可——但注意这等于在局域网里开了一个无鉴权 API，家里网络无所谓，公共网络别这么干。

写在最后

如果只有一句话：24GB 是甜点，qwen2.5:14b-q4_K_M 是默认模型，Ollama 是默认工具，q4_K_M 是默认量化。还没买机器的话，我的购机建议是：预算内内存优先于芯片档位——M4 Pro 48GB 在 LLM 场景下比 M4 Max 36GB 实用得多，因为"装不装得下"是一票否决，"跑得快一点"只是体验差异。

回头看这半年的折腾，最大的收获不是省了多少 API 费用，而是建立了一套清晰的心智模型：什么任务值多少钱的算力。14B 能干的活，本地零成本无限跑；70B 才能干的活，先算算值不值得；真需要顶级模型的活，几分钱的 API 调用远比自己硬扛划算。剩下的钱和精力，留给真正需要云端大模型的任务。本地模型不是云端的替代品，是隐私和零成本场景下的最佳补充——认清这个定位，你就不会在错误的战场上浪费一颗好芯片。