Ollama refusing toolcalls, which always worked fine in llama.cpp with qwen.

快速结论：该问题通常出现在客户端把包含 tool 角色的消息历史（例如 system → user → assistant → tool → assistant 的连续对话）提交给 Ollama 时，Ollama 返回 invalid request 并拒绝 tool 角色，而同一 GGUF 模型在 llama.cpp 中工作正常。优先排查消息提交路径是原生 Ollama /api/chat 还是 OpenAI 兼容的 /v1/chat/completions，以及是否在 Modelfile 中使用了 tool 角色。

适用环境：Issue 已确认操作系统为 Linux，GPU 为 Nvidia，CPU 为 AMD；用户使用同一 GGUF 的 Qwen 模型，在 llama.cpp 中可正常工作。Ollama 版本、Python、CUDA、PyTorch 等版本在 Issue 中未提供，无法确认。

最快修复方案：暂无确认的一步修复方案。Issue 中维护者使用原生 /api/chat 提交 user → assistant(tool_calls) → tool 消息链时验证 Ollama 可以正常处理 tool 角色；因此可优先尝试改用原生 /api/chat 端点复现，以区分是否为客户端或 OpenAI 兼容层的问题。

注意事项：该 Issue 最终以 needs more info 关闭，用户始终未提供可复现的最小请求和实际报错文本，因此无法确认根因，也未确认任何修复版本。维护者明确表示 tool 角色仅在 Modelfile 中被拒绝，而 API 请求中的 tool 角色可以正常工作；这一结论与用户实测现象存在冲突，需要结合具体客户端和端点自行验证。

问题场景

用户基于 llama.cpp 开发了一个 Agent 客户端，使用 Qwen 的 GGUF 模型。同样的客户端和模型换到 Ollama 后，当客户端在连续对话中回放包含 tool 角色的消息历史时，Ollama 拒绝该 tool 角色并报 invalid request，而 llama.cpp 可以正常处理。用户期望保持 system → user → assistant → tool → assistant → tool → assistant → user 这样的连续消息流，以复用 KV cache，避免每次工具调用后重建上下文。

报错原文

Ollama refusing toolcalls, which always worked fine in llama.cpp with qwen.
ollama says invalid request because it refuses the tool role
Server error '500 Internal Server Error' for url 'http://127.0.0.1:11434/v1/chat/completions'

原因分析

可能原因有以下几种，Issue 中未给出最终确认：

用户最初描述的现象是 Ollama 拒绝 tool 角色。维护者回应称，tool 角色只在 Modelfile 中被拒绝，理由是工具调用携带的信息通常可以聚合进 system message；但对于 API 聊天请求中的 tool 角色，Ollama 是可以处理的。
用户使用的是 OpenAI 兼容端点 /v1/chat/completions 时曾出现过 500 错误（用户自述无法稳定复现），因此问题可能出在 OpenAI 兼容层对 tool 消息的转换或校验上，而非原生 /api/chat 端点。
用户表示无法提供实际错误信息和可复现请求，维护者也表示“zero information that is actionable”，因此也无法排除客户端发送的消息结构、Modelfile 配置或请求体与 Ollama 预期格式不一致。

环境排查

确认 Ollama 版本（Issue 中未提供，需自行记录 ollama --version）。
确认操作系统为 Linux、GPU 为 Nvidia，与 Issue 报告环境一致。
确认使用的模型为与 llama.cpp 相同的 Qwen GGUF，并核对 Ollama 中的模型名称与 Modelfile。
确认客户端调用的端点是原生 /api/chat 还是 OpenAI 兼容的 /v1/chat/completions。
确认 Modelfile 中是否使用了 tool 角色，以及客户端提交的 JSON 中 messages 的角色序列是否符合预期。
确认是否存在 CUDA、驱动或 Python 侧版本差异；Issue 中未提供这些信息，不作为结论依据。

解决步骤

先不要依赖客户端，用 curl 直接向 Ollama 原生端点构造与客户端相同的消息链，确认 Ollama 是否拒绝 tool 角色。维护者在 Issue 中给出的可工作示例为：{"role":"user",...} → {"role":"assistant","tool_calls":[...]} → {"role":"tool","content":"..."}，提交到 localhost:11434/api/chat，并设置 "stream":false。
如果原生 /api/chat 能正常返回，而你的客户端走的是 /v1/chat/completions，则问题可能位于 OpenAI 兼容层，可优先尝试让客户端切换到原生端点，或对比两个端点发送的请求体差异。
检查 Modelfile 内容，确认没有把 tool 角色写进 Modelfile；如果确实写入了，将其移除或改为把工具返回信息并入 system message。
如果需要在多轮工具调用之间保留 KV cache，用户主张不要改写更早的消息（尤其不要改写 system message），因为这会令已缓存的 KV 状态失效；但这一优化思路在 Issue 中未得到维护者确认，属于用户侧设计考量，可自行评估。
如果问题仍可复现，按维护者要求准备最小可复现信息：具体端点、完整请求 JSON、Ollama 版本、模型名称，以及返回的完整错误文本。

验证方法

使用与客户端相同的消息序列，通过 curl 分别请求原生 /api/chat 和 /v1/chat/completions，观察是否返回 200 与正常 completion。如果原生端点返回正常而 OpenAI 兼容端点失败，说明问题与端点实现有关；如果两者都失败，则记录完整请求与返回的 JSON 错误信息用于进一步排查。Issue 本身以 needs more info 关闭，未提供最终验证结果。