第4章：KV Cache 跨层级管理论文精读

KV Cache 是长记忆系统的”主战场”——四类数据里它访问最频繁、失效代价最高、研究最密集。过去两年(2023-2025)集中爆发了 5+ 个有代表性的跨层级 KV 管理方案,各自切入了”放置 / 复用 / 压缩 / 调度 / 选择”这条武器链上的不同环节。本章把这五个方案放在同一张对比表里精读:AttentionStore(三级缓存 + 多轮会话)、LMCache(跨实例池 + 跨层级)、InfiniGen(重要 token 预测式加载)、CacheGen(KV 张量编码压缩)、Pensieve(亲和路由 + 跨会话调度)。读完这章你能回答两个问题:他们各自在什么场景下最优?把它们组合成”统一长记忆系统”还差哪些拼图? 这正是后续 Ch8 统一表示的研究入口。

📑 目录

• 1. KV Cache 为什么是主战场
• 2. 五大方案速查表
• 3. AttentionStore:三级缓存 + 多轮会话复用
• 4. LMCache:跨实例 / 跨层级池
• 5. InfiniGen:重要 token 预测式加载
• 6. CacheGen:KV 张量编码压缩
• 7. Pensieve:亲和路由 + 跨会话调度
• 8. Mooncake:集群级 KV 中心化(简述)
• 9. 横向能力矩阵
• 10. 给本项目的整合启示:还差哪些拼图
• 自我检验清单
• 参考资料

---

1. KV Cache 为什么是主战场

第 2 章已经从访问指纹分析了 KV 的特殊性,这里再总结成 3 条”为什么集中精力研究它”:

🌟 第一:失效代价不对称且极高——一次 KV miss 等于整段 prefill 重做,代价是数百毫秒到数秒。其它三类数据 miss 时一般只是从下一级搬数据(代价 ms 量级)。

🌟 第二:复用红利极大——跨用户共享 system prompt、跨轮共享对话历史、跨实例共享 RAG 文档前缀,这三类红利合起来通常占长记忆系统总收益的一半以上。

🌟 第三:算法侧有”语义压缩”空间——LLM 对小扰动鲁棒,可以做 KV 量化、token 选择、张量编码,这给 KV 管理提供了远比传统数据库更大的设计空间。

⭕ 设计含义:本章五个方案各自挖了上面三条红利中的一条。把它们组合起来,是项目第一模块的”统一抽象”必经之路。

---

2. 五大方案速查表

方案	出处	切入点	一句话价值
AttentionStore	USENIX ATC 2024	三级存储 + 会话级	把 KV 当冷热数据做 HBM-DDR-SSD 三级缓存
LMCache	UChicago + 开源	跨实例 + 跨层级	KV 从私有内存变集群共享池
InfiniGen	OSDI 2024	重要 token 选择	”全量留 CPU,按预测拉关键 token”
CacheGen	SIGCOMM 2024	KV 张量编码压缩	跨网络 / SSD 传输时的有损压缩 + 流式
Pensieve	OSDI 2024 / EuroSys’25	调度感知亲和	把”会话该回哪个 GPU”做进调度器
(Mooncake)	Moonshot 2024	集群级中心化	大规模 PD 分离 + KV 池(已在模块四/十三)

🍎 直觉对照:把 KV 比作”图书馆藏书”——AttentionStore 做的是多级书架;LMCache 做的是跨分馆借阅;InfiniGen 做的是只把要看的几页搬上桌;CacheGen 做的是借书前先压缩成微缩胶卷;Pensieve 做的是让你每次回到熟悉的那个分馆。五个方案各管一段,合起来才是完整的”图书馆”。

---

3. AttentionStore:三级缓存 + 多轮会话复用

3.1 一句话精髓

把 KV cache 当成”会话级冷热数据”做三级存储(HBM-DRAM-SSD),让多轮对话不再每次重算 prefill。

3.2 解决的问题

