prompt 缓存能省多少：把宣传的 90% 换算成你自己的数字

2026-08-07

每次有人问我「上了 prompt 缓存能省多少」，我都先反问一句：你的系统提示词有多长，用户那句话有多长，模型一次吐多少字？对方十有八九答不上来。答不上来就没法算——因为缓存能省多少，从来不是一个平台参数，而是你自己业务形态的函数。

宣传口径上那个「最高省 90%」是真的，但那三个字里最重要的是「最高」。它说的是缓存命中的那部分输入 token 的单价折扣上限，不是你账单总额的降幅。我见过太多人拿这个数字去做预算，上线一个月发现账单只掉了不到一成，然后回头骂缓存是智商税。它不是智商税，是你算错了分母。

这篇文章要做的事很简单：把「省多少」这个问题拆成一条四环的链路，每一环都告诉你什么情况下它会变小，然后用一组能逐项复算的数字，把宣传值和真实值的差距摆在你面前。

一、先搞清楚缓存到底作用在哪一档价上

现在带缓存的平台，计费表基本都是三档结构：输入 / 缓存输入 / 输出。这三档是分开计价的，缓存只动其中一档。

拿 DeepInfra 官方定价页上公开的价目做真实样本（$ / 每 100 万 token）：

模型	输入	缓存输入	输出
DeepSeek-V4-Pro	$1.30	$0.10	$2.60
DeepSeek-V4-Flash	$0.09	$0.018	$0.18
DeepSeek-V3.2	$0.26	$0.13	$0.38
DeepSeek-V3.1-Terminus	$0.27	$0.13	$0.95
DeepSeek-V3.1	$0.25	$0.13	$0.95

来源：DeepInfra 官方定价页（https://deepinfra.com/pricing），核对日期 2026-08-07。价格随时可能调整，下单前以官方定价页为准。本文只引用这一张表作为真实价格样本，其他平台的缓存价格、折扣比例、命中率数值本文一律不写——没核实过的数字不该出现在一篇教你算账的文章里。

先做一次最基础的除法。以 V4-Pro 为例，缓存输入相对普通输入的比例是：

0.10 ÷ 1.30 = 0.076923… ≈ 7.7%

也就是说，命中缓存的那部分输入 token，只按原价的 7.7% 计费，折扣幅度约 92.3%。这个数字比常见宣传口径的 90% 还漂亮一点。

但这里有个更值得注意的事：同一家平台，不同模型的折扣率完全不一样。把上表逐行算一遍：

模型	缓存输入 ÷ 输入	折扣幅度
DeepSeek-V4-Pro	7.69%	92.31%
DeepSeek-V4-Flash	20.00%	80.00%
DeepSeek-V3.2	50.00%	50.00%
DeepSeek-V3.1-Terminus	48.15%	51.85%
DeepSeek-V3.1	52.00%	48.00%

从 92.3% 到 48%，差了将近一倍。所以第一条实操结论：别用「缓存能省 90%」这种行业口头禅做规划，翻开你实际调用的那个模型那一行，自己做一次除法。

现在泼第一盆冷水。上面这个 92.3%，作用范围严格限定在已经命中的那部分输入 token 上：

输出一分不省。 V4-Pro 的输出价 $2.60，是输入价 $1.30 的两倍，缓存对这一档完全没有作用。
未命中的输入一分不省。 前缀变了、缓存过期了、走到别的节点上了，这次调用的输入就全额按 $1.30 计。
前缀之外的输入一分不省。 用户当前那句话、检索回来的文档片段、这一轮的对话历史，都是每次都在变的内容，从定义上就进不了缓存。

把这三句话合起来，就是下一节那条链路。

二、真实节省率的四环链路

真正决定你账单降幅的是这个式子：

实际节省率 = 前缀占比 × 命中率 × 缓存折扣率 × 输入成本占总成本的比重

