导读

大语言模型服务的瓶颈，越来越多地从“模型能不能生成”转向“系统能不能高效承载生成”。在自回归推理中，每生成一个 token，模型都要依赖此前上下文。为了避免重复计算，LLM serving 系统一般会缓存历史 token 的 key-value 张量，这就是 KV cache。它是低延迟、高吞吐推理的关键基础设施，但在长上下文、多租户、批量服务和 agent 工作负载下，KV cache 很快会成为显存、带宽、调度和能耗瓶颈。 这篇综述聚焦一个非常工程化、也非常关键的范围：system-aware KV infrastructure for serving LLMs，简称 sKis。作者强调，本文不是泛泛讨论 LLM 高效推理，也不是训练时压缩或重训模型，而是关注“服务阶段、以 KV cache 为核心、以系统指标为目标”的优化方法。 论文的核心贡献是提出一个系统行为视角的分类框架：时间维度关注 KV 何时被访问、计算与调度；空间维度关注 KV 放在哪里、如何迁移；结构维度关注 KV 如何表示、压缩、保留或淘汰。在此基础上，论文进一步分析不同行为之间的协同设计关系，以及它们与延迟、吞吐、显存、互连 I/O、能耗和质量退化之间的联系。 对于做 LLM serving、推理系统、长上下文、agent 基础设施和高吞吐部署的读者来说，这篇综述的价值在于把大量 KV cache 工作放进一个可操作的系统坐标系中：不是简单问“压缩多少 KV”，而是问“在什么时间、什么位置、以什么表示保留或迁移 KV，才能在 SLO、成本和质量之间取得更好的系统折中”。

1. Introduction / 引言

LLM 生成采用自回归范式，每个新 token 都依赖历史 token。若每一步都重新计算全部历史注意力，成本会非常高。因此，服务系统会保存此前 token 的 key 和 value 张量，让后续 decode 阶段直接复用，这就是 KV cache。 随着上下文窗口变长、并发请求增多、输出长度上升，KV cache 可能扩展到百万 token 级别。它不仅占据大量 GPU 显存，也会影响调度、批处理、预取、迁移、压缩、设备间通信和能耗。换句话说，KV cache 已经从模型内部的一个中间缓存，变成 LLM serving 基础设施中的一等对象。 本文把研究范围定义为 sKis：服务阶段运行、以 KV cache 为主要优化目标、旨在提升吞吐、延迟、显存、能耗等系统指标的方法。这个边界排除了三类相近但不同的方向：长上下文记忆增强、算子/内核层融合调度、训练时 KV 压缩或带 KV 复用的微调。 论文提出的主要视角是“系统行为”。相比按算法组件或压缩类型分类，系统行为更关注一个方法对 serving 系统做了什么：它是在改变执行顺序，还是改变数据放置，还是改变 KV 表示？这种视角更适合指导系统协同设计。

2. Foundations, Scope and Taxonomy / 基础、范围与分类

LLM 推理通常分为 prefill 和 decode 两个阶段。Prefill 处理初始提示并构建上下文 KV cache；decode 逐步生成后续 token，并持续读取和追加 KV cache。Prefill 更像大批量并行计算，decode 则更受内存访问、调度和小步迭代影响。

论文将 sKis 方法归纳为三个系统行为维度。 第一是时间行为，即 execution and scheduling。它关注 KV 数据什么时候被访问、计算、调度或隐藏延迟，包括 KV-centric scheduling、pipelining and overlapping、hardware-aware execution。 第二是空间行为，即 placement and migration。它关注 KV cache 放在哪里、如何在 GPU、CPU、SSD、不同 GPU 或异构计算设备之间移动，包括 memory hierarchy KV orchestration 和 compute device KV orchestration。 第三是结构行为，即 representation and retention。它关注 KV 以什么形式存在、如何压缩、如何选择保留或淘汰，包括 KV cache compression 和 KV cache retention management。

这个分类的好处在于，它把 KV cache 优化从单点技术扩展为系统设计空间。例如，一个方法可能既压缩 KV，又需要新的 kernel 支持；一个 offload 方法可能同时依赖预取、迁移和淘汰策略；一个调度方法可能通过 KV 复用提升吞吐，但也可能引入质量或尾延迟风险。

3. KV Execution and Scheduling / KV执行与调度

