跳到主要内容

推理侧 — KV 管理

核心要点：

  • 推理时长上下文 KV 的核心矛盾是显存 + 复用：放得下、读得快、相同前缀不重算
  • PagedAttention：把 KV 按页管理，降碎片、支持复用，是 vLLM 等推理引擎的事实标准
  • KV 量化：FP8 / INT4 / INT2 把 KV 体积再压 2-8 倍，工业有损但可接受
  • KV 驱逐：H2O / StreamingLLM / SnapKV —— 只保留"重要 token"的 KV，把长上下文 KV 占用压成常数
  • KV offload：把不活跃 KV 沉到 CPU / NVMe，靠互联带宽换显存容量
  • Prefix caching：相同前缀（系统 prompt、few-shot）的 KV 一次算多次用，对 RAG / agent 至关重要

本文回答"推理时长上下文怎么放得下、跑得快"的算法层问题。区别于 05-KV 架构压缩（架构层，训练时定型），本文讲推理时的动态压缩与管理；区别于 interconnect / KV 跨节点传输 等系统视角，本文不涉及跨节点通信。

推理 KV 管理的四类问题​

四类问题见 ，每类对应一类技术。

问题表现解药
显存碎片不同请求 KV 大小不一，预分配最大长度浪费PagedAttention
绝对显存不够长 KV 撞 HBM 上限量化、驱逐、offload
重复算 KV多请求共享相同前缀（系统 prompt / few-shot）Prefix caching
过期 KV长 reasoning / 长会话累积冗余 KV驱逐策略（H2O 等）

@tbl-longctx-kvmgmt-problems 推理 KV 管理的四类核心问题

下面分别展开四类技术。

PagedAttention — 像操作系统管内存​

Kwon et al., 2023 的 vLLM 原始论文[1]把 OS 的 paging 思想引入 KV 管理：

设计含义
KV 按块 (block) 分配每块固定大小（如 16 token），不再预分配整段序列
块表 (block table)每个序列维护"逻辑块号 → 物理块号"映射
共享块多个序列共用同一物理块（用于 prefix caching）
复制写时修改共享块时复制（COW）出独立块

@tbl-longctx-kvmgmt-paged PagedAttention 的核心机制

收益：

  • 碎片率从 60-80% 降到 < 5%：原本"预分配最大长度"的浪费基本消除
  • 吞吐 2-4 倍提升：同样显存能容纳更多并发请求
  • 天然支持 prefix caching、beam search、并行采样

业界采用：vLLM、SGLang、TensorRT-LLM、TGI 等所有主流推理引擎都内置 PagedAttention 或等价机制。PagedAttention 是当前推理引擎的事实基础。

系统视角的 PagedAttention（块分配、调度、跨节点同步）详见 interconnect / KV 跨节点传输瓶颈。本文只讲算法机制。

KV 量化 — 用精度换显存​

把 KV 从 FP16/BF16（2 bytes/value）降到更低精度：

精度bytes/valueKV 体积（相对 BF16）主要风险
FP16 / BF1621×baseline
FP810.5×精度损失轻微，工业广泛采用
INT40.50.25×短序列可控，长上下文需要校准
INT2 (KIVI)0.250.125×需要 per-channel + per-token 非对称量化

@tbl-longctx-kvmgmt-quant-bits KV 量化精度档位

KIVI 等代表方法​

KIVI（Liu et al., 2024）[2]提出非对称 2-bit KV 量化，无需微调：

  • Key 按 channel 维量化：观察到 Key 在 channel 维度更"窄"
  • Value 按 token 维量化：观察到 Value 在 token 维度更"窄"
  • 整体在 LLaMA / Mistral 上质量损失 < 1%

类似方法：KVQuant、SmoothQuant 系列、QServe 等。FP8 已是工业默认，INT4 / INT2 是研究和高压缩部署的选择。

量化与 PagedAttention 的关系​

量化降"单 token KV bytes"，PagedAttention 降"碎片"——两者正交，可叠加。vLLM 的 FP8 KV 模式就是 PagedAttention + FP8 量化的组合。

KV 驱逐 — 只保留"重要"的 KV​

