M3 MacBook Pro本地LLM编程实测

像许多开发者一样，我一直对在本地运行 LLM 感到好奇。

这个想法听起来近乎完美：下载一个模型，将 prompt 和代码留在自己的机器上，避免再订阅一项服务，还能把模型直接连接到 VS Code。我手上已经有一台搭载 M3 处理器和 36 GB 统一内存的 MacBook Pro，所以我想知道实际上能把它推到多远。

我并不是要证明笔记本能跑 LLM，这件事已经被验证过了。

我真正想问的问题更加实际：

本地模型能否成为我日常coding的助手？

在一周的实验中，我尝试了不同的模型，比较了普通版和 MLX 版，调整了上下文长度，把 Ollama 通过家庭网络连接到 VS Code，并尝试用它处理比独立代码片段更复杂的任务。

有些部分的效果远超预期。另一些部分则提醒我：跑一个模型和拥有一个高效的coding工作流是两件完全不同的事。

我在 36 GB 的 M3 MacBook Pro 上使用 Ollama，并将其连接到 VS Code——也包括从另一台联想笔记本通过本地网络连接。Gemma 4 26B 表现不错，而 gemma4:31b-mlx 给我带来了最佳的整体本地模型体验。qwen3-coder:30b 同样值得在coding相关任务中测试。

对于问题解答、代码解释、小改动和聚焦的代码生成，这套配置确实有用。但对于一个需要反复规划、仓库探索、代码修改和验证的中等复杂度项目，它的处理速度对于我想要的工作方式来说太慢了。

最终我还是回到了日常开发中使用 GitHub Copilot/Codex。但我并不认为本地实验是失败的。它帮助我理解了本地模型目前已经在哪些地方有用，在哪些地方仍然吃力，以及为什么完整的coding工作流和模型本身一样重要。

我设想的基础架构

我的配置涉及两台机器：

联想那台本来就是一台性能不错的开发笔记本。但它只有 8 GB 专用 GPU 内存，不太适合我想要尝试的 26B 到 31B 级模型。Mac 更大的统一内存池使它成为了更有意思的推理主机。

架构很简单：

VS Code on Lenovo -> local Wi-Fi -> Ollama on MacBook Pro -> local model

Ollama 在 11434 端口暴露了一个 HTTP API。默认情况下它只监听本机，但可以通过 OLLAMA_HOST 改变绑定地址，以便从其他设备访问。

在 macOS 上，相关设置如下：

launchctl setenv OLLAMA_HOST "0.0.0.0:11434"

重启 Ollama 后，我就能把 VS Code 集成指向 MacBook 的本地 IP 地址。

在排查 VS Code 内部问题之前，我发现先从联想那台验证一下更简单的网络通路会很有用：

curl http://<macbook-local-ip>:11434/api/tags

如果这返回了已安装模型的列表，说明 Mac、Ollama 服务器、端口和本地网络路由都工作正常。只有到那时才值得去调试编辑器配置。这个小小的分离让我避免了把每一个连接问题都当作 VS Code 问题来处理。

我把这件事限制在可信的家庭网络内。绑定到 0.0.0.0 会让服务在 localhost 之外也可访问，所以我不会把 11434 端口直接暴露在公共互联网上。

安装本身并不困难。Ollama 让下载、启动、停止和切换模型变得很直接。

ollama run gemma4:26b

要查看内存中当前还加载着什么，这个命令特别有用：

ollama ps

这个小命令回答了测试期间的一个重要问题：模型是完整加载用于加速推理，还是被拆分到多个处理器，又或者已经卸载了？

理解模型名称的真正含义

在这次实验之前，26b、30b、31b 这些数字听起来像是产品版本号。它们不是。B 代表的是十亿参数。

更大的数字通常意味着更强的模型容量，但并不自动代表在某台特定笔记本上有更好的体验。架构、量化、内存占用、上下文长度，以及模型为每次响应所做的工作量都会产生影响。

当我对比这些模型时，这一点变得很清楚。

我观察到的结果背后还有一个架构细节。Gemma 4 26B 是一个混合专家模型，每个 token 只有部分参数激活，而 31B 版本是密集模型。标签看起来很接近，但推理过程中实际执行的工作并不相同。这是为什么仅看模型大小是一个不完整的性能指标的其中一个原因。

初步结果确实令人印象深刻

一旦模型出现在 VS Code 工作流中，体验感觉出奇地正常。

本地设置适合以下这些聚焦任务：

