导语：AI 的“草稿纸”不够用了
你让 AI 读一份很长的合同、一次很长的聊天记录，或者一段推理题解，再让它接着回答。表面上看，这是模型够不够聪明的问题。可到了服务端，问题常常更像是：桌面太小，草稿纸太多，哪些纸该留，哪些纸能扔，谁先用桌子。
这里的“草稿纸”就是 KV Cache——模型处理过上下文后留下的中间记忆，能让后续生成不用反复重算。上下文越长，这份记忆越大，显存和带宽压力也越高。最近同时出现的三项工作，把同一个趋势讲得很清楚：KV Cache 已经不只是一个局部优化点，而是在变成 LLM serving（大模型在线服务）里的核心资源。
这三项工作分别从三个角度切入：KVpop 研究怎么预测哪些缓存未来还会有用；PEEK 研究怎么根据排队请求来安排缓存复用；一篇 survey 则把三十多个 KV cache management 系统放进同一张地图里。需要先说明：具体性能数字主要来自各论文自测，尤其 KVpop 和 PEEK 都还缺少独立复现实验。
先别急着算，先决定留什么
KVpop 的问题很直观：缓存剪枝 eviction/pruning，就是在空间不够时决定哪些旧记忆可以丢掉。像整理书桌，不能把所有资料都摊着，只能留下最可能再用的。难点在于，当前看起来不重要的内容，未来可能突然变关键。
很多旧方法会看“最近有没有用过”，或者保留开头的一小段和最近的一小段。KVpop 换了一个角度：不要只看现在有多重要，而是训练一个小模块去预测“未来会不会被注意到”。论文把这件事叫 predictive online pruning，也就是在线生成时做预测式剪枝。
具体说，KVpop 给每个 KV head（可以粗略理解为模型里一组独立的注意力读写通道）设一个固定预算。它总是保留少量 sink tokens（常被模型长期依赖的开头 token）、一个 protected window（最近一段暂时不删的窗口），再从更旧的 token 里挑出一批放进 long-range cache。真正的决策是：一个 token 离开 protected window、第一次面临“留还是删”时，模型用打分器判断它该不该进入长期缓存。
它的关键不在“打分”两个字，而在打分的监督信号。KVpop 用 future-attention target——未来注意力目标——来训练打分器。意思是，在训练时看完整的注意力行为，估计某个旧 token 在离开保护窗口之后，还会不会被后续内容用到。这样，模型学到的不是“刚才谁显眼”，而是“以后谁可能有用”。
论文还提出 delayed scoring，也就是延迟打分。一个 token 刚进入缓存时，证据还少；等它在 protected window 里待了一小段，模型已经看到了一些后续上下文，再决定它是否值得留下。这个设计像是你读完下一两段之后，再回头判断上一句是不是线索，而不是刚看到那句就立刻归档。
在实验上，KVpop 用 Qwen3-4B-Instruct-2507 和 Qwen3-8B 做了稀疏化蒸馏，并在 AIME、HMMT 这类数学推理任务上评估。按论文原文，KVpop 在 Qwen3-4B 上，75% KV cache compression 时保留 95% 的 dense-attention teacher 表现，88% compression 时保留 94%。在 Qwen3-8B 上，对应保留 95% 和 99%。这里的 teacher 指完整注意力模型，也就是不做这类缓存压缩的参照版本。
论文还报告了一个服务端更关心的结果：在 batch size 1、最长生成到 131k tokens 的自回归解码测试里，dense attention 的峰值显存从 16k tokens 时的 18GB 增到 131k tokens 时的 36GB；DMS 和 KVpop 只增长 19%，到 19GB。这个数字说明的不是“模型突然更聪明”，而是缓存增长被压住了。
队列里也藏着缓存答案
KVpop 关心单个请求内部该留什么。PEEK 看的是另一个层面：很多请求其实有相同开头。
比如一批用户都在同一个系统提示下提问，或者都让模型读同一篇文档的不同问题。前缀共享 prefix sharing，就是让这些相同开头复用已经算好的缓存，从而省内存、省时间。问题在于，在线服务里请求是排队来的，如果调度器没看见这种共享关系，就可能把能互相复用的请求拆散处理。
PEEK 是一个面向 LLM serving 的轻量级 scheduling and eviction framework，也就是调度和缓存淘汰框架。它覆盖 online streaming 和 offline batch，但论文重点放在 online regime，也就是请求不断到来、系统边服务边排队的场景。
它的做法是，在 pending queue（等待队列）上维护一棵 incremental radix tree。radix tree 可以理解为把很多字符串的共同开头折叠到一起的树。PEEK 用它找出队列里哪些请求共享前缀，再和引擎内部已有的 prefix cache 做 dual-walk 匹配，给每个等待请求找最长可复用前缀。
找到共享关系后，PEEK 会让 cluster pioneers 先进入执行。也就是让一组共享前缀请求里的“开路请求”先跑，把前缀缓存算出来；后面的 sibling requests 再继承这份刚热起来的缓存。它还设计了 eviction hook，保护那些被排队请求祖先路径依赖的缓存块，并用 multi-lane stride scheduler 限制饥饿问题，避免某些请求一直等不到。
论文在 SGLang 和 vLLM 两个引擎上、五个 workload、最高 4×H100（DP=2 over TP=2）设置下评测。作者报告，相比各自 stock baseline，PEEK 在 SGLang/vLLM 上分别带来最高 3.0×/2.6× cache hit、7.9×/7.1× TTFT、6.7×/5.5× E2E、3.6×/4.5× throughput gains。
这些都是“最高”数字，不等于所有场景平均提升。PEEK 的优势也依赖 workload 里确实有可利用的 prefix structure。材料本身说明，在没有可利用前缀结构的 workload 上，PEEK 与 baseline 的表现处于噪声范围内。换句话说，它不是魔法加速器，而是把“相同开头别重复算”这件事做进了队列调度。
Survey 把问题从技巧抬到系统层
第三篇 survey 的价值在于给这条线定了坐标。它说，KV cache 已经从 temporary per-request tensor（单个请求里的临时张量）变成 first-order memory object（一等内存对象）。这句话很系统论文，但意思不复杂：过去它像函数运行时产生的临时变量，现在它更像数据库缓存、内存池、分布式存储层，需要被长期管理、共享、隔离和调度。
这篇 survey 把三十多个 KV-management systems/frameworks 按四个轴分类：locality（缓存在哪里）、lifetime（活多久）、ownership（归谁管）、substrate（落在哪种底层资源上）。再归纳出五类架构：local-paged、disaggregated-pipeline、shared-store、memory-pool、hybrid-tier。
这些分类听起来抽象，但它们回答的是同一个工程问题：当很多用户、很多 GPU、很多长上下文请求同时出现时，KV Cache 到底是每个请求自己管，还是系统统一管；是只在本地 GPU 上分页，还是跨设备、跨层级流动；是短暂用完即丢，还是成为可共享的服务资产。
survey 还指出，当前评测缺少七项 KV-specific measurements，并把这些缺口和 fault tolerance、isolation、tiered eviction、speculative decoding、MoE serving、shared-cache semantics 等开放问题联系起来。也就是说，下一阶段的争论可能不会只是谁的 attention 更稀疏，而是谁能把缓存当成可靠、可隔离、可分层的系统资源来管理。
为什么值得现在看
这组工作放在一起，信号比单篇论文更强。
第一，长上下文推理的瓶颈正在从“模型能不能读长文”转向“服务端能不能承受这份记忆”。KV Cache 随上下文长度线性增长，长文档、长对话、长代码库都会把压力推到显存和带宽上。
第二，缓存治理开始分层。KVpop 处理 token 级别的保留决策，PEEK 处理请求队列级别的复用顺序，survey 则把它们放进更大的内存层级和系统架构里。一个管“哪些字值得留”，一个管“哪些请求该先来”，一个管“整套缓存系统该怎么分类和评测”。
第三，这些方法都在承认同一件事：缓存不是被动副产品。它会影响延迟、吞吐、成本，也会反过来影响模型在长推理里的表现。未来长上下文模型的竞争，可能不只看模型窗口标到多长，还要看系统能不能聪明地使用这扇窗口。
局限与未知
-
KVpop 的核心效果来自作者论文，任务主要集中在 AIME/HMMT，模型限定为 Qwen3-4B 和 Qwen3-8B；跨更多模型和任务的稳定性还需要更多验证。
-
PEEK 的提升是相对 SGLang/vLLM stock baseline 的 up to 峰值结果，并且依赖请求中存在可利用的 prefix-sharing structure。
-
survey 支撑的是趋势和分类框架，不验证 KVpop 或 PEEK 的具体实验数字。