聊天场景多轮对话越聊越长,每轮新请求要把整段历史 prefill 一遍——计算量随轮数 O(N²) 增长。已有 prefix cache 只能驻留 HBM,容量极小,踢出后再 miss 就得重算。

3.3 关键设计

维度	内容
存储分级	HBM(active session)→ DRAM(near-active)→ SSD(cold)
入卡时机	用户发起新轮次,根据 session ID 把 KV 预取到 HBM
拆分粒度	layer + token block,layer-wise 流水预取
替换策略	跨会话 LRU + 用户活跃度感知
框架透明	上层(vLLM/TGI)看到的还是”prefix cache 命中”

新轮次请求(session_id)
        │
        ▼
┌────────────────┐
│ Session Mgr    │ → 查 session 在哪一级
└──────┬─────────┘
       │
   ┌───┼───┬───────┐
   ▼   ▼   ▼       ▼
  HBM DRAM SSD  (远端,可选)
   │   │   │
   └─── 预取 / 流水 ───┘
       ▼
   Attention(只 decode 新 token)

3.4 局限

• 只针对对话场景——长记忆 Agent / RAG / 多模态没覆盖
• 假设 session 边界清晰,跨用户 prefix 共享支持弱
• SSD 走 OS page cache + buffered IO,没用 GPUDirect Storage
• KV 三级搬运是整块,没做语义压缩

3.5 给本项目的启示

🌟 直接竞品——第一模块”跨层级 KV 管理”的最强基线,论文必须做精确对比。差异化空间:

1. 多类型扩展:AttentionStore 只管 KV,我们把向量索引 / 多模态 blob 一起纳入
2. 跨用户 prefix:用 LMCache 思路补这块短板
3. GPUDirect Storage 直通:绕开 CPU bounce buffer
4. token 单位成本建模:AttentionStore 用启发式 LRU,我们升级成模型驱动放置

---

4. LMCache:跨实例 / 跨层级池

4.1 一句话精髓

把 KV 从”单引擎单实例”的私有内存,变成”集群共享、跨层级、可复用”的资源池——任何一台机器算过的 KV,其它机器复用。

4.2 解决的问题

vLLM / TGI 的 prefix cache 只在单实例 HBM生效。生产场景下:

1. 同一 system prompt(数千 token)被几十个推理实例反复算
2. RAG 文档块在多查询里重复出现
3. 同一用户被 LB 切到不同实例,KV 全丢

LMCache 把 KV 抽成”块”,跨实例、跨层级共享。

4.3 关键设计

设计	内容
KV 块寻址	用 token hash(或语义 hash)作 key,块大小可调
多级后端	HBM(本卡)→ DRAM(本机)→ 远端 → SSD
压缩集成	与 CacheGen 集成,跨网络/SSD 时编码
引擎适配	通过 hook 接进 vLLM / SGLang / TGI
命名空间	不同模型 / tokenizer 用 namespace 区分

┌──────┐  ┌──────┐  ┌──────┐
│vLLM#1│  │vLLM#2│  │vLLM#3│
└──┬───┘  └──┬───┘  └──┬───┘
   │         │         │
   └─────────┼─────────┘
             ▼
   ┌──────────────────┐
   │ LMCache Connector│
   └────────┬─────────┘
            │
   ┌────────┼────────┬────────┐
   ▼        ▼        ▼        ▼
 Local   Remote    SSD     (压缩 / 解码层)
 DRAM    KV pool   (cold)

4.4 关键收益(公开 benchmark)

• 长 system prompt + RAG 场景,首 token 延迟降低数倍
• 同一份 RAG 文档跨多查询的 KV 复用命中率经常 > 80%
• 跨实例池化避免并发突增时的”prefill 雪崩”

4.5 局限

• 主要针对 prefix 类复用,对话历史 / Agent 长记忆复用率没那么高
• 跨实例传输需要 RDMA / 快网,普通以太网下 P99 抖动大
• 块粒度对压缩 / 命中率是个 trade-off,没有自动调参

4.6 给本项目的启示

🌟 第一模块”统一抽象”的现成原型——LMCache 已经把 KV 抽成”块 + key + 多后端”。我们要做的增量:

