Skip to content

KV Cache Offloading 技术 ​

随着上下文窗口不断扩大,KV Cache 的显存占用已成为大语言模型推理的核心瓶颈。KV Cache Offloading 通过将非活跃 Cache 数据迁移到成本更低的存储层(CPU DRAM、NVMe SSD 或远程对象存储),在保留复用能力的同时释放 GPU 资源。

1. 为什么需要 Offloading ​

1.1 KV Cache 的重要性 ​

KV Cache 缓存了输入序列中每个 Token 的 Key 与 Value 矩阵,避免生成每个新 Token 时重复计算整个上下文,是推理加速的关键机制。

1.2 KV Cache 的瓶颈 ​

  • 线性增长的显存消耗:KV Cache 大小与序列长度成正比。长文本场景下单请求可达数十 GB。
  • 闲置资源浪费:用户输入停顿、多轮对话间隔期间,KV Cache 仍占用显存,无法服务其他活跃请求。

这些因素限制了系统的并发用户数与整体吞吐量。

2. Offloading 的工作机制 ​

  • 卸载(Offload):将非活跃或低频访问的 KV Cache 从 GPU HBM 移动到 CPU RAM、本地 SSD 或远程存储。
  • 按需加载(Reload):当请求恢复或需要复用上下文时,将数据重新加载回 GPU。

该机制避免了昂贵的重新计算,同时让 GPU 专注于当前活跃计算任务。

3. 适用场景 ​

场景说明
长上下文推理超长上下文模型部署且显存容易溢出时
多轮交互与上下文共享多用户或 Agent 跨会话访问相同基础内容
资源受限环境预算限制无法扩容 GPU,或需要优化基础设施成本
分布式推理大规模分布式 Worker 上 GPU 资源相对稀缺
间歇性工作负载会话存在明显空闲,长期占用显存极度浪费

4. 核心优势与权衡 ​

4.1 优势 ​

  1. 提升资源利用率:腾出显存以服务更多并发用户或更长序列。
  2. 降低计算成本:用廉价 CPU 内存或磁盘替代昂贵 HBM,减少对高端 GPU 的过度依赖。
  3. 降低延迟:相比从头重算 KV Cache,从 CPU / 磁盘加载通常更快。NVIDIA 报告显示,对于长输入序列,Offloading 可将 TTFT 降低高达 14 倍。

4.2 权衡 ​

性能高度依赖目标存储层的速度:

  • 若存储介质(如机械硬盘)读写过慢,加载时间可能超过重新计算。
  • 关键原则:确保 数据传输成本 < 重新计算成本。

5. KV Cache 显存计算 ​

估算 KV Cache 显存占用的公式:

KV Cache Size (GB)=2×B×S×L×H×D×Pbyte10243

参数说明:

  • 2:同时存储 Key 和 Value。
  • B:Batch Size。
  • S:序列长度。
  • L:Transformer 层数。
  • H:注意力头数。
  • D:注意力头维度。
  • Pbyte:每个元素的字节数(FP16 为 2,FP32 为 4)。

若已知 Hidden Size,通常 H×D=Hidden Size。

5.1 示例 1:Llama-2-7B ​

B=1,S=1024,L=32,H=32,D=128,FP16:

KV Cache Size=2×1×1024×32×32×128×210243≈0.5 GB

5.2 示例 2:Qwen2.5-32B,128K 上下文 ​

B=1,S=131072,L=64,H=40,D=128,FP16:

KV Cache Size=2×1×131072×64×40×128×210243≈160 GB

单请求即可达到 160 GB,充分说明 Offloading 在长上下文场景中的必要性。

6. 实践方案:LMCache ​

LMCache 是专为 LLM 服务设计的缓存扩展引擎,支持将 KV Cache 分层存储(GPU → CPU DRAM → 本地磁盘),并跨引擎实例复用缓存。

集成现状:

  • vLLM:支持 CPU Offloading 与请求间 Cache 共享,实现存算分离的 Prefill-Decode 解耦。
  • KServe:利用 LMCache 降低成本并保障大规模服务下的 SLO。
  • llm-d:通过 LMCache 将数据卸载到网络磁盘等廉价存储。

在多项基准测试中,结合 LMCache 与 vLLM 可实现 3–10 倍 的延迟降低。

参考 ​

Maintained by Robin