说到LLM推理优化里的Suffix Cache Reuse后缀缓存复用我先讲一个让我印象深刻的调试现场。某个服务的prompt缓存命中率长期在10%上下代码里明明把一段几千token的参考资料放在了最前面也按照官方文档标了cache_control可每次请求还是老老实实重新计价。后来把请求日志打出来一看发现每次调用都在提示词末尾追加了不同的用户问题——这就明白了所有静态内容都堆在前缀动态内容却偏偏出现在末尾即使前缀被缓存了请求依然会因为后缀的变化而无法复用整段缓存。Suffix Cache Reuse要解决的正是这种前缀匹配规则下几乎无人幸免的结构性问题。这篇内容适合正在做LLM API集成、对推理成本和时延敏感的同学。读完你会理解为什么常规前缀缓存容易失效后缀缓存复用的命中规则到底是什么以及如何通过调整提示词的消息块排列顺序让静态内容变成可稳定复用的缓存尾巴。1. 前缀缓存的死穴为什么大多数人的缓存命中率上不去1.1 公共前缀匹配的基本游戏规则大多数LLM服务的prompt caching核心逻辑都是公共前缀匹配。也就是说服务端会把请求中已经按token切分好的输入序列和缓存里存过的序列做比对从第一个token开始看能对齐多长。对齐得越长能直接读取的缓存就越多省下的input费用就越多。这套规则本身很公平但很多人对它的理解有一个致命盲区以为只要把不变的文本放在提示词里加个cache_control标记就万事大吉。实际上缓存系统判断的依据不是你想缓存哪段而是请求头部的公共匹配结果。只要你的公共前缀长度没有超过服务商设定的最小可缓存长度缓存就不会建立只要后续请求的头部和前一次不一样前面的缓存就只能作废。举一个最常见的例子。你在system消息里放了完整的产品规则说明在user消息开头放了某个固定任务描述但每次请求时用户提交的文本不一样而且你习惯性地把用户文本放在user消息的最后。这时候整个请求的前缀只包含system规则那一小段用户文本一出现公共前缀就断了。1.2 用户问题在末尾引发的雪崩式失效当动态内容出现在提示词末尾时失效的不只是末尾那几十个token而是前面漫长的公共部分全部无法复用。因为大多数缓存实现按前缀对齐一旦某个位置对不上从该位置往后的所有token都必须重新处理。这正是我开头说的调试现场里发生的事情。假设你要实现一个根据最新文档回答问题的功能。每次请求时你先把一份2000 token的产品手册放在前面后面拼接用户的问题。第一次请求时由于总长度超过门槛缓存成功建立缓存内容是产品手册第一个问题的整体。第二次用户换了问题请求变成了产品手册第二个问题。此时请求的前缀确实包含了完整的产品手册但因为后面多了一个和缓存不一致的问题token前缀匹配只能匹配到产品手册的末尾再往后就匹配不上了。更麻烦的是因为每次请求末尾的动态尾巴都不同第一次建立的缓存就再也派不上用场你需要反复写入新缓存成本反而比不缓存更高。这里的关键认知是缓存命中率低往往不是因为服务商实现得不好而是提示词的结构天然违背了前缀匹配的游戏规则。1.3 长度门槛缓存不是你想建就能建除了匹配规则之外还有个容易忽略的硬性门槛——最小可缓存长度。服务商通常会设置一个最小缓存token数不同服务商规定不同常见在1024 tokens上下具体以最新官方文档为准低于这个长度即使你标记了缓存断点系统也会忽略。所以如果你的系统提示词只有几百token动态内容又放在末尾那你大概率处于永远达不到缓存门槛的状态。很多人调了半天参最后发现自己的prompt压根就不够长这属于排查顺序错了。想判断自己是不是被长度门槛卡住最简单的办法是查看响应里返回的token使用明细。如果所有缓存的字段都是0而你的prompt总长度只有几百token那就别在缓存上花时间了先考虑把固定内容撑起来或者放弃这类短请求的缓存优化。2. 后缀缓存复用的本质让固定尾巴变成可复用资产2.1 缓存断点在prompt中画一条线既然传统的公共前缀匹配对动态前置、静态后置的结构无能为力那自然有人想能不能让缓存去匹配后缀这就是Suffix Cache Reuse的核心思路。要实现后缀复用依赖的核心机制是缓存断点cache breakpoint。你可以把断点理解成在提示词序列上画的一条线系统会记录从指定位开始的这一段内容并在后续请求中检查如果某个请求的末尾和这段被记录的内容一致就直接读取缓存而不需要重新计算。所以问题从如何让请求头部一致变成了如何让请求尾部一致。你不再需要把固定内容堆在最前面而是可以把固定的长文本放到提示词的最后让动态内容出现在开头。只要每次请求都保持同样的固定尾巴即使每次开头的用户问题千差万别系统也能稳定命中这一段缓存。这听起来像把prompt倒过来写但实现上远没有这么粗暴因为消息块本身还需要满足语义顺序。比较好的做法是在同一个user消息内部把动态内容放在前面的文本块把固定内容放在后面的文本块并在固定文本块上标记缓存断点。模型看到的依然是一个连贯的请求但缓存系统看到的是固定的尾巴。2.2 命中规则请求怎么才算撞上缓存后缀缓存的命中判定核心是看当前请求的末尾是否以某一个缓存后缀结束。这里的后缀不是指半个句子而是指已经被服务端分词并按块记录下来的完整文本段。命中判定通常发生在整个输入序列级别。也就是说假设你定义了一个静态的末尾文本块那么你的请求里从这个末尾块开始到消息结束所有token都必须和缓存内容完全一致。只要末尾块后面多出一个token哪怕是一个空格、一个标点这次后缀匹配就会失败。这带来了一个实际约束你必须在设计prompt时保证固定尾巴永远在最后。如果某些请求还需要在末尾追加额外的指令那这条尾巴就不再是尾巴缓存自然失效。所以后缀缓存复用更适合那些每次请求的最后内容都完全一样的场景。2.3 创建与读取一个请求里的双重身份后缀缓存复用的机制里一个请求可以同时承担两种身份创建缓存的writer或读取缓存的reader。第一次使用某个固定尾巴时服务端需要完整处理整个prompt并把这个尾巴写入缓存。这次请求在响应头里通常体现为缓存创建token数。后续再次调用时如果尾巴一致服务端直接读取缓存响应头里体现为缓存读取token数。这两种身份的成本模型差异很大。以主流API服务商通用的计费比例来说缓存创建写入通常比普通输入贵一些大约为普通input的1.25倍缓存读取则便宜得多大约是普通input的0.1倍。这意味着如果你只调用一两次后缀缓存反而可能让你多花钱但如果你的调用次数足够多第二次及之后的成本会断崖式下降。成本曲线大概是这样一个形状调用次数普通输入成本缓存创建成本缓存读取成本第1次1.0倍1.25倍0第2次及以后1.0倍00.1倍也就是说只要你的请求结构稳定跑个三五次之后整体成本就能远远低于完全不用缓存的情况。2.4 生命周期与TTL5分钟的窗口期缓存不是永久存在的。主流服务商通常会给缓存一个较短的生存时间比如常见的TTL是5分钟。如果你在5分钟内没有再次发起一个能命中该缓存的后缀请求这段缓存就会被判定为冷缓存并逐出。不过这里有个容易被误解的点TTL不是从创建开始固定倒计时而是会随着每次续期而刷新。也就是说每次你成功读取了一次缓存相当于给这段缓存续命了一次有效期会重新计算。所以高频率调用系统反而比低频率调用系统更容易享受缓存红利。实测下来对那种每几秒就有大量同类请求的服务TTL基本不构成障碍。真正要小心的反而是低频场景一个每天只触发几十次的内部工具两次调用间隔很容易超过5分钟缓存大概率每次都要重新创建。这种情况下后缀缓存不仅不能省成本反而会带来1.25倍的写入开销。3. 最适合后缀缓存复用的三个场景3.1 固定收尾指令与few-shot示例我最推荐用来做固定尾巴的内容是那些每次请求都必须携带、但内容完全不变的收尾指令和few-shot示例。举个例子。你做一个代码生成助手希望模型永远按照先讲思路、再给代码、最后给测试用例的格式输出。这些指令如果放在system消息里可能会被长对话上下文冲淡放在user消息的最后对模型行为的影响最大、也最稳定。同时因为你把它固定在了末尾它天然就是一个理想的缓存后缀。每次用户提交不同的代码片段前面的内容千变万化但最后那段固定的格式要求总能命中缓存。few-shot示例也有同样的性质。很多人喜欢把示例放在system消息里但反过来想想示例放在user消息的末尾对输出的引导作用其实更强。更何况示例这种每次都是同一批文本的内容放在缓存后缀里会带来非常稳定的收益。3.2 工具定义与输出约束常驻末尾如果你在做function calling相关的集成工具的JSON Schema定义通常是一大段静态文本并且每次请求都要带上。这段文本动辄几百上千token是缓存优化的优质对象。不过工具定义的使用方式和few-shot不太一样。工具列表往往需要在请求之间动态增删比如某个用户开通了某个功能对应的工具定义才被追加进来。此时你可以考虑把当前用户可用工具定义放在消息末尾的固定块中。只要用户在持续交互过程中权限没有变化这个工具定义块就不会变后缀缓存就能持续命中。输出约束也一样。有些场景要求模型只能在给定的枚举范围里返回禁止自由发挥。这类约束文本可以独占一个末尾块每次请求原样携带。这样既保证了输出合规又拿到了缓存收益一举两得。3.3 文档问答检索到的长上下文搬到尾部对于RAG场景把检索到的文档放前面、把用户问题放后面其实是最直觉的写法但也是最容易让缓存失效的写法。如果一定要优化一个更合理的排列是用户问题放前面检索到的长文档放后面并且在长文档块上标记缓存断点。你可能会问文档内容每次检索出来不都不一样吗还能缓存吗答案是如果每个用户的文档集合相对稳定或者同一批问题反复检索到同一批文档那么当前对话的文档上下文就是一根相对固定的尾巴。用户在同一个会话里追问多轮时每轮检索结果可能相似甚至相同此时后缀缓存就能覆盖掉最大的那部分token。当然如果文档内容每次都在变化这招就不适用了。不要为了缓存去硬套结构那只会破坏prompt的语义。3.4 别硬套动态生成结果在末尾时别用有一个比较常见的反模式让模型生成的结果本身处于消息末尾。比如你拿到模型输出后把assistant的输出直接拼到下一次请求的末尾当上下文。这时候因为assistant的输出每次都不一样末尾就是不断变化的内容缓存后缀必然失效。这种动态生成的尾巴不能做后缀缓存只能走常规的前缀缓存老路——把多轮历史这个稳定前缀维护好。用一句话概括后缀缓存复用的适用边界是请求末尾存在一段内容稳定、语义完整的静态文本。4. 手把手改造一个请求从缓存零命中到稳定命中4.1 改造前的prompt结构为了看得直观我拿一个典型的文档问答请求做示例。改造前你的prompt结构大概是这样的system: 你是一个友好的客服助手请基于提供的资料回答问题。 user: 块1产品使用手册2000 token静态内容 块2用户具体问题每次变化请问什么时候发货在这个结构里用户问题是最后一个文本块。服务端做前缀匹配时能匹配到的稳定部分只有system消息和产品手册的开头但一旦用户问题这个动态块出现整个后缀都变成了动态内容。第一次请求建立的缓存因为后面接上了不同的问题而无法复用于第二次请求。这种结构下缓存命中率自然不理想。4.2 改造后的结构现在把块顺序调整一下让动态内容在前静态内容在后system: 你是一个友好的客服助手请基于提供的资料回答问题。 user: 块1用户具体问题每次变化请问什么时候发货 块2产品使用手册2000 token静态内容你可能会担心模型读到的语义顺序变了会不会影响回答质量从我的实测经验看对多数通用模型来说用户问题先出现、参考资料后出现并不影响模型理解只要你在后面的文本块里加一句请基于上面的资料回答前面的问题模型就会正确地把问题和资料关联起来。需要注意的是不要在末尾块之后再追加任何结束语比如请回答之类的动态提示。因为一旦末尾块后面还有内容缓存尾巴就不再是之前那段文本了。4.3 cache_control的具体写法下面是一段示意性的消息结构展示了后缀块上如何标记缓存断点。不同服务商的写法大同小异核心思路是在你想缓存的文本块上加cache_control。{ model: your-model-name, max_tokens: 1024, messages: [ { role: user, content: [ { type: text, text: 用户当前的问题请问你们什么时候发货 }, { type: text, text: 以下是产品使用手册内容请基于它回答上面的问题。\n此处省略约2000 token的静态资料, cache_control: { type: ephemeral } } ] } ] }这样做之后静态资料块就是整个消息的结尾并且它被打上了缓存标记。后续每次请求只要用户问题块变化静态资料块保持不变服务端就能在资料块这一位置直接命中缓存。如果系统提示词本身也很长也可以在system消息里单独标记缓存让它独立于user消息缓存。不过不要把所有块都标上缓存标记断点越多缓存管理的复杂度越高还可能出现缓存空间互相挤占的问题。4.4 用返回头确认命中改造完成后别急着上线先查看响应中返回的token使用明细。不同服务商的字段名称略有差异但核心就是两个一个是缓存创建token数一个是缓存读取token数。你需要确认的目标很简单第一次请求时缓存创建token数稳步上升第二次及后续请求时缓存读取token数稳定出现并且数值接近你期望被缓存的长文本块的长度。如果连续多次请求都只看到创建值、读取值始终为零那说明你的请求结构还没有真正命中后缀缓存需要检查末尾块是否足够静态、是否达到了最小缓存长度。一个小经验把缓存读取token数打印到日志里做成监控看板的关键指标。这个数字直接反映你省下了多少input成本比单独看整体时延更直观。4.5 成本账一次改造能省多少钱我们来算一笔具体的账。假设一个请求每次携带2000 token静态资料和100 token动态问题总共2100 token。以缓存读取约为普通输入0.1倍的通用计费比例为参照不考虑输出token完全不缓存每次消耗2100 token的普通输入成本。后缀缓存第一次2000 token按缓存创建计费约1.25倍100 token普通计费总成本反而略高。后缀缓存第2到10次100 token普通计费2000 token按缓存读取计费约0.1倍总消耗约300 token的换算成本相比2100 token省了85%左右。实际测试中我在一个日调用量约2万次的服务上做了类似改造。同样数量的静态上下文整体input成本下降了70%以上响应时延也降了大概700到900毫秒。这个收益在每次prompt巨大的场景里非常可观。5. 实战中的坑与建议5.1 拆分粒度与断点数量有人喜欢把prompt里所有静态内容全堆到末尾结果搞出一个巨大无比的缓存尾巴。这表面上看缓存命中率很高但首次缓存创建成本也会变得很高。如果后续实际读取率不高你反而亏了。我的建议是把静态内容按复用频率分层复用频率最高的段落放末尾复用频率一般的段落放中间复用机会不大的一次性内容直接放开头。断点数量宁少勿多先保证最重要的那段尾巴稳定命中再考虑优化其他段落。5.2 小心每次都漏的伪命中有一种情况很迷惑人你看到缓存读取token数不为零但细看发现读取的只是某个小片段根本不是你以为的那段长文本。这种情况多半是因为服务端在你标记的缓存断点之外还自动识别了其他可复用片段导致统计数字被稀释了。判断是不是伪命中可以把读取token数和你预期缓存的文本长度做个占比对比。如果占比长期低于50%说明你的固定尾巴并没有真正稳定下来继续检查末尾块的拼接逻辑尤其是结尾有没有隐性空格、换行符或动态时间戳之类的东西。5.3 别让动态内容污染后缀我之前踩过一个大坑一个请求的动态内容里包含当前时间。我明明把它放在开头了但某个回调逻辑里又把这个时间拼到了末尾的内容备注位置。结果日志里缓存读取token数一直是0排查了半天才发现是末尾多了一个每次变化的时间字符串。这类问题的排查建议很朴素看一下请求日志里末尾文本块每两次请求之间是否完全一致。用脚本比对连续请求的最后一个文本块的哈希值只要哈希不一致就说明尾巴被污染了。5.4 监控命中的指标与工具不要只靠响应体里的token字段要在生产环境中建立两个辅助指标缓存读取token占input总token的比例这个数越高说明你的prompt结构越健康。连续请求之间最后一个文本块的内容重复率用于提前发现尾巴漂移问题。如果你用的是第三方SDK注意部分SDK的token明细字段没有完全透出需要查看底层HTTP响应头才能拿到缓存相关数值。遇到这种情况直接在HTTP层面打印响应头会更可靠。5.5 我给团队定的落地顺序在实践中我越来越相信先调结构再调参数这个原则。后缀缓存复用并不需要你买新设备、换新模型它只是要求你把消息块的排列顺序重新想一遍。我在团队里通常建议按这个顺序落地先给所有请求打印缓存token明细找出持续创建、从不读取的请求。从这些请求里挑出末尾内容固定、长度超过最小缓存门槛的那一类做排列顺序调整。调整后至少观察24小时对比之前的缓存读取占比和平均input成本。确认稳定后再逐步把其他场景迁移到这个布局上来。这样不会一次性改动过多也方便在灰度过程中快速回归。这个优化思路再往下走还可以延伸到系统提示词的分层组织、长对话历史的分段缓存甚至和模型路由策略结合把高频请求打到缓存命中率更高的模型上。但无论怎么扩展核心始终是那一句话缓存是跟着稳定内容走的哪段内容最稳定就应该把哪段内容放在最适合命中的位置。后缀缓存复用不是魔法只是一个尊重缓存规则的prompt布局技巧。 
长河君 · 2026/10/7 1:13:02 · 阅读 1.2k 后缀缓存复用：破解LLM推理中前缀缓存失效的提示词布局技巧
说到LLM推理优化里的Suffix Cache Reuse后缀缓存复用我先讲一个让我印象深刻的调试现场。某个服务的prompt缓存命中率长期在10%上下代码里明明把一段几千token的参考资料放在了最前面也按照官方文档标了cache_control可每次请求还是老老实实重新计价。后来把请求日志打出来一看发现每次调用都在提示词末尾追加了不同的用户问题——这就明白了所有静态内容都堆在前缀动态内容却偏偏出现在末尾即使前缀被缓存了请求依然会因为后缀的变化而无法复用整段缓存。Suffix Cache Reuse要解决的正是这种前缀匹配规则下几乎无人幸免的结构性问题。这篇内容适合正在做LLM API集成、对推理成本和时延敏感的同学。读完你会理解为什么常规前缀缓存容易失效后缀缓存复用的命中规则到底是什么以及如何通过调整提示词的消息块排列顺序让静态内容变成可稳定复用的缓存尾巴。1. 前缀缓存的死穴为什么大多数人的缓存命中率上不去1.1 公共前缀匹配的基本游戏规则大多数LLM服务的prompt caching核心逻辑都是公共前缀匹配。也就是说服务端会把请求中已经按token切分好的输入序列和缓存里存过的序列做比对从第一个token开始看能对齐多长。对齐得越长能直接读取的缓存就越多省下的input费用就越多。这套规则本身很公平但很多人对它的理解有一个致命盲区以为只要把不变的文本放在提示词里加个cache_control标记就万事大吉。实际上缓存系统判断的依据不是你想缓存哪段而是请求头部的公共匹配结果。只要你的公共前缀长度没有超过服务商设定的最小可缓存长度缓存就不会建立只要后续请求的头部和前一次不一样前面的缓存就只能作废。举一个最常见的例子。你在system消息里放了完整的产品规则说明在user消息开头放了某个固定任务描述但每次请求时用户提交的文本不一样而且你习惯性地把用户文本放在user消息的最后。这时候整个请求的前缀只包含system规则那一小段用户文本一出现公共前缀就断了。1.2 用户问题在末尾引发的雪崩式失效当动态内容出现在提示词末尾时失效的不只是末尾那几十个token而是前面漫长的公共部分全部无法复用。因为大多数缓存实现按前缀对齐一旦某个位置对不上从该位置往后的所有token都必须重新处理。这正是我开头说的调试现场里发生的事情。假设你要实现一个根据最新文档回答问题的功能。每次请求时你先把一份2000 token的产品手册放在前面后面拼接用户的问题。第一次请求时由于总长度超过门槛缓存成功建立缓存内容是产品手册第一个问题的整体。第二次用户换了问题请求变成了产品手册第二个问题。此时请求的前缀确实包含了完整的产品手册但因为后面多了一个和缓存不一致的问题token前缀匹配只能匹配到产品手册的末尾再往后就匹配不上了。更麻烦的是因为每次请求末尾的动态尾巴都不同第一次建立的缓存就再也派不上用场你需要反复写入新缓存成本反而比不缓存更高。这里的关键认知是缓存命中率低往往不是因为服务商实现得不好而是提示词的结构天然违背了前缀匹配的游戏规则。1.3 长度门槛缓存不是你想建就能建除了匹配规则之外还有个容易忽略的硬性门槛——最小可缓存长度。服务商通常会设置一个最小缓存token数不同服务商规定不同常见在1024 tokens上下具体以最新官方文档为准低于这个长度即使你标记了缓存断点系统也会忽略。所以如果你的系统提示词只有几百token动态内容又放在末尾那你大概率处于永远达不到缓存门槛的状态。很多人调了半天参最后发现自己的prompt压根就不够长这属于排查顺序错了。想判断自己是不是被长度门槛卡住最简单的办法是查看响应里返回的token使用明细。如果所有缓存的字段都是0而你的prompt总长度只有几百token那就别在缓存上花时间了先考虑把固定内容撑起来或者放弃这类短请求的缓存优化。2. 后缀缓存复用的本质让固定尾巴变成可复用资产2.1 缓存断点在prompt中画一条线既然传统的公共前缀匹配对动态前置、静态后置的结构无能为力那自然有人想能不能让缓存去匹配后缀这就是Suffix Cache Reuse的核心思路。要实现后缀复用依赖的核心机制是缓存断点cache breakpoint。你可以把断点理解成在提示词序列上画的一条线系统会记录从指定位开始的这一段内容并在后续请求中检查如果某个请求的末尾和这段被记录的内容一致就直接读取缓存而不需要重新计算。所以问题从如何让请求头部一致变成了如何让请求尾部一致。你不再需要把固定内容堆在最前面而是可以把固定的长文本放到提示词的最后让动态内容出现在开头。只要每次请求都保持同样的固定尾巴即使每次开头的用户问题千差万别系统也能稳定命中这一段缓存。这听起来像把prompt倒过来写但实现上远没有这么粗暴因为消息块本身还需要满足语义顺序。比较好的做法是在同一个user消息内部把动态内容放在前面的文本块把固定内容放在后面的文本块并在固定文本块上标记缓存断点。模型看到的依然是一个连贯的请求但缓存系统看到的是固定的尾巴。2.2 命中规则请求怎么才算撞上缓存后缀缓存的命中判定核心是看当前请求的末尾是否以某一个缓存后缀结束。这里的后缀不是指半个句子而是指已经被服务端分词并按块记录下来的完整文本段。命中判定通常发生在整个输入序列级别。也就是说假设你定义了一个静态的末尾文本块那么你的请求里从这个末尾块开始到消息结束所有token都必须和缓存内容完全一致。只要末尾块后面多出一个token哪怕是一个空格、一个标点这次后缀匹配就会失败。这带来了一个实际约束你必须在设计prompt时保证固定尾巴永远在最后。如果某些请求还需要在末尾追加额外的指令那这条尾巴就不再是尾巴缓存自然失效。所以后缀缓存复用更适合那些每次请求的最后内容都完全一样的场景。2.3 创建与读取一个请求里的双重身份后缀缓存复用的机制里一个请求可以同时承担两种身份创建缓存的writer或读取缓存的reader。第一次使用某个固定尾巴时服务端需要完整处理整个prompt并把这个尾巴写入缓存。这次请求在响应头里通常体现为缓存创建token数。后续再次调用时如果尾巴一致服务端直接读取缓存响应头里体现为缓存读取token数。这两种身份的成本模型差异很大。以主流API服务商通用的计费比例来说缓存创建写入通常比普通输入贵一些大约为普通input的1.25倍缓存读取则便宜得多大约是普通input的0.1倍。这意味着如果你只调用一两次后缀缓存反而可能让你多花钱但如果你的调用次数足够多第二次及之后的成本会断崖式下降。成本曲线大概是这样一个形状调用次数普通输入成本缓存创建成本缓存读取成本第1次1.0倍1.25倍0第2次及以后1.0倍00.1倍也就是说只要你的请求结构稳定跑个三五次之后整体成本就能远远低于完全不用缓存的情况。2.4 生命周期与TTL5分钟的窗口期缓存不是永久存在的。主流服务商通常会给缓存一个较短的生存时间比如常见的TTL是5分钟。如果你在5分钟内没有再次发起一个能命中该缓存的后缀请求这段缓存就会被判定为冷缓存并逐出。不过这里有个容易被误解的点TTL不是从创建开始固定倒计时而是会随着每次续期而刷新。也就是说每次你成功读取了一次缓存相当于给这段缓存续命了一次有效期会重新计算。所以高频率调用系统反而比低频率调用系统更容易享受缓存红利。实测下来对那种每几秒就有大量同类请求的服务TTL基本不构成障碍。真正要小心的反而是低频场景一个每天只触发几十次的内部工具两次调用间隔很容易超过5分钟缓存大概率每次都要重新创建。这种情况下后缀缓存不仅不能省成本反而会带来1.25倍的写入开销。3. 最适合后缀缓存复用的三个场景3.1 固定收尾指令与few-shot示例我最推荐用来做固定尾巴的内容是那些每次请求都必须携带、但内容完全不变的收尾指令和few-shot示例。举个例子。你做一个代码生成助手希望模型永远按照先讲思路、再给代码、最后给测试用例的格式输出。这些指令如果放在system消息里可能会被长对话上下文冲淡放在user消息的最后对模型行为的影响最大、也最稳定。同时因为你把它固定在了末尾它天然就是一个理想的缓存后缀。每次用户提交不同的代码片段前面的内容千变万化但最后那段固定的格式要求总能命中缓存。few-shot示例也有同样的性质。很多人喜欢把示例放在system消息里但反过来想想示例放在user消息的末尾对输出的引导作用其实更强。更何况示例这种每次都是同一批文本的内容放在缓存后缀里会带来非常稳定的收益。3.2 工具定义与输出约束常驻末尾如果你在做function calling相关的集成工具的JSON Schema定义通常是一大段静态文本并且每次请求都要带上。这段文本动辄几百上千token是缓存优化的优质对象。不过工具定义的使用方式和few-shot不太一样。工具列表往往需要在请求之间动态增删比如某个用户开通了某个功能对应的工具定义才被追加进来。此时你可以考虑把当前用户可用工具定义放在消息末尾的固定块中。只要用户在持续交互过程中权限没有变化这个工具定义块就不会变后缀缓存就能持续命中。输出约束也一样。有些场景要求模型只能在给定的枚举范围里返回禁止自由发挥。这类约束文本可以独占一个末尾块每次请求原样携带。这样既保证了输出合规又拿到了缓存收益一举两得。3.3 文档问答检索到的长上下文搬到尾部对于RAG场景把检索到的文档放前面、把用户问题放后面其实是最直觉的写法但也是最容易让缓存失效的写法。如果一定要优化一个更合理的排列是用户问题放前面检索到的长文档放后面并且在长文档块上标记缓存断点。你可能会问文档内容每次检索出来不都不一样吗还能缓存吗答案是如果每个用户的文档集合相对稳定或者同一批问题反复检索到同一批文档那么当前对话的文档上下文就是一根相对固定的尾巴。用户在同一个会话里追问多轮时每轮检索结果可能相似甚至相同此时后缀缓存就能覆盖掉最大的那部分token。当然如果文档内容每次都在变化这招就不适用了。不要为了缓存去硬套结构那只会破坏prompt的语义。3.4 别硬套动态生成结果在末尾时别用有一个比较常见的反模式让模型生成的结果本身处于消息末尾。比如你拿到模型输出后把assistant的输出直接拼到下一次请求的末尾当上下文。这时候因为assistant的输出每次都不一样末尾就是不断变化的内容缓存后缀必然失效。这种动态生成的尾巴不能做后缀缓存只能走常规的前缀缓存老路——把多轮历史这个稳定前缀维护好。用一句话概括后缀缓存复用的适用边界是请求末尾存在一段内容稳定、语义完整的静态文本。4. 手把手改造一个请求从缓存零命中到稳定命中4.1 改造前的prompt结构为了看得直观我拿一个典型的文档问答请求做示例。改造前你的prompt结构大概是这样的system: 你是一个友好的客服助手请基于提供的资料回答问题。 user: 块1产品使用手册2000 token静态内容 块2用户具体问题每次变化请问什么时候发货在这个结构里用户问题是最后一个文本块。服务端做前缀匹配时能匹配到的稳定部分只有system消息和产品手册的开头但一旦用户问题这个动态块出现整个后缀都变成了动态内容。第一次请求建立的缓存因为后面接上了不同的问题而无法复用于第二次请求。这种结构下缓存命中率自然不理想。4.2 改造后的结构现在把块顺序调整一下让动态内容在前静态内容在后system: 你是一个友好的客服助手请基于提供的资料回答问题。 user: 块1用户具体问题每次变化请问什么时候发货 块2产品使用手册2000 token静态内容你可能会担心模型读到的语义顺序变了会不会影响回答质量从我的实测经验看对多数通用模型来说用户问题先出现、参考资料后出现并不影响模型理解只要你在后面的文本块里加一句请基于上面的资料回答前面的问题模型就会正确地把问题和资料关联起来。需要注意的是不要在末尾块之后再追加任何结束语比如请回答之类的动态提示。因为一旦末尾块后面还有内容缓存尾巴就不再是之前那段文本了。4.3 cache_control的具体写法下面是一段示意性的消息结构展示了后缀块上如何标记缓存断点。不同服务商的写法大同小异核心思路是在你想缓存的文本块上加cache_control。{ model: your-model-name, max_tokens: 1024, messages: [ { role: user, content: [ { type: text, text: 用户当前的问题请问你们什么时候发货 }, { type: text, text: 以下是产品使用手册内容请基于它回答上面的问题。\n此处省略约2000 token的静态资料, cache_control: { type: ephemeral } } ] } ] }这样做之后静态资料块就是整个消息的结尾并且它被打上了缓存标记。后续每次请求只要用户问题块变化静态资料块保持不变服务端就能在资料块这一位置直接命中缓存。如果系统提示词本身也很长也可以在system消息里单独标记缓存让它独立于user消息缓存。不过不要把所有块都标上缓存标记断点越多缓存管理的复杂度越高还可能出现缓存空间互相挤占的问题。4.4 用返回头确认命中改造完成后别急着上线先查看响应中返回的token使用明细。不同服务商的字段名称略有差异但核心就是两个一个是缓存创建token数一个是缓存读取token数。你需要确认的目标很简单第一次请求时缓存创建token数稳步上升第二次及后续请求时缓存读取token数稳定出现并且数值接近你期望被缓存的长文本块的长度。如果连续多次请求都只看到创建值、读取值始终为零那说明你的请求结构还没有真正命中后缀缓存需要检查末尾块是否足够静态、是否达到了最小缓存长度。一个小经验把缓存读取token数打印到日志里做成监控看板的关键指标。这个数字直接反映你省下了多少input成本比单独看整体时延更直观。4.5 成本账一次改造能省多少钱我们来算一笔具体的账。假设一个请求每次携带2000 token静态资料和100 token动态问题总共2100 token。以缓存读取约为普通输入0.1倍的通用计费比例为参照不考虑输出token完全不缓存每次消耗2100 token的普通输入成本。后缀缓存第一次2000 token按缓存创建计费约1.25倍100 token普通计费总成本反而略高。后缀缓存第2到10次100 token普通计费2000 token按缓存读取计费约0.1倍总消耗约300 token的换算成本相比2100 token省了85%左右。实际测试中我在一个日调用量约2万次的服务上做了类似改造。同样数量的静态上下文整体input成本下降了70%以上响应时延也降了大概700到900毫秒。这个收益在每次prompt巨大的场景里非常可观。5. 实战中的坑与建议5.1 拆分粒度与断点数量有人喜欢把prompt里所有静态内容全堆到末尾结果搞出一个巨大无比的缓存尾巴。这表面上看缓存命中率很高但首次缓存创建成本也会变得很高。如果后续实际读取率不高你反而亏了。我的建议是把静态内容按复用频率分层复用频率最高的段落放末尾复用频率一般的段落放中间复用机会不大的一次性内容直接放开头。断点数量宁少勿多先保证最重要的那段尾巴稳定命中再考虑优化其他段落。5.2 小心每次都漏的伪命中有一种情况很迷惑人你看到缓存读取token数不为零但细看发现读取的只是某个小片段根本不是你以为的那段长文本。这种情况多半是因为服务端在你标记的缓存断点之外还自动识别了其他可复用片段导致统计数字被稀释了。判断是不是伪命中可以把读取token数和你预期缓存的文本长度做个占比对比。如果占比长期低于50%说明你的固定尾巴并没有真正稳定下来继续检查末尾块的拼接逻辑尤其是结尾有没有隐性空格、换行符或动态时间戳之类的东西。5.3 别让动态内容污染后缀我之前踩过一个大坑一个请求的动态内容里包含当前时间。我明明把它放在开头了但某个回调逻辑里又把这个时间拼到了末尾的内容备注位置。结果日志里缓存读取token数一直是0排查了半天才发现是末尾多了一个每次变化的时间字符串。这类问题的排查建议很朴素看一下请求日志里末尾文本块每两次请求之间是否完全一致。用脚本比对连续请求的最后一个文本块的哈希值只要哈希不一致就说明尾巴被污染了。5.4 监控命中的指标与工具不要只靠响应体里的token字段要在生产环境中建立两个辅助指标缓存读取token占input总token的比例这个数越高说明你的prompt结构越健康。连续请求之间最后一个文本块的内容重复率用于提前发现尾巴漂移问题。如果你用的是第三方SDK注意部分SDK的token明细字段没有完全透出需要查看底层HTTP响应头才能拿到缓存相关数值。遇到这种情况直接在HTTP层面打印响应头会更可靠。5.5 我给团队定的落地顺序在实践中我越来越相信先调结构再调参数这个原则。后缀缓存复用并不需要你买新设备、换新模型它只是要求你把消息块的排列顺序重新想一遍。我在团队里通常建议按这个顺序落地先给所有请求打印缓存token明细找出持续创建、从不读取的请求。从这些请求里挑出末尾内容固定、长度超过最小缓存门槛的那一类做排列顺序调整。调整后至少观察24小时对比之前的缓存读取占比和平均input成本。确认稳定后再逐步把其他场景迁移到这个布局上来。这样不会一次性改动过多也方便在灰度过程中快速回归。这个优化思路再往下走还可以延伸到系统提示词的分层组织、长对话历史的分段缓存甚至和模型路由策略结合把高频请求打到缓存命中率更高的模型上。但无论怎么扩展核心始终是那一句话缓存是跟着稳定内容走的哪段内容最稳定就应该把哪段内容放在最适合命中的位置。后缀缓存复用不是魔法只是一个尊重缓存规则的prompt布局技巧。