Context Cache（上下文缓存）

3 秒看懂

Context Cache 的本质：把”重复算过的前缀”的 KV 张量缓存下来，下次遇到相同前缀直接复用，跳过预填充阶段的计算。 用”空间换时间”——花 HBM/内存存 KV Cache，省掉每请求重算前缀的 GPU 算力。对于长系统提示、RAG 文档前缀、多轮对话等场景，可显著降低首 token 延迟（TTFT）和推理成本。

3 分钟产业解释

为什么 Context Cache 突然火了？

大模型推理正在从”一次性问答”走向 长上下文、多轮交互、RAG 检索增强 三大场景：

在没有 Context Cache 的情况下，每一条请求都要从头算一遍前缀的注意力，这在长上下文（128K–1M token）时代意味着巨大的算力浪费。以 100K token 前缀为例，单次 prefill 计算量正比于序列长度的平方（自注意力）或线性（带 FlashAttention 优化时），数千次请求重复算同一前缀，GPU 周期白白消耗。

Context Cache 将已经计算好的前缀 KV 张量缓存起来，后续请求只需计算新增 token 的 KV，然后与缓存拼接即可。

产业影响：

• 降低推理成本：缓存命中部分的 token 单价可降至原始输入价格的 ~10%–50%（各厂商定价口径不同）。
• 降低 TTFT：跳过大量 prefill 计算，首 token 延迟大幅缩短。
• 催生新定价模型：存储费 + 命中折扣，成为推理 API 的新竞争维度。

15 分钟专家深入

核心问题：KV Cache 是什么？

Transformer 的自注意力机制在处理每个 token 时，会计算 Key（K）和 Value（V）张量。在自回归生成阶段，先前 token 的 K、V 不会改变，可以缓存复用——这就是 KV Cache。

Per-token KV Cache 大小（估算量级）：

单 token KV 大小 = 2 × n_layers × n_kv_heads × d_head × dtype_bytes

例：Llama-70B 级模型（GQA，8 KV heads, 80 layers, d_head=128, FP16）
= 2 × 80 × 8 × 128 × 2 bytes
= 327,680 bytes ≈ 0.33 MB / token

100K token 前缀 → ~32 GB KV Cache（单请求）

⚠️ 上述为典型 GQA 架构估算。实际值取决于具体模型架构（MHA/MQA/GQA 的 KV head 数差异显著）和量化精度。具体模型的 KV Cache 规格应以厂商公开技术报告为准。

Context Cache 与标准 KV Cache 的关系

┌──────────────────────────────────────────────────────┐
│                    单请求 KV Cache（标准）              │
│                                                      │
│  [Prefix KV] ──计算──> 存在 GPU HBM ──> 生成时复用     │
│       │                                              │
│       └── 请求结束 ──> 释放                             │
└──────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────┐
│               Context Cache（跨请求复用）               │
│                                                      │
│  [Prefix KV] ──首次计算──> 存入缓存池 ──> TTL内所有请求  │
│       │                              复用该缓存        │
│       └── TTL 过期 / 被驱逐 ──> 释放                    │
└──────────────────────────────────────────────────────┘

关键区别： 标准 KV Cache 是请求级生命周期，Context Cache 是跨请求的、有持久化管理策略的缓存池。

主流实现路径

1. API 层显式缓存（Google Context Caching / Anthropic Prompt Caching）

由模型推理服务提供方在 API 层实现：

• 调用方显式创建缓存对象，指定要缓存的 token 序列（或内容）
• 返回一个缓存 ID / 引用
• 后续请求引用该缓存 ID，服务端直接复用已计算的 KV 张量
• 按 存储时长 + 命中 token 数 计费

Google Context Caching API（约 2024 年 6 月发布）：

• 支持 Gemini 1.5 Pro / Flash 等模型
• 允许缓存最长至模型最大上下文窗口（Gemini 1.5 Pro 支持 128K–1M 级别）的前缀
• 有最小缓存 token 数要求（约为数万 token 级别，具体值以官方文档为准）
• 缓存有 TTL（生存时间），可配置
• 命中 token 的输入价格大幅折扣，另收小时级存储费

