KV Cache 存在 GPU 显存或 CPU 内存中。显存太贵，存不了多少。高并发一来，旧的立刻被挤出。5-10 分钟后缓存热数据就没了。Anthropic 还要你手动标记 cache_control，标记错了白花钱。
KV Cache 可以存到磁盘上。怎么做到？先把 KV Cache 压缩 5-13 倍（MLA），压缩完只有原来的 1/10 不到，磁盘读写完全扛得住。不依赖显存，不会因为并发被挤出。缓存有效期从别人家的 5 分钟变成了几小时到几天。
标准多头注意力（MHA）每个 token 为每个注意力头存储完整的 Key 和 Value 向量。MLA 引入一个低维潜变量 c，将多个头的 K/V 信息压缩到这个潜变量中。查询时从 c 重建 K 和 V。压缩比由潜变量维度控制——DeepSeek V3 的潜变量维度约为原始 K/V 联合维度的 1/10 到 1/5。
关键工程含义：一个 100K token 会话的 KV Cache，标准 Transformer 可能占 40GB 显存——MLA 压缩后仅 4-8GB，可以直接写到 NVMe SSD 上。这是 DeepSeek 全球首家在 API 层面实现大规模磁盘缓存的技术基础。
每次请求的用户输入结束位置和模型输出结束位置各产生一个缓存前缀单元。不需要你手动标记 cache_control——全自动。
系统持续监测多次请求间的重复前缀。一旦检测到多个请求共享同一个前缀（比如同一个 system prompt），自动将该前缀落盘为独立缓存单元。
超长输入或输出（> 64K tokens）按固定 token 间隔截取缓存单元。确保长上下文请求也能部分命中缓存，而不是全扔。
不是简单的最近最少用。采用 LRU-K（K=2），额外引入访问热度衰减因子 α=0.95。一个前缀被访问两次以上才进入「高频池」——单次访问的不会挤掉多次访问的。
| 原则 | 怎么做 | 反面例子 |
|---|---|---|
| 固定 System Prompt | 移出所有动态内容（时间戳、用户ID） | "今天是 2026-06-13" 插在 System Prompt 开头 → 每一天前缀不同，永不命中 |
| 只追加，不修改 | 新消息放在对话历史末尾 | 在中间插入一条纠正 → 后面的所有内容缓存失效 |
| 工具定义稳定 | Tool JSON 定义 hardcode，不要每次动态生成 | 用 LLM 动态写 tool schema → 每次不同 |
| JSON 序列化确定 | json.dumps(data, sort_keys=True) | Python dict 的 key 顺序随机 → 相同的语义，不同的字节 → 不命中 |
| DeepSeek | OpenAI | Anthropic | |
|---|---|---|---|
| 缓存位置 | 磁盘（NVMe SSD） | GPU 显存 / SSD | GPU 显存 |
| 缓存有效期 | 数小时 — 数天 | 5-10 分钟 | 5 分钟 |
| 是否自动 | 全自动 ✅ | 全自动 ✅ | 需手动标记 ❌ |
| 命中价格折扣 | 10 倍 | ~2 倍 | ~10 倍 |
| 缓存写入收费 | 不收费 ✅ | 不收费 ✅ | 收费 ❌ |
| 压缩技术 | MLA（5-13×） | Paged Attention | 专有实现 |
| 模型 | 缓存命中率 | 备注 |
|---|---|---|
| DeepSeek | 100% | 12 小时后仍 100% |
| MiniMax | 90%（低峰） | 高峰期降至 70% |
| Kimi | 中等 | |
| GLM（智谱） | 2min:80%→15min:0% | 缓存快速失效 |
| OpenAI | 中等 |
| 场景 | 预期命中率 |
|---|---|
| Web 开发（高重复上下文） | 95%+ |
| 多轮对话（长 session） | 80-95% |
| 固定仓库代码问答 | 90%+ |
| 定时脚本（cron job） | 98%+ |
| 每次请求完全不同 | < 10% |
一位开发者使用 Claude developer mode 对接 DeepSeek API 做 Web 开发。单日消耗约 8900 万 tokens，总费用仅 ¥4.39（约 $0.64）。缓存命中率 98.07%。如果换成无缓存的 API 调用，这笔账单会是 ¥40+。