Prompt Cache 指南：OpenAI、Anthropic 与 DashScope 的成本优化策略

Prompt Cache 让你能够复用已处理的输入 Token，使供应商跳过重复前缀的冗余计算。结果是更低的延迟和更便宜的输入成本——在某些供应商上最高可节省 90%。目前所有主流 LLM API 都支持某种形式的 Prompt Cache，但各家的机制、价格乘数、TTL 和最小 Token 阈值差异足够大，选错策略的代价可能比不用缓存还高。

我们写这篇指南，是因为我们每天将请求路由到 OpenAI、Anthropic 和阿里云百炼（DashScope），缓存经济学直接影响哪个供应商-模型组合能提供最优的单次请求成本。这是我们最初在路由配置中优化输入成本时想要的跨供应商缓存参考。

来源：OpenAI Prompt Caching 文档，检索于 2026-06-17；Anthropic Prompt Caching 文档，检索于 2026-06-17；DashScope 上下文缓存文档，检索于 2026-06-17。

---

30 秒理解 Prompt Cache 的工作原理

当你向 LLM API 发送 Prompt 时，模型会对每个输入 Token 进行分词和计算。如果你的 Prompt 中有很大一部分——系统指令、代码仓库、文档——在多次请求中完全相同，供应商就可以缓存中间计算结果（注意力层的 key/value 张量）并复用。后续共享相同前缀的请求会跳过该计算，同时降低延迟和有效 Token 价格。

关键细节：缓存是基于前缀的。只有 Prompt 的开头部分可以被缓存。如果可变部分（如用户问题）在静态部分（如系统 Prompt）之前，缓存不会触发。将静态内容放在前面，动态内容放在后面。

OpenAI 兼容指供应商提供一个 chat-completions 接口，其请求与响应结构与 OpenAI API 契约足够接近——只需替换三个值（API key、base URL、模型名），原来的 OpenAI SDK 调用即可直接工作。最小实践面是POST /v1/chat/completions 带 messages、model， 并返回 OpenAI 形式的流式响应。

---

OpenAI：自动缓存与扩展保留

OpenAI 的 Prompt Cache 完全自动——不需要修改代码。任何 1,024 Token 以上的 Prompt 都符合条件。系统将请求路由到最近处理过相同前缀的服务器，匹配的前缀从缓存中提供。

关键参数：

• 最小 Token 数： 1,024
• 机制： 自动前缀匹配，基于哈希的路由
• 保留策略：
  • 内存缓存： 不活跃 5–10 分钟后过期，最长 1 小时。适用于 GPT-4.1 及更新模型。
  • 扩展缓存（24 小时）： 最长 24 小时。适用于 GPT-4.1、GPT-5、GPT-5.1 系列、GPT-5.2、GPT-5.4、GPT-5.5。非 ZDR 组织在支持的模型上默认启用。
• 价格折扣： 缓存输入 Token 按缓存费率计费。GPT-5.5：缓存 $0.50/MTok vs 标准输入 $5.00/MTok（90% 折扣）。GPT-5.4：缓存 $0.25/MTok vs 标准 $2.50/MTok（90% 折扣）。
• prompt_cache_key 参数： 可以将用户提供的 key 与前缀哈希组合，提高缓存命中率。保持每个唯一组合的请求低于约 15 RPM 以避免缓存溢出。

来源：OpenAI Prompt Caching 文档，检索于 2026-06-17；OpenAI API 定价，检索于 2026-06-17。

代码示例：OpenAI 自动缓存

from openai import OpenAI

client = OpenAI()  # 使用 OPENAI_API_KEY 环境变量

# 静态系统 Prompt——放在最前面以命中缓存
SYSTEM_PROMPT = """你是一位专业的代码审查专家。请分析以下仓库中的安全漏洞、
性能问题和代码风格问题。仓库内容如下：

{repository_contents}
"""  # 实际仓库内容会超过 1024 Token

response = client.chat.completions.create(
    model="gpt-5.4",
    prompt_cache_retention="24h",  # 请求扩展保留
    messages=[
        {"role": "system", "content": SYSTEM_PROMPT},
        {"role": "user", "content": "重点检查认证模块。"},
    ],
)

