DeepSeek 缓存省钱的关键是精确匹配

DeepSeek 的上下文缓存默认开启，但开启不等于命中。原文想纠正的误解是：反复发送相似内容，就能自动享受低价。实际决定账单的是输入前缀有没有匹配已落盘的完整缓存单元，以及响应里究竟记录了多少命中 token。

作者给出的例子中，缓存让重复文档问答的输入费用降低约 94%。这个数字有明确前提。对写 AI 应用、接入 coding agent 的程序员，更有用的是理解命中规则、调整消息顺序，再用真实用量验证。

为什么同一份文档，第二次提问仍可能不命中

原文所说的缓存叫 Context Caching on Disk，缓存保存在磁盘上，作用于输入前缀。后续请求复用已有计算结果，相应输入 token 按命中价格收费。它按账户自动启用，不需要开关、主动申请或修改代码。

这里有两道门槛：内容必须从开头匹配，还必须匹配一个已经持久化的完整缓存单元。仅有一段相同内容，并不足以保证命中。

作者用文档问答解释这个过程。设 A 是长文档，B、C、D 是不同问题：

• 第一次发送 A + B，系统保存相应缓存单元。
• 第二次发送 A + C，虽然文档相同，但没有完整匹配 A + B，因此仍可能未命中。
• 系统识别两次请求的共同前缀 A，把 A 单独持久化。
• 第三次发送 A + D，才可以匹配缓存单元 A。

原文将这套规则与 DeepSeek-V4 使用的滑动窗口注意力（Sliding Window Attention）联系起来。对调用方而言，最实用的理解是：不能把缓存想成一个能从任意位置取用的文本仓库。

重复内容要放在前面，还要经过缓存预热，才有机会持续享受命中价。

多轮对话通常更适合这套机制。只要保留历史并继续追加，下一轮输入会包含上一轮输入和模型回复，可以复用截至模型输出处的缓存单元。每次重新构造请求、只保留固定文档的无状态问答，则可能需要前一两次请求预热。

不过，原文有一处内容缺失：它提到官方指南列出三类缓存持久化时机，却没有实际列出三项。仅凭给出的文章，无法补全这份规则清单。

50 倍差价，到底能省下多少钱

先限定数字的有效范围：作者声明，价格和规则核对于 2026-09-19，文章也写于 2026 年 9 月 19 日。下面是这份快照中的数据，不能直接当成此后的实时报价。

按每 1M 输入 tokens 计算，非高峰价格如下：

模型	缓存命中	缓存未命中	未命中与命中价之比
deepseek-flash	$0.003	$0.15	50 倍
deepseek-v4-pro	$0.022	$0.66	30 倍

这两个倍数针对输入 token 单价，不代表整次请求或整个应用便宜同样倍数。输出 token 的收费不受这项缓存折扣影响。

作者的算例是一份 500K-token 文档，连续回答 50 个独立问题，每次重新发送文档，不维护对话状态。忽略较短的问题内容，共计发送 25M 输入 tokens。

如果全部按非高峰未命中价收费，deepseek-flash 的输入成本是：

25 × $0.15 = $3.75。

如果前两次未命中，后面 48 次均命中文档部分，就约有 1M 未命中 tokens 和 24M 命中 tokens，成本为：

$0.15 + 24 × $0.003 ≈ $0.22。

约 94% 的降幅来自这组假设下的算术推导。原文没有展示请求日志或实际账单，因此不能把它当作作者已经测出的生产收益。

非高峰折扣还能叠加。原文给出的高峰时段为周一至周五 UTC 01:00–04:00、06:00–10:00，对应北京时间 09:00–12:00、14:00–18:00；其他时间为非高峰，费率是高峰的 50%。

作者还比较了 deepseek-v4-pro 的高峰未命中价 $1.32，与 deepseek-flash 的非高峰命中价 $0.003，得到 440 倍差距。这个数字跨了模型、时段和缓存状态，不能理解为单靠缓存就能省下 440 倍。

怎样知道提示词正在悄悄破坏缓存

最直接的证据在响应的 usage 对象里：

• prompt_cache_hit_tokens：从缓存获取、按命中价计费的输入 tokens。
• prompt_cache_miss_tokens：重新计算、按未命中价计费的输入 tokens。

接入 API 后，应先看前几次真实请求，而不是因为缓存默认开启，就在预算里假设全部命中。

作者指出，时间戳、request ID、当天日期等动态内容如果放在 system prompt 开头，会改变后续内容赖以匹配的前缀。固定规则、固定材料应尽量靠前，当前问题和其他变量靠后。

连续请求的命中数始终为零时，输入开头变化是优先排查项；长对话进行到一半，命中量突然下降，则可以检查历史中间是否发生了改写。不过，零命中也可能涉及预热、失效等因素，不能只凭一个指标断定根因。

缓存也有寿命。原文引述的口径是，停止使用后通常会在几小时到几天内清理。每天夜间执行的任务可能保持温热，隔一周再执行的任务可能重新付出预热成本，这都不是承诺。

此外，缓存属于尽力提供的服务，不保证 100% 命中。它复用的是输入前缀计算，生成阶段仍受 temperature 等采样设置影响，所以命中相同缓存也可能得到不同措辞。第三方转售端点是否提供同样折扣，也需要单独确认。

我的判断

原文最有用的地方，是把优化对象从「提示词写得像不像」拉回了「请求结构是否稳定」。对于固定 system prompt、持续追加历史的 coding agent，这个方向有实际意义：频繁改写前部内容，会削弱后续复用机会。

但「通常前一两次后命中率就上来」只能作为工作流预期。缓存失效、服务侧尽力策略、实际消息组织方式，都会影响结果。原文没有对照实验，也没给出不同工作负载的命中率分布，不能据此推断一般团队都能获得约 94% 的收益。

作者运营 AI API 价格比较网站，并声明没有联盟链接。文章提供了清晰的计算方法，但没有足够证据证明这些数字来自完整实测。把它当成计费机制解读和排查线索比较合适。

还要区分容量与经济性。原文称 V4.1-Flash 和 V4 Pro 都支持最高 1M-token 上下文；这与前文的 deepseek-flash、deepseek-v4-pro 命名如何对应，没有交代清楚。容量上限也不代表每次都应该填满。缓存能降低重复输入的单价，裁剪无关上下文则直接减少输入数量，两种办法可以一起用。

能拿来做什么

1. 在 Node API 调用层记录 prompt_cache_hit_tokens 和 prompt_cache_miss_tokens，按任务汇总实际命中比例，并把输入、输出费用分别计算，避免用输入折扣估算整个应用成本。

2. 检查消息拼装顺序，把固定规则和反复使用的文档放在前面，把日期、request ID、当前问题等动态内容尽量后置，同时保留业务所需的指令优先级。

3. 为重复文档问答和 coding agent 各跑一组真实请求，检查预热后的命中变化；历史裁剪、摘要或重写发生后，再观察缓存是否受到影响。

4. 对可延后的批处理任务，结合非高峰时段估算费用；使用第三方端点时，先确认它是否区分命中与未命中价格，再代入自己的用量计算。