1. 块扩到多类型:KV 块 + 向量索引片段 + 多模态对象,共用一套 key/backend 抽象
2. 语义级 key:不只是 token hash,加入 embedding 相似度去重
3. 跨层级一致性:LMCache 没解决”远端缓存被更新本地怎么知道”——长记忆 Agent 必须考虑
4. token 成本反馈调度:把”块该放哪一级”写成在线优化,不是固定 LRU

---

5. InfiniGen:重要 token 预测式加载

5.1 一句话精髓

不是把所有 KV 都存,而是在线预测”哪些 token 这一步用得上”,只把那些拉回 HBM——把容量瓶颈转化为选择问题。

5.2 解决的问题

长上下文 KV 太大装不下;直接卸载 CPU 延迟高;启发式淘汰(H2O / StreamingLLM)信息损失累积。InfiniGen 的视角:Attention 本质上每步只看少数关键 token,做”按需精确加载”。

5.3 关键设计

layer 1 ── attention ── 用 score 预测 layer 2 的 top-k
                            │
                            ▼
                     从 CPU 拉 top-k KV → HBM
                            │
layer 2 ── attention(只用拉回的)── 预测 layer 3
                            │
                            ▼
                          ……

维度	内容
KV 全量驻留	全部留 CPU 内存,HBM 只装 active 片段
轻量预测器	用前几层 attention 分数预测后几层 top-k 重要 token
按需加载	只把预测的 top-k 从 CPU 拉回 HBM
流水重叠	加载 layer N+1 与计算 layer N 并行

🧠 关键洞察:Attention 分数在层间有相关性——前几层重要的 token 在后几层往往也重要。这给了 speculative load 的可行基础。

5.4 关键收益

• 相比全量卸载基线,端到端推理速度数倍提升
• 长上下文 benchmark 上,精度退化可忽略(预测准了)
• 可服务最大上下文长度显著拉长

5.5 局限

• 预测器训练需校准数据,未见过领域可能 miss
• top-k 错了就 stall(回退全量找)
• 仅推理,不考虑 SSD 持久化层
• 多用户并发,各 session “重要 token”集合不同——预测器需 per-session 维护

5.6 给本项目的启示

🌟 核心方法论价值:把”哪些数据放哪一级”从启发式 LRU 升级到模型驱动的预测式选择。可扩展:

1. 多类型 importance 预测:KV / 向量 / RAG chunk 各有自己的 importance signal,统一抽成”下一步访问概率”
2. 三级化预测:不只是”加载到 HBM”,还要预测”卸到 DRAM 还是 SSD”
3. 预测器 + 成本模型耦合:重要程度 × 当前层级带宽 → 是否值得搬运

---

6. CacheGen:KV 张量编码压缩

6.1 一句话精髓

把 KV cache 当成”张量数据流”,做有损 + 渐进式编码——既减少传输体积,又能边收边用。

6.2 解决的问题

KV 跨节点传输时网络成了新瓶颈:32K context KV 几个 GB,直传 P99 延迟数秒。跨实例 KV 复用、KV pool 远端拉取、容灾重建都撞这堵墙。传统 LLM 量化(KIVI / AWQ)关注计算/存储,不关注传输路径。

6.3 关键设计

设计	内容
张量统计建模	利用 KV 张量数值分布(layer/channel)做差异化编码
可调有损	压缩比可调,精度损失可控,按下游容忍度选档
渐进式流式	先传”低保真版本”足够开始 decode,后传”补丁”提升精度
网络自适应	根据当前带宽决定压缩比

Source GPU
    │ KV tensor
    ▼
┌──────────────┐
│ Encoder(分级)│ ← layer/channel 统计 → 选码本
└──────┬───────┘
       │ encoded stream
       ▼
   ── 网络 ──
       │
┌──────▼───────┐
│ Decoder      │ → 部分解码即可开始 decode
└──────┬───────┘
       ▼
Target GPU