# 检查缓存性能
usage = response.usage
cached = usage.prompt_tokens_details.cached_tokens
total_input = usage.prompt_tokens
print(f"缓存命中: {cached}/{total_input} tokens ({cached/total_input*100:.0f}%)")

不需要特殊标注。第二次发送相同系统 Prompt 前缀的请求时，cached_tokens 将不为零。

---

Anthropic：显式 cache_control 与双 TTL 层级

Anthropic 通过 cache_control 字段提供开发者控制的缓存。你可以选择自动缓存（系统选择最优断点）或显式断点（你标记哪些内容块需要缓存）。创建缓存有成本，但读取有大幅折扣。

关键参数：

• 最小 Token 数： 1,024（工具/消息块）
• 机制： 内容块上的显式 cache_control 标注，或顶层自动模式
• TTL 选项：
  • 5 分钟（ephemeral）： 默认。每次缓存命中重置 5 分钟计时器。缓存写入成本为标准输入价格的 1.25 倍。
  • 1 小时： 可选。缓存写入成本为标准输入价格的 2 倍。适用于 Anthropic API 和 Amazon Bedrock 上的 Claude 模型。
• 缓存读取价格： 标准输入价格的 10%（90% 折扣）。Claude Opus 4.8：读取 $0.50/MTok vs 标准 $5.00/MTok。
• 最大断点数： 每个请求最多 4 个 cache_control 标记。

来源：Anthropic Prompt Caching 文档，检索于 2026-06-17；Anthropic 定价，检索于 2026-06-17。

代码示例：Anthropic 显式缓存

import anthropic

client = anthropic.Anthropic()

# 自动缓存——系统将断点应用于最后一个可缓存块
response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    cache_control={"type": "ephemeral"},  # 顶层：自动模式
    system="你是一位专业的代码审查专家。请分析以下仓库中的安全漏洞、"
           "性能问题和代码风格问题。[大量仓库内容]",
    messages=[
        {"role": "user", "content": "重点检查认证模块。"},
    ],
)

print(response.usage)
# 输出：cache_creation_input_tokens, cache_read_input_tokens, input_tokens

细粒度控制方式——在单独的内容块上放置 cache_control：

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "[大量静态内容——仓库、文档等]",
            "cache_control": {"type": "ephemeral"},  # 显式断点
        }
    ],
    messages=[
        {"role": "user", "content": "存在哪些安全问题？"},
    ],
)

Anthropic 缓存什么时候反而更贵

缓存写入不是免费的。在 5 分钟 TTL 下，你在创建缓存时支付标准输入价格的 1.25 倍。如果你的请求间隔超过 5 分钟未能复用缓存，你就白付了写入溢价。盈亏平衡点：如果命中率低于约 15%，你付出的比不用缓存更多。监控 cache_creation_input_tokens 与 cache_read_input_tokens 来验证节省效果。

---

DashScope：显式与隐式上下文缓存

阿里云百炼（DashScope）提供两种缓存模式。两者都可通过 OpenAI 兼容 API 使用：

显式缓存：

• 最小 Token 数： 1,024
• TTL： 5 分钟（命中后重置）
• 缓存写入成本： 标准输入价格的 125%
• 缓存读取成本： 标准输入价格的 10%（90% 折扣）
• 最大断点数： 每个请求 4 个
• 支持模型： qwen3.7-max、qwen3.6-max-preview、qwen3-max、qwen3.7-plus、qwen3.6-plus、qwen3.5-plus、qwen-plus、qwen3.6-flash、qwen3.5-flash、qwen3-coder-plus、qwen3-vl-plus、deepseek-v3.2、kimi-k2.6、kimi-k2.5、glm-5.1 等。

隐式缓存（自动）：

• 最小 Token 数： 256
• TTL： 不确定——系统定期清理长期未使用的缓存
• 缓存写入成本： 标准输入价格的 100%（无溢价）
• 缓存读取成本： 标准输入价格的 20%（80% 折扣）
• 始终开启： 无法关闭，自动应用于所有请求。

