新文章

Birgitta Böckeler 最近花了一些时间尝试在本地运行大语言模型来完成一些编程任务。在这篇备忘录中，她概述了影响这些模型可行性的因素。

https://t.co/ALp5q6p3g5

本地模型用于编程的可行性

来源：https://martinfowler.com/articles/exploring-gen-ai/local-models-for-coding-factors.html 直到不久前，我已经很久没有尝试在本地运行模型了，之前每次尝试都让我非常失望。但大约一个月前，我又重新投入其中——网络上关于它们进步有多大、运行起来比以前可行多少、以及其中一些在编程方面变得多么出色的说法太多了，让人无法忽视。所以，这是我大约在过去4周里断断续续使用它们的个人体验。

在这份备忘录中，我将从更通用的介绍开始，然后梳理影响这些模型在编程中可行性的各种因素。在后续的备忘录中，我将更详细地描述我的实际经历。

范围

我主要关注的是它们在编程中的实用性，并且不仅仅是自动补全，而是智能体式编程。其次，我感兴趣的是它们对于不想花大量时间去研究一堆规格说明、额外工具和各种调优才能让它工作的开发者来说，总体准备程度和易用性如何。

在硬件方面，我在这两台机器上运行了模型：

• Apple M3 Max，48GB 内存
• Apple M5 Pro，64GB 内存

影响可行性的因素

有无数因素会影响结果，这使得评估在有限的资源约束下哪种配置效果最好变得相当繁琐。同时，当人们在网上分享他们使用这些模型成功的经验时，也很难从噪音中筛选出有效信号。

我觉得特别令人困惑的是，在自动化的评估设置中，尽管所有其他设置都相同，一个模型在更强的那台机器上明显产生了更好的结果（不仅仅是速度更快，代码质量也更高！）。

我先提供一个总结，然后再详细说明每个因素。

目标模型可运行性响应速度工具调用成功结果质量模型LLM运行时量化架构格式推理硬件内存处理能力内存带宽工具框架任务规模与复杂性上下文窗口大小预填充（系统提示、工具、……）

不同的工具模式会影响……

提供模板来改进

更好的硬件匹配会带来更好的……

在优化方面存在差异……

图1：可能影响结果的众多因素——点击或悬停框体可高亮显示箭头。

• 可运行性： 内存是核心限制。我使用的模型大小在15-25GB之间，上下文窗口最大64K，使用OpenCode和Pi框架，且启用了零个技能和MCP服务器。
• 响应速度： 受很多因素影响，但有些模型表现得相当不错，与一年前相比有了质的飞跃。配置：LM Studio + 4BIT量化 + M3 Max/M5 Pro + GGUF/MLX两者。
• 智能体式编程的可行性： 工具调用仍然比较棘手，模型经常失败，但通常可以从失败中自我恢复。这尤其是智能体式编程的一个关键组成部分。没有它，你当然仍然可以走老路，从聊天窗口复制粘贴。而且小型模型在自动补全方面显然比在智能体式使用中可行得多。
• 结果质量： 取决于任务（更多内容将在下一份备忘录中说明），但显然远不及大型模型所具备的能力。总体而言，结果时好时坏。我只关注功能的正确性，没有深入考察代码质量。

内存

模型权重必须能够放入可用的RAM中，或者更具体地说，是VRAM。如果不能，运行时要么崩溃（我遇到过这种情况！），要么速度慢到无法使用。在Apple Silicon上，几乎所有RAM都可以被GPU访问，没有单独的VRAM限制，这在其他机器配置上可能有所不同。

影响： 模型可运行性；响应速度

我的经验： 在48GB的机器上，我运行了8GB到近30GB的模型。当然，30GB非常勉强，尤其是加上上下文窗口之后；15-25GB的大小更舒服，我也不需要关闭那么多其他应用程序。在64GB的机器上，我曾经运行过一个48GB大小的模型——一开始效果不错，但很快就崩溃了……

处理能力

更多核心通常意味着更快的令牌生成速度，但架构也很重要，较新的芯片代际可以用更少的核心来缩小差距。在不深入每个配置和架构细节的情况下，这很难在不同机器之间进行比较。

影响： 响应速度

