Distributed KV Cache Management

导言

长上下文把 KV cache 从一块 GPU 临时张量，逐步推成了跨 GPU、CPU、SSD、NIC 和远程内存流动的分布式状态。表面上，近几年的论文分别在做分页、卸载、压缩、P/D 解耦、远程复用或直通访问；从更抽象的角度看，它们其实都在回答同一个问题：如何分布式地管理一批有依赖、可重算、持续增长且必须按时到达的数据？

本文以放置、组织、传输为主轴，把命名、依赖、正确性、调度与故障恢复作为支撑平面，纵向回看 2022—2026 年的演化，横向比较七类设计范式，并推演下一阶段可能出现的三条路径。研究截止日期为 2026-08-24。

证据口径

• 事实来自论文原文、正式会议页面或项目官方文档，并在相关判断附近给出链接。
• 本文推断是对多篇工作共同趋势的归纳，不等同于作者原话。
• 本文观点是为了建立统一模型而提出的抽象；它用于解释设计，不声称已经成为行业标准。

核心结论

不是普通缓存

本文观点：KV cache 更准确的抽象是“依赖携带的物化中间状态”，而不是普通 Key-Value Cache。它具有五个同时存在的性质：

1. 可派生：只要 Token、模型权重、位置语义和推理配置仍在，KV 可以重新计算；因此丢失通常影响延迟和成本，不一定影响数据耐久性。
2. 前缀依赖：第 t 个位置的状态由它之前的上下文决定。PagedAttention 原文明确指出，同一 Token 出现在不同位置时，其 KV 可以不同。PagedAttention
3. 单请求内追加：Decode 每步追加新状态，历史块通常不再修改；这使内容寻址、引用计数和写后发布比传统可变缓存更合适。
4. 容量大且在关键路径上：它既像存储对象，又是下一次 Attention 的直接输入；“已经命中但来不及加载”仍然等价于一次性能上的未命中。
5. 生命周期跨计算阶段：Prefill 生产，Decode 消费并继续追加；多轮会话、RAG、Agent 工具调用还会让它暂停、恢复、复用或迁移。

可以把第 l 层、前缀长度为 t 的状态写成：

$$
C_{l,t}=F_l(W, A, x_{0:t}, P, Q),
$$

其中 W 是模型版本，A 是 Adapter/LoRA 等增量权重，x 是 Token 前缀，P 是位置编码与截断策略，Q 是量化、稀疏和 Attention 配置。只比较 Token 文本而忽略这些依赖，可能得到形状正确但语义错误的 KV。

三个主问题

近几年系统工作的差异，可以压缩为三个主问题和三个支撑问题：

1. 放置 Placement：某个 KV 块的权威位置和当前副本在哪里——HBM、CPU DRAM、SSD、远程缓存池，还是计算存储设备？热块应该复制，长尾应该分片，还是直接重算？
2. 组织 Organization：KV 以请求、连续张量、固定页、前缀树、内容寻址对象、层、Head 还是 Token 区间为单位？逻辑依赖粒度、内存分配粒度、网络传输粒度与 Kernel Tile 粒度是否一致？
3. 传输 Transport：由生产者 Push 还是消费者 Pull？整段搬、逐层流式搬、压缩搬，还是不搬数据而把 Attention 移到数据旁边？如何处理拥塞、背压和完成通知？
4. 身份与正确性：怎样证明“这份 KV 正是当前请求需要的版本”？父前缀、模型版本、位置、租户和写入完成状态如何进入标识？
5. 调度与拓扑：请求去找已有数据，还是数据去找空闲计算？局部性、负载均衡、TTFT、TPOT 和网络带宽如何联合权衡？
6. 故障与安全：副本丢失后重算还是恢复？跨租户命中是否泄漏前缀存在性？未完成或旧版本对象是否可能被读到？

五年演化

本文推断：主线不是“KV 越搬越远”，而是管理边界逐层外扩。

flowchart LR
    A[2022<br/>请求内状态<br/>随迭代调度] --> B[2023<br/>逻辑地址与<br/>物理地址分离]
    B --> C[2024<br/>状态可卸载、<br/>可迁移、跨阶段]
    C --> D[2025<br/>全局缓存池与<br/>语义化复用]
    D --> E[2026<br/>分离式内存、<br/>直访与近数据计算]

    B -. 分页 .-> B1[Page / Block]
    C -. 流动 .-> C1[Prefill → Decode]
    D -. 服务化 .-> D1[Namespace / Directory]
    E -. 硬件协同 .-> E1[RDMA / NVLink-C2C / SSD]

1. 2022：先把时间切细。 Orca 的迭代级调度让不同请求可以在每个 Token 迭代边界加入或退出 Batch。它首先把自回归请求暴露为跨迭代存活的状态机，但 KV 仍主要绑定在执行实例上。Orca，OSDI 2022
2. 2023：再把地址虚拟化。 PagedAttention 把连续逻辑 KV 映射到不连续物理块，解决预留和碎片问题，也让块级共享成为可能。PagedAttention，SOSP 2023
3. 2024：让状态开始移动。 CachedAttention 在 HBM、DRAM、SSD 间分层保存多轮 KV；DistServe 和 Splitwise 把 Prefill/Decode 放到不同 GPU；CacheGen 开始专门压缩跨网络传输的 KV；LoongServe 则为单个长请求动态调整序列并行资源。
4. 2025：KV 成为独立且有类型的数据平面。 Mooncake 把闲置 CPU、DRAM、SSD 和 NIC 组织成全局分离式 KV 池；IMPRESS 和 Aqua 分别利用重要 Token 与闲置 Peer HBM；CacheBlend、Jenga、DiffKV 又承认不同位置、层、Head、Token 与状态类型的依赖并不均匀。
5. 2026：KV 成为可编程数据流，计算与数据重新靠拢。 Strata 联合重做层级布局、I/O 和调度；SYMPHONY 解耦计算与 KV 存储；DirectKV 让 GPU Kernel 直接访问 CPU 驻留 KV；SIGCOMM 2026 的 DualPath、KVServe、KVCodec、Turbo 等工作继续改变路径、表示和计算位置。

四个反复出现的矛盾

