给 DeepSeek 连续发送同一份材料第二次却没看到缓存命中不一定需要申请一个“缓存开关”。本文面向已能完成 Chat Completions 调用的新手用固定资料与变化问题做小规模对照检查前缀稳定性和 usage 计数。依据 2026 年 10 月 15 日官方说明整理未在读者账号实测不承诺命中比例、速度或节省金额。1. 先读取用量再判断是否未命中DeepSeek 当前官方说明上下文硬盘缓存默认启用并且按已经落盘的前缀单元匹配命中是尽力而为不保证每次成功。上下文硬盘缓存 因此只看响应耗时很难可靠判断是否使用了缓存。最短检查是在一条正常完成的非流式响应里读取 usage输入总 Token、命中 Token、未命中 Token。Token 是模型处理文本的单位不等于汉字数也不等于 HTTP 请求体的字节长度。官方 API 文档给出 prompt_cache_hit_tokens 与 prompt_cache_miss_tokens并说明它们与 prompt_tokens 的关系。Chat Completions API 如果 SDK 对非标准字段做了封装可查看它导出的响应对象字段缺失时先确认接入方式不能把缺失直接当作零。不要为了做缓存测试增加无用的超长材料。选取一份你本来需要反复问答的虚构规则使用相同模型与相同接入路径做少量请求即可。测试本身也可能产生费用。2. 固定资料在前变化内容放后准备一份虚构活动规则包含报名日期、物品种类、领取位置和联系人角色等多条信息保存为稳定文本。问题分别问“在哪里领取”“哪些物品可领”“何时截止”但不要每次重新排序规则段落。把稳定的角色说明和资料放在消息开头变化的问题放后面。不要在最前面添加每次不同的时间戳、随机请求编号或日志摘要如果这些信息确有业务意义应保留只是可以考虑它们的合理位置不能为了缓存而改变任务含义。组成部分是否在多次请求中稳定推荐处理固定规则说明是保持文本与顺序一致同一份资料是直接复用已保存内容本次具体问题否放在资料之后影响答案的实时状态否如实传入不为命中隐藏这里说的是输入前缀不是语义相似。两段规则意思一样但字句、顺序或消息结构改变并不能自动视作相同前缀。也不要把原始规则重新交给模型改写后再测试这样每次输入可能已经发生变化。3. 记录三次用量不写死第二次必命中当前官方文档解释公共前缀识别与落盘有自己的时机。首次请求完成后换一个问题并不意味着第二次一定命中后续请求需要匹配已建立的前缀单元。本文不把某个固定轮次作为所有模型和请求的保证。下面代码只分析你已保存的三份非流式响应 JSON不发送新请求。把实际结果分别保存为 cache-a.json、cache-b.json、cache-c.json在本地 Python 3 环境运行。文件应保存在自己控制的目录不含需要公开分享的密钥。importjsonfrompathlibimportPathfornamein[cache-a.json,cache-b.json,cache-c.json]:usagejson.loads(Path(name).read_text(encodingutf-8))[usage]hitusage.get(prompt_cache_hit_tokens)missusage.get(prompt_cache_miss_tokens)totalusage.get(prompt_tokens)ifany(notisinstance(n,int)orn0fornin[hit,miss,total]):print(name,缺少有效计数请检查响应来源)continueifhitmiss!total:raiseValueError(输入计数不一致)ratiohit/totaliftotalelseNoneprint(name,{input:total,hit:hit,miss:miss,ratio:ratio})命中比例是本次输入中的计数比例不是整体费用折扣。输出 Token 仍需生成输入与输出价格也不是同一个量。本文不提供过期价格或根据一次样本推算长期收益。4. 计数为零时检查实际发送的前缀先比较三次发送到服务端的 messages 结构和内容。你的本地模板稳定不代表代理层没有在开头插入时间、工具说明或其他上下文。测试副本可以保存脱敏后的请求结构但不要把真实客户材料与认证头写进公开日志。接着核对模型、服务商和接口路径是否相同。本文讨论 DeepSeek 官方 API 的响应行为其他平台即便提供相似模型也可能有不同缓存实现或字段不应直接套用计数结论。如果只在请求中间有一段相同材料前面却已经变化这不等同于稳定前缀。根据任务语义整理输入顺序但不要删掉必要的安全规则或用户条件。正确性优先于命中不能为了复用前缀让答案基于错误上下文。如果前缀一致仍然没有命中保留有限样本后停止反复预热。官方明确提示缓存不是百分之百保证也会自动清理。更换模型、时隔较久、服务状态等因素需要结合具体证据判断不猜测内部节点路由机制。5. 命中不是答案缓存也不是会话记忆缓存复用的是输入处理的一部分模型仍然计算当前输出。同样输入可能生成不同措辞不能用“回答一模一样”证明命中也不能用措辞不同证明缓存失效。后续问题需要的资料仍应在请求中正确提供。不要因为前一轮命中过就删掉材料只发一个问题期待硬盘缓存替你保存会话。聊天历史管理与输入缓存是两个任务分别检查才能避免为了省输入而丢失关键信息。把对照结果与答案质量一起记录资料版本、模型名、输入计数、命中计数以及是否答对规则字段。如果调整顺序后命中改善但答案开始漏条件应先修内容组织不把更高命中率当成最终目标。统计多次请求时用命中 Token 总和除以输入 Token 总和而不是简单平均每次百分比否则一个极短请求会获得与长请求相同的权重。发生失败或缺少 usage 的请求单列说明不把它们强行填成零后混入完整样本。需要估算费用时再按当前官方定价分别计算命中输入、未命中输入与输出不能只套一个统一折扣。成功完成这项排查意味着你能区分字段缺失、真实零命中和部分命中并能解释前缀是否稳定。把稳定内容保持稳定、把必要变化如实传入、用实际 usage 观察结果就足以建立一个可靠的缓存诊断起点。参考资料上下文硬盘缓存DeepSeek更新时间未显示。Chat Completions APIDeepSeek更新时间未显示。访问于 2026-10-15。
给 DeepSeek 连续发送同一份材料第二次却没看到缓存命中不一定需要申请一个“缓存开关”。本文面向已能完成 Chat Completions 调用的新手用固定资料与变化问题做小规模对照检查前缀稳定性和 usage 计数。依据 2026 年 10 月 15 日官方说明整理未在读者账号实测不承诺命中比例、速度或节省金额。1. 先读取用量再判断是否未命中DeepSeek 当前官方说明上下文硬盘缓存默认启用并且按已经落盘的前缀单元匹配命中是尽力而为不保证每次成功。上下文硬盘缓存 因此只看响应耗时很难可靠判断是否使用了缓存。最短检查是在一条正常完成的非流式响应里读取 usage输入总 Token、命中 Token、未命中 Token。Token 是模型处理文本的单位不等于汉字数也不等于 HTTP 请求体的字节长度。官方 API 文档给出 prompt_cache_hit_tokens 与 prompt_cache_miss_tokens并说明它们与 prompt_tokens 的关系。Chat Completions API 如果 SDK 对非标准字段做了封装可查看它导出的响应对象字段缺失时先确认接入方式不能把缺失直接当作零。不要为了做缓存测试增加无用的超长材料。选取一份你本来需要反复问答的虚构规则使用相同模型与相同接入路径做少量请求即可。测试本身也可能产生费用。2. 固定资料在前变化内容放后准备一份虚构活动规则包含报名日期、物品种类、领取位置和联系人角色等多条信息保存为稳定文本。问题分别问“在哪里领取”“哪些物品可领”“何时截止”但不要每次重新排序规则段落。把稳定的角色说明和资料放在消息开头变化的问题放后面。不要在最前面添加每次不同的时间戳、随机请求编号或日志摘要如果这些信息确有业务意义应保留只是可以考虑它们的合理位置不能为了缓存而改变任务含义。组成部分是否在多次请求中稳定推荐处理固定规则说明是保持文本与顺序一致同一份资料是直接复用已保存内容本次具体问题否放在资料之后影响答案的实时状态否如实传入不为命中隐藏这里说的是输入前缀不是语义相似。两段规则意思一样但字句、顺序或消息结构改变并不能自动视作相同前缀。也不要把原始规则重新交给模型改写后再测试这样每次输入可能已经发生变化。3. 记录三次用量不写死第二次必命中当前官方文档解释公共前缀识别与落盘有自己的时机。首次请求完成后换一个问题并不意味着第二次一定命中后续请求需要匹配已建立的前缀单元。本文不把某个固定轮次作为所有模型和请求的保证。下面代码只分析你已保存的三份非流式响应 JSON不发送新请求。把实际结果分别保存为 cache-a.json、cache-b.json、cache-c.json在本地 Python 3 环境运行。文件应保存在自己控制的目录不含需要公开分享的密钥。importjsonfrompathlibimportPathfornamein[cache-a.json,cache-b.json,cache-c.json]:usagejson.loads(Path(name).read_text(encodingutf-8))[usage]hitusage.get(prompt_cache_hit_tokens)missusage.get(prompt_cache_miss_tokens)totalusage.get(prompt_tokens)ifany(notisinstance(n,int)orn0fornin[hit,miss,total]):print(name,缺少有效计数请检查响应来源)continueifhitmiss!total:raiseValueError(输入计数不一致)ratiohit/totaliftotalelseNoneprint(name,{input:total,hit:hit,miss:miss,ratio:ratio})命中比例是本次输入中的计数比例不是整体费用折扣。输出 Token 仍需生成输入与输出价格也不是同一个量。本文不提供过期价格或根据一次样本推算长期收益。4. 计数为零时检查实际发送的前缀先比较三次发送到服务端的 messages 结构和内容。你的本地模板稳定不代表代理层没有在开头插入时间、工具说明或其他上下文。测试副本可以保存脱敏后的请求结构但不要把真实客户材料与认证头写进公开日志。接着核对模型、服务商和接口路径是否相同。本文讨论 DeepSeek 官方 API 的响应行为其他平台即便提供相似模型也可能有不同缓存实现或字段不应直接套用计数结论。如果只在请求中间有一段相同材料前面却已经变化这不等同于稳定前缀。根据任务语义整理输入顺序但不要删掉必要的安全规则或用户条件。正确性优先于命中不能为了复用前缀让答案基于错误上下文。如果前缀一致仍然没有命中保留有限样本后停止反复预热。官方明确提示缓存不是百分之百保证也会自动清理。更换模型、时隔较久、服务状态等因素需要结合具体证据判断不猜测内部节点路由机制。5. 命中不是答案缓存也不是会话记忆缓存复用的是输入处理的一部分模型仍然计算当前输出。同样输入可能生成不同措辞不能用“回答一模一样”证明命中也不能用措辞不同证明缓存失效。后续问题需要的资料仍应在请求中正确提供。不要因为前一轮命中过就删掉材料只发一个问题期待硬盘缓存替你保存会话。聊天历史管理与输入缓存是两个任务分别检查才能避免为了省输入而丢失关键信息。把对照结果与答案质量一起记录资料版本、模型名、输入计数、命中计数以及是否答对规则字段。如果调整顺序后命中改善但答案开始漏条件应先修内容组织不把更高命中率当成最终目标。统计多次请求时用命中 Token 总和除以输入 Token 总和而不是简单平均每次百分比否则一个极短请求会获得与长请求相同的权重。发生失败或缺少 usage 的请求单列说明不把它们强行填成零后混入完整样本。需要估算费用时再按当前官方定价分别计算命中输入、未命中输入与输出不能只套一个统一折扣。成功完成这项排查意味着你能区分字段缺失、真实零命中和部分命中并能解释前缀是否稳定。把稳定内容保持稳定、把必要变化如实传入、用实际 usage 观察结果就足以建立一个可靠的缓存诊断起点。参考资料上下文硬盘缓存DeepSeek更新时间未显示。Chat Completions APIDeepSeek更新时间未显示。访问于 2026-10-15。
