2026年8月最适合编程的本地 LLM（按显存）：Qwen3-Coder 30B、gpt-oss-20b、Qwen 2.5 Coder 7B

2026 年 8 月最适合编码的本地 LLM，首先由你的 VRAM 决定。如果你有一张 24GB 显卡——RTX 3090 或 4090——就运行 Qwen3-Coder-30B-A3B-Instruct：总参数 30B，每个 token 仅激活 3.3B，262,144 token 的上下文窗口，并且是我们可验证的最佳全能本地编码成绩。在 16GB 上则是 gpt-oss-20b，OpenAI 的 Apache-2.0 混合专家模型，约 14GB 即可完全放入 GPU，实测约 140 token/秒。在 8GB 上则是 Qwen2.5-Coder-7B，约 4.7GB 的可靠主力。本页其余内容是推理过程、实测数据，以及这些选择各自会出错的具体情形。

头版做对了什么——又忽略了什么

目前针对“最适合编程的本地 LLM”的排名，混合了一篇真正有用的文章和大量靠域名权重撑起来的内容。Tembo 的指南（2026 年 6 月 5 日）框架是对的——它按 8GB / 12–16GB / 24GB 分档来组织，并最终落在 Qwen Coder 系列上——但它没有发布这些本地模型的基准分数、每秒 token 数、上下文窗口大小，也没有按 RAM 给出 Apple Silicon 选择。一个 GitHub 评估工具（gauravvij/local-llm-coding-eval）有真实数字，但没有结论，而且只在 CPU 上运行。其余的是单人作者的观点文章（XDA、Yahoo Tech）和内容单薄的榜单文章（apidog、Security Boulevard、SitePoint），它们靠域名权重排名，而不是靠实用性。

他们全都跳过的东西，按让你付出代价的大小排序：

• 智能体能力差距。代码生成与驱动智能体完成跨多文件改动，并不是同一种能力。第一页几乎没有提到它；而这恰恰决定了你最终是保留还是卸载一个模型。

• 上下文窗口。 智能体编程在加载文件和测试输出时会消耗大量 token。在追问它能适配多长上下文之前，“30B 能塞进 24GB”的说法毫无意义。

• 量化数学。没人解释过，4 位量化大约需要参数量（以 GB 计）的显存，也没人说明 Q3 是以细微的语法错误为代价来换取显存。

• 实测速度。很少有文章会为其推荐的模型给出 tokens/sec，而那些确实给出的文章又彼此差异巨大，因为上下文和量化会改变一切。

• 当本地模型是错误选择时。一项针对 15,000 行 Flutter 应用（EPAM）的 2026 年实地测试仍表明，云端前沿模型能在最难的多步骤重构中胜出。没有一篇榜单文章会告诉你何时该停手。

大多数清单文章略过的显存计算

让这篇文章里其他所有数字都变得清晰可读的经验法则：在 4 比特量化下，模型所需的显存大致是其参数量对应的 GB 数——7B ≈ 5GB，30B ≈ 18GB 以上，这还未计入 KV 缓存的开销。Q4 是编程场景的最佳平衡点；Q3 及更低精度虽能节省显存，却会明显引入细微的语法错误。而 KV 缓存会随上下文窗口增长，这正是为什么“30B 能塞进 24GB”只有在明确指定上下文长度时才成立。

混合专家模型改变了计算方式，而这对下面两个重要选择至关重要。总参数量决定占用空间；激活参数量决定速度。这就是为什么 Qwen3-Coder-30B-A3B（总参数 30B，激活 3.3B）和 gpt-oss-20b（总参数 20.9B，激活 3.61B）实际感受都远快于其在磁盘上的权重所暗示的速度，而 DeepSeek V4 Flash——总参数 284B，激活 13B——尽管 API 便宜，却不太适合本地部署。

24GB 显存：Qwen3-Coder 30B

