本地大模型能取代 Claude Code 吗？SWE-bench 用错了

核心结论：本地 LLM 写对一段函数早已不是问题，但作为可靠的 Agent——稳定地发出工具调用、在多文件修改中保持一致性、不偏离 schema——这才是决定你能否关掉 Claude Code 标签页的关键。而后者，恰恰是所有排行榜都不测的东西。

这是每个「本地模型替代 Claude Code」指南的开头：一墙的 SWE-bench 分数，一句胜利的「我们距离前沿只有五分了」，以及一张 GPU 购物清单。我把它们跑了个遍后得出结论：它们没有错，只是测量了容易测量的东西，而非真正决定你能否关闭 Claude Code 标签页的东西。

为什么这件事突然可行了

2026 年发生了两件事，都不是「模型在 Twitter 上更响亮了」。

MoE 打破了硬件墙。 稠密 70B 模型为每个 token 激活全部 700 亿参数；而 MoE 模型总参数量巨大，每个 token 只激活极小一部分——Qwen 的 35B-A3B 每次只激活约 30 亿。显存由加载的文件大小决定，速度由那个微小的激活切片决定。于是曾经需要服务器的模型现在能跑在游戏显卡上，量化后甚至能塞进笔记本。

Agent 学会了说本地话。 这是 2025 年的帖子普遍错过的部分。2026 年 1 月，Ollama 原生支持了 Anthropic Messages API，LM Studio 和 llama.cpp 紧随其后。这才是解锁点：Claude Code 不再需要代理垫片就能跟 localhost 对话，只需把一个环境变量指向它即可。管道不再是难点，对话终于必须从「它能不能写代码」推进。

rss source: Can a local LLM replace Claude Code? The benchmark everyone quotes is the wrong one.

MoE（Mixture of Experts，混合专家） 是一种稀疏激活的模型架构：模型内部由多个「专家」子网络组成，每个 token 只被路由到其中一小部分专家进行计算。它的关键价值在于把「总参数量」与「每 token 计算量」解耦——总参数决定模型的知识容量，激活参数决定推理速度与算力开销。这就是为什么 Qwen 35B-A3B 这样总参数 350 亿、每次只激活约 30 亿的模型，能在消费级显卡上跑出远超同尺寸稠密模型的质量。

作为对比，稠密模型（如 Llama 70B）每生成一个 token 都要激活全部参数，显存和算力需求随参数线性上升。而 MoE 的显存需求主要由需要加载的权重总量决定，速度则由激活切片决定。因此量化后的 MoE 模型既能装进 8GB 笔记本，又能保留接近中型稠密模型的能力。它的代价是训练更复杂、显存占用（而非算力）仍是瓶颈，且不同专家的负载均衡需要专门设计。

Anthropic Messages API 是 Claude Code 等工具与模型通信所使用的接口协议（请求中包含 system、messages、tools 等字段）。2026 年 Ollama、LM Studio、llama.cpp 等本地推理框架原生实现了这一协议，意味着本地模型可以直接「冒充」Anthropic 端点，Claude Code 无需任何代理转换层，只需通过 ANTHROPIC_BASE_URL 环境变量把请求指向 localhost 即可。这一步消除了过去最麻烦的粘合层，是本地 Agent 工作流真正可用的分水岭。

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

SWE-bench Verified 是每个标题里的统计量，2026 年自托管模型的报告数字确实逼近前沿：单张 24GB 卡上的模型能跑到约 77 分，与云端前沿相差无几。

但陷阱恰恰在这里：

SWE-bench 衡量的是「给定一个 bug，产出正确补丁」——这是一个写作任务。 它几乎无法说明当模型在驱动你的编辑器时，真正会出问题的四件事。

工具调用的有效性 —— 它能不能可靠地（而不是「通常能」）产生一个结构良好、能被工具链解析的 edit_file / run_command 调用？
长程一致性 —— 第 11 次调用还记得第 2 次的计划吗？
负载下的上下文 —— 塞入 4 万 token 的真实仓库后质量还能保持，还是在远早于广告窗口长度时就崩掉？
指令遵循 —— 你说「别动测试」，它就不动测试吗？

这四项没有一项在排行榜上，但它们全是你的本地设置感觉和演示不一样的原因。

