AI 中 Cache 存储位置详解

KV Cache 存在谁的 GPU 显存里就归谁管。用云 API 你只能"触发命中"，自部署你才能"完全掌控"。

一句话答案

Cache 存在 LLM 服务商的 GPU 显存里，不在你这边。

📍 三种"Cache"的存储位置

类型	存在哪里	谁控制	你能干预吗
Prompt Cache（KV Cache）	🏢 服务商 GPU 显存	服务商	❌ 只能按规则触发
客户端响应缓存	💻 你的服务器/浏览器	你自己	✅ 完全控制
本地模型缓存	🖥️ 本地 GPU 显存（自部署时）	你自己	✅ 完全控制

🔍 Prompt Cache — 存在服务商 GPU 显存

你的请求                          服务商机房
────────                          ────────
                                 ┌─────────────────────────────┐
                                 │  GPU 0                      │
                                 │  ┌───────────────────────┐  │
  POST /chat/completions  ──────►│  │  KV Cache（显存）      │  │
  {                              │  │  [system_prompt 的 KV] │  │ ← 缓存在这！
    messages: [                  │  │  [历史对话的 KV]       │  │
      {system: "你是客服..."},   │  │  推理时直接复用，      │  │
      {user: "我的订单..."}      │  │  不重新计算 attention  │  │
    ]                            │  └───────────────────────┘  │
  }                              └─────────────────────────────┘

KV Cache 是什么？

Transformer 推理过程：
输入 Token 序列 → 每一层 Self-Attention 计算 → 生成 K、V 矩阵

┌──────────────────────────────────────────────┐
│  Layer 1:  K1, V1  ← 每个 Token 的 Key/Value │
│  Layer 2:  K2, V2                             │
│  ...                                          │
│  Layer 32: K32, V32                           │
│                                               │
│  这些 K、V 矩阵就是 KV Cache                  │
│  占用：每 Token 约 0.5~2 MB 显存              │
│  1000 Token ≈ 1 GB 显存                      │
└──────────────────────────────────────────────┘

如果前缀没变 → K、V 没变 → 直接复用，跳过计算

🏢 各服务商的 Cache 实现

服务商	名称	TTL	触发条件
OpenAI	Prompt Caching	5~10 分钟	前缀 ≥ 1024 Token，自动触发
Anthropic	Prompt Caching	5 分钟	标记 cache_control，前缀 ≥ 1024 Token
Google	Context Caching	可自定义	显式创建 cached content
DeepSeek	Prefix Caching	约 5 分钟	前缀匹配自动触发
本地部署	KV Cache	进程存活期间	自动（vLLM/SGLang）

🌰 Anthropic Cache 流程示例

第一次请求：
  system: "你是客服助手..." (5000 tok) ← 标记 cache_control
  user:   "我的订单啥时候发货？" (20 tok)
  → 全部计算 attention → 生成 KV Cache → 写入 GPU 显存
  → 计费：5000 × $3/M = $0.015（正常价格）
  → 💾 Cache 存入显存，TTL 5 分钟开始倒计时

第二次请求（3 分钟后，Cache 未过期）：
  system: "你是客服助手..." (5000 tok) ← 前缀一字不差！命中！
  user:   "能退换货吗？" (15 tok)
  → 前 5000 Token 直接读 KV Cache，跳过计算 ⚡
  → 计费：5000 × $0.3/M + 15 × $3/M = $0.0015
  → 💰 省了 90%！

第三次请求（8 分钟后，Cache 已过期）：
  → KV Cache 已被清除 → 重新计算 → 重新写入
  → 计费：5000 × $3/M = $0.015（正常价格）

🧠 为什么 Cache 不能存你这边？

❌ 把 KV Cache 下载到本地，下次上传复用？

不行，因为：
1. 体积巨大：5000 Token → KV Cache 约 5 GB，传输比计算还慢
2. 硬件绑定：A100 算的 Cache 拿不到 H100 上用
3. 安全隔离：服务商不会暴露内部计算中间结果

✅ 所以：Cache 只能在服务商的 GPU 显存里
   你能做的：按规则触发缓存命中（前缀不变 + TTL 内）

🎯 总结

┌────────────────────────────────────────────────────┐
│  🏢 云端 API → 服务商的 GPU 显存（你看不见摸不着） │
│  🖥️ 本地部署 → 你的 GPU 显存（你可以监控和管理）   │
│  💻 客户端   → 响应缓存（不是 Token 级 KV Cache）   │
│                                                    │
│  ✅ 把不变的放前面 → 触发 Cache 命中               │
│  ✅ 控制请求间隔 → 在 TTL 内复用                    │
│  ✅ 本地部署 → 完全控制 KV Cache 生命周期           │
│  ❌ Cache 的存储位置、TTL、淘汰策略 → 服务商定       │
└────────────────────────────────────────────────────┘

一句话记忆

KV Cache 是 GPU 算出来的中间结果，存在谁的 GPU 显存里就归谁管。用云 API 你只能"触发命中"，自部署你才能"完全掌控"。

---

整理日期：2026-04-30