2026年9月 Ollama 编程模型实测推荐

参数规模 9 亿的模型击败了 270 亿的模型——只要你给它的是一份扫描文档而非一段对话。这一事实揭示了"本地模型 Top 10"榜单毫无用处的原因：它们按规模排序，而选模型看的根本不是规模。

我花了一个周末，按任务类型而非参数量来筛选 Ollama 模型库。以下是 2026 年 9 月底的地形图——以及更重要的是，当下面这些名字全部被替换之后依然适用的三条法则。

法则 1：看标签，别看名字

按最新排序 Ollama 模型库，排在最前面的是 deepseek-v4.1-flash、glm-5.3、kimi-k3、minimax-m3。这四个都带有 cloud 标签。

这意味着 ollama run 会把你的提示词发送到别人的服务器上。这是尝试一个根本不可能装进你电脑的模型的好方法。但这不是本地推理——如果你来这里是为了隐私或离线工作，这些行首先被划掉。

法则 2：专精模型在其主场碾压规模

本月最清晰的例子是 glm-ocr：9 亿参数，2.2 GB 磁盘占用，在 OmniDocBench V1.5 上以 94.62 分占据榜首。给它喂一份排版混乱的发票——嵌套表格、脚注和公式混杂——它照样hold住。一个通用型 270 亿视觉模型做不到——没人训练过它理解文档结构。

正确的流程枯燥但有效：glm-ocr 把文档转成结构化文本，然后通用模型基于这些文本进行推理。

法则 3：基准测试不是你的任务

SWE-bench 这个人人挂在嘴边的数字，测量的是根据 issue 描述在陌生仓库里修一个 bug。这与"帮我写这个函数"完全不同，与"解释这段代码是干什么的"更是毫无相似之处。你用来做自动补全的模型，SWE-bench 分数高说明不了什么问题。

Qwen3.8-27B 于 8 月 14 日发布：278 亿 Dense 参数，Apache 2.0，Ollama 构建体 17.7 GB，256K 上下文窗口，含视觉能力。Qwen 报告的数据：Terminal-Bench 2.1 得分 73.0（较上代 63.4 提升），SWE-bench Pro 61.7，LiveCodeBench v6 90.3，OSWorld-Verified 84.3（较上代 63.9 提升）。在相同架构上，其 Artificial Analysis 指数比上一代提升了 14 点——全部来自后训练。

如果 18 GB 权重超出承受范围，选择在两个更小的之间：

这些吞吐量数字来自 Artificial Analysis 在提供商硬件上的测试——在家里会低一些，比例关系才是关键。大多数评测忽略的一个细节：Devstral 的上下文开销大约是别人的两倍，每 32K tokens 约 5 GB，而 MoE Qwen 只要 3 GB。在一台内存紧张的机器上，这直接决定结果。

Agents：Meta 回来了，这才是本月惊喜

三周前，Meta 还是开放权重领域的反面教材——这家公司发明了这套策略，结果在 OpenRouter 上的 tokens 占比还不到百分之一。如今 muse-glimmer 已入驻 Ollama 模型库：300 亿参数，Apache 2.0，18.2 GB，128K 上下文，三周内超过二十万次拉取。

模型卡写得很克制：专为"工具使用、长任务和故障恢复"调优。不是最聪明的——而是最能完成的那个。Meta 报告的数据：MCP Atlas 75.5，SWE-Bench Pro 51.2，AIME 2026 94.7。

这种表述才是真正的教训。Agent 任务不是给出一个答案，而是一百个连续给出。正确率 90% 但永远察觉不到自己错误的模型，打不过正确率 85% 但能发现并重做错误的模型。

隔壁是 NVIDIA 的 nemotron-3.5-lightning（8 月 11 日）：总共 300 亿，活跃参数 30 亿，交织 Mamba-2 和 MoE 层，SWE-bench Verified 51.56，GPQA Diamond 75.44，MMLU Pro 81.94。头条的 1200 tokens/秒是提供商硬件的测量值，不是笔记本的——但架构确实是专为快速吐 token 打造的。

Writing：诚实的答案仍然是"本地不行"

在 EQ-Bench Creative Writing v3 上，榜首是闭源的：Claude Opus 5 以 2121 Elo，GPT-5.6 Sol 以 1963。开放权重最高分属于 Kimi K3，得分 2071——这是一个需要多节点集群的 2.8 万亿参数模型。"开放"的意义类似于操作系统源代码对没有芯片代工厂的人开放。

