_{记忆点：命中率高不等于省钱，要用账单与延迟数据证明收益。}

💡 答案要点

Prompt Caching = 对重复的 Prompt 前缀复用服务端缓存，减少重复预填充的计算和计费。

原理：KV Cache 从单请求扩展到多请求

传统 API 调用：每次 → 重新计算全部 token 的 KV Cache → 全价
Prompt Caching：相同 prefix → 复用已有 KV Cache → 读缓存低价

底层机制：

1. 服务端识别可复用的相同前缀；
2. 命中时复用缓存，减少相同前缀的重复计算；
3. 未命中时正常计算，并可能写入缓存；
4. 最小可缓存长度、保留时间、写入费用和显式标记方式都由供应商及模型决定，不能写成统一常量。

各家实现对比

Provider	典型机制	使用前要核对
OpenAI	支持隐式缓存；部分模型支持显式缓存模式	prompt_cache_options、写入/读取 token、TTL、模型支持范围
Anthropic	在内容块上设置 cache_control	最小长度、TTL、写入和命中价格
Amazon Bedrock	能力取决于底层模型和 Bedrock 接口	支持模型、缓存点和区域限制

如何优化 Prompt 顺序以最大化 Cache Hit Rate

# ❌ 错误：动态内容放在前面，每次请求都 miss
def bad_prompt(user_query, docs):
    return {
        "role": "user",
        "content": f"{user_query}\n\n参考资料：\n{docs}"
    }

# ✅ 正确：静态 System Prompt 在最前，动态内容在最后
def good_prompt(user_query, docs):
    messages = [
        {"role": "system", "content": SYSTEM_PROMPT},  # ← 不变，可缓存
        {"role": "system", "content": TOOL_DEFINITIONS},  # ← 不变，可缓存
        *conversation_history[-5:],  # ← 历史变化少，部分可缓存
        {"role": "user", "content": user_query},  # ← 唯一变化的部分
    ]
    return messages

Cache Breakpoint（显式控制缓存点）

# Claude: 在需要缓存的位置加 cache_control 标记
messages = [
    {"role": "system", "content": SYSTEM_PROMPT,
     "cache_control": {"type": "ephemeral"}},  # ← 这段一定会缓存
    {"role": "user", "content": user_query},  # ← 不会触发新缓存
]

# OpenAI：不要复用 Anthropic 的 cache_control 字段。
# 支持显式缓存的模型使用 prompt_cache_options；
# 具体 breakpoint/TTL 结构以当前 Responses API 文档为准。
response = client.responses.create(
    model="gpt-5.6",
    input=messages,
    prompt_cache_options={"mode": "explicit"},
)

如何验证是否省钱

至少对比四项：缓存写入 token、缓存读取 token、未缓存输入 token、端到端延迟。缓存写入可能比普通输入更贵；如果前缀短、变化频繁或复用次数低，显式缓存反而可能增加成本。

30 秒回答

“Prompt Caching 适合长且重复的稳定前缀，例如工具定义、固定规则和共享文档。优化时先把稳定内容放前面、动态内容放后面，再从 API usage 中统计写入与命中 token。不能只看命中率，还要把缓存写入费、TTL 内复用次数和延迟一起计算。各供应商字段不同，不能把 Anthropic 的 cache_control 直接套到 OpenAI。”

参考： OpenAI GPT-5.6 model guidance

---