• 解释不熟悉的代码；
• 生成一个小方法；
• 建议一种重构方案；
• 写一个单元测试大纲；
• 比较两种实现方案；以及
• 帮助思考一个类或 API 的设计。

对于这些聚焦任务，本地设置表现不错。看着一个能力还算不错的模型从我自己的笔记本上响应，而不需要把 prompt 发送到托管推理服务，也是有一种满足感的。

在这个阶段很容易宣布成功了。一个 prompt 进去，有用的代码出来，本地 LLM 演示成功。

但那不是我在意的测试。

我想用模型的方式和现代coding助手一样：给它一个目标，让它检查多个文件，创建一个计划，做修改，重新考虑一个决策，运行检查，修复问题，然后继续。

这就是体验发生变化的地方。

Coding Agent 将每一丝延迟都放大了

单个慢的响应是可以接受的。但 agentic coding 循环不一样。

这基本就是我第一个 prompt 和一个真实项目之间的差别。

一个功能可能需要模型：

• 检查仓库；
• 读取相关文件；
• 理解现有设计；
• 生成一处或多处编辑；
• 解释一次构建或测试失败；然后
• 重复部分循环。

如果每一步都明显更慢，延迟会叠加。我不再只等待一次答案，而是在开发循环的每个转折点都在等待。

在小任务上，31B MLX 模型可以产出好的结果。但在一个中等复杂度的项目上，整体流程变得太慢了。模型经常能做下一步，但我等得足够久，以至于失去了节奏。

这是我实验最大的教训：

Coding 生产力取决于整个循环的延迟，而不仅仅是一次生成答案的质量。

一个模型在聊天窗口里可能令人印象深刻，但作为自主或半自主coding助手仍然显得不切实际。

上下文长度不是免费的升级

仓库级的工作也需要上下文。模型必须看到足够的代码库内容、指令、对话和工具输出，才能做出一致的修改。

把上下文窗口增加到模型支持的最大值很诱人，但配置的上下文会消耗内存。更多的上下文会减少可用于推理的资源，并让已经繁重的工作流变得更慢。

Ollama 允许在启动服务器时配置上下文长度：

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

当前的 Ollama 文档中存在一个有趣的张力。对于 24–48 GiB 内存层级的系统，Ollama 默认使用 32K 上下文，但其文档建议 agent 和coding工具至少需要 64K。两种建议都有道理：前者对内存谨慎，后者反映了仓库级工具可能需要多少上下文。

所以我的 32K 起点不是模型的理论极限，而是对于一台 36 GB 共享内存的机器（模型、上下文缓存、操作系统、编辑器和其他应用程序共用）的实际折中。

最大的值不一定是最好的值。在 36 GB 的 Mac 上，模型、它的上下文缓存、macOS 和任何其他运行中的应用程序共享同一个内存池。

对我来说，这变成了一种平衡：

• 更小的模型响应更快，但在复杂工作上可靠性更低。
• 更大的模型产出更强的答案，但拖慢了整个开发循环。
• 更多的上下文有助于仓库感知，但增加了内存压力。
• 减少上下文改善了资源使用，但限制了助手一次能考虑多少项目内容。

没有任何设置能让这四个问题同时消失。

MLX 有帮助，但没有改变最终结论

因为我用的是 Apple 芯片，所以我也探索了 MLX 变体。MLX 专为 Apple 芯片上的机器学习设计，可以充分利用其统一内存架构。

gemma4:31b-mlx 最终在整体质量方面成为我测试中表现最好的本地选项。它让我认识到我的 MacBook Pro 比最初想象的更有能力。

然而，优化并不能消除底层的工作负载。一个 31B 级模型仍然需要生成 token、推理任务、处理上下文，并参与 agent 循环的每一步。

MLX 改善了实验体验。它并没有把笔记本变成云推理集群。

我也短暂探索过是否应该放弃 Ollama 直接使用 MLX-LM。这是一个有趣的方向，但我最终把它从这次实验中剔除了。我的目标是改善 VS Code 内部的coding体验，而不是用另一个还需要配置和维护的栈来替换一个简单的服务层。对这次测试来说，Ollama 的便利性本身就是价值的一部分。

我也考虑过加更多硬件

有一刻，我想知道加一台或多台 Mac mini 能否解决问题。

这个想法很有吸引力：开发机保持 VS Code，把模型放到无头 Mac 上，把它们当作本地推理服务器。