Anthropic Prompt Caching（约 2024 年 8 月发布）：

• 支持 Claude 系列模型
• 缓存寿命较短（约 5 分钟级别，适合同一会话内的连续请求）
• 在 API 请求中通过特殊标记声明缓存断点（cache breakpoint）
• 命中 token 定价约为原始输入价格的 ~10%（具体以官网为准）

2. 引擎层自动前缀缓存

在推理引擎内部实现，对调用方透明：

vLLM — Automatic Prefix Caching (APC)：

• 基于 PagedAttention 的 KV Cache 内存管理
• 对每个 KV block 计算内容哈希（hash of token IDs）
• 不同请求如果共享相同 token 前缀，对应 block 直接复用
• LRU 策略驱逐
• 前缀必须从序列起始处匹配（严格前缀匹配）

SGLang — RadixAttention：

• 使用 基数树（Radix Tree） 数据结构组织 KV Cache
• 支持更灵活的前缀/后缀匹配（不限于严格前缀）
• 适合多轮对话等共享前缀在不同位置出现的场景
• 驱逐策略支持 LRU 等多种策略

3. 分层缓存（HBM → DRAM → SSD）

当缓存规模超过 GPU 显存容量时：

GPU HBM（热缓存）  ←→  CPU DRAM（温缓存）  ←→  SSD（冷缓存）
   命中：μs级              命中：~ms级              命中：~10ms级

• GPUinference 等方案探索将不活跃的 KV Cache 卸载到 CPU 内存或 SSD
• 命中时需要将 KV 张量搬回 GPU HBM，涉及 PCIe/内存带宽瓶颈
• 需要权衡：重算（compute-bound）vs. 搬运（bandwidth-bound）哪个更快
• 对于超长上下文（百万 token 级），分层缓存是必要的

技术原理

自注意力中的 KV 计算与缓存

标准自回归推理流程：

Prefill 阶段（处理 prompt）:
  输入: [t1, t2, ..., tN]  (N = prompt 长度)
  对每个 token i:
    Q_i = x_i · W_Q
    K_i = x_i · W_K        ← 每层都产生
    V_i = x_i · W_V        ← 每层都产生
    Attention(Q_i, K_1..i, V_1..i) = softmax(Q_i·K_1..i^T / √d) · V_1..i

  输出: KV Cache = [(K_layer0, V_layer0), ..., (K_layerL, V_layerL)]
        每层 K,V 形状: [seq_len, n_kv_heads, d_head]

Decode 阶段（生成 token，逐 token）:
  输入: 新 token t_{N+1}
  Q_{N+1} = x_{N+1} · W_Q
  K_{N+1}, V_{N+1} = ...（新计算）
  将 K_{N+1}, V_{N+1} append 到已有 KV Cache
  Attention(Q_{N+1}, K_1..N+1, V_1..N+1)

  复用了 K_1..N 和 V_1..N，无需重算 ✓

Context Cache 的核心机制

Context Cache 命中时的流程:

请求 A (首次): [PREFIX_100K | suffix_A_1K]
  → Prefill 101K tokens
  → 缓存 PREFIX 的 KV: KV_prefix = [(K,V) for each layer, seq 0..99999]
  → 存入 Context Cache 池，关联 hash/prefix_id

请求 B (命中): [PREFIX_100K | suffix_B_1K]   ← 前缀相同!
  → 查 Context Cache → 命中!
  → 只需 Prefill suffix_B_1K (1K tokens)
  → 拼接: KV_total = KV_prefix (缓存) + KV_suffix_B (新算)
  → Prefill 计算量: ~1K tokens (vs. 101K 无缓存时)
  → 加速比: ~100x (仅 prefill 阶段)

前缀匹配策略

驱逐与生命周期管理

