苹果芯片跑本地大模型的性能和意义

问题描述：

最近正好手头有两台苹果电脑，一台是满血版 MacBook Pro（M1 Pro，32GB+1TB，10 核 CPU + 16 核 GPU），另一台是 Mac Studio（M4 Max，128GB+1TB），我想借这个机会，看看苹果芯片在本地跑大模型时到底能做到什么程度。我想知道这两个问题：

1. 苹果芯片跑本地大模型，真实性能到底在什么水平；
2. 到了现在，本地部署这件事到底还有没有意义，意义又主要体现在哪。

我先贴我本地实际跑出来的一批结果，再聊聊我自己对“苹果芯片 + 本地大模型”这件事的判断，哪些是优势，哪些是想象，哪些场景值得投入，哪些场景其实不如直接用云端。

如果你们手里也有 M1/M2/M3/M4 不同机器，或者不同框架、不同量化的测试，也欢迎一起补数据，把这帖做成一个可参考的样本帖，而不只是单次跑分展示。

网友解答：

---

--【壹】--：

这次主要测试的是阿里新出的 Qwen3.6-35B-A3B，也穿插了一些其他模型和题目。

MacBook Pro 受制于内存限制，32GB 内存搭配 20GB 左右的模型都比较勉强，所以只能使用 4bit 量化版本，5.4bit、6bit 量化这种都跑不起来。但即使是 4bit 量化版，也依然能看出不错的理解力，很多题目里的“坑”它其实能识别出来。

为了避免最后只剩下主观印象，这篇文章主要看四类信号：

• 能否加载
• 生成速度
• 是否答对
• 错在什么地方

先说结论

1. 8bit 量化和完整版 BF16 差别不大。简单的问题，4bit、8bit 量化版本都能解决，也就是 128GB 电脑和 32GB 电脑都能完成，无非是速度问题。
2. 特别复杂的问题，本地大模型都难以胜任；目前看来，GPT Thinking 这类模型基本都解决了。
3. 也许在超长上下文的真实工程场景里，量化程度会凸显出差异。
4. 目前感觉订阅模型的性价比更高，为本地大模型购买昂贵设备还划不来；但如果未来 token 价格大涨，也许才是发力的时候。之前看到一个测试结论：本地大模型（需要 512GB 内存才能支持的满血版）落后顶级订阅模型约 6 个月，而最先进的订阅大模型还不会开放给本地部署，所以我觉得目前没必要为本地集群下血本投资设备。

---

--【贰】--：

image1920×9445 876 KB

---

--【叁】--：

32G的机器在于，自己用电脑要占一些内存，上下文还要占一些。32G内存就比较吃紧了。64G就非常宽裕，128G能用来跑更高量化了。

另外其实算力够（M4、M5系列）试试qwen3.6-27b这个dense模型应该也还行。我的M1Pro跑起来太慢了。

3.6这代给我的感觉比之前的明显要好，plus也是。

---

--【肆】--：

会不会是Qwen3 Next发布的时候还没有这个问题,3.6在这个问题出现后对这个问题做了特殊优化?

---

--【伍】--：

这个真有可能，好多ai都对着答案回答问题

---

--【陆】--：

我也用的是32g的机器。现在唯一用它的就是用了一个转录以及一个后处理的模型,进行语音输入法。
具体的参考:【迭代后处理】Handy-v0.8.1-Qwen3-ASR-with-Qwen3.5-Post-Processing-dev ， 一共占了3个多g
Screenshot 2026-04-25 at 19.42.281230×944 103 KB

部署小模型作为一种日用的处理，还是不错的。但干活肯定不行啦。一些小任务可以交给他，就比如说翻译、图像处理之类的

下一步，我肯定要买64g + 1tb的机器了。
这种情况还是容易撑爆它，虽然说大部分时间还是绿色。但 Codex 处理量上来了之后，就容易出现内存爆掉的情况，而且我还开了 n 多个标签页。

---

--【柒】--：

我感觉，目前只有本地跑图有点意义，其他的本地模型都不太行。

---

--【捌】--：

第四组：更接近真实业务的规则引擎

