事件背景
据
r/LocalLLaMA 社区用户 onil_gova 发
帖披露，阿里巴巴最新发布的 Qwen3
.6 模型引入了一个新的 preserve_thinking 参数。该参数的作
用是在多轮对话中将模型的思维链（chain-of-thought）推
理内容保留在上下文中。这一改动直接解决了
Qwen 3.5 中存在的 KV cache 失效问题——在旧版本中，推理
token 会在每轮对话时被剥离并以
不同方式重新序列化，导致缓存连续性被
破坏，进而影响 Agent 的整体表现。
Qwen
官方模型页面明确指导开发者将参数设置为 "
preserve_thinking": True，以替代此前的临时方案
"chat_template_kwargs": {"preserve_thinking": False}。该功能为选择性启
用（opt-in），必须显式开启，默认情况下不会自
动激活。
为何值得关注
KV cache 失效并非 无关紧要的表面问题。当模型在会 话中途丢失此前的推理 token 时，推理引擎必须在每一轮对话中 对完整上下文窗口重新计算 attention。对于需要工 具调用、多步规划、迭代式代码生成等操作的长 Agent 链路 而言，这直接转化为更高的延迟和更多的 token 消耗。
根据
帖子引用的 Qwen 官方文档，preserve_thinking「在
Agent 场景下尤为有益，完整保留推理上下文有
助于提升决策一致性，并在许多情况下通过减少冗余推理来降低整体
token 消耗」。言下之意：在生产环境中运行 Q
wen3.6 Agent 流水线却未启用该参数的团
队，正在为每一次推理调用付出持续累积的额外成本。
两种状态下的行为差异是具体可见的。未启用该 参数时，模型将完全失去对自身此前思维链的访问能 力——这一缺口会在单次会话中表现为事 实性不一致或明显的「失忆」现象。启用后，模型能够将此 前的推理步骤作为一等公民的上下文加以引 用，这对以下场景具有重要意义：
- 需要整合中间输 出结果的多步工具调用 Agent
- 早期架构推理会 影响后续实现决策的代码生成循环
- 任何跨越 一轮以上、使用思维模式（thinking mode）的工作流
技术细节
据 onil_gova 描述，问题根源出在 chat template 本身。Qwen 3 .5 的模板在序列化对话历史之前会剥离 thinking token，这意味着以特 定字节序列为基础构建的 KV cache 会在每一个新轮次因前 序 token 的序列化形式发生变化而失效。Qwen3.6 在 模板层面解决了这一问题，通过以原始形式保留 thinking block，确保缓存键（cache key）在各轮之间保持稳定。
该参数可在推理时传入。对于使用 chat_template_kwargs 的框
架，正确的调用方式为：
{"preserve_thinking": True}验证方法简单直接。社区记录的测试方
法如下：提示模型在不使用工具的情况下生成两个 20 位数字，然
后在下一轮中询问第二个数字。在 preserve_thinking 关闭的状态下，模型会
回答第二个数字不存在——因为它无法访问此
前的推理内容。启用该参数后，模型能够立即从保留的 thinking 上下文中检
索出第二个数字。
根据 Qwen 官方模型页面，该参数同时适用于 thinking 和非 thinking 推理模式，这意味着 KV cache 效率的提升并不局限于显式思维链工 作流。
后续动态
截至本文发布时，各运 行时的支持情况尚不完整。r/LocalLLaMA 帖子证 实，LM Studio 目前尚不支持该参数。oMLX 项目目 前有一个由 onil_gova 提交的开放 Pull Request，正在推进 对该参数的支持，但尚未合并。使用其他运行时的开 发者——包括 vLLM、llama.cpp、Ollama、Transformers——应在 假定参数已生效之前，先验证自 己的推理服务栈是否正确处理了该参数。
- LM Studio：已确认暂不支持，请关 注下一个版本周期的更新。
- oMLX：PR 已开放，尚未合并 。
- vLLM / Transformers：根据现有信息，状态未经确认——在 部署至生产 Agent 流水线之前，请务必验证模板处理逻辑。
- Ollama：状态未 经确认——可能需要在 modelfile 层面进行模板自定义。
任何在 Agent 或多轮生产环境中运行 Qwen3.6 的团队，都 应立即审查自己的运行时配置。默认关闭该参数意味着你 的系统正在沿用 3.5 版本中同 样的 cache 失效行为——白白损失本可获得的推理效率。