如果承认 KV 不需要全保留，可以把长上下文 KV 压成常数。

H2O — Heavy Hitter Oracle​

H2O（Zhang et al., 2023, NeurIPS）[3]观察到一个现象：

少量 token 承担了 attention 的多数权重——称为 heavy hitters。

驱逐策略：在每个 step 维护一个累计 attention 得分，删除累计得分最低的 KV。保留"最近 token + heavy hitters"：

类别留下删掉
最近 $w$ 个 token✓—
累计高得分 token（heavy hitters）✓—
其他—✓

@tbl-longctx-kvmgmt-h2o H2O 的两类保留策略

效果：保留 KV 大小约 20-30%，文本生成质量基本无损。

StreamingLLM — Attention Sink​

Xiao et al., 2023（ICLR'24）[4]提出更激进的策略，灵感来自一个反直觉观察：

句首的几个 token 永远拿到大量 attention，即使它们与当前内容无关——称为 attention sink。

物理解释：softmax 必须把概率"分配出去"，找不到匹配时模型把权重倾倒在固定位置。

StreamingLLM 设计：始终保留句首 4 个 token + 最近 $w$ 个 token，完全丢弃中段。配合改良的位置编码处理（位置 ID 重映射），可以无限延伸生成而不退化。

保留大小
句首 sink token固定 4 个
最近 token固定窗口 $w$（如 4K）
总 KV常数

@tbl-longctx-kvmgmt-streamingllm StreamingLLM 的 KV 保留策略

应用场景：长会话 / 流式输出（如客服 bot 累计数十万 token 历史），不需要精确回忆早期内容，只需流畅延续。

局限：精确检索任务退化​

驱逐策略都有共同限制：遗忘的信息找不回来。若任务需要"精确回忆远距离 token"（如 NIAH），驱逐策略会失效。所以驱逐适合长生成 / 长会话，不适合长精确检索。

SnapKV / 类似工作​

SnapKV（Li et al., 2024）[5]改进 H2O：在 prefill 完成时一次性选好要保留的 KV，避免每步动态计算。性能 / 质量平衡更好。

KV Offload — 用互联带宽换显存容量​

把不活跃 KV 沉到 CPU 内存或 NVMe，按需上传：

存储层带宽容量
HBM3-8 TB/s80-192 GiB / 卡（H100 80 / H200 141 / B200 / GB200 192）
CPU DRAM （via NVLink-C2C 或 PCIe）数百 GB/sTB 级
NVMe SSD数 GB/s数十 TB

@tbl-longctx-kvmgmt-offload-tiers KV offload 的三层存储

典型方案：

  • Hot KV 在 HBM：当前活跃序列
  • Warm KV 在 CPU：暂停或低频请求
  • Cold KV 在 NVMe：历史会话归档

关键约束：上传延迟。CPU → GPU 通过 NVLink-C2C（Grace-Hopper）或 PCIe 5（H100/A100），实际可用 50-100 GB/s 量级。1 GiB KV 上传需 10-20 ms，可能成为 decode 单 token 延迟瓶颈。

业界采用：vLLM、SGLang、LMCache 等都支持 KV offload，多用于长会话 / 多租户场景。

NPU 直通 CMS（华为云 AMS）​

2026-06 华为云 INSPIRE 大会发布的 AMS（Agentic Memory Storage）方案引入了一条新的硬件 offload 路径：KV Cache 从 NPU 直接写入 CMS（Context Memory Storage）专用硬件，不经 CPU 中转[6]。传统 offload 路径是 NPU → CPU DRAM → NVMe，每次数据搬移都经过 PCIe 和 CPU 内存控制器；NPU→CMS 直通把这跳省了，理论上延迟更低。

AMS 在 CMS 上支持 KV Cache 分层池化（hot/warm/cold），与上表的三层 offload 对应——但 CMS 替代了 CPU DRAM 和 NVMe 两层，以专用硬件提供 PB 级容量。截至 2026-06 为厂商规格，未出货、无实测，带宽和延迟数字未公开。

AMS 作为记忆系统的完整对标（与 Mem0/Letta/A-Mem/Hindsight 对比）见 3.7 生产记忆系统对标。

