问题：重复的预填充计算正在吞噬 API 预算
一家企业每天通过 API 调用大模型处理数千份客服工单。每份工单都会携带相同的系统指令、工具定义、产品手册片段和对话历史，只有最后一条用户消息不同。从账单上看，输入 token 费用占据了总成本的大头，而其中绝大部分输入内容在每次请求之间几乎完全一样。工程师的第一反应是缩短提示词，但业务要求必须携带完整上下文，压缩空间有限。
问题的根源在于大模型推理的预填充（prefill）阶段。当模型收到一段提示词时，它需要把每个 token 都过一遍 Transformer 层，生成对应的 Key/Value（KV）缓存，供后续解码阶段使用。这段计算量与输入长度成正比，而且无法跳过——即使这段内容在上一秒刚刚被处理过。对于长上下文、高并发的企业场景，重复的预填充计算既拖慢响应，又推高成本。
提示词缓存（Prompt Caching）正是针对这一瓶颈设计的优化机制。它的核心思想是：如果后续请求的开头 token 与之前完全一致，服务端可以直接复用之前预填充阶段生成的 KV 状态，跳过这段重复计算。本文将以企业知识库问答为贯穿场景，对比 Anthropic 与 OpenAI 的缓存实现，分析命中条件、计费差异、失效策略以及适用边界。
为什么提示词缓存能省下 90% 的输入成本
要理解缓存的价值，先要看清推理成本的构成。大模型生成一个 token 的代价远低于处理一个输入 token。以 Anthropic 的 Claude Sonnet 4 为例，基础输入价格为 3 美元/百万 token，输出价格为 15 美元/百万 token，输出是输入的 5 倍。然而在长输入场景下，输入 token 的总量往往远大于输出，预填充阶段的计算量占了整个请求的绝大部分。缓存命中后，读取缓存的费用只有基础输入的 10%，写入缓存的费用则比基础输入贵 25%（5 分钟 TTL）或 100%（1 小时 TTL）。
缓存之所以能复用，依赖的是 Transformer 的前缀可复用特性。预填充阶段生成的 KV 张量只与当前 token 及其之前的上下文有关。如果两个请求的 prompt 前缀完全一致，那么模型在前缀部分产生的 KV 状态也完全一致，可以直接复用。服务端只需要为新增的 token 继续计算。这要求服务端对 prompt 进行严格的归一化处理，确保“相同”的文本在二进制层面完全一致，通常通过哈希值来标识。
在工程实现上，缓存通常分布在内存或快速存储中，并带有 TTL（生存时间）管理。Anthropic 默认提供 5 分钟缓存，每次命中都会刷新有效期，且刷新不额外收费。OpenAI 的缓存则完全自动，无需任何配置，命中后价格自动降低。两者的底层原理相同，但控制方式和计费模型差异显著，下面分别展开。
Anthropic：显式断点与分层缓存
Anthropic 的提示词缓存通过 cache_control 参数显式控制。你可以在请求的 system、tools 或 messages 中的某个 content block 上添加 cache_control: {"type": "ephemeral"}，系统会缓存从开头到该断点的所有内容。每个请求最多可以设置 4 个缓存断点，实现分层缓存。
分层缓存的价值在于隔离变化。假设你的提示词结构是：工具定义 → 系统指令 → RAG 文档 → 对话历史。如果只更新了对话历史，那么工具、系统指令和文档的缓存仍然有效，API 只需重新计算对话历史之后的部分。这避免了“牵一发而动全身”的缓存失效。
Anthropic 还提供自动前缀查找功能：即使不设置断点，系统也会自动检查前 20 个 content block 内是否有可复用的缓存前缀。但自动查找有上限，如果静态前缀由超过 20 个 content block 组成，自动匹配可能失败，这时需要手动设置断点。
缓存的最小长度要求因模型而异：Opus 和 Sonnet 系列要求至少 1024 tokens，Haiku 系列要求至少 2048 tokens。短于这个长度的内容不会被缓存。此外，thinking block 和子内容块（如引用）不能直接缓存，只能随顶级块间接缓存。
OpenAI：全自动缓存与零配置
OpenAI 的提示词缓存是完全自动的，不需要修改任何代码。系统会自动检测请求中可缓存的前缀，并复用之前缓存的结果。计费上，缓存命中的输入 token 价格远低于普通输入，且缓存写入不额外收费。
OpenAI 的缓存要求最小前缀长度为 1024 tokens（对于 gpt-4o 及更新模型），缓存粒度以 128 tokens 为增量（例如 1024、1152、1280……）。缓存的有效期通常为 5～10 分钟不活动后清除，低峰期可能持续长达 1 小时。
OpenAI 提供了一个可选参数 prompt_cache_key，用于帮助路由系统识别具有相同长前缀的请求。你可以为共享相同前缀的请求设置相同的 key，以提高缓存命中率。但需要注意，同一 key 的请求频率应保持在约 15 次/分钟以下，否则可能溢出到其他机器，导致缓存失效。
OpenAI 的缓存覆盖范围包括：完整的 messages 数组（system、user、assistant 消息）、用户消息中的图片（需保证 detail 参数一致）、tools 数组以及结构化输出的 schema。缓存命中情况可以在响应的 usage.prompt_tokens_details.cached_tokens 字段中查看。
计费模型对比：写入贵、读取便宜
两家提供商在计费逻辑上有一个共同点：写入缓存（即首次处理并存储）比基础输入贵，读取缓存（命中）比基础输入便宜。但具体比例和是否额外收费差异很大。
| 对比维度 | Anthropic | OpenAI |
|---|---|---|
| 启用方式 | 显式 cache_control 或自动前缀查找 | 全自动，零配置 |
| 缓存断点 | 最多 4 个显式断点 | 无显式断点，自动前缀匹配 |
| 最小缓存长度 | Opus/Sonnet: 1024 tokens；Haiku: 2048 tokens | 1024 tokens（gpt-4o 及更新） |
| 缓存粒度 | 以 content block 为单位 | 128 tokens 增量 |
| 缓存 TTL | 默认 5 分钟，可升级 1 小时（额外收费） | 5～10 分钟不活动，低峰期可达 1 小时 |
| 写入费用 | 基础输入的 125%（5 分钟）或 200%（1 小时） | 不额外收费 |
| 读取费用 | 基础输入的 10% | 约基础输入的 25%（可节省 75%） |
| 命中率提升手段 | 手动断点隔离变化 | prompt_cache_key 路由优化 |
| 数据隔离 | 组织级隔离，不同组织不共享 | 组织级隔离 |
| 缓存失效条件 | 内容变动、TTL 过期、修改工具或图片 | 内容变动、TTL 过期、请求频率过高 |
从成本角度看，Anthropic 的读取价格极低（10%），但写入价格较高，适合长输入、多次复用的场景。OpenAI 的写入免费，读取价格稍高（约 25%），但胜在零配置，适合快速接入。实际选择需要结合请求频率和输入长度来测算。
贯穿场景：企业知识库问答的缓存设计
假设你正在为企业构建一个知识库问答系统，提示词结构如下：
- 系统指令（固定，约 500 tokens）
- 工具定义（固定，约 300 tokens）
- 产品手册片段（固定，约 2000 tokens）
- 对话历史（动态增长，每次请求不同）
- 当前用户问题（动态）
如果使用 Anthropic，你可以在系统指令、工具定义和产品手册片段末尾分别设置缓存断点。这样，当对话历史变化时，前三者的缓存依然有效，API 只需处理对话历史和用户问题。如果使用 OpenAI，系统会自动缓存前 1024 tokens 的前缀，但你的静态内容可能超过这个长度，因此需要尽量把静态内容放在前面，并考虑使用 prompt_cache_key 来稳定路由。
下面用流程图展示一次请求的缓存处理逻辑：
flowchart TD
A[发起请求] --> B{检查前缀哈希}
B -- 命中 --> C[读取缓存 KV 状态]
B -- 未命中 --> D[完整预填充计算]
C --> E[仅计算新增 token]
D --> F[写入缓存并设置 TTL]
E --> G[生成响应]
F --> G
G --> H[返回结果与 usage 统计]
在这个流程中，关键决策点是前缀哈希匹配。系统会计算 prompt 前缀的哈希值，与缓存中的记录比对。如果命中，直接加载 KV 状态，跳过预填充；如果未命中，则完整计算并写入缓存。值得注意的是，Anthropic 的缓存刷新机制：每次命中都会重置 TTL，且不额外收费。这意味着高频请求可以持续保持缓存有效。
失效条件与失败模式
缓存并非万能，以下条件会导致缓存失效，需要在实际设计中规避：
- 内容变动：任何文本、图片或工具定义的修改都会使对应缓存失效。在 Anthropic 中，如果修改了某个 content block，该块及其后的缓存全部失效，但之前的块仍可复用。
- TTL 过期：超过 5 分钟（或 1 小时）未被使用，缓存自动清除。对于低频请求，缓存可能无法命中，反而增加了写入成本。
- 请求频率过高：OpenAI 中，同一
prompt_cache_key的请求频率超过约 15 次/分钟，可能导致缓存溢出到其他机器，命中率下降。 - 前缀长度不足：短于最小缓存长度的前缀不会被缓存。
- 多模态内容变化：图片的 detail 参数或内容变化都会导致缓存失效。
一个常见的失败模式是：开发者为了追求缓存命中，将动态内容（如时间戳、随机数）放在静态前缀之前，导致前缀频繁变化，缓存完全失效。正确做法是将静态内容放在前面，动态内容放在后面。
另一个陷阱是缓存写入成本。对于一次性请求或低频请求，写入缓存的花费可能超过节省的成本。例如，一个只调用一次的请求，写入 2000 tokens 的缓存需要支付 125% 的基础输入费用，而没有任何后续命中来摊薄成本。因此，缓存适合高频、长输入、内容稳定的场景。
数据隐私与安全边界
提示词缓存涉及数据存储，隐私是必须考虑的因素。Anthropic 明确说明，缓存严格隔离在组织内，不同组织即使内容完全相同也不会共享缓存。缓存采用加密哈希，且不可手动清除，只能等待 TTL 过期。这意味着，如果你的提示词包含敏感数据，这些数据会在缓存中保留一段时间（5 分钟或 1 小时），期间可能被后续请求命中。
对于有零数据保留（ZDR）要求的企业，Anthropic 提供了相关说明，但缓存本身会短暂存储数据。OpenAI 的缓存同样在组织内隔离，但具体保留策略需参考其数据使用政策。在合规敏感的场景中，需要评估缓存带来的隐私风险，可能需要在缓存启用和数据处理之间做出权衡。
适用边界与决策建议
提示词缓存并非适用于所有场景。以下情况适合启用缓存：
- 提示词包含大量静态内容（系统指令、文档、工具定义），且这些内容在多次请求中保持一致。
- 请求频率较高，能够在 TTL 内多次命中。
- 输入长度较长，预填充成本占比高。
以下情况可能不适合：
- 提示词几乎完全动态，静态前缀很短。
- 请求频率极低，缓存写入成本无法被命中收益覆盖。
- 对数据隐私有严格限制，无法接受缓存存储。
在实际决策中，建议先分析请求日志，统计提示词前缀的重复率。如果重复率超过 50%，且平均输入长度超过 2000 tokens，缓存通常能带来显著收益。同时，要监控 cache_read_input_tokens 和 cache_creation_input_tokens 两个指标，前者反映命中量，后者反映写入量。理想状态下，命中量应远大于写入量。
最后，缓存不会改变模型的输出结果。Anthropic 和 OpenAI 都明确表示，缓存只优化输入处理，输出内容与不使用缓存时完全一致。因此，你可以放心地将其作为成本优化手段，而不必担心影响生成质量。
提示词缓存是 Transformer 前缀复用特性在工程上的直接应用。理解其命中条件、计费模型和失效策略，能帮助企业在不牺牲质量的前提下，显著降低大模型 API 的调用成本。