长对话反复读取同一段上下文，SGLang 可以优先保留它的计算缓存

一个多轮 AI 任务，每次都会带上相同的资料开头，再追加新消息。用户看见的是对话继续，模型服务却可能反复处理一大段相同输入。SGLang 的前缀缓存，复用的是这部分计算；它的会话感知缓存还会考虑，哪些缓存仍被活跃会话引用。

这篇适合已经在运行模型服务的人。目标是减少重复计算的机会成本，和助手“记住用户偏好”属于不同层面。

缓存的，是共同前缀的计算结果

官方设计说明解释，前缀缓存按相同 token 前缀复用 KV。对于全注意力模型，后续请求可以复用已缓存的前缀，再计算新增 token。它缓存的不是整份最终答案，问题变化后依然要继续生成。

混合架构的情况更复杂：全注意力需要沿匹配路径的数据，滑动窗口注意力需要边界前的一段连续窗口，Mamba 类状态则需要边界上的快照。Unified Radix Cache 把这些组件放在共享树结构中，由各组件检查可复用的位置。

因此，字符串开头看起来相似，还不足以承诺复用多少。实际 token 前缀、模型结构和缓存是否仍在，都会影响结果。

Session-Aware Radix Cache 文档给出 --enable-session-radix-cache 开关。这项功能由 UnifiedRadixCache 实现，应用需要在同一会话的每次请求中发送相同的顶层 session_id。

请求完成后，可复用的缓存叶节点会登记到这个会话名下。内存需要回收时，未被会话引用的数据通常先淘汰，仍被活跃会话引用的前缀因此有机会留下。共享前缀还能有多个会话引用。

这里是软保护，绝不是内存锁定。未引用数据清理完仍不足时，被引用的缓存也可能淘汰。应用不能靠设置 session_id 就承诺一段历史永远驻留显存。

文档特别强调，session_id 只标记缓存引用，不会追加或重建对话上下文。每次请求仍须包含这一轮需要的完整 prompt；只传新问题和同一个 ID，不能期待服务自动找回之前所有消息。

会话结束时，应调用 /close_session，包括错误和取消路径。它移除该会话的引用，但不会立即释放全部 KV；这些内容仍可复用，只是回到正常淘汰顺序。

这条生命周期很具体：应用保存业务对话，服务缓存模型计算，会话引用帮助后者安排资源。把三者分开，才能在用户关闭任务后正确收尾，也能解释为什么一次缓存命中不代表永久记忆。

SGLang采用 Apache-2.0，实际模型、硬件与缓存层按部署选择。这个机制值得继续研究的场景，是长会话很多、共同前缀反复出现，同时内存又容不下所有缓存的模型服务。