• 局部性与负载均衡：请求跟着 KV 走，可以减少传输，却可能把热点压在少数实例；KV 跟着空闲 GPU 走，可以均衡计算，却会制造网络流量。
• 传输与重算：远端已有 KV 不代表必须加载。对短前缀、拥塞链路或不兼容版本，重算可能更快。
• 细粒度复用与大粒度 I/O：小页便于共享和减少碎片，大块更能吃满 PCIe、RDMA 和 SSD 带宽。Strata 的出发点之一正是碎片布局造成的小 I/O。Strata，OSDI 2026
• 通用抽象与硬件直通：分页、对象接口和远程缓存较通用；NVLink-C2C、GPUDirect、CXL、UB 或计算存储能缩短路径，却把系统绑定到特定硬件和 Kernel。

关键时间线

时间	工作	当时主要瓶颈	新增抽象	留下的新问题
2022-07	Orca，OSDI	请求级批处理不适合逐 Token 生成	迭代级调度、选择性批处理	请求状态仍随执行实例放置
2023-10	PagedAttention，SOSP	连续预留导致内部/外部碎片，前缀难共享	逻辑块、物理块、Block Table	Attention Kernel 需要理解分页；块大小成为全栈折中
2024-06	Splitwise，ISCA	Prefill 计算密集、Decode 带宽受限，共置硬件利用率低	P/T/Mixed Pool、逐层 KV Handoff	阶段弹性换来网络交接和容量配比依赖
2024-07	InfiniGen，OSDI	CPU Offload 后，全量取回 KV 受总线限制	预测重要 KV，只预取必要项	访问集合预测与模型准确性进入系统边界
2024-07	DistServe，OSDI	Prefill 与 Decode 相互干扰、资源计划耦合	P/D 分池、带宽感知放置	KV 交接成为显式网络依赖
2024-07	DéjàVu，ICML	Pipeline Bubble、KV 预留与故障重算代价高	Microbatch KV Stream、异步副本、复制前沿	恢复粒度绑定 Pipeline 与 Microbatch
2024-07	CachedAttention，ATC	多轮对话重复 Prefill	HBM/DRAM/SSD 层级、逐层预取、异步保存	位置编码、截断与历史有效性需要单独处理
2024-08	CacheGen，SIGCOMM	远程 KV 比原始文本大，加载时间高	KV 专用编码、带宽自适应流式传输	压缩版本、质量预算和解码算力需要协同
2024-11	LoongServe，SOSP	超长请求资源需求随阶段变化	弹性序列并行	GPU 伸缩、KV 分片和迁移必须同步调整
2025-02	Mooncake，FAST	节点本地缓存容量小，P/D 资源与状态难统一调度	分布式 KV Pool、全局 Conductor、Transfer Engine	目录、热点复制、网络拥塞和中心控制复杂化
2025-02	IMPRESS，FAST	三级前缀缓存全量读取产生 I/O 放大	Query-Specific 重要 Token、KV-Aware 磁盘布局	Probe 与近似筛选引入质量边界
2025-03	vAttention，ASPLOS	专用分页 Kernel 侵入 Attention 实现	连续虚拟地址、按需物理页映射	页粒度、驱动能力与跨节点管理仍未解决
2025-03	Aqua，ASPLOS	CPU Offload 慢，而 Scale-up 域中存在闲置 Peer HBM	拓扑内 HBM 借用、Producer/Consumer 配对	收益依赖空闲 HBM、NVLink 和负载互补性
2025-03	InstAttention，HPCA	长上下文 Attention 反复搬运 SSD 中 KV	存储侧 Attention、GPU-CSD P2P	计算存储能力、算子支持和负载均衡受设备约束
2025-04	CacheBlend，EuroSys	RAG Chunk 不一定处于原位置，直接拼 KV 会丢失跨 Chunk 依赖	非前缀复用、选择性重算、加载与计算流水	“命中”变成部分可用而非二元状态
2025-08	HACK，SIGCOMM	P/D 传输和反量化开销	压缩域上近似计算	表示格式进入计算语义，质量边界更复杂
2025-10	Jenga，SOSP	新模型各层状态尺寸和 Token 依赖异构	两级分配器、逐层缓存接口	统一固定页不再足以描述全部状态
2025-10	DiffKV，SOSP	Key/Value、Token、Head 重要性不同	差异化压缩、GPU 并行 Compaction	稀疏布局与动态整理引入新管理成本
2026-05	SYMPHONY，NSDI	多轮会话状态使计算节点难弹性调度	计算-内存解耦、提示驱动预取、协同内存管理	提示可能错误，优先级和回退决定尾延迟
2026-05	DroidSpeak，NSDI	微调模型变体之间重复计算	跨模型逐层复用与选择性重算	模型兼容不再是简单版本相等
2026-07	Strata，OSDI	HBM/DRAM/SSD 层级被碎片 I/O 和 Delay Hit 拖慢	Host/GPU 布局解耦、GPU 辅助 I/O、缓存感知调度	数据布局与调度器绑定更深
2026-07	ECHO，OSDI	原生稀疏模型仍受 KV 容量和召回延迟限制	图友好管理、无损预测预取、融合流水	预取逻辑依赖模型内部 Indexer 语义
2026-07	DirectKV，OSDI	CPU Offload 仍需要 HBM Staging Buffer 和双向复制	GPU 对 CPU KV 的 Zero-Copy 访问	依赖高带宽一致互连和专门的 Attention Kernel
2026-08	KVServe、KVCodec，SIGCOMM	固定压缩策略或昂贵解码抵消远端复用收益	SLO/质量感知在线压缩、GPU 视频编解码	表示版本、质量约束和专用 Codec 资源进入调度
2026-08	DualPath、TurboBus、Turbo、Connex，SIGCOMM	存储 NIC、PCIe、分片 Attention 和动态端点各有路径瓶颈	双路径加载、链路池化、网内归约、迁移契约	系统更加依赖拓扑、流量隔离和 Epoch/顺序语义

从这条时间线可以看出，早期论文主要改变内存地址和调度粒度；中期开始改变阶段所有权和缓存层级；后期则同时改变数据语义、全局命名、传输路径和计算位置。这也是 KV cache 研究从 MLSys 问题扩展到 SOSP、OSDI、FAST、NSDI、SIGCOMM 和 HPCA 的原因。

横向对比

七种范式

选择这七类比较对象，是因为它们分别把主导权交给不同资源：本地内存管理器、序列并行执行器、层级缓存、阶段调度器、全局缓存服务、语义选择器和硬件数据通路。它们不是互斥产品，一套生产系统往往叠加其中数种。