Qwen3-Coder-30B-A3B-Instruct是目前我们能指出的最强全能本地编码模型。它于2025年7月由阿里巴巴Qwen团队以Apache 2.0许可发布，是一款混合专家（MoE）模型，总参数量300亿、每token激活33亿，上下文窗口为262,144个token，4位量化下占用约17–20GB——这在24GB显卡上仍留有充足余量，可容纳长时间编码会话所需的KV缓存。

在我们最信任的独立本地测试框架（gauravvij/local-llm-coding-eval，四个模型通过 Ollama 在 CPU 上本地运行）上，qwen3-coder:30b 的代码生成得分为 80%，工具选择为 77%，智能体准确率为 80%——这是四个模型中最均衡的结果，也是唯一一个同时在这三项任务上都表现强劲的模型。第三方跟踪器汇总其 SWE-bench Verified 约为 50.3，Aider Polyglot 为 66.2，LiveCodeBench v6 为 58.9；请将这些视为第三方汇总数据，而非阿里巴巴的官方数字——对于该模型，Qwen 公布的也只有官方数字。

实测速度会因硬件不同而差异很大。最有用的数据点：一个社区 TurboQuant 配置在 8GB RTX 3060 Ti 上运行它，在完整 262K 上下文下生成速度约为 29 token/秒；而 oMLX 基准测试测得，4-bit MLX 构建在 M4 Pro（48GB）上、1K 上下文时为 73.6 token/秒，到 64K 上下文时降至 13.5 token/秒。在普通的 Ollama 配置中，24GB 显卡上你应该预期的是每秒几十个 token 的范围，而不是每秒几百个——这就是在家运行一个接近前沿水平的编码模型所付出的代价。

需要坦率说明的是：它不是速度最快的本地编程模型，而且已经推出了更新的 Qwen3-Coder-Next，面向托管和 CLI 使用，而非量化本地安装。但就单卡上的智能体式、仓库级工作而言，Qwen3-Coder-30B 是当下之选。

16GB 显存：gpt-oss-20b

在 16GB 显卡上，答案是 gpt-oss-20b——而且优势毫无悬念。它由 OpenAI 于 2025 年 8 月 5 日在 Apache 2.0 许可下发布，是一个混合专家（Mixture-of-Experts）模型，总参数量为 20.9B，每个 token 激活 3.61B 参数，上下文窗口为 131,072 个 token，其原生 MXFP4 量化版本约为 14GB。这是决定性的事实：它能在 16GB 显卡上 100% 在 GPU 上运行，没有任何部分溢出到系统内存。

为什么模型常驻 GPU 比任何基准测试都更重要：能完全装入显存的模型，比需要卸载的模型快 3–11 倍。一项独立基准测试记录到，gpt-oss-20b 在 RTX 4080 上达到 139.93 tokens/秒——约为相同占用规模下稠密替代方案的 2.8 倍——而一位 2026 年测试者的评分给它打出了 52.1 的“智能指数”，称其在 16GB 级别的专业编程和调试方面无可匹敌。它的占用非常吃紧，所以要单独运行它，并保持适度的上下文长度；当上下文窗口接近上限时，质量会下降。

在 16GB 显存上的智能体式替代方案是 Devstral 24B（devstral-small-2:24b），它是 16GB 级别本地编程模型中唯一公布了 SWE-bench Verified 成绩的——46.8%——但速度很慢，通常需要 CPU 卸载，速度约为 18 tokens/秒。如果你的工作是跨文件的智能体式编辑，并且能接受这样的速度，那 Devstral 值得占一席之地；如果你想要速度加上干净的代码，gpt-oss-20b 是更好的默认选择。稠密的 14B 模型——Qwen3-Coder 14B 或 Q5 量化的 Qwen2.5-Coder 14B——则是舒适又廉价的备选方案。

8GB 显存：Qwen 2.5 Coder 7B

