摘要 ：这篇文章Local LLMs That Can Replace Claude Code探讨了小型开发团队如何使用开源的本地大语言模型（LLM）来替代昂贵的Claude Code服务。文章的技术亮点在于评估了Qwen3-Coder （32B）、DeepSeek V3、GLM-4.7和MiniMax M2.1等前沿编码模型，并分析了它们在硬件需求、推理性能和集成方式上的可行性。该方案适合预算有限但希望
1、能够替代 Claude 的本地 LLM摘要
能够替代 Claude Code 的本地 LLM 小型工程师团队很容易在 Anthropic 的 Claude Code (Sonnet/Opus 4.5) 上每月烧掉超过 2000 美元。由于预算紧张，你可能想知道是否可以...
小型工程师团队很容易在 Anthropic 的 Claude Code (Sonnet/Opus 4.5) 上每月烧掉超过 2000 美元。由于预算紧张，你可能想知道是否可以在不牺牲质量的情况下利用本地 LLM。
一个较弱的底层开放模型是否仍然可以为中小型开发团队做"几乎是 Claude Code"的工作？
像 Qwen3-Coder (32B) 、DeepSeek V3 、GLM-4.7 和 MiniMax M2.1 这样的模型正在推动代码理解的前沿水平。
事实上，最近的基准测试表明，最新的 Qwen 和 DeepSeek 模型与专有模型相媲美，它们甚至可能正在引领编码 LLM。
这些进步表明，如果硬件和集成障碍不是致命的，小团队可以使用本地 LLM 勉强过活。
让我们继续。
2、入围替代 Claude Code 的 OSS 模型
内部运行的候选者并不缺乏。
这里有一些你的选择
2.1 Qwen3-Coder (32B MoE, 128K 上下文)
它拥有 235B 参数（22B 激活），并专门针对编码和代理任务进行了调整。智谱 AI 的基准测试表明，Qwen3 在编码测试中与 OpenAI 的 GPT-4 等深度专有模型竞争（或击败）。即使是 Qwen3 的较小版本（14B，8B）也在更轻的硬件上提供了强大的编码支持。
2.2 DeepSeek V3/Coder
V3 "Terminus" 系列在数学/推理和代码方面很强，尽管官方权重尚未完全公开。（DeepSeek 的 R1 671B 在 6×A100 GPU 上进行了量化，约 10 万美元的硬件。）
非官方报告表明，DeepSeek 的编码器模型很强大，但同样需要严肃的 GPU 集群。
即使经过量化，DeepSeek-V3.2 也需要 350--400+ GB 的 VRAM（多 GPU）进行推理。
DeepSeek 类模型是数据中心规模的，可能超出了典型团队的设置，但如果你手头有基础设施，绝对值得一试。
2.3 GLM-4.7
GLM-4.7 在数学/推理方面比其前身有重大提升，他们甚至称其为"成本仅为一小部分的 Claude 级编码模型"。
GLM-4.7 权重是开放的（在 HuggingFace/ModelScope 上），它可以使用 vLLM 或 SGLang 等框架提供服务。
在正面交锋的基准测试中，GLM-4.7 实际上表现出色，在实践中，GLM-4.7 对许多编码查询效果很好，而且它在比完整 Sonnet 轻得多的硬件上运行。
2.4 MiniMax M2.1 (230B MoE)
来自 MiniMax 团队的新人（2025 年 12 月），M2.1 是一个 混合专家模型，具有 10B 激活/230B 总参数，专门为编码代理和工具使用而设计。
该团队确认模型权重是完全开源的。
我们还没有测试过它，但它承诺"没有封闭 API 的顶级编码性能"和快速推理（MoE 意味着每个请求只有部分网络激活）。
如果 M2.1 不负众望，它可能会改变游戏规则，但即使运行它也需要多个 GPU（10B 激活权重仍然需要 >80GB 的 VRAM）。
2.5 较小的模型
除了巨头之外，还有高效的编码器：
- Qwen 14B/8B
- GPT-OSS 120B
- Llama-4 变体
这些在单个 GPU（8--24GB VRAM）上运行，对于较简单的任务非常有能力。
Qwen3--14B 在 GitHub 问题上获得约 58%，在 Q4 量化下在一个 RTX 4090 (24GB) 上运行 Qwen 14B 对于常规编码建议来说很流畅。
这些较小的模型在解决新颖复杂问题方面无法与 Opus/Sonnet 匹敌，但它们极大地拓宽了可行性，因为 1-2 千美元的 GPU 可以为一个开发人员服务。
3、硬件和性能现实
如前所述，DeepSeek-V3.2 (685B MoE)，即使量化到 4 位，也需要 350--400+ GB 的 GPU RAM，这意味着一个 8×A100/H100 集群。（全精度将超过 1 TB！）。
DeepSeek 的顶级模型纯粹是数据中心领域。
相比之下，上面的开放模型从几 GB 到几十 GB 不等。
Qwen3--32B 模型需要 ~24GB VRAM（如果是 4 位量化则为 16GB），如果量化，这适合一张高端桌面卡（例如 RTX 6000/4090）。
Qwen3--14B 需要 ~12GB（8GB Q4 量化）。
GLM-4.7 在尺寸上具有可比性（据报道为 2.5T token，但权重大小类似于 28--32B 范围），你可以轻松地在一个 48GB H100（一张卡）上运行它。
MiniMax M2.1 的激活 10B 至少需要 80GB 的 GPU 内存（10B×8 字节 + 开销），所以这是一个 2× H100 级别的工作。
在实践中，一个小团队可以构建一个适度的推理设备：2×48GB GPU，256GB RAM，使用 vLLM 进行服务。
你可以同时加载 Qwen3--32B（量化 16 位）和 GLM-4.7，并支持几个并发开发人员。
一旦模型预热（vLLM 的批处理和 KV 缓存有帮助），你可以每秒处理数千个输入 token 的吞吐量。
作为参考，单个 48GB 卡可以产生 ~10K token/s 的"上下文预填充"。
典型的编码提示（~500 token）可以在 0.5--1 秒内完成。（比云 API 慢，但在局域网上可以接受。）
自然，更多的并发意味着更多的 GPU。
你可以将负载分摊到 2 张卡上；每个开发人员的 Claude CLI 会话被路由到空闲的 GPU。
你也可以尝试 Nvidia MIG 分区，将多个较小的模型打包到一张卡上以进行轻量级任务（Minimax M2.1 具有多 GPU 支持，GLM-4.7 也有）。
这并非零开销，有时 vLLM 会停顿等待 GPU 交换缓存上下文。
但随着硬件变得更便宜，人们可以轻松地并行化（8×4090 设置约为 3 万美元，而且价格只会下降）。
4、与 Claude Code（及替代品）集成
Claude Code CLI 遵守模型名称的环境变量。你可以在 CLI 配置中设置 CLAUDE_MODEL=glm-4.7（或类似）。
你也可以使用 开源代理框架。像 OpenCode、Roo Code 或 Cline 这样的项目允许你插入任何 LLM 后端。
你可以将你的本地 Qwen 或 MiniMax 模型插入到类似 Claude 的 CLI 界面中。
留在 Claude Code 生态系统内的一个优势是 代理提示工程 非常成熟。输出的质量不仅仅是模型，还有系统提示、对话格式、代码上下文的检索。
通过重用 Claude 的模板，即使是从较小的模型中，你也可以获得不错的结果。
5、结果
小型开发团队可以用本地模型替换 Claude Code 的大部分功能，但前提是你将其视为适当的基础设施。
不要让每个开发人员在他们的笔记本电脑上运行不同的模型。相反，在同一个 Claude Code CLI（或等效代理）后面提供一个一致的模型。
这样，所有开发人员都会看到相同的行为，你可以全局调整提示。
这可以为你提供非常相似的日常编码输出：代码补全、错误修复、PR 摘要等。
总之，没有什么能阻止这列火车。