同一段长提示再次到来，服务可以省去重算，却未必能马上开始生成。缓存还在不在？请求该发给哪台机器？如果 KV 只在 SSD 上，首个 token 还得等它读回 GPU。
KVTether：闲置的上下文先别删
一次工具调用尚未返回，旧消息暂时用不到；任务一旦删除这段消息，对应的 KV 就可以回收。普通的最近最少使用策略看不出这两种状态的区别。
KVTether 让 Agent 显式报告消息状态。只有这些信号及时、准确，服务才知道该给谁留出缓存。
KVCompass：把请求发给持有缓存的节点
各节点上报缓存的新增和淘汰。入口先查谁持有匹配前缀，再把排队、网络和剩余计算的成本算进路由选择。
跨区转发的是请求，不是整块 KV。索引过时或持有者队列太长时，命中最多的节点未必最快。
FlatCake：把同一会话要读的 KV 放在一起
FlatCake 在创建 KV 时就选择内存或 SSD，把同一会话的缓存按层连续放置；读回时合并小请求，直接送入 GPU。
看首个 token 的等待时间时，要同时看缓存命中率和实际读盘开销。论文的对比使用 B200 和高复用负载。
KVStream：先读完的存储层接着领下一块
同一缓存块在本地 NVMe 和并行文件系统各有一份。两个读取端共享待办队列，谁先读完，谁就领取下一个未读块。
这里用额外写入换取并行读回；如果前缀很少复用，或内存本来就装得下，复制成本可能反而拖慢推理。