HiState: Hierarchical Prefix Cache Management for Hybrid LLM Serving in Agentic Workloads

用混合模型跑 agent 的推理团队值得读，因为 HiState（这篇论文的前缀缓存系统）不加 GPU 内存，就缓解了一个只在混合模型上才有的缓存失效。混合模型的循环层会把整段前缀压成一个固定大小的快照（论文叫 checkpoint），没法截短回更早的位置。所以 KV 明明还在，只要匹配位置的快照没存过或已被淘汰，就要从更早的快照甚至从头重算一大段。HiState 抓住一个不对称：一次缓存命中要读所有匹配的 KV，却只读一个快照，而且快照大小和上下文长度无关。所以它把大量历史快照放到 SSD，把内存留给 KV；再按存储压力决定每段存多密的快照，并把快照和 KV 放进同一个淘汰队列，按重算代价决定先删谁。在两份公开的编程 agent 请求记录上，p99 TTFT 相对基于 vLLM 的 Marconi 最多加速 5.73 倍，相对 SGLang 的 HiCache 最多加速 5.44 倍。快照多存不占快内存，每次命中也只从慢存储读一个。

它到底在解决什么问题？

先说清楚混合模型的缓存为什么特殊。全注意力层给每个 token 存一份 KV，前缀缓存可以在任意位置截断复用：新请求和旧请求前 5000 个 token 相同，就直接用这 5000 个 token 的 KV。循环层（线性注意力、状态空间模型这一类）不存每个 token 的东西，只维护一个固定大小的状态，每读一个 token 就原地更新一次。读到第 7000 个 token 时，这个状态里已经混进了第 5001 到 7000 个 token 的信息，没法退回到第 5000 个 token 时的样子。所以混合模型要从某个位置接着算，既要这个位置之前的全部 KV，也要在这个位置或更早处存过的一个快照。快照存得比匹配位置早，就从这个快照恢复循环层状态，快照之前的 KV 直接复用，快照到匹配位置之间的 token 重新跑一遍 prefill；一个快照都没有，就要把整段前缀重新 prefill。

普通聊天里这不是大问题：每一轮都是在上一轮后面追加，存好每轮结尾的快照基本就够了。Marconi 这类已有方案主要在每轮结尾和观察到的分叉点存快照。agent 不一样。用一个编程 agent 的会话演示（示意）：

第 6 轮和第 8 轮的 KV 都还在缓存里，却因为缺快照要重算一大段。论文把这类发生在一轮中间的命中叫“内部命中”。还有一种失败：第 1 轮结尾存过快照，但会话往前跑了很多轮，这个旧快照一直没人读，在 LRU 下被挤掉；一个直接的补救是命中时把同一前缀上更早的快照全部刷新访问时间（论文叫全部刷新），但这样所有活跃会话的历史快照都被保住，别的会话在等工具结果时，它最新的那个快照反而会因为“看起来很久没用”被挤掉，下一轮追加时直接缓存未命中。

直接的办法是每隔固定 token 数就存一个快照，但这很贵。论文算过：Qwen3.5-9B 在 32K 上下文里每 1024 个 token 存一个快照，光 FP32 的循环层状态就约 1.6 GB，比同一段的 BF16 KV（约 1.1 GB）还大（第 1 节）。快照把内存占满，别的会话的 KV 就被挤出去，省下的重算又在别处还回去。

整体设计

HiState 是建在 vLLM 上的前缀缓存管理系统，回答三个问题：

关键分工是：分层让快照能多存，间隔控制决定存多密，淘汰决定哪些快照和哪些旧会话该让位。下面拆开讲。

为什么历史快照适合放 SSD，KV 应优先留在快内存？

论文的出发点是一个简单的计数。一段 L 个 token 的上下文，每隔 I 个 token 存一个快照。缓存里存着全部 L 个 token 的 KV 和大约 L/I 个快照。在结尾处命中一次，要读全部 KV，但只读一个快照。论文把“一次命中要读的字节”除以“为这段上下文存的字节”叫访问占比：KV 是 100%，快照是 I/L。32K 上下文下，间隔 1024 时快照的占比是 3.1%，间隔 4096 时是 12.5%（第 3.1 节）。也就是说，存在快内存里的快照，一次命中只用得上其中很小一部分，其余都在白占位置。

再看从慢存储读回来的代价。论文按 Qwen3.5-9B、单卡 H100、PCIe 5.0 的 64 GB/s 和 SSD 的 5 GB/s 估算（图 5b）：

快照放到 SSD，每次命中只多花约 10 毫秒，而且这个数和上下文多长、存了多少个快照都无关。KV 放到 SSD，多花的时间随上下文长度一起涨，128K 时接近 1 秒。所以快内存应该优先留给 KV，快照多存在 SSD 上几乎不影响单次命中的速度。HiState 的放置规则就按这个来：GPU 上只放正在跑的 KV 和状态，CPU 内存优先放可复用的 KV 前缀，历史快照放 SSD；CPU 也放不下时，较冷的 KV 才下到 SSD。