⚠️ 本文所有数字均为厂商自报。 不同指南引用同一模型的分数天差地别，因为它们悄悄把 SWE-bench Verified 换成了 Pro 或 Terminal-Bench 却从不说明。买 GPU 前请先去官方 SWE-bench 排行榜核实。

值得了解的七大家族（以及各自到底适合什么）

请按家族思考，而非单个 checkpoint——每个家族都有多个尺寸，正确的选择是既装得进你的卡、又匹配你工作类型的那一个。

Qwen 3.x —— 本地编程的骨干

如果只跑一个家族，就是它。Qwen 是开放权重里编程与工具调用双料领先者，而这两者的组合才是关键。Qwen 3.6 27B（稠密）约 77% SWE-bench Verified，量化后约 22GB，单张 24GB GPU 或 M 系列 Mac 可跑，是可靠的工具调用者；Qwen 3.5 35B-A3B（MoE）总参数 350 亿、激活约 30 亿，Q4 量化仅需 8GB 显存，是「笔记本上的前沿」主推款；Qwen3-Coder 是代码特化线，30B 适合日常，480B 若你有 64GB+ 统一内存则是最强开放编码器。最适合通用编程 Agent、工具使用工作流。弱项：没有明显短板，是安全默认。

GLM-4.x —— 预算内的长会话 Agent

GLM 在长时间、工具密集的 Agent 运行上以小巧尺寸打出超预期表现。GLM-4.7-Flash 约 59% SWE-bench，能在 5-8GB 笔记本上跑——这是「我只有集显级 GPU」的可用选项，不是玩具。GLM-4.6/4.x（MIT 许可）推荐用于多步 Agent 会话，其中跨多次调用的一致性比单发分数更重要。弱项：困难单发编程的天花板低于 Qwen 27B。

DeepSeek V3.2 / V4-Pro —— 开放权重最高天花板

DeepSeek^广告提交了开放模型最佳结果——V4-Pro 约 80.6% SWE-bench Verified——但只有当你的桌子里有台服务器（80GB+）时它才算「本地」。最适合服务器级硬件上的硬核代码任务或团队自托管盒子。弱项：不是消费级 GPU 模型，这是升级层，不是日常驾驶。

Devstral Small 2 —— 宽松许可的工作马

约 68% SWE-bench Verified，Apache-2.0，适配 12-16GB 显存。是「我需要干净许可 + 中端卡」的最佳选项，在其尺寸下也是扎实的 Agent 编码器。弱项：多文件推理止步于 27B 层之下。

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

Kimi 面向长程 Agent 工作，在更难的 Pro 基准上得分不错，但本地运行需要重量化或服务器硬件。弱项：单张消费级 GPU 不现实；其分数基于 Pro，不要和上面的 Verified 数字直接对比。

GPT-OSS（20B / 120B）—— OpenAI 的开放权重，Codex 原生

通过 --oss 标志自然嵌入 Codex CLI。20B 跑消费级硬件，120B 是服务器级。最适合已标准化 Codex、想要零工具摩擦本地回退的团队。弱项：在开放工具调用可靠性上，Qwen/GLM 通常更胜一筹。

Gemma 4 —— 轻量通用型

Gemma 4（12B / 27B）是轻硬件通用型——16GB 机器上想要全能而非代码专精时很好用。弱项：是通用型而非编码专精，硬 SWE 任务上会落后于编码调优模型。

（荣誉提名：MiniMax M2.x，Agent 优先训练且定价激进——如果吞吐/美元是你的约束，值得关注。）

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

真正该驱动你 GPU 决策的图表是：性能 vs 达到该性能所需的显存。曲线在约 24GB 前陡峭上升，然后趋平——480B 编码器在 Verified 上甚至低于 27B，却要 3 倍内存。教训：单张 24GB 消费级 GPU 跑 Qwen 3.6 27B 是自托管甜点区。再往上除非你特别需要服务器级天花板，否则都是收益递减。

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

这是我选择本地模型方式的重新组织点：工具调用是与写代码分开训练的独立技能。 一个模型可以产出漂亮的函数，却仍然在 Agent 唯一需要的那件事上失败——每次尝试都能一次发出有效的工具调用。

