为什么这轮 Prompt Caching 值得关注
2024 年下半年，OpenAI、Anthropic 和 Google 相继推出服务端 Prompt Caching，将不再是一个“自己用 Redis 搞个 KV 缓存”的 DIY 玩法，而是变成了 API 原生的低成本特性。核心变化在于：缓存命中不再需要你手动管理过期和哈希，而是在 API 层自动完成，按缓存命中量单独计费（通常为完整 prompt 价格的 20%-50%）。对于高频调用同一段 system prompt 的 Agent loop 或 RAG 管道来说，延迟可以从 2-3 秒降到 200-400 毫秒，成本直接腰斩。
但这股热潮里最容易被忽略的一点是：缓存不是“免费午餐”。API 提供方对“哪些内容能缓存、缓存多久、何时失效”有严格约束。不了解这些边界，轻则缓存失效导致零加速，重则产生非预期的上下文泄漏。
它在真实工程流程里到底解决什么问题
想象一个典型的 Agent 工作流：
- 用户发消息“帮我查下上海明天的天气”。
- Agent 调用函数（get_weather）并附上当前系统 prompt（内含角色定义、工具列表、输出格式约束）。
- LLM 返回 JSON 指令。
- Agent 解释该 JSON，调用天气 API。
- 将结果拼接成最终回复。
在这一过程中，第 2 步和第 3 步之间如果 system prompt 长达 2k token，每次循环都重新处理就是巨大的浪费。Prompt Caching 解决的核心问题是：对重复出现的 prompt 前缀（通常是 system prompt + 固定 few-shot）只计算一次 KV 缓存，后续相同前缀的推理直接复用。 在 Agent loop、多轮对话、A/B 测试中这类场景非常常见。
具体场景：客服机器人的缓存策略
一个常见客服机器人 system prompt 可能包含：
- 公司知识库索引（1k tokens）
- 对话风格指令（0.5k tokens）
- 安全过滤规则（0.5k tokens）
假设每个用户提问前系统都要拼接这 2k tokens，日请求 10 万次，KV 缓存命中率可达 90% 以上。按 price cache hit 计算，每日成本可从 $20 降到 $4（OpenAI 定价为例）。
最容易失败的地方与错误理解
失败点 1：系统提示或上下文前缀频繁变动
如果 system prompt 里带了自定义变量（比如当前用户所在国家）、时间戳、随机授权码等每次不同的内容，那么 prompt 前缀就被污染了。例如：
You are a helpful assistant. Today is 2025-04-07.
每次日期不同，缓存永远无法命中。解决方案是把易变字段放到前缀之后（比如用户消息里），并严格确保前 80% 的 token 保持稳定。
失败点 2：多用户共用一个 API Key 时的上下文泄漏
Prompt Caching 是按公共前缀匹配的，不是按会话隔离的。如果两个用户的对话 history 前几句相同（比如都是“你好”），则可能复用对方的缓存。第三方库 anthropic-python 的早期版本就曾因为自动拼接 assistant 前缀而意外触发跨会话缓存。解决方案是在每个用户请求中加入唯一标识 session_id 作为前缀的一部分（但不需要缓存它），例如在 prompt 最开头添加<session id="abc">，然后利用 API 提供的“前缀跳过”参数（如 Anthropic 的 prompt_caching 配置）来避免缓存这些元数据。
错误理解：缓存一定省成本
实际上，如果缓存命中率低于 30%，成本反而高于无缓存——因为缓存命中的单次 token 价格虽然低，但缓存写入本身通常不计费，但会占用服务端资源，一些 API 会按缓存的 token 数量收取额外储存费（如 Google Gemini 的 $0.10 / 1M tokens stored）。对于对话长度极短（<100 tokens）或没有固定前缀的应用，Prompt Caching 带来的收益几乎为零。
如果你现在就要落地，第一步应该怎么做
- 审计你的 prompt：找出所有高频调用的 API 调用，记录它们的公共前缀长度和变化频率。优先对前缀稳定超过 80% 的端点启用缓存。
- 检查 API 文档：OpenAI 要求 prompt 完全匹配且长度>=1024 tokens；Anthropic 只缓存前 1024 tokens；Google 支持任意前缀但按存储量计费。不同提供商的缓存策略差异巨大。
- 从单端点灰度：选一个非关键路径（如后台分析报表生成），先启用缓存并添加监控指标：缓存命中率、p50/p95 延迟、成本前后对比。
- 设置 fallback 开关：一旦命中率低于 20%，或出现非预期的上下文混淆（比如回复中出现了其他用户的数据），立即降级为无缓存模式。
下面是迁移检查清单（图片见文内）:
- 确定可缓存的稳定前缀（长度 >= 1024 tokens）
- 修改 API 调用头，添加 cache 启用参数（如
"anthropic-beta": "prompt-caching-2025-03-17"） - 将易变字段移到前缀之后，或使用 skip 标记
- 在生产中运行 A/B 测试（50% 流量启用缓存）
- 监控缓存命中率、错误率和用户反馈
失败时的回退方案
如果 Prompt Caching 始终无法获得有意义的命中（比如平台不支持、前缀太短、变动太频繁），可以回退到：
- 本地 KV 缓存：用 Redis 或 in-memory cache 缓存 LLM 输出（注意：只适用于完全相同的 prompt 和温度，不同温度输出不同）。
- 语义缓存：对 prompt 进行 embedding，在 Redis 中搜索相似度 >0.95 的历史请求，复用输出（但需要做 hash 验证，避免逻辑偏差）。
- 请求合并：同一 prompt 短时间内的重复请求可直接从内存返回结果（适合轮询场景）。
这些方案需要你自行处理过期、冲突和隔离，不如 API 原生缓存省心，但胜在完全可控。
下一步：从工具使用者到系统设计者
如果你已经在考虑缓存命中率、跨会话泄漏、成本模型这些工程细节，说明你已经不满足于“调 API”的层面。真正的系统效率提升来自于对 Provider 特性的深度理解和组合设计——比如将 Prompt Caching 与 Agent 的循环控制流结合，或者在 MCP 工具调用中利用上下文复用。这些系统化的知识无法在零散的文章碎片中闭环，需要成体系的课程和工程案例来补齐。
暂无评论，快来发表你的见解吧