Prompt 缓存实战：计费模型、断点机制与 cache_control 命中率优化

1. 从一个被忽视的账单说起Prompt 缓存到底在解决什么问题如果你最近半年在调用大模型 API 做产品大概率经历过这样的场景一个多轮对话的 Agent每轮都要把系统提示词、工具定义、历史对话重新塞进请求里。用户聊到第十轮输入 token 已经堆到两三万账单跟着水涨船高延迟也肉眼可见地变长。更让人头疼的是这些内容里有大量重复——系统提示词一个字没变工具定义一个字没变变的只是最后那句用户提问。Prompt 缓存Prompt Caching就是冲着这个痛点来的。它的核心逻辑非常朴素如果请求的前缀部分和上一次完全一致服务端就直接复用上次已经算好的中间状态不再重复计算同时按更低的费率计费。这件事在工程上的价值等同于给一个反复读取同一张大表的查询加了物化视图。但真正落地的时候问题就来了。缓存不是开了就省钱这么简单它牵扯到三个必须搞清楚的机制计费怎么算、断点在哪里、cache_control 怎么标。我见过太多团队兴冲冲开了缓存结果账单没降反升或者命中率低得可怜根本原因就是没吃透这三件事之间的关系。这篇文章适合三类人看一是正在做 LLM 应用、被 token 成本压得喘不过气的后端和算法工程师二是负责成本优化、需要给老板解释为什么这个月账单降了 40%的技术负责人三是刚接触 prompt engineering、想搞清楚缓存这块到底怎么玩的新手。我会把计费模型、断点机制、cache_control 的标注方法、命中率排查这几块掰开揉碎讲清楚尽量做到你看完就能上手改自己的代码。先给一个最直观的结论Prompt 缓存省钱的本质是用写入缓存的溢价换后续读取的折扣只有当同一段前缀被复用的次数超过盈亏平衡点你才是真的赚了。这个平衡点具体是多少后面会算给你看。2. 计费模型拆解缓存写入、缓存读取、普通输入的三档价差要理解 Prompt 缓存的计费先得接受一个反直觉的事实缓存不是免费的写入缓存本身要加钱。这跟很多人想象的缓存 省钱完全不一样。服务商的逻辑是我帮你把这段内容的中间状态存下来了占了我的存储和内存资源所以写入时收你一点溢价但你后续读取时我不用重新算所以给你一个大折扣。这是一个典型的先投入后收益模型。2.1 三档计费口径的对比以目前主流服务商的公开口径为例具体数字各家不同但比例关系大同小异输入 token 通常被分成三档计费类型相对基准价触发条件典型倍率普通输入cache miss1.0x前缀未命中缓存基准缓存写入cache write1.25x首次写入或缓存过期后重建溢价约 25%缓存读取cache read0.1x前缀命中已有缓存折扣约 90%这张表是理解一切的钥匙。注意几个关键点第一缓存写入的溢价通常只在建立缓存那一次发生。也就是说你第一次发请求那段前缀被写入缓存这次按 1.25 倍计费第二次发同样的前缀命中缓存按 0.1 倍计费。如果你只发一次那你就白付了 25% 的溢价一点没省。第二缓存读取的折扣力度非常大通常是 90% 左右。这意味着只要命中一次就能把写入的溢价赚回来还有富余。算一笔账写入溢价 0.25读取省下 0.9那么命中一次就净赚 0.65。命中两次净赚 1.55。所以命中率是王道。第三缓存有存活时间TTL。主流实现里缓存通常存活 5 分钟左右每次命中会刷新这个计时。如果你的请求间隔超过 TTL缓存就失效了下次又得重新写入。这一点对低频调用的场景非常致命——你以为开了缓存实际上每次都在重建。2.2 盈亏平衡点怎么算我把公式写出来你可以直接套设普通输入单价为 P缓存写入溢价为 0.25P缓存读取节省为 0.9P 设一段前缀被复用 N 次含首次写入 总成本 1.25P首次写入 (N-1) × 0.1P后续读取 不开缓存成本 N × P 盈亏平衡1.25 0.1(N-1) N 解得N 1.167也就是说同一段前缀只要被复用超过 1.17 次也就是复用 2 次以上缓存就开始省钱。这个门槛低得惊人几乎任何多轮对话场景都能轻松跨过。但前提是——你得真的命中而不是每次都 miss。注意这里的倍率是行业常见口径的近似值不同服务商、不同模型的具体数字会有差异务必以你实际使用的服务商文档为准。但比例关系写入溢价小、读取折扣大是普遍规律。2.3 为什么写入要收溢价很多人不理解为什么写入要加钱。从服务商角度想就通了缓存写入意味着要把这段内容的 KV 状态注意力机制里的 key-value 张量持久化到高速存储里还要维护索引、处理过期、保证一致性。这些都是有成本的。而读取时这些状态已经现成直接拿来用计算量几乎为零所以能给出极低的折扣。从你的角度这个溢价其实是一种押金——你赌这段前缀会被复用赌赢了就大赚赌输了就多付 25%。所以判断一段内容值不值得缓存本质上是在判断它的复用概率。3. 断点机制缓存到底在哪里断开理解了计费接下来是最容易踩坑的部分断点。Prompt 缓存不是把整个请求都缓存起来而是按前缀匹配从开头一直匹配到某个断点为止。断点之后的内容哪怕只差一个字也会导致整段缓存失效。3.1 前缀匹配的严格性缓存匹配是逐 token 严格比对的。这意味着系统提示词里多一个空格、少一个换行缓存直接 miss工具定义的顺序换了一下缓存直接 miss时间戳、随机 ID、用户昵称这类动态内容如果放在前缀里缓存永远命中不了我见过最典型的翻车案例有人在系统提示词里塞了当前时间2024-xx-xx xx:xx:xx结果每次请求时间都不一样缓存命中率 0%。这种错误看起来低级但在实际项目里非常常见因为大家习惯性地把上下文信息都堆在开头。3.2 断点标记 cache_control 的作用断点是通过cache_control这个字段来标记的。它的语义是从这里往前的所有内容请缓存起来。也就是说你在请求体里某个内容块的末尾打一个cache_control: {type: ephemeral}服务端就会把从请求开头到这个块结尾的所有内容作为一个缓存单元。一个典型的结构长这样{ system: [ { type: text, text: 你是一个专业的客服助手负责处理订单查询...此处省略 2000 字系统提示词, cache_control: {type: ephemeral} } ], tools: [ { name: query_order, description: 根据订单号查询订单状态..., input_schema: {...} } ], messages: [ {role: user, content: 帮我查一下订单 12345} ] }这里cache_control打在系统提示词块的末尾意味着系统提示词这段会被缓存。下次请求如果系统提示词一字不差就能命中。3.3 多个断点与缓存层级高级用法是打多个断点形成缓存层级。比如断点 1系统提示词最稳定几乎不变断点 2工具定义 系统提示词较稳定断点 3历史对话 工具定义 系统提示词随对话增长这样设计的好处是即使历史对话变了系统提示词和工具定义那两层缓存依然能命中。服务端会从最长的匹配前缀开始复用逐层回退。但要注意断点数量通常有上限常见是 4 个而且每多一个断点就多一次写入成本。所以不是越多越好要按稳定性分层来设计越靠前的内容越稳定越靠后的越易变。3.4 断点位置的实操判断怎么决定断点打在哪我的经验是问自己三个问题这段内容在多次请求间是否逐字节一致这段内容的体量是否足够大通常建议至少几百 token太小不值得这段内容的复用频率是否够高间隔是否在 TTL 内三个都 yes就打断点。有一个 no就别浪费写入溢价。4. cache_control 实战从零改造一个多轮对话应用光讲原理不够我拿一个真实的多轮客服 Agent 场景把改造过程完整走一遍。假设你原来有一个请求长这样import time def build_request(user_input, history): system_prompt 你是一个电商客服助手。 当前时间{now} 用户等级{level} ...此处省略 1500 字规则说明 .format(nowtime.strftime(%Y-%m-%d %H:%M:%S), level黄金会员) messages [{role: system, content: system_prompt}] messages.extend(history) messages.append({role: user, content: user_input}) return messages这段代码有两个致命问题系统提示词里塞了动态时间导致每次都不一样没有打 cache_control服务端根本不知道要缓存。4.1 第一步剥离动态内容把动态内容从系统提示词里挪出来放到消息末尾或者用户消息里def build_request(user_input, history, user_level): # 静态部分完全不变适合缓存 static_system 你是一个电商客服助手。 ...此处省略 1500 字规则说明不含任何动态内容 # 动态部分单独放在后面 dynamic_context f当前用户等级{user_level}当前时间{time.strftime(%Y-%m-%d %H:%M:%S)} messages [ {role: system, content: static_system}, *history, {role: user, content: f{dynamic_context}\n\n用户问题{user_input}} ] return messages这一步做完系统提示词就变成了逐字节一致的静态内容具备了缓存的前提。4.2 第二步打上 cache_control 断点以支持 cache_control 的 API 格式为例把系统提示词块标记为可缓存def build_request_with_cache(user_input, history, user_level): static_system 你是一个电商客服助手。 ...1500 字规则说明 dynamic_context f当前用户等级{user_level}当前时间{time.strftime(%Y-%m-%d %H:%M:%S)} request { system: [ { type: text, text: static_system, cache_control: {type: ephemeral} } ], messages: [ *history, {role: user, content: f{dynamic_context}\n\n用户问题{user_input}} ] } return request4.3 第三步给历史对话也加断点多轮对话里历史对话是逐轮增长的。如果只缓存系统提示词那历史对话部分每次都要重新算。更好的做法是在历史对话的最后一个消息上也打一个断点def build_request_full(user_input, history, user_level): static_system ...1500 字 dynamic_context f当前用户等级{user_level} messages list(history) if messages: # 在历史对话的最后一个消息上打断点 messages[-1] { **messages[-1], cache_control: {type: ephemeral} } messages.append({role: user, content: f{dynamic_context}\n\n用户问题{user_input}}) return { system: [{type: text, text: static_system, cache_control: {type: ephemeral}}], messages: messages }这样设计后缓存形成两层系统提示词一层系统提示词 历史对话一层。当用户继续对话时历史对话那层会增长但系统提示词那层始终命中。4.4 第四步验证命中情况改造完必须验证。大多数服务商的响应里会返回缓存相关的用量字段类似{ usage: { input_tokens: 150, cache_creation_input_tokens: 0, cache_read_input_tokens: 1800, output_tokens: 220 } }cache_read_input_tokens大于 0说明命中了cache_creation_input_tokens大于 0说明这次在写入。连续两次相同前缀的请求第二次应该看到cache_read有值、cache_creation为 0。如果第二次还是cache_creation有值说明前缀没匹配上回去检查是不是有隐藏的动态内容。实操心得我习惯在开发环境加一个断言如果连续两次请求的cache_read_input_tokens都是 0就直接抛异常。这样能在 CI 阶段就发现缓存失效问题而不是等到月底看账单才发现。5. 命中率排查为什么你的缓存总是不生效缓存改造做完最常遇到的问题就是明明打了断点命中率还是上不去。我把踩过的坑整理成一张速查表基本覆盖 90% 的场景。5.1 常见失效原因速查表现象可能原因排查方法解决方式命中率 0%前缀含动态内容时间、ID、随机数打印两次请求的完整前缀做 diff剥离动态内容到断点之后命中率忽高忽低请求间隔超过 TTL记录请求时间戳看间隔缩短调用间隔或接受重建成本首次命中后失效前缀里有浮点数精度问题对比序列化后的字符串统一数字格式避免精度漂移部分命中断点位置不合理看 cache_read 的 token 数调整断点按稳定性分层完全没命中cache_control 字段格式错误检查 API 版本和字段名对照官方文档核对字段命中但没省钱复用次数太少统计每段前缀的复用次数复用 2 次的内容不要缓存5.2 动态内容的隐蔽来源动态内容不只有时间戳。我遇到过几个特别隐蔽的JSON 序列化顺序不稳定。Python 的 dict 在 3.7 之后保序但如果你从数据库查出来的字段顺序不固定序列化后的字符串就不一样。解决办法是显式排序 key。浮点数精度。比如工具定义里有个默认值0.1 0.2不同环境算出来可能是0.30000000000000004或0.3。这种差异肉眼看不出来但缓存比对是逐字节的直接 miss。换行符差异。Windows 的\r\n和 Linux 的\n混用在跨平台部署时特别容易出问题。统一用\n。工具定义的顺序。如果你用 set 或者无序结构存工具每次序列化顺序可能不同。改成有序列表。5.3 用 diff 定位问题最有效的排查手段就是把两次请求的完整前缀打印出来做 diff。我一般这么干import difflib import json def diff_prefix(req1, req2): s1 json.dumps(req1, sort_keysTrue, ensure_asciiFalse) s2 json.dumps(req2, sort_keysTrue, ensure_asciiFalse) if s1 s2: print(前缀完全一致缓存应该命中) return for line in difflib.unified_diff( s1.splitlines(), s2.splitlines(), lineterm ): print(line)跑一次就能看到到底哪个字符不一样。这个方法帮我定位过好几次看起来一样但就是不命中的诡异问题。5.4 TTL 与调用频率的匹配缓存 TTL 通常是 5 分钟每次命中会刷新。这意味着高频调用场景比如用户连续对话缓存几乎一直有效命中率极高低频调用场景比如每天跑一次的批处理缓存基本没用每次都在重建中等频率比如每隔几分钟一次要看具体间隔接近 TTL 时命中率会掉对于低频场景我的建议是要么不用缓存要么把多次调用合并成一次批处理让它们在同一个 TTL 窗口内完成。注意不要为了命中缓存而人为加快调用频率那可能触发服务商的速率限制得不偿失。缓存是优化手段不是目的。6. 成本核算与监控把缓存收益量化出来改造完、排查完最后一步是把收益量化。没有数据支撑的优化都是自嗨你需要一套能持续监控的指标。6.1 核心监控指标我一般盯这几个数缓存命中率cache_read_input_tokens / (cache_read cache_creation 普通 input)单请求平均成本 总成本 / 请求数缓存节省金额 假设不缓存的总成本 - 实际总成本写入/读取比cache_creation / cache_read这个比值越低越好命中率健康值我个人的经验线是60% 以上。低于这个数说明断点设计或者调用模式有问题值得回头排查。6.2 一个真实的成本对比拿一个日均 10 万次调用的客服 Agent 举例系统提示词 2000 token平均历史对话 3000 token用户输入 200 token。不开缓存每次输入约 5200 token按基准价算。开缓存后假设系统提示词层命中率 95%历史对话层命中率 70%项目不开缓存开缓存节省系统提示词成本2000 × 1.02000 × (0.05×1.25 0.95×0.1)约 88%历史对话成本3000 × 1.03000 × (0.3×1.25 0.7×0.1)约 55%用户输入成本200 × 1.0200 × 1.00%综合5200约 1750约 66%综合成本降了三分之二。这个数字在真实项目里是可信的前提是命中率达标。6.3 监控落地方式最简单的做法是在调用层包一个装饰器把每次响应的 usage 字段打到日志或者时序数据库里def log_cache_usage(response, request_id): usage response.get(usage, {}) metrics { request_id: request_id, input: usage.get(input_tokens, 0), cache_read: usage.get(cache_read_input_tokens, 0), cache_write: usage.get(cache_creation_input_tokens, 0), output: usage.get(output_tokens, 0), } # 打到你的监控系统 print(json.dumps(metrics))然后按天聚合画一条命中率曲线。曲线掉了就说明有问题及时排查。6.4 别忽略的隐性成本缓存优化不是只有省钱这一面。有几个隐性成本要算进去开发维护成本。为了命中缓存你得把动态内容剥离、统一序列化、维护断点逻辑这些都是代码复杂度。如果团队小、调用量不大可能不值得。调试难度。缓存命中与否会影响响应内容理论上不该影响但实践中偶有边界情况调试时多了一层变量。缓存失效的雪崩。如果大量请求共享同一段前缀缓存一失效所有请求同时重建可能造成瞬时压力。这个在超大规模场景才需要担心。我的建议是调用量日均低于 1 万次的场景先别急着上缓存把 prompt 本身精简一下可能收益更大。缓存是规模化的优化手段规模不够时性价比不高。7. 进阶玩法多断点分层与跨请求复用基础玩法掌握后可以看看进阶场景。这些是我在实际项目里验证过有效的。7.1 多租户场景的缓存隔离SaaS 产品里不同租户的系统提示词可能不同。这时候缓存要按租户隔离否则 A 租户的缓存被 B 租户命中就出大事了。做法是把租户 ID 作为前缀的一部分但要注意——租户 ID 放在最前面会导致每个租户独立缓存命中率按租户分摊。更好的做法是把公共部分所有租户共享的规则放在最前面缓存租户特有部分放在后面。这样公共层命中率极高租户层按各自频率命中。7.2 长文档问答的缓存策略RAG 场景里检索到的文档片段每次可能不同。如果直接把文档塞进 prompt缓存基本没用。我的做法是把文档内容放在断点之后只缓存系统提示词和固定的指令模板。文档部分虽然不缓存但系统提示词那部分能稳定命中整体还是省。如果文档本身是固定的比如产品手册问答那就把文档也纳入缓存在文档末尾打一个断点。7.3 批处理任务的缓存复用批量跑任务时如果每条任务共享同一段指令可以把它们放在同一个 TTL 窗口内连续发送。这样第一条写入缓存后面全部命中。我做过一个数据标注任务5000 条数据共享 3000 token 的标注规则命中率 99.8%成本降了 90% 以上。7.4 缓存与 prompt engineering 的配合缓存优化和 prompt engineering 是相辅相成的。一个结构清晰的 prompt天然就适合缓存静态规则在前动态上下文在后边界清晰。反过来如果你的 prompt 写得一团乱动态静态混在一起那缓存怎么调都调不好。所以我的建议是在做 prompt engineering 的时候就把缓存友好性考虑进去。把这段内容会不会变作为一个设计维度和这段内容该不该放同等重要。8. 我踩过的几个坑和最后的经验聊了这么多机制和方法最后分享几个我实际踩过的坑都是文档里不会写的。第一个坑以为缓存是自动的。早期我以为只要请求前缀一样服务端就会自动缓存。实际上不是你必须显式打cache_control否则服务端根本不知道你想缓存。这个认知差让我白白多付了一个月的钱。第二个坑断点打太靠后。我一开始把断点打在历史对话的末尾想着缓存越多越好。结果历史对话每轮都变导致整个缓存单元每轮都失效连系统提示词那部分都跟着重建。后来改成两层断点系统提示词单独一层问题才解决。断点要打在最稳定的边界上而不是最长的内容上。第三个坑忽略 TTL。有个内部工具是每天早上跑一次我给它加了缓存结果每次都是重建白付写入溢价。后来干脆去掉缓存改成把多次调用合并成一次批处理反而更省。第四个坑没监控。上线后没盯命中率过了两周才发现命中率只有 20%一直在做无效优化。没有监控的优化等于没优化这句话在缓存这件事上体现得淋漓尽致。如果让我给一个最实用的建议那就是先把监控搭起来再动手优化。你只有看到真实的命中率和成本数据才知道该往哪个方向使劲。盲目调断点、改 prompt很可能是在优化一个根本不存在的瓶颈。缓存这件事说到底是一个理解你的请求结构的过程。当你能清楚地回答我的请求里哪些部分是不变的、哪些是变的、变的频率有多高缓存优化就水到渠成了。技术手段都是次要的对业务请求模式的理解才是核心。