🧠 关键洞察:KV cache 不需要 bit-perfect —— attention 对小扰动鲁棒,有压缩空间。同时它有强结构(layer / head / channel),不是普通张量。

6.4 关键收益

• 相比 fp16 直传,网络体积降低数倍至一个数量级
• 加载延迟显著加快
• 调档下精度退化接近无损

6.5 局限

• 压缩 / 解压本身耗 GPU/CPU,端到端收益取决于网络瓶颈
• 编码方案是 KV 专用,不能直接套向量索引或多模态对象
• 跨模型迁移码本要重新校准
• 不考虑 SSD 持久化层的存储压缩

6.6 给本项目的启示

🌟 多类型数据通用编码层是空白——CacheGen 给了 KV 答案,我们扩展:

1. 统一编码框架:把 CacheGen 的”网络/存储自适应有损编码”思想做成通用接口,KV / 向量 / blob 各自注册编码策略
2. 跨层级一致性:同一份数据 HBM 用 fp16,DRAM 用 int8,SSD 用 4-bit + RLE
3. 预算感知调度:网络/带宽预算 + 精度预算 → 联合优化压缩比

---

7. Pensieve:亲和路由 + 跨会话调度

7.1 一句话精髓

多轮对话场景下,把”会话历史”作为一等公民放进调度器,KV 复用从被动 cache 升级到主动调度。

7.2 解决的问题

聊天 / Agent 长会话:同 session 轮次间 KV 高度相关,但不同 session 复用率低,调度器经常把同一 session 切到不同 GPU——KV 全丢。已有 prefix cache 命中后还要把 KV 拷回当前实例,搬运不免费。

Pensieve 视角:调度器应感知会话亲和性,让同 session 尽量回原 GPU,而不是事后补救。

7.3 关键设计

维度	内容
会话亲和路由	维护 session→GPU 映射,新轮次优先回原 GPU
KV 漂移容忍	原 GPU 满了允许”温迁移”——同步 KV 到新 GPU 再开 decode
跨轮 prefix 重排	高复用片段(系统 prompt / 文档)单独打 tag
调度与放置耦合	调度决策直接看 KV 当前所在层级

新轮次请求(session_id)
        │
        ▼
┌──────────────┐
│ Affinity LB  │ → 查 session→{GPU, KV 在哪一级}
└──────┬───────┘
       │
   ┌───┼───┬───────┐
   ▼   ▼   ▼       ▼
 GPU#1 GPU#2 迁移   回退到 prefill
 hit   近旁 (DRAM   (cache miss)
       pool →HBM)

7.4 局限

• 强亲和带来负载不均,极端情况下少数 hot session 拖死某 GPU
• 跨实例迁移本身有开销,小会话场景反而不划算
• 调度器复杂度上升,故障切换容易丢 session 状态

7.5 给本项目的启示

🌟 存储层与调度层的耦合是项目第一模块关键问题——Pensieve 给了具体范例:

1. 多类型亲和:不只是 KV,用户的向量记忆库 / RAG 文档块也亲和(同用户的所有数据放近一点)
2. 会话与层级联动:活跃会话进 HBM,睡眠退 DRAM,长期不活跃退 SSD
3. 温迁移成本模型:迁移收益 vs 重 prefill 代价——这正是项目”token 单位成本”问题的子问题
4. 结合容错:亲和失败时(GPU 故障)怎么和会话状态对接——跨到第三模块

---

8. Mooncake:集群级 KV 中心化(简述)

详见 模块四第6章 PD 解耦架构、模块十三第5章 分离式 KV-Cache 与 PD 分离。

8.1 一句话定位

Mooncake 是Moonshot 内部规模化部署 + 公开技术报告的 KV pool 系统——把上面四个方案的思路在集群级别拼起来:KV pool 中心化 + Prefill/Decode 解耦 + GPU/CPU/SSD 三级 + 调度感知。

8.2 在本项目里的位置