四个乘数，任何一环变小，结果都会成比例缩水。而且它们天然都小于 1，所以四个数乘下来通常远比直觉低。逐环拆开看。

第一环：前缀占比

指的是「每次调用都逐字不变的那段开头」占总输入 token 的比例。系统提示词、工具/函数定义、常驻业务规则、少样本示例，这些属于前缀；用户输入、RAG 检索片段、对话历史，这些属于变化输入。

判定标准只有一条：从第一个 token 开始，连续有多少个 token 逐字不变。中间只要差一个字，从那个位置往后全部算变化输入。这一点非常反直觉——很多人以为「系统提示词就是前缀」，但如果你在系统提示词末尾拼了一句「当前时间是 2026-08-07 14:23:11」，那整段系统提示词的前缀身份就在那个时间戳处被截断了，后面的内容全部作废。

什么情况下前缀占比小：

系统提示词只有一两百字，用户每次贴进来的是几千字的合同、日志、代码文件。前缀占比可能连 5% 都不到，缓存基本没有发挥空间。
RAG 场景里检索片段放在系统提示词之前。位置一错，前缀直接归零。
多租户系统里把租户名、用户昵称拼在提示词最前面——每个用户一套前缀，等于没有共享缓存。

第二环：命中率

前缀占比说的是「理论上有多少可以缓存」，命中率说的是「这些可缓存的内容里，实际有多少真的命中了」。常见的掉命中率原因：

前缀不稳定。 时间戳、随机请求 ID、A/B 实验分组标记、动态拼接的用户画像，混进前缀里就会让每次调用的前缀都不一样。
请求间隔超过缓存有效期。 缓存不是永久的，各家的存活时间策略不同，具体值请查你所用平台的官方文档。低频调用的服务可能每一次都是冷启动，命中率接近 0。
前缀内部顺序漂移。 工具定义如果是从一个字典或集合里遍历生成的，两次运行的顺序可能不同；示例列表如果做了随机打散，前缀也就跟着变了。
首次调用天然不命中。 缓存要先写进去才能读出来，任何一段新前缀的第一次调用一定是未命中。

第三环：缓存折扣率

就是上一节算的那个数，V4-Pro 是 92.31%。这一环是四环里唯一不由你控制的，取决于你选的平台和模型。

第四环：输入成本占总成本的比重

这是最容易被完全忽略的一环。缓存只在输入这一侧起作用，如果你的账单里输出占了大头，那缓存能撬动的盘子本来就小。

生成类任务是重灾区：写文案、生成长报告、代码补全、翻译长文，这些场景输出 token 多，而且输出单价通常还高于输入单价（V4-Pro 就是 2 倍关系）。反过来，分类、抽取、意图识别、审核这类「长输入短输出」的任务，输入占比高，才是缓存真正的主场。

完整算一遍

下面这组参数全部是假设值，用来做算术演示，不代表任何真实业务的实际数据。单价用上表 V4-Pro 那一行（$1.30 / $0.10 / $2.60），按 30 天月计。

参数	假设值
固定前缀	6,000 token/次
变化输入	2,000 token/次
输出	800 token/次
日调用量	5,000 次
缓存命中率	70%

月调用次数 = 5,000 × 30 = 150,000 次。

不开缓存的月成本：

输入：(6000 + 2000) × 150000 = 1,200,000,000 token = 1200 M token
      1200 × $1.30 = $1,560
输出：800 × 150000 = 120,000,000 token = 120 M token
      120 × $2.60 = $312
合计：$1,872

开缓存（命中率 70%）的月成本：

命中部分：6000 × 70% = 4200 token/次
          4200 × 150000 = 630 M token → 630 × $0.10 = $63
未命中输入：6000 × 30% + 2000 = 3800 token/次
          3800 × 150000 = 570 M token → 570 × $1.30 = $741
输出：不变，$312
合计：$63 + $741 + $312 = $1,116

结果：

