每一篇“用本地模型替代 Claude Code”的指南开头都一样：一大片 SWE-bench 分数，一句得意洋洋的“我们距离前沿只差五个点”，外加一张 GPU 购物清单。我读过十几篇，也跑过其中大多数配置。它们倒也不算错。它们衡量的是容易衡量的东西，而不是决定你究竟能不能关掉 Claude Code 标签页的那个东西。

下面这个版本，没人会写进标题里——这是在真正把 Claude Code 和 Codex 指向本地模型干活之后得出的：

本地 LLM 写出一个正确的函数，已经是解决了的问题。本地 LLM 成为一个可靠的智能体——干净地发出工具调用，连续十次，跨越一次多文件编辑，且不偏离 schema——则还没有。而后者才是全部的工作。

所以让我们正经地来做这件事。我们会逐一过一遍 2026 年末真正重要的模型家族，每个家族真正适合什么，硬件现实，配置（现在只要 60 秒），没人截图展示的失败模式，以及一个成本模型，让你知道这到底能不能给你省下一分钱。还配了图表，因为一张得眯着眼看的数字表格，恰恰就是问题所在。

首先：为什么这件事突然就行得通了

2026 年有两件事变了，而这两件都不是“模型在 Twitter 上嗓门更大了”。

1. 混合专家（MoE）打破了硬件墙。一个稠密的 70B 模型，每生成一个 token 都要激活全部 70B 参数。而 MoE 模型有着巨大的总参数量，但每个 token 只触发其中一小片——Qwen 的 35B-A3B 激活约 3B。显存由你加载的文件大小决定；速度则由那一小片激活参数决定。于是一个过去需要服务器才能跑的模型，现在在一块游戏 GPU 上就能跑，量化之后，在笔记本上也能跑。

2. 智能体学会了说本地话。这是 2025 年那些帖子漏掉的部分。在2026 年 1 月，Ollama 原生支持了 Anthropic Messages API，随后 LM Studio 和 llama.cpp 也跟上了。这就是解锁点：Claude Code 不再需要一个代理垫片来和localhost通信。你只要把一个环境变量指向它，就能用了。管道工程不再是难的部分——这意味着对话终于必须越过“它会不会写代码”这个问题。

人人都引用的那个数字——以及它为什么误导你

SWE-bench Verified 是每条新闻标题里的那个数字，而 2026 年报告的数据确实挤满了前沿。

SWE-bench Verified for self-hostable models — vendor-reported, with the 24GB sweet spot highlighted

看那张图，故事似乎已经讲完了：单张 24GB 显卡上的模型就能达到约 77，与云端前沿的差距在舍入误差之内。但问题就在这里，而这正是整篇文章的重点：

SWE-bench 衡量的是“给定一个 bug，产出一个正确的补丁”。那是一项写作任务。它几乎完全没有说明当模型驱动你的编辑器时真正会出问题的四件事。

  1. 工具调用有效性——它能否发出格式良好、edit_file/run_command能被 harness 解析的调用，可靠地，而不是通常能？
  2. 长程一致性——第 11 次调用还记得第 2 次调用时的计划吗？
  3. 负载下的上下文——在 40K token 的真实仓库内容下质量还能保持吗，还是在远未达到宣称窗口之前就崩了？
  4. 指令遵循——当你说“别动测试”时，它真的不动测试吗？

这四项没有一项在排行榜上。而这四项正是你的本地环境感觉和演示不一样的原因。

⚠️把本文中的每个数字都当作厂商自报数据。不同的指南对同一个模型给出天差地别的分数，因为它们悄悄把 SWE-benchVerified换成了Pro或Terminal-Bench却从不说明。在因为一个百分比就买 GPU 之前，先去官方 SWE-bench 排行榜上核实。

值得了解的 7 个系列（以及每个系列实际适合什么）

按系列来思考，而不是单个 checkpoint——每个系列都有多个尺寸，正确的选择是既适合你的显卡又适合你任务的那个。

1. Qwen 3.x——本地编码的骨干