范式	代表工作	放置	组织单位	传输方式	依赖处理	最适合	主要失效条件
本地分页	PagedAttention、vAttention	单实例 HBM，必要时 Host Swap	固定 Token Block 或连续虚拟地址	设备内寻址，少量 Swap	请求 Block Table、引用计数	中短上下文、高并发、稳定单机池	单请求超过本地容量；远程共享需求强
弹性序列并行	LoongServe	同一请求跨多 GPU 分片	序列片段、阶段并行计划	GPU 间 Collective/迁移	同一序列的分片完成依赖	单请求极长、Prefill 计算大	网络慢、伸缩频繁、迁移收益小于成本
层级卸载	CachedAttention、InfiniGen、IMPRESS、Strata	HBM/DRAM/SSD	页、层、重要 Token	预取、逐层流水、异步回写	预测未来访问，保证使用前 Ready	本地有大容量 Host/SSD，长上下文	I/O 碎片、预测失败、加载无法隐藏
P/D 解耦	DistServe、Splitwise	Prefill 与 Decode 不同 GPU Pool	请求 KV、Layer Stream	Push/RDMA/流式传输	Prefill 完成事件触发 Decode	两阶段资源形态差异大，SLO 清晰	KV 过大或网络拥塞，交接压过解耦收益
全局 KV 服务	Mooncake、SYMPHONY	远程 DRAM/SSD Pool，多级副本	内容寻址对象、Paged Block	RDMA、Striping、多 NIC	目录、租约、热点复制、预取提示	多轮/RAG/Agent，有高前缀复用	命中率低、中心元数据瓶颈、远程尾延迟高
语义化压缩与复用	CacheGen、CacheBlend、Jenga、DiffKV、DroidSpeak	依重要性和兼容性动态放置	Chunk、Layer、Head、Token 子集	压缩流、选择性加载与重算	显式识别位置、层和模型依赖	非前缀 RAG、异构模型、带宽受限	误差不可接受，元数据和 Kernel 复杂度过高
直访、拓扑借存与近数据计算	Aqua、InstAttention、DirectKV、Turbo	Peer GPU、CPU、CSD 或交换机成为可用层级	Kernel Tile、远端 Buffer、局部 Attention	Zero-Copy、P2P、Query Broadcast/Reduction	硬件完成语义、Tile 级流水	高带宽互连、闲置 Peer HBM 或可计算设备可用	PCIe/网络太慢、设备不通用、资源争用

为什么选择或放弃

1. 优先本地分页：当请求能放进单机 HBM、前缀共享主要发生在同一实例时，它仍是最简单且延迟最低的基线。放弃它通常不是因为分页“过时”，而是容量或共享边界越过了单机。
2. 选择层级卸载：当 Host DRAM/SSD 便宜且未来访问可预测时，容量收益明显；如果每步都要同步拉取不可预测的 KV，卸载只是在关键路径上增加慢设备。
3. 选择 P/D 解耦：当 Prefill 和 Decode 的资源比例随负载明显不同，分池可以独立扩缩；如果两阶段之间的 KV 交接无法被流水隐藏，Colocation 或 Chunked Prefill 可能更合适。Mooncake 论文也明确讨论了这项争议，而不是把 P/D 视为无条件最优。Mooncake PDF
4. 选择全局缓存池：多轮对话、固定 System Prompt、热门文档和 Agent 重复轨迹能够提供较高复用；一次性随机长 Prompt 则可能只付出存储、目录和网络成本。
5. 选择语义化方案：当“所有 KV 等价”这一假设已经明显不成立时，按位置、层、Head 或 Token 区分可以提升效率；代价是正确性和质量不能再只由内存系统保证。
6. 选择直访/近数据计算：当互连带宽足够高、Kernel 能适配远端内存时，减少中转 Buffer 很有价值；在普通 PCIe 或异构设备上，显式批量搬运可能仍然更快、更易控。

不要只比较命中率

分布式 KV 系统至少需要同时比较：TTFT、TPOT、Goodput、P99、网络字节、重算 FLOPs、HBM/DRAM/SSD 占用、命中到达时间、质量损失和故障恢复代价。只报命中率，会把“命中了但晚到”“命中后解压太慢”“热点命中把节点压垮”等问题全部隐藏。

详细分析

先定义对象

要分布式管理 KV，第一步不是选 RDMA 还是 SSD，而是回答：系统正在管理的对象究竟是什么？

一个更完整的逻辑对象标识可以写成：

KVBlockID = Hash(
    model_snapshot,
    adapter_set,
    attention_schema,
    parent_prefix_hash,
    token_ids,
    position_policy,
    multimodal_input_hash,
    numeric_format,
    tenant_salt,
)

这不是某个框架现成 API，而是本文给出的正确性清单。vLLM 当前的 Automatic Prefix Caching 已经把父块 Hash、当前块 Token 和额外 Hash纳入块标识；额外项可包含 LoRA ID、多模态输入 Hash 与租户隔离 Salt。vLLM Prefix Caching 文档

还应把三层身份分开：

• Semantic ID：说明它是哪一个模型语义、哪条前缀血缘下的 KV。
• Representation ID：说明它是 BF16/INT8、稠密/稀疏、Layer/Head/TP Shard，以及采用哪种 Codec 和物理 Layout。
• Physical Locator：说明当前副本位于哪个 Tier、Node、Device、Memory Region 和 Placement Epoch。

迁移只改变 Locator，压缩或重排改变 Representation，只有模型、前缀或位置语义变化才改变 Semantic ID。把这三层混成一个地址，会让迁移、压缩和版本失效互相污染。

父块 Hash 非常关键。仅对当前 16 个 Token 做 Hash，不能区分：

[系统提示 A] + [相同的当前块]
[系统提示 B] + [相同的当前块]

两段当前文本相同，但其隐藏状态和 KV 受到此前上下文影响。把父 Hash 链起来后，KV Block 才成为一棵前缀树或 DAG 上的节点，而不只是“Token 字符串对应的缓存”。

对象还需要状态，而不只是 ID：

stateDiagram-v2
    [*] --> Missing
    Missing --> Allocated: reserve
    Allocated --> Filling: prefill / decode append
    Filling --> Ready: write complete + publish
    Ready --> Moving: copy / stream / replicate
    Moving --> Ready: destination verified
    Ready --> Evicted: lease expired / pressure
    Evicted --> Missing
    Missing --> Ready: recompute

只有 Ready 对象能被消费者使用。Allocated 表示地址存在，不表示 KV 已经生成完；Moving 也不表示远端副本已经可见。这意味着 P/D 解耦至少需要目标地址、数据传输、完成通知和发布顺序四类状态。所谓“无状态调度”，通常只是计算实例不长期拥有状态，而不是系统真的没有状态。

一个关键区别

