本地编码智能体模型

代码不能离开本机，或者每天要跑上千次小编辑时，本地模型才值得考虑。本页按显卡显存（8、12、16、24 GB）和 Apple Silicon 的统一内存（16、32、64 GB）排列能试的候选。某个模型放不放得下、留多少给上下文，怎么算见单卡部署。

挑候选时，最先要过的一关不是分数，而是格式：Benchmark 高分无法弥补 Harness 无法解析的输出格式问题。比如 gpt-oss-20b 是用 Harmony 格式训练的，这是 OpenAI 为 gpt-oss 定的对话与工具调用格式，模型卡说换用别的格式它就不能正常工作。如果运行时不支持 Harmony，模型发出的工具调用 Harness 就解析不了，分数再高也用不上。

Mac 的统一内存同时要装下系统、显示和其他程序，留给模型的比标称容量少一截。Ollama 0.40.0 起，Apple Silicon 上凡是 MLX 支持的架构都自动用 MLX 运行，Gemma 4 在列。

候选快照

数据核验时间：2026-10-29，依据各家官方模型卡。截至这一天，尚无公认的“最佳本地编码模型”。实际表现取决于具体的量化方案、推理运行时、Prompt 模板、上下文长度及 Harness 配置。

按内存档位排的候选

内存档位	先试	也可以试	先要确认
8 GB 显卡	Gemma 4 E4B：有效参数 4.5B，128K 上下文；官方 QAT q4_0 GGUF 5.15 GB	MiniCPM5-2B：2.5B 稠密（不含嵌入层 1.98B），131,072 上下文，Apache-2.0，官方提供 GGUF、MLX 和 GPTQ	这一档只适合分拣、查询生成和单文件小改。LiveCodeBench v6 上 E4B 52.0、MiniCPM5 69.1，都是厂商数字；MiniCPM5 在 SGLang 中要用 minicpm5 工具调用解析器
12 GB 显卡	Gemma 4 12B：11.95B 稠密，256K 上下文，LiveCodeBench v6 72.0；官方 QAT q4_0 GGUF 6.98 GB	8 GB 档的模型，配更长的上下文	文件占掉约 7 GB，剩下约 5 GB 给 KV 缓存和运行时
16 GB 显卡	gpt-oss-20b：总参 21B / 激活 3.6B 的 MoE，MXFP4 量化，模型卡写明可在 16 GB 内存中运行，Apache-2.0	Gemma 4 26B-A4B：总参 25.2B / 激活 3.8B 的 MoE；官方 QAT q4_0 GGUF 14.4 GB	gpt-oss 要求运行时支持 Harmony；Gemma 26B 的文件放下以后，上下文只剩不到 2 GB
24 GB 显卡	Devstral Small 2 24B：Apache-2.0，256K 上下文，SWE-bench Verified 68.0（厂商数字）；模型卡称单张 RTX 4090 可以运行	Gemma 4 31B：30.7B 稠密，LiveCodeBench v6 80.0，官方 QAT q4_0 GGUF 17.7 GB。Qwen3.8-27B：27B 稠密，Apache-2.0，原生 262,144 上下文，4-bit 下光权重约 13.5 GB	Devstral 在 vLLM 中要加 --tool-call-parser mistral --enable-auto-tool-choice。Qwen3.8-27B 没有官方 GGUF，只有约 1,600 个社区量化；它默认开启思考，可按请求用 enable_thinking: False 关掉
Mac 16 GB	Gemma 4 E4B 或 12B 的 QAT GGUF	MiniCPM5-2B 的官方 MLX 4-bit 版	mlx-lm 0.31.2 加入了 Gemma 4 的工具调用解析器，0.32.0 加入了 MiniCPM5 的。gpt-oss-20b 标称 16 GB，和系统共用这块内存就太紧
Mac 32 GB	Devstral Small 2 24B：模型卡称 32 GB 内存的 Mac 可以运行	Gemma 4 26B-A4B 或 31B 的 QAT GGUF（14.4 / 17.7 GB）；gpt-oss-20b	先确认运行时对 Devstral 的 Mistral 工具调用格式、对 gpt-oss 的 Harmony 都能正确解析
Mac 64 GB	Qwen3.8-27B 或 Qwen3-Coder-30B-A3B 的 8-bit 社区量化，光权重约 27–31 GB	Flint 40B-A2.5B：Recursive 的编码 Agent 模型，总参 39.8B / 激活约 2.5B。262,144 上下文，Apache-2.0，SWE-bench Verified 74.2（厂商数字）；Ollama 版 23 GB	Qwen3-Coder-30B-A3B 只有非思考模式，原生 262,144 上下文。Flint 的官方模型卡按单张 B300 或 H200 部署，没有官方量化文件，Ollama 版是另行打包的

注意：“先试”和“也可以试”是按文件大小和模型定位做的推断，并非模型卡上的官方建议。MoE 的“激活参数”仅描述单 Token 计算量，不会减少模型文件的总权重体积。表中“光权重约多少 GB”按参数量乘以每参数字节数估算（4-bit 为 0.5 字节，8-bit 为 1 字节），不含 KV 缓存。

真正进入选型的候选，统一用本地模型评测协议复测。

选型维度

下载模型前，先明确要解决的问题，再逐项核对候选模型在实际工程中的表现。最关键的是生成的补丁能否直接应用、工具调用格式是否合法，以及它在仓库主力语言（而非仅仅 Python）上的真实水平。稳定度同样重要，需要观察多次运行下来结果真正被采纳的比例。

运行代价方面，要结合具体硬件看首字延迟、峰值显存、CPU 卸载压力以及实际可用的上下文长度。同时确认所选推理引擎支持它的对话与推理格式，留意具体模型文件对应的许可证与分发约束，并在多语言输入及安全拒绝边界上测试它是否会频繁误拒。

基于角色的路由策略

在日常工作流里，可以按任务后果分派不同体量的模型。小模型适合文件分类、检索词构造、日志精简和单文件机械修改等低后果、能在外部直接验证的步骤；大一档的量化模型则用来做有边界的实现或代码审查。无论用哪一档，改动都在仓库副本里做、跑测试，失败了直接丢弃副本，不碰工作目录。涉及架构设计、安全敏感操作或反复出现的同一错误时，就升级到更强的模型或交给人；什么时候算“完成”、什么时候该停，见有界 Agent 循环。

我的阅读