同样的系统提示词和长背景，每次请求都重发一遍，既费 token 又慢。提示词缓存把不变的前缀存起来复用，命中就只算一次，成本和时延一起降。
快速结论
- 提示词缓存复用不变的前缀，命中即省 token 与钱。
- 它把系统设定、长背景等稳定部分缓存起来。
- 要把不变内容放前面，易变内容放后面才好命中。
- 缓存有失效：前缀一变，命中即失，需重缓存。
为什么要缓存提示词
很多请求带着相同的长前缀：系统设定、角色说明、知识背景。每次都重发，既烧 token 又占时延。这部分明明不变，却反复付费，冤。
缓存让不变的前缀只算一次，后续命中直接复用。对前缀长、调用频的场景，省下的钱很可观。缓存是提示词经济的杠杆。
缓存怎么工作
请求进来，系统看前缀是否和之前某次一致。一致就命中缓存，跳过重复计算，只处理变化部分。命中率是省钱的关键指标。
缓存按前缀分段：越长越稳定的前缀越值得缓存。理解这机制，你才会刻意把稳定内容摆前面，提高命中。
什么适合进缓存
稳定的大块内容最适合：系统指令、角色设定、长背景知识、固定示例。这些内容几乎每次一样，缓存命中率天然高。
易变的（如用户当前输入、实时数据）不适合缓存，放后面。区分稳定与易变，是缓存设计的第一步，摆错位置就命中不了。
顺序决定命中
缓存通常按前缀匹配，所以要把不变内容放最前、易变放最后。若易变内容插在前面，前缀就变，后面再稳定也白搭。
顺序不是排版，是命中率开关。重排提示词结构，让稳定块前置，往往比换模型更省。一个小改动，省下的是持续的费用。
命中率怎么提
提高命中靠前缀尽量不变：系统设定固定、少插动态变量、多轮对话里背景前置。命中率高，缓存才真省钱。
还要注意缓存粒度：有些平台按块缓存，把最可能复用的块独立出来。理解平台的缓存规则，才能把命中率榨出来。
和长上下文的关系
长上下文让模型能装更多，但也意味着每次重发长内容更贵。缓存恰好解这痛：长背景只算一次，上下文再长也不反复付费。
两者配合：长上下文提供能力，缓存提供经济性。没有缓存，长上下文的成本会随调用量线性膨胀，难以规模化。
成本怎么算
省的是重复前缀的 token 费。调用越频、前缀越长，省得越多。把每次省的量乘调用次数算出来，缓存的价值一目了然。
也要注意缓存自身可能有最小计费单元或过期。算总账时把规则算清，避免以为省了其实没省够。成本账要落在平台实际计费上。
失效与失效边界
前缀一改，原缓存失效，要重新计算并缓存新前缀。频繁改前缀等于没缓存，所以稳定内容要尽量真稳定，别随手动。
还要注意平台缓存的过期时间：太久不命中会被清。高频调用能保活，低频的可能每次重建。理解过期，才不误判省了多少。
多用户场景
多用户共享同一系统前缀时，缓存被大家共用，命中率更高、更省。但用户专属内容要隔离，不能缓存串味，否则泄隐私。
设计上把公共稳定前缀和用户私有部分分开摆：前者前置缓存、后者后置不缓存。隔离与复用兼顾，才安全又省。
和提示词版本管理的关系
提示词一改版，前缀就变，旧缓存失效。所以版本管理要和缓存配合：稳定期别乱改前缀，确要改就接受一次重建成本。
理解这层，你就不会为小优化频繁改系统前缀，导致缓存反复失效。版本节奏与缓存经济要一起算，而非各管各。
常见三个坑
坑一：易变内容放前面，前缀常变命中低。坑二：频繁改系统前缀，缓存反复失效。坑三：多用户缓存串味，泄隐私。
三者都靠稳定前置、少改前缀、公私隔离化解。提示词缓存是细活，摆法和节奏决定省不省。
调试怎么看
多数平台返回缓存命中情况（命中 token 数）。盯这个数，命中低就查前缀是否真稳定、顺序是否对。调试靠数据不靠猜。
还可做对照：同一前缀请求两次，看第二次是否命中省费。对照实验能验证缓存是否真生效，避免以为开了其实没中。
和模型路由的衔接
路由把请求分给不同模型，若各模型提示词前缀不同，缓存难共用。统一前缀或按模型分别缓存，才能既路由又省钱。
理解这层，你就不会为路由便利把前缀搞得五花八门。缓存与路由要协调，否则省了这件费了那件，总账不降反升。
衡量缓存值不值
看两件事：缓存命中率多高、单位请求成本降多少。两率齐好，说明缓存真起作用；命中低，先查前缀稳定性而非怪平台。
再看时延是否也降：命中后响应更快，体验加分。缓存价值用省钱又提速双尺量，命中稳、省得多，才值得持续用。
图：提示词缓存 核心要点（运营GO 整理）
| 内容 | 摆位 | 是否缓存 |
|---|---|---|
| 系统设定 | 最前 | 是 |
| 长背景 | 前置 | 是 |
| 用户实时 | 最后 | 否 |
延伸阅读：什么是 Prompt（提示词）、什么是 MCP（模型上下文协议）。
下一步行动清单
- 稳定前缀前置、易变后置。
- 系统设定少改保命中。
- 公私内容分离防串味。
- 盯命中率与省费数据。
- 路由与缓存协调不互耗。
