06 DeepSeek 的缓存，硬盘缓存和极端价差

DeepSeek 的 Context Caching 很值得单独讲，因为它和 Claude、OpenAI 的体感差异很大。

Claude 需要管理 cache_control，OpenAI 自动做前缀缓存。DeepSeek 也默认开启，但它明确叫上下文硬盘缓存。用户不需要改代码，每次请求都会触发缓存构建；后续请求如果和之前请求有重叠前缀，重叠部分就有机会从缓存里读取。

DeepSeek 的关键点在于：前缀要先被持久化成一个完整的 cache prefix unit。

官方文档里说得很明确：后续请求只有完整匹配某个已经持久化的 cache prefix unit，才能命中缓存。

这和简单理解的“前面有一段相同就一定命中”有差别。

举个简化例子：

第一次：A + B
第二次：A + B + C

第二次可以命中 A + B，因为第一轮请求结束后，A + B 已经成为一个 cache prefix unit。

但如果是这样：

第一次：A + B
第二次：A + C

第二次未必能直接命中。因为之前持久化的是 A + B，而 A + C 没有完整匹配这个 unit。

不过 DeepSeek 会检测多次请求之间的 common prefix。前两次请求都带着 A，系统可能会把 A 持久化成新的 cache prefix unit。等第三次请求变成：

第三次：A + D

这时就有机会命中 A。

这个机制对长文档问答、长上下文复用、Agent 连续任务都很重要。它意味着 DeepSeek 的缓存命中不只看“文本有没有重叠”，还要看这段重叠内容有没有被系统写成可匹配的缓存单元。

DeepSeek 文档里提到三类持久化位置：

这几个规则解释了为什么 DeepSeek 有时第一轮、第二轮看起来没命中，第三轮反而开始命中。缓存构建需要几秒钟，系统也会在后台整理 prefix unit。

DeepSeek 的 usage 字段很直观：

prompt_cache_hit_tokens

表示本轮输入里命中缓存的 token。

prompt_cache_miss_tokens

表示本轮输入里没有命中缓存的 token。

这两个字段比只看总 input token 有用得多。因为 DeepSeek 的 hit 和 miss 价格差距非常大。

价格这里要直接看官方人民币价格。

按 DeepSeek 当前中文价格页，deepseek-v4-flash 的 100 万 input token：

deepseek-v4-pro 的 100 万 token：

这组价格放在一起看，差距非常夸张。Flash 的 hit / miss 输入价格差 50 倍；Pro 的 hit / miss 输入价格差 120 倍。

对 DeepSeek 来说，cache hit 会直接决定这一轮长输入是几分钱级别，还是几块钱级别。

我自己在五一期间跑过一批 DeepSeek 调用，总量大约 15 亿 token，最后花费不到 50 元人民币。平均下来，大约是 0.033 元 / 100 万 token。

这个数字放在普通 input 价格下很难成立。它说明真正影响总成本的关键，已经从标价表上的 cache miss 单价，转向大量重复上下文有没有落到 cache hit 档位。

DeepSeek 这家公司也确实有点 AI 菩萨的味道。

它原本定价并不低，后来做过一轮优惠活动，价格打到 2.5 折，也就是原价的四分之一。更离谱的是，活动快结束时，它没有把价格拉回去，直接把原价改成了优惠价。对长期跑长上下文任务的人来说，这种定价方式比单纯发一轮限时优惠实在得多。

这也是为什么 DeepSeek 特别适合讨论中转站和网关账单。

如果网关只告诉你总 input token，不区分 prompt_cache_hit_tokens 和 prompt_cache_miss_tokens，你根本看不出上游到底用了哪种价格。上游大量命中缓存，网关仍然按普通 input token 给用户计费，用户也很难从账单里发现。

还有几个边界也要记住。

DeepSeek 的缓存只匹配输入前缀，输出仍然每次生成，会受 temperature 等参数影响。它也不承诺 100% 命中，官方说是 best-effort。缓存不用之后会自动清理，一般是几小时到几天。

所以 DeepSeek 缓存的工程重点是：

Claude 的缓存强调显式控制，OpenAI 的缓存强调自动路由，DeepSeek 是默认开启的磁盘 prefix 复用系统。它的使用门槛很低，但账单解释一定要看 hit / miss。对长上下文和 Agent 场景来说，这个差异会直接反映到成本上。