DeepSeek API 的“缓存命中”是指请求中已有的输入前缀复用了服务端先前保存的内容。它不是把上一次回答原样返回，也不是在你的电脑上生成一个可手工清理的缓存文件。判断是否命中，直接看响应 usage 中的 prompt_cache_hit_tokens 与 prompt_cache_miss_tokens，不要只凭“这次回答更快”猜测。
哪些内容有机会命中
DeepSeek 的官方上下文缓存说明写明，该能力默认启用，不要求开发者额外开启。服务端比较的是请求前部相同的内容：先前的前缀须已写入缓存，而且后续请求必须完整匹配一个已保存的前缀单元。把固定系统说明、同一份长资料放在前面，再在后面提出不同问题，才有复用前缀的机会。
例如，第一次请求包含“固定说明 + 文档 A + 问题 1”，第二次包含“固定说明 + 文档 A + 问题 2”。这两次虽然有共同开头，但不保证第二次立即命中；官方示例说明，服务端可能在观察到共同前缀后保存新单元，后续请求才命中。把问题写在文档前面、每次改动系统说明或改变文档顺序，都会改变前缀，降低命中可能。
从真实 API 响应读取计量字段
如果你已有可用的 DeepSeek API 调用代码，先关闭流式输出，查看一次完整响应中的 usage。下面是字段位置示意，数值是为了说明读法而虚构的，不是本文实测结果：
{
"usage": {
"prompt_tokens": 1200,
"prompt_cache_hit_tokens": 800,
"prompt_cache_miss_tokens": 400
}
}示意响应中，800 个输入 token 计为命中，400 个计为未命中。以实际接口返回为准；先保存原始响应，再用下面的 Python 代码读取字段：
usage = response["usage"]
hit = usage.get("prompt_cache_hit_tokens", 0)
miss = usage.get("prompt_cache_miss_tokens", 0)
print(f"命中输入 token: {hit}; 未命中输入 token: {miss}")代码假设 response 是 JSON 解析后的字典；如果你使用的 SDK 返回对象，应按它的实际对象结构读取。官方文档明确给出这两个字段的含义。不要把 prompt_tokens、命中 token 和未命中 token 随意相加，先以当前接口说明核对统计口径。
做一个可复核的小实验
- 固定模型、系统说明及一段你有权使用的脱敏资料；记录请求体中的消息顺序。
- 用这段固定前缀分别提两个不同问题，保存每次响应的
usage和请求时间。 - 保持前缀完全一致，再提出第三个问题，查看
prompt_cache_hit_tokens是否大于零。 - 最后故意改动前缀开头的一句话，再请求一次，比较命中字段。不要把输出文字不同误判为缓存失效。
如果第三次仍未命中，先核对模型、消息顺序、空格及资料内容是否真的一致。即使一致，也不能承诺必定命中：前缀需要被持久化，缓存策略和时间条件由服务端决定。官方文档还说明，输出仍由模型推理生成，温度等设置仍可能影响文字，因此“缓存命中”不等于“答案确定相同”。
何时值得为缓存调整提示词
你反复处理同一份较长资料、只在末尾更换问题时，可以把稳定内容放前面，并用实际 usage 比较。只问一次的短问题，或每次资料都不同的任务，没必要为了追求命中而牺牲提示词清晰度。费用和延迟是否改善，需按当前官方价格、实际命中字段与同一环境中的测量结果分别核对；本文不承诺节省比例。
本文解释的是 DeepSeek 在线 API 的服务端机制，不能套用到通过 Ollama 运行的本地 DeepSeek 模型。阅读和示例均未使用你的 API 密钥做实测。
Ai菜鸟网。发布者：AI小管家，转载请注明出处：https://www.alyyhw.com/29739.html