这一部分关注 KV cache 的时间行为，也就是如何在运行时安排 KV 的访问、计算和调度，使系统减少等待、提升吞吐并控制延迟。

缓存中心调度

KV-centric scheduling 将 KV 特征纳入调度决策。传统请求调度通常关注 batch size、队列长度或计算负载，而 KV 中心调度会进一步考虑 KV cache 的命中率、复用潜力、请求共享前缀、token 重要性和 attention 贡献。 在请求级别，系统可以优先调度具有高 KV 复用潜力的请求，以减少重复计算和缓存压力。在 token 级别，方法可以决定哪些 KV entry 参与注意力计算，从而降低有效上下文成本。在 kernel 级别，方法可以根据 query/KV 长度等特征调度 attention 工作负载。 这类方法直接影响平均延迟、尾延迟和吞吐，但难点是调度决策必须非常快，并且不能破坏服务公平性或 SLO。尤其在多租户或突发流量下，KV 复用与延迟控制之间存在明显张力。

流水化与重叠

Pipelining and overlapping 试图隐藏 KV 相关延迟。典型做法包括将计算与 I/O 重叠、将 prefill 和 decode 分阶段并行、在通信发生时执行其他可并行工作，或在 KV 迁移/预取过程中同时推进计算。 这类方法的核心不是减少 KV 本身，而是减少 KV 带来的等待时间。对于长上下文、跨设备迁移和异构内存层次尤其重要。它通常与空间行为耦合，因为只有当 KV 被放置在 CPU、SSD 或其他 GPU 上时，重叠 I/O 和计算才变得特别关键。

硬件感知执行

Hardware-aware execution 关注具体硬件拓扑、内存层次和 kernel 行为。包括 disaggregated inference、compute offloading、attention kernel 调度、异构设备协同等。 这类方法要求系统理解 HBM、L2 cache、CPU 内存、SSD、NVLink、PCIe、CXL 等不同层级的带宽和延迟。它的收益可能很高，但实现成本也更高，因为需要 runtime、kernel 和调度器协同。

4. KV Placement and Migration / KV放置与迁移

空间行为回答的是：KV cache 应该放在哪里？什么时候迁移？如何在显存不足时保持吞吐和延迟？

内存层次编排

Memory hierarchy KV orchestration 将 KV 放置在 GPU、CPU、SSD 等不同内存层级中。GPU HBM 快但昂贵且容量有限；CPU 内存容量更大但访问慢；SSD 可进一步扩容但延迟更高。系统需要判断哪些 KV 应保留在 GPU，哪些可以下放，哪些需要提前预取。 代表思路包括基于成本模型的放置、基于 attention 或复用信号的重要性估计、基于队列状态和内存压力的在线 offload/reload。其关键挑战是预测未来是否会再次使用某段 KV，以及迁移成本是否会抵消显存节省。

计算设备编排

Compute device KV orchestration 关注 KV 在多个计算设备之间的分布和迁移。例如在 prefill/decode 分离、跨 GPU 集群、异构加速器或远程 KV 传输场景中，KV 不只是存在内存层级中，还会跨计算节点和设备流动。 这类方法直接影响互连 I/O 和设备利用率。论文指出，HAE 与 CDO 是最强的协同设计模式之一：硬件感知执行通常需要与跨设备 KV 放置和传输结合，才能发挥整体收益。

5. KV Representation and Retention / KV表示与保留

结构行为回答的是：KV cache 应该以什么形式存在？哪些 KV 应该被压缩、合并、低秩近似、保留、复用或淘汰？

缓存压缩

KV cache compression 是当前研究最密集的方向之一，目标是直接降低 KV 内存占用。常见方法包括量化、低秩近似和结构压缩。 量化将浮点 KV 张量转成低精度格式，如 8-bit、4-bit 或混合精度。实际系统中常见问题是 key 和 value 的分布不同、不同通道或 token 的敏感性不同、outlier 对精度影响很大。因此，不少方法采用非对称量化、混合 bitwidth 或专门的 outlier 处理。 低秩近似尝试利用 KV 张量的冗余结构，用更低秩表示减少存储和计算。结构压缩则可能合并 token、压缩注意力结构或利用层间/头间冗余。 论文强调，KVCC 虽然流行，但常常相对孤立。压缩并不自动带来端到端收益，因为量化/反量化、低秩更新、压缩索引和 kernel 支持都会引入额外开销。KVCC 若不能与执行、迁移和 runtime 控制协同，可能只是在显存指标上好看，而未必改善真实 serving。