月节省额  = $1,872 − $1,116 = $756
实际节省率 = 756 ÷ 1872 = 40.38%

用四环链路验算一遍，应该完全对得上：

前缀占比   = 6000 ÷ 8000            = 75%
命中率     =                          70%
折扣率     = 1 − 0.10/1.30          = 92.31%
输入占比   = 1560 ÷ 1872            = 83.33%

0.75 × 0.70 × 0.9231 × 0.8333 = 0.4038 → 40.38%  ✓

宣传的 92.3%，在这个还算相当理想的场景里，落到账单上是 40.4%。 而这已经是个前缀占比 75%、输出很短的好底子了。

顺便看两个衍生指标。把命中率拉满到 100%（现实中做不到，但作为上限有参考价值）：

命中：6000 × 150000 = 900 M → 900 × $0.10 = $90
变化输入：2000 × 150000 = 300 M → 300 × $1.30 = $390
输出：$312
合计 $792，理论最大节省 = $1,872 − $792 = $1,080，即 57.69%

也就是说，在这套参数下，你把命中率优化到神仙水平，天花板也就 57.7%。这个上限完全由前缀占比和输入占比锁死，跟你多努力无关。

还有一个很实用的口径叫实际输入均价：开缓存后输入侧总花费 $804（$63 + $741），除以输入总量 1200 M token，得到 $0.67 / 百万 token。用它替换报价单上的 $1.30 去做预算，比拍脑袋估一个折扣靠谱得多。

再换一组参数，看看链路是怎么崩的——长输出、短前缀的生成类场景：

参数	假设值
固定前缀	2,000 token/次
变化输入	3,000 token/次
输出	3,000 token/次
日调用量	5,000 次
缓存命中率	50%

不开缓存：输入 5000 × 150000 = 750 M × $1.30 = $975
          输出 3000 × 150000 = 450 M × $2.60 = $1,170
          合计 $2,145

开缓存：  命中 2000 × 50% = 1000 → 150 M × $0.10 = $15
          未命中 1000 + 3000 = 4000 → 600 M × $1.30 = $780
          输出 $1,170
          合计 $1,965

月节省 = $180，节省率 = 180 ÷ 2145 = 8.39%

链路验算：0.40 × 0.50 × 0.9231 × (975/2145 = 45.45%) = 8.39% ✓

同一个平台、同一个模型、同一个 92.3% 的折扣率，一个场景省 40.4%，另一个只省 8.4%。 差别全在你自己那四个数上。

这四个变量的组合太多，手算容易漏项，站内的缓存省钱测算器就是照着上面这套口径实现的：填固定前缀、变化输入、输出 token、日调用量、三档单价和命中率，直接给出开缓存前后的月成本、月节省额、节省比例、前缀占总输入的比例、命中率拉满时的理论最大节省额，以及上面说的实际输入均价。你可以先按保守命中率算一个下限，再填 100% 看上限，真实值一定落在这两个数之间。

想先补一下缓存的底层机制和它跟应用层结果缓存的分工，可以看Prompt Caching 省钱原理与实践和缓存复用减少重复调用；如果你连输入输出各自花了多少钱都还没拆开过，那得先看输入与输出 token 的成本差异，第四环那个比重就是从那里来的。

三、怎么把命中率抬上去（可执行清单）

四环里，折扣率你改不了，前缀占比和输入占比取决于业务形态（能改但代价大），命中率是投入产出比最高的那一环。按收益从大到小排：

1. 把动态内容从系统提示词里挪走——这条收益最大

时间戳、随机 ID、请求 traceId、用户名、会话编号、当前日期，凡是每次调用都不同的东西，一律不要放在系统提示词里。做法是把它们移到用户消息的后半段，或者干脆放在整个 prompt 的最末尾。

❌ system: "你是客服助手。当前时间 2026-08-07 14:23:11，用户 ID u_88213。规则如下……"
✅ system: "你是客服助手。规则如下……"（完全静态）
   user:   "……用户问题……\n[上下文] 当前时间 2026-08-07 14:23:11，用户 u_88213"

