内存 16-32G 的机器跑本地代码模型到底能到什么水平

很多人觉得本地跑代码模型就是个玩具，但其实现在的量化技术和 MoE 架构已经把门槛拉低到了一个很微妙的临界点。如果你只有 16G 到 32G 的内存（或者显存），而且因为公司规定不能用云端 API，那么在选择模型时得非常小心，因为这直接决定了你是能用它写业务逻辑，还是得花更多时间去帮它改 Bug。

从实际的 Aider 评分来看，Qwen2.5-Coder-32B 能跑到 73% 左右，虽然离 Claude 3.5 Sonnet 那种 84% 的顶级水准还有 10 个百分点以上的差距，但这 10% 的差距就是“能直接合入代码”和“必须经过严格人工 Review”的区别。

不过 MoE（混合专家）架构救了低内存用户。比如 DeepSeek-Coder-V2-Lite，虽然总参数 16B，但推理时激活的只有 2.4B，这对内存压力极小。而 Qwen3-Coder-30B-A3B 同样走这个路线，虽然总数 30B，但激活参数仅 3.3B，这让 16-32G 的设备第一次在处理实际项目（而不是简单的 Demo）时有了可用性。

针对不同内存配置，我总结了一套实操参考：

• 16G 内存： 建议跑 DeepSeek-Coder-V2-Lite-Instruct (Q4 GGUF)。这个配置能稳住代码补全、解释代码和写简单的单测，但千万别指望它能做跨文件的架构重构。
• 24G 内存： Qwen3-Coder-30B-A3B (Q4 GGUF) 是个好选择，它支持较大的上下文，适合在整个代码库里搜答案，但复杂的 API 迁移依然得人工把关。或者选 Devstral Small 2 (24B)，它的优势是 Apache 2.0 协议且对无独立显卡的设备更友好。
• 32G 内存： 可以尝试 Qwen2.5-Coder-32B-Instruct (Q4/Q5 GGUF)。它的代码编辑能力最强，能处理绝大多数点状修改，但在顶层架构设计上还是比不过顶级云端模型。

目前最稳的本地部署工作流是：Ollama + Continue.dev (VS Code 插件)。建议采取“大小模型组合”策略，用极小模型做实时补全，用中型模型做 Chat。

在 Continue.dev 的 config.json 中可以这样配置（以 Qwen 为例）：

{
  "models": [
    {
      "title": "Qwen-Chat",
      "model": "qwen2.5-coder:7b",
      "provider": "ollama"
    }
  ],
  "tabAutocompleteModel": {
    "title": "Qwen-Autocomplete",
    "model": "qwen2.5-coder:1.5b",
    "provider": "ollama"
  }
}

这种分工能保证你在打字时没有延迟，在提问时又有足够的逻辑能力。