Viability of local models for coding

本地模型在编码中的可行性

Birgitta Böckeler

Birgitta 是 Thoughtworks 的高级工程师和 AI 辅助交付专家。她拥有 20 多年软件开发、架构和技术领导经验。

本文属于「探索生成式 AI」系列，该系列记录了 Thoughtworks 技术人员在软件开发中使用生成式 AI 技术的探索过程。

2026年7月7日

直到最近，我已经有很长时间没有尝试在本地运行模型了，因为每次尝试都让我感到非常失望。不过大约一个月前，我重新投入其中——网上关于这些模型进步的宣传实在太多了，它们现在运行起来更加可行，而且有些模型在编码方面表现得非常出色。因此，这将是我过去四周使用这些模型的个人体验分享。

在本备忘录中，我将从更一般的介绍开始，逐步分析影响这些模型编码可行性的关键因素。后续备忘录中，我将详细描述我的实际使用体验。

范围

我的主要关注点是这些模型对编码的实用性，而不仅仅是自动补全功能，更关注智能代理编码能力。其次，我关心这些模型对开发者的友好程度，特别是那些不想深入研究大量规格说明和额外工具配置的开发者。

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

• Apple M3 Max，48GB RAM
• Apple M5 Pro，64GB RAM

影响可行性的因素

影响模型表现的因素众多，这使得在现有资源限制下评估最佳配置变得非常繁琐。同时，当人们在线分享这些模型的成功案例时，区分有效信息和噪音也变得极其困难。

我发现一个特别令人困惑的现象：在自动化评估设置中，某款模型在性能更强的机器上（不仅仅是速度更快，生成的代码质量也更好）表现明显优于其他模型，尽管所有其他设置都相同。

我将先给出一个概述，然后详细分析每个因素。

xml version="1.0" encoding="UTF-8"?

请勿使用除 draw.io 以外的编辑器编辑此文件

svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"

图1：可能影响结果的众多因素 - 点击或悬停方框以高亮箭头。

• 可运行性：RAM 是核心限制因素。我使用的模型大小在 15-25GB 之间，上下文窗口最大为 64K，使用 OpenCode 和 Pi 框架（无 Skills 和 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 内存的机器上，我使用了约 300 亿参数的模型，上下浮动约 50 亿。在 64GB 内存的机器上加载的最大模型是 Qwen3 Coder Next 80B（MoE），它在解决我给它的任务时比小模型表现好得多——但在我继续对话后就崩溃了。

推理能力

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

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

我的经验：我尝试的所有模型都有推理能力，在大多数实验中默认是开启的。但我也经常发现它们在推理链中陷入无尽循环，尤其是较小的模型。（“等等，...”，“实际上，...”，“但是等等，...”）因此我也进行了几次关闭推理功能的自动化测试——结果令人惊讶，不仅速度更快（这符合预期），而且表现甚至略好！这提醒我们推理并非总是必要的，有时甚至可能适得其反。

工具调用能力

对于代理使用，模型必须能够可靠地生成符合 harness 期望模式的结构化工具调用语法。未经专门训练或微调用于工具调用的模型通常会产生格式错误的调用。

影响：使用智能代理工具的能力

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

格式

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

我的体验：我尝试了其中一两个模型的两种格式，但个人感觉差异不大。这可能与我进行的非结构化评估方式有关——另一方面，正如任何用户体验研究员都会告诉我们的，感知到的速度最终才是重要的，而不是时钟显示的数值...

量化

量化通过压缩模型权重来减小文件体积，以牺牲部分质量换取更小的内存占用。量化级别通常在模型名称和描述中标注为Q4 / Q6 / Q8，或4BIT / 6BIT / 8BIT，数字越低表示压缩率越高。最近最热门的新技术是QAT（量化感知训练）模型变体，这些模型在训练过程中模拟量化进行训练。理论上它们应该比标准量化更好地保留质量。

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

我的体验：我下载的所有模型都是Q4 / 4BIT版本，还没有机会尝试其他变体。我也还没尝试过QAT版本。

架构

MoE（专家混合）模型虽然总参数量很大，但在推理时只激活部分权重，因此35B MoE模型所需的RAM远少于35B密集模型，运行速度也更快。

影响：所需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)

运行时

运行时负责模型发现、配置和加载。它还决定了一个实际问题，即我们如何将工具链与模型集成。通常这是通过启动一个提供工具链支持的典型 API 的 Web 服务器来实现，然后将该 Web 服务器的本地 URL 配置为工具链中的模型提供方。工具链最广泛支持的是 OpenAI API，但例如 Claude Code 则期望使用 Anthropic 的 Claude API。

影响因素：配置和发现的便捷性；与工具链的集成便捷性；响应速度

图 2：LM Studio 中的“开发者”视图，显示正在运行的服务器和迄今为止描述的许多因素（提供方 URL、模型大小、API、上下文窗口大小配置）

我的体验：虽然我过去使用过其他运行时，但目前又回到了使用 LM Studio，主要是因为其用户体验。有很多关于哪种运行时对哪种硬件和模型类型最优化的细节，以进一步提高速度。但回顾本地模型运行的总体可行性，用户体验起着巨大作用。就我同事最常提到的替代方案而言，oMLX 是其中之一。

工具链（Claude Code、OpenCode、Pi 等）

编码工具链在注入上下文窗口的开销（系统提示、工具数量）方面可能差异显著，这在我们资源受限的本地环境中会变得更为严重。我们围绕这一点扩展的工具链也会产生影响，例如有多少技能或 MCP 服务器处于活动状态。每个工具链的描述都会发送给模型，再次占用上下文窗口的空间。

我之前提到过小型模型在工具调用方面仍然存在困难，而且每个工具链的基本工具可能都有略微不同的模式，这可能也不利于问题解决。以编辑文件为例：

• Pi：old_text 和 new_text（见此处）

• OpenCode：oldString 和 newString（见此处）

• Claude Code：old_string 和 new_string（至少当我询问它时是这样说的）

最后，并非所有工具链都轻松支持本地模型的集成。开源工具通常是首选，但 Claude Code 也可以指向本地提供方。GitHub Copilot 似乎支持其 CLI，我认为在 Cursor 中也可以通过覆盖 OpenAI 的基础 URL 并指向 localhost 来实现。

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

我的体验：在我的尝试中，我使用了 OpenCode 和 Pi。我避开了 Claude Code，因为它似乎会显著增加上下文窗口的负担。

后续内容

在我的下一封备忘录中，我将更深入地探讨我给予模型的任务类型以及我的体验。

我总体结论的预览：以这种方式使用小型模型仍然相当混乱且难以评估。得出结论的过程令人沮丧，因为结果取决于太多因素。因此，我认为对于不想花太多时间的开发者来说，它目前还不足以实现简单的“即插即用”体验。

然而，基于这次体验，我现在本地使用的一个首选模型是 Qwen3.6 35B MoE。它在所有我尝试的模型中提供了能力、速度和内存占用的最佳平衡。

后续内容敬请期待！

致谢

特别感谢 Jigar Jani 和 Syed Atif Akhtar 的审阅及宝贵意见。

GenAI（Claude 和 Claude Code）用于研究及语言润色。

最新文章（7月7日）：

本地模型在编程中的可行性

往期文章：

软件工程循环中的人类与智能体 /