证据收敛于几点：参数量低于约 4B 时可靠性断崖式下跌，低于 7B 的模型无论用哪个 Agent 包装都会发出格式错误的调用；原生工具使用训练胜过外挂语法约束；模型比工具链更重要——把 Claude Code 换成 OpenCode 或 Codex 救不了一个会搞乱 JSON 的模型；多步链是死亡之地——一次调用没问题，连续五次各自依赖前一次时，较小的本地模型开始幻觉调用，发明不存在的函数或用漂移的参数重复调用，Agent 陷入重试循环。

实际切分：Agent 工作要找来自有原生工具训练家族的 14B-32B 模型。这在 2026 年末压倒性地意味着 Qwen，GLM-4.x 和 Devstral Small 2 是可信替代。低于约 7B 的都是聊天模型在冒充 Agent。

工具调用（Tool Calling / Function Calling） 指模型按照预先定义的 JSON Schema，输出一个结构化调用请求（如 {name: "edit_file", arguments: {...}}），供外部工具链解析执行。它与「生成自然语言代码」是两种不同的训练目标：前者要求模型精确理解 schema 的字段名、类型、必填项，并在多轮对话中保持参数与历史的一致性。

可靠性断崖的根源在于训练数据分布：小模型在预训练中见到的结构化调用样本远少于自然语言代码，且缺乏专门的强化学习对齐。当任务从单次调用升级为链式调用（第 N 次调用依赖第 N-1 次的结果），误差会累积——字段名轻微拼错、参数类型漂移、引用不存在的函数，都会导致工具链拒绝执行并触发重试，而每次重试都是一次完整生成，延迟成倍放大。

Berkeley Function-Calling Leaderboard（BFCL） 是目前最权威的工具调用评测基准之一，它按「简单函数」「并行调用」「多轮多函数」「相关性检测」等维度打分，能比 SWE-bench 更直接地反映 Agent 场景下的模型能力。选模型时结合 SWE-bench 与 BFCL 两个榜单，才能覆盖「写对代码」和「用对工具」这两项独立技能。

配置真的只要 60 秒

因为 Agent 现在会说本地话了，这一步平淡无奇——这正是重点。

Claude Code → 本地模型（经 Ollama）：

# 1. 拉取一个能干的编码器
ollama pull qwen3-coder:30b
# 2. 把 Claude Code 指向 localhost + 一个一次性 token
export ANTHROPIC_BASE_URL="http://localhost:11434"
export ANTHROPIC_AUTH_TOKEN="local-dummy"
# 3. 运行
claude

Codex CLI → 本地模型：Codex 跟任何 OpenAI 兼容端点对话。用 Ollama 时 --oss 标志指向本地服务器（:11434）；LM Studio 服务在 :1234/v1。在 config.toml 里固定 provider/model。工具链选择：Ollama 是终端优先选项（甚至有 Claude Code / Codex / OpenCode 的一键启动器）；LM Studio 是 GUI。两者都行——记住，是模型而非工具链决定你的工具调用可靠性。

两个各花了我一晚上的坑：显式设置上下文窗口——至少 32K，最好 64K+；默认值往往很小，编码 Agent 会瞬间饿死。但质量远早于广告上限就退化，KV 缓存还会吃掉你本想留给权重的显存，两边都要预算。切回云端：unset ANTHROPIC_BASE_URL（或从 settings.json 删掉）。很明显，直到你忘记并纳闷「Claude」怎么变笨了。

硬件档位指南

你的硬件	选择	现实
8GB 笔记本 / 小 GPU	GLM-4.7-Flash、Gemma 4 12B	单文件协助可用；Agent 工作预计要重试
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% 的常规单文件任务能力，而随着工作变得 Agent 化，差距迅速拉大。 失败模式按咬人频率排序：schema 漂移→重试循环（模型发出略微畸形的编辑，工具链拒绝，重试时又漂向别处，一个困难步骤能吃掉十几次往返）；多文件推理瓦解（「在模块里重命名并修复导入」，云端枯燥可靠，本地 30B 到第三个文件就迷路）；你感受得到的延迟（云端几秒完成的链在本地要几分钟——不是 token/秒差，而是每次重试都是一次完整生成）；上下文悬崖又早又陡（模型在标称窗口一半左右就微妙变差，而「微妙地不遵循计划」正是 Agent 里你承受不起的）。这些都不使本地无用，它使本地成为不同的工具，而非更便宜的克隆。