数据库通常把存储副本视为真相，计算结果可以丢；KV cache 恰好相反：Token 与模型快照更接近真相，KV 是昂贵但可重建的副本。因此它可以采用 Best-Effort Replica、丢失后重算和弱持久性，但不能放松语义身份与写入原子性。

放置：谁靠近谁

放置决策有三个彼此独立的维度：

1. 存储层级：HBM、Host DRAM、本地 SSD、远程 DRAM、远程 SSD、对象存储。
2. 拓扑距离：同一 GPU、同一 Superchip、同一节点、同一机架、跨机架。
3. 所有权：请求私有、实例本地共享、模型池共享、集群全局共享、跨模型共享。

许多论文只在其中一个维度移动数据。例如 CachedAttention 主要扩展存储层级；DistServe 主要改变阶段所有权；Mooncake 同时扩展层级、拓扑和全局共享范围；DroidSpeak 又把所有权扩展到同架构微调模型之间。

请求找数据，还是数据找计算

这是分布式 KV 调度最核心的矛盾：

• Cache Affinity：把请求送到已有前缀的实例，节省搬运和重算，但热门前缀可能造成负载倾斜。
• Load Balance：把请求送到最空闲实例，再搬 KV；计算更平衡，但网络与目标显存可能成为瓶颈。
• Remote Access：计算不迁移，KV 也不落到 HBM，而由 Kernel 直接读远端层级；减少显式迁移，却把远端带宽放进每次 Attention 的关键路径。
• Recompute：两者都不迁移，在目标实例重建 KV。它消耗 Prefill FLOPs，但可能避开拥塞、解压和版本转换。

可以用一个简单的在线选择式表达：

$$
T_{use}(b,c)=\min
\begin{cases}
T_{recompute}(b,c),\
T_{fetch}(b,s\rightarrow c)+T_{decode}(b),\
T_{remote_attention}(b,s,c).
\end{cases}
$$

这里 b 是 KV Block，c 是消费者，s 是当前存储位置。真实调度还要加入排队时间、容量影子价格、SLO 风险和依赖是否 Ready。缓存命中只是候选路径，不是调度结论。

复制、分片与重算

• 复制热前缀可以降低热点读取拥塞，并让更多 Prefill 实例获得亲和性。Mooncake 的 Conductor 会围绕缓存位置调度，并对热点块做迁移或复制。Mooncake，FAST 2025
• 分片超长 KV可以突破单节点容量，但一次 Attention 可能要访问所有序列分片，并合并局部结果；这把 KV 管理与 Sequence/Context Parallelism 绑定起来。
• 只保留或读取重要子集如 InfiniGen、LServe 与 IMPRESS，把“完整副本”改成“召回集合”；它节省容量和传输，却要求模型或运行时能预测当前 Query 需要哪些历史。
• 借用拓扑内闲置 HBM如 Aqua，把同一 NVLink/NVSwitch Domain 中的 Memory Producer 与 Consumer 配对；它比 CPU DRAM 快，但只有负载和拓扑存在互补余量时才成立。Aqua，ASPLOS 2025
• 不做高可用副本也可能合理。Mooncake Store 官方架构说明其 Cache Layer 的复制为 Best-Effort，不保证高可用；写入保持对象原子性，读取获得一致版本但不保证最新版本。Mooncake Store 架构

最后一点说明了 KV 与业务数据库的差别：它更关心“可及时重建”而不是“永不丢失”。但如果重算会让 P99 超过 SLO，Best-Effort 在性能意义上仍然可能失败。

组织：四种粒度冲突

KV 的“块”并不是天然存在的。同一份数据至少有四种候选粒度：

1. 依赖粒度：一个前缀节点、RAG Chunk、一次多轮会话的历史段。
2. 分配粒度：HBM Page、不同层的状态页、Buddy/Slab 中的内存块。
3. 传输粒度：RDMA Segment、SSD I/O、压缩 Bitstream、Multi-NIC Stripe。
4. 计算粒度：Attention Kernel 读取的 Layer、Head、Token Tile。

PagedAttention 的突破，是把逻辑 Token Block 与物理 KV Block 分开：逻辑连续不再要求物理连续，Block Table 保存映射。它使按需增长、块级共享和 Copy-on-Write 成为可能，但也让 Kernel、调度器和 Swap 都围绕 Page 工作。

论文 Figure 6：逻辑 KV Block 通过 Block Table 映射到不连续的物理块。截图来自 PagedAttention 论文第 6 个 PDF 页面；它证明的是地址虚拟化机制，不代表跨节点分布式缓存。

此后两条路线分别修正了分页的边界：

• vAttention使用 CUDA Virtual Memory Management 维持连续虚拟 KV 地址，把动态物理分配隐藏在虚拟内存映射下，减少专用 PagedAttention Kernel 的侵入。vAttention，ASPLOS 2025
• Strata发现 GPU 上适合计算的碎片布局并不适合 Host/SSD 大块 I/O，因此解耦 Host 与 GPU 布局，再用 GPU 辅助整理大传输。换句话说，计算页与传输块不必是同一个物理布局。

从页表到内容寻址

页表解决“同一请求的逻辑地址映射到哪块显存”；全局复用还要解决“另一请求如何证明它需要同一内容”。这推动系统从 Request ID 转向 Prefix Hash、Block Key 和全局目录。

Mooncake 将 KV 作为对象管理，提供 Get/Put/List/Del 等接口，并由中心 Master 维护对象到 VRAM/DRAM/NVM Buffer 的映射；Transfer Engine 负责跨多 NIC 的 Zero-Copy 与 Striping。Mooncake Store 官方架构 从抽象上看，它已经不只是推理引擎的内存管理器，而是为可派生张量定制的分布式对象缓存。

论文 Figure 2：Prefill Pool、Decoding Pool、分布式 KVCache Pool、Transfer Engine 和全局 Conductor 被放入同一控制闭环。截图来自 Mooncake FAST 2025 论文第 3 个 PDF 页面。

从同质页到语义对象

固定页隐含了一个早期假设：各层每个 Token 的状态尺寸、生命周期和访问方式大致相同。新模型正在打破它：

• Sliding Window Attention 只保留有限窗口；Full Attention 依赖全部历史；Mamba/Gated Delta 类状态可能固定大小或只需要最近状态。
• Jenga 为不同层暴露 Page Size、Active Pages 和逐层缓存策略，说明“所有层统一保留完整前缀”已经不是通用模型。Jenga，SOSP 2025
• DiffKV 区分 Key/Value、Token 重要性与不同 Head 的稀疏模式，并为不规则释放后的空间设计 GPU 并行 Compaction。DiffKV，SOSP 2025
• DroidSpeak 发现同架构微调模型之间可以逐层复用一部分 KV，另一部分需要重算。对象兼容性由“模型版本相同”变成“哪些层在误差预算内兼容”。DroidSpeak，NSDI 2026