本地真正能跑的是什么，是工作文本：邮件、摘要、润色段落、把通话记录转成结构化文本。那里推荐的是 gemma4，2530 万次拉取，库中下载量最高的模型。

5 月份在 RTX 5070 Ti 上用俄语做的一项测试，让 Gemma 4、Qwen 3.6 和 Qwen3-Coder 跑了十二个实际任务。Gemma 4 快速模式下得分 12/12，Qwen 3.6 得到 9/12。一个比任何指数都更有价值的发现：开启思考模式反而让指令遵循变差——Gemma 从 12 降到 11，Qwen 从 9 降到 7。

Medicine：唯一一个必须用专精模型的领域

先说边界，再说模型。开放医疗模型基于 Health AI Developer Foundations 条款发布，Google 明确表示它们不属于临床级别，需要针对具体任务进行验证。这是一个开发者的构建块，不是面向患者的聊天机器人，也不是第二意见。

在这个边界内，它们确实有用。medgemma1.5:4b——3.3 GB，128K 上下文，含视觉；1.5 版新增了全切片组织病理学、纵向成像、解剖定位和文档理解。在 EHRQA 上得分 89.6%，将检验报告转成结构化 JSON 的 macro-F1 为 91.0。纯文本版 medgemma:27b 在 MedQA 上达到 87.7%。对于由医生分级的广泛健康对话，gpt-oss-120b 在 HealthBench 上以 0.576 领先开放模型——但那是 65 GB 权重。

私人实际用例：把自己的病历整理成可读格式，把几份文档合并成一张表，为就诊准备问题——全部在本地机器上完成，不用把医疗数据送到别人的云端。

Retrieval：嵌入模型比生成模型更重要

本地 RAG 搭建中最常见的错误，是把所有显存都花在大型生成模型上，然后随便抓一个最先想到的嵌入模型。实际应该反过来：如果检索返回的块本来就错了，上面再强的模型也会自信地总结错误内容。

Qwen3-Embedding 系列让你可以把向量维度设成 32 到 1024 之间的任意值——这直接节省了你的向量数据库开销——是你来选择权衡而不是被动继承。

至于上面的生成器，小模型就够用。IBM 的 granite4.2（3B/8B/30B，Apache 2.0，128K）正是为这个场景调优的：RAG、工具调用和结构化 JSON 输出。

下面的规模不是估算值——我从 Ollama 注册表清单中拉取的，所以这是你实际会下载的层的总和，截至 2026 年 9 月 20 日。加载到内存中会更大，取决于你的上下文大小。

刻意缺失的部分

Translation（翻译）。我本来打算写那一节，但诚实的答案是这个细分领域最好的模型是闭源的。Qwen3.8-LiveTranslate，9 月 19 日发布，在 60 种输入语言上以 2.3 秒延迟做同声传译——仅 API，无权重。本地只有通用模型做翻译，"fine"而已。

Ornith-1.5。规模 9B、35B 和 397B，256K 上下文，一个自我改进循环自己生成训练任务，一个月内三十万次拉取。模型库里最有趣的一行——正是它不在我的列表上的原因：目前还没有可比较的独立数据。

在 16 GB MacBook 上

gemma4:12b 作为全能手，外加 glm-ocr 和 qwen3-embedding:0.6b 处理文档和自有档案搜索。所有更重的模型都是另一台机器或租用端点的事。

如果我只能永久保留一个模型，那会是 Gemma 4，选一个能装进去的规格。不是因为它赢了基准测试——它没有——而是因为它做你让做的事，而不是做它觉得更有趣的事。两千五百万次拉取是很多人独立得出相同结论的结果。

原文首发于 klukyanov.ru。

更简短的每周文章（俄语）—— Telegram。

参考配置

下面这些不是估算值——我从 Ollama 注册表清单中拉取的，所以这是你实际会下载的层的总和，截至 2026 年 9 月 20 日。内存占用会更大，取决于你的上下文大小。

模型	参数量	磁盘占用	上下文	许可证
glm-ocr	0.9B	2.2 GB	128K	-
Qwen3.8-27B	27.78B	17.7 GB	256K	Apache 2.0
muse-glimmer	30B	18.2 GB	128K	Apache 2.0
nemotron-3.5-lightning	30B (3B 活跃)	-	-	-
medgemma1.5:4b	4B	3.3 GB	128K	-
medgemma:27b	27B	-	-	-
granite4.2	3B/8B/30B	-	128K	Apache 2.0
gemma4	-	-	-	-
gemma4:12b	12B	-	-	-
qwen3-embedding:0.6b	0.6B	-	-	-