098、Prompt Caching 优化实战：在 API 调用中利用缓存降低延迟和成本的方案

098、Prompt Caching 优化实战：在 API 调用中利用缓存降低延迟和成本的方案

一次让我肉疼的账单

上个月接手一个内部代码审查助手项目，团队用 Claude API 做批量代码分析。上线第三天，运维同学甩过来一张账单——日均 API 调用费用突破 200 美元，P95 延迟飙到 8 秒。我第一反应是“谁把循环写成了死循环”，查完日志发现真相更扎心：同一个代码仓库的 200 个文件，每次请求都带着完整的项目上下文（README、架构文档、编码规范），这些内容占了 token 消耗的 70%，而且每次都在重复传输。

更离谱的是，Claude 在处理这些重复上下文时，每次都要重新计算 attention，延迟和成本就这么白白烧掉了。当时我盯着监控面板，脑子里只有一个念头：必须把缓存搞上去。

缓存不是简单的“存起来”

很多人以为 Prompt Caching 就是把请求结果存 Redis，下次命中直接返回。这个思路在简单问答场景没问题，但在工程化场景里，Claude 的缓存机制远比这复杂。

Claude 的 Prompt Caching 核心原理是服务端缓存——当你发送的 prompt 前缀与之前某次请求的前缀完全一致时，API 服务端会复用之前计算好的 KV Cache（Key-Value Cache），跳过这部分 token 的 attention 计算。这意味着：