这一题比上一题更接近真实业务：规则多、优先级明确、字段也多，而且有重复判定、例外情况和汇总统计，特别适合看模型会不会在细节上漏掉一两步。

你是一个严格的报销规则引擎。只能根据下面给出的员工信息、规则和 claim 表计算。不要输出解释，不要输出推理过程，不要输出 markdown，只输出一个 JSON 对象。 规则优先级从高到低，按 1 -> 11 依次应用；一旦某条规则使 claim 被拒绝，就不再继续看后续规则。 员工等级说明：grade 为 1/2/3/4，数字越大等级越高。 规则： 1. 若 project_blocked=yes，则该 claim 直接拒绝。 2. 若 weekend=yes 且 travel_tag=no 且 oncall=no，则该 claim 直接拒绝。 3. 重复 claim 规则：若两个或多个 claim 满足 employee、date、category、merchant、amount 全相同，则只保留 claim_id 字典序最小的那一条继续评估，其余重复 claim 直接拒绝。 4. 若 receipt=no，则该 claim 直接拒绝；唯一例外是 category=metro 且 amount<=4，此时允许继续评估。 5. 若 category=flight 且 grade<3 且 advance_approval=no，则该 claim 直接拒绝。 6. 若 category=hotel，则 cap 为： - T1: 180 - T2: 240 - T3: 320 批准金额 = min(amount, cap) 7. 若 category=meal，则 cap 为： - T1: 30 - T2: 45 - T3: 60 若 client_meeting=yes，则在原 cap 基础上再 +20。 批准金额 = min(amount, cap) 8. 若 category=taxi，则 cap 为： - 普通 taxi: 25 - 若 airport_transfer=yes，则 cap=40 批准金额 = min(amount, cap) 9. 若 category=metro，则 cap=10，批准金额 = min(amount, 10) 10. 若 category=misc，则只有在 special_approval=yes 时才可批准；若可批准，则批准金额=amount，否则直接拒绝。 11. 若 claim 通过了前面所有规则： - 对于 flight，批准金额=amount - 对于 hotel/meal/taxi/metro/misc，批准金额按对应规则计算 员工表： employee grade A 2 B 3 C 1 D 4 E 2 F 3 G 2 H 2 claim 表： claim_id employee date weekend category tier merchant amount receipt travel_tag oncall advance_approval client_meeting airport_transfer special_approval project_blocked C1 A 2026-07-08 no hotel T2 Marriott 260 yes no no no no no no no C2 A 2026-07-11 yes meal T2 Bistro 52 yes no no no no no no no C3 B 2026-07-12 yes flight T1 Delta 190 yes yes no no no no no no C4 B 2026-07-12 yes taxi T1 CityCab 38 yes yes no no no yes no no C5 C 2026-07-07 no flight T2 United 210 yes no no no no no no no C6 C 2026-07-07 no flight T2 United 210 yes no no no no no no no C7 D 2026-07-09 no misc T3 SuppliesCo 85 yes no no no no no no no C8 D 2026-07-09 no misc T3 SuppliesCo 85 yes no no no no no yes no C9 E 2026-07-10 no metro T1 Metro 3 no no no no no no no no C10 E 2026-07-10 no meal T1 Cafe 28 no no no no no no no no C11 F 2026-07-12 yes hotel T3 Hilton 350 yes yes no no no no no yes C12 G 2026-07-10 no taxi T2 AirportCab 44 yes no no no no yes no no C13 G 2026-07-10 no meal T2 ClientLunch 70 yes no no no yes no no no C14 H 2026-07-12 yes metro T1 Metro 6 no no yes no no no no no 定义： - approved_amount_by_claim: 只包含被批准的 claim_id，value 为最终批准金额（整数）。 - denied_ids: 所有被拒绝的 claim_id，按字典序升序。 - denied_reason_by_claim: 只包含被拒绝的 claim_id，reason 只能是以下之一： "project_blocked" "weekend_not_allowed" "duplicate" "missing_receipt" "flight_requires_approval" "misc_requires_special_approval" - partially_capped_ids: 指“被批准，但批准金额 < amount”的 claim_id，按字典序升序。 - employee_approved_totals: 只统计有批准 claim 的员工，总金额为该员工所有批准金额之和。 - top_employee: approved total 最高的员工；若并列，取 employee 字典序最小者。 - true_statement_ids: 从下列陈述中选出为真的，按字典序升序输出： S1. 恰好有 6 个 claim 被批准。 S2. total_approved_amount 严格大于 570。 S3. top_employee 是 B。 S4. 所有因 duplicate 被拒绝的 claim，如果忽略 duplicate 规则，都会变成批准。 S5. 至少有一个被批准的 claim 同时满足 weekend=yes 和 travel_tag=yes。 只输出这个 JSON，对象字段不能多也不能少： { "approved_amount_by_claim": { "C?": 0 }, "denied_ids": ["..."], "denied_reason_by_claim": { "C?": "..." }, "partially_capped_ids": ["..."], "employee_approved_totals": { "A": 0 }, "top_employee": "", "total_approved_amount": 0, "true_statement_ids": ["..."] }