我的经验： 在M3 Max和M5 Pro上，我运行的所有模型与一年前相比，速度都相当令人印象深刻。不过，随着对话变长，速度会下降。对于某些任务，我可以在当前速度下接受使用它们——如果输出质量也令人满意的话。

内存带宽

内存带宽是令牌生成的瓶颈，决定了数据在RAM和计算单元之间移动的速度。

影响： 响应速度

我的经验： 我使用的M3 Max和M5 Pro都具有几乎相同的约300 GB/s带宽，所以我没什么可对比的。但如上所述，我尝试的所有模型的速度都相当可以接受。

参数量

参数量基本上代表了模型已学习的知识和能力的大小。更多参数通常意味着更好的输出质量，但也意味着更大的文件大小。

影响： 所需RAM量；结果质量

我的经验： 在48GB内存下，我使用了大约30B参数（± 5B）的模型。我在64GB机器上加载的最大的模型是Qwen3 Coder Next 80B（MoE），它解决我交给它的任务比小型模型好得多——但在继续对话后就崩溃了。

推理能力

推理模型在响应之前会经历一个“思维链”过程，这有助于处理复杂的多步骤任务，但也会生成显著更多的令牌并减慢响应速度。

影响： 任务复杂度；响应速度；上下文窗口大小（进而影响对RAM的需求）

我的经验： 我尝试的所有模型都具有推理能力，并且在大部分实验中默认启用。然而，我经常注意到它们在推理链内陷入无休止的循环，尤其是较小的模型（“等等……”“实际上……”“但是等等……”）。所以我也在关闭推理的情况下做了几次我的自动化设置运行——结果发现，不仅速度更快（这是意料之中的），而且表现相同甚至略好！这很好地提醒我们，推理并非总是必要的，有时甚至会适得其反。

工具调用能力

对于智能体式使用，模型必须能够可靠地生成符合框架期望模式的、结构化的工具调用语法。没有专门为工具调用进行训练或微调的模型，经常会产生格式错误的调用。

影响： 使用智能体式框架的能力

我的经验： 这是我尝试的模型中的一个常见问题，不过它们通常能够自我纠正并从失败的工具调用中恢复（例如，使用了错误的参数名，如file.path而不是filePath）。

格式

GGUF是llama.cpp运行时（如LM Studio和Ollama）的标准格式，拥有最大的模型库。MLX是苹果自家为Apple Silicon构建的框架，可能更快，但目前可用的MLX格式模型较少。

影响： 响应速度

我的经验： 我对一两个模型尝试了两种格式，但个人没有感受到太大差异。这可能是因为我的评估方式非结构化——另一方面，正如任何用户体验研究人员会告诉我们的，感知到的速度最终才是最重要的，而不是时钟显示的时间……

量化

量化会压缩模型权重以减少文件大小，以牺牲一定质量换取更小的RAM占用。量化级别通常用Q4 / Q6 / Q8或4BIT / 6BIT / 8BIT在模型名称和描述中标记，数字越小表示压缩程度越高。最近最新的热点是模型的QAT（量化感知训练）变体，这些模型在训练过程中模拟了量化过程进行训练。它们旨在比标准量化更好地保持质量。

影响： 所需RAM量；响应速度；响应质量

我的经验： 我下载的所有模型都是Q4 / 4BIT级别的，我还没时间尝试不同的变体。我也还没尝试过QAT版本的。

架构

MoE（混合专家） 模型拥有很大的总参数量，但在推理时只激活其权重的一个子集，因此一个35B的MoE模型所需的RAM显著更少，运行速度也快于35B的dense模型。

影响： 所需RAM量；响应速度

我的经验： Qwen3.6 35B MoE模型在我使用过的模型中，在参数量与RAM使用之间取得了迄今为止最好的平衡，因此在可运行性和结果质量上也很出色。这可能要归功于MoE架构，我不太确定。架构或许也能解释我的一个体验：在64GB机器上，模型展现的编程能力比在48GB机器上更好——可能是因为它在那里加载了更多专家？我不确定这是否正确，但这是目前我唯一合理的假设。

上下文窗口大小设置

上下文窗口大小通过KV缓存占用额外的RAM（超出模型权重），并且会随着上下文长度增长而增加。运行时中配置的默认大小对于智能体式编程来说太小了，必须设置为至少32K，甚至64K。

