📚 课程目录第3章缓存机制概述

3. 缓存机制概述：KV Cache原理、缓存命中率、缓存与吞吐量的关系

3.1 为什么需要KV Cache：从自回归解码说起

大语言模型（LLM）在推理时采用自回归解码方式：每生成一个token，都要把已生成的全部token作为输入，重新计算一次前向传播。如果不做任何缓存，第N次解码时，模型需要重新计算前N-1个token的Key矩阵和Value矩阵——而这些计算结果与第N次解码时完全相同，属于典型的重复计算。

KV Cache的核心思想非常直接：把历史token的Key和Value矩阵保存在显存中，后续解码只计算新token的Key和Value，并与缓存拼接后参与注意力计算。这样，每次解码的计算量从“处理全部历史token”降为“仅处理最新token”，大幅减少浮点运算量（FLOPs）。

核心公式：在标准多头注意力中，第t步解码时，若不使用KV Cache，需要计算Q、K、V三个矩阵，其中K和V的维度为 [t, num_heads, head_dim]；使用KV Cache后，只需计算新token对应的K_new和V_new，维度为 [1, num_heads, head_dim]，再与缓存拼接。

# 伪代码对比：无缓存 vs 有缓存
# 无KV Cache（每次全量计算）
for t in range(seq_len):
    q, k, v = model(input_ids[:t+1])  # 重复计算前t个token的K、V
    output = attention(q, k, v)

# 有KV Cache
cache = None
for t in range(seq_len):
    q, k, v = model(input_ids[t:t+1], past_key_values=cache)
    # 只计算新token的K、V，历史K、V从cache中读取
    output = attention(q, k, v)
    cache = update(cache, k, v)

KV Cache的代价是显存占用。每个请求的缓存大小约为：2 × num_layers × num_heads × head_dim × seq_len × dtype_size（因子2对应K和V两组矩阵）。以Llama-2-7B为例，单请求生成1024个token时，KV Cache约占用 2 × 32 × 32 × 128 × 1024 × 2字节 ≈ 512MB。因此，KV Cache管理直接决定了推理服务的并发上限。

3.2 缓存命中率：衡量KV Cache复用效率的关键指标

在vLLM等推理框架中，KV Cache不仅服务于单个请求的增量解码，还可以通过PagedAttention和前缀缓存（Prefix Caching）实现跨请求的缓存复用。此时，缓存命中率成为衡量缓存系统效率的核心指标。

缓存命中率定义如下：

缓存命中率 = 命中的KV块数量 / 请求所需的KV块总数 × 100%

在vLLM中，KV Cache以固定大小的块（Block）为单位管理，每个块通常包含16个token的KV数据。当新请求的前缀与缓存中已有块完全一致时，直接复用该块，无需重新计算。

影响缓存命中率的主要因素包括：

前缀长度：请求的公共前缀越长（如System Prompt、Few-shot示例），可复用的块越多，命中率越高。
块大小：块越小，缓存粒度越细，命中率越高，但块表（Block Table）开销增大。
缓存容量：显存中可容纳的块总数有限，超出后需按LRU等策略淘汰，容量不足会降低命中率。
请求分布：多轮对话中，同一用户的历史轮次可复用；不同用户的System Prompt相同时也可复用。

场景	可复用内容	命中率特征
单请求增量解码	自身历史token的K、V	100%（必然命中）
多轮对话（同用户）	System Prompt + 历史轮次	高（取决于历史长度）
共享System Prompt（不同用户）	System Prompt部分	中高（前缀越长越高）
完全独立的请求	几乎无复用	低（仅可能命中通用前缀）

3.3 缓存与吞吐量的关系：显存换算与并发上限

推理服务的吞吐量通常定义为：每秒处理的token总数（tokens/s）。在GPU显存固定的前提下，KV Cache的大小直接决定了能同时处理的请求数量（并发度），进而影响吞吐量。

假设单张A100-80GB GPU，模型权重占用40GB，剩余40GB可用于KV Cache。若每个请求的KV Cache占用512MB（对应1024 token输出），则理论上最多容纳约80个并发请求。但实际还需考虑激活值（Activation）和临时张量开销，通常可用KV Cache约为总显存的50%~70%。

vLLM通过PagedAttention技术，将KV Cache划分为不连续的块，按需分配，避免了传统方法中因预分配最大长度而导致的内部碎片浪费。这使得实际可容纳的请求数大幅提升。

# vLLM 启动参数中与KV Cache相关的关键配置
# --gpu-memory-utilization: 控制用于KV Cache的显存比例（默认0.9）
# --max-num-seqs: 限制最大并发序列数
# --block-size: KV Cache块大小（默认16 token）

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-7b-chat-hf \
    --gpu-memory-utilization 0.85 \
    --max-num-seqs 64 \
    --block-size 16

吞吐量与KV Cache的关系可总结为以下链条：

KV Cache容量↑ → 可容纳更多并发请求 → GPU计算单元利用率↑ → 吞吐量↑
缓存命中率↑ → 减少重复计算 → 单请求延迟↓ → 单位时间处理请求数↑ → 吞吐量↑
块管理效率↑（PagedAttention）→ 减少显存碎片 → 同等显存下容纳更多请求 → 吞吐量↑

实践要点：在vLLM中，可通过 /metrics 端点监控 vllm:cache_hit_rate 指标。若命中率低于0.3，说明前缀复用不足，可考虑增加System Prompt长度或启用自动前缀缓存（--enable-prefix-caching）。

3.4 案例复盘：一个典型的吞吐量优化场景

场景描述：某企业部署了基于vLLM的聊天机器人服务，使用Llama-2-13B模型，单张A100-80GB GPU。初始配置为 --gpu-memory-utilization 0.7，未开启前缀缓存。压测发现吞吐量仅为 320 tokens/s，GPU利用率约45%。

诊断过程：

通过监控发现，cache_hit_rate 仅为0.12，说明大量请求的System Prompt未被复用。
分析请求日志，发现所有请求都带有相同的2KB System Prompt，但vLLM默认未开启前缀缓存。
检查显存分配，发现KV Cache仅占用约28GB（0.7 × 40GB可用），存在提升空间。

优化措施：

# 优化后启动参数
python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-13b-chat-hf \
    --gpu-memory-utilization 0.92 \
    --max-num-seqs 128 \
    --enable-prefix-caching \
    --block-size 16

优化结果：

指标	优化前	优化后	提升幅度
缓存命中率	0.12	0.78	+550%
吞吐量	320 tokens/s	890 tokens/s	+178%
GPU利用率	45%	87%	+42pp
平均延迟（P50）	1.8s	0.9s	-50%

常见误区：

误区1：认为KV Cache只影响显存，不影响计算速度。实际上，缓存命中率低会导致大量重复计算，直接拖慢生成速度。
误区2：盲目调大 --gpu-memory-utilization 到0.99。需预留足够显存给激活值和临时张量，否则会触发显存溢出（OOM）或频繁的显存交换，反而降低吞吐量。
误区3：忽略块大小的影响。块过小（如8）会增加块表管理开销；块过大（如32）会降低命中率。16是多数场景下的平衡点。

复盘总结：KV Cache是LLM推理性能优化的核心杠杆。理解其原理后，优化路径清晰可见：先提升缓存命中率（减少无效计算），再提高显存利用率（增加并发），最后微调块大小（平衡粒度与开销）。三者协同作用，才能最大化吞吐量。