结果

image1920×2916 341 KB

结果分析

第一，C10 必须拒绝。
C10 是 meal，receipt=no。
规则 4 只有一个例外：category=metro 且 amount<=4。
C10 不是 metro，所以必须是 missing_receipt。
这就是为什么你的 8bit 把 C10 批了以后，E 变成 31，总额变成 604，这些都连带错了。

第二，C8 也必须拒绝。
C7 和 C8 在规则 3 的重复判定里是重复项，因为重复只看：

• employee

• date

• category

• merchant

• amount

  这五个字段。
  C7 和 C8 这五项完全相同，所以只保留 claim_id 更小的 C7，C8 直接 duplicate 拒绝。
  注意这里不管 special_approval 是否一样，因为规则 3 根本不看那个字段。

  所以：

• 8bit 错在：把 C10 批了

• 4bit 错在：把 C10 批了，还把 C8 也批了

  这题已经开始有明显区分度了，因为 8bit 和 BF16 只错 1 个关键点，4bit 错 2 个关键点。但与此同时，BF16 的 tok/s 大幅下降。

  从这个结果来看，量化后的模型并不是“完全不能用”，但一旦题目开始依赖严格规则、异常分支和多处联动，低量化版本就更容易在关键点上掉链子。

---

--【玖】--：

我觉得大内存，大核心的机子，让codex发挥并行工作能力才是王道

---

--【拾】--：

M4 Pro 48GB内存，跑 gemma4:26b 速度还行，但是没有测试过长时间复杂任务

---

--【拾壹】--：

第三组：更像规则求解器的综合题

下面这题同时考精确筛选、依赖关系、时序约束、组合优化和严格 JSON 输出。它已经不像普通问答题，更像一个小型规则求解器。

你是一个严格的组合优化求解器。只能根据下面给出的数据和规则计算。不要输出解释、不要输出推理过程、不要输出 markdown，只输出一个 JSON 对象。 所有日期都在同一个时区；“至少 2 天”按自然日差值计算。 所有输出数组都必须按 ID 升序排列。 项目表： ID lane review security_block depends approved launch engineers gpu value P1 Core yes no - 2026-07-10 2026-07-13 4 3 18 P2 Edge yes no - 2026-07-09 2026-07-12 3 2 14 P3 Tools yes no - 2026-07-11 2026-07-14 2 1 10 P4 Core yes no P3 2026-07-09 2026-07-15 4 3 17 P5 Edge yes no P2 2026-07-10 2026-07-15 5 3 19 P6 Tools no no - 2026-07-08 2026-07-13 2 1 8 P7 Core yes yes - 2026-07-09 2026-07-14 3 2 13 P8 Edge yes no - 2026-07-12 2026-07-15 3 4 15 P9 Tools yes no - 2026-07-10 2026-07-12 2 2 9 P10 Core yes no P9 2026-07-10 2026-07-12 3 2 14 规则： 1. 基础可选条件：review=yes 且 security_block=no。 2. launch 必须满足： - 不早于 approved 后第 2 天（即 launch - approved >= 2 天） - 不晚于 2026-07-15 3. 若某项目有 depends，则其依赖项目必须被同时选中，且该项目的 launch 必须严格晚于每个依赖项目的 launch。 4. 所选项目总 engineers <= 12。 5. 所选项目总 gpu <= 9。 6. 所选项目中必须至少包含 1 个 Core、1 个 Edge、1 个 Tools。 7. P4 与 P5 不能同时被选中。 8. P8 与 P9 不能同时被选中。 9. 优化目标：使所选项目的 total value 最大。 10. 若 total value 并列，按以下顺序打破平局： a) 选择项目数更少者优先 b) 所选项目中的最晚 launch 更早者优先 c) selected_ids 升序排列后，字典序更小者优先 11. must_reject_ids 的定义： 指“无论优化目标如何，只要满足规则 1-8，就绝不可能出现在任何可行解中的项目 ID”。 12. 判断下列陈述哪些为真： S1. 最优解恰好选择 4 个项目。 S2. 任一包含 P8 的可行解都不能包含 P9。 S3. P5 属于 must_reject_ids。 S4. 存在 total value >= 52 的可行解。 只输出下面这个 JSON schema，字段名必须完全一致，不能多也不能少： { "selected_ids": ["..."], "total_value": 0, "total_engineers": 0, "total_gpu": 0, "latest_launch": "YYYY-MM-DD", "must_reject_ids": ["..."], "true_statement_ids": ["..."] }

