缓存命中deepseek

很多人第一次看到 DeepSeek 账单里出现「缓存命中」和「缓存未命中」两个单价，会以为系统算错了，或者以为开了缓存就一定便宜。实际上命中与否取决于你的请求前缀长得一样不一样，跟开不开某个开关没关系。这篇按「先看懂计价、再确认命中、最后想办法提高命中」的顺序讲，适合已经在跑固定系统提示词、批量任务的开发者对照排查。

不少人第一次看 DeepSeek 的账单，会看到「缓存命中」和「缓存未命中」两个不同的输入单价，然后怀疑是不是系统算错了。其实这跟开不开某个开关没关系，命中与否只取决于你这次请求的前缀跟之前发过的长得一样不一样。前缀重复了，重复那部分就按更便宜的价算；没重复，全价。就这么简单。

这篇按三步走：先搞清楚账单上那两行数怎么来的，再说怎么确认自己到底命中了没有，最后讲怎么把重复前缀固定下来提高命中率。适合已经在跑固定系统提示词、批量处理任务的开发者对照排查。如果你每次请求内容都完全不一样，那这套东西对你用处不大，后面也写了不适用的情况。

缓存命中的钱是怎么算出来的

一次调用的输入成本不是单一价格，而是被拆成两段来算的：重复前缀覆盖到的那部分 token 走「缓存命中」价，剩下新写的部分走「未命中」价，两段加起来才是这次调用的输入总成本。所以账单上出现两个数字是正常的，不是重复收费，也不是把同一次调用算了两次。

命中段

本次请求的前缀与之前某次请求逐字节相同的那部分 token

未命中段

本次请求里新增加、之前没出现过的内容，第一次必然走这个价

折扣比例

不同时期不一样，到 DeepSeek 官方价格与规格页核对当时的数字

怎么确认自己到底命中了没有

光看账单总额看不出命中情况，得回到接口返回的用量字段里去核对。有些客户端会把命中与未命中的 token 数合并成一个总数给你，那种口径下你没法验证，只能从底层原始响应或者网关日志里翻。

• 先看接口返回的用量结构里，命中与未命中是不是分开给的两个字段，只给一个 total 就没法核对
• 拿当次用量按两个单价分别乘一遍，加起来跟账单金额对上，说明确实命中了
• 对照站内真实用量榜看同类任务的量级，判断自己的命中比例是不是偏低
• 如果连续多次请求命中段几乎为零，说明你的前缀拼接方式可能有隐藏差异

比较常见的坑是看着像一样、实际不一样。比如系统提示里嵌了当天日期、会话 ID、随机排序的示例，每次生成出来的字符串都不同，命中段自然就是零。这种情况不是缓存坏了，是你自己把前缀写成了每次都不一样。

把重复前缀固定下来，命中率才上得去

想让命中段真的起来，核心就一件事：把不变的东西放最前面并保持逐字节一致，把会变的东西一律往后挪。顺序错了、中间插了变量，前面拼得再长也白搭。

1. 固定前缀内容把系统提示、few-shot 示例、固定参考文档按固定顺序拼在最前面，改一个空格或换行都可能导致整段失效
2. 把变量挪到后面用户问题、时间戳、随机 ID、动态选取的示例，全部放在固定前缀之后，别插在中间
3. 批量任务集中连发同一份长前缀的请求尽量连着发，中间别穿插别的短请求，避免前缀被挤掉
4. 多轮问答先铺长文档长文档场景先把文档作为前缀发一次，后续轮次只在尾部追加新问题，不要每轮重发整份文档

哪些情况下这套做法不适用

缓存命中不是万能药，有些场景折腾半天也省不了多少，甚至根本用不上。判断标准很简单：你的请求之间有没有一段稳定重复的长前缀。没有的话，优先去优化别的地方。

• 前缀本身就很短，命中段省下的量极小，花时间重构模板不划算，按原样写更省事
• 每次请求内容天然完全不同，比如一次性翻译、独立问答，没有可复用前缀，缓存基本用不上
• 任务间隔很长，缓存有存活时间，隔太久再发同样的前缀可能已经失效，别假设它还在
• 前缀里混了动态内容又不好拆的，先拆干净再谈命中，拆不动就别硬上

一套可复用的排查顺序

遇到账单对不上、或者命中率莫名其妙低的时候，按下面这个顺序走一遍，基本能定位到问题在哪。别一上来就改代码，先把证据捞出来。

1. 捞字段从用量日志里把命中与未命中两个字段单独拿出来，不要只看总 token 数
2. 挑样本比对抽三条请求，把各自的前缀原样贴出来逐字符比对，看到底从第几个字符开始出现差异
3. 固化成模板把差异位置之前的公共部分固化成一个模板，调整代码里的拼接顺序，把变量统一挪到后面
4. 复跑对账用同样的任务再跑一轮，重新对一次账单，看命中段占比有没有变化

这套流程的价值在于把「感觉命中了」变成「账上能对上」。真要看当期单价和折扣数字，别信别人转述，到站内价格页面按当时的数字核对一遍更靠谱。