显式和隐式缓存在同一请求中互斥——如果设置了 cache_control，只有显式模式生效。

来源：DashScope 上下文缓存文档，检索于 2026-06-17；DashScope 定价，检索于 2026-06-17。

代码示例：DashScope 显式缓存（OpenAI 兼容）

from openai import OpenAI

client = OpenAI(
    api_key="sk-xxx",  # DashScope API Key
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
)

LONG_SYSTEM_CONTENT = "[大量文档、代码或上下文——必须 ≥1024 Token]"

response = client.chat.completions.create(
    model="qwen3.7-max",
    messages=[
        {
            "role": "system",
            "content": [
                {
                    "type": "text",
                    "text": LONG_SYSTEM_CONTENT,
                    "cache_control": {"type": "ephemeral"},
                }
            ],
        },
        {"role": "user", "content": "总结关键发现。"},
    ],
)

# 检查缓存 Token
details = response.usage.prompt_tokens_details
print(f"缓存创建: {details.cache_creation_input_tokens}")
print(f"缓存命中: {details.cached_tokens}")

DashScope OpenAI 兼容端点返回的 cache_creation_input_tokens 和 cached_tokens 与 OpenAI 相同的字段结构——所以在供应商之间切换不需要修改响应解析代码。

---

跨供应商对比

核心要点：

• OpenAI 最简单：无需代码修改，自动前缀检测，GPT-5+ 模型的 24 小时扩展保留意味着缓存在长时间开发会话中持续有效。
• Anthropic 控制力最强：显式断点让你精确控制缓存内容，但写入溢价意味着你需要稳定的请求模式才能回本。
• DashScope 在高命中率场景下性价比最高：显式模式 10% 的读取成本与 Anthropic 持平，隐式模式 20% 的读取成本零配置即可享受。

---

最大化缓存命中率的路由策略

在多供应商路由时，缓存亲和性至关重要。一个在供应商 A 命中缓存的请求如果被路由到供应商 B，整个缓存投入就浪费了。考虑以下策略：

1. 可缓存工作负载的供应商粘性路由

将对话或工作负载类型固定到单个供应商。如果你的系统 Prompt 有 10K Token，每次切换供应商都会在新供应商上产生冷启动缓存未命中。一次缓存未命中的成本可能超过替代供应商更便宜的单价节省。

2. Prompt 前缀排序规则

将静态内容放在前面，可变内容放在后面。这一规则普遍适用：

• 系统指令 → 可缓存
• Few-shot 示例 → 可缓存
• 工具定义 → 可缓存
• 对话历史 → 部分可缓存（每轮增长）
• 当前用户消息 → 不可缓存

3. 缓存感知的模型选择

当你的应用使用长系统 Prompt（>10K Token）时，支持扩展缓存保留的模型价值不成比例地增加。一个 $5/MTok 输入但有 24 小时缓存的模型，有效 Token 成本可能比 $2/MTok 但只有 5 分钟缓存的模型更低。

4. 监控缓存性能

按供应商跟踪以下指标：

• 缓存命中率： cached_tokens / total_input_tokens
• 有效输入成本： (未缓存 Token × 标准费率 + 缓存 Token × 缓存费率 + 写入 Token × 写入费率) / 总 Token
• 缓存 ROI： 将有效输入成本与无缓存基线进行比较

---

成本建模：什么时候缓存省钱

缓存不是免费的。在 Anthropic 和 DashScope 显式模式下，缓存写入溢价意味着每次缓存创建的成本高于标准输入。只有后续请求命中缓存的频率足够高，才能摊销写入成本。

盈亏平衡公式（Anthropic 5 分钟 ephemeral）：

• 写入成本：标准输入的 1.25 倍
• 读取成本：标准输入的 0.10 倍
• 基准成本（无缓存）：标准输入的 1.00 倍

对同一前缀的 N 次请求，缓存总成本 = 1.25 + 0.10 × (N - 1)。无缓存总成本 = 1.00 × N。缓存盈亏平衡点：

