一句话：大模型 API 的账单里，有一大块钱你本不该付。缓存不是「优惠」，是对重复计算的正当拒绝。

从大模型推理到底层的注意力机制，再到 API 厂商的定价策略，「缓存」贯穿整条价值链。理解了这一层，你才能真正看懂 DeepSeek 为什么被称为「赛博善人」，Token 中间商怎么靠信息差割韭菜，以及 Claude Code 源码里密密麻麻的 cache 关键字藏着什么省钱秘籍。

本文四层递进：

1. KV Cache——模型推理的「记忆器官」
2. Prompt Cache——API 层面的「预付费卡」
3. DeepSeek 与 Token 中间商——定价权之战
4. Claude Code 源码——工程化的极致缓存架构

01 KV Cache：没有它，每生成一个字都要从头算一遍

1.1 Transformer 的注意力机制，天然带着重复计算

大模型生成文本，逐字进行。每生成一个新 token，都要计算它与前面所有 token 的「注意力权重」。这个计算需要三样东西：

• Query（Q）：当前 token 的「查询向量」
• Key（K）：历史每个 token 的「键向量」
• Value（V）：历史每个 token 的「值向量」

注意力公式：

Attention(Q, K, V) = softmax(Q × K^T / √d_k) × V

关键洞察： 当模型生成第 n 个 token 时，前 n-1 个 token 的 K 和 V 已经在生成第 n-1 个 token 时算过了。如果不加处理，这些计算会被重复执行——第 n 个 token 的生成，需要把前 n-1 个 token 的 K、V 全部重算一次。

1.2 KV Cache 的解法：以空间换时间

核心思想： 把每一步算好的 K 和 V 矩阵存起来，下一步直接复用。

流程对比：

复杂度变化：

• 无缓存：O(n²)——每步都与全部历史计算
• 有缓存：O(n)——每步只与新增的历史计算

内存开销：
以 GPT-3 175B 为例，每个 token 的 KV Cache 约 20KB。1000 token 的序列需要约 20MB。批量处理时线性增长。

1.3 为什么只有 KV Cache，没有 Q Cache？

核心原因： 当前 token 的 Q 只参与当前步的计算，历史上的 Q 对当前生成没有用处。当前步只需要「当前的 Q」去查询「历史的 K/V」。

第 3 步生成：
- 需要：Q3（新算）, [K1, K2, K3]（K1,K2 来自缓存，K3 新算）
- 不需要：Q1, Q2（历史上的 Q 不参与当前计算）

1.4 没有 KV Cache 会怎样？

成本爆炸：

• 生成 1000 token 的序列，无缓存需要约 100 万次注意力计算
• 有缓存只需约 1000 次，差距 1000 倍

实际表现：

• 无缓存：长文本生成速度随长度线性下降，最终卡住
• 有缓存：速度相对稳定，可处理超长上下文

02 Prompt Cache：API 厂商的「预付费卡」

2.1 从推理层到 API 层

KV Cache 解决了单条请求的推理效率问题。Prompt Cache 解决的是跨请求的效率问题：

如果你连续发 10 条请求，每条的前 90% 内容都是相同的系统提示和上下文，为什么要付 10 次全额费用？

Prompt Cache 的本质： API 服务商在服务器端缓存「前缀的 KV Cache」，下次请求前缀匹配时，直接跳过预填充阶段，只计算新增部分。

2.2 为什么命中率一高，成本就能「砍到脚踝」？

Prompt Cache 的定价模型：

关键数据：

• Claude Code 生产环境：92% 命中率，81% 成本降低
• 20,000 token 的系统提示，50 轮对话：
  • 无缓存：100 万 token 全价 = 💲3.00（Sonnet）
  • 有缓存：100 万 token 命中价 = 💲0.30
  • 省 💲2.70，仅一个会话

2.3 Prompt Cache 的工作机制

前缀匹配原则：

• 缓存 key = 请求前缀内容的 hash（从第 0 个 token 开始）
• 匹配规则：前缀必须完全一致，中间开始的重复无法命中
• 最小缓存块：1024 tokens（Anthropic/DeepSeek）

生命周期：

• Anthropic：5 分钟 TTL，命中自动续期；可选 1 小时 TTL（写入价 2x）
• OpenAI：5-10 分钟默认，可选 24 小时（需显式开启）
• DeepSeek：10-30 分钟，硬盘持久化

2.4 如何最大化缓存命中率

核心原则：不变的内容放前面，变化的内容放后面。

请求结构（最优）：
┌───────────────────────────────────────────────────┐
│  System Prompt（系统指令）                         │ ← 缓存
│  Tools Definition（工具定义）                      │ ← 缓存
│  CLAUDE.md（项目上下文）                           │ ← 缓存
│  ─────────────────────────────────────────────  │ ← cache_control 断点
│  History Messages（动态历史）                      │ ← 部分缓存
│  User Input（用户输入）                            │ ← 动态
│  Tool Results（工具返回）                          │ ← 动态
└───────────────────────────────────────────────────┘

避坑：

• 不要在系统提示里加时间戳、随机 ID、动态变量
• 不要中途修改工具定义顺序
• 不要频繁切换模型（缓存与模型绑定）