缓存保留管理

KV cache retention management 关注哪些 KV 应被保留、淘汰、复用或重新分配。常见策略包括 allocation and reuse、eviction。 Allocation and reuse 会识别共享前缀、重复上下文或可复用 KV，从而避免重新计算。Eviction 则在显存压力下决定删除哪些 token 的 KV。问题在于，KV 的重要性不是静态的：某些早期 token 可能对后续生成仍重要，某些最近 token 未必有用；不同任务、上下文和模型层的注意力模式也不同。 因此，保留管理本质上是质量、显存、延迟之间的动态折中。过度淘汰会引发质量下降，过度保留会压垮显存，错误预取又会浪费 I/O。

6. Observations and Open Challenges / 观察与开放挑战

论文第六部分从两个角度总结研究格局：行为-目标矩阵和行为-行为协同网络。前者分析不同行为对平均延迟、尾延迟、吞吐、GPU 显存、互连 I/O、能耗和质量影响；后者分析文献中哪些行为经常被联合设计。

关键观察

第一，结构类工作最密集，并且主要围绕显存节省展开。KV 压缩和保留管理直接作用于内存占用，因此研究密度最高。 第二，时间行为最直接影响延迟和吞吐。调度、流水化和硬件感知执行可以减少调度停顿、流水线气泡和设备利用不足。 第三，空间方法主要针对互连 I/O，且常与流水化重叠结合。KV transfer、offload、prefetch 若不能与计算重叠，很容易成为新瓶颈。 第四，能耗仍然研究不足。很多方法降低显存或计算强度，理论上应影响能耗，但多数工作并未系统报告或优化 power/energy。 第五，质量损失是普遍问题。时间方法可能导致请求处理不一致，空间方法可能遗漏 KV，结构方法可能降低 KV 精度。实际系统必须让退化可度量、可约束、可归因。 第六，HAE-CDO 是最强协同模式。跨设备编排往往需要硬件感知执行共同支持，才能在异构拓扑中获得真实收益。 第七，KVCC 虽然热门，但协同不足。压缩应与 kernel、迁移、调度和 SLO 控制结合，而不是只给出离线压缩率。

开放挑战

论文总结了多个未来方向。第一是 SLO 驱动的尾延迟控制。长上下文和突发请求会让 KV 生成、迁移和压缩互相干扰，系统需要标准化 preemption、降级和尾部行为语义。 第二是能耗感知 sKis。未来系统应把 power profiling 纳入 runtime 决策，在能耗、延迟、质量之间联合优化。 第三是可信质量度量。除了平均任务分数，系统应报告最坏情况、质量下界和 stress workload 下的退化模式，让质量风险与具体系统行为对应起来。 第四是异构拓扑可迁移性。当前很多策略面向特定 GPU 集群或单租户设置，未来需要适配 NVLink、NVSwitch、PCIe、CXL 和多租户环境。 第五是跨行为联合优化。例如在同一预算下共同决定 eviction、offload、prefetch、compression bitwidth 和 reuse 策略，而不是单独优化其中一项。

7. Conclusion / 结论

这篇综述将 LLM serving 中的 KV cache 优化系统化为 sKis，并提出了清晰的三维行为分类：时间上的执行与调度、空间上的放置与迁移、结构上的表示与保留。这个框架把大量看似分散的方法放到同一张系统地图中，有助于理解它们分别作用于哪些 bottleneck，又会影响哪些服务指标。 论文最重要的启发是：KV cache 优化不是单一压缩问题，而是系统级协同设计问题。真正高效的 LLM serving 需要同时考虑何时访问 KV、在哪里存放 KV、如何表示 KV、哪些 KV 值得保留，以及这些决策如何在 SLO、显存、互连、能耗和质量之间取得平衡。 随着长上下文、agent、多模态和多租户 LLM 服务持续增长，KV cache 将继续成为推理基础设施的核心资源。未来 sKis 的关键，不只是提出更高压缩率或更快 kernel，而是构建可观测、可协同、可迁移、可验证的 KV cache runtime。