因此，未来的 KV Namespace 很可能不只是 (prefix_hash → bytes)，而要表达层类型、位置语义、表示格式、质量等级和可重算规则。

传输：什么时候搬

传输设计的第一原则不是峰值带宽，而是依赖到达时间。一次 Decode 能启动，需要它所访问的所有 KV 分片在正确版本上 Ready；其中最慢的一块决定关键路径。

Push 与 Pull

• Producer Push：Prefill 生成一层或一块 KV 后立即流向 Decode。优点是能与后续 Prefill 重叠；缺点是必须预先选择 Decode 实例并预留地址，过早绑定可能损害负载均衡。
• Consumer Pull：Decode 或 Prefill 在确定需求后从全局池读取。优点是选择更晚、调度更灵活；缺点是 Miss 或目录查询容易进入 TTFT/TPOT 关键路径。
• Advisory Prefetch：SYMPHONY 利用用户交互或工作负载结构提供的提示提前搬缓存，并用优先级和协同内存管理应对提示不可靠。SYMPHONY，NSDI 2026

生产系统通常同时使用三者：新 KV 逐层 Push，历史前缀按目录 Pull，交互间隙再做预测预取。

整体、逐层与双路径

一次性传完整 KV 容易获得大带宽，但 Decode 要等最后一字节；逐层流式可以早到早用，却增加元数据、完成事件和小消息。Mooncake 的典型流程会逐层把增量 KV 流向 Decode，并用多 NIC Transfer Engine 聚合带宽。SIGCOMM 2026 的 DualPath 进一步同时利用 Prefill 与 Decode 两侧的存储 I/O 路径，再经 RDMA 汇合。SIGCOMM 2026 Program

这不是简单的“链路越多越快”。多路径必须处理：

• 同一对象不同 Segment 的顺序与完成条件；
• 某一路拥塞时的动态分流和背压；
• 目标 Buffer 的容量预留与取消；
• Decode 被调度走后，迟到数据如何回收；
• 重复到达和重试是否幂等。

当计算端点本身会扩缩或迁移时，问题又从“选哪条路”升级为“路由变化时正在飞的数据怎么办”。SIGCOMM 2026 的 Connex 为 Token Stream、Activation 和 KV Transfer 定义 Endpoint Mobility Contract，用 Epoch-Based Routing、显式 Handover、Exactly-Once Delivery 和 Credit Backpressure 约束切换过程。Connex，SIGCOMM 2026 这类机制说明，Placement Epoch 最终必须进入 KV 的传输协议，而不能只存在于调度器内存里。

压缩、重算与质量预算

CacheGen 把 KV 编码为更紧凑的 Bitstream，并随可用带宽调整不同部分的压缩级别；论文报告在其测试中将 KV 大小降低 3.5—4.3×。CacheGen，SIGCOMM 2024 HACK 则尝试直接在量化 KV 上近似计算，避免传输后完整反量化。HACK，SIGCOMM 2025

从分布式系统角度看，压缩产生了新的版本维度：

同一逻辑 KV
├── BF16 完整副本
├── INT8 网络副本
├── 更低比特冷副本
└── 只保留重要 Token 的稀疏副本

调度器必须知道消费者 Kernel 支持哪个版本、转换成本是多少、质量预算是否允许。否则“远端有副本”仍然不可直接使用。

直访：让计算靠近数据

传统 Offload 路径是：

CPU/SSD KV → DMA → HBM Staging Buffer → Attention Kernel

DirectKV 在 GH200/GB200 一类高带宽 CPU-GPU 平台上，让 GPU Kernel 经 NVLink-C2C 直接访问 CPU 驻留 KV，并通过面向 CPU Memory 的 Tiling、Warp Pipeline 和 Kernel Fusion 隐藏远端访问。论文报告其实现最多减少 50% CPU-GPU 传输量和 43% GPU 内存占用，但端到端提升最高为 1.2×；这也说明去掉一次复制并不等于消除带宽差距。DirectKV，OSDI 2026

论文 Figure 1：红色路径先把 KV 搬入 HBM Buffer，绿色路径让 GPU SM 经 L2 和 NVLink-C2C 直接读取 CPU Memory。截图来自 DirectKV OSDI 2026 论文第 4 个 PDF 页面。

“直驱/直访”至少要区分四种机制：

1. 控制面旁路：设备核心直接提交通信描述符，减少 Host/AICPU 下发。AIV-Direct 主要属于这一类。
2. 数据面旁路：GPU RDMA、GPUDirect Storage 或 P2P 避免 Host Bounce Buffer。
3. 地址空间直访：GPU Kernel 直接 Load CPU/CXL/Peer Memory，不显式 Swap 到 HBM。
4. 近数据计算：InstAttention 把 Decode Attention 下沉到计算存储设备，不再把全部 KV 搬回 GPU。InstAttention，HPCA 2025

SIGCOMM 2026 的 Turbo 又把 Query Broadcast 和局部 Attention Aggregation 下沉到交换机：KV 仍分散在 GPU，但网络设备参与合并局部结果。Turbo，SIGCOMM 2026 它与 InstAttention 分别代表“存储侧计算”和“网内归约”，共同回答了同一个抽象问题：如果依赖数据太大且分布太散，能否只移动 Query 和部分结果？

这四类不能混称为同一种“直驱”。尤其是 Serving Large Language Models on Huawei CloudMatrix384 中的 AIV-Direct，主要指 AIV Core 经 UB 直接写远端 NPU Memory、降低 MoE Dispatch/Combine 小消息的 SDMA 启动开销；论文中的 P/D KV 交接使用独立 RDMA Plane，Context Caching 又是 UB 连接的 DRAM/SSD 池。它与 KV 分布式管理共享“缩短控制/数据路径”的思想，但 AIV-Direct 本身不是 KV Cache 协议。

正确性：不是最新，而是匹配

普通缓存经常讨论 Strong Consistency 或 Eventual Consistency；不可变 KV Block 更适合问：

当前读到的对象，是否与所需依赖完全匹配，并且已经完整写入？

对写后不变、内容寻址的块来说，系统不一定需要所有副本立刻更新到“最新”；它需要：