快照存多密？

快照越密，内部命中时要重算的 token 越少，但占的存储越多。HiState 对每段新加进来的上下文单独选一个间隔，把两种代价加起来取最小。复现时要自己确定这些位置的循环状态在 prefill 中怎样截取，比如是否按间隔切分 prefill 的处理批次。

重算代价按“命中点离它前面最近的快照有多远”算，并假设命中落在段内每个位置的概率相同。存储代价是快照个数乘以一个快照的大小，再乘一个压力系数。快照的大小用“相当于多少个 token 的 KV”来折算，这样两种代价能用同一个单位相加。压力系数等于 KV 在缓存里平均能待多久，除以快照在 SSD 上平均能待多久。这两个时长用指数滑动平均在线估计。快照比 KV 先被挤掉，说明 SSD 紧张，系数变大，间隔就放宽。HiState 实际是在系统支持的几档间隔里取让总代价最小的一档；在均匀假设下，连续近似的解能看出趋势：
$$I^{\ast }=\sqrt{2L{N}_s\frac{T_{\mathrm{KV}}}{T_{\mathrm{state}}}}$$
$L$ 是这段新上下文的长度，$N_s$ 是一个快照折合多少个 token 的存储，$T_{\mathrm{KV}}$ 和 $T_{\mathrm{state}}$ 是 KV 和快照的平均驻留时间。直觉是：段越长、SSD 越紧，快照就越稀。举个能心算的例子（示意）：一段 8000 个 token，一个快照折合 100 个 token，两种驻留时间相等，根号里是 2×8000×100，连续解约 1265 个 token；SSD 变紧、系数变成 4，连续解翻倍到约 2530。HiState 会在支持的档位里选最接近最优的一档。不管选多少，这段的结尾快照都会存，保证下一轮追加能直接接上。

空间不够时先删谁？

淘汰要同时照顾两件事：同一个会话里，以后可能退回去用的历史快照要留住；不同会话之间，不能让一个早就不活跃的会话一直占着空间。

HiState 先划定能淘汰的单位。中间快照可以单独删，删了 KV 还在，命中时退到更早的、仍保留着的快照接着重算；如果相邻快照也被删了，这段可能很长，所以重算量要放进打分。每个会话最后一个中间快照之后、到结尾为止的那段 KV，和结尾快照绑成一个单位，因为要从结尾接着往下算，两样缺一不可。按论文的说法，回收一个冷会话时，删掉的是它没有被别的会话共享的 KV 和剩下的状态；删掉结尾单位后剩下的前缀如何再划分单位，论文没有展开。所有会话的中间快照和这些结尾单位放在一起排序，分数是
$$H_x=t_x+\tau \frac{C_x}{M_x}$$
$t_x$ 是上次访问时间，$C_x$ 是删掉它之后预计多出的重算 token 数，$M_x$ 是删掉它能从当前空间不够的那一层（比如 CPU 内存或 SSD）实际腾出的空间，只在别的层上占空间的对象腾不出位置，$\tau$ 调节“新旧”和“删了亏多少”谁更重要，分数最低的先删。$C_x$ 按命中位置的概率加权求期望：各会话等概率，结尾被访问的概率用指数滑动平均估计，剩下的概率均匀分给段内各位置。命中某个快照时，同一前缀上它前面的所有快照也一起刷新访问时间，这样活跃会话的历史快照不会因为“很久没被直接读”而被挤掉。这一步和单纯的 LRU 加全部刷新相同，区别在成本项 $C_x/M_x$：它让彼此挨得很近、删掉后只需少量重算的中间快照得分低，更容易被删。最终先删谁仍由访问时间、重算代价和腾出的空间一起决定，一个久不活跃的会话的结尾单位也可能分数最低、被整体回收。

论文图 7 是一个具体例子：B 会话有 S1、S2 两个历史快照和结尾快照 S3，S1 前面是一长段前缀，S1 和 S2 之间只隔一小段；C 会话只有结尾快照 S6。现在要删一个。

LRU 删 S1，因为它最久没被访问，B 以后退回 S1 就要重算那段长前缀。LRU 加全部刷新保住了 B 的历史快照，却把 C 正在等着用的 S6 挤掉。HiState 删 S2，因为从 S1 重建它只要算很短一段。这样 S1 和 S6 都留了下来。

实验：尾延迟降了多少？