它会同时考：

• 精确筛选
• 依赖与时序
• 组合优化
• tie-break
• “任何可行解都不可能出现”的强判断
• 严格 JSON 输出

结果

image1732×1258 122 KB

这题里，4bit 就已经能生成正确答案。M4 Max 是 85 tok/s，M1 Pro 是 33.79 tok/s，8bit 量化版速度是 73.04 tok/s。

这说明一件很有意思的事：有些题看起来“复杂”，但本质上更偏规则执行和搜索。只要模型没有在中间掉步，4bit 也不一定会输。

---

--【拾贰】--：

第一组：先看最基础的逻辑题

1）32GB 内存 + M1 Pro + 4bit 量化

image1900×1564 229 KB

只有 20GB 的模型，居然也给出了正确答案。算上 KV cache 和其他应用，内存几乎拉满，速度是 40 tok/s。

2）M4 Max + 128GB + 4bit 量化

image1866×750 125 KB

速度直接来到 90 tok/s，体验已经明显高出一档。

3）M4 Max + 128GB + 8bit 量化

image1982×914 150 KB

毫无压力，速度是 76 tok/s，生成非常快。

4）Qwen3 Next

image1920×1489 183 KB

大参数模型反而有点掉链子，不过 M4 Max 的速度依然很猛。

这一组测试说明了一件事：在“基本逻辑题”上，4bit 量化并没有想象中那么弱；真正拉开差距的，更多还是速度，以及面对更高难度任务时的稳定性。

---

--【拾叁】--：

昨晚在x上看到一个问题 r里面有多少个strawberry

好多模型感觉都是一本正经的数了3个出来。少数模型回答了0个

---

--【拾肆】--： freegrid:

我想聊的其实不只是 “Mac 跑本地模型快不快”，而是两个更实际的问题：

AI生成内容要用截图的方式提供哦

---

--【拾伍】--：

苹果的统一内存让普通人至少拥有了部署开源大模型的能力。

目前小模型例如Qwen3.6对于企业智能体来说已经足够跑了。但是场景肯定不是拿来日常Vibe Coding用的。

除非你真的非常在乎你的隐私内容或者商业机密。本地部署的成本、模型效果和易用性肯定是不如直接买API的。还不说硬件在不断迭代，当前购入的硬件性价比会逐渐降低，云端API的价格随着技术的迭代也会下降。

不过据我在Reddit /r/LocalLLaMA/ 的观察来看，除了商业用途外的，大多数本地部署大模型的人，本质是在"折腾"。

说不定，再过一年，30B的模型就能媲美Opus4.6呢？

---

--【拾陆】--：

本地主要是不降智+隐私+稳定，价格上不会有任何优势，当然就目前这个硬件价格趋势，说不定用了几年卖出去还能倒赚一笔

---

--【拾柒】--：

