一文搞懂大模型 API 缓存：Claude Prompt Caching 如何帮你降本又提速

我想问问天
131 阅读9分钟

前言

image-20260118230214556

很多人第一次把大模型接进业务时，都会有一种兴奋感。

效果真好，模型真聪明，很多原来要写一大堆代码的逻辑，现在一句 prompt 就能搞定。

但很快，另一个现实问题就来了。

接口越来越慢，账单越来越长，尤其是当你开始做多轮对话、RAG 知识库、Agent 自动化时，会发现大量 prompt 其实每天都在重复发送，你就会发现，哇，api调用好贵啊，发了这么多重复的东西。

系统提示词、背景说明、长文档上下文，每一次调用都重新让模型“读一遍”，这件事本身就很反直觉。

这也是为什么，这两年大模型 API 的缓存能力，开始变成一个非常值得单独拿出来讲的话题。

今天这篇文章，我们就专门聊一件事：

大模型 API 层到底有哪些缓存能力，以及 Claude 的缓存是怎么设计、怎么用的。

1.目前主流的大模型厂商对缓存的支持情况

如果你只从模型效果看，很容易忽略一个事实。

大模型厂商在 API 层面，其实已经悄悄做了很多工程优化，缓存就是其中非常重要的一环。

先看一张整体对比表，更直观一些。

厂商 / 模型是否支持 API 层缓存缓存类型是否需要显式配置是否返回缓存命中信息备注
OpenAI GPT-4 / GPT-4o支持Prompt 前缀缓存否部分模型支持自动生效，主要降低输入成本和延迟
Anthropic Claude支持Prompt Cache（前缀缓存）是是可控性强，适合复杂系统
Google Gemini支持隐式缓存 / 显式缓存部分需要部分支持显式缓存适合长上下文和 RAG
Azure OpenAI支持Prompt 前缀缓存否否与 OpenAI 行为基本一致
通义千问支持提示词缓存否是返回命中 token 数量
文心一言支持提示词缓存否是对企业用户较友好
开源模型（LLaMA 等）不直接支持依赖业务或推理层需要自建否常配合 KV Cache、网关缓存

目前可以看到一个整体趋势。主流云厂商的缓存能力，大多集中在“提示词前缀缓存”这一层，开发者几乎不需要额外配置，就能获得一定的性能和成本收益。

而像 Claude 这样，把缓存做成显式、可控能力的厂商，目前只有一家，所以如果你是AI应用开发工程师，你想要在上下文上节省成本，最直接的就是使用claude的缓存。

image-20260118230910952

2.Claude 缓存的作用和原理

在一众厂商里，Claude 的缓存设计非常有代表性，也很适合用来讲清楚 API 缓存这件事。

先说作用。

Claude 的提示词缓存主要解决两个问题。

一个是成本。

如果你的 prompt 里有大量静态内容，比如系统指令、背景知识、范例对话，这些内容每次都重新推理，本身就很浪费。缓存命中后，这一部分的输入 token 会以极低的价格计费。

另一个是延迟。

因为缓存命中时，模型可以直接跳过前缀的计算，几乎立刻开始处理新增内容，所以首 token 时间会明显缩短。

那它是怎么做到的？

Claude 的缓存核心思路非常工程化。

开发者在 prompt 中标记一个缓存边界，边界之前的内容会被视为可缓存前缀。

第一次请求时，Claude 会完整处理 prompt，并把这部分中间推理状态缓存下来。

后续请求只要携带完全一致的前缀和相同的缓存边界，服务端就会直接复用这段缓存状态，只对后面的新增内容继续推理。

整个过程发生在服务端，对调用方式几乎没有影响。

缓存本身有生命周期，默认是几分钟。在有效期内重复使用相同前缀，缓存就会持续命中；过期后会重新计算并生成新的缓存。

在 API 返回的 usage 信息里，Claude 会明确告诉你有多少 token 是从缓存中读取的，这一点对性能和成本调优非常关键。

注意：这个缓存和咱们后端平时说的数据缓存不太一样，后端里面的缓存可以减少服务器的计算，数据直接用上一次的，但是大模型API层面的缓存，仅限于input, 也就是咱们输入的prompt，缓存的仅仅是输入的重复部分，输出是不能缓存的啊，很容易上下文只差几个字，要回答的部分就是千差万别，所以输出是不缓存的。

image-20260118231807108

3.Claude 缓存怎么使用

理解原理之后，真正落地其实并不复杂。Anthropic叫这个缓存技术叫Prompt caching，它允许开发者在 API 请求中“缓存”频繁使用的上下文（如大型文档、代码库或复杂的系统指令），从而大幅降低延迟并削减 90% 的输入成本。

Claude 的提示词缓存通过 cache_control 参数来控制，核心思路可以总结为一句话。

把稳定、可复用的内容放在 prompt 最前面，并明确标记缓存边界。

一个典型场景是这样的。