如果你只跑一个系列，那就是这个。Qwen 在编码和工具调用两方面都是开源权重的领先者，而这个组合才是关键。

  • Qwen 3.6 27B（稠密）——默认的自托管编码器。约 77% SWE-bench Verified，量化后约 22GB，可放进单张 24GB GPU 或 M 系列 Mac。可靠的工调用者。
  • Qwen 3.5 35B-A3B（MoE）——总参数 35B，激活约 3B。运行起来轻得惊人（Q4 下 8GB 显存），因为只有激活的那部分消耗算力。“笔记本上的前沿”头条选手。
  • Qwen3-Coder（30B-A3B / 480B-A35B / Next-80B-A3B）——代码专家线。30B 是极佳的日常主力；如果你有 64GB+ 统一内存或多 GPU，480B 是最强的开源编码器。

最适合：你的通用编码智能体、工具使用工作流，以及任何想要一个能把 80% 的工作做好的模型的人。弱点：没有明显短板——它是稳妥的默认选择。

2. GLM-4.x——预算有限时的长会话智能体

GLM 在以下方面超出其体量：长时间、工具密集的智能体运行，而 Flash 变体是真正可用的最轻量选择。

  • GLM-4.7-Flash——约 59% SWE-bench，可运行于5–8GB 笔记本。这是“我只有一块接近集显的 GPU”时并非玩具的选项。
  • GLM-4.6 / 4.x（MIT 许可证）——推荐用于长时间、多步智能体会话，这类场景中多次调用间的一致性比单次原始得分更重要。

最适合：笔记本级硬件、长时间智能体会话、偏好宽松许可证的公司。弱点：在困难的单次编码任务上上限低于 Qwen 27B。

3. DeepSeek V3.2 / V4-Pro——开源最高上限

DeepSeek 发布了最高的开源结果——约80.6% SWE-bench Verified（V4-Pro）——但只有在你的桌子里塞了一台服务器（80GB+）时它才算“本地”。

最适合：拥有服务器级硬件或团队自托管机器的纯硬核代码任务。弱点：不是消费级 GPU 模型；这是升级层级，不是日常主力。

4. Devstral Small 2——宽松许可证的主力

约 68% SWE-bench Verified，Apache-2.0，适配12–16GB。这是“我需要干净的许可证，而且它能在中端显卡上运行”的最佳选项，也是同尺寸下扎实的智能体编码器。

最适合：需要许可证确定性的商业使用、中端 GPU、智能体子任务。弱点：多文件推理的上限低于 27B 层级。

5. Kimi K2.x——长时程前沿（如果你有机架）

Kimi 面向长时程智能体工作，在更难的Pro基准测试上得分不错，但本地运行需要重度量化或服务器硬件。

最适合：在严肃硬件上的长时间自主运行。弱点：不是现实可行的单消费级 GPU 选择；基准数据来自Pro，所以不要把它们与上面的 Verified 数字直接对比。

6. GPT-OSS（20B / 120B）——OpenAI 的开源权重，原生支持 Codex

OpenAI 的开源权重系列可自然接入Codex CLI，通过--oss标志。20B 可在消费级硬件上运行；120B 属于服务器级。

最适合：已标准化使用 Codex、希望拥有零工具摩擦本地回退方案的团队。弱点：Qwen/GLM 在开源工具调用的可靠性上通常更胜一筹。

7. Gemma 4——轻量级通用模型

Gemma 4（12B / 27B）是面向较低硬件配置的通用模型——当你需要一个能力全面的全能选手而非代码专精模型时，它非常适合 16GB 的机器。

最适合：笔记本电脑、编码与写作混合使用、低显存设备。弱点：它是通用模型，而非编码专精模型——在困难的 SWE 任务上会落后于针对编码调优的模型。

（荣誉提名：**MiniMax M2.x，以智能体优先训练，定价激进——如果吞吐量/美元是你的约束条件，值得关注。）

效率拐点：更多硬件 ≠ 更好

下面这张图才真正应该驱动你的 GPU 决策——性能与达到该性能所需显存的对比。

Efficiency frontier: SWE-bench vs VRAM, showing the 24GB knee where returns flatten

