Context Cache（上下文快取）

3 秒看懂

Context Cache 的本質：把”重複算過的字首”的 KV 張量快取下來，下次遇到相同字首直接複用，跳過預填充階段的計算。 用”空間換時間”——花 HBM/記憶體存 KV Cache，省掉每請求重算字首的 GPU 算力。對於長系統提示、RAG 文件字首、多輪對話等場景，可顯著降低首 token 延遲（TTFT）和推論成本。

3 分鐘產業解釋

為什麼 Context Cache 突然火了？

大型模型推論正在從”一次性問答”走向 長上下文、多輪互動、RAG 檢索增強 三大場景：

場景	上下文特徵	重複字首佔比
企業助手	萬 token 級 system prompt + Few-shot	接近 100% 字首重複
RAG	召回文件拼接進 prompt	部分文件高頻復現
多輪對話	歷史對話逐輪累積	越早的輪次越穩定
Agent / 工具呼叫	系統指令 + 工具 schema	大量靜態字首

在沒有 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 階段)

字首匹配策略

策略	匹配方式	靈活性	典型實現
嚴格字首匹配	Token 序列必須從位置 0 開始完全相同	低	vLLM APC（預設）
顯式快取斷點	使用者/API 指定快取邊界	中	Google/Anthropic API
Radix Tree 匹配	支援任意位置的公共子串	高	SGLang RadixAttention
Hash-based Block 匹配	按 block 粒度雜湊，支援非連續匹配	中-高	研究方案

驅逐與生命週期管理

• TTL（Time-To-Live）：API 快取通常有生存時間（如 Anthropic ~5 min，Google 可配置更長）
• LRU（Least Recently Used）：引擎內部快取常用 LRU 驅逐
• 容量配額：按帳戶/模型限制最大快取 token 數或記憶體大小
• 失效條件：模型更新、系統提示變更、快取底層資料結構變化

---

技術演進史

時間	事件	意義
2017–2020	KV Cache 在自迴歸解碼中成為標配	單請求內最佳化的基礎
2022–2023	FlashAttention 推動長上下文視窗落地	長字首成為可能，快取價值凸顯
2023	PagedAttention / vLLM 釋出	KV Cache 記憶體管理精細化，block 級複用基礎
2023	SGLang RadixAttention 釋出	跨請求字首共享從概念走向生產級實現
2024 Q1	vLLM Automatic Prefix Caching 合入	開源引擎原生支援字首快取
2024 Q2	Google Context Caching API 釋出	首個雲端廠商 API 級 Context Cache 產品
2024 Q3	Anthropic Prompt Caching 釋出	競爭跟進，快取斷點機制創新
2024–2025	分層快取（HBM→DRAM→SSD）、分散式 KV 共享等研究推進	向超長上下文和大規模服務演進

---

技術路線對比

維度	API 顯式快取（Google/Anthropic）	引擎自動字首快取（vLLM/SGLang）	分層/分散式快取（研究前沿）
快取粒度	整段字首（使用者指定）	Block/token 級自動匹配	可跨節點共享
匹配靈活性	顯式指定	自動 hash/字首匹配	取決於架構
儲存位置	服務端 HBM（對使用者透明）	本地 GPU HBM	HBM + DRAM + SSD
快取壽命	小時級（可配置）	會話級（LRU 驅逐）	取決於策略
適用場景	開發者直接呼叫 API	自建推論服務	超大規模推論叢集
成本模型	儲存費 + 命中折扣	基礎設施成本內化	硬體成本
開發者負擔	低（API 呼叫）	低（引擎自動）	高（需基礎設施能力）
典型延遲影響	TTFT 可降低一個數量級（長字首）	同上	加上跨層搬運開銷

---

上下游

上游（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 推論：共享字首的批次請求，字首只需算一次

---

關鍵指標