03 DeepSeek：赛博善人的「硬盘缓存」革命

3.1 为什么 DeepSeek 被称为「赛博善人」

价格对比（2026 年 5 月，每百万 token）：

关键发现：

• DeepSeek 的缓存命中价打到 原价的 1/10，V4-Pro 甚至达到 1/120
• 而且全部自动开启，无需任何代码改动
• 官方公开运营数据：24 小时内，56.3% 的输入 token 命中硬盘缓存

3.2 硬盘缓存：把 KV Cache 从显存搬到磁盘

技术前提： DeepSeek 的 MLA（Multi-head Latent Attention）架构极大压缩了 KV Cache 体积。

工程意义：

• 其他模型的 KV Cache 大到只能塞进昂贵的 GPU 显存
• DeepSeek 的压缩后 KV Cache 小到可以放进便宜的分布式硬盘
• 结果：跨请求的缓存可以持久化存储，TTL 长达 10-30 分钟

性能数据：

• 128K token 长 prompt，首 token 延迟：
  • 缓存未命中：~13 秒
  • 缓存命中：~0.5 秒
  • 26 倍提升

3.3 一个反直觉的结论：你应该加更多上下文

传统 prompt engineering 的建议是「prompt 要短、tokens 要省」。但在 DeepSeek 的缓存机制下，这个逻辑完全反转：

缓存命中的 token 几乎免费。1000 tokens 的缓存命中输入只要 💲0.000028。

这意味着：

• 加更多 few-shot 示例？成本不变，质量提升
• 加载更长的项目文档？成本不变，上下文更丰富
• 多轮对话历史全保留？只要前缀不变，新增历史也享受缓存

Prompt engineering 的新哲学：

• 旧问题：「怎么用最少的话把任务说清楚？」
• 新问题：「在几乎免费的稳定上下文里，放什么最有价值？」

04 Token 中间商：缓存差价的「割韭菜」艺术

4.1 中转站的生意经

Token 中间商（API 中转站）的核心模式：

用户 → 中转站 API → 上游厂商（OpenAI/Anthropic/DeepSeek）
          ↑
      赚差价

三档生意：

典型案例：

• 💲200/月的 Claude Code Max 账号，拆分转售可套到 💲2000-5000
• 表面卖 💲1/百万 token，实际扣费按 💲5/百万

4.2 缓存差价：最隐蔽的割法

核心套路：

中转站内部：
- 向用户收取「未命中价」（全价）
- 自己享受「缓存命中价」（1/10 甚至 1/120）
- 差价 = 用户的冤枉钱

具体手法：

1. 缓存命中率不透明

   • 用户看不到 prompt_cache_hit_tokens 和 prompt_cache_miss_tokens
   • 中转站可以伪造响应，隐藏缓存命中事实
   • 用户按全价付费，中转站按 1/10 价结算

2. 前缀污染策略

   • 中转站在转发请求前，偷偷在 prompt 前加一段自己的标记
   • 结果：每次请求前缀都不同，缓存永远无法命中
   • 用户被迫持续支付全价

3. 倍率偷改

   • 声称「比官方便宜 50%」
   • 实际计费时按 5 倍倍率扣费
   • 用户发现时往往已经产生巨额账单

案例数据：
某开发者单日消耗 8900 万 tokens，真实成本应为：

• 若 98% 命中 DeepSeek 缓存：约 💲2.5
• 若中转站按全价收费：约 💲25
• 差价 💲22.5，一天之差

4.3 为什么 DeepSeek 的缓存让中间商更难割

DeepSeek 的硬盘缓存自动开启，而且命中率极高（实测 95%+）。这意味着：

• 正规中转站：利润变薄，因为上游成本本身就极低
• 黑心中转站：更难用「缓存不透明」套路，因为缓存几乎是必然的

但新的套路已经出现：

• 「缓存优化服务」：声称帮你优化缓存命中率，实则无实质操作，收服务费
• 「专属缓存节点」：声称独享缓存池，实则共享，收取溢价

05 Claude Code 源码：缓存的工程化极致

5.1 源码层面的缓存架构

Claude Code 的源码（src/ 目录）中，缓存不是「功能」，是「基础设施」。

SYSTEM_PROMPT_DYNAMIC_BOUNDARY

// prompts.ts
const SYSTEM_PROMPT = {
  static: "你是 Claude，一个编程助手...",  // ← 缓存层
  dynamic: DANGEROUS_uncachedSystemPromptSection(), // ← 动态层
  tools: ALL_TOOLS_DEFINITION,  // ← 缓存层
};

DANGEROUS_ 前缀的含义： 代码级警告。这段内容若放入静态区，会导致缓存失效，每次请求重新创建缓存，成本从 💲0.30/MTok 飙升到 💲3.75/MTok（12.5 倍差距）。

缓存共享架构

// 分类器与对话引擎共享基础上下文
class CacheSharing {
  shared_prefix = {
    system_prompt: BASE_SYSTEM,
    tools: ALL_TOOLS,
    context: PROJECT_CONTEXT
  };

