Prompt Cache 怎么真正省钱：固定前缀、命中率、版本失效与权限隔离

很多团队看到供应商支持 Prompt Cache就以为打开一个参数长提示词的费用会自动下降。上线后却发现三种反常现象控制台显示偶尔命中月账单几乎没变为了提高命中把所有租户的资料塞进同一前缀形成权限风险Prompt 修改后旧缓存似乎失效团队却无法判断是正常版本切换、TTL 到期还是请求结构每次都在漂移。Prompt Cache 缓存的不是模型答案而是某段输入前缀经过模型计算得到的中间状态。新请求从开头拥有相同 Token 序列时服务可以复用这部分计算减少重复 Prefill。用户问题、动态检索结果和生成答案仍然不同模型依然执行后续输入与 Decode。因此它与“同一个问题直接返回旧答案”的响应缓存完全不同正确性边界也不同。真正省钱需要同时满足四个条件可复用内容足够长它放在输入最前面且序列化稳定在缓存有效期内重复出现缓存读取的折扣能够覆盖首次写入和未命中成本。任何一项不成立缓存开关都可能只是增加复杂度。本文建立一个供应商无关的方法先拆 Prompt生成稳定前缀指纹再从真实 usage 读取缓存写入与读取 Token用当前模型价格参数计算而不是硬编码价格通过冷启动、热命中、版本切换和跨租户四组实验验证最后把版本、TTL、数据保留和权限边界纳入日常运维。1. Prompt Cache 缓存的到底是什么自回归模型处理输入时会为每一层 attention 计算 Key 和 Value。若后续请求拥有相同前缀服务可以复用已经生成的 KV 状态从变化位置继续计算。缓存通常依附于特定模型、具体 Token 序列、请求参数和供应商路由不是一份可以随意拷贝到另一模型的文本缓存。相同 Token 前缀工具定义系统规则稳定示例公共文档缓存断点/可复用前缀本次检索结果用户问题模型继续 Prefill Decode缓存命中响应缓存的键可以是规范化问题、用户权限和模型版本命中后不调用模型Prompt Cache 命中后仍会调用模型只是少算前缀。前者适合答案允许复用的确定性场景必须处理陈旧答案后者适合系统指令、工具 Schema、few-shot 示例和长公共上下文生成结果仍可随问题变化。不要把两者的命中率混用。响应缓存的一次命中可能省掉整次调用Prompt Cache 的一次命中只省掉被复用的输入段。如果总输入一万 Token只命中开头一千价值与命中九千完全不同。正确指标是缓存读取 Token 占可缓存输入 Token 的比例并结合费用权重和请求量计算。2. 先算经济账再决定是否缓存设稳定前缀长度为P每次变化部分为D。未缓存输入单价为C_normal缓存写入单价为C_write缓存读取单价为C_read。一次冷写加N次热读的前缀成本为P × C_write N × P × C_read不使用缓存时同样的N 1次请求前缀成本为(N 1) × P × C_normal变化部分D和输出 Token 在两种方案中通常都要付费所以评估缓存收益时单独比较前缀更清楚。若供应商的自动缓存不收额外写入费C_write可能等于普通输入费显式缓存或更长 TTL 可能有不同倍率。价格和模型支持会变化必须从当前官方定价页填入不能把文章里的历史数字写死到生产代码。下面的纯标准库脚本接收本次观察到的普通输入、缓存写入、缓存读取与输出 Token以及对应每百万 Token 价格计算实际费用和“假设全部按普通输入计费”的基线。它不假定任何厂商字段只处理你已经归一化后的 usage。# cache_cost.pyfrom__future__importannotationsimportargparsefromdecimalimportDecimal MILLIONDecimal(1000000)defmoney(tokens:int,price_per_million:Decimal)-Decimal:returnDecimal(tokens)*price_per_million/MILLION parserargparse.ArgumentParser()parser.add_argument(--ordinary,typeint,requiredTrue,help未缓存输入 token)parser.add_argument(--write,typeint,requiredTrue,help写入缓存 token)parser.add_argument(--read,typeint,requiredTrue,help从缓存读取 token)parser.add_argument(--output,typeint,requiredTrue)parser.add_argument(--ordinary-price,typeDecimal,requiredTrue)parser.add_argument(--write-price,typeDecimal,requiredTrue)parser.add_argument(--read-price,typeDecimal,requiredTrue)parser.add_argument(--output-price,typeDecimal,requiredTrue)argsparser.parse_args()actual(money(args.ordinary,args.ordinary_price)money(args.write,args.write_price)money(args.read,args.read_price)money(args.output,args.output_price))baselinemoney(args.ordinaryargs.writeargs.read,args.ordinary_price)money(args.output,args.output_price)savingbaseline-actualprint(factual{actual:.8f})print(fbaseline{baseline:.8f})print(fsaving{saving:.8f})print(fsaving_rate{(saving/baseline*100ifbaselineelseDecimal(0)):.2f}%)脚本的价格参数必须和模型、区域、TTL、批处理方式一致。若供应商把写入、读取和普通输入拆成不同 usage 字段直接映射若只返回cached_tokens则把总输入减去 cached 得到普通输入并确认是否存在单独写入费用。无法确认时标记未知不要用零填充。缓存是否值得还取决于“同一前缀在 TTL 内被复用几次”。一份两万 Token 的制度文档每天只问一次五分钟缓存很难命中一个两千 Token 的公共系统提示每秒被调用几十次复用更稳定。应按前缀族统计复用间隔分布而不是用全站请求量推算。3. 固定前缀的正确顺序一个易命中的请求通常按“变化频率从低到高”排列工具定义、系统规则、固定 few-shot、稳定公共资料、本次检索片段、用户身份相关状态、当前问题。供应商按前缀匹配时前面任何 Token 变化都会使后续内容无法沿同一条前缀复用。最常见的破坏项是时间戳、请求 ID、随机数和用户名称。把“当前时间为……”放在 system 第一行会让整个前缀每秒变化把追踪号写进 Prompt 只是为了日志关联也会白白打散缓存。追踪信息放 HTTP Header 或审计元数据真正需要模型理解的当前日期才放到稳定段之后。工具定义顺序同样重要。即使 JSON 对象语义相同属性顺序、空白和描述文字变化都可能生成不同 Token。应用启动时从确定版本的 Schema 构建一次稳定序列不要每个请求从无序来源重新拼装。多工具列表要按固定标识排序但不能在语义依赖顺序的接口上擅自重排。下面的构建器将稳定前缀和动态后缀分开使用规范 JSON 生成指纹。指纹用于观测和版本核对不替代供应商自己的缓存键。它还拒绝在稳定前缀中出现已知动态占位符防止时间戳不小心进入缓存段。# prompt_builder.pyfrom__future__importannotationsimporthashlibimportjsonfromdataclassesimportdataclassfromtypingimportAny FORBIDDEN({{request_id}},{{timestamp}},{{user_id}})defcanonical(value:Any)-str:returnjson.dumps(value,ensure_asciiFalse,sort_keysTrue,separators(,,:))dataclass(frozenTrue)classPromptPackage:messages:tuple[dict[str,str],...]prefix_fingerprint:strprompt_version:strdefbuild_prompt(*,policy:str,examples:tuple[str,...],public_context:str,private_context:str,question:str,prompt_version:str,)-PromptPackage:stable{policy:policy,examples:examples,public_context:public_context,prompt_version:prompt_version,}stable_textcanonical(stable)ifany(markerinstable_textformarkerinFORBIDDEN):raiseValueError(dynamic placeholder found in stable prefix)fingerprinthashlib.sha256(stable_text.encode(utf-8)).hexdigest()messages({role:system,content:stable_text},{role:user,content:canonical({private_context:private_context,question:question})},)returnPromptPackage(messages,fingerprint,prompt_version)if__name____main__:firstbuild_prompt(policy只依据材料回答不确定时明确说明。,examples(问状态答正常。,),public_context公共设备说明书版本 3。,private_contextA 租户今日巡检记录。,question设备状态如何,prompt_versionsupport-v3,)secondbuild_prompt(policy只依据材料回答不确定时明确说明。,examples(问状态答正常。,),public_context公共设备说明书版本 3。,private_contextA 租户另一条记录。,question是否需要维修,prompt_versionsupport-v3,)assertfirst.prefix_fingerprintsecond.prefix_fingerprintassertfirst.messages[0]second.messages[0]assertfirst.messages[1]!second.messages[1]print(first.prefix_fingerprint)代码里的sort_keysTrue只用于我们自己序列化的结构。直接调用 OpenAI 或 Anthropic SDK 时实际请求的 tools、system、messages 有固定层级不能把所有内容压成一个 JSON 字符串照搬。原则不变确定性生成、稳定内容在前、动态内容在后并对最终发送结构做快照测试。4. 最小可缓存长度与断点不是通用常数供应商通常设定最小可缓存前缀模型之间也可能不同。当前 OpenAI 官方 Prompt Caching 文档区分 GPT-5.6 及以后模型与更早模型新模型提供更明确的缓存模式、断点和 TTL 选项早期模型的缓存资格会受工具、图片、输出 Schema、推理强度等请求设置影响。Anthropic 则支持自动缓存与显式cache_control断点并提供不同 TTL 选择。不要把“超过一千 Token 必然命中”当成跨平台规则。先查目标模型官方页再从响应 usage 验证。最小长度满足只是获得缓存资格不代表路由到的机器一定保有条目也不代表前缀没有变化。断点应放在最后一个真正稳定的内容块之后。放得太早能复用的内容没有进入缓存放得太晚把每次变化的 RAG 结果或用户问题也包含进去下一次必然生成新键还可能产生不必要的缓存写入费。把稳定规则、固定示例和公共资料作为一个可版本化单元通常比在每个小段放断点更易管理。显式缓存不是越多断点越好。供应商可能限制断点数量或回看范围多个层级还会增加费用解释难度。只为存在不同变化频率且有实际复用的段落拆分例如工具定义月度变更、政策周度变更、对话历史每轮增长。没有观测数据时先用一个稳定前缀断点。5. 用四组实验验证不要看一次请求第一组是冷启动使用从未出现的前缀或等待 TTL 过期发送一次请求记录缓存写入、读取、普通输入、输出、TTFT 与总延迟。它建立首次请求成本。第二组是热命中在有效期内保持稳定前缀完全相同只修改末尾问题连续发送多次观察读取 Token 是否上升。第三组是版本切换只改变prompt_version或稳定政策的一句话预期旧前缀不再命中新版本发生一次写入后续再热读。这验证失效是否可解释。第四组是权限隔离两个租户使用内容相同但隔离键不同的请求确认不会跨租户读取同一信任组内再确认允许复用。每组至少保存请求包的脱敏指纹、模型、区域、缓存配置、发送时间、usage 和延迟。不要保存完整私密上下文来换取可复现性可以保存稳定公共段的版本与 HMAC 指纹。若要调试 Token 差异在隔离测试环境使用无敏感合成内容。下面脚本读取归一化后的 JSONL 结果按prefix_fingerprint统计读写 Token、请求数和 Token 命中率。每行形如{fingerprint:...,input_tokens:12000,cache_read_tokens:8000,cache_write_tokens:0}。字段映射由供应商适配层负责。# analyze_cache.pyfrom__future__importannotationsimportjsonimportsysfromcollectionsimportdefaultdict totals:dict[str,dict[str,int]]defaultdict(lambda:{requests:0,input:0,read:0,write:0})forlineinsys.stdin:ifnotline.strip():continuerowjson.loads(line)itemtotals[row[fingerprint]]item[requests]1item[input]int(row.get(input_tokens,0))item[read]int(row.get(cache_read_tokens,0))item[write]int(row.get(cache_write_tokens,0))forfingerprint,iteminsorted(totals.items()):eligibleitem[input]item[read]item[write]rateitem[read]/eligibleifeligibleelse0.0print(json.dumps({fingerprint:fingerprint[:12],**item,token_hit_rate:round(rate,4)},ensure_asciiFalse,))运行python analyze_cache.py normalized-usage.jsonl。这里的分母只是统一报表的基线必须结合供应商 usage 语义调整有的平台总输入已经包含读取 Token有的平台把普通、写入和读取互斥拆分。适配层写单元测试保证三者不会重复相加。除了 Token 命中率还要看请求命中率和节省金额。请求命中率高但每次只命中很短一段收益有限少量超长前缀命中可能贡献大部分节省。按prompt_version、模型、租户信任组和业务场景分组才能找到真正应该优化的前缀。6. 版本失效通过新键自然切换Prompt Cache 通常没有必要提供“全局删除旧缓存”的业务按钮。更安全的失效方式是不可变版本政策、工具 Schema、few-shot 或公共资料改变时生成新prompt_version和新指纹新请求自然写入新缓存旧条目不再被引用等待 TTL 淘汰。版本号不能只写latest。可使用发布号加内容摘要例如support-2026-09-21-a13f9c。摘要基于规范化稳定前缀计算发布系统保存“版本 → 摘要 → 变更原因 → 审批人”。这样出现回答变化时能确认当时究竟用了哪一版。不要把版本号放到稳定前缀前面以外的随意位置。它本身就是隔离旧新缓存的组成部分应和政策一起固定。灰度时一部分租户使用 v3一部分使用 v4指标按版本拆分。回滚只需重新指向 v3不需要修改 v3 内容。若在原版本上直接改文字既破坏审计也会造成看似相同版本却产生不同指纹。紧急撤销与普通更新不同。若旧前缀含错误权限说明或敏感数据不能只等待 TTL。停止生成旧版本请求调用供应商提供的缓存管理能力若有缩短或等待保留期并评估供应商数据删除流程。更重要的是修复数据进入缓存前的授权检查因为删除不能抵消已经发生的越权发送。模型版本、工具 Schema、图像、响应格式和推理参数也可能影响缓存身份。应用自己的prompt_version只描述业务前缀不应假设它能跨模型共享。报表键至少包含供应商、模型、区域、业务版本与信任边界避免把两个无法复用的流量错误合并。7. TTL更长不一定更省TTL 决定条目多久没有使用后失效或最多保留多久。更长 TTL 提高低频前缀再次命中的机会但可能有额外写入价格、数据保留义务和容量限制。选择依据是复用间隔分布若九成复用发生在两分钟内延长到一小时未必增加多少命中若批处理任务每半小时重复同一政策短 TTL 会不断冷写。当前 Anthropic 官方文档说明自动缓存默认使用短 TTL并可选择更长的一小时 TTL价格不同OpenAI 官方文档也按模型与组织数据政策区分内存和扩展保留。具体支持与价格会更新部署前查目标模型页面并确认 Zero Data Retention 等组织设置是否允许扩展保留。不要用定时“保温请求”维持所有缓存。保温本身付费、制造无业务价值的推理还可能掩盖本来不值得缓存的低频前缀。只有经经济账证明保温成本低于冷写成本、且业务对冷启动延迟敏感时才为少数关键前缀使用受控预热。发布后预热也应有限。新版本可以用一条无敏感的标准请求建立缓存并验证 usage但不要同时从所有副本、所有区域发起避免重复写入。缓存可能是机器本地的流量路由会影响复用供应商若提供缓存路由键应按官方建议设置稳定键并控制高频键的负载分布。8. 权限隔离比命中率重要即使缓存只保存中间状态不直接返回明文也不能把它视为无敏感性。缓存存在可能通过延迟形成侧信道条目还代表某段输入已被发送并保留在服务端。租户、项目、数据区域或密级不同就不应该为了提高命中率共享私密前缀。第一原则是只把真正公共的内容放入跨租户稳定前缀。产品说明、公开政策和同版本工具 Schema可以共享客户合同、内部工单、检索片段和个人信息放在租户边界之后。若一份资料对 A 和 B 都可见但权限未来可能分离仍应按权限组版本化不要假设“今天相同”意味着永远可以共享。第二原则是缓存路由键包含信任边界。使用供应商提供的prompt_cache_key、cache_salt或等价机制时值应来自不可伪造的服务端租户或权限组 ID不能直接相信客户端提交的字符串。相同租户的多个用户可在政策允许时共享不同租户默认隔离。第三原则是先鉴权再构建 Prompt。应用必须确认用户有权读取文档才把文档加入任何可缓存段。Prompt Cache 不是访问控制系统命中也不能绕过每次请求的权限检查。权限撤销时停止构建包含该文档的前缀并按敏感程度执行紧急失效流程。第四原则是限制观测标签。监控可以记录 HMAC 后的租户 ID、前缀版本和命中 Token不能把客户名称、文档标题、原始缓存键放到公开指标。Prometheus 标签具有高基数与广泛可见性完整指纹放审计存储指标只保留受控维度。9. RAG 场景为什么经常命不中RAG 每次检索出的文档块、顺序和分数都可能变化。如果把它们放在系统规则之前整个请求前缀随问题改变即使放在后面若期待缓存 RAG 内容也要保证相同文档以相同顺序和格式出现。检索分数的小数位、当前时间、动态片段 ID 都会改变 Token。更合理的拆法是稳定的回答规则、引用格式和工具 Schema在前租户公共且版本稳定的知识说明可按权限组缓存本次 Top-k 结果与问题放后。不要为了命中把整个知识库塞进 Prompt成本、上下文和权限都会恶化RAG 的价值正是只取相关证据。检索结果可做确定性序列化按业务认可的相关性与稳定 ID 排序分数不需要模型时不写入统一标题、页码和分隔符正文清洗版本固定。注意排序规则改变属于 Prompt 版本变化应在灰度中观察引用正确率而不只是缓存命中率。同一对话的历史消息会自然形成增长前缀。某些平台能复用前一轮历史但截断策略若从开头删除消息会让前缀整体变化。长对话应采用稳定摘要或分段策略并把摘要版本纳入指纹。为了缓存而永远保留全部历史会最终触碰上下文上限。10. 失败模式与排查顺序问题一cached_tokens总为零。先确认模型支持缓存、输入达到目标模型的最小资格、稳定内容确实在开头再比较最终发送的原始 JSON而不是比较业务对象。检查时间戳、工具顺序、空格、系统模板和模型是否变化最后检查两次请求间隔是否超过 TTL 或被路由到无法复用的缓存位置。问题二命中率高但费用没下降。查看命中 Token 在总输入中的占比、缓存读取价格、首次写入价格和输出 Token 成本。长输出应用的主要费用可能在 DecodePrompt Cache 只能优化输入。还要确认报表是否把缓存读取 Token 又计入普通输入造成重复计算。问题三费用下降但 TTFT 没改善。网络、排队和 Decode 可能占主要时间或者命中前缀相对总 Prefill 太短。结合供应商请求时间线、输入长度与并发分析不要保证缓存一定改善端到端延迟。问题四新版本发布后命中率断崖式下降。这在版本切换初期可能完全正常因为新前缀需要冷写。按版本拆指标观察后续是否恢复若长期不恢复检查发布过程是否为每个副本生成了不同时间戳、构建 ID 或工具顺序。问题五少数租户命中异常高。确认缓存键是否错误地省略租户边界或所有租户被写成默认值。用两个合成租户做隔离实验若 B 的首次请求直接读取 A 的私密前缀立即停止流量并按安全事件处理而不是把它当成优化成果。问题六显式断点返回400。核对当前模型支持、断点数量、TTL 组合和 content block 位置。不同云平台对同一模型的 API 包装可能不同不能直接复制另一平台示例。保留响应请求 ID并查官方文档不记录完整敏感请求。问题七同一文本指纹相同供应商仍不命中。我们的字符级规范指纹只能证明应用认为稳定实际 tokenizer、聊天模板、工具和隐藏控制 Token 仍可能不同。用目标 SDK 的最终请求快照和 tokenizer 检查且确认模型、区域、组织和缓存路由键一致。11. 监控要从“开没开”升级到“省了多少”核心计数包括普通输入 Token、缓存写入 Token、缓存读取 Token、输出 Token、请求数和费用。核心分组包括供应商、模型、业务 Prompt 版本、TTL、信任组和区域。核心体验指标包括 TTFT、端到端延迟、失败率与冷启动比例。派生指标至少有四个Token 命中率、写入放大率、每千次请求节省金额、冷写后平均复用次数。写入放大率高说明大量前缀写入后没有再读可能是 TTL 太短、版本过碎或缓存根本不适合该场景。命中率升高但业务质量下降则说明为了稳定前缀牺牲了必要的动态上下文必须回滚。账单对账不能完全依赖客户端估算。供应商 usage 是请求级事实供应商账单是财务事实两者按请求 ID或时间窗口对齐。出现缺失 usage 时单独计数不要默认为零成本。价格配置要有生效日期历史费用按当时价格重算不能用今天的价目表解释上月账单。告警应关注变化某版本发布后缓存读取比例持续低于基线某租户写入 Token 激增扩展 TTL 的条目没有获得足够复用缓存费用降低但 TTFT P95 恶化。每个告警附带 Prompt 版本与发布记录值班人员才能定位。12. 安全、合规与数据保留边界把 Prompt 发送给供应商之前先确认合同、地域与数据分类允许。缓存会让服务端在一段时间内保留由 Prompt 计算出的状态可能影响 Zero Data Retention 资格。组织级数据政策与所选 TTL 决定能否使用扩展缓存不能由开发者为了命中率私自覆盖。API Key 放在服务端密钥管理系统浏览器和移动端不直接调用供应商。缓存相关键不应包含明文邮箱、手机号或合同号使用服务端生成的不可逆标识。日志不记录完整 system、工具参数与文档正文调试环境用合成数据。Prompt Injection 不会因为使用缓存而消失。若恶意指令进入稳定公共前缀它可能在有效期内影响更多请求。进入缓存前仍要确认内容来源和权限外部文档作为“不可信数据”与系统指令分隔更新公共知识后跑安全回归。缓存命中不能跳过内容审核、工具授权或输出校验。它只跳过部分模型计算不代表请求已经安全验证。每次工具执行都重新验证用户权限与参数任何写操作带幂等键和人工确认边界。需要删除数据时区分应用数据库、日志、供应商请求记录和 Prompt Cache。删除应用里的文本不一定立即删除供应商缓存根据官方能力和合同执行并记录完成证据。无法逐条删除的短期缓存应停止引用并等待明确最长保留期同时评估事件影响。13. 发布、灰度与回滚每次 Prompt 变更都生成新版本和前缀摘要先跑静态检查无动态占位符、无未授权文档、工具顺序确定、目标模型满足缓存资格。再用合成请求跑冷写与热读确认 usage 符合预期。缓存没命中不一定阻止发布但必须知道原因和成本影响。灰度阶段同时观察质量与成本。把少量租户切到新版本比较任务成功率、拒答率、结构化输出通过率、TTFT 和缓存费用。只有缓存更省但质量不变或更好才扩大流量。不要仅凭 cached token 上升发布。回滚通过路由恢复旧的不可变版本。旧版本若仍在 TTL 内可能立即命中这是好事如果已过期会发生一次冷写。发布系统应能接受这次短暂成本而不是为了避免冷写继续使用有问题的新 Prompt。多区域发布要分别预热和观察因为缓存可能不跨区域共享。先确认区域数据政策再让真实流量自然升温。不要从一个区域导出 KV 状态到另一区域除非供应商明确支持且合规评审通过。14. 什么时候不要使用 Prompt Cache稳定前缀很短、请求复用间隔远大于 TTL、每次工具或 Schema 都不同、动态 RAG 占绝大多数输入时缓存收益通常有限。此时保持请求清晰比强行制造稳定段更重要。先缩短冗余 Prompt、精简重复工具描述或改善检索比引入缓存更直接。强隔离业务如果无法获得可靠的租户缓存分区也不应跨租户复用。含有高敏感信息且组织政策不允许任何扩展保留时选择不缓存或只缓存公开规则。安全边界不能用折扣交换。离线批处理若平台提供 Batch API 或专门折扣应把它与 Prompt Cache 组合成本一起比较不要默认实时缓存最便宜。自托管模型还要计算 GPU 显存被 KV Cache 占用的机会成本命中带来的 Prefill 节省可能换来更少的并发容量。最终Prompt Cache 是一种工作负载优化不是业务功能。它适合“长、稳定、短时间重复”的前缀通过真实 usage 证明收益通过不可变版本管理失效通过租户或权限组控制共享通过质量回归防止为了命中牺牲正确性。能回答“省了多少、为什么命中、何时失效、谁可以复用”才算把缓存真正用起来。上线后的复盘还要保留一组完全关闭缓存的对照请求。它能帮助团队区分模型本身变慢、网络抖动与缓存策略退化避免把所有延迟变化都归因于命中率。对照流量不必很大但必须使用相同模型、相同输出上限和同一批脱敏问题并记录实际输入、缓存命中量、首字延迟与最终质量结果。只有成本、延迟和质量三项能在同一口径下比较缓存优化才具备可验证、可回滚的工程价值。参考资料OpenAI Prompt CachingOpenAI Data ControlsAnthropic Prompt CachingvLLM Automatic Prefix Caching 设计Python hashlib 文档