Qwen models end the entire chat when thinking ends

快速结论：这个现象通常出现在 Qwen 模型进行长思考输出时，表现为对话在思考结束后看起来被“直接截断”；优先排查 num_predict 上限和上下文缓冲区是否已用尽，而不是先怀疑模型本身在思考结束时会终止会话。

适用环境：Issue 中确认的环境为 Linux、Nvidia GPU、AMD CPU、Ollama 0.33.3；维护者在回复中使用 ollama run qwen3.8 做了对照测试。

最快修复方案：暂无确认的一步修复方案。可优先尝试调大上下文长度（Issue 回复者通过将 OLLAMA_CONTEXT_LENGTH 增加到 131072 后恢复正常输出），并同时检查 num_predict 是否被设得过小。

注意事项：“Qwen 模型在思考结束时结束整个对话”这一结论并未被 Issues 讨论证实；维护者明确表示 Qwen 模型不会在 thinking 结束后结束会话。OLLAMA_CONTEXT_LENGTH 调大会显著增加显存/内存占用，需要根据硬件承载能力调整，131072 只是回复者本机验证可行的取值，并非通用推荐值。

问题场景

用户在 Ollama 0.33.3（Linux + Nvidia GPU）中运行 Qwen 系列模型，并开启了 thinking（思考）输出。模型输出大量内部思考内容后，正文回答没有正常接续，用户观察到整个对话运行似乎被终止。日志中可以看到思考内容在 “Wait, could … be related to …” 之类的句子后戛然而止，随后出现 >>> 标记。

报错原文

Qwen models end the entire chat when thinking ends

日志中实际表现的截断位置（节选）：

    *   Wait, could "Micron Markup" be related to **"Microchip"**? Maybe the user thinks it's a 
subsidiary of Microchip?
    *   If so, I should clarify that too.
    *   But the question

>>>

The parts above the >>> are thinking.

维护者对照测试中的正常输出为：

Thinking...
...done thinking.

Hello! How can I help you today?

原因分析

根据维护者的回复，这更像是触发了 num_predict 输出上限，或者上下文缓冲区已被填满。长思考内容会消耗大量 token：当 thinking 部分耗尽可用输出预算或上下文空间时，正文回答就没有余量继续生成，从用户视角看就像是“思考一结束、整个对话就结束”。

此外，问题发生时使用的客户端未在 Issue 中说明，客户端对 thinking 标签的处理方式也可能影响显示，但这属于尚未验证的可能原因。

环境排查

确认 Ollama 版本（Issue 中为 0.33.3），排查版本差异是否与 thinking 解析相关。
确认当前 OLLAMA_CONTEXT_LENGTH 取值，判断是否远小于长思考所需上下文。
确认请求中或 Modelfile/API 参数里的 num_predict 是否被设置得过小或为负数以外的固定上限。
确认使用的客户端类型，以及客户端是否会单独渲染 thinking 内容；客户端未说明时不建议直接归因于模型。
确认 GPU 显存是否足以支撑更大的上下文；Issue 记录了 Nvidia GPU、AMD CPU、Linux，但未给出具体显存和驱动版本。
用 ollama run 命令行直接对照测试，排除客户端因素。

解决步骤

先用命令行复现：运行 ollama run 加载同一 Qwen 模型，输入同样或相近的长思考问题，确认截断是否在官方 CLI 下同样出现。
检查当前 num_predict 设置。若被固定为较小值，先取消或调大，确保 thinking 之后仍有输出预算生成正文。
调大上下文长度：Issue 回复者将 OLLAMA_CONTEXT_LENGTH 增加到 131072 后恢复正常。修改后需重启 Ollama 服务使配置生效。
由于上下文扩大后显存占用会上升，若出现显存不足，可回退到硬件能承受的较小值，再结合缩短问题长度、减少思考内容来验证。
换用另一客户端做交叉验证，判断截断是否只出现在某一客户端的 thinking 渲染环节。