  // YOLO 分类器（自动审批工具调用）
  classifier = new YOLOClassifier(this.shared_prefix);

  // 主对话引擎
  query_engine = new QueryEngine(this.shared_prefix);
  // 同一个前缀，成本只计一次
}

工程意义： YOLO 模式下的意图分类器与主对话共用缓存前缀，无需额外写入成本。

5.2 Auto Compact：防止动态尾部爆炸

问题： 多轮对话后，消息历史不断累积，动态尾部越来越长，可能挤占缓存前缀的有效空间。

解法： autoCompact.ts

对话历史膨胀 → 触发 compact → 折叠为摘要 → 只保留关键决策树
     ↑                                              ↓
  接近 token 上限                                缓存前缀稳定

关键策略：

• 早 compact，不要攒着：越晚 compact，被全价计费的内容越多
• 按子任务 compact：做完一个子任务就 compact 一次
• 不要 resume session：恢复 session 时序列化结构可能与原始结构有微小差异，导致缓存失效，前几轮按全价计费

5.3 CLAUDE.md：缓存命中率最敏感的文件

最佳实践（< 50 行）：

# 项目说明

## 关键命令
- 安装: pnpm install
- 开发: pnpm dev
- 测试: pnpm test

## 代码约定
- 用 TypeScript strict 模式
- API 路由放 src/api/

## 关键文件
- 配置: config/index.ts
- 数据库 schema: prisma/schema.prisma

## 不要做
- 不要修改 .env.production

设计哲学：

• CLAUDE.md 是「索引」，不是「文档」
• 告诉 Claude 去哪里找信息，而不是把信息塞进来
• 不写动态内容（今日更新、本周计划、临时方案）—— 一改就失效

5.4 实测效果

优化后成本 = 不开缓存的 15.6%，节省 84%。

06 总结：缓存是 AI 基础设施的新战场

价值链全景图

┌─────────────────────────────────────────────────────────┐
│  应用层（Claude Code / Agent 系统）                        │
│  ├── Prompt 结构优化（静态前缀 / 动态后缀）                  │
│  ├── Auto Compact（防止尾部爆炸）                         │
│  └── Cache Sharing（多组件复用前缀）                        │
├─────────────────────────────────────────────────────────┤
│  API 层（MaaS 厂商）                                       │
│  ├── Prompt Cache（前缀匹配）                              │
│  ├── TTL 管理（5min / 1h / 硬盘持久化）                     │
│  └── 定价策略（命中价 0.1x）                               │
├─────────────────────────────────────────────────────────┤
│  推理层（vLLM / TensorRT-LLM）                            │
│  ├── KV Cache（单请求内复用）                             │
│  ├── PagedAttention（显存管理）                            │
│  └── 量化（FP16 / INT8 / INT4）                           │
├─────────────────────────────────────────────────────────┤
│  模型层（Transformer 架构）                                 │
│  ├── 注意力机制（Q/K/V 计算）                              │
│  ├── MLA 压缩（DeepSeek 创新）                             │
│  └── 前馈网络（FFN）                                       │
└─────────────────────────────────────────────────────────┘

核心洞察：

1. KV Cache 解决单请求内的重复计算，把 O(n²) 降到 O(n)
2. Prompt Cache 解决跨请求的重复计算，把长尾成本降到脚踝
3. DeepSeek 的 MLA + 硬盘缓存，把「缓存」从显存解放到磁盘，实现了极致的低价
4. Token 中间商的利润空间，正被透明的缓存机制压缩
5. Claude Code 的源码，展示了工程层面如何把缓存用到极致

给开发者的三句话：

• 保持前缀稳定 —— 这是缓存生效的第一前提
• 早 compact，不要攒 —— 越晚 compact，冤枉钱越多
• 缓存命中的 token 几乎免费 —— 在 DeepSeek 上，加上下文比减上下文更划算

参考与延伸

• Wilson Wu: 深入理解 KV-Cache - https://wilsonwu.me/blog/2025/kv-cache-in-llm/
• 番石榴 AI: 大模型推理优化技术 - KV Cache - https://zhuanlan.zhihu.com/p/700197845
• 田歌: 一块被忽视的算力金矿：关于 Prompt Caching - https://www.51cto.com/aigc/11620.html
• Sam Rose (Ngrok): Prompt Caching 技术博客 - https://developer.volcengine.com/articles/7587308087636459574
• DeepSeek API 文档: 上下文硬盘缓存 - https://api-docs.deepseek.com/zh-cn/news/news0802
• yeasy: Claude 技术指南 - 提示缓存 - https://yeasy.gitbook.io/claude_guide/di-si-bu-fen-shi-zhan-pian/10_optimization/10.2_caching
• 腾讯云: Claude Code Prompt Cache 深度解析 - https://developer.aliyun.com/article/1732421
• 21 财经: 月入 500 万、毛利 50%，揭秘 AI 圈的 Token 二道贩子 - https://www.21jingji.com/article/20260506/herald/5b6fb5497a3a0bb307e1f01363780b88.html

#tag #KVCache #PromptCache #DeepSeek #ClaudeCode #缓存 #大模型推理 #API定价 #成本优化 #小凯