缓存命中与省钱 | 成本与安全 | 做产品

缓存命中与省钱

同一种模型、同一套提示词，两个团队的实际成本可以差一倍——区别往往只在一件事：缓存命中率。

你会遇到的现象

• 提示词里每次塞进一段会变的时间戳或随机内容

• 把用户历史插在系统提示中间，导致前缀每轮都不同

• 账单比同行的估算高很多，找不到原因

缓存怎么工作

大模型厂商普遍提供前缀缓存：如果你这次的请求，前面一段和之前某次请求完全一致，那一段就按折扣价计费（低至输入价的十分之一甚至更低），因为模型厂商不需要为重复的内容重新计算。

它是自动的——不需要你申请，但需要你「配合」。配合的方式只有一个：让每次请求的前缀尽量一致。

注意两个关键词：前缀和完全一致。

「前缀」意味着只有开头部分能吃到缓存。中间任何位置的不一致，都会让整条前缀作废——因为缓存是连续匹配的。「完全一致」意味着哪怕一个字符不同，命中就断。

什么决定命中

三个最容易打断命中的因素：

**一、前缀里有会变的内容。**时间戳、随机数、动态拼接的字符串，放在前缀里，每条请求都不同，缓存永远不会命中。

**二、中段插入了变化。**比如把用户历史放在系统提示和长期规则之间。系统提示 + 规则这部分本来可以稳定，因为中间插了变的内容，整条作废。

**三、顺序不稳定。**同一份内容，这次排 A 前 B 后，下次 B 前 A 后——两次都不匹配。

缓存是「整体命中」不是「部分命中」：前缀中第一个不一致的位置之后，全部按原价算。所以安排顺序特别重要。

怎么安排前缀

按这个顺序组织每次请求：

**固定不变的放最前。**系统提示、长期规则、固定知识——这些每次一样，放最前面，构成稳定的缓存前缀。

**会变的内容放最后。**用户本轮的问题、临时指令、检索到的当次资料，放到最末尾。

**中间尽量别放会变的。**如果用户历史必须包含，也放在固定前缀之后、靠近问题的地方——宁可让「前缀」短一些但稳定，也不要为了把历史塞前而打断命中。

再补几条细节：

一、去掉无意义的变化。「当前时间」「用户 ID」这类每次都会变的字段，除非模型真的需要，否则别拼进提示词。

**二、变动内容也别完全乱序。**比如检索资料每次不同，但你可以固定它们的排列规则（按得分降序），至少结构稳定。

**三、把「长期规则」从系统提示里拆出来。**如果长期规则要频繁更新，把它放系统提示后面单独一段——更新它时，至少系统提示那段还能命中。提示词分层在这里有直接的经济意义。

实际效果

一个典型的客服 Agent：系统提示 + 技能说明 + 固定知识约 1500 Token，用户问题平均 100 Token。前缀稳定时，每次输入成本 ≈ 1500 × 缓存价 + 100 × 原价，而完全不缓存时是 1600 × 原价。按缓存价约为原价的十分之一算，输入成本能降 80% 以上。

对高频、长提示词的场景，这是最大的一笔优化——比换模型、压输出都来得直接。

最后一条：**把缓存命中率当指标统计。**多数厂商的计费明细会体现缓存用量。把它记进日志、按月对比。命中率从 0 提到 80%，很可能就是你最省力的一笔成本优化。

典型客服 Agent：固定前缀约 1500 Token，用户问题约 100 Token

前缀没命中

1600 Token 全按原价

前缀命中

1500 × 缓存价（约原价的十分之一）＋ 100 × 原价 输入成本降 80% 以上 —— 对高频、长提示词的场景，这是最大的一笔优化

要吃到它，只需要配合一件事：让前缀尽量一致 固定不变的放最前（系统提示、长期规则、固定知识）· 会变的放最后（本轮问题、临时指令、当次检索资料） 中间插一个时间戳或用户 ID，整条前缀就全部作废——缓存是整体命中，不是部分命中。

把缓存命中率当成一个指标来统计：多数厂商的计费明细会体现缓存用量，记进日志按月对比。命中率从 0 提到 80%，很可能就是你最省力的一笔成本优化。

一次调用的计费构成 三种价格里，缓存价就是用来省钱的。

提示词的分层 分层不只是清晰，还直接决定缓存命中。

上下文窗口 内容越多越要依赖缓存，否则每轮都全价。