• TTL（Time-To-Live）：API 缓存通常有生存时间（如 Anthropic ~5 min，Google 可配置更长）
• LRU（Least Recently Used）：引擎内部缓存常用 LRU 驱逐
• 容量配额：按账户/模型限制最大缓存 token 数或内存大小
• 失效条件：模型更新、系统提示变更、缓存底层数据结构变化

技术演进史

技术路线对比

上下游

上游（Context Cache 依赖什么）

┌─────────────────────────────────────────────┐
│              硬件层                           │
│  GPU HBM (存 KV Cache)                       │
│  CPU DRAM / NVMe SSD (分层缓存)              │
│  高速互联 (NVLink / PCIe / RDMA)             │
│  大容量显存 GPU (H100/H200/MI300X/B200等)     │
└─────────────┬───────────────────────────────┘
              │
┌─────────────▼───────────────────────────────┐
│            模型架构层                          │
│  GQA/MQA (减少 KV head 数，降低缓存体积)       │
│  长上下文窗口 (128K–1M token)                  │
│  KV Cache 量化 (FP8/INT4 KV 压缩)             │
└─────────────┬───────────────────────────────┘
              │
┌─────────────▼───────────────────────────────┐
│           推理引擎层                           │
│  PagedAttention (block 级内存管理)             │
│  FlashAttention (高效注意力计算)               │
│  Prefix Hashing / Radix Tree                 │
└─────────────────────────────────────────────┘

下游（Context Cache 使能什么）

• 低成本长上下文 RAG：缓存检索到的文档，后续问题直接复用
• 企业级 AI 助手：万 token 级 system prompt 只算一次
• 多轮对话体验优化：TTFT 降低，交互更流畅
• Agent 框架：工具 schema + 系统指令缓存，减少工具调用开销
• Batch 推理：共享前缀的批量请求，前缀只需算一次

关键指标

供需与市场数据

需求侧驱动力

• 上下文窗口持续扩大：从 4K → 128K → 1M，prefill 计算成本线性/超线性增长
• RAG 成为企业标配：文档片段反复作为前缀输入
• 推理成本成为 AI 支出大头：随着模型规模化，推理成本占比上升，缓存是直接降本手段
• 多轮交互需求增长：客服、编程助手、教育等场景

供给侧现状

• 主要云厂商均已布局：Google、Anthropic 已公开产品，其他厂商预计跟进
• 开源引擎生态：vLLM、SGLang 等已支持自动前缀缓存，降低自建门槛
• GPU 显存容量是核心约束：缓存越多需要越多 HBM → 推动 HBM 容量需求

对产业链的影响

• 算力需求结构性变化：缓存命中部分不需要重新计算，理论上降低峰值计算需求；但缓存存储增加 HBM 占用 → 利好 HBM 供应商（更多显存需求）
• 推理服务竞争维度变化：从”谁更便宜/更快”扩展到”谁的缓存策略更优”
• 长上下文成为可负担能力：Context Cache 使长上下文推理成本从”奢侈品”变”可消费”

代表公司与资本映射

资本映射逻辑：

• Context Cache 本身是软件/算法层优化，不直接对应独立公司
• 间接受益：HBM 存储供应商（SK hynix、Samsung、Micron）——缓存需要更多显存
• 间接受益：大容量 HBM GPU（NVIDIA H200/B200，AMD MI300X）——缓存池驻留需要显存
• 平台竞争：Context Cache 能力成为推理 API 差异化要素之一

投资逻辑

核心投资命题

Context Cache 是推理成本曲线的”曲率调节器”——它不能改变模型本身的能力，但能显著改变推理的经济学。

1. 直接降本效应：对长前缀场景，推理成本可降低 50%–90%（取决于缓存命中率和定价模型）。这意味着 同等算力基础设施能服务更多请求，或 同等请求量需要更少算力。

2. HBM 容量需求增加：缓存需要存储空间 → 每张 GPU 能缓存的前缀越多越好 → 推动 HBM 容量竞赛。H200（96GB HBM3e）vs H100（80GB HBM3）的缓存容量优势更明显。