先定义一个后面要用的概念。复用敏感请求是满足两个条件之一的请求：在 vLLM 的磁盘卸载版（下表的对比基线）下，命中率比无限缓存（不淘汰、每个位置都存快照的理想参照）低至少 5 个百分点；或者 HiState 和 vLLM 的磁盘卸载版之间命中率差至少 5 个百分点。这类请求是缓存策略真正起作用的地方。

实验在单卡 H100 上跑 Qwen3.5-9B，GPU 缓存池约 45 GiB，另给 96 GiB CPU 内存和 150 GiB 磁盘。负载来自两份真实编程 agent 的公开记录：Weka（Claude Code 会话，125 个会话、3,784 个请求）和 TraceLab 的 Codex 子集（68 个会话、4,791 个请求），同时最多 24 个会话在跑，各回放约三小时。对比的系统有：vLLM 加 Marconi 的每轮结尾存快照策略（只用 GPU）、作者在 vLLM 上补的 CPU 卸载版和 CPU 加磁盘卸载版（都用 LRU），以及 SGLang 的 HiCache。命中率只算真正没重算的 token：KV 匹配上但快照要重算，不算命中。

这些数字说明了两件事，另有一点要注意。第一，光有卸载就能把尾延迟降下来很多，但 HiState 比同样能卸载到磁盘的 vLLM 版本还快，说明容量只是一部分，留对快照同样重要。第二，HiCache 虽然也用磁盘，p95 和 p99 却比只卸载到 CPU 的 vLLM 版本还差。论文的解释是它默认把 GPU 缓存对半分给 KV 和状态，状态那一半不能拿来缓解 KV 的压力，KV 在被复用前就被挤掉了。要注意的是，平均 TTFT 是在复用敏感请求这个子集上算的，不是全部请求；在全部请求上，p50 和磁盘卸载版大体持平，Weka 上略差。

消融在 TraceLab 的 46 个复用敏感请求上做（图 10）。把淘汰换回按文件的 LRU，平均 TTFT 涨 37%，损失最大；把间隔控制换成另外两种存快照的方式，平均 TTFT 涨约 9% 到 10%：一种是 vLLM 的对齐策略，只在调度步结束、且正好落在缓存块边界的位置存快照；一种是固定每 32 个缓存块存一个（实验里 GPU 缓存池的一个块是 576 个 token），两种都保留结尾快照。这说明淘汰策略贡献最大，间隔控制决定能从哪里接着算，两者都要。

合成实验专门测“回头改上下文”越频繁时，存中间快照的价值有多大：每个会话跑 16 轮，每轮新输入 8K token，改动请求的比例分四档，最高 10%。和 vLLM 的磁盘卸载版相比，HiState 让改动请求的平均 TTFT 降 18% 到 21%，因为它在改动点附近留着快照；上一轮结尾的快照晚于改动点、含着被改掉的内容，不能用，基线只能退到改动点之前更早的有效快照去重算。

我认为它的局限

第一，环境很窄。只测了 Qwen3.5-9B 一个模型、一张 H100，没有多卡并行，也没有和 prefill-decode 分离这类部署方式组合。循环层占比不同的其他混合模型上，快照和 KV 的大小比例会变，SSD 上的收益要重新算。

第二，收益集中在尾部。p50 和磁盘卸载版基本一样，Weka 上还略差；Weka 上 p99 相对磁盘卸载版的额外提升，论文自己也说比 TraceLab 小。改动请求的平均 TTFT 只降 18% 到 21%，不是数量级的变化。

第三，访问概率靠简单假设。重算代价假设命中在段内均匀分布，跨会话也假设等概率。真实 agent 的截断常常发生在固定位置（比如工具输出的中间），按这种规律存快照可能比均匀假设更省，论文没有测这个方向。空闲很久后才回来的会话，HiState 照样未命中，在复用敏感请求上只能找回无限缓存约 85% 到 87% 的可复用 token。

一个搜索/推荐团队可以怎么试

搜索和推荐里的 agent（比如多轮检索助手、对话推荐）同样会回头改上下文。服务端用混合模型的团队，可以这样试：

1. 先量一下问题有多大：在自己的请求日志里统计 KV 能匹配上、但匹配点不在任何一轮结尾的请求占多少，以及这些请求的 TTFT。占比很低就不必动。
2. 先做最便宜的一步：把历史快照写到 SSD，KV 优先留在 CPU 内存，结尾快照照常放快内存，看 p95 和 p99 TTFT 的变化。
3. 再换淘汰策略：消融里淘汰贡献最大，可以先只把 LRU 换成“访问时间加上重算代价除以空间”的打分，再决定要不要做自适应间隔。
4. 一直盯着 p50：确认尾部的收益没有用常见请求的延迟去换。

结论与评价

最关键的启发是：混合模型的前缀缓存要把 KV 和快照放在不同层的存储上，因为一次命中读全部 KV 却只读一个快照；淘汰时再把两者放进同一个队列，按重算代价统一排序。