曲线陡峭攀升至约 24GB，然后趋于平缓——480B 编码模型甚至在 Verified 上跌至低于27B 模型，却要消耗 3 倍的内存。教训是：单块 24GB 消费级 GPU 运行 Qwen 3.6 27B 是自托管的甜蜜点。超过这个点就是收益递减，除非你特别需要服务器级的上限。

排行榜隐藏的那堵墙：工具调用

正是这个发现重组了我挑选本地模型的方式。工具调用是一项与编写代码分开训练的技能。一个模型可以写出漂亮的函数，却仍然无法完成智能体所需的那一件事——在第一次尝试时就发出有效的工具调用，每次都如此。

Tool-calling reliability tiers by model size — directional, not a benchmark

证据所指向的结论：

  • 可靠性在约 4B 参数以下会断崖式下跌。低于 7B 的模型无论用哪个智能体框架包装，都会发出格式错误的工具调用。框架救不了一个无法格式化调用的模型。
  • 原生工具使用训练胜过外挂的语法约束。用工具模板训练的模型表现良好；外挂约束解码的模型会漂移。
  • 模型比框架更重要。把 Claude Code 换成 OpenCode 再换成 Codex，也修不好一个会把 JSON 搞乱的模型。
  • 多步链式调用才是它崩溃的地方。一次工具调用没问题。连续五次、每次依赖上一次，才是较小的本地模型开始幻觉调用的地方——凭空发明一个不存在的函数，或用漂移的参数重新调用一个函数——然后智能体陷入重试循环。

实际的取舍：对于智能体工作，需要一个来自一个原生工具训练家族的 14B–32B 模型。在 2026 年末，这压倒性地意味着Qwen，以及GLM-4.x和Devstral Small 2作为可信的备选。任何低于约 7B 的模型都只是一个伪装成智能体的聊天模型。

配置过程真的只要 60 秒

因为智能体现在本地就能对话，所以这显得平淡无奇——而这正是重点。

Claude Code → 本地模型（通过 Ollama）：

# 1. 拉取一个能力足够的编码模型
ollama pull qwen3-coder:30b

# 2. 将 Claude Code 指向 localhost + 一个一次性令牌
exportANTHROPIC_BASE_URL="http://localhost:11434"
exportANTHROPIC_AUTH_TOKEN="local-dummy"

# 3. 运行它
claude

Codex CLI → 本地模型：Codex 可与任何 OpenAI 兼容的端点通信。使用 Ollama 时，--oss标志会将其指向本地服务器（:11434）；LM Studio 服务于:1234/v1。在config.toml中固定提供商/模型。

工具选择：Ollama 是终端优先的选项（它甚至为 Claude Code / Codex / OpenCode 提供一键启动器）；LM Studio 是图形界面。两者都可行——记住，决定工具调用可靠性的是模型，而不是工具。

两个坑，每个都让我搭进去一个晚上：

  • 显式设置上下文窗口——至少 32K，理想情况下 64K+。默认值往往很小，编码智能体会立刻陷入饥饿。但质量会在远早于标称上限之前就开始下降，而且 KV 缓存会吃掉你本想留给权重的显存。两者都要预留。
  • 要切回云端： unset ANTHROPIC_BASE_URL（或将其从settings.json中移除）。显而易见，直到你忘了这件事，然后纳闷为什么“Claude”变笨了。

硬件档位指南

你的硬件 选择 现实情况
8GB 笔记本 / 小显存 GPU GLM-4.7-Flash、Gemma 4 12B 可用于单文件辅助；智能体任务预计需要重试
12–16GB GPU Devstral Small 2、Qwen3-Coder 14B 级 可靠的日常编码模型；干净的 Apache-2.0 选项
24GB GPU（最佳甜点） Qwen 3.6 27B 值得为此购买的型号；可靠的工具调用者，约 77% SWE-bench
64GB+ 统一内存 / 多 GPU Qwen3-Coder-480B、GPT-OSS 120B 专业级上限；收益递减
服务器 80GB+ DeepSeek V4-Pro、Kimi K2.x 团队机器 / 升级档位，不是桌面机

它实际在哪里出问题（诚实部分）