一个字的改动，前缀占比可能从接近 0 直接回到 70% 以上。我见过命中率长期趴在地板上的服务，最后查出来就是有人在系统提示词开头加了一行「本次请求 ID」用来排查问题。

2. 固定工具定义与示例的顺序

工具/函数定义如果是从 dict、set 或数据库查询结果里遍历出来的，顺序可能随机漂移。少样本示例如果做了随机采样或打散，同理。解决办法很朴素：序列化时显式排序，或者干脆写成硬编码的有序列表，并且在单测里锁住这段前缀的哈希值，谁改了谁的 CI 就红。

JSON 序列化也要注意 key 的顺序，很多语言的默认行为不保证稳定，序列化工具提供的排序开关记得打开。

3. 多轮对话组织成「只追加不修改」的结构

对话历史天然是增长的，只要你每一轮都是在上一轮的完整消息序列后面追加，那么前 N 轮就构成了稳定前缀，可以持续命中。会破坏这个结构的常见操作有：

中途做历史摘要压缩，把前面十轮换成一段摘要——摘要那一刻前缀全废。
在历史里插入或修改 system 消息。
对历史做滑动窗口截断（丢掉最早的几轮），窗口一滑，开头就变了。

这些操作不是不能做，而是要知道它的成本：每做一次，缓存就重新冷启动一次。合理的做法是把压缩频率降下来，比如从每 5 轮压一次改成每 20 轮压一次，或者只在真的逼近上下文上限时才压。

4. 正视缓存有效期，低频调用别指望缓存

缓存有存活时间，具体策略和数值查你所用平台的官方文档。关键是拿它跟你的调用间隔比：如果你的服务是每小时跑一次的定时任务，或者是一个日均几十次调用的内部工具，那很可能每次都是冷启动，命中率接近 0，这一环直接把整条链路乘成 0。

反过来，如果你的调用是持续高频的，可以考虑把同一前缀的请求在时间上聚拢（比如批处理任务集中在一个窗口内跑完），而不是均匀摊到一整天。

5. 别忘了先量出你现在的命中率

上面所有优化都需要一个基线。多数平台的响应体里会返回本次调用的 token 用量明细，包含缓存相关的字段名和口径请查官方文档。把它落到日志里，按天聚合出「命中 token / 总前缀 token」，这就是你的真实命中率。没有这个数，后面所有优化都是盲改。

四、什么时候压根不值得为缓存做改造

缓存改造不是免费的。重排 prompt 结构、改造对话历史管理、给前缀加单测、加埋点统计命中率，这些都是实打实的工时。有三种情况我会直接劝人别做：

第一，调用量太小。 还是用第二节那组参数（前缀 6000、变化 2000、输出 800、命中率 70%、V4-Pro 单价），但把日调用量从 5,000 降到 200 次：

月调用 200 × 30 = 6,000 次
不开缓存：(8000 × 6000 / 1e6) × $1.30 + (800 × 6000 / 1e6) × $2.60
        = 48 × $1.30 + 4.8 × $2.60 = $62.40 + $12.48 = $74.88
开缓存：  命中 4200 × 6000 = 25.2 M × $0.10 = $2.52
          未命中 3800 × 6000 = 22.8 M × $1.30 = $29.64
          输出 $12.48
          合计 $44.64
月节省 = $74.88 − $44.64 = $30.24（节省率仍是 40.38%，因为比例与调用量无关）

节省率一模一样，但绝对额只有 30 美元出头。这点钱连一天工时都换不来，改造还要冒引入新 bug 的风险。判断标准很直接：先用缓存省钱测算器按你的真实参数估出月节省额，再对比改造要花的工时成本——省下来的钱不够一天工时，就别改。