3. 推理 API 竞争格局变化：拥有高效缓存机制的平台能提供更低价格 → 用户粘性增强。这也是 Google、Anthropic 率先推出 API 级产品的原因。

4. 对推理算力需求的净效应是复杂的：

   • 单请求计算量降低（缓存命中）
   • 但长上下文变得可负担 → 使用量上升（Jevons 悖论）
   • 净效应：推理算力总需求可能不降反升

风险与不确定性

• 如果模型架构发生根本性变化（如不再使用 Transformer 自注意力），KV Cache 机制可能失效
• 技术快速迭代，当前实现可能被新方案取代
• 缓存安全/隐私问题（跨租户缓存隔离）

常见误读纠偏

误读 1：“Context Cache 就是 KV Cache”

❌ KV Cache 是单请求内的标准优化——每条请求在 decode 阶段缓存自己的 KV，请求结束即释放。 ✅ Context Cache 是跨请求的缓存复用机制——将 A 请求计算的 KV 存下来，让 B、C、D…请求复用。两者层级不同。KV Cache 是基础，Context Cache 是在其之上的”缓存池”管理。

误读 2：“Context Cache 对所有请求都有加速效果”

❌ 只有前缀命中的请求才能受益。如果每条请求的前缀完全不同（如个性化极强的 prompt），缓存命中率为零，反而有额外的缓存查找和管理开销。Context Cache 的价值取决于工作负载中前缀的重复程度。典型的高价值场景（系统提示、RAG 文档、Few-shot 模板）确实有很高的前缀重复率。

误读 3：“缓存命中的 token 不消耗任何资源”

❌ 缓存命中的 token 节省了计算（compute），但 仍然占用 HBM 存储空间。大量并发缓存可能导致 GPU 显存被 KV Cache 占满，挤压 decode 阶段的 batch size，反而降低吞吐。这是经典的 内存-计算 trade-off，需要在缓存命中率和可用显存之间取得平衡。

误读 4：“Context Cache 等于 Prompt Caching，只是叫法不同”

⚠️ 部分正确但不完全等价。Prompt Caching 更偏向 API 层的商业概念（厂商定价策略），Context Cache 更偏向底层技术实现（KV 张量的存储与复用机制）。Google 用 “Context Caching” 命名其 API，Anthropic 用 “Prompt Caching”，但底层技术原理一致。在开源引擎中，通常称为 “Prefix Caching” 或 “Automatic Prefix Caching”。

学习路径

入门

1. 理解 Transformer 自注意力机制中的 Key、Value 概念
2. 理解自回归推理中的 Prefill 和 Decode 两个阶段
3. 了解 KV Cache 的基本原理（为什么 decode 阶段可以缓存 KV）

进阶

4. 阅读 PagedAttention 论文（vLLM，2023）——理解 KV Cache 的内存管理
5. 阅读 SGLang RadixAttention 相关工作——理解跨请求前缀共享
6. 实践：在 vLLM 中开启 --enable-prefix-caching，对比有/无缓存的 TTFT 和吞吐

深入

7. 研究 GQA/MQA 对 KV Cache 体积的影响
8. 研究 KV Cache 量化（FP8/INT4 KV）对缓存空间和精度的影响
9. 关注分层缓存、分布式 KV 共享等前沿研究
10. 实际测试不同工作负载下的缓存命中率，建立直觉

一句话总结

Context Cache 是”别重复算已经算过的前缀”的工程化落地——通过跨请求共享 KV 张量，将长上下文推理的计算成本与延迟砍掉一个数量级，是长上下文 AI 应用走向规模化的关键使能技术。

延伸阅读与来源

⚠️ 准确性声明：本页技术原理基于公开论文和文档。具体 API 定价、缓存 TTL、最小缓存 token 数等细节会随厂商更新而变化，请以各厂商最新官方文档为准。部分量级数据为基于模型架构的估算，已标注。