提示缓存：被90%开发者忽视的API成本杀器

大模型API账单里藏着一项近乎白送的折扣：对已经处理过的输入token，服务商只收十分之一的价格。这就是提示缓存（Prompt Caching），现代LLM API上杠杆率最高的成本优化手段。但多数开发者要么没用，要么用错了方式，导致缓存命中率惨淡。

提示缓存的底层逻辑：稳定前缀才是关键

服务商处理请求时，会把输入token送进模型计算——这是你付费的大头。但如果下一次请求开头是完全相同的token序列，比如同一段系统提示、同一份代码库上下文、同一组few-shot示例，服务商无需重新计算，直接复用缓存的中间结果，只收零头价格。

这里的关键词是稳定前缀（stable prefix）。缓存从提示词开头向后匹配，匹配上的部分享受折扣；一旦token出现分叉，比如新的用户消息、最新的工具返回结果，后续内容按原价计费。

这个机制带来一个明确的架构约束：稳定内容放前面，可变内容放后面。系统指令、仓库上下文、示例、参考文档统统置顶，且每次字节级一致；每次变化的内容放在末尾。顺序对了，剩下的交给缓存。

KV Cache（键值缓存） 是提示缓存能成立的技术基础。Transformer 模型在自回归生成时，每一层注意力都会为已处理的 token 计算 Key 和 Value 向量，并保存在显存中供后续 token 查询。若不缓存，每次请求都要对整个输入序列重算这些张量，算力开销与输入长度成正比。提示缓存本质上就是把上一次请求的 KV 张量按前缀索引留存下来，命中时直接加载而跳过前向计算。这也解释了两条约束：一是缓存必须从序列开头连续匹配，因为注意力是因果的，后面的 token 依赖前面所有位置的 KV；二是逐字节一致的要求源于 tokenizer——哪怕多一个空格，分词结果就变，KV 张量的位置对应关系也就断了。不同服务商的缓存有效期（通常几分钟到几小时不等）和存储粒度也由这套显存/存储权衡决定。

算一笔账：90%折扣到底省多少

以GPT-5.6 Sol的公开定价为例：新鲜输入每百万token收费4.00美元，缓存读取每百万token仅需0.40美元，正好是九折优惠的反面——仅付十分之一。

套入参考负载：每月1100个任务，每个任务12K新鲜输入、48K缓存输入、6K输出token。单任务成本为：新鲜输入0.0480美元，缓存输入0.0192美元，输出0.1200美元。注意，48K缓存token是新鲜token量的四倍，花费却不到后者的一半。如果不启用缓存，这48K按全价计算是0.1920美元，每月1100个任务能省下约190美元——输入账单的大头直接被抹掉。

有一项成本常被忽略：缓存写入。某个前缀首次被缓存时，服务商收取溢价，GPT-5.6 Sol上是输入费率的1.25倍。也就是说，带新前缀的首次调用比不缓存还贵一点。但之后每次复用几乎免费。只要调用次数超过个位数，这笔账就压倒性划算——只是别把首次调用也当成打折来建模。

让缓存命中的五条工程规则

缓存失效大多不是服务商的问题，而是提示词结构的问题。

固定顺序，每次一致。 稳定前缀必须逐字节相同，不只是语义相同，而是同样的token、同样的顺序。用固定模板程序化生成提示词，而不是按代码运行时的偶然顺序拼接字符串。

前缀里不能有动态内容。 时间戳、请求ID、用户名、"今天的日期"——任何一个落在缓存区域内，每个请求的前缀都不同，缓存永远不命中。把动态内容移到稳定块之后，或者接受缓存从它之后才开始。

最长的稳定内容放最前。 按变化频率排序：系统提示（从不变）→ 参考文档（很少变）→ 对话摘要（缓慢变化）→ 实时请求（每次变）。即使后面的块轮换，也能最大化缓存部分。

别打乱工具定义。 在agent循环中，工具schema往往是体量很大的稳定块，是完美的缓存材料。但如果框架每次调用都重排或重新生成它们，缓存就断了。固定下来。

验证，别假设。 重构后去用量面板看缓存token占比。重复性负载的目标是80%以上输入token走缓存。如果只有20%，前缀里还有东西在变——抓两个连续提示词做diff，把它找出来。

现实中的命中率预期

