本地AI编程模型实测：18G显存能否跑赢Opus？

为什么选错本地编程模型代价翻倍

当下最被推荐的本地编程模型之一是能装进游戏显卡、免费又快速的 Gemma 系列。但在 Qwen 官方发布的对比表格里，它只修复了 17.4% 的真实 GitHub issue；而紧挨着它的 Qwen 模型得分高达 73.4%。同样一张桌子上，差距四倍。那么你到底该下载哪一个？

一位国外UP主围绕这个问题做了系统性梳理，覆盖 16GB、24GB、32GB、64GB 四档显存，展示了真实的贪吃蛇代码生成测试、速度数据，以及一个几乎能骗过所有人的跑分陷阱。关键在于——视频里的每一个数字都标注了来源，并非作者自测。

选错模型的代价是双重的：你下载了一个 19GB 的文件，结果你的编程 Agent 在一个它根本修不了的 bug 上反复打转。更麻烦的是，现在排名靠前的很多榜单，本身已经过时了。

第一条规则：模型必须足够新

UP主定下的第一条铁律：视频里每个模型都必须是过去 12 个月内发布的（以 Hugging Face 页面为准）。这一条直接淘汰了两个老牌热门——Qwen3 Coder 30b 和 GPT-OSS 20b，而它们至今仍出现在近几个月的各类推荐榜单里。

最终入选的七个模型包括：GLM 4.7 Flash 与 Qwen3 Coder Next、Gemma 4 26b 与 Gemma 4 31b、Qwen3.6 系列、Gemma 4 12b，以及最新的 Qwen3.8 27b。保持模型的时效性，是避免被过时榜单误导的第一道防线。

跑分陷阱：谜题分数 ≠ 修复仓库能力

这是全片最核心的洞察。不同基准测试考察的能力天差地别：

SWE-Bench Verified：给模型真实的 GitHub issue，检查补丁能否通过测试
SWE-Bench Pro：更难的版本
Terminal Bench：命令行里的 Agent 任务
Live Code Bench：竞赛风格的解谜题

解谜题和修复你自己的代码仓库，完全是两回事。谷歌官方的模型卡给 Gemma 4 26b 的 Live Code Bench 打了 77.1%，看起来精英级别。但谷歌的卡上压根没有 SWE-Bench 分数。唯一能查到的来源是 Qwen 的模型卡：它给 Gemma 4 26b 的 SWE-Bench Verified 只打了 17.4，而同为 MoE 架构的 Qwen3.6 35b A3b 拿到 73.4——同级别模型，四倍差距。

Gemma在大型仓库任务上表现较弱

当然要公允地说，这个数字来自竞争对手在 Qwen 自家 Agent 环境下跑出的结果。但 Atomic Chat 的编程指南也佐证了同一结论：Gemma「在大型仓库任务上效果较差」。谜题更强，真实仓库更弱——这是贯穿全文的判断。

SWE-Bench Verified 是目前最接近「真实编程工作」的主流基准。它从 GitHub 上抓取真实的 bug report 和对应的修复 PR，让模型在不知道答案的情况下独立生成补丁，再用原始测试套件验证补丁是否真正修复了问题。这意味着模型不仅要读懂代码库的上下文，还要写出能通过已有单元测试的改动——单纯记住语法规则或解出算法谜题是远远不够的。相比之下，Live Code Bench 的题目更接近 LeetCode 竞赛：给定独立函数签名，写出符合规范的实现，几乎不涉及跨文件依赖、遗留代码风格或增量修改。两个基准考察的认知路径根本不同，这也解释了为什么一个模型能在谜题榜上遥遥领先，却在真实仓库任务里一败涂地。

显存与文件大小：16GB 机器已经很挤

根据 Ollama 官方库页面的数据：Gemma 4 12b 约 8GB，Gemma 4 26b 为 16–19GB，Qwen3.8 27b 为 18GB，GLM 4.7 Flash 为 19GB，Qwen3.6 35b 为 23–24GB，而 Qwen3 Coder Next 高达 52GB。

别忘了，这只是模型文件本身。你的上下文、编辑器和操作系统都需要额外内存。所以在一台 16GB 的机器上下载 16–19GB 的模型，已经相当勉强。

18GB 真的跑赢 Opus 了吗？

24GB 是最佳甜点区。Qwen3.6 27b（4月发布的 dense 模型）在 Qwen 卡上拿到 SWE-Bench Verified 77.2、SWE-Bench Pro 53.5、Live Code Bench 83.9，体积约 18–19GB。而最新的 Qwen3.8 27b 同样是 18GB，分数却跃升至 SWE-Bench Pro 61.7、Terminal Bench 2.1 为 73、Live Code Bench 90.3。