KV 在跨节点传输（如 PD 分离的 prefill → decode 拷贝）见 interconnect / KV 跨节点传输瓶颈。

Prefix Caching — 公共前缀的 KV 复用​

现象与价值​

很多场景多请求共享相同前缀：

场景共享前缀长度
系统 prompt（"You are a helpful assistant..."）固定字符串$10^2 \text{-} 10^3$ token
Few-shot prompt$K$ 个示例$10^3 \text{-} 10^4$ token
RAG 检索结果多个文档串接$10^4 \text{-} 10^5$ token
Agent 系统多步调用同一 system + tool 描述$10^3 \text{-} 10^5$ token

@tbl-longctx-kvmgmt-prefix-sharing Prefix caching 适用场景

收益：相同前缀的 KV 只算一次，后续请求直接复用——prefill 时间从 $O(n)$ 降到 $O(\text{增量}_n)$，长前缀场景吞吐数倍提升。

数据结构​

方法数据结构代表实现
哈希块整段前缀哈希为 key 找 KVvLLM Prefix Caching
RadixAttention前缀树（trie）按 token 共享分支SGLang
LRU 替换按访问时间淘汰 KV普遍

@tbl-longctx-kvmgmt-prefix-impl Prefix caching 的实现方法

RadixAttention[7] 是当前最灵活的方案：把前缀按 token 维度组织成 trie，多个请求自然在 trie 上共享分支，命中粒度细。

与系统调度的接力​

Prefix caching 的算法机制在本文；调度层面（请求路由到有 hot KV 的实例、跨节点 KV 复用）见 interconnect / Cache-aware 调度 和 Mooncake。

四类技术的组合实践​

不同技术解决不同问题，工业部署通常同时启用多个：

部署目标必选可选
通用高吞吐推理PagedAttentionFP8 量化、prefix caching
极长上下文（1M+）PagedAttention + 量化 + 上下文并行offload、驱逐（生成型任务）
长会话 / 流式PagedAttention + StreamingLLMFP8 量化
多租户高并发PagedAttention + prefix caching + offload量化、驱逐
Agent / RAGPagedAttention + prefix caching量化

@tbl-longctx-kvmgmt-combinations 四类 KV 管理技术的组合实践

Takeaway​

知识点核心结论
PagedAttention把 KV 按块管理，碎片率从 60-80% 降到 < 5%，吞吐提升 2-4 倍，是主流推理引擎的事实基础。
KV 量化FP8 / INT4 / INT2 把单 token KV 体积压 2-8 倍，FP8 已是工业默认，与 PagedAttention 正交可叠加。
KV 驱逐H2O / StreamingLLM / SnapKV 只保留重要 token（最近窗口 + heavy hitter / attention sink），把长上下文 KV 压成常数，但精确检索任务会退化。
KV offload把不活跃 KV 沉到 CPU / NVMe，用互联带宽换显存容量，上传延迟是主要约束。
Prefix caching相同前缀的 KV 算一次多次复用，prefill 时间从 $O(n)$ 降到 $O(\text{增量}_n)$，RadixAttention 是最灵活方案。

@tbl-longctx-kvmgmt-takeaway 全文要点

参考资料​

  1. Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention, 2023. https://arxiv.org/abs/2309.06180
  2. Liu et al., KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache, 2024. https://arxiv.org/abs/2402.02750
  3. Zhang et al., H2O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models, 2023. https://arxiv.org/abs/2306.14048
  4. Xiao et al., Efficient Streaming Language Models with Attention Sinks (StreamingLLM), 2023. https://arxiv.org/abs/2309.17453
  5. Li et al., SnapKV: LLM Knows What You are Looking for Before Generation, 2024. https://arxiv.org/abs/2404.14469
  6. 华为云，华为云发布Agentic AI系列新品打造智能时代"硅基黑土地"，2026-06-05. https://www.huaweicloud.com/news/2026/20260605100619686.html
  7. Zheng et al., SGLang: Efficient Execution of Structured Language Model Programs （含 RadixAttention），2023. https://arxiv.org/abs/2312.07104