模型列表已于 2026 年 10 月 14 日 核对。以下推荐是针对不同工作负载的测试顺序，而非新一轮受控编程基准测试的结果。除了模型权重本身，还要为上下文和运行时缓冲区预留内存。
合适的本地编程模型，是能够完全装入 GPU 显存、并为上下文留出空间的最大模型。而”为上下文留出空间”这一点，往往比大多数人想象的更关键。一个 32B 模型在完全驻留显存时能以每秒 60 个 token 的速度运行，一旦溢出到系统内存就会骤降到每秒 1–2 个 token。对于一个需要循环执行数十次工具调用的编程智能体来说，这就是”能用”和”根本没法用”的区别。
所以问题不是”最好的 Ollama 编程模型是什么”，而是”我的显卡能装下的最好模型是什么”。本指南按当前 NVIDIA RTX 消费级 GPU 的显存档位，逐一推荐适配的编程模型、预期速度，并指出何时应放弃本地推理、转用云端模型。
如需了解模型本身的排名，请参阅最佳 Ollama 编程智能体模型。本文是其硬件配套篇。
快速对照：GPU 与模型
| GPU | 显存 | 当前测试候选 | 上下文预算 |
|---|---|---|---|
| RTX 5090 | 32GB | qwen3.8:27b、muse-glimmer:30b、qwen3-coder:30b | 先从有限范围开始；扩展前先测量 |
| RTX 4090 / 3090 | 24GB | 相同的工作站候选，需选择合适的构建 | 余量更少；检查实际分配 |
| RTX 5070 Ti / 4070 Ti Super / 4060 Ti 16GB | 16GB | gemma4:e4b、qwen3:8b、经过验证的较小 14B 构建 | 更短的上下文；考虑运行时开销 |
| RTX 3060 12GB | 12GB | qwen3:8b、gemma4:e4b（如果构建能装下） | 短上下文 |
| 8GB 显卡 | 8GB | 实际能装下的较小 Gemma 或 Qwen 构建 | 检查权重加上下文，而不能只看名称 |
本次更新未运行新的每秒 token 数基准测试。旧的速度数据不能直接套用到 Qwen3.8 或 Muse Glimmer 上。请在代表性任务中使用 ollama ps 来检查驻留情况和内存占用。
32GB：RTX 5090
在同一个仓库任务上对比 Qwen3.8 27B、Muse Glimmer 30B 和 Qwen3 Coder 30B。Qwen3.8 和 Muse Glimmer 的默认下载约为 18GB，在 32GB 显卡上为上下文和运行时缓冲区留有一定空间。
ollama pull qwen3.8:27b
下载大小并非完整的工作内存占用。在确定默认选项之前，请在你的目标上下文长度下测量内存和延迟。Nemotron 3.5 Lightning 的默认下载较大，约为 25GB；长上下文需要更多余量。
即使在 5090 上，复杂的多文件任务也更适合交给前沿云端模型。将 haimaker 作为云端提供商与本地 Ollama 并行配置，当本地模型无法完成任务时即可切换。
使用 HAIMAKER 路由本地与云端模型24GB：RTX 4090 和 RTX 3090
Qwen3.8 27B、Muse Glimmer 30B 和 Qwen3 Coder 30B 是这一档位的候选。约 18GB 的下载在 24GB 硬件上留下的余量比 32GB 显卡更少。请检查实际的上下文占用，不要想当然地认为官方标注的最大上下文窗口能完整装下。
ollama pull qwen3.8:27b
不同的量化方式会同时影响质量和内存占用。选用模型发布方提供的量化标签，然后在你的显卡上对比任务正确完成率和延迟。
16GB：RTX 5070 Ti、4070 Ti Super、4060 Ti 16GB
从 Gemma 4 E4B、Qwen3 8B 或经验证的较小版本 Qwen3 14B 开始。为上下文和运行时缓冲区留出空间。
ollama pull qwen3:8b
gpt-oss 20B 的下载约为 14GB，因此 16GB 硬件在智能体会话期间可能会比较吃紧。短上下文或许可以工作，但请检查实际分配。MoE 模型的活跃参数量描述的是计算量，而非需要存储多少专家权重。
12GB：RTX 3060 12GB 及类似显卡
在 12GB 档位，8B 级别是甜点选择。Qwen3 8B 能以交互速度运行，胜任日常智能体工作：解释不熟悉的代码、编写小函数、起草测试、总结日志。
ollama pull qwen3:8b
你可以将 Q4 量化的 14B 模型（约 8GB）塞进 12GB 显卡，但上下文空间会很快捉襟见肘。对于流畅的智能体循环，一个完全驻留的 8B 模型通常比一个争抢内存的 14B 模型体验更好。
8GB：入门级显卡
8GB 需要小构建和短上下文。在假设能装下之前，请先检查 Gemma 4 E4B 或 Qwen3 8B 的实际下载大小加上运行时分配。
ollama pull gemma4:e4b
对这个档位要设定合理的预期。它适合代码解释、样板代码生成和小型单文件编辑，但不适合让编程智能体执行多文件重构。一旦智能体开始打开文件、修改补丁、处理工具输出，较小的模型就会跟不上节奏。
胜过一切基准测试的规则
让模型完全驻留在显存中。其他一切都是次要的。
- CPU 卸载会急剧降低吞吐量；请测量实际模型和卸载配置的表现
- 量化是让模型装下的手段：Q4_K_M 是实用的默认选择，Q5/Q8 仅在有富余显存时使用
- 提示处理在每张显卡上都很快；token 生成才是瓶颈，且与显存带宽成正比
- 一个完全驻留的小模型永远胜过一个需要交换内存的大模型
选择量化版本时，为上下文留出余量。一个在 0K 上下文时能装下但在 16K 时溢出的模型会在会话中途交换内存——这是最糟糕的情况。
何时改用云端模型
当隐私、成本或离线工作很重要时，本地是最佳选择。但它并非在每个任务上都自动更优，任何消费级 GPU 都改变不了这一点。在以下情况下请使用云端模型：
- 任务涉及多个文件
- Bug 很隐蔽，需要强推理能力
- 你需要可靠的工具调用
- 变更将触及生产环境
- 你没有时间逐行审查生成的代码
实用的做法是本地优先，而非仅限本地。在你的 RTX 显卡上运行 Qwen3 Coder 或 14B 模型来处理廉价且私密的日常任务，当任务变难时再升级到更强的云端模型。
如何将本地和云端模型一起路由
- haimaker.ai — 一个云端提供商，可以在你的智能体中与 Ollama 一起配置，用一个密钥即可访问你对比的云端模型
- Ollama — 在你的 RTX 显卡上运行本地模型，通过 localhost 上的 OpenAI 兼容 API 提供服务
- 你的编程智能体 — 将 OpenCode、OpenClaw 或任何 OpenAI 兼容的智能体指向本地端点处理低成本工作，指向云端端点处理其余任务
总结
选择适合你实际显卡的模型和上下文。在 24–32GB 硬件上测试当前工作站候选模型，在更低配置上测试较小的构建。更新的模型只有在能以你可容忍的延迟准确完成任务时才有用。
如需了解模型本身的排名，请参阅最佳 Ollama 编程智能体模型。如需 OpenClaw 专属的本地配置，请参阅OpenClaw 最佳本地模型。