能拿到多少命中率，取决于负载形态。带稳定仓库上下文的编码agent，70%到90%的输入token被缓存是现实目标，系统提示和代码库上下文在调用间几乎不变，只有任务描述和工具结果在变。固定系统提示的聊天机器人是50%到80%，系统提示缓存得好，但对话历史不断增长和偏移，长会话中命中率会被侵蚀，定期摘要历史而非原样重发有帮助。一次性或高度可变的任​​务只有0%到30%，如果每个请求的输入都真正不同，比如文档处理、独特查询，就没有多少重复前缀可缓存，别硬上，缓存是为重复而生的。

规律很清晰：负载越像"同一套设置，不同的问题"，命中率越高；越像"每样都不同"，命中率越低。

对话历史为何会侵蚀缓存命中率 值得单独说清。多轮对话中，每新增一条用户消息或助手回复，历史就向后延长一段，而缓存只能匹配到最后一个稳定断点。若系统提示和早期历史被完整缓存，新增的一轮消息本身要按新鲜 token 计费，这部分无法避免；但问题在于很多实现会把滚动摘要、当前轮次元数据或重新格式化的历史插到前面，导致整个前缀位移。更常见的陷阱是每轮都重新生成完整的 messages 数组并调整角色标记，使原本一致的部分出现细微差异。缓解办法包括：保持历史只追加不改写、把周期性摘要作为一个独立块固定在稳定区末尾而非开头、以及避免在历史中回填时间戳等易变字段。命中率随会话变长而下降是正常现象，关键是让下降来自真正新增的内容，而非结构性的前缀漂移。

哪些负载最受益

最大赢家：agent编码循环（巨大的稳定上下文、成千上万次重复）、文档集固定的RAG系统、长系统提示的聊天机器人、对多输入跑同一套提示的评测框架。这些恰好也是输入体量最大的场景，所以缓存才如此重要。

收益一般：部分重复的混合负载，系统提示能缓存上，其余不多。仍值得做，配置成本几乎为零。

直接跳过：真正的一次性推理、对独特文档的批量任务、输入永不重复的场景。缓存写入溢价意味着你会付得更多而收益为零。

缓存不命中时怎么排查

重构后命中率仍然低，罪魁祸首几乎总是藏在稳定前缀里的某个小而动态的东西。排查方法不花哨但有效：抓两个连续提示词，diff它们，看究竟是哪些token不同。常见嫌疑人包括：模板注入的时间戳和日期（系统提示顶部的"当前日期：..."是经典缓存杀手）、插进指令里的会话或请求ID、每次调用以非确定性顺序重新生成的工具定义（排序，或者更好的做法是序列化一次后复用）、把对话历史放在系统提示之前而不是之后（每来一条新消息，整个前缀都平移）、以及字符串模板在不同代码路径下渲染出的空白和格式差异。一次修一个，每改一次看一次面板，命中率应该阶梯式上升，平台期说明变动的因素已经找全了。

还有一个微妙之处：最小可缓存长度。服务商通常要求稳定前缀超过某个最小token数才会启用缓存，短提示词无论结构多好都可能不达标。如果你的提示词只有几百token，缓存可能根本不适用，这也没关系——小输入本来也没什么可省的。缓存的價值体现在大而重复的上下文上。

底线

提示缓存是LLM API里最接近"免费的钱"的东西：对最大的token类别打约九折的折扣（实为付十分之一），代价只是把提示词顺序排对。那些为重复上下文付全价的开发者并不是被多收了钱——他们只是每次都以略微不同的顺序发送同样的token。修好顺序，盯住面板，看着发票上的输入行塌下去。

背景补充

工具 schema（Function Calling 定义） 在 agent 循环中通常以 JSON Schema 形式随请求发送，模型据此决定调用哪个工具、传什么参数。Anthropic、OpenAI 等厂商都将其作为系统级输入的一部分参与前缀匹配。问题在于许多 agent 框架会用字典或集合来组织工具列表，而 Python 等语言的字典遍历顺序、JSON 序列化的键排序在不同版本或不同运行路径下可能不一致；有的框架还会在每次调用时动态注入当前可用工具的子集。这两种做法都会让工具定义块在多轮之间发生字节级漂移，使本可缓存数万 token 的稳定块失效。稳妥做法是在进程启动时把工具定义序列化成固定字符串（如按名称排序后 json.dumps），整个会话复用同一份；若确实需要动态增减工具，就把变化的部分拆到稳定块之后。