正是这张表宣称它在 SWE-Bench Pro 上击败了 Opus 4.6 Max：61.7 对 53.4。

对比表显示其在SWE-Bench Pro上击败Opus 4.6 Max

但请看脚注：Opus 的分数是官方上报值，而 Qwen 模型跑的是 Qwen 自己「修正、精炼」过的基准版本——测试根本不是同一个。所以不，一个 18GB 的文件并没有真的击败 Opus。

UP主转向独立来源 Artificial Analysis 的智能指数：Qwen3.8 27b 得 34，Qwen3.6 27b 得 21，Gemma 4 26b 得 17，GLM 4.7 Flash 得 15，Gemma 4 12b 得 14，Qwen3 Coder Next 仅 9（部分标注为估计值）。另一个关键细节：Artificial Analysis 指出 Qwen3.8 在测试中生成了至少 700 万 token，而中位数仅 82 万——它「想太多」。在本地机器上，每一个思考 token 都是你要等待的时间。

Artificial Analysis 智能指数（Intelligence Index）是一个由第三方机构针对多项能力加权合成的综合评分，涵盖编程、推理、指令遵循等维度，并统一在相同环境下运行测试，目的是提供一个不受厂商控制的横向对比基线。与厂商自测的单一基准相比，它更难通过「挑选有利测试」来刷高分。文章中 Qwen3.8 27b 得 34、Gemma 4 26b 得 17 的差距，在这一语境下比厂商卡上的数字更具参考价值。值得注意的是，部分分数被标注为「估计值」，说明并非所有模型都已完成完整测试，选型时仍需结合其他来源交叉验证。

分档推荐与速度实测

32GB 可以跑 Qwen3.6 35b A3b（23–24GB），每 token 仅激活约 30 亿参数，所以很快，SWE-Bench Verified 为 73.4。替代方案是 GLM 4.7 Flash（19GB，MIT 许可证），SWE-Bench Verified 为 59.2，不错但落后于 Qwen。

GLM 4.7 Flash 采用MIT许可证

真实输出测试里，Atomic Chat 给四个模型同样的提示：写一个能玩的贪吃蛇并玩到输。Gemma 4 26b 跑出约 136 token/s，dense 的 Qwen3.6 27b 约 47 token/s——同样提示，快了三倍。Qwen3.6 27b 做出了四者中最好的贪吃蛇（得分 80），但在第二项弹球物理模拟测试中，它是唯一失败的那个。而速度飞快的 Gemma 两项都通过了。

64GB 档，Qwen3 Coder Next 是 800 亿参数、仅 30 亿激活的巨兽，SWE-Bench Verified 为 70.2，但在 Atomic Chat 测试中仅 5.5 token/s，Artificial Analysis 上只得 9 分，低于 27b 模型。更大并不自动等于更好。

速度同样取决于运行时。据 Stridenote，Ollama 自己的测试显示 Qwen3.5 35b 切换到 Apple Silicon 的 MLX 后，从 58 token/s 跳到 112 token/s——同一个模型，速度几乎翻倍。

切换MLX后速度近乎翻倍

MoE（Mixture of Experts，混合专家）架构是理解「参数量大但速度快」这一现象的关键。传统 dense 模型每次推理都要激活全部参数；MoE 模型则将参数分成若干「专家」模块，每次只路由给少数几个专家处理，其余模块闲置。Qwen3.6 35b A3b 的命名正体现了这一点：总参数 350 亿，但每个 token 仅激活约 30 亿（A3b）。这让它在推理速度和显存占用上接近一个 30 亿参数的小模型，但因为专家总量庞大，知识容量和任务能力又接近更大的 dense 模型。MLX 是苹果针对 Apple Silicon 统一内存架构优化的机器学习框架，相比 Ollama 默认后端能更充分利用 M 系列芯片的带宽，因此同一模型在 MLX 下速度几乎翻倍并非意外。

速查表与四条验证法则

选型速查表：

16GB：Gemma 4 12b
24GB：Qwen3.6 27b，或 Qwen3.8 27b（如果你能等它思考）
32GB：Qwen3.6 35b（追求速度）
64GB：高精度的 Qwen3.8，或 Coder Next（如果你有耐心）

相信任何榜单之前的四条检查：

模型是否发布不足一年？
谁跑的基准测试——厂商还是独立第三方？
用的是哪个基准——真实仓库还是解谜题？
文件大小加上上下文余量是否放得下？

这套方法论的价值，甚至超过具体的推荐结果本身。在厂商各自为自己的模型挑选最有利基准的当下，学会分辨跑分的来源与性质，才是本地部署用户真正该掌握的能力。