Prompt Caching（提示缓存）

什么是 Prompt Caching

Prompt Caching（提示缓存）是主流大模型 API 提供的一项成本与延迟优化能力：你可以标记提示里的某一段为「缓存断点（cache breakpoint）」，API 会把「从开头直到该断点」的整个前缀算一次、缓存起来，后续请求只要前缀相同，就直接读取缓存结果，不再重复处理。

它缓存的是完整前缀——按 tools → system → messages 的顺序，直到你标记的 cache_control 块为止。

解决什么问题

没有缓存时，下面这些场景每次请求都要把同样的长内容从头算一遍：

• 一份几万字的系统提示（角色设定 + 规则）
• 塞进上下文的整篇文档 / 知识库片段（RAG）
• 一大堆 few-shot 示例
• 不断变长的多轮对话历史

这些内容在相邻请求里几乎不变，却反复占 token、占算力。Prompt Caching 把它们「算一次、反复用」，典型命中读价只有标准输入价的 10%（0.1x）。

工作原理

以 Anthropic 的 cache_control 为例，两种开启方式：

• 自动缓存：在请求顶层加一个 cache_control，系统自动把缓存断点打到「最后一个可缓存块」，并随对话增长前移。最适合多轮对话。
• 显式缓存断点：在具体的 system / messages 内容块上直接标 cache_control，精细控制缓存哪一段。

import anthropic

client = anthropic.Anthropic()
resp = client.messages.create(
    model="claude-sonnet-4",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "你是一个代码审查助手，遵循本团队的 200 条规范……",  # 稳定长前缀
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[{"role": "user", "content": "审查这段 PR"}],
)

计费结构（以 Anthropic 为例）

默认缓存生命周期 5 分钟，命中即免费刷新；嫌短可买 1 小时档。

OpenAI（Prompt Caching）、Gemini（Context Caching）也有类似机制，命名与断点方式略有差异，但「复用稳定前缀省钱」的核心一致。

和 Context Engineering 的关系

Prompt Caching 是 Context Engineering 的省钱搭档：你把「该塞进上下文的」精心组织好，再用缓存断点把其中稳定不变的大块（系统提示、参考资料）钉在缓存里，让真正变化的部分（用户新消息）走标准价。配合 Compaction（长对话压缩）还能进一步保住系统提示的缓存命中。

常见误区

• 以为缓存「自动永远有效」——默认只有 5 分钟，跨请求间隔太久缓存失效，反而白付写入价。
• 把频繁变动的内容标成断点——前缀一变就整体 miss，等于没缓存。
• 在本地推理里找这个功能——Ollama / vLLM 自托管场景走的是 KV Cache / prefix cache，概念相近但不是 API 层的 prompt caching。

怎么用：三步上手

1. 找出稳定前缀：系统提示、常驻文档、few-shot 示例——这些放进缓存最划算。
2. 在稳定块末尾打 cache_control：多轮对话用自动缓存最省心。
3. 监控命中率：API 返回的 usage 里通常有 cache_read_tokens / cache_creation_tokens，命中率上去才真正省钱。

哪些工具支持

• Claude 系列（Claude Sonnet 4 等）原生支持 cache_control，Claude Code 在长上下文场景自动利用。
• GPT 系列（GPT-5）提供 Prompt Caching。
• Gemini 提供 Context Caching。
• 网关层如 LiteLLM 可统一转发各家缓存语义。

延伸阅读

• 长上下文管理：Context Engineering
• 模型如何调工具：Function Calling
• 协议层：MCP
• 推理引擎：vLLM

来源

• Anthropic — Prompt Caching 文档
• Anthropic — Pricing（含 Prompt Caching 倍率）