我把DeepSeek缓存命中率从5%提到70%，只改了一行代码

上周差点把咖啡喷键盘上——DeepSeek API 的账单在 3 小时内从 ¥47 飙到 ¥1,280。凌晨两点，我盯着那个数字看了整整五分钟，确认自己没看花眼。

原因？缓存失效。一个我自以为“肯定没问题”的小细节。

写这篇文章纯粹是想把我踩过的坑整理出来。用 DeepSeek API 快一年了，从最开始自己瞎捣鼓到后来接了三个商业项目，缓存这块的教训攒了不少——有些是用真金白银换来的。

缓存不是你想缓，想缓就能缓

先说个反直觉的事。

DeepSeek 的缓存机制跟 OpenAI 完全不是一回事。

很多从 GPT 切过来的兄弟，惯性思维觉得“我传同样的 system prompt，它肯定自动缓存吧”。我之前也是这么想的。结果被现实狠狠教育了。

看个真实数据。我有个客服机器人的项目，去年 11 月上的线，每次对话传一段 2000 多字的 system prompt，里面塞了产品手册、FAQ、话术规范。我当时想当然以为 DeepSeek 会像 GPT-4 那样自动命中缓存。跑了一周之后拉 API 日志一看：

| 场景 | 预期缓存命中 | 实际缓存命中 | 单次成本 |

|------|------------|------------|---------|

| 相同 system prompt，不同 user query | 应该命中 | 0% | ¥0.018 |

| 连续 50 轮对话，上下文累积 | 部分命中 | 约 12% | ¥0.023 |

0%。

我看到这个数字的时候真的人傻了。后来翻了半天文档（顺便吐槽一下，DeepSeek 的官方文档写得确实不如 OpenAI 的清晰），才发现他们的缓存策略跟 prompt 的结构稳定性强相关——不是内容相同就行了。具体来说，token 边界对齐要求比 GPT 严格得多。GPT 在这方面做了大量模糊化处理，DeepSeek 目前还没做到这个程度。

缓存失效的三大元凶

我把自己遇到的缓存失效场景归成了三类。这三类基本覆盖了我 90% 以上的踩坑记录。

1. Prompt 结构漂移

这个坑我踩得最深。简单说就是：你以为传的是同一个 prompt，实际上每次都有微小差异。

举个例子。我之前写了个自动生成周报的工具，prompt 模板长这样：

你是一个专业的周报撰写助手。今天是{date}，请根据以下工作内容生成周报：
{work_content}

看着没问题对吧？

但 {date} 是动态插入的，每次调用都会变成"2025年1月15日"、"2025年1月16日"……DeepSeek 看到的是完全不同的字符串，缓存直接失效。我当时的日调用量大概 3000 次，缓存命中率不到 5%。

后来怎么解决的？把日期挪到 user message 里，system prompt 保持绝对静态。命中率瞬间飙到 70% 以上。就改了一行代码。

教训：system prompt 里一个标点都别动，动态内容全部下沉到 user message。

等等，这里我要更正一下——不是所有动态内容都能下沉。比如角色扮演场景里，有些核心设定确实需要动态调整。这种情况我的做法是：把 system prompt 拆成"静态骨架"和"动态皮肤"两部分，静态部分放 system，动态部分放当轮 user message 的最前面，用特定标记包裹。这样至少骨架部分能稳定命中缓存。实测下来比全部塞 system 好太多了。

2. 上下文长度触发的隐式失效

这个是去年 12 月在一个长文档摘要项目里发现的，当时 debug 了整整一个周末。

DeepSeek 的缓存有个特点：当上下文超过某个阈值，缓存策略会变得更保守。官方文档里没明确说这个阈值——至少我翻遍了 docs.deepseek.com 没找到。但我用不同长度的文档测了一周，数据大概是这样的：

• 文档 < 2K tokens：缓存命中率约 85%
• 文档 2K-4K tokens：缓存命中率约 60%
• 文档 > 4K tokens：缓存命中率骤降到 20% 以下

4K 这个数字是我用 deepseek-chat 模型测出来的。换成 deepseek-reasoner 可能会不一样，但我没测过，有测过的兄弟可以说一下。

我猜测是长上下文导致内部注意力机制的计算路径变化太大，之前缓存的 KV cache 没法复用。嗯...这个比较复杂，我其实也不太确定底层原理。有在 infra 团队搞过推理优化的朋友跟我说可能跟 DeepSeek 的 MoE 架构有关，专家路由在长上下文下会有切换。但这都是猜测，欢迎懂行的在评论区补充。

3. 多轮对话的缓存断裂

这个场景特别容易出现在客服、教育、心理咨询这类需要长对话的产品里。