在 8GB 显存上，最实在的答案就是 Qwen2.5-Coder-7B：7B 参数在 Q4_K_M 量化下约占用 4.7GB，原生上下文为 32,768 个 token，可扩展至接近 128K，并且在 7B 级别中拥有最强的代码补全基准测试成绩。它是一个较旧的模型——发布于 2024 年 11 月——但这没关系，因为在 8GB 这个范围内，还没有更新的模型能取代它的地位。社区测试显示，在 RTX 4060 或 3070 上其速度约为 50 tokens/sec；2026 年 3 月一项独立的 RTX 4060 测试测得 28–35 tokens/sec，这一差异几乎完全由上下文设置造成。

在 8GB 上有三件事很重要，而在其他情况下并非如此。首先，将上下文限制在 4–8K：导致 8GB 显卡 OOM 的是 KV 缓存，而不是权重——有项基准测试显示，仅靠限制上下文，速度就从约 3.6 tokens/秒跃升至约 37 tokens/秒。其次，用 ollama ps 确认模型 100% 在 GPU 上；任何 CPU 分担都意味着速度骤降。第三，用 Q4_K_M，而不是 Q3——Q3 的语法错误带来的代价比节省的显存更大。

2026 年值得注意的进展是，Qwen3-Coder-30B-A3B-Instruct现在可以通过 TurboQuant KV 缓存压缩塞进 8GB 显存——有社区配置在 RTX 3060 Ti 上、完整 256K 上下文下测得约 7.5GB 和约 29 tokens/sec。它确实能用，但操作相当繁琐，因此我们不建议将其作为默认方案。如果你想要更新的开箱即用选项，Qwen3 8B（约 5.2GB，混合思考模式）在通用推理上比 Qwen2.5-Coder-7B 略有提升，但在纯代码方面仍稍逊一筹。

那 Apple Silicon 呢？

统一内存让这笔账只朝一个方向变化：容量上去了，生成速度下来了。48GB 的 M4 Pro 能装下 16GB Windows 显卡装不下的模型，但在长上下文下生成 token 的速度要慢得多。我们手上的数据是：Qwen3-Coder-30B-A3B-Instruct 的 4-bit MLX 版本在 M4 Pro 上，1K 上下文时占用 16.6GB，64K 时占用 25.5GB，随着上下文增长，生成速度从 73.6 tokens/秒降到 13.5（oMLX 基准测试）。gpt-oss-20b 可以轻松装进 16GB 统一内存，是 Mac 上不错的选择。如果你想在 Apple 芯片上跑多模态，Gemma 4 12B 在约 16GB 统一内存中运行，支持 256K 上下文——如果你的编码工作常要对照图片密集的文档，这是最强的本地选择。

独立的数字：代码生成并不是关键技能

我们找到的最清晰数据，是一个值得完整引用的本地基准测试。gauravvij/local-llm-coding-eval 通过 Ollama 在本地 CPU 上运行了四个模型，不使用云——涵盖代码生成、函数调用和多步智能体任务——其结果与“代码生成数字越大越赢”的直觉相悖：

• Qwen3.6 27B（qwen3.6:27b，稠密，约 17GB）：80.0% 代码生成，84.6% 工具调用，100% 智能体——最全面的全能选手。

• Qwen3.6 35B A3B（qwen3.6:35b-a3b，MoE，约 18GB）：代码生成 70.0%，工具 84.6%，智能体 100%。

• Qwen3-Coder-30B-A3B-Instruct（qwen3-coder:30b，MoE，约17GB）：80.0% 代码生成，76.9% 工具，80% 智能体——最均衡。

• DeepSeek-Coder-V2 33B（deepseek-coder:33b，稠密，约 18GB）：90.0% 代码生成——四者中最佳——但智能体 10%，在多步任务上排名垫底。

最后一句就是全部教训。一个在纯代码生成上拔得头筹、却在智能体任务上一败涂地的模型，就是你在第一次“读这个文件、改这个函数、跑测试”的循环之后就会卸载的模型。评判一个本地编码模型，要看智能体那一列，而不是代码生成那一列。

