大模型 API 账单瘦身术：Prompt Caching 提示词缓存原理、实战与省钱避坑
你的 RAG、Agent 应用 60%–90% 的 API 费用，其实都花在了重复计算同一段提示词上。Prompt Caching 能在不降低任何输出质量的前提下，把输入成本砍掉 50%–90%——本文从 KV Cache 底层机制讲到四大厂商 2026 年最新实现，再给出可复现的代码、盈亏平衡矩阵与避坑清单。
开篇：从一个真实业务场景说起
假设你负责一个基于 RAG（检索增强生成）的企业智能客服：系统提示词 + 工具定义 + 一份 50,000 token 的产品手册，每次用户提问都会原封不动地塞进请求。按 Claude Sonnet 4.6 的 $3/MTok 算，每天 1,000 次咨询就是 50,000,000 输入 token、每天 $150 白花——因为这段上下文从来没变过，只是每次都被模型从头到尾重新算了一遍。
更隐蔽的是 Agent 场景：一个 20,000 token 系统提示词的长任务 Agent，单次任务要循环调用十几轮，每轮都把同一段提示词重发一遍。OpenClaw、Claude Code 这类工具之所以敢把整个代码库摘要塞进上下文，背后靠的正是 Prompt Caching。
问题来了：你兴冲冲地给请求加了 cache_control 标记，账单却没降几个钱；或者你压根不知道有这回事，每月在重复 token 上多付 60%–90%。这篇文章要解决的，就是「提示词缓存到底怎么省、省多少、什么时候反而更贵」这一件事——从 KV Cache 原理讲到四大厂商 2026 年最新规范，再到可直接照抄的生产级配置。
技术背景与核心概念扫盲
为什么重复上下文这么贵：Prefill 与 Decode
Transformer 大模型生成回答分两个阶段：
- Prefill（预填充）：把提示词（Prompt）中每个 token 与前面所有 token 做注意力计算（Attention），复杂度约 O(n²)。提示词越长，这一阶段越贵。
- Decode（解码）：逐 token 生成输出，每一步只让新 token 与历史 KV 做注意力，复杂度 O(n)。
Decode 阶段之所以能 O(n)，靠的是 KV Cache（键值缓存）——把 Prefill 阶段算好的每个 token 的 K、V 张量存下来复用。但问题在于：KV Cache 默认只在单次请求内部复用。下一次请求哪怕前缀一模一样，服务端也会把整个 Prefill 重算一遍。
Prompt Caching（提示词缓存） 做的事情，就是把这个「请求内复用」升级为「跨请求复用」：服务端把重复前缀对应的 KV 张量持久化，后续请求命中时直接跳过 Prefill，只对新内容计算。你为命中的部分付的只是「读取缓存」的折扣价，模型输出的结果和完整计算逐字节一致——因为没有蒸馏、没有量化、没有质量折损，纯粹是省掉了重复劳动。
演进脉络：从 JSON Mode 时代到断点时代
提示词缓存不是 2026 年的新概念，但 2026 年的实现形态发生了质变：
- 2024 年：OpenAI 上线自动缓存（自动识别 ≥1024 token 前缀，命中 5 折）；Anthropic 推出显式
cache_control断点机制（公共预览 8 月、GA 12 月）；Google 在 I/O 大会上线显式上下文缓存。 - 2025 年：DeepSeek 靠 MLA 低秩压缩把 KV 状态压缩数倍，全球首家把缓存落盘（硬盘缓存）；Google 为 Gemini 2.5 上线零配置隐式缓存。
- 2026 年：Anthropic 将默认 TTL（生存时间）从 1 小时缩短为 5 分钟并推出 1 小时档；OpenAI 在 GPT-5.6 家族引入显式缓存断点
prompt_cache_breakpoint；DeepSeek 缓存命中价格降至首发价 1/10。
一句话概括现状：缓存已经从「可选项」变成了生产级 LLM 工程的默认基础设施，而各家在「自动 vs 手动」「写溢价 vs 无溢价」上的分歧，正是选型时最容易踩坑的地方。
底层原理深度拆解
一层层剥开：KV Cache 如何跨请求复用
以单层注意力为例。输入 token 序列经 Embedding 后得到向量 x，通过三个权重矩阵投影出 Q、K、V。注意力得分为 Q·Kᵀ，再对 V 加权求和。K 和 V 只依赖输入本身，与后续生成无关，所以可以缓存。
图 1：Transformer 解码的 KV Cache 机制与跨请求前缀缓存
请求 1: [系统提示 2000 tok] [用户Q1 50 tok]
│ Prefill 完整计算 │ Decode 生成 A1
▼ ▼
KV 张量(2000+50) ───────────────▶ 响应 A1
│ KV 状态持久化到缓存池（内存/硬盘）
▼
请求 2: [系统提示 2000 tok] [用户Q2 80 tok]
│ 前缀完全匹配 → 从缓存读取 KV，跳过 Prefill
▼
仅对新 token 执行 Prefill → Decode 生成 A2
图 1 说明：两个请求共享前 2000 个 token 的完全一致前缀，请求 2 直接复用请求 1 持久化的 KV 张量，注意力计算量从 O((2050)²) 降到 O((80)² + 2000 的读取开销)。
关键前提是「前缀完全匹配」：缓存以字面 token 序列为键，前缀里任何一个字符变化（哪怕是时间戳、换行符、emoji），命中的就是另一条缓存路径，整段失效。这决定了后面所有优化策略都围绕一件事——保持前缀字节级稳定。
两大实现流派：断点式 vs 自动式
2026 年主流厂商分成了两种截然不同的工程哲学：
流派 A：Anthropic 显式断点（Explicit Breakpoints）
你在内容块上手动挂 cache_control: {"type": "ephemeral"}，服务端为「从提示词开头到该断点」的整段前缀算一个累计哈希，只在此处写入一条缓存。前缀顺序固定为 tools → system → messages。每个请求最多 4 个断点，且查找时向前回溯（Lookback）最多 20 个内容块。
流派 B：OpenAI / DeepSeek 自动缓存（Automatic Caching） 你不需要做任何事：OpenAI 自动为 ≥1024 token 的稳定前缀建缓存（命中按 128 token 粒度计费）；DeepSeek 在请求边界、公共前缀检测、固定 token 间隔三处自动持久化「缓存前缀单元」。代价是你对缓存边界失去控制权。
流派 C：Google 混合
Gemini 2.5 的隐式缓存零配置、75%–90% 折扣；显式缓存则要手动创建 cachedContents 资源并支付存储费（约 $1/MTok/小时）。
为什么「缓存了却没省钱」：写溢价与盈亏平衡
Anthropic 是唯一收「写溢价」的厂商：首次写入某段前缀，按基础输入价的 1.25×（5 分钟档）或 2.0×（1 小时档） 计费；之后的每次命中读取仅 0.1×。这意味着命中率低时，你一直在为「写入」付溢价，却等不来足够的「读取」摊薄成本——这就是很多人「配了缓存账单反而涨」的根源。OpenAI、Google、DeepSeek 都没有写溢价，miss 就是原价，怎么都不亏，只是省多省少的问题。
图 2：Anthropic 断点式缓存与 OpenAI 自动式缓存的架构对比
Anthropic（手动断点） OpenAI（自动缓存）
┌──────────────────────────┐ ┌──────────────────────────┐
│ tools 定义 [固定] │ │ 系统指令 [≥1024 token] │
│ system 指令 [固定] │ │ 历史消息 [自动识别最长前缀] │
│ RAG 文档 [固定] │ │ 新用户输入 [不缓存] │
│ ── cache_control 断点 ◀──┤ └──────────────────────────┘
│ 动态用户消息 [不缓存] │ 自动前缀匹配，无断点控制权
└──────────────────────────┘
写：1.25× / 2.0×（有溢价） 写：无溢价
读：0.10×（90% 折扣） 读：0.10×–0.50×（50%–90% 折扣）
控制：4 个断点 + 20 块回溯 控制：无，纯自动
图 2 说明：Anthropic 给你「断点在哪」的绝对控制权，但写入要付费；OpenAI 全自动、无写溢价，但缓存边界由服务端决定。
手把手实战落地
下面用 Python SDK 完成四种主流缓存模式的落地。环境要求：anthropic>=0.40、openai>=1.60，均可通过 pip install -U anthropic openai 安装；文中价格与参数均基于 2026-08-13 时的官方文档。
示例 1：Anthropic 自动缓存——一行参数开启
最简单的方式是在请求顶层挂 cache_control，服务端自动把断点放在最后一个可缓存块上：
import anthropic
client = anthropic.Anthropic() # 读取 ANTHROPIC_API_KEY 环境变量
response = client.messages.create(
model="claude-sonnet-5",
max_tokens=1024,
# 顶层 cache_control：自动在最后一个可缓存块上打断点
cache_control={"type": "ephemeral"},
system="你是负责分析文学作品的 AI 助手，擅长从主题、人物、写作风格三个维度输出见解。",
messages=[{"role": "user", "content": "分析《傲慢与偏见》的婚姻观。"}],
)
# 查看本次请求的缓存账本
print("本次写入缓存 tokens:", response.usage.cache_creation_input_tokens)
print("本次命中缓存 tokens:", response.usage.cache_read_input_tokens)
print("新鲜计算 tokens:", response.usage.input_tokens)
注意：顶层自动缓存的断点位于最后一个可缓存块。若你的结构是「静态系统提示 + 每次变化的用户消息」，断点会落到变化块上，导致每次都 miss（详见踩坑篇）。
示例 2：Anthropic 显式多断点——系统提示 + RAG 文档分层缓存
多轮 RAG 问答是最典型的场景：产品手册固定、问题每次变化。用两个断点分别缓存系统提示与文档，让动态内容彻底隔离在断点之后：
import anthropic
client = anthropic.Anthropic()
SYSTEM_PROMPT = "你是 XX 产品的技术支持代理，回答务必引用文档原文。" * 30 # 模拟 >1024 token
DOCS = "（50,000 token 的产品手册全文……）"
response = client.messages.create(
model="claude-sonnet-5",
max_tokens=1024,
system=[
{
"type": "text",
"text": SYSTEM_PROMPT,
"cache_control": {"type": "ephemeral"}, # 断点 1：缓存系统提示
}
],
messages=[
{
"role": "user",
"content": [
{
"type": "text",
"text": f"参考文档：\n\n{DOCS}",
"cache_control": {"type": "ephemeral"}, # 断点 2：缓存文档
},
# 用户问题放在断点之后，每次变化但不影响前面的缓存
{"type": "text", "text": "问题：如何解决错误 429 限流？"},
],
}
],
)
# 第二次及以后的请求，这两个断点前的 KV 全部从缓存读取
print("缓存写入:", response.usage.cache_creation_input_tokens)
print("缓存命中:", response.usage.cache_read_input_tokens)
第一次请求为「系统提示 + 文档」两条前缀写入缓存（按写溢价计费），从第二次提问开始，这两段全部按 0.1× 读取价计费。50,000 token 手册被引用 1,000 次时，无缓存 $150/天 vs 有缓存约 $18.4/天，每天省 $131。
示例 3：OpenAI 自动缓存——零代码改动 + 命中监控
GPT-5.5 及更早模型（gpt-5.5、gpt-5.4 等）自动开启缓存，你无需传任何参数，只要保证前缀稳定且 ≥1024 token。要做的只是读取 usage 字段确认命中：
from openai import OpenAI
client = OpenAI() # 读取 OPENAI_API_KEY
# Responses API：静态指令放 instructions，动态输入放 input
response = client.responses.create(
model="gpt-5.5",
instructions="你是资深法律顾问，回答需给出法条依据与风险提示。" * 20, # 稳定前缀
input="请问竞业限制协议的最长期限是多少？",
)
details = response.usage.input_tokens_details
print("缓存命中 tokens:", details.cached_tokens)
print("未命中 tokens:", details.input_tokens - details.cached_tokens)
⚠️ 版本红线：GPT-5.5 及更早模型不支持
prompt_cache_options/prompt_cache_breakpoint参数，传了会返回 400 错误——它们只能用自动缓存。显式断点是 GPT-5.6 家族的新能力。如果你同时在 Azure OpenAI 与 OpenAI 直连之间切换，务必按模型版本区分调用方式。
示例 4：DeepSeek 硬盘缓存——OpenAI 兼容协议零改动
DeepSeek 的上下文硬盘缓存对用户完全透明，按前缀单元自动匹配，用 OpenAI 兼容接口即可，费用按命中/未命中分开计：
from openai import OpenAI
client = OpenAI(
base_url="https://api.deepseek.com",
api_key="sk-你的key",
)
# 系统提示 + 金融报告正文作为稳定前缀，问题每次变化
messages = [
{"role": "system", "content": "你是一名资深财务报告分析师……" * 40},
{"role": "user", "content": "<财报全文……>\n\n请分析该公司的盈利能力。"},
]
resp = client.chat.completions.create(
model="deepseek-v4-flash",
messages=messages,
temperature=0.3,
)
# DeepSeek 特有的两个缓存计数字段
print("缓存命中 tokens:", resp.usage.prompt_cache_hit_tokens)
print("缓存未命中 tokens:", resp.usage.prompt_cache_miss_tokens)
DeepSeek 的缓存是「尽力而为」：缓存构建需要数秒，命中需完整匹配某个已持久化的前缀单元；不再使用后几小时到几天内自动清理。价格方面（截至 2026-08-13）：V4-Flash 命中 0.02 元/MTok（未命中 1 元）、V4-Pro 命中 0.025 元/MTok（未命中 3 元），是四大厂商中缓存单价最低的。
示例 5：通用成本核算函数——验证你省了多少钱
「配了缓存」不等于「省了钱」，必须用 usage 字段做定量核算。下面这个函数适用于任何 Anthropic 系模型：
def calculate_cost(usage, prices: dict) -> dict:
"""根据 usage 字段核算实际成本与相对无缓存的节省率。
prices 示例（每百万 token，美元）:
{"input": 3.00, "cache_read": 0.30,
"cache_write": 3.75, "output": 15.00}
"""
M = 1_000_000
# 从 usage 中安全取数，缺失字段视为 0
read = getattr(usage, "cache_read_input_tokens", 0) # 缓存命中
write = getattr(usage, "cache_creation_input_tokens", 0) # 缓存写入
fresh = getattr(usage, "input_tokens", 0) # 新鲜输入
out = getattr(usage, "output_tokens", 0)
# 实际成本：命中部分按读取价，写入部分按写价，其余按原价
actual = (
read / M * prices["cache_read"]
+ write / M * prices["cache_write"]
+ fresh / M * prices["input"]
+ out / M * prices["output"]
)
# 假设没有缓存：所有输入都按原价
baseline = (
(read + write + fresh) / M * prices["input"]
+ out / M * prices["output"]
)
savings = (baseline - actual) / baseline * 100 if baseline > 0 else 0
return {"actual_usd": actual, "baseline_usd": baseline, "savings_pct": savings}
# 用法示例：10,000 token 缓存命中、输出 500 token
class _U:
cache_read_input_tokens = 10_000
cache_creation_input_tokens = 10_000 # 首次写入
input_tokens = 20
output_tokens = 500
print(calculate_cost(_U(), {"input": 3.0, "cache_read": 0.3, "cache_write": 3.75, "output": 15.0}))
# 输出 ≈ {'actual_usd': 0.0098, 'baseline_usd': 0.0365, 'savings_pct': 73.0}
示例 6：命中率监控——把缓存当线上指标来盯
缓存命中率应和延迟、错误率一样进监控大盘。Anthropic 与 OpenAI 都在响应里返回缓存用量，按下面公式算命中率并设告警：
def hit_rate(usage) -> float:
"""计算本次请求的缓存命中率（0~1）。"""
read = getattr(usage, "cache_read_input_tokens", 0)
write = getattr(usage, "cache_creation_input_tokens", 0)
fresh = getattr(usage, "input_tokens", 0)
total = read + write + fresh
return read / total if total > 0 else 0.0
# 结合 Prometheus/StatsD 打点：对长稳定前缀负载，命中率 < 0.6 视为结构问题
关键细节与踩坑指南
坑 1：2026 年 TTL 变更——不知道就白交一个月学费
Anthropic 在 2026 年初把默认 TTL 从 1 小时缩短到 5 分钟（1 小时档需显式指定 ttl: "1h" 且写价升到 2.0×）。这意味着：缓存写入后 5 分钟内没有再次命中的请求，缓存即失效；且 TTL 从「请求开始」计时，不是响应结束——一次流式响应如果耗时 4 分钟，后续请求必须在响应结束后约 1 分钟内跟上。
对策：把需要共享缓存的批量操作（如多语言翻译、批量文档问答）打包进 5 分钟窗口内的连续循环；稀疏流量业务改用 1 小时档或干脆不用 Anthropic。
坑 2：断点打在「每次都变」的块上
这是文档里反复强调的头号错误。前缀哈希是累计的——断点前的任何块变化都会使整条哈希失效。如果你把 cache_control 挂在含时间戳/用户 ID 的动态块上，服务端只会为「动态内容」写缓存，静态内容永远读不到。
正确做法：断点永远放在「跨请求保持一致的最后一块」上；动态内容（用户查询、时间戳、个性化信息）一律放到断点之后。
坑 3：静态与动态混排、工具乱序
工具定义顺序一换，或把动态时间戳塞进系统提示词，整条前缀失效。Anthropic 官方在 Claude Code 实践中总结出 7 条反直觉经验，核心两条：静态在前、动态在后（tools → 系统提示 → 项目上下文 → 会话历史 → 聊天记录）；状态更新用消息而不是改提示词——日期变了、文件改了，用下一轮对话里的系统消息传达，别动静态块。
坑 4：对话中途换模型
缓存与具体模型绑定。在 100k token 的长对话深处切到小模型（如 Haiku），等于把整个前缀重新 Prefill 一遍，往往比一直用大模型更贵。任务交接请用子代理（Subagent）机制，而不是换模型。
坑 5：并发请求的缓存时序
Anthropic 的缓存条目在第一个响应开始后才可用。并发打 10 个相同请求，只有第一个是写入，后面 9 个可能全部 miss。需要并发命中时，先发 1 个预热请求，等首个响应开始再放行其余请求。
坑 6：最小可缓存长度不达标
Anthropic 各模型有最小可缓存前缀长度（约 1024–4096 token，Haiku 系要求更高），不足则不建缓存且不报错——你以为配好了，实际 cache_creation_input_tokens 和 cache_read_input_tokens 都是 0。落地时务必打印 usage 字段验证，别只凭代码「觉得生效了」。
生产环境最佳实践
提示词排序规范：最稳在前，最活在后
把整个优化收敛成一句话——按内容稳定性从高到低排序：
| 内容块 | 变化频率 | 推荐位置 | 放错位置的代价 |
|---|---|---|---|
| 工具/函数定义 | 几乎不变 | 第 1 位（最前） | 重排工具使下方全部失效 |
| 系统提示指令 | 极少 | 第 2 位 | 改动一个词就断前缀 |
| 参考文档/RAG 语料 | 偶尔 | 第 3 位 | 每次重排检索块会杀死命中 |
| 对话历史 | 增长、旧轮固定 | 第 4 位 | 回改旧轮使尾部失效 |
| 实时用户查询/工作记忆 | 每请求 | 最后 | 放前面则整条前缀失效 |
直接可复用的生产配置模板
# 生产级提示词组装规范（Anthropic 显式断点版）
def build_cached_request(user_query: str, retrieved_chunks: list[str]):
return {
"model": "claude-sonnet-5",
"max_tokens": 2048,
# 缓存点 1：系统提示（稳定，永远放最前）
"system": [{
"type": "text",
"text": SYSTEM_PROMPT,
"cache_control": {"type": "ephemeral"},
}],
"messages": [{
"role": "user",
"content": [
# 缓存点 2：检索到的文档块（同批次内稳定）
{"type": "text", "text": "参考资料：\n" + "\n---\n".join(retrieved_chunks),
"cache_control": {"type": "ephemeral"}},
# 动态查询绝不缓存，放在断点之后
{"type": "text", "text": f"请回答：{user_query}"},
],
}],
}
TTL 档位选择决策
- 高频负载（每分钟 >2 次命中）：5 分钟档，写溢价 1.25×，盈亏平衡点仅约 1.4 次读取/写入。
- 中频负载：1 小时档（写溢价 2.0×），但注意命中率需 ≥67% 才能跑赢 5 分钟档，低于 50% 比不缓存还贵。
- 慢批量 Agent：OpenAI 的 24 小时扩展保留（
prompt_cache_retention: "24h"）适合隔天仍复用的长任务。 - 自托管 vLLM：前缀缓存（APC）无成本顾虑，O(1) 哈希查找，共享前缀负载吞吐可提升 14–24 倍。
三层缓存叠加架构
把命中率压榨到极限，可以叠加三层：语义缓存（embedding 相似度拦截，命中省 100% 输入+输出）→ 前缀缓存（本文章主题，省 50%–90% 输入）→ 全量推理（0% 节省）。调优良好的系统可把 70%–80% 的 token 路由进前两层缓存。
安全与合规
各家缓存都强调租户隔离：DeepSeek 缓存按用户逻辑隔离、长时间不用自动清空；Anthropic 支持零数据保留（ZDR）协议下的缓存。敏感场景下，把缓存开关与数据留存策略绑定，并在缓存层做脱敏。
横向对比与选型建议
图 3：四大厂商 2026 年提示词缓存核心参数对比（截至 2026-08-13）
| 维度 | Anthropic Claude | OpenAI GPT | Google Gemini | DeepSeek |
|---|---|---|---|---|
| 开启方式 | 手动断点/自动 | 自动（5.6 起支持显式断点） | 隐式+显式 | 全自动 |
| 缓存读取折扣 | 90%（0.1×） | 50%–90% | 75%–90% | ~90%（约 0.1×） |
| 写入溢价 | 5min 档 1.25×；1h 档 2.0× | 无 | 显式有存储费 $1/MTok/h | 无 |
| TTL | 5min 默认 / 1h 可选 | 5–10min 自动，24h 扩展可选 | 300s / 3600s | 几小时到几天 |
| 最小前缀 | 约 1024–4096 token | 1024 token | 1024–2048 token | 64 token 存储单元 |
| 命中控制 | 4 断点 + 20 块回溯 | 无（自动） | 显式 cachedContents | 无（自动） |
| 典型命中单价 | $0.30/MTok（Sonnet 4.6） | $0.50/MTok（GPT-5.5） | $0.03/MTok（2.5 Flash） | 0.02 元/MTok（V4-Flash） |
图 3 说明：Anthropic 给最强控制力但收写溢价；OpenAI/DeepSeek 零门槛但无边界控制；Google 显式缓存有存储费，低频场景要谨慎。
选型决策路径
- 要确定性、延迟敏感（如语音 Agent、实时编码助手） → 选 Anthropic 显式断点，命中率可设计为 100%（前缀匹配即命中），写溢价用高 QPS 摊薄。
- 快速原型、不想改代码 → OpenAI / DeepSeek 自动缓存，怎么都不亏，省多省少随缘。
- 海量长文档、极致低价 → DeepSeek V4 系列，缓存命中单价全球最低（0.02 元/MTok），且 1M 上下文、384K 输出。
- Google 生态（Vertex AI） → 隐式缓存零配置；显式缓存只在「每存储小时读取量足够大」时启用，否则存储费吃掉折扣。
- 自托管 → vLLM 前缀缓存，无计费、纯算力收益，但需自己养 GPU。
性能实测与效果验证
盈亏平衡矩阵：什么时候缓存反而更贵
图 4：不同命中率下缓存后输入成本占「无缓存基线」的百分比（<100% 为省钱，>100% 为亏钱）
| 命中率 | Anthropic 5min(1.25×/0.1×) | Anthropic 1h(2.0×/0.1×) | OpenAI(1.0×/0.1×) | Google 隐式(1.0×/0.25×) |
|---|---|---|---|---|
| 30% | 90.5% | 143%（亏） | 73% | 77.5% |
| 50% | 67.5% | 105%（亏） | 55% | 62.5% |
| 60% | 56% | 86% | 46% | 55% |
| 70% | 44.5% | 67% | 37% | 47.5% |
| 80% | 33% | 48% | 28% | 40% |
| 90% | 21.5% | 29% | 19% | 32.5% |
图 4 说明：公式为 混合成本 = (1−命中率)×写倍率 + 命中率×读倍率。可见 Anthropic 1 小时档在命中率 ≤50% 时比不缓存更贵；而 OpenAI/DeepSeek 无写溢价，任何命中率下都不亏。业界经验：稳定前缀负载命中率低于 60% 就是结构问题（多半是动态数据泄漏进前缀），低于 30% 时写溢价会反噬（Vellum/Helicone 生产报告命中率普遍在 50%–80%）。
真实项目实测数据
- 系统提示缓存（10,000 token × 100 次调用）：无缓存 $3.00 → 有缓存 $0.334，节省 89%。
- RAG 文档缓存（50,000 token 手册 × 1,000 次/天）：$150/天 → $18.4/天，每天省 $131。
- 批处理窗口化（10 次请求打包在 5 分钟 TTL 内）：成本从 10.0 单位 → 2.15 单位，节省 78.5%。
- 真实博客自动化系统：CLAUDE.md（约 10k token）每天复用 30+ 次，输入成本降约 65%，月度 API 支出从 $40–60 降至 $15–20。
- ProjectDiscovery 案例：把动态「工作记忆」从系统提示移到末尾用户消息，命中率从 7% 飙到 84%，整体 LLM 成本降 59%，98 亿 token 改由缓存服务。
延迟收益
缓存命中跳过 Prefill 阶段，首 token 时延（TTFT）大幅下降——Amazon Bedrock 官方数据称缓存命中响应速度最高提升 85%；语义缓存层命中时 P50 延迟是个位数毫秒（对比全量推理 1–5 秒）。代价权衡也真实存在：Anthropic 1 小时档写溢价高，naive full-context caching 反而可能抬高延迟，所以缓存边界必须刻意设计。
总结与未来展望
Prompt Caching 是 2026 年生产级 LLM 工程里杠杆率最高的单一成本优化手段：它不改变模型、不降输出质量，只是把重复计算的前缀 KV 状态跨请求复用，就能砍掉 50%–90% 的输入成本。你真正需要掌握的三件事：前缀保持字节级稳定并按稳定性排序、根据写溢价与 TTL 选对厂商与档位、用 usage 字段持续监控命中率——做到这三点，命中率 60%–90% 是可设计、可验证的工程目标。展望未来，缓存正从「前缀匹配」走向「语义匹配」（vCache 等方案已能按相似度命中并给出错误率保证），与模型路由、语义缓存叠加后，多模型时代的成本结构会进一步分化；而 DeepSeek 把 KV 状态压缩落盘带来的「缓存近乎免费」，也预示着长上下文应用的定价范式正在被重写。
延伸阅读
- Anthropic 官方 Prompt Caching 文档与 4 断点机制详解
- OpenAI 官方 Prompt Caching 指南与 GPT-5.6 显式断点规范
- DeepSeek 上下文硬盘缓存官方文档与命中规则
- 《Don't Break the Cache》：面向长周期 Agent 任务的提示词缓存评估论文
- LLM 推理：首 token 时延优化与 System Prompt Caching 知乎深度解析
文章标签：Prompt Caching、提示词缓存、LLM 成本优化、KV Cache、上下文工程、Anthropic、OpenAI、DeepSeek、模型路由、Agent 成本控制