指標	定義	典型量級	備註
快取命中率	命中請求 / 總請求	依工作負載差異極大，企業場景可 >80%	最核心的價值指標
TTFT 縮短比例	(原始 TTFT - 快取後 TTFT) / 原始 TTFT	長字首場景可 >90%	直接影響使用者體驗
字首計算節省	快取命中 token 數 × 單 token prefill 計算量	—	對應算力成本節約
KV Cache 體積/token	2 × layers × kv_heads × d_head × dtype	模型相關，量級約 0.1–1 MB/token（大型模型）	GQA 顯著小於 MHA
快取儲存成本	$/M token/hour（API定價）或 硬體佔用（自建）	API 約 $0.01–0.1/小時/百萬token 量級 [估算]	各廠商定價不同，以官網為準
快取建立延遲	首次建立快取的 Prefill 時間	等同於原始 Prefill 時間	一次性成本
快取驅逐延遲	混合儲存下 KV 搬運的額外延遲	DRAM→HBM: ~ms 級	分層快取才涉及

---

供需與市場資料

需求側驅動力

• 上下文視窗持續擴大：從 4K → 128K → 1M，prefill 計算成本線性/超線性增長
• RAG 成為企業標配：文件片段反覆作為字首輸入
• 推論成本成為 AI 支出大頭：隨著模型規模化，推論成本佔比上升，快取是直接降本手段
• 多輪互動需求增長：客服、程式設計助手、教育等場景

供給側現狀

• 主要雲端廠商均已版面配置：Google、Anthropic 已公開產品，其他廠商預計跟進
• 開源引擎生態：vLLM、SGLang 等已支援自動字首快取，降低自建門檻
• GPU 視訊記憶體容量是核心約束：快取越多需要越多 HBM → 推動 HBM 容量需求

對產業鏈的影響

• 算力需求結構性變化：快取命中部分不需要重新計算，理論上降低峰值計算需求；但快取儲存增加 HBM 佔用 → 利好 HBM 供應商（更多視訊記憶體需求）
• 推論服務競爭維度變化：從”誰更便宜/更快”擴充套件到”誰的快取策略更優”
• 長上下文成為可負擔能力：Context Cache 使長上下文推論成本從”奢侈品”變”可消費”

---

代表公司與資本對映

公司/專案	角色	Context Cache 相關能力
Google (Gemini)	雲端廠商 API	Context Caching API，支援最長至百萬 token 級字首快取（具體上限以官方為準）
Anthropic (Claude)	雲端廠商 API	Prompt Caching，cache breakpoint 機制，短 TTL 適合連續請求
OpenAI	雲端廠商 API	未公開獨立 Context Cache 產品，有隱式字首複用機制
vLLM (UC Berkeley)	開源推論引擎	Automatic Prefix Caching，PagedAttention 記憶體管理
SGLang (UC Berkeley)	開源推論引擎	RadixAttention，基數樹匹配
NVIDIA	GPU/引擎	TensorRT-LLM 等推論架構，HBM 供應
SK hynix / Samsung / Micron	HBM 供應商	Context Cache 增加 HBM 需求量，利好出貨

資本對映邏輯：

• 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 應用走向規模化的關鍵使能技術。

---

延伸閱讀與來源

來源	內容	連結展望
vLLM 官方文件	Automatic Prefix Caching	vLLM Docs → Features → Automatic Prefix Caching
SGLang 論文/文件	RadixAttention 原理	SGLang GitHub 及相關論文
Google Cloud 文件	Context Caching API	Google AI for Developers → Gemini API → Context Caching
Anthropic 文件	Prompt Caching	Anthropic Docs → Prompt Caching
”Efficient Memory Management for Large Language Model Serving with PagedAttention”	vLLM/PagedAttention 原始論文	arXiv, 2023
KV Cache 量化相關論文	FP8/INT4 KV Cache	arXiv 相關工作

⚠️ 準確性宣告：本頁技術原理基於公開論文和文件。具體 API 定價、快取 TTL、最小快取 token 數等細節會隨廠商更新而變化，請以各廠商最新官方文件為準。部分量級資料為基於模型架構的估算，已標註。