在真实工作上跑一周，模式是一致的：一个优秀的本地编码模型在常规单文件任务上能给你大约云端 Claude 70% 的表现，而随着工作变得更智能体化，差距会迅速扩大。失败模式，按它们咬人的频率排序：

  • Schema 漂移 → 重试循环。模型会输出一个略微格式错误的编辑，harness 会拒绝它，重试时它又会以不同的方式偏离。在一个困难的步骤上，这会消耗十几次往返。
  • 多文件推理会崩溃。“在整个模块中重命名这个并修复导入”正是云端无聊而可靠、而本地 30B 到第三个文件就迷失的地方。
  • 你能感受到的延迟。云端几秒就能完成的链条可能要花几分钟在本地——不是因为 tokens/秒 差，而是因为每次重试都是又一次完整生成。
  • 上下文悬崖来得又早又陡。模型在标称窗口的一半左右就开始微妙地变差，而“在遵循计划上微妙地变差”正是你在智能体里承受不起的。

这些都不让本地变得无用。它让本地成为一种不同的工具，而不是更便宜的克隆。

那么它真的省钱吗？

这才是人们尝试的真正原因，所以让我们算算账，而不是对着“免费”挥挥手。本地并不免费——它是预付的。你用按量计费的 API 账单换取固定硬件 + 电费 + 照看重试所花的时间。

Cost break-even: cumulative cost of a local GPU vs metered cloud API over a year

  • 一块能舒适运行 Qwen 3.6 27B 的二手 24GB GPU：几百美元，一次性。
  • 持续负载下的电费：真实但很小——对个人来说每月个位数美元。
  • 与之相对：一个重度 Claude Code 用户每月能烧掉数百美元，而运行智能体集群的团队会晒出令人瞠目的账单（“一个月 4,660 美元”的截图如今已成一种体裁）。

诚实的结论：对于做随意编码的个人，本地很少能比小心使用云端更划算——硬件和折腾的成本超过你能省下的。它真正翻转的地方是高用量、重复性或受隐私约束的工作负载——尤其是智能体集群，你把便宜的 80% 调用路由到本地模型，只在需要它们的 20% 上花前沿 token。那种路由——而不是“替换 Claude Code”——才是 2026 年真正的胜利。

做决定的框架

别再问“哪个模型最好”。问“这是哪项工作”。

当工作是以下情况时选择本地：

  • 私密或离线——不能离开这台机器的代码。
  • 高用量、每任务便宜——集群中成千上万的分类/摘要/样板子调用。
  • 狭窄且单文件——一个函数、一个测试、一个正则、一次迁移。
  • 省额度——把简单的 80% 路由到本地，把困难的 20% 升级出去。

把云端 Claude/Codex 留给：

  • 多文件、长周期的变更在需要多步骤保持一致性的场景是价值所在。
  • 大上下文工作在需要整个上下文窗口真正发挥作用的场景。
  • “一次做对，还要快”——任何重试循环的成本高于 token 成本的任务。

我得出的那句总结：本地正在成为默认选项，而前沿模型是升级路径。这与大多数团队今天的做法正好相反——而钱就在这里。

真正的答案

本地 LLM 能取代 Claude Code 吗？作为在困难、多步骤、大上下文工作上充当你的智能体——还不能，而阻碍它的不是 SWE-bench 分数，而是长会话中的工具调用可靠性。作为那 80% 不需要前沿模型的任务的廉价、私密、始终可用的主力——绝对可以，就在今天，在一块 24GB GPU 上，而且它每个月都在变好。

错误在于把它当成非此即彼。真正获得价值的人并没有“取代”任何东西。他们运行两个模型，并清楚哪项工作该交给哪个。

如果这篇对你有用，关注我——我写关于 AI 智能体、本地模型以及围绕它们的那些不光鲜的工程，随着模型发布，我正在测试更多这类配置。

轮到你了：对你来说真正的分界线在哪里——具体是哪个任务让你转向云端、拒绝信任本地模型？我在收集真实的分界点，而不是基准测试里的分界点。👇

来源与自行核实

本文中的数字是厂商报告的，且每月变动——不要因为博客里的一个百分比就去买硬件。请到一手来源核实：

成本和工具调用层级图表是示意性的，绘制目的是展示权衡的形态——请代入你自己的 API 账单和 GPU 价格，得到适用于你的数字。