/api/tags omits “tools” capability for deepseek-r1 while /api/show reports it correctly

快速结论：当客户端（例如 VS Code Language Model provider / GitHub Copilot Chat 集成）通过 /api/tags 判断模型能力时，deepseek-r1 会缺少 tools 能力，导致工具调用被误判为不支持。这是 Ollama 列表缓存路径读取 GGUF 时的解析缺陷，优先确认 /api/show 与 /api/tags 的能力是否一致。

适用环境：Ollama 0.30.11；Windows 11 Pro；模型 deepseek-r1:32b；CPU Intel Core i9 14900K；GPU RTX 4090。Issue 中未提供 Python、CUDA、PyTorch 等依赖信息。

最快修复方案：暂无确认的一步修复方案。Issue 中给出的修复是 PR #17254：让 /api/tags 的列表路径读取 tokenizer.chat_template，并以与 /api/show 相同的方式推导 tools/thinking 能力，同时附带回归测试。可优先尝试从该 PR 分支构建验证。

注意事项：上述修复在 Issue 评论中为根因说明与 PR 方案，并非已发布稳定版的确认修复；从分支构建属于未验证操作，落地前需自行承担构建风险。Issue 未给出其他官方临时绕过方法。

问题场景

用户在 Windows 11 上使用 Ollama 0.30.11 加载 deepseek-r1:32b，并通过 ollama show、POST /api/show 与 GET /api/tags 三个入口查询模型能力。前两者都返回 tools、thinking、completion，但依赖 /api/tags 做能力发现的客户端（如 VS Code Language Model provider / GitHub Copilot Chat 集成）只看到 completion 和 thinking，因此错误地禁用了 DeepSeek R1 的工具调用功能。

报错原文

/api/tags omits "tools" capability for deepseek-r1 while /api/show reports it correctly

原因分析

Issue 评论给出的根因是：/api/tags 由模型列表缓存提供，而该缓存使用的 GGUF reader 在遇到第一个 tokenizer.* 键时就停止了，从未读取 tokenizer.chat_template；DeepSeek R1 的工具支持正是在这个 chat template 中声明的。/api/show 会读取该模板，因此两个端点得到的能力集合不一致。修复方向是让列表路径也读取 chat template，并以与 /api/show 相同的方式推导 tools/thinking 能力。

环境排查

确认 Ollama 版本是否为 0.30.11，或是否存在相同版本线的复现。
确认操作系统为 Windows 11 Pro（Issue 环境）。
确认模型为 deepseek-r1:32b。
确认硬件环境：RTX 4090、Intel Core i9 14900K（Issue 环境）。
Issue 未提供 Python、CUDA、PyTorch 等依赖版本，若需进一步排查应自行补全这些信息。

解决步骤

先复现能力差异：执行 ollama show deepseek-r1:32b，确认输出中包含 tools、thinking、completion。
调用 POST /api/show，body 为 {"model": "deepseek-r1:32b"}，确认 capabilities 中包含 tools。
调用 GET /api/tags，检查 deepseek-r1:32b 对应的 capabilities 是否缺少 tools。
如果确认缺少，可优先尝试从 Issue 评论中提到的 PR #17254 分支构建 Ollama，该 PR 让列表路径读取 tokenizer.chat_template 并同步推导能力，附带回归测试。
在分支构建上再次执行上述三个查询，确认 /api/tags 也返回 tools。Issue 评论提到，若能确认 deepseek-r1:32b 在 /api/tags 中显示 tools，将有助于该 PR 落地。

验证方法

重新请求 GET /api/tags，确认 deepseek-r1:32b 的 capabilities 中出现 tools，并与 ollama show deepseek-r1:32b 及 POST /api/show 的结果保持一致。若依赖 /api/tags 的客户端不再禁用工具调用，即说明问题已被修复。