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

2026年8月最适合编程的本地LLM，首先由你的显存决定，其他因素都排在后面。如果你有一张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 tokens/秒。在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/秒数据，而那些给出的，结果又大相径庭，因为上下文和量化方式会让一切截然不同。

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

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

让本文中其他所有数字都能读懂的经验法则：在 4 比特量化下，模型大约需要与其参数量相当的 GB 数——7B ≈ 5GB，30B ≈ 18GB+，这还没算 KV 缓存的开销。Q4 是编程的最佳平衡点；Q3 及以下能节省显存，但会带来可测量的细微语法错误。而 KV 缓存会随上下文窗口增长，这就是为什么“30B 能装进 24GB”只在你实际必须指定上下文长度时才成立。

混合专家（MoE）改变了背后的计算逻辑，而这对于下面两个重点选项至关重要。总参数量决定占用空间，激活参数量决定速度。这正是为什么 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是目前我们能找到的最强全能本地编程模型。它由阿里巴巴的 Qwen 团队于 2025 年 7 月以 Apache 2.0 协议发布，是一个混合专家（MoE）模型，总参数量为 30B，每个 token 激活 3.3B，上下文窗口达 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；请把这些视为汇总数据，而非 Alibaba 的官方数字；后者才是 Qwen 为该模型公布的全部内容。

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

诚实的提醒是：它不是最快的本地编码器，而且已有更新的 {{1}}Qwen3-Coder-Next{{/1}}，面向托管和 CLI 使用，而非量化本地安装。但若要在单卡上进行智能体式、仓库规模的工作，{{2}}Qwen3-Coder-30B{{/2}} 是当下的选择。

16GB 显存：gpt-oss-20b

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

为什么 GPU 驻留比任何基准测试都更重要：能装进显存的模型比需要卸载的模型快 3–11 倍。一项独立基准测试记录了 gpt-oss-20b 在 RTX 4080 上达到 139.93 tokens/sec——约为同等占用下稠密替代方案的 2.8 倍——而 2026 年一位测试者的评分给了它 52.1 的“智能指数”，称其在 16GB 级别中用于专业编码和调试无与伦比。它的占用很紧张，因此要单独运行它并保持适度的上下文；在窗口接近上限时质量会下降。

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

8GB 显存：Qwen 2.5 Coder 7B

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

在 8GB 上有三件事很重要，而在别处则不然。第一，把上下文限制在 4–8K：让 8GB 显卡 OOM 的是 KV 缓存，而不是权重——有个基准测试仅靠限制上下文，速度就从约 3.6 跃升到约 37 tokens/sec。第二，用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/秒。它确实能用，但调校起来相当麻烦，因此我们不建议将其作为默认方案。如果你想要一个更新的开箱即用选项，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 Silicon 上使用多模态，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 成本，以及在延迟比质量上限更重要的自动补全场景中的正确默认选择。但在某些具体且可识别的情况下，它是错误的选择——而这正是第一页会跳过的那一节：

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

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

• 你没法伺候硬件。 硬件可是真金白银：一块 24GB 的显卡就属于 700–1,600 美元这一档，还得加上电费和维护成本。用量低的时候，调用 API 比付电费还划算。

• DeepSeek V4 Flash 就是证明。 在总参数量 284B 的情况下，仅 DeepSeek V4 Flash 的 4 位权重就大约有 140GB——它不是面向消费级显卡的模型，就这样。它采用 13B 激活设计，这正是其 API 快速且便宜的原因——每 100 万 tokens 价格为 $0.15 / $0.29（MIT，100 万上下文）。对于该模型来说，“在本地运行”是个错误的问题；API 才是重点。

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

如果你想要同一问题的 API 侧答案——当本地并非合适的取舍时，默认使用哪个云端编码模型——我们已在最佳编码 LLM 指南中单独讨论过，而我们的 AI 编码智能体文章则涵盖了可与这些本地模型配合使用的 Cline 和 OpenCode 等框架。

购买前如何测试卡片

做出决定的最便宜方式是在购买硬件之前先运行你自己的提示。Ollama 或 LM Studio 能在几分钟内让这三个选项中的任何一个运行起来，而真正重要的测试是你仓库中的真实文件，而不是基准测试。路由器在相邻的决策中占有一席之地：当你将本地候选模型与托管的前沿模型进行比较时，一个端点就能让你在不来回切换密钥的情况下，用同一个提示词同时测试两者。在 OrcaRouter 上，DeepSeek V4 Flash 以其提供商列表价格原样提供——每 1M 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 日有效——掏钱之前请重新核实产品阵容和标价，因为这个领域每周都在变。