1. 从一次账单异常说起Prompt 缓存到底在解决什么问题如果你正在调用大模型 API 做产品大概率遇到过这种情况同一个系统提示词、同一段背景资料在一天之内被重复发送了几百上千次月底账单出来的时候输入 token 的费用占了总成本的大头。更让人头疼的是明明内容完全一样每次请求都要重新计算一遍延迟也降不下来。这不是你的代码写得有问题而是没有用上Prompt 缓存这个机制。Prompt 缓存的核心思路非常朴素把那些反复出现、内容固定的前缀部分比如系统提示词、工具定义、知识库片段、few-shot 示例在服务端缓存下来后续请求如果命中相同前缀就直接复用已经计算好的中间状态不再重复计费、不再重复计算。它解决的是重复输入成本高、首 token 延迟长这两个最实际的痛点。适合所有在做 LLM 应用开发的人——不管你是刚接第一个 API 的新手还是已经在优化线上成本的老手这套机制都值得花时间吃透。但这里有个容易被忽略的事实缓存不是自动生效的它需要你在请求里显式声明断点。很多人以为只要内容一样平台就会自动缓存结果发现账单没降、延迟没变然后开始怀疑是不是平台虚标。实际上缓存机制的设计里有一个关键概念叫断点breakpoint你得告诉系统从这里开始前面的内容请缓存起来。断点打在哪里、打几个、怎么和计费规则配合直接决定了你能省多少钱。这篇文章就把计费逻辑和断点策略这两件事拆开讲清楚顺带把实际踩过的坑一并交代。2. 计费规则拆解缓存命中与未命中到底差在哪2.1 输入 token 的三档定价逻辑要理解缓存的价值先得搞清楚计费是怎么分档的。目前主流平台的计费模型里输入 token 通常分成三档价格依次递减计费类型说明相对价格以某平台为例普通输入 token未命中缓存的完整输入基准价 1x缓存写入 token首次建立缓存时写入的部分约 1.25x缓存命中 token后续请求复用缓存的部分约 0.1x这张表里最关键的信息是缓存命中的价格只有普通输入的十分之一左右。也就是说如果你的系统提示词有 2000 token一天被调用 1000 次不做缓存的话这 200 万 token 全按基准价算做了缓存之后第一次写入按 1.25 倍算一次后面 999 次全按 0.1 倍算成本差距是数量级的。但这里有个反直觉的点缓存写入比普通输入还贵。很多人第一次看到这个规则会疑惑——既然要省钱为什么写入还要加价原因在于建立缓存本身需要服务端额外做一次状态持久化这个开销是真实存在的。所以缓存策略的本质是一道数学题写入成本 N 次命中成本 N 次普通输入成本只有当复用次数足够多时缓存才划算。2.2 算一笔账多少次复用才回本假设一段前缀有 1000 token普通输入单价为 P缓存写入为 1.25P缓存命中为 0.1P。设复用次数为 N包含首次写入那一次则不做缓存N × 1000 × P做缓存1000 × 1.25P (N-1) × 1000 × 0.1P令两者相等N 1.25 0.1(N-1)解得N ≈ 1.28。也就是说只要同一段前缀被复用超过 2 次缓存就开始省钱。这个门槛低得超出很多人的预期。实际场景里系统提示词在一天内被调用几十上百次是常态所以缓存几乎是稳赚不赔的。真正需要权衡的不是要不要缓存而是缓存多长的前缀、断点打在哪里。注意不同平台的缓存有效期不一样有的是 5 分钟有的是 1 小时。如果你的调用频率很低比如同一段前缀隔几小时才用一次可能缓存早就过期了这时候写入成本就白花了。所以缓存策略要结合你的实际调用节奏来定。2.3 缓存命中的判定条件前缀必须完全一致缓存命中不是内容相似就行而是要求从开头到断点位置的 token 序列完全一致一个字符都不能差。这一点极其重要因为很多人在系统提示词里塞了动态内容——比如当前时间戳、用户 ID、随机数——结果每次请求前缀都不一样缓存永远命中不了钱照花延迟照旧。我见过一个典型的错误案例有人在系统提示词开头写了当前时间是 2024-01-15 10:30:00想着让模型知道时间。结果每次请求这个时间都在变整个前缀的缓存全部失效。正确的做法是把动态内容放到断点之后或者干脆放到用户消息里让固定的部分保持稳定。3. 断点机制缓存控制的核心开关3.1 断点是什么为什么必须显式声明断点breakpoint是你在请求里主动标记的一个位置含义是从这个位置往前的内容请缓存起来。它不是自动的因为服务端无法猜测你希望缓存哪一段——可能你想缓存系统提示词也可能想缓存整个知识库还可能只想缓存工具定义。显式声明让控制权回到开发者手里。在请求结构里断点通常通过一个缓存控制字段来标记挂在消息对象上。以常见的消息数组结构为例大致长这样{ messages: [ { role: system, content: [ { type: text, text: 你是一个专业的客服助手以下是产品知识库……, cache_control: { type: ephemeral } } ] }, { role: user, content: 帮我查一下退货政策 } ] }这里的cache_control就是断点标记。它挂在哪个内容块上就表示到这个块结束为止的前缀可以被缓存。ephemeral表示这是临时缓存平台会按自己的策略管理生命周期。3.2 断点位置的选择越靠前越省但别乱放断点打在哪里直接决定了缓存覆盖的范围。原则很简单断点之前的内容越多、越稳定缓存收益越大。所以理想情况下断点应该打在整个请求里最靠后的那个稳定边界上。但这里有个常见的误区有人为了最大化缓存范围把断点打在最末尾结果把用户消息也包进去了。用户消息每次都不一样导致缓存永远命中不了。正确的做法是找到固定内容和动态内容的分界线断点打在这条线上。举个实际例子。假设你的请求结构是系统提示词固定2000 token工具定义固定1500 token知识库片段半固定可能按用户查询动态检索3000 token用户消息动态100 token这种情况下断点应该打在工具定义之后、知识库之前。这样系统提示词和工具定义这 3500 token 稳定命中缓存知识库和用户消息走普通计费。如果你把知识库也纳入缓存由于它是动态检索的命中率会很低反而浪费写入成本。3.3 多个断点的分层缓存策略部分平台支持在同一个请求里打多个断点形成分层缓存。这个能力在复杂场景下非常有用。比如第一个断点系统提示词最稳定命中率最高第二个断点工具定义 少量示例较稳定第三个断点知识库片段按业务模块分组中等稳定分层的好处是即使后面的内容变了前面的缓存依然有效。比如用户切换了业务模块知识库片段变了但系统提示词和工具定义的缓存不受影响依然命中。这比只打一个断点的鲁棒性高得多。不过要注意断点数量通常有上限常见是 4 个而且每个断点都会带来一次写入开销。所以不是越多越好要根据内容的稳定层级来设计。我的经验是把内容按变化频率分成 2 到 3 层就够了层数太多管理成本反而上升。4. 实战中的断点设计几个真实场景的取舍4.1 客服机器人系统提示词 知识库的两段式客服机器人是最典型的缓存受益场景。系统提示词通常很长角色设定、回复规范、安全边界而且完全固定知识库片段则根据用户问题动态检索。我的做法是系统提示词单独打一个断点确保它 100% 命中知识库片段不打断点走普通计费用户消息自然也在断点之后这样设计的原因是知识库片段的检索结果每次都可能不同命中率低打断点反而增加写入成本。而系统提示词是铁打的固定内容命中率接近 100%收益最稳定。实测下来一个 2500 token 的系统提示词在日均 5000 次调用的情况下光这一项每月就能省下相当可观的费用。而且首 token 延迟从原来的 800ms 左右降到了 300ms 以内用户体验的提升是能直接感知到的。4.2 代码助手工具定义是缓存的大头代码助手类应用的特点是工具定义特别长。一个功能完整的代码助手可能定义了十几个工具每个工具的 schema 描述加起来轻松超过 3000 token。这部分内容完全固定是缓存的绝佳目标。我的策略是把工具定义和系统提示词合并成一个断点放在消息数组的最前面。因为这两部分都是固定的合并缓存可以减少断点数量降低管理复杂度。实测命中率能稳定在 95% 以上。这里有个细节值得注意工具定义的顺序也会影响缓存命中。如果你在代码里用字典或哈希表存储工具定义每次序列化出来的顺序可能不一样导致前缀不一致缓存失效。解决办法是固定工具定义的顺序比如按名称排序后再序列化。这个坑我踩过排查了半天才发现是顺序问题。4.3 多轮对话断点该不该跟着对话走多轮对话场景比较特殊因为历史消息会不断累积。有人会想既然历史消息也是固定的已经发生过的对话不会变那是不是可以把断点打在历史消息的末尾让整个对话历史都缓存起来理论上可行但实际要谨慎。原因是多轮对话的历史每轮都在增长上一轮的断点位置和这一轮不一样缓存前缀对不上命中率会打折扣。而且对话历史越长写入成本越高。我的建议是多轮对话只缓存系统提示词和工具定义这些真正固定的部分对话历史走普通计费。除非你的对话轮次非常固定比如固定 3 轮否则跟着对话走不划算。5. 那些文档里不会写的踩坑记录5.1 动态内容混进前缀最常见的缓存杀手前面提过时间戳的问题但实际项目里混进前缀的动态内容远不止这一种。我整理了一份缓存杀手清单都是实际踩过的时间戳和日期系统提示词里写今天是 X 月 X 日每次请求都变用户 ID 和会话 ID为了个性化把用户标识拼进了系统提示词随机数或 UUID某些框架会自动注入请求 ID动态排序的列表比如工具列表、知识库片段列表顺序不固定浮点数格式化差异同一个数值有时序列化成1.0有时是1导致前缀不一致排查这类问题的方法很简单把两次请求的完整 payload 打印出来逐字符对比前缀部分。只要有一个字符不同缓存就不会命中。我一般会在开发阶段加一个断言检查前缀的哈希值是否稳定不稳定就直接报警。5.2 缓存过期与调用节奏的错配缓存是有生命周期的常见的是 5 分钟到 1 小时。如果你的调用节奏和缓存周期错配就会出现刚写入就过期的尴尬情况。比如你的应用是定时任务每小时跑一次每次跑的时候缓存刚好过期那写入成本就白花了。解决办法有两个一是调整调用节奏让请求集中在缓存有效期内二是评估是否值得缓存如果复用次数太少干脆不用缓存走普通计费反而更省。我一般会统计一段时间的调用间隔分布如果大部分间隔都超过缓存有效期就放弃缓存。5.3 断点数量超限导致的静默失败部分平台对断点数量有硬性限制超过之后不会报错而是静默忽略多余的断点。这个行为很坑因为你的代码看起来没问题但实际缓存没生效。我遇到过打了 6 个断点结果只有前 4 个生效的情况排查了很久才发现是数量限制。建议在代码里对断点数量做校验超过平台上限就直接报错别让它静默失败。同时把断点配置集中管理方便统一调整。5.4 缓存命中率监控没有度量就没有优化上线缓存之后一定要监控命中率。大部分平台在 API 响应里会返回缓存相关的统计字段比如命中 token 数、写入 token 数。把这些数据采集起来做成看板你才能知道缓存策略到底有没有效果。我一般关注三个指标命中率命中 token / 总输入 token、写入频率单位时间内的缓存写入次数、成本节省比例对比不做缓存的预估成本。如果命中率低于 70%说明前缀稳定性有问题需要排查如果写入频率过高说明缓存频繁过期需要调整策略。6. 把缓存做稳的几个工程习惯6.1 前缀内容版本化管理系统提示词和工具定义不是一成不变的产品迭代时经常要改。每次改动都会导致缓存失效这是正常的。但如果改动频繁缓存就一直建立不起来。我的做法是给前缀内容做版本管理每次改动分配一个新版本号旧版本的缓存自然过期新版本重新建立。同时控制改动频率非必要不改改之前评估对缓存的影响。具体操作上我会把系统提示词和工具定义抽成独立的配置文件用版本号命名比如system_prompt_v3.txt。代码里引用版本号而不是直接硬编码内容。这样改动有迹可循也方便回滚。6.2 请求构造的确定性保证要保证缓存命中请求构造必须是确定性的。这意味着同样的输入每次序列化出来的 payload 必须完全一致。除了前面提到的工具顺序问题还要注意JSON 序列化时 key 的顺序要固定浮点数的格式化要统一字符串的编码要一致统一用 UTF-8换行符要统一\n还是\r\n这些细节看起来琐碎但任何一个不一致都会导致缓存失效。我一般会写一个单元测试对同一份输入连续序列化两次断言结果完全一致。这个测试能挡住大部分低级错误。6.3 灰度上线与回滚预案缓存策略的调整会影响线上成本和延迟所以不要一次性全量切换。我的做法是先在小流量上验证观察命中率和成本变化确认没问题再逐步放量。同时准备好回滚预案一旦发现异常比如命中率骤降、延迟上升能快速切回原策略。灰度期间要重点观察的指标包括缓存命中率、首 token 延迟、总成本。如果命中率符合预期但延迟没降可能是平台侧的缓存读取有额外开销需要进一步评估是否值得。7. 关于缓存策略我个人的几点体会做了几个带缓存的 LLM 应用之后我最大的体会是缓存不是配置项而是架构设计的一部分。它要求你在设计请求结构的时候就有意识地把内容按稳定性分层。如果一开始没想清楚后面再补缓存往往要重构请求构造逻辑成本很高。另一个体会是不要为了缓存而缓存。有些场景下复用次数本来就少硬上缓存反而增加复杂度和写入成本。判断标准很简单算一下复用次数超过 2 次就值得低于 2 次就别折腾。这个门槛低但也不是所有场景都能达到。最后分享一个小技巧把缓存命中率做成一个实时告警指标。一旦命中率跌破阈值立刻收到通知。这样能在问题扩散之前就发现避免成本悄悄上涨。我现在的项目里这个告警帮我抓到过好几次前缀被意外改动的问题省了不少排查时间。
1. 从一次账单异常说起Prompt 缓存到底在解决什么问题如果你正在调用大模型 API 做产品大概率遇到过这种情况同一个系统提示词、同一段背景资料在一天之内被重复发送了几百上千次月底账单出来的时候输入 token 的费用占了总成本的大头。更让人头疼的是明明内容完全一样每次请求都要重新计算一遍延迟也降不下来。这不是你的代码写得有问题而是没有用上Prompt 缓存这个机制。Prompt 缓存的核心思路非常朴素把那些反复出现、内容固定的前缀部分比如系统提示词、工具定义、知识库片段、few-shot 示例在服务端缓存下来后续请求如果命中相同前缀就直接复用已经计算好的中间状态不再重复计费、不再重复计算。它解决的是重复输入成本高、首 token 延迟长这两个最实际的痛点。适合所有在做 LLM 应用开发的人——不管你是刚接第一个 API 的新手还是已经在优化线上成本的老手这套机制都值得花时间吃透。但这里有个容易被忽略的事实缓存不是自动生效的它需要你在请求里显式声明断点。很多人以为只要内容一样平台就会自动缓存结果发现账单没降、延迟没变然后开始怀疑是不是平台虚标。实际上缓存机制的设计里有一个关键概念叫断点breakpoint你得告诉系统从这里开始前面的内容请缓存起来。断点打在哪里、打几个、怎么和计费规则配合直接决定了你能省多少钱。这篇文章就把计费逻辑和断点策略这两件事拆开讲清楚顺带把实际踩过的坑一并交代。2. 计费规则拆解缓存命中与未命中到底差在哪2.1 输入 token 的三档定价逻辑要理解缓存的价值先得搞清楚计费是怎么分档的。目前主流平台的计费模型里输入 token 通常分成三档价格依次递减计费类型说明相对价格以某平台为例普通输入 token未命中缓存的完整输入基准价 1x缓存写入 token首次建立缓存时写入的部分约 1.25x缓存命中 token后续请求复用缓存的部分约 0.1x这张表里最关键的信息是缓存命中的价格只有普通输入的十分之一左右。也就是说如果你的系统提示词有 2000 token一天被调用 1000 次不做缓存的话这 200 万 token 全按基准价算做了缓存之后第一次写入按 1.25 倍算一次后面 999 次全按 0.1 倍算成本差距是数量级的。但这里有个反直觉的点缓存写入比普通输入还贵。很多人第一次看到这个规则会疑惑——既然要省钱为什么写入还要加价原因在于建立缓存本身需要服务端额外做一次状态持久化这个开销是真实存在的。所以缓存策略的本质是一道数学题写入成本 N 次命中成本 N 次普通输入成本只有当复用次数足够多时缓存才划算。2.2 算一笔账多少次复用才回本假设一段前缀有 1000 token普通输入单价为 P缓存写入为 1.25P缓存命中为 0.1P。设复用次数为 N包含首次写入那一次则不做缓存N × 1000 × P做缓存1000 × 1.25P (N-1) × 1000 × 0.1P令两者相等N 1.25 0.1(N-1)解得N ≈ 1.28。也就是说只要同一段前缀被复用超过 2 次缓存就开始省钱。这个门槛低得超出很多人的预期。实际场景里系统提示词在一天内被调用几十上百次是常态所以缓存几乎是稳赚不赔的。真正需要权衡的不是要不要缓存而是缓存多长的前缀、断点打在哪里。注意不同平台的缓存有效期不一样有的是 5 分钟有的是 1 小时。如果你的调用频率很低比如同一段前缀隔几小时才用一次可能缓存早就过期了这时候写入成本就白花了。所以缓存策略要结合你的实际调用节奏来定。2.3 缓存命中的判定条件前缀必须完全一致缓存命中不是内容相似就行而是要求从开头到断点位置的 token 序列完全一致一个字符都不能差。这一点极其重要因为很多人在系统提示词里塞了动态内容——比如当前时间戳、用户 ID、随机数——结果每次请求前缀都不一样缓存永远命中不了钱照花延迟照旧。我见过一个典型的错误案例有人在系统提示词开头写了当前时间是 2024-01-15 10:30:00想着让模型知道时间。结果每次请求这个时间都在变整个前缀的缓存全部失效。正确的做法是把动态内容放到断点之后或者干脆放到用户消息里让固定的部分保持稳定。3. 断点机制缓存控制的核心开关3.1 断点是什么为什么必须显式声明断点breakpoint是你在请求里主动标记的一个位置含义是从这个位置往前的内容请缓存起来。它不是自动的因为服务端无法猜测你希望缓存哪一段——可能你想缓存系统提示词也可能想缓存整个知识库还可能只想缓存工具定义。显式声明让控制权回到开发者手里。在请求结构里断点通常通过一个缓存控制字段来标记挂在消息对象上。以常见的消息数组结构为例大致长这样{ messages: [ { role: system, content: [ { type: text, text: 你是一个专业的客服助手以下是产品知识库……, cache_control: { type: ephemeral } } ] }, { role: user, content: 帮我查一下退货政策 } ] }这里的cache_control就是断点标记。它挂在哪个内容块上就表示到这个块结束为止的前缀可以被缓存。ephemeral表示这是临时缓存平台会按自己的策略管理生命周期。3.2 断点位置的选择越靠前越省但别乱放断点打在哪里直接决定了缓存覆盖的范围。原则很简单断点之前的内容越多、越稳定缓存收益越大。所以理想情况下断点应该打在整个请求里最靠后的那个稳定边界上。但这里有个常见的误区有人为了最大化缓存范围把断点打在最末尾结果把用户消息也包进去了。用户消息每次都不一样导致缓存永远命中不了。正确的做法是找到固定内容和动态内容的分界线断点打在这条线上。举个实际例子。假设你的请求结构是系统提示词固定2000 token工具定义固定1500 token知识库片段半固定可能按用户查询动态检索3000 token用户消息动态100 token这种情况下断点应该打在工具定义之后、知识库之前。这样系统提示词和工具定义这 3500 token 稳定命中缓存知识库和用户消息走普通计费。如果你把知识库也纳入缓存由于它是动态检索的命中率会很低反而浪费写入成本。3.3 多个断点的分层缓存策略部分平台支持在同一个请求里打多个断点形成分层缓存。这个能力在复杂场景下非常有用。比如第一个断点系统提示词最稳定命中率最高第二个断点工具定义 少量示例较稳定第三个断点知识库片段按业务模块分组中等稳定分层的好处是即使后面的内容变了前面的缓存依然有效。比如用户切换了业务模块知识库片段变了但系统提示词和工具定义的缓存不受影响依然命中。这比只打一个断点的鲁棒性高得多。不过要注意断点数量通常有上限常见是 4 个而且每个断点都会带来一次写入开销。所以不是越多越好要根据内容的稳定层级来设计。我的经验是把内容按变化频率分成 2 到 3 层就够了层数太多管理成本反而上升。4. 实战中的断点设计几个真实场景的取舍4.1 客服机器人系统提示词 知识库的两段式客服机器人是最典型的缓存受益场景。系统提示词通常很长角色设定、回复规范、安全边界而且完全固定知识库片段则根据用户问题动态检索。我的做法是系统提示词单独打一个断点确保它 100% 命中知识库片段不打断点走普通计费用户消息自然也在断点之后这样设计的原因是知识库片段的检索结果每次都可能不同命中率低打断点反而增加写入成本。而系统提示词是铁打的固定内容命中率接近 100%收益最稳定。实测下来一个 2500 token 的系统提示词在日均 5000 次调用的情况下光这一项每月就能省下相当可观的费用。而且首 token 延迟从原来的 800ms 左右降到了 300ms 以内用户体验的提升是能直接感知到的。4.2 代码助手工具定义是缓存的大头代码助手类应用的特点是工具定义特别长。一个功能完整的代码助手可能定义了十几个工具每个工具的 schema 描述加起来轻松超过 3000 token。这部分内容完全固定是缓存的绝佳目标。我的策略是把工具定义和系统提示词合并成一个断点放在消息数组的最前面。因为这两部分都是固定的合并缓存可以减少断点数量降低管理复杂度。实测命中率能稳定在 95% 以上。这里有个细节值得注意工具定义的顺序也会影响缓存命中。如果你在代码里用字典或哈希表存储工具定义每次序列化出来的顺序可能不一样导致前缀不一致缓存失效。解决办法是固定工具定义的顺序比如按名称排序后再序列化。这个坑我踩过排查了半天才发现是顺序问题。4.3 多轮对话断点该不该跟着对话走多轮对话场景比较特殊因为历史消息会不断累积。有人会想既然历史消息也是固定的已经发生过的对话不会变那是不是可以把断点打在历史消息的末尾让整个对话历史都缓存起来理论上可行但实际要谨慎。原因是多轮对话的历史每轮都在增长上一轮的断点位置和这一轮不一样缓存前缀对不上命中率会打折扣。而且对话历史越长写入成本越高。我的建议是多轮对话只缓存系统提示词和工具定义这些真正固定的部分对话历史走普通计费。除非你的对话轮次非常固定比如固定 3 轮否则跟着对话走不划算。5. 那些文档里不会写的踩坑记录5.1 动态内容混进前缀最常见的缓存杀手前面提过时间戳的问题但实际项目里混进前缀的动态内容远不止这一种。我整理了一份缓存杀手清单都是实际踩过的时间戳和日期系统提示词里写今天是 X 月 X 日每次请求都变用户 ID 和会话 ID为了个性化把用户标识拼进了系统提示词随机数或 UUID某些框架会自动注入请求 ID动态排序的列表比如工具列表、知识库片段列表顺序不固定浮点数格式化差异同一个数值有时序列化成1.0有时是1导致前缀不一致排查这类问题的方法很简单把两次请求的完整 payload 打印出来逐字符对比前缀部分。只要有一个字符不同缓存就不会命中。我一般会在开发阶段加一个断言检查前缀的哈希值是否稳定不稳定就直接报警。5.2 缓存过期与调用节奏的错配缓存是有生命周期的常见的是 5 分钟到 1 小时。如果你的调用节奏和缓存周期错配就会出现刚写入就过期的尴尬情况。比如你的应用是定时任务每小时跑一次每次跑的时候缓存刚好过期那写入成本就白花了。解决办法有两个一是调整调用节奏让请求集中在缓存有效期内二是评估是否值得缓存如果复用次数太少干脆不用缓存走普通计费反而更省。我一般会统计一段时间的调用间隔分布如果大部分间隔都超过缓存有效期就放弃缓存。5.3 断点数量超限导致的静默失败部分平台对断点数量有硬性限制超过之后不会报错而是静默忽略多余的断点。这个行为很坑因为你的代码看起来没问题但实际缓存没生效。我遇到过打了 6 个断点结果只有前 4 个生效的情况排查了很久才发现是数量限制。建议在代码里对断点数量做校验超过平台上限就直接报错别让它静默失败。同时把断点配置集中管理方便统一调整。5.4 缓存命中率监控没有度量就没有优化上线缓存之后一定要监控命中率。大部分平台在 API 响应里会返回缓存相关的统计字段比如命中 token 数、写入 token 数。把这些数据采集起来做成看板你才能知道缓存策略到底有没有效果。我一般关注三个指标命中率命中 token / 总输入 token、写入频率单位时间内的缓存写入次数、成本节省比例对比不做缓存的预估成本。如果命中率低于 70%说明前缀稳定性有问题需要排查如果写入频率过高说明缓存频繁过期需要调整策略。6. 把缓存做稳的几个工程习惯6.1 前缀内容版本化管理系统提示词和工具定义不是一成不变的产品迭代时经常要改。每次改动都会导致缓存失效这是正常的。但如果改动频繁缓存就一直建立不起来。我的做法是给前缀内容做版本管理每次改动分配一个新版本号旧版本的缓存自然过期新版本重新建立。同时控制改动频率非必要不改改之前评估对缓存的影响。具体操作上我会把系统提示词和工具定义抽成独立的配置文件用版本号命名比如system_prompt_v3.txt。代码里引用版本号而不是直接硬编码内容。这样改动有迹可循也方便回滚。6.2 请求构造的确定性保证要保证缓存命中请求构造必须是确定性的。这意味着同样的输入每次序列化出来的 payload 必须完全一致。除了前面提到的工具顺序问题还要注意JSON 序列化时 key 的顺序要固定浮点数的格式化要统一字符串的编码要一致统一用 UTF-8换行符要统一\n还是\r\n这些细节看起来琐碎但任何一个不一致都会导致缓存失效。我一般会写一个单元测试对同一份输入连续序列化两次断言结果完全一致。这个测试能挡住大部分低级错误。6.3 灰度上线与回滚预案缓存策略的调整会影响线上成本和延迟所以不要一次性全量切换。我的做法是先在小流量上验证观察命中率和成本变化确认没问题再逐步放量。同时准备好回滚预案一旦发现异常比如命中率骤降、延迟上升能快速切回原策略。灰度期间要重点观察的指标包括缓存命中率、首 token 延迟、总成本。如果命中率符合预期但延迟没降可能是平台侧的缓存读取有额外开销需要进一步评估是否值得。7. 关于缓存策略我个人的几点体会做了几个带缓存的 LLM 应用之后我最大的体会是缓存不是配置项而是架构设计的一部分。它要求你在设计请求结构的时候就有意识地把内容按稳定性分层。如果一开始没想清楚后面再补缓存往往要重构请求构造逻辑成本很高。另一个体会是不要为了缓存而缓存。有些场景下复用次数本来就少硬上缓存反而增加复杂度和写入成本。判断标准很简单算一下复用次数超过 2 次就值得低于 2 次就别折腾。这个门槛低但也不是所有场景都能达到。最后分享一个小技巧把缓存命中率做成一个实时告警指标。一旦命中率跌破阈值立刻收到通知。这样能在问题扩散之前就发现避免成本悄悄上涨。我现在的项目里这个告警帮我抓到过好几次前缀被意外改动的问题省了不少排查时间。
