一个被算法细节锁死的工程问题
LLM 推理服务里最没有争议的优化是什么？前缀缓存（prefix caching）：如果两个请求共享系统提示词，第二次就不用重算这部分，直接复用 KV 状态。vLLM 等主流引擎都内置了它， savings 实打实。
但它的命中条件苛刻到反直觉：从第一个 token 开始逐字一致。RAG 系统恰好是命中条件的最大破坏者——同一份文档今天在系统提示词之后、明天在对话历史之后；同一批检索结果因为动态元数据（时间戳、会话 ID、用户偏好注入）被推到不同位置。文档明明是同一份，KV 状态明明是同一个，却因为「位置不齐」而全部重算。
来自日本存储厂商 Kioxia 的三位作者（Taiga Ikeda、Daisuke Miyashita、Jun Deguchi）把这个问题做成了一个开源测试床：KV-Repurpose，10 月 9 日提交 arXiv（2610.13060），基于 vLLM 实现，Apache-2.0 协议，代码在 github.com/taiga333/eval-kv-repurpose。它的核心主张是：前缀复用只是 KV 缓存复用的一个特例，分段（segment-wise）复用才配得上 RAG 负载的真实形态。
系统拆解：五个组件，缺一不可
KV-Repurpose 不只是一个「按段查缓存」的技巧，而是一个端到端评测系统，五个组件环环相扣：
缓存感知的段调度：把提示词按文档边界切段，每段的 KV 状态独立存取，新请求按段匹配复用。这是与 vLLM 现有前缀树（Radix Attention 风格）的根本区别——匹配单位从「前缀树路径」变成「内容段」。
预热机制：论文里最容易被忽略但最关键的设计——通过一条前缀不含任何用户特定内容的专用请求来生成共享文档的缓存。如果直接等用户请求触发缓存，第一个命中的用户会把私有上下文封装进共享段，产生数据泄漏。附录 A.2 给出了这个泄漏行为的实证例子。
容量管理与淘汰：30GB 的固定缓存预算下，哪些段的 KV 状态值得保留、哪些被淘汰，直接决定命中率。
负载生成器：这是论文说服力的来源——它不是拿一个人工构造的「理想复用场景」自证，而是生成了 Zipfian 分布的 RAG 负载：20% 的请求共享固定内容，但共享内容出现在不同位置。这贴近真实检索流量的形态（热门文档天然聚拢流量）。
运行时监控：token 级命中率、TTFT、质量指标一体化监控，让「复用收益 vs 质量代价」变成可观测的在线权衡。
核心数字：20 倍命中率差距，和它背后的容量经济学
主实验设定：同一负载、同样 30GB 缓存容量，对比分段复用与前缀缓存。
- 分段复用：63.9% token 级命中率
- 前缀缓存：3.3%
- 把前缀缓存的容量放大到 1TB：也只有 17.9%
这三行数字值得多看一眼。前缀缓存的失败不是容量不足，而是结构性失效——位置不对齐的内容永远进不了命中窗口，买多少内存都没用。分段复用 30GB 就打出了前缀缓存 1TB 还高 3.5 倍的命中率。对推理服务来说，命中率的差异直接落进 TTFT 与 GPU 时间：命中段免重算，未命中段才进预填充。
命中率之外，论文还在 100B 参数级模型上验证了延迟收益，并明确表示这类收益「在缓存容量受限的多级存储体系（含专用上下文内存系统）中会进一步放大」——考虑到 Kioxia 的存储厂商背景，这个研究视角显然不是偶然：当 KV 缓存从 GPU 显存溢出到 SSD 与专用存储层，复用率就变成了存储系统的核心指标。
质量代价：一张表看懂「哪里能省、哪里不能省」
论文最诚实的部分是 LongBench Pro 上的质量对照（Recompute 为全量重算基线，Repurp 为分段复用）：
| 任务 | 数据集 | Recompute | Repurp | 损失 |
|---|---|---|---|---|
| 单文档 QA (F1) | QASPER | 0.42 | 0.42 | 无 |
| 多跳 QA (F1) | HQA | 0.71 | 0.60 | 明显 |
| 多跳 QA (F1) | 2WMQA | 0.80 | 0.50 | 严重 |
| 多跳 QA (F1) | MuSiQue | 0.61 | 0.40 | 严重 |
| 摘要 (ROUGE-L) | QMSum | 0.20 | 0.19 | 无 |
| 摘要 (ROUGE-L) | GovRepo | 0.26 | 0.26 | 无 |
| 摘要 (ROUGE-L) | M-News | 0.22 | 0.17 | 轻微 |
规律清晰到可以写成一条运维守则：输出主要依赖局部文档的任务（单文档 QA、通用摘要）可以放心复用；需要跨文档拼合证据的任务（多跳问答）会显著受损。论文用附录 A.2 的「跨段信息泄漏」实证解释了机理：分段复用改变了段与段之间的注意力交互条件——多跳问题恰恰最依赖这种交互。诊断实验把输入过滤到只剩相关文档，性能部分恢复但差距仍在，说明这不是噪声而是结构性损失。
工程视角：谁该关注、怎么落地
推理服务团队：如果你的流量画像接近「少量热门文档、大量重复检索」（企业知识库、客服 FAQ、代码文档问答都是典型），这个方向值得认真评估。第一步不是改 vLLM，而是用 KV-Repurpose 的负载生成器跑你自己的请求日志，量化「位置错位的重复内容」占比——论文的 20% 共享率是模拟值，你的真实值决定一切。
与现有生态的关系：论文引用了 LMCache 的 issue #3238（前缀缓存引擎尚未支持此类复用）与 TurboRAG（预计算分块 KV 的 RAG 加速）等工作，定位是给社区一个统一的评估基线。也就是说，各家引擎的「超越前缀复用」实现迟早会来，而 KV-Repurpose 提供的是评测它们的标准场地。
质量护栏：落地时建议按请求类型路由——摘要类、单文档类请求走复用路径，多跳推理类请求强制重算。与其追求全局命中率，不如把复用限制在质量无损的请求子集上；论文的表格已经替你把边界画好了。
结语
KV-Repurpose 的价值不在提出了一个惊人技巧——「按段复用」的直觉人人都有——而在于它把直觉放进了完整的系统里实测，给出了两个同样重要的数字：63.9% 对 3.3% 的收益上限，和 MuSiQue 从 0.61 掉到 0.40 的代价下限。RAG 推理优化的下一步竞争，很可能就从这两个数字之间展开。
论文信息：KV-Repurpose: A Testbed for Evaluating Non-Prefix KV-Cache Reuse，Taiga Ikeda, Daisuke Miyashita, Jun Deguchi（Kioxia Corporation），arXiv 2610.13060，2026 年 10 月 9 日提交，代码 Apache-2.0 开源。