Schema 漂移（schema drift） 指模型在多次工具调用中逐渐偏离预定义 JSON Schema 的现象。表现包括：字段名出现近义词替换（file_path 写成 filename）、嵌套结构被展平、枚举值超出允许范围、必要字段被省略或多余字段被添加。它之所以致命，是因为工具链通常做严格校验，一次格式违规就整链失败，而重试时模型往往不会纠正到同一方向，反而漂向另一种错误，形成「重试循环」。

上下文悬崖（context cliff） 描述的是模型的有效上下文远小于其标称窗口的现象。当输入接近标称窗口（如 128K）的一半时，模型对早期内容的注意力权重下降，开始遗忘指令细节或提前做出的设计决策。这对 Agent 是灾难性的：Agent 依赖长期记忆维持计划一致性，一旦「忘记目标」就会产出看似合理但偏离任务的操作。压缩上下文、分阶段总结、把关键约束固定插入 prompt 顶部，是缓解上下文悬崖的常见工程手段。

所以它真的省钱吗？

这是人们尝试的真正原因，所以我们来算账而不是挥手说「免费」。本地不是免费——它是预付。你用计量 API 账单换固定硬件 + 电费 + 照看重试的时间。一张二手 24GB GPU 舒适跑 Qwen 3.6 27B：几百美元，一次性。持续负载下的电费：真实但很小，个人每月个位数美元。对比：一个重度 Claude Code 用户每月能烧几百美元，跑 Agent 集群的团队账单更是触目惊心（「一个月 4660 美元」的截图已经是一种体裁了）。诚实结论：对做休闲编程的个人，本地相对于小心使用云端很少回本——硬件和折腾成本超过你省下的。真正翻转的是高容量、重复或隐私绑定工作负载——尤其是 Agent 集群，把便宜的 80% 调用路由到本地模型，只在需要前沿的 20% 上花前沿 token。那个路由——而非「替代 Claude Code」——才是 2026 年真正的胜利。

模型路由（model routing） 是 2026 年混合 AI 工作流的核心范式：把每个请求按难度、隐私要求、延迟容忍度动态分发到本地或云端模型。常见的分层策略是「本地处理高频、低成本、隐私敏感的 80% 请求（分类、摘要、样板代码、单文件改写），云端处理低频但高难度的 20%（多文件重构、长程规划、一次性正确答案敏感的任务）」。

路由的收益不只是省钱：本地部分提供了零网络延迟与数据不出机器的隐私保障，云端部分保留了前沿模型的能力上限。实现上可以是简单的启发式规则（按文件数、token 长度、任务类型分流），也可以训练一个小分类器预测「本地是否会失败」。真正的成本不在推理硬件，而在构建和维护路由逻辑与降级回退机制——这正是「替代 Claude Code」与「与 Claude Code 共存」两种思路的根本差异。

做决定的框架

别再问「哪个模型最好」，问「这是哪项工作」。

在这些情况下用本地：私有或离线（不能离开机器的代码）；高容量、单任务便宜（集群里成千上万的小分类/摘要/样板子调用）；狭窄且单文件（一个函数、一个测试、一个正则、一次迁移）；省额度（简单 80% 本地，困难 20% 升级）。

保留云端 Claude/Codex 用于：多文件、长程变更，其中跨多步的一致性就是价值；大上下文工作，你需要整个窗口真正起作用；「一次就对、快速」，任何重试循环成本超过 token 的场景。

我最终落到的一句话：本地正在成为默认，前沿模型是升级路径。 这与大多数团队今天的运行方式相反——而钱就在这里。

真正的答案

本地 LLM 能取代 Claude Code 吗？ 对于在困难、多步、大上下文工作上充当你的 Agent——还不能，阻碍它的不是 SWE-bench 分数，而是长会话中的工具调用可靠性。对于充当那 80% 不需要前沿模型的任务的便宜、私有、永远可用的工作马——绝对可以，今天，单张 24GB GPU 上，而且每月都在变好。错误在于把它当二元问题。真正获得价值的人不是在「替代」任何东西，他们跑两个模型并知道哪项工作归谁。

本文数字为厂商自报且每月变动。花钱买硬件前，请在官方 SWE-bench 排行榜核实编程分数，在 Berkeley Function-Calling Leaderboard 核实工具调用。