_{记忆点：命中率再高不等于省钱，还要看写入费用、TTL 和复用次数。}

💡 答案要点

Prompt Caching 的收益取决于三个关键变量的乘积：

Total Savings = Cache_Hit_Rate × Dynamic_Tokens_Saved × Frequency × ΔCost_Per_Token
                              │                            │
                   （改写后不变的 prefix          （同一前缀
                    被命中节省的量）                 被重复使用的次数）

各家定价差异直接影响收益：

Provider	缓存写入价	缓存读取价	最小长度	典型 TTL
OpenAI	略低于常规输入	低很多	动态	~15min
Anthropic	cache_control 标记的块	仅计费读取部分	无硬性下限	会话内
Bedrock	取决于底层模型	取决于模型	因模型而异	不确定

ROI 计算公式：

prompt_size = 3000 tokens（System Prompt + Tools）
daily_requests = 10000（日均调用）
hit_rate = 0.80（预估命中率）
openai_input_price = $3.00/M tokens
openai_cache_read_price = $0.30/M tokens  （约 10% 的输入价格）
savings_per_day = hit_rate × daily_requests × prompt_size × (input_price - read_price)
                = 0.80 × 10000 × 3000 × ($3.00 - $0.30) / 1e6
                = $64.80/天
annual_savings ≈ $23,652/年

实操优化技巧：

# 1. 最大化静态前缀长度
messages = [
    {"role": "system", "content": SYSTEM_PROMPT},       # 最长不变部分
    {"role": "system", "content": TOOL_DEFINITIONS},     # 工具定义
    *conversation_history[-3:],  # 尽可能少地放进历史
    {"role": "user", "content": user_message},           # 唯一变化的部分
]

# 2. 同租户共享同一个 conversation
# 同一个用户的多次请求天然命中缓存

# 3. 避免在每个请求中引入随机内容
# ❌ 不要在消息里加 timestamp / request_id / random seed
# ✅ 这些放到请求头或元数据里，不进 messages

常见陷阱：

• ❌ 缓存写入比正常输入还贵 → 短文本频繁写缓存反而亏本
• ❌ 不同模型的 System Prompt 不一样 → 换模型 = 缓存全部失效
• ❌ TTL 过期后写入竞争 → 大量并发同时写入导致缓存不稳定
• ❌ 只看命中率不看整体 → 命中率 90% 但写入费极高 = 净亏损

面试话术：

"我做过的一个项目在 Prompt Caching 上每月省了大约 30% 的 API 费用。关键不是命中率——很多人以为命中率 90% 就一定省钱，但如果写入价格很高或者复用次数太低，缓存可能适得其反。我的做法是先统计现有 API 账单：写入 token 多少、读取 token 多少、总调用量多少，算出 breakeven point，再决定要不要开启显式缓存。"

---