写代码的本地 LLM 推荐：8GB 到 24GB 显存选型

当下写代码的本地 LLM 首选：24 GB 卡上跑 Qwen3 Coder 30B A3B，12–16 GB 用 Q4 的 Qwen2.5 Coder 14B，8 GB 用 Q4 的 Qwen2.5 Coder 7B。这几个模型全都完全离线运行，能补全、能重构真实代码，每个 token 零成本。显存塞不下模型时，先降一档量化，再考虑降模型尺寸。本文把模型对到显存档位，对比大家真正吵得最多的两个编程模型家族，最后给出可运行命令——五分钟左右你就能在本地跑起代码生成。

你的 GPU 上该用哪个本地 LLM 写代码？

先按显存选，再看模型——权重加上下文装得进内存，模型才算装得下。下面是 2026 年社区跑分和日常使用中反复胜出的短名单：

显存	模型	量化	权重占用磁盘	为什么它赢下这一档
8 GB	Qwen2.5 Coder 7B Instruct	Q4_K_M	~4.7 GB	自动补全和小型重构上最佳的速度-质量比
12 GB	Qwen2.5 Coder 14B Instruct	Q4_K_M	~9.0 GB	整文件编辑装得进上下文；3060 级显卡仍有 30+ tok/s
16 GB	Qwen3 14B 或 gpt-oss-20b	Q4_K_M	~9–12 GB	面对模糊需求的推理更强；4090 级显卡保得住速度
24 GB	Qwen3 Coder 30B A3B	Q4_K_M	~18.6 GB	MoE：每个 token 只激活约 3B 参数，速度依然可用

两条规则让这张表在实际中站得住：

1. 给 KV cache 留 1–2 GB 显存余量。14B 模型 Q4 加 8K token 上下文，在 10 GB 预算里塞不下——上下文也算在总账里。
2. 先降一档量化，再降模型尺寸。Q5/Q4 只损失百分之几的质量；把 14B 换成 7B，损失远不止这个数。

跑编程本地 LLM 需要多少显存？

老实的经验法则：所需显存 ≈ 量化后的权重 + 每 1K token 上下文 0.125 GB（8-bit KV cache）。换成白话数字：

• 8 GB：7B–8B 模型 Q4 跑得很从容。预期补全长度的回答，4K–8K 上下文。
• 12 GB：14B Q4 的甜点位——模型加一个现实的 8K–16K 编程上下文都放得下。
• 16 GB：打开 20B 级稠密模型和更长上下文的 Qwen3 14B。
• 24 GB：跑 Q4 的 Qwen3 Coder 30B A3B MoE，这是你能自己托管的、最接近云端质量的编程模型。

只有 CPU？也能跑——llama.cpp 在笔记本 CPU 上跑 7B Q4 也有 5–10 tok/s——但把它当耐心练习，别当日常主力。至于给模型底下垫哪套运行时工具，Ollama vs LM Studio 对比讲的就是这件事。

Qwen3 Coder 对比 DeepSeek：谁更适合写代码？

这是自动补全竞技场真正会被问到的那组对决，答案可以干净地一刀切开：

• Qwen3 Coder（30B A3B）是为编辑循环而生：它遵守工具调用的指令格式约定，产出一致的 diff，而且——决定性的一点——MoE 设计让每个 token 只激活约 3B 参数，一张 24 GB 卡就能跑出 40–60 tok/s。对 IDE 式用法来说，响应速度本身就是质量。
• DeepSeek V3/R1 系在更高的层面上较量：架构决策、刁钻算法、多步推理。但旗舰是 600B+ 参数；本地只能重度量化之后跑在多卡或 Mac 统一内存的机器上，而且它”写关于代码的散文”比写代码本身更快。

本地结论：日常主力用 Qwen3 Coder；只有硬件足以近全精度托管时，才轮到 DeepSeek。在 8–16 GB 档，这场争论没有意义——Qwen2.5/3 Coder 就是塞得进去的最强选择。

怎么用 Ollama 把最好的编程本地 LLM 跑起来？

五条命令，从零到一个编辑器能用的 OpenAI 兼容 API：

# 1. 安装 Ollama（Linux）
curl -fsSL https://ollama.com/install.sh | sh

# 2. 拉取匹配你显存档位的模型（以 8 GB 显卡为例）
ollama pull qwen2.5-coder:7b

# 3. 交互式对话
ollama run qwen2.5-coder:7b

# 4. 通过 OpenAI 兼容 API 在任何工具里调用
curl http://localhost:11434/v1/chat/completions 
  -d '{
    "model": "qwen2.5-coder:7b",
    "messages": [{"role": "user", "content": "Refactor this fn to be async: add(a,b){return a+b}"}]
  }'

# 5. 把依赖 OPENAI_BASE_URL 的工具指过来
export OPENAI_BASE_URL=http://localhost:11434/v1

没有 API key，没有速率限制，没有按 token 计的账单。Linux 上安装器会注册 systemd 单元，服务器哪天不听话，journalctl 会告诉你原因——journalctl 速查表里有调试服务所需的精确过滤器。

本地 LLM 能胜任真正的开发工作吗？

编辑循环：能。硬骨头：不能——而这个分工恰恰就是正确的用法。14B–30B 的本地模型处理重构、样板代码、测试脚手架、正则、“解释一下这个祖传函数”，比大多数云端 API 一个来回还快。它输给大型托管模型的地方，是跨多文件的长链推理和冷门框架的边角知识——30B 模型知道的东西，就是比前沿模型少。

行之有效的工作流：90% 的击键交给常驻的本地模型，只有真正棘手的设计问题才去够托管的前沿模型。日常工作的代码永远不离开这台机器——这对客户代码很重要——而你早已拥有的显存，悄悄顶掉了一份订阅。