检索文档不再卡在固定前缀：同一份文档换系统提示也能复用KV缓存，命中率从3.3%升到63.9%
核心概要
KV-Repurpose把大模型推理中的KV缓存复用从“必须前缀完全相同”改成按段独立判断，同一份检索文档即使前面换了系统提示、对话历史或时间戳，也能复用已算好的缓存。在30 GB缓存容量下，Zipf式RAG负载的token级命中率从前缀缓存的3.3%升到63.9%，首token延迟随之下降；单文档问答与摘要质量基本保持，跨文档推理则明显退化。
深度剖析
大模型推理服务里的KV缓存复用不再要求整段前缀逐字相同，而是按分隔符切出的段各自判断能否复用，一段未命中不影响后面段落命中。 此前的服务引擎主要只优化精确前缀匹配，同一份检索文档出现在不同系统提示、对话历史或动态元数据之后时，缓存无法复用，只能重新做prefill。 在2500条按Zipf分布抽样的LongBench Pro T5.1请求上，20%请求共享固定前缀时，30 GB容量下KV-Repurpose的token级命中率为63.9%，前缀缓存为3.3%；前缀缓存即便把容量加到1 TB也只到17.9%。
实现方式是在vLLM上做段级缓存感知调度，并只对复用的键做位置校正，不重算与前面前缀的注意力。 缓存中的键以未旋转形式保存，复用时按当前位置重新施加RoPE，把缓存键对齐到新位置；这只是一次轻量位置调整，而非重新计算注意力。 系统在vLLM v0.20.0上以不到900行Python扩展实现，模型为超过1000亿参数的GPT-OSS-120B，单张NVIDIA H200 GPU，KV缓存存放在NVMe SSD上，对比基线用LMCache作KV连接器。
复用带来的质量代价按任务类型分化：单文档问答和摘要基本保持，跨文档推理明显下降。 以LMCache前缀缓存作为无法复用、必须重算的质量参照，重算在QASPER单文档问答上token级F1为0.42，复用同为0.42；多文档的2WikiMultihopQA从0.80降到0.50，MuSiQue从0.61降到0.40。 LongBench Pro的25个任务上，复用与重算的平均分分别为0.43和0.45；把多文档输入限制为相关文档后性能部分回升但差距仍在，所有分数为三次运行平均。
启示与展望
这套测试床面向长上下文RAG式服务场景，在单张H200、GPT-OSS-120B、KV缓存放在NVMe SSD的配置下验证，负载为8K到128K token的英文文档。它给出的是朴素段级复用的基线，作者明确表示不把它当作最先进方法，也未与更复杂的PIC技术做直接比较或组合。
跨文档推理上的退化在把输入限制为相关文档后只是部分回升，差距仍在，作者不把回升归因于文档数量减少或无关内容移除中的任一因素。实验只用一个模型，结果未必推广到其他架构、规模或训练设置；大规模部署下的存储效率评估留作后续工作。作者还报告，若用含用户信息的提示生成可复用缓存，100个姓名中有35个在复用后被复现，因此文档缓存改为仅由文档本身生成。