1.25 + 0.10(N - 1) < N → N > 1.28

所以只要 2 次请求命中缓存，Anthropic 显式缓存就开始省钱。约束条件是 5 分钟 TTL——如果你的请求间隔超过 5 分钟，缓存过期，你又要支付写入溢价。

OpenAI 自动缓存没有写入溢价，所以每次缓存命中都是纯节省。唯一风险是低命中率（前缀分散或缓存被淘汰）。

DashScope 隐式缓存也没有写入溢价，任何缓存命中节省 80%。这是最安全的默认模式。

---

TheRouter 集成：缓存感知工作负载的路由考虑

TheRouter 将 OpenAI 兼容请求路由到配置的供应商，并在产品路径支持的情况下提供供应商/模型路由和回退。对于缓存敏感的工作负载，注意以下几点：

• 供应商亲和性： 当工作负载受益于 Prompt Cache 时，将路由配置为倾向一致的供应商，而非在供应商之间轮询。每次切换供应商都会重置缓存。
• 回退成本感知： 如果主供应商宕机，TheRouter 回退到备选供应商时，第一个请求将是缓存未命中。在高可用配置的成本预测中要考虑这一点。
• 模型别名： 当 DashScope 和 OpenAI 都提供支持缓存的同类模型时，缓存经济学（写入溢价、TTL、读取折扣）可能不同。评估每次请求的有效成本，而非单纯的单价。

更多回退路由架构细节，请参见我们的 LLM API 回退路由指南。

---

生产清单

部署 Prompt Cache 到生产环境前：

• 测量基准成本 ——记录至少 100 个代表性请求的 prompt_tokens 和 completion_tokens
• 重构 Prompt ——将静态内容（系统指令、示例、工具定义）移到前面；将可变内容放在最后
• 选择显式或自动 ——OpenAI 用自动模式简单省事；Anthropic/DashScope 用显式模式需要保证断点
• 设置保留策略 ——在 OpenAI 上对长会话启用 prompt_cache_retention: "24h"；在 Anthropic 上对批处理工作负载考虑 1 小时 TTL
• 监控缓存指标 ——跟踪 cached_tokens、cache_creation_input_tokens 和每次请求的有效成本
• 测试缓存失效 ——验证 Prompt 变更（系统指令、工具定义）能正确使陈旧缓存失效
• 计算 ROI ——确认命中率超过所选供应商写入溢价的盈亏平衡阈值
• 检查供应商路由 ——确保路由配置为可缓存工作负载保持供应商亲和性

---

常见问题

Q：Prompt Cache 会影响输出质量吗？ 不会。缓存只复用输入处理的中间计算（key/value 张量）。模型为每个请求生成新的输出。缓存和非缓存请求产生完全相同的结果。

Q：可以缓存工具定义吗？ 可以，三家供应商都支持。工具定义是 Prompt 前缀的一部分，可以被缓存。在 OpenAI 上自动缓存。在 Anthropic 和 DashScope 上，将工具定义放在 cache_control 断点之前。

Q：缓存数据在组织间共享吗？ 不会。OpenAI 的缓存按组织隔离。Anthropic 的缓存按 API Key 隔离。DashScope 的缓存按工作空间隔离。

Q：如果修改了缓存前缀中的一个 Token，会怎样？ 从修改点开始缓存未命中。Prompt Cache 是精确前缀匹配——对缓存部分的任何修改都会使匹配失效。修改点之前未变化的部分在某些供应商上可能仍然匹配。

Q：哪个供应商的缓存最适合 Agent 工作负载？ Agent 工作负载（多轮对话、重度工具调用）最受益于扩展 TTL，因为工具调用会产生往返延迟。OpenAI 的 24 小时扩展保留在这里最强。Anthropic 的 5 分钟默认值在工具调用能在窗口内完成时也可用。DashScope 的 5 分钟显式缓存也会在命中时重置，适合快速多轮交互。

更多供应商接入细节，请参见我们的指南：阿里云百炼 API 指南、DeepSeek API 指南、OpenAI 兼容 API 供应商、OpenAI 迁移到 TheRouter 指南。