折腾的就当九年义务教务了哈哈哈哈，起码知道是什么东西。对某一部分精英来说，速度就是价值，早一分就是一个机遇，保密性无所谓，无脑上订阅。剩余的，中国有足够的人口基数，慢慢酝酿，开源的模型就是教科书+实验基地，足够的积累总有灵光一现的非线性突破和井喷式性能提升

---

--【拾捌】--：

第二组：长上下文里的证据定位

这一题更适合拉开差距，因为它考的不是模型会不会某个知识点，而是能不能在长材料里准确定位证据，并且严格按格式输出。换句话说，它测的不是“知道不知道”，而是“读没读清楚”。

下面给出 6 段材料。只根据材料回答。每问必须输出 answer 和 evidence；evidence 只写段号数组。没有明确信息就写“信息不足”。只输出 JSON。 ​ [P1] Atlas 设计并不试图在每个周期里只追逐最重的通信对，而是要求安装后的拓扑在整个周期内对剩余需求仍然有用。 [P2] 为了做到这一点，设计会保留一部分拓扑预算，用于 bounded-hop residual accessibility；实验里统一使用的 hop budget 是 K=4。 [P3] 在中等负载下，与 KM 相比，Atlas 的 average FCT 下降了 14.2%，max epoch-end backlog 下降了 20.9%。 [P4] 作者指出，average epoch-end backlog 的区分度弱于 throughput、makespan 和 maximum backlog。 [P5] 原型系统规模为 8 节点；底层 MEMS 器件切换时间约 10 ms，但业务可见恢复可达秒级。 [P6] 文中给出的 oracle 调度只作为理论上界参考，并未宣称可直接部署。 ​ 问题： 1) 这个设计与纯 demand matching 的结构性区别是什么？ 2) 哪个 backlog 指标被认为区分度较弱？ 3) 原型系统有多少节点？ 4) 对 oracle 调度作了什么部署层面的声明？ 5) 与 Gemini 相比的平均吞吐提升是多少？ ​ 输出格式： { "q1":{"answer":"","evidence":[]}, "q2":{"answer":"","evidence":[]}, "q3":{"answer":"","evidence":[]}, "q4":{"answer":"","evidence":[]}, "q5":{"answer":"","evidence":[]} }

标准答案：

{ "q1":{"answer":"保留一部分拓扑预算以保证 bounded-hop residual accessibility，而不是只追逐最重通信对","evidence":["P1","P2"]}, "q2":{"answer":"average epoch-end backlog","evidence":["P4"]}, "q3":{"answer":"8","evidence":["P5"]}, "q4":{"answer":"没有宣称可直接部署；oracle 只作为理论上界参考","evidence":["P6"]}, "q5":{"answer":"信息不足","evidence":[]} }

这道题里，各个模型开始出现明显差异：

1）4bit 量化

image1876×668 107 KB

它“基本对”，但不一定是最完整的答案。这个回答抓住了 P1 的高层意思：

• 不是只追逐最重通信对
• 而是让拓扑对剩余需求仍然有用这已经回答了“区别是什么”的大方向。但标准答案里我故意把 P2 的机制层信息 也放进去了：
• 保留一部分拓扑预算
• 用于 bounded-hop residual accessibility这部分更像“结构性区别”的具体实现机制。所以如果评分很严格，更准确的评价是：语义正确，但证据和答案略少了一层机制细节。

2）依据 Claude Opus 4.6 微调的版本（34.37GB）

image1874×1184 120 KB

同样不行。

3）8bit 量化版（35.15GB）

image1886×682 97 KB

还是不行。

4）GPT-5.4 Thinking

image1958×1336 125 KB

到了这一档，输出已经明显稳了很多。

5）Qwen3 Next 80B

image1942×1628 142 KB

这一轮终于给出了我期待的答案，参数量的优势还是很直观。

如果说上一题只是“基本能不能做”，那这一题已经开始逼近真实工作里的一个关键要求：不仅要答对，还要把证据链交代清楚。

---

--【拾玖】--：

只是单纯能跑，要跑得快是不可能的。除非弄十几张h100。
但是有这个钱不如api爽用。 对于个人而言除非是有强隐私要求。