如果目标是分离开发工作和推理，或者从不同机器服务不同模型，这可能是有用的。但多台电脑不会自动将它们的内存合并成一个更大的池来运行单个 Ollama 模型。没有为这个目的设计的分布式推理层，每台机器仍然是各自独立的服务器。

买更多硬件也会改变经济学。本地设置可能避免了按 token 计费，但硬件、电费、配置、维护，以及我自己的等待时间都不是免费的。

在买另一台机器之前，我首先需要证明本地推理能够改善我的日常工作流程。就目前而言，它还没有达到那个程度。

为什么我又回到了 GitHub Copilot

在尝试调优本地设置之后，我回到日常开发工作中使用 GitHub Copilot。

原因不是本地模型不好。它们出人意料地好。

对于一个中型项目，我想要更快的迭代、更好的仓库级协助、以及更少的时间花在观看每一步完成上。Copilot 在我实际做的那些工作上给了我更实用的体验。

这个对比也帮助我理解了一款coding产品不仅仅是 LLM。模型很重要，但上下文收集、文件选择、工具执行、编辑应用、错误恢复，以及整个循环周围用户体验同样重要。

在本地运行一个能力很强的模型只解决了这个系统的其中一部分。

我仍然会使用本地模型的场景

我没有放弃本地 LLM。我仍然会把这套配置用于：

• 学习模型、量化、上下文和推理实际是如何工作的；
• 聚焦的代码解释和小规模实现问题；
• 离线实验；
• 测试 prompt 而不用担心用量配额；以及
• 需要本地模型 API 的原型构建。

我也会把它作为辅助助手来保留，而不是强迫它取代每一个云端coding工具。

这可能是从实验中获得的最有用的心态。选择不必是全本地或全云端。不同的工具可以服务工作流的不同部分。

下次我会做哪些不同的事

如果我重复这个对比，我会让它更加系统化。

我会对每个模型使用同一组任务：

• 解释一个不熟悉的类；
• 实现一个受限的功能；
• 给现有代码添加测试；
• 调试一个故意引入的失败；
• 跨多个文件重构；以及
• 完成一个需要规划和验证的仓库级任务。

对于每个任务，我会记录：

• 到首次有用响应的时间；
• 任务完成总时间；
• 需要修正的次数；
• 峰值内存压力；
• 模型在上下文增长时是否保持连贯；以及
• 最终代码是否通过构建和测试。

Ollama 的 API 已经返回了有用的计时字段，包括 total_duration、load_duration、prompt_eval_count、prompt_eval_duration、eval_count 和 eval_duration。这意味着未来的对比不需要只依赖秒表或感觉响应有多快。

例如，输出生成速度可以这样计算：

tokens per second = eval_count / (eval_duration / 1,000,000,000)

我仍然会把这作为一个次要指标。模型可以快速生成 token，但可能把代码带向错误的方向。重要的结果是它是否正确完成了任务、它需要多少干预，以及整个循环花了多长时间。

Tokens per second 有意思，但我真正在乎的指标是每分钟完成多少开发者工作。

结论

我的本地 LLM 实验始于一个简单的问题：我能用在自己硬件上运行的模型替换我的云端coding助手吗？

对于我目前的机器和工作流程，诚实的答案是：还不能完全做到。

36 GB 的 M3 MacBook Pro 能运行比我最初想象的更强的模型。Gemma 4 26B 表现出色，而 31B MLX 变体确实令人印象深刻。Ollama 也让运维方面足够简单，让我可以专注于模型而不是花整周时间配置基础设施。

但一旦我从孤立的 prompt 走向中等复杂度的项目，速度就成了限制因素。本地模型可以帮助我写代码，但它们还跟不上我对日常 agentic 工作流所期望的节奏。

所以我回到了 GitHub Copilot——但这次更好地理解了我在为什么付费，对本地 AI 也有了更现实的看法。

本地 LLM 不再只是新奇事物。它们今天就有用了。但对我来说，目前最好的用途是作为一个私有的、灵活的辅助工具——而不是桌上唯一的coding助手。

资源

Ollama: VS Code integration

Ollama FAQ: context, networking, memory, and model management

Ollama: context length and model offloading

Ollama API: generation response and timing fields

Ollama model library: Gemma 4

Ollama model library: Qwen3 Coder

MLX documentation: unified memory on Apple silicon

本文中的观察基于我自己的硬件、模型选择、prompt 和项目。性能和输出质量会因机器、量化、上下文大小、集成方式和工作负载而异。

AI 协助说明：我使用 AI 帮助组织和编辑本文。设置、实验、观察和结论均基于我自己的经验。