1. 先搞清楚Claude API的计费逻辑再谈缓存命中很多人一上来就问“怎么提高缓存命中率”但连Claude API到底怎么计费的都没弄明白。我见过太多团队账单翻了三倍还在那儿调prompt方向完全错了。先把计费模型吃透后面所有优化动作才有依据。1.1 三种token的定价差异Claude API的计费把输入token分成了几类价格差距非常大。以Anthropic官方定价为参考具体数字会随版本调整但比例关系基本稳定Token类型相对价格说明普通输入token基准价每次请求都全额计费缓存写入token约1.25倍基准价第一次建立缓存时收取缓存读取token约0.1倍基准价命中缓存后读取便宜一个数量级输出token约数倍基准价模型生成的内容这张表是整篇内容的地基。你可以看到缓存读取的价格只有普通输入的十分之一左右。这意味着什么如果你的系统提示词有5000个token每次请求都全额计费和命中缓存后计费成本差距是10倍。一天跑一万次请求这个差距就是真金白银。但这里有个反直觉的点缓存写入比普通输入还贵25%。所以缓存不是无脑开就省钱只有当同一段内容被重复使用至少2次以上缓存才真正划算。单次请求加缓存你反而多付了25%。1.2 缓存的最小粒度与生命周期Claude的prompt caching是按“前缀”匹配的不是按整段内容匹配。它有一个最小缓存长度门槛不同模型版本不一样通常在1024到2048 token之间低于这个长度根本不给你缓存。生命周期方面缓存默认有5分钟的存活时间每次命中会刷新这个计时。也就是说如果你的请求间隔超过5分钟缓存就失效了下次又得重新写入。这个特性决定了你的优化策略必须考虑请求的时间分布而不是只看总量。我踩过的一个坑有个批处理任务每小时跑一次每次处理一批数据。我兴冲冲地加了缓存结果发现根本没命中——因为间隔一小时缓存早过期了。后来改成把批处理拆成5分钟内能跑完的小批次命中率才上来。1.3 为什么“重复计费”才是真正的成本杀手大部分团队的成本问题不是单价高而是同一段内容被反复全额计费。典型场景系统提示词system prompt每次请求都带着几千token少样本示例few-shot examples固定不变每次重复发送长文档问答场景同一篇文档被问了几十个问题多轮对话里历史消息不断累积重复发送这些内容的共同点是内容不变但每次都在付费。缓存机制就是专门解决这个问题的。理解这一点你就知道优化的靶心在哪里了。2. 四步优化法从结构设计到命中率验证下面这四步是我在实际项目里反复验证过的流程。顺序不能乱因为每一步都依赖前一步的产出。2.1 第一步把prompt拆成“静态前缀”和“动态后缀”这是整个优化的核心动作。Claude的缓存是按前缀匹配的所以你必须保证每次请求的开头部分完全一致变化的内容全部放到后面。具体怎么做把prompt结构重新组织[静态部分 - 放最前面] - 系统角色定义 - 行为规范 - 少样本示例 - 固定知识库内容 [动态部分 - 放最后面] - 用户当前问题 - 本次请求特有的上下文 - 需要模型处理的变量数据我见过最常见的错误是把用户问题放在最前面或者把动态内容穿插在静态内容中间。这样每次请求的前缀都不一样缓存永远命中不了。举个实际例子。假设你在做一个客服助手错误写法用户问{question} 你是XX公司的客服需要遵守以下规范{rules} 参考知识{knowledge}正确写法你是XX公司的客服需要遵守以下规范{rules} 参考知识{knowledge} 用户问{question}看起来只是顺序调了一下但前者缓存命中率是0后者能到80%以上。因为前者的第一个token就是变量后者前面几千token都是固定的。注意静态部分必须超过模型的最小缓存长度门槛否则缓存机制根本不启动。如果你的系统提示词只有几百token要么补充内容到门槛以上要么考虑把多个固定片段合并。2.2 第二步用cache_control标记精确控制缓存断点光有静态前缀还不够你得显式告诉API“从这里开始缓存”。Claude API通过cache_control参数来标记缓存断点。在请求体里你需要在content数组的某个位置加上标记{ model: claude-sonnet-4-20250514, system: [ { type: text, text: 你的系统提示词内容..., cache_control: {type: ephemeral} } ], messages: [ { role: user, content: [ { type: text, text: 固定的参考文档内容..., cache_control: {type: ephemeral} }, { type: text, text: 用户的实际问题... } ] } ] }关键点在于cache_control标记的位置。它标记的是“缓存到这里为止”也就是这个标记之前的所有内容都会被缓存。你可以设置多个断点但一般2到4个就够了太多反而增加管理复杂度。我通常的断点策略是第一个断点系统提示词结束处第二个断点少样本示例结束处第三个断点固定知识库结束处这样即使某一部分内容有微调也不会影响前面部分的缓存命中。2.3 第三步控制请求节奏别让缓存“凉了”前面说过缓存默认5分钟过期。如果你的请求间隔太长缓存就白建了。这一步要解决的就是让请求在缓存有效期内复用。几个实操策略策略一合并短时间内的请求。如果业务允许把几秒内到达的多个请求攒一攒一起发。这样它们共享同一份缓存。策略二预热缓存。对于可预测的请求高峰提前发一个请求把缓存建好。比如每天早上9点开始有大量请求你8点55分发一个预热请求缓存就能覆盖9点后的第一批流量。策略三调整批处理窗口。前面提到的批处理场景把窗口从1小时改成4分钟确保每批都在缓存有效期内。策略四长对话场景保持活跃。多轮对话如果用户思考时间较长可以在中间插入轻量的心跳请求维持缓存。不过这个要权衡心跳本身也有成本。实测下来光是调整请求节奏这一项在批处理场景就能把命中率从接近0拉到70%以上。2.4 第四步监控命中率并持续调优优化不是一次性的你得有数据反馈。Claude API的响应里会返回缓存相关的用量信息{ usage: { input_tokens: 150, cache_creation_input_tokens: 0, cache_read_input_tokens: 4800, output_tokens: 320 } }cache_read_input_tokens就是命中缓存的token数cache_creation_input_tokens是新建缓存的token数。命中率可以这样算命中率 cache_read_input_tokens / (input_tokens cache_creation_input_tokens cache_read_input_tokens)我建议把这个指标接入监控面板按小时、按接口维度看趋势。一旦命中率掉下来立刻排查是不是prompt结构被改了或者请求节奏变了。有个细节cache_creation_input_tokens在缓存刚建立时会有值后续命中时这个值变成0cache_read_input_tokens变大。如果你看到每次请求都有大量creation说明缓存一直没命中得回去检查前缀一致性。3. 那些让缓存失效的隐蔽陷阱上面四步是正向优化但实际项目里缓存失效往往是因为一些不起眼的细节。这一章专门讲我踩过的坑。3.1 时间戳和随机ID是缓存杀手最隐蔽的坑prompt里混入了动态生成的内容。比如系统提示词里带了当前时间戳请求ID、会话ID被拼进了前缀用户信息名字、等级放在了静态部分这些东西每次都不一样导致前缀永远在变缓存永远命中不了。而且它们往往藏在很不起眼的地方排查起来很费劲。我的排查方法把两次请求的完整prompt打印出来逐字符diff。任何差异都会导致缓存失效。如果差异出现在你以为是静态的部分那就是问题所在。3.2 JSON序列化的顺序问题如果你把结构化数据序列化成JSON放进prompt要注意键的顺序。Python的json.dumps默认不保证顺序同样的数据可能生成不同的字符串。这会导致前缀不一致。解决方案用sort_keysTrue固定键顺序或者用separators参数去掉多余空格。import json # 不稳定键顺序可能变化 json.dumps(data) # 稳定键按字母排序 json.dumps(data, sort_keysTrue, separators(,, :))这个坑我在一个多语言项目里踩过同样的配置数据中文环境下键顺序和英文环境不一样导致两个环境的缓存互相干扰。3.3 模型版本切换导致缓存全失效缓存是和模型绑定的。你把模型从claude-sonnet-4切到claude-opus-4之前的缓存全部作废得重新建立。所以做A/B测试或者灰度发布时要注意缓存成本。两个模型并行跑等于两份缓存成本会上升。建议在测试阶段接受这个成本测试完尽快收敛到单一模型。3.4 多租户场景的缓存隔离如果你的系统服务多个客户每个客户有独立的系统提示词那缓存是按客户隔离的。客户A的缓存客户B用不了。这种情况下命中率的分母是“单个客户的请求量”。如果某个客户请求量很小缓存可能一直建不起来就过期了。这时候要考虑小客户是不是干脆不用缓存或者把多个小客户的公共部分抽出来共享缓存。我做过一个SaaS项目把系统提示词拆成“平台通用部分”和“客户定制部分”通用部分所有客户共享缓存定制部分各自缓存。这样整体命中率提升了一大截。4. 不同业务场景下的缓存策略差异缓存优化没有万能公式不同场景的策略差别很大。这一章按场景拆解。4.1 长文档问答一次缓存多次复用这是缓存收益最大的场景。一篇几万token的文档用户可能问几十个问题。把文档放在静态前缀里缓存一次后续所有问题都命中缓存。关键操作文档内容放在messages的最前面加cache_control标记用户问题放在文档后面确保文档内容在5分钟内被多次提问如果用户提问间隔较长可以考虑在文档缓存快过期时主动发一个轻量请求刷新。不过要算清楚刷新请求的成本 vs 重新建立缓存的成本哪个更划算。4.2 多轮对话历史消息的缓存管理多轮对话的缓存比较微妙。每轮对话历史都在增长前缀在变化。如果每轮都重新缓存成本反而高。我的做法是只缓存系统提示词和固定的少样本示例对话历史不缓存。因为对话历史每轮都变缓存它没有意义。系统提示词那部分固定不变缓存收益稳定。如果对话轮次很多历史消息很长可以考虑对历史消息做摘要压缩减少重复发送的量。但这属于另一个优化维度了。4.3 批处理任务时间窗口是关键批处理场景的缓存优化核心是把任务按时间窗口分组。同一窗口内的任务共享缓存。具体做法把大批次拆成5分钟内能跑完的小批次每个小批次的第一条请求建立缓存后续请求命中监控每批的命中率如果低于阈值说明批次太大或太小我做过一个数据标注任务原来是一天跑一次全量改成每4分钟跑一批后缓存命中率从0提升到85%整体成本降了六成多。4.4 高并发实时场景预热与保活实时场景请求量大但分散缓存容易在低峰期过期。策略是高峰期前预热缓存低峰期用低频心跳保活监控命中率曲线在掉点时自动触发预热这个策略需要一些工程投入但对于请求量大的系统收益很明显。5. 实测数据与成本核算说了这么多方法到底能省多少我拿一个真实项目的数据来说明。5.1 优化前后的对比项目背景一个文档分析助手系统提示词约3000 token参考知识库约5000 token平均每天处理8000次请求。指标优化前优化后缓存命中率0%82%平均每次请求输入token82008200其中缓存读取token06724其中全额计费token82001476相对成本100%约22%成本降到原来的两成左右。这个降幅主要来自那8000 token的固定内容从全额计费变成了十分之一价格的缓存读取。5.2 缓存写入成本的摊销别忘了缓存写入有25%的溢价。在上面这个例子里每天第一次请求要付写入成本但后续几千次请求都是读取。写入成本被摊薄到可以忽略。但如果你的请求量很小比如一天只有几十次那写入溢价可能抵消不了收益。这种情况下要算一笔账缓存收益 命中次数 × 缓存内容token数 × (基准价 - 缓存读取价) 缓存成本 写入次数 × 缓存内容token数 × (缓存写入价 - 基准价)只有收益大于成本缓存才划算。粗略估算同一段内容被复用3次以上缓存就开始赚钱。5.3 命中率的天花板在哪里理论上命中率可以到100%但实际项目里总有一些请求是“冷启动”的——第一次请求、缓存过期后的请求、内容有变化的请求。这些拉低了整体命中率。我的经验是稳定运行的场景命中率做到80%到90%是合理目标。追求100%往往意味着过度工程投入产出比不划算。如果命中率低于60%说明优化还有明显空间。6. 把缓存优化纳入日常工程流程缓存优化不是做完就完了它需要持续维护。这一章讲怎么把它变成团队的习惯。6.1 在代码层面固化prompt结构别让开发者随手改prompt结构。我建议把prompt模板做成配置静态部分和动态部分在代码里明确分离class PromptBuilder: def __init__(self, system_prompt, examples, knowledge): # 静态部分构建一次多次复用 self.static_prefix self._build_static( system_prompt, examples, knowledge ) def build(self, user_question): # 动态部分拼在后面 return [ {type: text, text: self.static_prefix, cache_control: {type: ephemeral}}, {type: text, text: user_question} ]这样结构上就保证了静态部分在前、动态部分在后不会因为开发者疏忽而破坏缓存。6.2 把命中率纳入监控告警在监控系统里加一条规则缓存命中率低于阈值比如60%持续10分钟触发告警。这样一旦有人改了prompt导致缓存失效能第一时间发现。告警信息里带上最近一次prompt的hash值方便快速定位是哪次改动导致的。6.3 上线前的缓存检查清单每次prompt有改动上线前过一遍这个清单[ ] 静态内容是否还在最前面[ ] 是否混入了时间戳、随机ID等动态内容[ ] JSON序列化是否稳定键顺序固定[ ]cache_control标记位置是否正确[ ] 静态部分长度是否超过最小缓存门槛[ ] 请求间隔是否在缓存有效期内这个清单看起来简单但能挡住大部分低级错误。我们团队用了之后因为prompt改动导致的缓存失效事故基本没有了。6.4 定期review缓存成本占比每个月review一次账单看缓存相关的成本占比。如果缓存读取成本占比很低说明命中率不够还有优化空间。如果缓存写入成本占比异常高说明缓存频繁失效重建要查原因。我一般会看三个数缓存读取token占比、缓存写入token占比、全额计费token占比。健康的状态是读取占大头写入和全额计费都占小头。这套流程跑顺之后缓存优化就从“一次性项目”变成了“日常运维”成本控制也变得可预期。