维度	Mooncake 已经做了	本项目要补
跨层级	✅ HBM/DRAM/SSD 三级	+ 远端 RDMA pool 显式建模
跨实例	✅ 中心化 KV 池	+ 多类型(向量 / 多模态)同源管理
调度感知	✅ KVCache-centric scheduling	+ 模型驱动 + 成本目标函数
多类型	❌ 只 KV	⭐ 本项目核心增量
容错	部分	⭐ 第三模块核心增量

⭐ Mooncake 是项目的最强工业基线——精读它的技术报告对申报书”现状 vs 增量”非常有帮助。

---

9. 横向能力矩阵

把六个系统在 8 个维度上做能力对比:

能力	vLLM(基线)	AttentionStore	LMCache	InfiniGen	CacheGen	Pensieve	Mooncake	本项目目标
单卡 KV 分页	✅	✅	✅	✅	✅	✅	✅	✅
HBM-DRAM 卸载	❌	✅	✅	✅	—	部分	✅	✅
HBM-DRAM-SSD 三级	❌	✅	✅	部分	—	—	✅	✅
远端 RDMA pool	❌	❌	✅	❌	✅(网络)	❌	✅	✅
跨实例复用	❌	弱	✅	❌	—	部分	✅	✅
重要 token 选择	❌	❌	❌	✅	❌	❌	❌	✅(借鉴)
张量编码压缩	❌	❌	✅(集成)	❌	✅	❌	部分	✅(扩展到多类型)
会话亲和调度	❌	弱	❌	❌	❌	✅	✅	✅
多类型(向量+多模态)	❌	❌	❌	❌	❌	❌	❌	⭐ 核心增量
token 成本模型	❌	启发式	启发式	❌	❌	❌	部分	⭐ 核心增量

🌟 观察一:没有任何一个系统把所有 8 个能力都做齐——每个方案都是”切一刀深挖”。

🌟 观察二:多类型(向量 + 多模态)和 token 成本模型 这两列全空——这正是项目第一模块的学术增量空间。

🌟 观察三:把 LMCache + AttentionStore + InfiniGen + CacheGen + Pensieve + Mooncake 拼在一起也不等于”统一长记忆系统”——它们都假设”KV 是唯一的长记忆数据”。把这个假设打破,就是项目的真正贡献。

---

10. 给本项目的整合启示:还差哪些拼图

读完五个方案,可以清晰画出”整合视图”还缺哪些:

10.1 已有的强武器(可直接复用)

武器	来源	用在哪
单卡 KV 分页	vLLM PagedAttention	单实例底座
三级缓存框架	AttentionStore	跨层级管理基础
跨实例池抽象	LMCache	集群级共享
张量有损编码	CacheGen	网络 / SSD 传输优化
会话亲和调度	Pensieve	调度器与放置耦合
重要 token 预测	InfiniGen	选择性加载思想
中心化 KV pool	Mooncake	工业级生产经验

10.2 缺的拼图(项目要补)

缺口	内容	难度
⭐⭐⭐ 多类型统一抽象	让 KV / 向量 / 多模态 / scratchpad 共用同一套放置接口	高
⭐⭐⭐ 跨层级一致性协议	远端缓存被更新本地怎么知道(LMCache 没解决)	中
⭐⭐ 模型驱动放置决策	把放置从启发式 LRU 升级到学习式 / 优化式	中
⭐⭐ token 单位成本建模	全栈 TCO 公式 + 在线优化	高(科学问题腹地)
⭐⭐ 多类型通用编码层	CacheGen 思想推广到向量 / 多模态	中
⭐⭐ 跨用户 prefix 共享 + 隐私	系统 prompt 全租户共享 + 用户数据严格隔离	中
⭐ GPUDirect Storage 直通	绕开 CPU bounce buffer	低(工程)
⭐ 故障下的会话亲和退路	Pensieve 没考虑 GPU 故障怎么办	中(跨第三模块)

10.3 整合视图草图

                  ┌──────────────────────────────────┐
                  │   长记忆数据统一抽象(Ch8)        │
                  │   {KV, 向量, 多模态, scratchpad} │
                  └────────────────┬─────────────────┘
                                   │
       ┌───────────────────────────┼───────────────────────────┐
       ▼                           ▼                           ▼
