提示词缓存与性能实用技巧

编辑部发布 2026-06-26 更新 2026-06-27 11 分钟阅读 2,198 字

本文围绕「提示词缓存与性能实用技巧」整理操作要点、适用场景和常见问题，帮助你先判断是否适合继续操作，再按步骤完成配置。

提示词缓存与性能：实用技巧

提示词缓存（Prompt Caching）是大型语言模型 API 的核心优化功能，它允许系统识别并重复使用已处理的前缀 token——包括系统指令、长上下文、工具描述或对话历史——从而在后续请求中显著降低延迟和成本。本质上，它在你的输入中划定一道“缓存断点”，让相同的起始部分只需计算一次。

这项能力对频繁使用固定系统提示、处理超长文档或执行异步批处理任务的用户尤为关键。正确启用后，首 token 耗时（TTFT）可降低约 85%，同时输入 token 成本最多减少 50%。然而，其生效条件相当严格——若使用不当，你可能根本看不到任何性能提升，甚至反而增加延迟。

开始之前

确认你的模型支持缓存

并非所有模型或 API 端点都开放提示词缓存。截至 2025 年中，主要平台的情况如下：

平台	支持缓存的模型	缓存条件	费用折扣
Claude (Anthropic)	Claude 3.5 Sonnet, Claude 3 Opus, Claude 3 Haiku	前缀连续 ≥1024 token	输入 token 成本 -50%
OpenAI	GPT-4o, GPT-4 Turbo	前缀连续 ≥1024 token（部分需经由特定端点）	输入 token 成本 -50%
Gemini（Google）	Gemini 1.5 Pro, 1.5 Flash	上下文 ≥32768 token 时自动触发	上下文 token 成本 -64%~75%
Mistral	Mistral Large (24.11)	需在请求中显式标记 `cache:true`	待确认

关键检查点：如果你使用的是不支持缓存的旧模型（如 GPT-3.5-turbo），或通过第三方代理调用 API，提示词缓存不会生效；即使包含了缓存参数也会被忽略（API 也不报错）。

理解缓存的工作边界

位置决定一切：只有从输入开头开始的连续 token 序列才会被缓存。任何插入、替换或顺序调整都会使缓存失效。
缓存有生存期：多数平台在缓存未被命中的 5–60 分钟后将其自动丢弃（Claude 约 5 分钟，Gemini 更长）。
缓存命中的证据：API 响应中 usage.cache_creation_input_tokens 和 usage.cache_read_input_tokens 字段的数值从 0 变为正数，是缓存生效的唯一可靠标志。如果不显示这些字段，说明未命中缓存。

实操步骤

以下是一个真实场景：你正在使用 Claude API 构建一个合同审查助手，每次请求都需要带上 3000 token 的法律条款知识库（系统提示），然后传入不同的待审查合同（用户内容）。

第 1 步：设计可缓存的提示结构

把提示词拆成三个明确部分：

[system]
你是专业的合同审查助手...（知识库正文，约 3000 token）
--- 缓存断点 ---
[user]
请审查以下合同条款：{user_contract_text}

关键：让系统提示以完全相同的内容出现在每一次请求的最前端。不要在知识库前插入时间戳、随机 ID 或用户特定的问候语。

第 2 步：在 API 请求中标记缓存断点

以 Anthropic Messages API 为例：

{
  "model": "claude-3-5-sonnet-20241022",
  "system": [
    {
      "type": "text",
      "text": "你是专业的合同审查助手...\n（知识库正文，约 3000 token）",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [
    {"role": "user", "content": "请审查以下合同条款：\nXXXXX"}
  ],
  "max_tokens": 4096
}

在 system 参数的文本块上添加 cache_control: {type: "ephemeral"} 来指示 API 创建缓存断点。OpenAI 的 API 则需要在 messages 数组中相同位置添加该参数。

新手最容易忽略的一点：system 参数本身不从 0 token 开始算——它自带约 4 token 的隐式开销。如果知识库恰好只有 1020 token，加上这 4 token 后 1024 阈值达标，缓存才会创建。

第 3 步：验证缓存是否命中

发送第一次请求后，检查 API 响应中的 usage 对象。

字段	首次请求（创建缓存）	后续请求（命中缓存）	含义
`cache_creation_input_tokens`	3004	0	本次创建了缓存的 token 数
`cache_read_input_tokens`	0	3004	本次命中了缓存的 token 数
`input_tokens`	3010	6	实际计费的输入 token（不含缓存命中部分）

注意：如果多次请求后 cache_read_input_tokens 始终为 0，说明缓存未生效。最常见的原因是前缀长度未达到 1024 token 或每次请求的前缀不完全一致。

第 4 步：优化缓存利用率

批量处理：连续发送对同一知识库的不同查询，在缓存失效前尽可能多次命中。理想节奏是每 2–3 分钟发送一批。
合并系统提示：如果多个模型共享同一套指令，将该指令段落放在最前面统一缓存，而不要在每个模型各自重复。
避免日期间隔：不要在缓存前缀中嵌入今天的日期或用户名称，除非这些信息在每个请求中完全相同。只需把有差异的部分放到用户消息中。

核查清单

首次配置缓存时，请逐项核验：

使用的模型是否在官方文档中明确支持提示词缓存
最新 SDK 版本是否包含缓存参数的支持（anthropic Python SDK ≥0.39.0，openai Python SDK ≥1.43.0）
缓存前缀长度是否严格超过 1024 token（Claude/OpenAI）或 32768 token（Gemini）
所有请求的前缀（从开头到缓存断点）是否完全一致——包括空格、换行、标点
API 响应中是否包含 cache_* 计数字段
连续发送两个相同的请求后，第二个请求的 cache_read_input_tokens 是否 > 0
客户端所用的 API 密钥是否具有访问缓存功能的权限（部分平台需单独启用）

排错指南

现象	可能的原因与解决方案
响应中无 `cache_*` 字段	模型不支持缓存或 SDK 版本过旧。升级 SDK 或更换模型。
始终只有 `cache_creation`，没有 `cache_read`	两次请求的前缀不完全一致。用精确字符串比较工具检查两端。常见陷阱：末尾多了一个空格或不同的 Unicode 引号。
缓存偶尔命中、偶尔丢失	可能是缓存因不活跃被自动清除（间隔超过 5 分钟）。缩短单次任务的请求间隔，或在缓存失效前批量发出。
带了 `cache_control` 后请求反而变慢	创建缓存的首批请求本身不会有加速效果——缓存是在处理时才写入的。只有后续请求才会受益。
Gemini 显示缓存已激活但费用未下降	Google 的缓存计费方式与 Claude/OpenAI 不同：缓存命中时仅收取命中的处理费，但存储缓存本身按 token 时长计费。长空闲期可能抵消节省。

何时应该停止当前操作：如果你检查 API 文档后发现自己的场景中根本无法满足连续一致前缀长度 ≥1024 token 的条件（例如系统提示只有 200 token 且你无法添加内容），那么提示词缓存不适合你。与其强行填充无用 token 凑数（会导致实际输入成本增加），不如考虑其他优化手段：例如减少每轮携带的历史消息、使用批量 API 或异步流式调用。

常见问题