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=1S=1024L=32H=32D=128,FP16:

KV Cache Size=2×1×1024×32×32×128×2102430.5 GB

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

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

KV Cache Size=2×1×131072×64×40×128×210243160 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