在本地运行何时是错误的决定

本地优先是合适的默认选择，适用于隐私、离线工作、零边际 token 成本，以及延迟比质量上限更重要的自动补全。但在特定且可识别的情境中，它是错误的选择——而这正是第 1 页跳过的那一节：

• 最难的智能体工作仍会让你败下阵来。EPAM 对一款 15,000 行 Flutter 应用开展的 2026 年实地测试发现，云端前沿模型（GPT-5.3-codex）在最复杂的多步重构任务上仍优于本地模型。如果你每天的工作就是对遗留代码进行长达八小时的重构，那么本地模型尚未准备好。

• 你的上下文需求超出了你的显卡。一个加载整个仓库的编码智能体会远远超出 16GB 显卡所能容纳的 KV cache。Qwen3-Coder-30B 的 256K 上下文正是它能在 24GB 档位胜出的原因——更小的显卡会在这场竞争中早早出局。

• 你不能一直守着硬件。硬件是真金白银：一块 24GB 显卡属于 700–1,600 美元这一档，还要加上电费和维护成本。在低用量下，调用 API 比耗电更便宜。

• DeepSeek V4 Flash 就是明证。其总参数量为 284B，仅 4 位权重就约占 140GB——这绝不是消费级显卡能跑的模型，毫无疑问。它的 13B 激活设计正是其 API 速度快、价格低的原因：每 100 万 token 仅 $0.15 / $0.29（MIT，100 万上下文）。对这款模型来说，“本地运行”是个错误的问题；API 才是关键所在。

• 团队需要一致性。如果四位工程师各自运行不同模型的不同量化版本，“只在我机器上能跑”就会变成构建隐患。共享的 API 端点为你提供一个确定性的目标。

如果你想了解这个问题的 API 侧答案——当本地模型并非合适取舍时，默认使用哪个云端编程模型——我们在 best-LLM-for-coding 指南中单独讨论过；我们的 AI-coding-agents 文章也介绍了可与这些本地模型配合使用的 Cline 和 OpenCode 等框架。

如何在购买该卡之前进行测试

最省钱的判断方式是在购买硬件之前先用自己的提示词跑一跑。Ollama 或 LM Studio 能在几分钟内让这三款中的任意一款跑起来，而真正重要的测试是你仓库里的真实文件，而不是基准测试。路由器在紧邻的决策上自有其价值：当你把本地候选模型与托管的前沿模型进行比较时，一个端点就能让你用同一个提示词同时跑两者，而无需来回管理多个密钥。在 OrcaRouter 上，DeepSeek V4 Flash 按提供商标价原样透传——每 100 万 tokens $0.15 / $0.29，0% 加价——并带有自动故障转移，这使它成为衡量“我的本地模型真的比 $0.15 的 API 更好吗？”的廉价而诚实的标尺。

一个坦率的提醒：OrcaRouter 不托管 Qwen3-Coder-30B-A3B-Instruct 或 gpt-oss-20b。如果你的目标严格来说是离线运行，那路由器对你无关紧要——自己托管就完事了。如果你的目标是在花钱买显卡之前，把同一个开放权重模型与前沿模型做 A/B 对比，那么路由器的工作是对比，而不是托管。

底线

先看显存，再看模型质量。24GB 显存上，运行 Qwen3-Coder-30B-A3B-Instruct——它是目前最强的全能本地编码模型，具备智能体工作所需的 256K 上下文。16GB 显存上，运行 gpt-oss-20b——这是少有的既快又能完全放在 GPU 上的模型。8GB 显存上，运行 Qwen2.5-Coder-7B，并把上下文长度保持适中。评判它们时，要看“智能体”这一列，而不是“代码生成”这一列；同时要接受：最难的多文件重构仍然得靠云端。以上数据截至 2026 年 8 月 10 日有效——花钱之前请重新核实产品阵容和标价，因为这个领域每周都在变化。