在本地部署大模型（如基于 ninfer、vLLM 等引擎）跑复杂的 Agent 任务时，上下文窗口爆炸和KV Cache 命中率暴跌是我们最头疼的两座大山。
为了控制上下文，很多开发者会顺手把 preserve_thinking 设为 no，试图通过剥离历史思考内容来省显存。但当你打开监控面板，往往会看到一幅惨烈的景象：命中率剧烈抖动，大量的“折叠后重建”块，首字延迟（TTFT）飙升。
今天，我们抛开表面的现象，从推理引擎的底层架构出发，对比本地部署中最常见的两种策略：
- 极端克制：
preserve_thinking=no（直接剥离历史思考）
- 高级控制：
preserve_thinking=true + 上下文压缩（保留思考，必要时智能折叠）
第一部分：认清假象——no 到底在什么时候引发断崖？
首先纠正一个常见误区：并不是你一用 preserve_thinking=no，缓存就立刻瘫痪。
根据 Qwen 等模型的模板渲染规则：keep_thinking = preserve_thinking || (i > last_query_index)。
这意味着，在最后一次真实用户提问之后的“未闭合回合”里，思考内容是恒保留的。
- 单轮内的 Agent Tool Loop：用户问了一次，Agent 自动连续调用 5 次工具。这属于同一个回合，
no 不会剥离思考，缓存是完美命中的。
- 真正的灾难发生在“跨用户轮次”时：一旦用户插入了新的提问，历史 5 轮的工具调用和思考会被一次性全部剥离。原本连续的 Token 序列瞬间在
assistant 起始符处分叉。
分叉的后果是什么？
- 孤儿 KV 占据显存：生成时写入的思考 KV 还在，但新 prompt 里没有对应 Token，无法复用。
- 被迫回滚重算：引擎的严格前缀匹配（Token 级精确对齐）失败，只能回退到早期的轮次检查点（
restore_turn_checkpoint）。你的 GPU 不得不把上一轮已经算过的正文再重新 prefill 一遍。
- 上下文污染被强行切断：这其实是
no 唯一的好处——如果模型上一步想错了，剥离思考可以防止它沿着错误思路“钻牛角尖”。
第二部分：true 模式的隐忧与“自主压缩”的陷阱
既然 no 会在跨轮时断崖，那一直开启 preserve_thinking=true 行不行？
在长程对话中，思考内容会随轮次无限累加，很快撑爆显存和上下文窗口（比如 197K 的红线）。
这就引出了学术界热门的解法：true + 自主压缩（Agentic Context Compaction）。
例如 SelfCompact 等论文提出，让模型具备元认知，在接近窗口上限时，自己把历史总结成一段摘要。
但工程落地并没有想象中美好：
- 缓存安全分叉极难落地：最理想的压缩，是把指令作为尾部 user 消息追加（复用旧缓存），让模型输出摘要。但在现有的框架中，动态替换历史消息极易破坏 Token 序列的稳定性，导致下一轮缓存全毁。
- 信息有损与元认知差距：论文明确指出，如果不加严格的规则约束，模型根本不知道什么时候该压缩。它经常在推导中途触发，把关键的工具 ID、报错代码或特定约束给“总结”没了，直接导致 Agent 执行崩溃。
- BPE 漂移：回传的思考格式如果差一个空格，缓存就会退化为
restore_response_checkpoint，重算整条响应。
第三部分：本地部署务实选型：到底什么时候用 true，什么时候用 no？
受限于单机显存和算力，本地部署的选型不能盲目跟风。你需要根据业务场景对症下药：
✅ 必须使用 preserve_thinking = true 的场景
核心特征：需要跨轮次的逻辑连续性，对首字延迟（TTFT）极度敏感，硬件资源可支撑上下文膨胀。
- 复杂 Coding / Debug 场景：代码修改和报错排查是严密的逻辑推导。模型必须记住上一轮“为什么这么改”以及“之前的报错堆栈是什么”。剥离思考会导致模型频繁“失忆”，反复给出无效建议，甚至陷入死循环。
- 长程 Agent 任务（多步工具调用）：在规划复杂任务（如研报生成、多步数据分析）时，Agent 需要依赖上一步的推理结论来决定下一步调用什么工具。保留思考能保证决策链不断裂。
- 高频多轮交互应用（如智能客服、虚拟伴侣）：用户会在短时间内频繁追问。开启
true 能让引擎走 append_frontier 路径，KV 缓存命中率稳定在 95%-99% 以上，提供极致的低延迟体验。
- 数学推导、学术研究辅助：复杂公式的推导需要严密的连贯性。保留历史草稿，模型才能在此基础上继续做下一步变换。
- 有充足显存或支持磁盘缓存的服务器环境：硬件扛得住 Prompt 体积线性增长的压力。
???? 适用 preserve_thinking = no（默认 false）的场景
核心特征：单次任务闭环、对上下文体积敏感、需要清理错误思路、或纯文本轻量问答。
- 单次 Agent 任务（One-shot Tool Loop）：用户只提问一次，Agent 在后台自动连续调用工具。此时思考内容处于“未闭合回合”，引擎根本不会剥离，全程缓存完美命中；任务结束后，历史不占用后续显存。
- 极简聊天问答 / 知识检索：如翻译、天气查询、名词解释。无需复杂的逻辑推理，历史思考毫无价值，剥离后能节省大量 Token。
- 极度显存受限的本地部署：比如 16G/24G 消费级显卡。虽然
no 会导致下一轮重算（浪费算力），但这比直接 OOM（爆显存）要好。两害相权取其轻。
- 防止“上下文污染”与纠错：如果模型上一步想错了，保留思考会导致它沿着错误路径“钻牛角尖”。用户发新消息时，
no 机制会强行剥离错误思考，相当于帮模型“刷新重启”，让它重新思考。
- 对历史连贯性无要求的流水线作业：如批量处理独立的文档摘要、情感分析。每一次请求相对独立，不需要依赖多轮历史。
???? 快速决策指南：
如果你在做 Coding 或 复杂自动化 Agent，且硬件允许，无脑开 true。
如果你在做 单次任务分发、轻量闲聊，或模型经常钻牛角尖，保持 no。
第四部分：终极解法与工程落地
在极端长程对话中，preserve_thinking=true 迟早会面临窗口溢出的问题。此时，受控的上下文压缩是唯一出路。
工程落地时，必须注意以下三个关键细节：
- 拒绝“完全自主”，采用外部强制摘要：不要完全指望模型自己触发压缩。应通过独立的规则或小模型，在上下文达到 80% 时，强制把最老的几轮对话总结成一段固定格式的摘要。
- 接受短暂的阵痛：当发生压缩时，接受这一轮
full_reset 带来的短暂算力阵痛。只要把摘要作为新的稳定前缀，下一轮马上就能重新开始 99% 的命中率攀升。
- 底层显存优化兜底：对于极端显存受限，老老实实上 KV Cache 量化（INT8/FP8） 或底层驱逐策略，而不是靠在上层删减 Token 来硬省。剥离文本导致的频繁全量
prefill，会带来巨大的瞬时算力峰值，反而可能直接 OOM。
总结
preserve_thinking=no 并不是一无是处，它适用于“单轮内闭环”的场景，帮你清理错误记忆；但在高频多轮的 Agent 场景下，它会像慢性毒药一样拖垮你的 KV 缓存。
在算力寸土寸金的本地机器上，先保 Token 对齐，再谈上下文压缩。用 true 守住命中率的底线，用受控的压缩策略解决窗口溢出，才是让本地大模型跑出云端体验的硬核解法。