1. 身份匹配：模型、Adapter、Token 前缀、位置、格式和租户域一致。
2. 原子发布：消费者不能看见半写入对象。
3. 父依赖闭合：子块可用时，它引用的父前缀必须对应同一依赖链。
4. 幂等传输：重试、重复 Push 不会产生两个冲突身份。
5. 安全隔离：跨租户不能通过命中延迟推断他人是否使用过某个秘密前缀。

还必须把三种“可用”分开，否则同一个 Hit Rate 会混合完全不同的正确性：

可用语义	代表工作	消费前动作	正确性边界
精确状态复用	Mooncake、Strata、SYMPHONY、KVCodec	校验后直接加载或直读	数值状态与依赖精确匹配；只改变位置或无损表示
修复式复用	CacheBlend、DroidSpeak	选择性重算 Token 或 Critical Layer	旧状态并非完全等价，修复后满足质量要求
质量预算式近似	IMPRESS、DiffKV、HACK、KVServe	稀疏选择、量化或在线选 Codec	必须显式满足任务质量下限，不能只验证 Hash

ECHO 是介于预测和精确执行之间的特殊情况：预取可以漏，但遗漏项会被 Recall，因而预测错误影响性能而不放宽最终语义。ECHO，OSDI 2026

对一个正在生成的序列，可以维护 committed_frontier：只有它之前所有必需 Layer、Head 和 TP Shard 都通过版本检查并完成发布，Decode 才能把前缀视为可读。当前追加尾部只有一个合法 Writer；Beam、并行采样或 Agent 分支发生时，应创建新的 Branch/Epoch，而不是让多个 Writer 修改同一尾部。

Mooncake Store 的“读取一致版本但不保证最新”在不可变对象语境下是合理折中；vLLM 的 Cache Salt 则把安全域加入第一个块的 Hash，避免未授权租户共享和基于延迟的前缀探测。Mooncake Store、vLLM Cache Isolation

位置依赖是最容易被低估的正确性问题。CacheBlend 指出：一个 RAG Chunk 单独预计算的 KV，被移动到另一个 Chunk 之后时，缺少对前置文本的 Cross-Attention，不能直接当成完整 Prefill 结果。它通过选择性重算少量 Token 融合缓存。CacheBlend，EuroSys 2025 这说明分布式复用不是简单的 memcpy，而是带数据血缘的增量视图维护。

调度：命中也可能迟到

随着 KV 进入远端层级，调度器需要联合管理三种队列：

• 计算队列：Prefill FLOPs、Decode Token Step、Batch Slot。
• 容量队列：HBM Page、Host Buffer、SSD 空间、远端配额。
• 传输队列：NIC、PCIe、NVLink、SSD Queue、解压/重排 Kernel。

只优化其中一个会产生反直觉结果：

• 为最高缓存命中把请求集中到一台 Prefill 实例，导致排队时间超过重算节省。
• Decode Slot 已经预留，但 KV 传输拥塞，宝贵 HBM 空等。
• 多个请求同时 Miss 同一长前缀，第一份正在加载，其余请求都等待，形成 Strata 所说的 Delay Hit。
• 为隐藏 I/O 填入更多计算请求，结果 Batch 中 KV 总量超过 HBM，再次触发 Eviction。

Mooncake 的架构把 Prefill Cache-Aware Scheduler、KVCache Balance Scheduler 和 Decode Load-Balance Scheduler放在统一 Conductor 下；Strata 再把缓存加载延迟直接加入 Batch 组合；SYMPHONY 则让推理框架和远程内存层协同调整优先级。演化方向很明确：KV Placement 不再是调度后的副作用，而是调度决策本身。

一个可执行的调度目标可以写成：

$$
\max ; Goodput
\quad s.t. \quad
P(TTFT\le S_{ttft})\ge p,
;P(TPOT\le S_{tpot})\ge p,
;M_{tier}\le C_{tier},
;B_{link}\le C_{link}.
$$

其中请求的预计完成时间必须包含：目录查询、排队、加载、解码格式转换、重算和依赖等待，而不是只计算 GPU Kernel 时间。

租约与恢复

不同生命周期需要不同租约：

• Active/Pinned：Decode 正在读取，不能被普通淘汰策略回收。
• Paused：Agent 等待工具、用户或外部服务，返回时间未知；系统需在保留、降级到慢层和丢弃后重算之间选择。
• Warm/Reusable：当前没有活跃消费者，但预计会被多轮会话或共享前缀再次使用。
• Soft Replica：只服务性能，可以在容量压力或节点故障时直接丢弃。

KV 的恢复根不是某一份缓存副本，而应是：

Token Log
+ Model / Adapter Version
+ Position / Attention Configuration
+ Request / Branch Epoch
+ Sampling State

Prefill 节点失败可以重跑或读取前缀副本；Decode 节点失败可以从最近提交前沿加载 KV，或从 Token Log 重算；缓存节点失败可以退化为 Miss；传输中断则应丢弃未越过 Publish Barrier 的目标对象。这类系统需要的是延迟韧性，而不是把每份 KV 都做成强持久数据库。

演化不是直线

每次“解决”都会把瓶颈推到下一层：

1. Orca 提高动态批处理能力，更多并发请求让 KV 容量更快成为瓶颈。
2. PagedAttention 消除大部分显存碎片，更长上下文和更大 Batch 又把容量边界推向 CPU/SSD。
3. Offload 扩大有效容量，CPU-GPU/SSD-GPU 传输成为瓶颈，催生预取、稀疏选择和 Zero-Copy。
4. P/D 解耦消除阶段干扰，却把原本实例内部的依赖变成网络上的 KV Handoff，催生 CacheGen、HACK、KVServe、DualPath。
5. 全局复用减少重复 Prefill，又暴露位置、模型、租户和质量版本兼容问题，催生 CacheBlend、DroidSpeak 与更严格的 Namespace。
6. 直访减少显式搬运，远端带宽、Kernel Tiling、硬件可移植性和错误恢复成为新边界。

最稳定的设计原则

不要把某一级存储、某种传输协议或某个 Block Size 写死为 KV 的本质。更稳定的接口应表达：对象身份、依赖、可用版本、位置、Ready 事件、可接受的重算/质量预算和拓扑成本；底层再选择分页、RDMA、SSD、CXL、UB 或近数据计算。

未来判断

以下不是对单篇论文结论的复述，而是基于 2022—2026 年公开工作做出的趋势推断。判断标准不是“某个方案看起来更先进”，而是它能否同时承受更长上下文、更大并发、Agent 分支、异构存储和故障尾延迟。