我做过一个 AI 辅导老师的项目，对话轮次经常到 20 轮以上。每轮对话我都把历史消息传回去，messages 数组越来越长。然后我发现一个规律：第 8-10 轮之后，缓存命中率会断崖式下跌。

原因很简单：前面的对话历史一直在变，DeepSeek 没法把"前缀"缓存下来。每次新消息进来，整个上下文都是新的组合。这不是 bug，是前缀缓存的固有局限。GPT-4 也一样，只不过 GPT-4 在其他层面做了补偿，比如更激进的 prompt 压缩。

我现在的做法是：超过 10 轮对话后，用 DeepSeek-V2-Lite（deepseek-chat-lite，大概 ¥0.001/1K tokens 那个）对历史对话做摘要，把摘要塞进 system prompt，然后只保留最近 5 轮原始对话。这样 system prompt 虽然变了一次，但后续 5 轮都能稳定命中缓存。

实测下来，10 轮以上的长对话成本降低了约 40%，而且回复质量没明显下降——至少我的用户没投诉。有朋友问能不能用别的模型做摘要，我试过 GPT-3.5，跨厂商的 token 切分不一致，缓存命中率反而更低。别问我怎么知道的。

Prompt 工程设计的三个原则

基于上面这些教训，我给自己定了三条铁律。现在接新项目，第一件事不是写 prompt，而是按这三条过一遍。

第一，动静分离。 System prompt 写死。一个字都别动。所有变量、日期、用户信息、动态指令，全部放 user message 或者 assistant message 里。我现在的 system prompt 都是纯静态的角色定义和规则说明，连"你好"这种问候语都不放。放 user 里，别心疼那个 token。

第二，结构固定。 不只是内容固定，格式也要固定。比如你的 prompt 里有列表，就一直用列表；用了 Markdown 标题就一直用标题。别今天用 ### 明天用 **。DeepSeek 的分词器对这些符号很敏感——据我了解，他们用的是 BytePiece 分词器，跟 GPT 的 tiktoken 行为差异不小。格式变化可能导致 token 切分不同，缓存就废了。

第三，长度控制。 如果你做的是高并发场景（日调用 > 1万次），尽量把 system prompt 控制在 2K tokens 以内。这不是官方建议，是我自己测出来的性价比甜点。超过这个长度，缓存收益开始递减。大概是因为长 prompt 本身的推理成本就高，缓存省的那点钱被稀释了。

一个土办法

分享一个很土但很有效的方法。

DeepSeek 的 API 返回里有个 usage 字段，里面有个 prompt_tokens。如果你两次调用传了"相同"的 prompt，但 prompt_tokens 不一样，说明缓存没命中——因为命中的话，计费的 tokens 会大幅减少。

我写了个简单的 Python 脚本，每次调用都记录 prompt_tokens，然后对比连续两次调用的差值。差值接近 0 就是命中了，差值很大就是没命中。脚本大概长这样：

import json

last_tokens = None
with open("api_log.jsonl", "r") as f:
 for line in f:
 resp = json.loads(line)
 current = resp["usage"]["prompt_tokens"]
 if last_tokens:
 delta = current - last_tokens
 if delta > 100:
 print(f"⚠️ 缓存可能失效: delta={delta}")
 last_tokens = current

靠这个土办法，我定位到了好几个之前完全没意识到的缓存失效问题——包括上面说的日期变量、格式不一致、甚至是一个藏在 system prompt 角落里的多余空格。那个空格让我一个月多花了大概 ¥200，你敢信。

对了，有兄弟在 r/MachineLearning 上分享过用 prompt_tokens_details 里的 cached_tokens 字段直接看缓存命中量，更精准。不过这个字段 DeepSeek 我测的时候有时有有时没有，可能跟模型版本有关。2025 年 1 月之后的新版 API 好像稳定返回了，但我没验证过。

就这样吧。

现在我接新项目，第一件事不是写 prompt，而是先设计缓存策略。这个习惯帮我省了至少 60% 的 API 费用。说实话，省下来的钱够我再养一个兼职标注员了。

你们有没有遇到过类似的坑？或者有更好的缓存优化技巧？评论区聊聊，我也想知道是不是只有我一个人被这个坑过。

Edit：没想到这么多兄弟有共鸣。统一回复一下评论区问得多的：多轮对话摘要我现在用的是 deepseek-chat-lite，2024 年 12 月刚上的那个版本，成本几乎可以忽略。别用跨厂商的模型做摘要再喂回来，tokenizer 不一致，缓存命中率更低。真的，别试。

#DeepSeek #API优化 #Prompt工程 #缓存策略 #成本控制