影响： 任务规模与复杂度；所需RAM量；响应速度；使用推理的能力

我的经验： 我试着看看能设置多小。对于小任务，我有时可以用32K，但经常需要增加到64K，所以这似乎是一个不错的默认最小值。由于模型本身已经逼近我可用RAM的极限，我不确定还能增加多少，即使在64GB机器上也是如此……所以，尽管许多模型理论上支持更大的窗口，实际使用中会受到内存限制。

使用的模型列表

编程领域的热点一直是Qwen3和Gemma 4，所以我选择的就是这些。

Qwen3

• Qwen3.6 35B-A3B MoE Q4 GGUF (22 GB)
• Qwen3.6 Coder Next 80B MoE GGUF (45 GB)

Gemma 4

• Gemma 4 12B Q4 GGUF (7.5 GB)
• Gemma 4 26B 4BIT MLX (15.6 GB)
• Gemma 4 31B 4BIT MLX (29 GB)

运行时

运行时负责模型的发现、配置和加载。它还决定了一个实际问题：我们如何将框架与模型集成。通常的做法是启动一个web服务器，提供一系列框架支持的常见API，然后将该web服务器的localhost URL配置为框架中的一个模型提供商。框架支持最广泛的是OpenAI API，但例如Claude Code期望的是 Anthropic 的 Claude API (https://platform.claude.com/docs/en/api/messages)。

影响： 配置和发现的便利性；与框架集成的便利性；响应速度

图2：LM Studio中的“开发者”视图，显示了一个正在运行的服务器以及到目前为止描述的许多因素（提供商URL、模型大小、API、上下文窗口大小配置）

我的经验： 虽然我以前用过其他运行时，但我目前又回到了使用LM Studio (https://lmstudio.ai/)，主要是因为它的用户体验。关于哪个运行时针对哪种硬件和哪种模型进行了最优化以获得更高速度，有很多细节和门道。但回想一下运行本地模型的更广泛可行性，用户体验在这方面起着巨大的作用。顺便提一下，我的同事中最常提到的替代方案是oMLX (https://omlx.ai/)。

框架（Claude Code、OpenCode、Pi、……）

编程框架在向上下文窗口中注入多少额外内容（系统提示、工具数量）方面可能存在显著差异，这在本地资源受限的情况下会成为一个更大的问题。我们围绕框架的扩展（例如，启用了多少技能或MCP服务器）也会产生影响。每个扩展的描述都会被发送给模型，同样会占用上下文窗口的空间。

我在上面提到，小型模型在工具调用上仍有困难——而且每个框架对基本工具的模式都略有不同，这很可能没有帮助。以编辑文件为例：

• Pi：old_text 和 new_text（参见 here (https://github.com/earendil-works/pi/blob/main/packages/coding-agent/src/core/tools/edit.ts)）
• OpenCode：oldString 和 newString（参见 here (https://github.com/anomalyco/opencode/blob/dev/packages/opencode/src/tool/edit.ts)）
• Claude Code：old_string 和 new_string（至少我这样问它时，它确实是这么说的）

最后，并非所有框架都容易支持本地模型的集成。开源工具通常是首选，但Claude Code也可以指向本地提供商。GitHub Copilot似乎在其CLI中支持这一点 (https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/use-byok-models)，我认为在Cursor中也可以覆盖OpenAI基础URL并将其指向localhost。

影响： 所需上下文窗口大小；工具调用成功率；可集成性

我的经验： 在尝试中，我使用了OpenCode和Pi。我避开了Claude Code，因为它似乎会明显地占用上下文窗口 (https://portkey.ai/blog/the-harness-tax/) 不少空间。

接下来

在接下来的备忘录中，我将更深入地探讨我交给模型的任务类型以及我的经历。

先预览一下我的总体结论：像这样使用小型模型仍然相当混乱且难以评估。得出结论的过程令人沮丧，因为结果取决于太多因素。因此，我会说，对于不想花太多时间的开发者来说，它仍然没有准备好提供简单的“即插即用”体验。

不过，基于这次经历，我确实找到了一个现在在本地使用的首选模型：Qwen3.6 35B MoE。在我尝试过的模型中，它在能力、速度和RAM占用之间提供了最佳的平衡。

更多内容敬请期待！