路线一：依赖原生的 KV Cache OS

今天多数系统分别拥有一部分能力：vLLM 管页表与前缀 Hash，Mooncake 管远端对象与拓扑传输，DistServe 管 P/D Placement，Strata 管加载等待，DéjàVu 管复制前沿。它们还没有共同收敛成一个真正的“KV Cache OS”。

我认为最可能先出现的形态，是一个横跨框架和存储层的控制面：

                 Semantic Namespace
     (model, adapter, tokens, position, branch, tenant)
                           │
                      Prefix / Branch DAG
                           │
        ┌──────────────────┼──────────────────┐
        │                  │                  │
   Placement          Representation       Lifecycle
HBM/DRAM/SSD/Remote   BF16/INT8/Sparse     Lease/Pin/Evict
        │                  │                  │
        └──────────────────┼──────────────────┘
                           │
                Scheduler + Transfer Engine

它不必亲自保存所有字节，但必须回答六件事：对象是否存在、依赖是否闭合、哪个表示可直接消费、哪份副本按时可达、谁持有租约、失败后从哪个提交前沿恢复。这样，cache hit 才从布尔值变成一个带时间和成本的承诺。

• 成立前提：框架愿意暴露稳定的语义身份、Ready/Publish 事件和重算成本；目录查询与依赖图维护不能进入每个 Token Step 的高开销关键路径。
• 可观测信号：不同推理引擎开始共享 Cache Connector、对象格式和 Namespace；调度器直接查询远端目录；Prefix Tree 扩展为 Agent Branch DAG；缓存服务出现租约、配额和版本兼容 API。
• 失败条件：模型、Adapter、Kernel Layout 与量化格式持续碎片化，导致“逻辑命中、物理不可用”；跨租户安全要求又使共享域过小，元数据成本超过复用收益。

它更像文件系统加调度器，而不是数据库

历史 KV 主要是写后不变、可由 Token Log 重建的派生状态，因此不需要一般数据库的多写事务。真正要原子化的是 身份确认、对象发布、租约转移和调度承诺。如果把所有副本都做成强一致持久数据，成本往往高于失败后重算。

路线二：机架级共享内存与直访数据面

第二条路线试图继续消除“先复制到本地 HBM 才能计算”的假设。DirectKV 已展示 GPU Kernel 直读 CPU Memory；LoongServe 把 Query 发往分散的 KV Owner；InstAttention 把 Attention 推到存储侧；CloudMatrix 则展示 UB/RDMA/DRAM/SSD 并存的 Scale-up Domain。它们虽然机制不同，却都在逼近同一目标：让地址、传输和计算位置可以独立选择。

未来的机架级 KV Pool 可能同时提供两类接口：

1. 对象接口：Get/Put/Prefetch/Replicate，适合大块、可预测、跨故障域的数据移动。
2. 远程内存或主动计算接口：Load/Attend/Reduce，适合不值得完整复制的冷 KV 或分片 KV。

调度器应按复用次数选择路径：只读一次时直接远程访问；会连续 Decode 多轮时先搬入 HBM；KV 分散且搬运昂贵时，把 Query 发给 Owner 做局部 Attention，再归约结果。这比把 Zero-Copy 当成无条件最优更符合成本规律。

• 成立前提：机架内互连的带宽、尾延迟和故障隔离足以支撑 Attention 关键路径；Kernel 能对远端访问做 Tiling、流水和回压；地址撤销、节点重启和迟到读有明确定义。
• 可观测信号：GPU/NPU Runtime 暴露稳定的 Peer/CXL/统一地址访问；Attention Kernel 原生接受远端或分片 KV；KV Appliance 同时支持 RDMA 对象传输与近数据算子。
• 失败条件：HBM 与远端介质的性能差距长期过大，随机小读放大尾延迟；硬件语义高度厂商绑定；一次网络抖动就阻塞整个 Decode Batch。此时显式异步复制仍会是更稳健的主路径。

直访不等于没有数据运动

GPUDirect 通常省掉 Host Bounce Buffer，但不保证由 GPU 自主完成全部控制；Zero-Copy 省掉显式中间副本，但字节仍要经过互连；CXL 或统一地址空间解决可达性，也不会自动解决模型版本、Branch Epoch 和半写对象的语义正确性。

路线三：主动 KV 与模型—缓存协同

第三条路线不再默认“必须保存并搬运全部稠密 K/V Tensor”。InfiniGen 与 IMPRESS 预测真正需要的 Token，CacheGen 为链路生成多码率表示，HACK 在量化 KV 上直接近似计算，CacheBlend 选择性重算位置相关 Token，DroidSpeak 只传多模型协作时必要的中间状态。共同趋势是：KV 从被动字节数组变成可选择、可变形、带质量预算的物化视图。

这条路线最终可能把数据节点变成“主动 KV 节点”：它不仅返回字节，还能执行过滤、量化转换、局部 Attention、跨 Chunk 融合或增量修复。更进一步，模型架构和训练过程会显式考虑可复用性、可分片性和跨位置稳定性，而不是让系统在训练完成后被动适配。

• 成立前提：系统能把近似误差映射到任务质量和 SLO；模型与 Cache Representation 有明确版本契约；算子支持混合精度、稀疏与局部重算。
• 可观测信号：调度器开始携带 quality_budget；远端 Cache 返回多个表示而非单一 Tensor；Attention API 接受稀疏、量化或部分可重算 KV；论文同时报告系统性能与任务质量，而非只报告困惑度。
• 失败条件：表示版本组合爆炸，校准成本高于节省；误差在长链 Agent 任务中累积且难以归因；模型更新频繁，使预计算 Cache 大量失效。

综合判断

未来三到五年更可能是三条路线叠加，而不是一种机制胜出：

层面	最可能的稳定抽象	仍会快速变化的实现
语义面	内容身份、Prefix/Branch 依赖、版本、安全域	Token/Chunk/Session 的具体编码
控制面	Placement、Lease、Ready、重算预算、恢复前沿	调度启发式与元数据服务形态
数据面	对象传输、远程读取、计算随数据走三选一	RDMA、CXL、NVLink、UB、SSD 与压缩算法
执行面	消费者声明可接受的 Representation	Page Size、Kernel Layout、量化与稀疏格式

因此，最值得投入的不是押注某个单一介质，而是先把接口分层：Semantic ID 决定“是不是同一份状态”，Representation ID 决定“能不能直接用”，Physical Locator 决定“从哪里、以什么代价取得”。 只要三者仍被揉成一个地址，系统每增加一种硬件、模型或复用方式，就要重写整条链路。