┌─────────────┐            ┌──────────────┐            ┌──────────────┐
│ 放置(Ch9)  │            │ 迁移(Ch10)  │            │ 编码(扩展) │
│ LP/RL/启发式│            │ 冷热演化     │            │ 多类型编码   │
└──────┬──────┘            └──────┬───────┘            └──────┬───────┘
       │                          │                            │
       └──────────────────────────┼────────────────────────────┘
                                  │
                  ┌───────────────▼────────────────┐
                  │ token 单位成本目标函数(Ch11)  │
                  └───────────────┬────────────────┘
                                  │
        ┌─────────────────────────┼──────────────────────────┐
        ▼                         ▼                          ▼
   HBM 三级缓存               跨实例 RDMA pool            SSD 大容量层
   (借鉴 AttentionStore)      (借鉴 LMCache/Mooncake)     (+ GPUDirect)

🌟 关键洞察:整合不是”把五个方案拼起来”,而是先建一个统一抽象,再把这些方案当成具体策略插槽。比如 InfiniGen 的”重要 token 预测”在我们的框架里就是”放置策略 #N”,CacheGen 的”张量编码”就是”压缩策略 #M”——彼此可组合、可替换、可对比。

---

✅ 自我检验清单

• 五大方案速查:能用一句话各概括 AttentionStore / LMCache / InfiniGen / CacheGen / Pensieve 的切入点
• AttentionStore vs vLLM:能说清两者的关系——一个解决单卡分页、一个解决跨层级
• LMCache 块抽象:能讲清”块 + key + 多后端”的好处与对多类型扩展的潜力
• InfiniGen 反直觉:能解释”全量留 CPU 反而更快”的物理逻辑
• CacheGen 两个用途:能列举它在网络传输 vs 跨层存储上各自的价值
• Pensieve 调度耦合:能讲清”调度看 KV 在哪”为什么比”事后再搬”高效
• Mooncake 定位:能描述它是上面几个方案在集群级的”工业整合版”
• 能力矩阵:能默写”多类型 + token 成本模型”两列全空的事实
• 缺的 8 个拼图:能复述至少 5 个,并各举一句话说明为什么本项目要补
• 整合视图:能画出”统一抽象 → 放置/迁移/编码 → 成本目标函数 → 三级介质”的草图

---

📚 参考资料

五大方案原始论文 / 项目

• AttentionStore (USENIX ATC’24):arXiv 2403.19708
• LMCache 开源项目:github.com/LMCache/LMCache
• InfiniGen (OSDI’24):arXiv 2406.19707
• CacheGen (SIGCOMM’24):arXiv 2310.07240
• Pensieve (OSDI’24 / EuroSys’25)
• Mooncake 技术报告 (Moonshot, 2024):github.com/kvcache-ai/Mooncake

相关基线 / 算法

• vLLM PagedAttention (SOSP’23):arXiv 2309.06180
• DistServe (OSDI’24):arXiv 2401.09670
• Splitwise (ISCA’24):arXiv 2311.18677
• H2O / StreamingLLM / Quest —— KV 算法侧淘汰 / 选择(对比 InfiniGen)
• KIVI / AWQ / GPTQ —— KV / 权重量化(对比 CacheGen)

调研笔记腹地

• 项目调研 - 长记忆分离式存储 —— 8 篇核心论文精读 + 三模块调研清单(本章是其中 KV 相关 5 篇的教程化整合)

本系列其它模块

• 模块四第6章 PD 解耦架构 —— PD 分离细节
• 模块十三第5章 分离式 KV-Cache 与 PD 分离 —— 远端 KV pool
• 模块零第4章 分布式通信与 I/O 优化 —— NCCL / NIXL / GPUDirect
• [本模块第3章 三级存储基础与延迟带宽 cheat sheet](./第3章-三级存储基础与延迟带宽cheat sheet.md) —— KV 放置的物理底座