大模型推理 KV 缓存优化管理深度调研报告

调研主题： 大模型推理 KV 缓存优化管理 所属域： 大模型框架 调研日期： 2026-03-11

第一部分：概念剖析

1. 定义澄清

通行定义

KV 缓存（Key-Value Cache）是大语言模型（LLM）推理过程中用于存储 Transformer 注意力机制中间计算结果的数据结构。在自回归生成过程中，为了避免重复计算已生成 token 的 Key 和 Value 矩阵，系统将这些中间结果缓存起来供后续 token 生成时复用，从而将推理复杂度从 O(n²) 降低到 O(n)。

KV 缓存优化管理指的是通过内存管理算法、数据压缩技术、调度策略等手段，在保证推理正确性的前提下，最小化 KV 缓存的内存占用、最大化 GPU 利用率、提升系统吞吐量和降低延迟的技术体系。

常见误解

边界辨析

2. 核心架构

┌────────────────────────────────────────────────────────────────┐
│                    KV 缓存管理系统架构                          │
├────────────────────────────────────────────────────────────────┤
│                                                                │
│   ┌─────────┐    ┌──────────────┐    ┌─────────────────────┐  │
│   │ 请求调度 │ →  │ KV 缓存管理器 │ →  │ 注意力计算引擎       │  │
│   │ Scheduler│    │ Cache Manager│    │ Attention Engine    │  │
│   └────┬────┘    └──────┬───────┘    └──────────┬──────────┘  │
│        │                │                       │              │
│        ▼                ▼                       ▼              │
│   ┌─────────┐    ┌──────────────┐    ┌─────────────────────┐  │
│   │ 批处理  │    │  物理内存块   │    │   GPU HBM 显存      │  │
│   │ Batcher │    │  Physical    │    │   Memory Pool       │  │
│   │         │    │  Block Pool  │    │                     │  │
│   └─────────┘    └──────────────┘    └─────────────────────┘  │
│         │                │                       │              │
│         └────────────────┼───────────────────────┘              │
│                          ▼                                       │
│              ┌───────────────────────┐                          │
│              │  元数据管理 (Metadata) │                          │
│              │  - 块表 Block Table    │                          │
│              │  - 引用计数 Ref Count  │                          │
│              │  - 序列映射 Seq Map    │                          │
│              └───────────────────────┘                          │
│                          │                                       │
│         ┌────────────────┼────────────────┐                     │
│         ▼                ▼                ▼                     │
│   ┌───────────┐   ┌───────────┐   ┌───────────┐                │
│   │ 预填充    │   │ 解码阶段  │   │ 驱逐策略  │                │
│   │ Prefill  │   │ Decode    │   │ Eviction  │                │
│   └───────────┘   └───────────┘   └───────────┘                │
│                                                                │
└────────────────────────────────────────────────────────────────┘

数据流向：
1. 请求进入 → 调度器分配 batch 位置
2. 预填充阶段 → 为 prompt 分配连续/分页 KV 块
3. 解码阶段 → 逐 token 追加 KV 块，查表获取历史
4. 内存不足 → 触发驱逐/换出策略

组件职责说明：

3. 数学形式化

公式 1：KV 缓存内存占用模型

其中：

• $B$：batch size（并发请求数）
• $L$：序列长度（prompt + generated）
• $H$：注意力头数
• $D_{kv}$：每个头的 KV 维度
• $\text{precision\_bytes}$：精度字节数（FP16=2, INT8=1, FP8=1）

解释： KV 缓存内存占用由 batch size、序列长度、模型结构共同决定，是推理系统设计的首要约束。

公式 2：PagedAttention 地址映射

其中：

• $S$：块大小（block size，通常 16-256 tokens）
• $\text{BlockTable}$：逻辑序列到物理块的映射表

解释： PagedAttention 将连续的逻辑序列切分为固定大小的物理块，通过块表实现非连续物理存储的逻辑连续访问。

公式 3：内存利用率优化目标

其中：

• $\pi$：调度策略
• $\eta$：GPU 计算单元利用率
• $T_i^{\text{compute}}$：有效计算时间
• $M_{\text{GPU}}$：可用 GPU 显存

解释： KV 缓存管理的目标是在显存约束下最大化 GPU 利用率，通过智能调度让更多请求并发执行。

公式 4：Cache Eviction 决策函数

解释： 驱逐决策综合考量块的最近使用时间、访问频率和注意力重要性得分，优先驱逐低价值块。

4. 实现逻辑