仍待确认的问题

这轮调研能够确认“研究方向正在从显存优化走向分布式状态管理”，但下面几项尚无公认答案：

1. 语义身份是否可能标准化：目前没有跨 vLLM、TensorRT-LLM、SGLang、Mooncake 等系统通用的 Semantic ID、Branch Epoch、Position Schema 和 Publish 协议。即便都叫 KV Block，也未必能交换。
2. 表示兼容由谁负责：模型版本相同仍可能因 TP/PP 切分、Head Layout、DType、压缩与 Kernel Packing 不同而无法直读。转换发生在生产者、缓存服务还是消费者，尚未收敛。
3. 依赖图能否扩展到 Agent 工作负载：工具调用带来长时间 Pause、分支与回退，传统线性 Prefix Tree 不足以表达其租约和回收价值；公开论文中的真实 Agent Trace 仍有限。
4. 近似 KV 如何验收：压缩、稀疏、选择性重算的质量指标各异。面向代码生成、长文推理和多轮 Agent 时，局部 Attention 误差如何转化为最终任务失败，还缺少统一基准。
5. 跨租户复用是否值得：内容寻址会带来命中侧信道和数据残留风险；强隔离又会降低共享率。vLLM 的 Cache Salt 解决部分命名隔离，但不等于完整的访问控制、擦除证明和审计。
6. 远程命中何时优于重算：这取决于 Prefill 算力价格、网络尾延迟、压缩开销和后续复用次数。很多论文在不同硬件与 Trace 上各自比较，尚不能直接推出统一阈值。
7. 故障语义应做到哪一级：KV 可重建并不意味着重建免费；但为每个 Token 做强持久复制又代价过高。复制到请求、Chunk、Layer、Microbatch 还是 Token Frontier，应由 SLO 和故障域决定。
8. “直驱”概念仍需严格区分：CloudMatrix 技术报告中的 AIV-Direct 面向 MoE 通信，P/D KV 使用另一条 RDMA 数据面；把二者直接等同会误判优化对象。该报告目前是 arXiv 技术报告，其结论还应结合实现细节与后续同行评议验证。
9. 2026 年部分工作仍处于最新发表窗口：Strata、ECHO、DirectKV、SYMPHONY、DroidSpeak 已有会议官方页面；SIGCOMM 2026 的 DualPath 等条目可由官方 Program 确认，但本文没有把尚未充分公开的实现细节当成已验证事实。
10. 尚无系统统一覆盖全部问题：现有工作通常只在分页、P/D 交接、远端缓存、传输、压缩、直访、近数据计算或恢复中的一到三项做到深入。所谓“KV Cache OS”仍是本文的抽象归纳，而不是某篇论文已经完整实现的产品。

参考资料

以下优先列会议官方页面、正式 DOI、作者论文或项目官方设计文档；访问与出版状态核对截止到 2026-08-24。

2022—2024

• Orca: A Distributed Serving System for Transformer-Based Generative Models，OSDI 2022。
• Efficient Memory Management for Large Language Model Serving with PagedAttention，SOSP 2023。
• Splitwise: Efficient Generative LLM Inference Using Phase Splitting，ISCA 2024。
• DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving，OSDI 2024。
• DéjàVu: KV-cache Streaming for Fast, Fault-tolerant Generative LLM Serving，ICML 2024。
• Cost-Efficient Large Language Model Serving for Multi-turn Conversations with CachedAttention，USENIX ATC 2024。
• InfiniGen: Efficient Generative Inference of Large Language Models with Dynamic KV Cache Management，OSDI 2024。
• CacheGen: KV Cache Compression and Streaming for Fast Large Language Model Serving，SIGCOMM 2024。
• LoongServe: Efficiently Serving Long-context Large Language Models with Elastic Sequence Parallelism，SOSP 2024。

2025—2026

• Mooncake: Trading More Storage for Less Computation — A KVCache-centric Architecture for Serving LLM Chatbot，FAST 2025。
• IMPRESS: An Importance-Informed Multi-Tier Prefix KV Storage System for Large Language Model Inference，FAST 2025。
• CacheBlend: Fast Large Language Model Serving for RAG with Cached Knowledge Fusion，EuroSys 2025。
• vAttention: Dynamic Memory Management for Serving LLMs without PagedAttention，ASPLOS 2025。
• Aqua: Network-Accelerated Memory Offloading for LLMs in Scale-Up GPU Domains，ASPLOS 2025。
• InstAttention: In-Storage Attention Offloading for Cost-Effective Long-Context LLM Inference，HPCA 2025。
• HACK: Homomorphic Acceleration via Compression of the Key-Value Cache for Disaggregated LLM Inference，SIGCOMM 2025。
• Jenga: Effective Memory Management for Serving LLM with Heterogeneity，SOSP 2025。
• DiffKV: Differentiated Memory Management for Large Language Models with Parallel KV Compaction，SOSP 2025。
• Serving Large Language Models on Huawei CloudMatrix384，arXiv 技术报告，2025。
• SYMPHONY: Enabling Compute-Memory Disaggregation in LLM Serving Systems，NSDI 2026。
• DroidSpeak: KV Cache Sharing Across Fine-tuned Model Variants，NSDI 2026。
• Strata: Hierarchical Context Caching for Long Context Language Model Serving，OSDI 2026。
• ECHO: Efficient KV Cache Offloading with Lossless Prefetching for Serving Native Sparse Attention LLMs，OSDI 2026。
• No Buffer, No Bottleneck: Efficient Zero-Copy KV Cache Offloading for Long-Context LLMs，OSDI 2026。
• KVServe: Service-Aware KV Cache Compression for Communication-Efficient Disaggregated LLM Serving，SIGCOMM 2026。
• DualPath: Accelerating Agentic LLM Inference by Harvesting Disaggregated KV-Cache Storage I/O，SIGCOMM 2026。
• Efficient Remote KV Cache Reuse with GPU-native Video Codec，SIGCOMM 2026，系统名 KVCodec。
• TurboBus: Pooling PCIe Bandwidth for LLM Workloads via Scale-Up Fabrics，SIGCOMM 2026。
• SIGCOMM 2026 Technical Program，另含 Turbo 的网内 Attention Aggregation、Connex 的动态端点迁移契约等工作。

实现与设计文档

• vLLM Automatic Prefix Caching Design，Prefix Hash、Cache Salt 与隔离说明。
• Mooncake Store Architecture，对象 API、原子写、版本语义、零拷贝与多 NIC Transfer Engine。