本地代码的LLM：顶级推荐

Lisa Ernst · 06.10.2025 · 技术 · 5 分钟

本概览介绍当前在本地硬件上运行且无需云连接的代码本地LLMs。关键在于可验证的基准、硬件需求（VRAM/RAM）以及如代码填充等功能。我们汇总现状并展示哪个模型适合哪种机器。

介绍与基础

我们所说的“本地”是指在自有硬件上对模型的完全运行，例如通过像 Runner 这样的工具 Ollama 或直接通过 llama.cpp/vLLM。 Ollama 能够轻松进行拉取/运行，即使使用量化也如此。 Quantisierung (例如 GGUF Q4_K_M) 大幅减少对内存的需求，通常伴随适度的质量损失。

在实际应用中，以下方面很重要：

填充（Infilling/FIM）: 针对性地填补代码中的空白，由以下模型支持 StarCoder2 和 CodeGemma.
上下文窗口: 能够包含更长的文件或项目。 Qwen2.5-Coder 这里提供最多128K Token。
运行时预算: 粗略经验值用于 Ollama 为：7B规模的模型至少需要8 GB RAM/VRAM，13B模型需要16 GB，70B模型需要64 GB。

本地运行的动机在于隐私性、可重复性、离线工作和成本控制。厂商如 BigCode/Hugging Face、Alibaba/Qwen 和 DeepSeek 提升了速度和透明度。工具如 Ollama 通过简单的 Pull/Run 和量化（GGUF/4位）降低进入门槛。扩展如 Continue 直接将本地模型集成到 VS Code/JetBrains。

Quelle: YouTube

当前状态与模型

自2024年以来，代码本地LLMs领域取得了显著进展：

StarCoder2 (3B/7B/15B): 该模型在 The Stack v2 上引入了 FIM 训练，提供16K上下文窗口。15B 版本 übertrifft 在许多基准测试中与之相当的大型模型，如在 dieser Veröffentlichung 所述。
Qwen2.5-Coder (0.5B–32B): 在开放代码基准测试中报道了最先进的结果（SOTA）。32B-Instruct 变体明确瞄准开源SOTA，在 EvalPlus, LiveCodeBench 与 BigCodeBench。
DeepSeek-Coder-V2: 引入了 MoE 设计。V2-Lite 版本（16B，活跃 2.4B）提供128K上下文，面向本地使用。更大的 V2 版本（236B，活跃 21B）在多项代码基准测试中名列前茅，但不适合消费级硬件。
CodeGemma (2B/7B): 聚焦于高效的 Infilling。7B 版本文档完善，包含 4 位设置和 FIM 令牌。

为了公平比较，出现了低污染的基准测试，如 LiveCodeBench (滚动的) 和 EvalPlus (HumanEval+/MBPP+). Hugging Face 在这方面提供更多信息。

Quelle: nutstudio.imyfone.com

面向编程的最佳本地LLMs的可视化呈现。

实际应用与整合

选择合适模型在很大程度上取决于可用硬件和计划中的任务：

笔记本/8–12 GB VRAM: Qwen2.5-Coder-7B 或 CodeGemma-7B. 这些模型在 Infilling 能力和低延迟方面表现出色，尤其是在 4 位运行时。
16 GB VRAM: StarCoder2-15B-Instruct 或 DeepSeek-Coder-V2-Lite (16B aktiv 2.4B). 在质量和速度之间取得良好平衡。
24 GB+ VRAM: Qwen2.5-Coder-32B-Instruct. 该模型是开源、强大并提供大范围的上下文窗口。
仅CPU/小型 iGPU: Gemma/CodeGemma 或更小的 Qwen-Coder Varianten. Google 公开展示了在 Ollama 上的 CPU 运行。

在实践中，推荐将 IDE 与 Continue (VS Code/JetBrains) 与一个 Ollama-Server. 建议主动使用 Infilling，而不仅仅进行聊天，并与 EvalPlus — 或 LiveCodeBench-Problemen 用于自己的领域进行。

Quelle: YouTube

分析与评估

