DeepSeek 上下文缓存与成本优化：命中规则、观测与实践

DeepSeek 的上下文缓存对所有用户默认开启，不需要添加 use_cache 参数。缓存按输入前缀匹配：后续请求复用已持久化的相同前缀时，相关输入 Token 才可能命中。

一、把稳定内容放在前面

系统提示、输出规则、长文档和固定示例适合放在消息前部；每次变化的用户问题放在后面。若在前缀中插入时间戳、随机 ID 或动态文本，后续内容即使相同也可能无法复用。

推荐顺序：
1. 固定系统指令
2. 固定格式说明与示例
3. 可复用的长文档
4. 本次请求的动态问题

二、从响应中观察命中

响应的 usage 中包含 prompt_cache_hit_tokens 和 prompt_cache_miss_tokens。请把两项都纳入监控，不要根据“请求看起来相似”推断命中。

usage = response.usage
print('hit:', usage.prompt_cache_hit_tokens)
print('miss:', usage.prompt_cache_miss_tokens)

三、理解缓存边界

• 缓存是尽力而为机制，不承诺每次都命中。
• 缓存构建需要时间，长时间不用的内容会被自动清理。
• 缓存复用输入前缀，不会固定模型输出；输出仍会重新生成。
• 涉及不同终端用户时，应按官方规则使用 user_id 做隔离，且不要把隐私信息直接放入该字段。

四、成本计算原则

分别用缓存命中输入、未命中输入和输出 Token 乘以官方当日单价。价格可能调整，因此本站不在文章正文中固化金额；预算与结算请始终以官方价格页为准。