系统指令、背景说明、工具定义，这些内容在多次请求中保持不变。

你把它们作为 prompt 的前半部分，在末尾添加 cache_control 标记。

第一次请求时，Claude 会正常处理这些内容，并在满足最小 token 要求后写入缓存。

第二次请求开始，只要前缀内容和边界位置一致，就会命中缓存，直接复用前缀计算结果。

在返回结果中，你可以通过 cache_read_input_tokens 等字段判断缓存是否真的生效。

实践中有几个细节需要特别注意。

缓存前缀必须完全一致，哪怕多一个空格或换行，都可能导致无法命中。

缓存有有效期，请求间隔过长时，需要重新写入。

不同模型对最小可缓存长度有要求，prompt 太短时缓存不会生效。

即使命中缓存，你仍然需要把完整 prompt 发送给 API，服务端会基于完整内容判断是否可复用缓存。

image-20260118233723028

3.1. 工作原理

  • 前缀匹配： 缓存是基于“前缀”的。只有当请求的开头内容（包括 System Prompt 和消息顺序）与已缓存的内容完全一致时，缓存才会生效。

  • 缓存寿命 (TTL)： 默认有效期为 5 分钟。每当缓存被命中（被读取）时，该计时器会重置，重新计算 5 分钟。

  • 最小字符限制： * Claude 3.5 Sonnet / 3.5 Haiku / 3.0 Opus： 至少需要缓存 1024 tokens。

    • Claude 3.0 Haiku： 至少需要缓存 2048 tokens。

  • 写入上限： 目前每个 API 请求最多允许设置 4 个 缓存断点（breakpoints）。

3.2. 费用结构

  • 写入价格： 比基础输入（Input）价格贵约 25% 。
  • 读取价格： 比基础输入价格便宜 90% 。

3.3官方使用示例 (引用自官网)

官方文档通过 Python 示例展示了如何使用 cache_control 参数。在这个例子中，开发者将一本完整的长篇小说（《白鲸记》）放入 System Prompt 供后续多次提问，而无需每次付费重复解析整本书。

代码实现

Python

import anthropic
​
client = anthropic.Anthropic()
​
# 读取长篇文档（例如《白鲸记》全文）
with open("moby_dick.txt", "r") as f:
    book_content = f.read()
​
response = client.beta.prompt_caching.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "你是一个研究《白鲸记》的专家。"
        },
        {
            "type": "text",
            "text": book_content,
            # 在长文本处设置缓存断点
            "cache_control": {"type": "ephemeral"}
        }
    ],
    messages=[
        {
            "role": "user",
            "content": "请分析亚哈船长在第一章中的动机。"
        }
    ],
)
​
# 输出统计：可以查看 cache_creation_input_tokens (写入) 
# 或 cache_read_input_tokens (命中)
print(response.usage)

3.4常见问题 (FAQ) 核心要点

根据官方 FAQ 部分，以下是开发者最关心的几点：

问题官方解答要点
我怎么知道缓存是否生效？API 响应的 usage 字段会显示 cache_creation_input_tokens（写入量）和 cache_read_input_tokens（读取命中量）。
缓存支持哪些模型？目前支持 Claude 3.5 Sonnet, 3.5 Haiku, Claude 3 Opus, 以及 3 Haiku。
我能在 Messages 数组里用缓存吗？可以。通常建议在多轮对话的倒数第二条消息或倒数第四条消息设置断点。
缓存会跨用户/跨 API Key 共享吗？不会。缓存严格限制在单个组织的同一个 API Key 范围内。
如果我的缓存未被命中，会额外收钱吗？如果没有命中，你只需支付正常的输入 Token 费用。只有当你在请求中明确指定了 cache_control 标记时，该部分才会按写入价格收费。

3.5最佳实践建议

  1. 静态内容放在最前面： 将永远不变的系统指令、大型知识库文件放在 Prompt 的最顶端。
  2. 管理断点： 在多轮对话中，定期移动 cache_control 标记到最新的稳定历史记录处，以确保后续对话能持续命中。
  3. 监控流量： 如果你的请求间隔超过 5 分钟，缓存会自动清理。对于低频应用，缓存可能无法发挥最大经济效益。如果你这个提示词可能很多agent都会使用到，而且频率比较高，可以手动设置成一小时

总结

从工程角度看，大模型 API 缓存并不神秘，它做的事情很直接，让那些反复出现、几乎不变的上下文，不再被模型一次次重新理解。

当你开始构建复杂对话、知识库问答、Agent 系统时，缓存往往决定了系统能不能长期稳定运行。

理解缓存、使用缓存，本质上是在把大模型当成一个可以持续优化的工程系统。

如果你正在为 LLM 的成本和延迟考虑，（当然主要是成本，延迟可以有很多其他办法可以减少用户对性能的变化感知），你可以看看Claude Prompt Caching~

avatar
文章
阅读
粉丝