厂商经常强调“开放 SOTA”（Qwen）或“同类最佳”（StarCoder2），这在一定程度上得到基准测试的支持，但也包含营销因素。查看 mehrere Quellen 因此值得关注。社区的反馈各不相同：有些本地设置受到好评，而其他人在编辑任务中的质量波动，通常与提示、上下文和编辑器集成有关，如 hier 所述。

事实核查：证据与主张

有据可查：
- 7B/13B/70B 关于 Ollama 的大致 RAM 指标在实践中得到了广泛证实。
- StarCoder2 提供 FIM 训练、16K 上下文，并与同等规模模型相比在 15B 级别上有强劲结果 (Quelle).
- Qwen2.5-Coder 32B-Instruct 在开放代码基准中声称 SOTA，覆盖从 0.5B 到 32B 的规模，上下文可达 128K。
- DeepSeek-Coder-V2-Lite: 16B 的 MoE（活跃 2.4B），128K 上下文。大型 V2 版本在代码基准测试中显示出非常高的分数，但不适合消费级硬件。
- CodeGemma 7B: FIM 令牌有文档记录，4 位运行大约需要 9 GB 左右。
不明确/含糊：
- “每十亿参数1 GB VRAM”是社区的经验值，随着量化、上下文长度和 Offload 的改变而有较大变动。模型/运行器文档在这里更为精确（ Qwen, Ollama).
错误/误导：
- “量化会让模型无法用。”在许多编码工作流程中，4 位是一个不错的折中。质量损失取决于模型、任务和上下文长度（ CodeGemma, Qwen).

Quelle: pieces.app

一个图表，比较不同 LLM 模型在编码领域的性能。

结论与展望

要寻找“最佳本地编码用LLM”，如今有真正的多种选择。对于 24GB+ VRAM 来说是 Qwen2.5-Coder-32B-Instruct 开放模型中的首选。在 16 GB VRAM 下，提供 StarCoder2-15B-Instruct 非常圆滑的 Infilling 和稳定的性能。在 7B 规模区间，存在 Qwen2.5-Coder-7B 和 CodeGemma-7B 务实的选择：快速、节能且文档完备。 DeepSeek-Coder-V2-Lite 在 MoE 效率和大上下文方面表现出色，前提是经过干净的量化和整合。

效用分析

权重：性能 60%，本地资源适配 20%，IDE 功能/FIM+上下文 10%，许可证 10%。性能预测基于引述的基准/模型文档。

Qwen2.5-Coder-32B-Instruct: 8.4/10 – 最高的开源性能，大的上下文窗口；需要更多 VRAM，但在复杂任务中表现出色。
Qwen2.5-Coder-14B-Instruct: 8.4/10 – 极佳的性价比，适用广泛，Apache-2.0 许可证。
DeepSeek-Coder-V2-Lite (16B, aktiv 2.4B): 8.0/10 – 高效的 MoE，128K 上下文；量化后可强力使用。
StarCoder2-15B-Instruct: 7.9/10 – FIM 强，16K 上下文，透明的训练；对编辑/完成任务稳健。
Qwen2.5-Coder-7B-Instruct: 8.0/10 – 移动/笔记本友好，快速延迟下质量良好；非常适合内联编辑。
CodeGemma-7B: 7.5/10 – 简洁，FIM 非常整洁，良好的文档/设置；对快速自动完成功能表现出色。

想要现在就开始的人，安装 Ollama, 拉取 Qwen2.5-Coder-7B 或 StarCoder2-15B, 激活 Continue 在 VS Code 中激活并有意识地使用 Infilling。这样就能立即受益，而无需绑定到云提供商。

待解问题

跨多种编程语言和框架的代码质量鲁棒性仍是待解的问题。滚动基准测试关注数据泄露，但不能提供完整保证（ LiveCodeBench, Hugging Face). 哪些指标与在编辑器中的实际生产力（编辑/重构/仓库上下文）最相关？ Aider 公开了编辑/重构基准测试，但标准化仍未确立。对于本地硬件，关于最佳量化/Offload 设置仍有疑问，这里 Runner 指南和你自己的微基准测试（ Qwen, Ollama).

Quelle: openxcell.com

LLMs 在开发过程中的集成方式的展示。