第二，前缀本来就短。 系统提示词只有两百字、没有工具定义、没有少样本示例，用户输入却动辄几千 token。这种形态下前缀占比可能不到 5%，第一环就把链路掐死了，做什么都是白费。这时候该优化的是别的地方：换更便宜的模型、压缩输入、控制输出长度。

第三，改造会破坏业务逻辑。 最典型的是多租户隔离：为了共享前缀，你得把租户相关信息全部移出系统提示词，但这可能跟你的权限设计、数据隔离要求冲突。还有那种「必须把当前时间放进 system 才能保证模型正确判断时效性」的业务——挪到用户消息末尾通常也能达到同样效果，但你得回归测试一轮确认模型行为没变。为了省钱把正确性搞坏，是最不划算的交易。

五、一个容易忽略的反效果：缓存写入可能是要收钱的

前面所有计算都建立在一个隐含假设上：把前缀写进缓存这件事本身不额外收费。这个假设不总是成立。

有些平台的计费模型里，缓存这件事是分成「写入」和「读取」两档的：读取那一档很便宜（就是我们前面算的那个折扣价），但写入那一档可能比普通输入还贵——因为平台要为你额外做存储和状态维护。它的收费机制大致是这样：

一段前缀第一次被送进来时，走的是「写入」计价，单次成本高于普通输入；
之后在有效期内每次命中，走「读取」计价，单次成本远低于普通输入；
有效期一过，下次再来又是一次写入。

这就产生了一个明确的盈亏平衡点：这段前缀在有效期内被读取的次数，必须多到足以摊平那一次写入的溢价，缓存才是赚的。如果你的前缀写进去却很少被命中——比如每个用户一套私有前缀、调用间隔比有效期还长、或者前缀频繁变动——那么你可能一直在付写入溢价，却几乎吃不到读取折扣，总账反而比不开缓存更贵。

我在这里刻意不写任何具体的倍率数字，也不点名哪家平台是这个模式——这些我没有逐一核实过，写出来就是在误导你做预算。你要做的是：打开你实际使用的那个平台的定价页，确认它的计费表里到底有几档，是「输入 / 缓存输入 / 输出」三档，还是「输入 / 缓存写入 / 缓存读取 / 输出」四档。如果是后者，把写入那一档的价格和你的预期命中次数一起算进去再决定。

顺带说一句，站内那个测算器建模的是三档结构（输入 / 缓存输入 / 输出），没有对写入档单独计价。如果你的平台是四档模式，测算器给出的节省额会偏乐观，需要你自己把写入成本手动扣掉。这一点在工具页的说明里也写了，不是遗漏，是刻意划定的口径边界。

六、自查清单

上线缓存优化之前，把这几条对一遍：

翻你自己那个模型那一行，用「缓存输入价 ÷ 输入价」算出真实折扣率，不要用行业口头禅里的 90%。
数清楚前缀 token 数，标准是「从第 1 个 token 开始逐字不变的连续长度」，中间断一个字后面全不算。
确认计费表有几档，尤其确认缓存写入是否单独收费、是否贵于普通输入。
grep 一遍系统提示词的拼装代码，看有没有时间戳、随机 ID、traceId、用户名混进去；有就往后挪到用户消息末尾。
锁住前缀的顺序：工具定义显式排序、示例写成有序列表、序列化打开 key 排序，并用单测锁哈希。
埋点统计真实命中率，从平台返回的用量明细里取，按天聚合，别拿假设值当结论。
用缓存省钱测算器算出月节省额和理论上限，两个数一起看：节省额决定值不值得做，上限决定你还有多少优化空间。
拿月节省额除以你的工时单价，不够一天工时的改造直接放弃，把精力花在换模型或压缩输出上。

最后一句：算清楚再动手，别让缓存变成又一个「上了但不知道有没有用」的优化。把你自己的前缀长度、输入输出比例、日调用量填进缓存省钱测算器，两分钟就能拿到一个可以写进方案里的数字。