class KVCacheManager:
    """
    KV 缓存管理器核心类
    职责：统一管理 GPU 显存中的 KV 缓存块，支持分页分配、动态扩展、智能驱逐
    """
    def __init__(self, config):
        # 物理块池：预分配的固定大小 GPU 内存块
        self.num_blocks = config.num_blocks
        self.block_size = config.block_size  # 每块 token 数
        self.gpu_blocks = self._allocate_gpu_blocks()

        # 块表：sequence_id -> layer -> [logical_block_idx -> physical_block_id]
        self.block_tables = defaultdict(lambda: defaultdict(dict))

        # 引用计数：跟踪每个物理块被多少序列引用（用于 copy-on-write）
        self.ref_counts = np.zeros(self.num_blocks, dtype=int)

        # 空闲块管理
        self.free_block_queue = deque(range(self.num_blocks))

    def allocate_blocks(self, seq_id, num_tokens, layer):
        """
        为指定序列分配 KV 缓存块
        核心逻辑：按需分配物理块，建立逻辑 - 物理映射
        """
        num_blocks_needed = ceil(num_tokens / self.block_size)
        physical_blocks = []

        for _ in range(num_blocks_needed):
            if not self.free_block_queue:
                # 内存不足：触发驱逐
                self._evict_blocks()

            physical_id = self.free_block_queue.popleft()
            physical_blocks.append(physical_id)

        # 建立逻辑到物理的映射
        logical_idx = len(self.block_tables[seq_id][layer])
        for phys_id in physical_blocks:
            self.block_tables[seq_id][layer][logical_idx] = phys_id
            self.ref_counts[phys_id] = 1

        return physical_blocks

    def get_kv_cache(self, seq_id, layer, token_range):
        """
        获取指定 token 范围的 KV 缓存
        核心逻辑：通过块表查找物理块，计算块内偏移
        """
        start_token, end_token = token_range
        start_block = start_token // self.block_size
        end_block = (end_token - 1) // self.block_size

        kv_chunks = []
        for logical_idx in range(start_block, end_block + 1):
            physical_id = self.block_tables[seq_id][layer][logical_idx]
            block_start = max(0, start_token - logical_idx * self.block_size)
            block_end = min(self.block_size, end_token - logical_idx * self.block_size)

            kv_chunk = self._read_from_gpu(physical_id, block_start, block_end)
            kv_chunks.append(kv_chunk)

        return torch.cat(kv_chunks, dim=0)

    def append_token(self, seq_id, layer, new_kv):
        """
        解码阶段追加新 token 的 KV
        核心逻辑：检查当前块是否已满，必要时分配新块
        """
        current_tokens = self._get_token_count(seq_id, layer)
        current_block_idx = current_tokens // self.block_size
        offset_in_block = current_tokens % self.block_size

        # 检查是否需要新块
        if offset_in_block == 0:
            self.allocate_blocks(seq_id, 1, layer)

        physical_id = self.block_tables[seq_id][layer][current_block_idx]
        self._write_to_gpu(physical_id, offset_in_block, new_kv)

    def _evict_blocks(self):
        """
        驱逐策略：基于 LRU + 注意力重要性
        核心逻辑：选择最少使用的块，换出到 CPU 或丢弃
        """
        # 计算每个块的驱逐分数
        eviction_scores = []
        for block_id in range(self.num_blocks):
            if self.ref_counts[block_id] > 0:
                score = self._compute_eviction_score(block_id)
                eviction_scores.append((score, block_id))

        # 排序并驱逐最低分的块
        eviction_scores.sort(key=lambda x: x[0])
        blocks_to_evict = eviction_scores[:self.num_blocks // 4]

        for _, block_id in blocks_to_evict:
            self._evict_single_block(block_id)
            self.free_block_queue.append(block_id)

    def _compute_eviction_score(self, block_id):
        """
        计算块的驱逐分数（分数越高越应该保留）
        """
        recency = time.time() - self.last_access[block_id]
        frequency = self.access_count[block_id]
        importance = self.attention_score[block_id]

        return 0.5 / (recency + 1) + 0.3 * frequency + 0.2 * importance

5. 性能指标

6. 扩展性与安全性

水平扩展

垂直扩展

安全考量

第二部分：行业情报

1. GitHub 热门项目（15+ 个）

2. 关键论文（12 篇）

3. 系统化技术博客（10 篇）

4. 技术演进时间线

2017 ─┬─ Transformer 论文发布，注意力机制成为主流
      │  影响：KV 缓存概念的雏形，但早期未显式优化

2020 ─┼─ GPT-3 发布，大模型推理延迟问题凸显
      │  影响：工业界开始关注推理优化，KV 缓存管理萌芽

2022 ─┼─ ChatGPT 引爆大模型应用，推理成本成为瓶颈
      │  影响：学术界和工业界投入大量资源优化推理效率

2023 ─┼─ PagedAttention 论文发表 (SOSP'23)，vLLM 开源
      │  影响：革命性突破，显存利用率从 50% 提升至 90%+
      │
      ├─ FlashAttention-2 发布
      │  影响：进一步优化注意力计算，与 KV 缓存管理协同

2024 ─┼─ RadixAttention 提出，支持跨请求 KV 缓存共享
      │  影响：SGLang 框架实现多轮对话和 few-shot 高效复用
      │
      ├─ H2O、SnapKV 等动态驱逐策略涌现
      │  影响：长上下文场景内存占用大幅降低
      │
      ├─ RetrievalAttention 支持百万级上下文
      │  影响：突破显存容量限制，实现超长序列推理

2025 ─┼─ Mooncake 分布式 KV 缓存池架构成熟
      │  影响：多节点推理场景性能显著提升
      │
      ├─ 推测性 KV 生成技术 (InfiniGen) 实用化
      │  影响：进一步减少冗余计算

2026 ─┴─ 当前状态：KV 缓存管理成为大模型推理框架的标准组件
         影响：PagedAttention 成为默认选项，动态驱逐、分布式
               缓存池、长上下文优化成为研究热点

第三部分：方案对比

1. 历史发展时间线

2018 ─┬─ 连续内存分配 → 简单但碎片严重，利用率<50%
      │
2021 ─┼─ 动态分配器 → 减少碎片但仍存在外部碎片问题
      │
2023 ─┼─ PagedAttention → 分页管理，利用率提升至 90%+
      │
2024 ─┼─ RadixAttention → 支持前缀共享，减少重复存储
      │
2024 ─┼─ 动态驱逐 (H2O/SnapKV) → 长上下文场景优化
      │
2025 ─┼─ 分布式 KV 缓存池 (Mooncake) → 跨节点共享
      │
2026 ─┴─ 当前状态：多种技术融合，场景化优化成为主流

2. 六种方案横向对比

3. 技术细节对比

*注：动态驱逐和检索式加载的显存效率指有效存储比例，实际可支持更长序列

4. 选型建议

5. 成本分析（以 70B 模型为例）

假设使用 NVIDIA A100 80GB GPU，运行 Llama-3-70B 模型（FP16）：

月度成本估算（AWS p4d.24xlarge，$32.77/小时）：

• 8×A100 实例：~$24,000/月
• 使用 PagedAttention 后，同等吞吐可减少约 50% 实例数
• 节省成本：~$12,000/月

第四部分：精华整合

1. The One 公式

用一个"悖论式等式"概括 KV 缓存优化管理的核心本质：

这个公式揭示了 KV 缓存优化的两大核心：通过分页管理消除空间浪费，通过智能调度消除时间浪费。

2. 一句话解释

KV 缓存优化就像是给大模型推理配备了一个"智能图书馆"：不再为每个读者（请求）预留整排书架（连续内存），而是按需分配书架格子（分页），记录每本书的位置（块表），并在书架满时智能清理不重要的书（驱逐），让更多读者能同时阅读，大幅提升图书馆的吞吐效率。

3. 核心架构图

┌─────────────────────────────────────────────────────────────────┐
│                     KV 缓存优化管理                              │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   请求 → [调度器] → [PagedAttention] → [注意力计算] → 响应      │
│            │            │                    │                  │
│            ▼            ▼                    ▼                  │
│       批处理优化    分页块表管理        GPU 核计算               │
│       Batch Size   Logical→Physical     FlashAttention          │
│       Priority     Free List                                    │
│                                                                 │
│   ───────────────────── 关键指标 ─────────────────────          │
│                                                                 │
│   显存利用率: 90%+    │    吞吐提升: 2-4x    │    延迟: <50ms   │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

4. STAR 总结

5. 理解确认问题

问题： 为什么 PagedAttention 能够显著提升显存利用率，而传统的连续内存分配方式利用率较低？请从内存分配的角度解释其核心机制。

参考答案： 连续内存分配为每个请求预先分配一整块连续空间，大小基于最大可能序列长度。由于实际序列长度分布不均，导致大量预分配空间闲置（内部碎片），且无法被其他请求使用。同时，请求结束后释放的空间大小不一，难以有效复用（外部碎片）。PagedAttention 将逻辑序列切分为固定大小的物理块，按需分配，用多少分多少，消除了内部碎片；所有物理块大小相同，可以任意复用，消除了外部碎片。此外，块表机制允许逻辑上连续的序列在物理上非连续存储，进一步提升了内存调度灵活性。

附录：关键术语表

报告生成日期： 2026-03-11 总字数： 约 7,500 字