上下文缓存是什么：重复发送的提示词前缀可以便宜很多

如果每次请求的开头都是同一段长内容，比如系统提示词、产品手册、工具定义，支持上下文缓存的模型会把这段前缀存起来。下次遇到相同的前缀，命中的部分按「缓存读取价」计费。以 gpt-5.4-mini 为例，普通输入是 ¥1.5 / 百万 tokens，缓存读取只要 ¥0.15。固定前缀越长、调用越频繁，省得越多。

缓存是怎么工作的

模型读提示词时，要对每个 token 做一遍计算。两次请求开头的一大段如果完全相同，第二次就能直接复用第一次算好的结果，省下来的计算体现在价格上。

所以缓存按「前缀」匹配：从第一个 token 起逐字相同的部分才算命中。中间改了一个字，这个字之后的内容就都命中不了。

各家模型的缓存方式

表里是各家公开的一般规则，最小长度、有效期这些细节会调整，以各模型的官方说明为准。一个模型有没有缓存价，在模型与价格里看它的「缓存读取」列就知道。

看懂缓存价格

下面是 Claude Sonnet 5.5 在各分组的价格：

它在最低价分组的缓存写入价是 ¥4 / 百万 tokens，比普通输入高，但之后每次命中都只按缓存读取价计费。同一段前缀被复用的次数越多，越划算。

其他几个常用模型的普通输入价和缓存读取价（每百万 tokens，最低价分组）：

• deepseek-v4.1-flash：输入 ¥2.8，缓存读取 ¥0.056
• gemini-3.8-flash：输入 ¥1.5，缓存读取 ¥0.15
• gpt-5.5：输入 ¥10，缓存读取 ¥1

能省多少：算一笔账

一个客服机器人，每次请求里系统提示词加产品资料固定 6,000 tokens，用户问题和最近几轮对话约 1,000 tokens，回答约 400 tokens，每月 10 万次。

不命中缓存：

固定的 6,000 tokens 全部命中缓存：

实际命中率到不了 100%。缓存过期、前缀被改动，都会让一部分请求按原价计费。上线后用 usage 里的缓存 tokens 算出真实命中率，再按它做预算。

怎么写提示词才容易命中

1. 不变的放前面，变化的放最后。推荐顺序：系统提示词、工具定义、固定资料、历史对话、本次问题。
2. 系统提示词里不要放当前时间、请求编号、用户名这类每次都变的值。确实需要，就放进最后一条用户消息。
3. 工具定义和示例的顺序保持固定，序列化 JSON 时字段顺序也要固定。
4. 同类请求集中发送。缓存有有效期，长时间没被命中就会清除，重新写入又要付一次费。
5. Claude 需要显式标记：把 cache_control 加在固定内容的最后一个块上。

import os
import anthropic

client = anthropic.Anthropic(base_url="https://open.tutujin.com", api_key=os.environ["TUTUJIN_API_KEY"])

with open("product_manual.md", encoding="utf-8") as f:
    manual = f.read()  # 几千 tokens 的固定资料

resp = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=1024,
    system=[
        {"type": "text", "text": "你是产品客服，只根据下面的手册回答。"},
        {"type": "text", "text": manual, "cache_control": {"type": "ephemeral"}},
    ],
    messages=[{"role": "user", "content": "保修期多久？"}],
)
print(resp.usage.cache_creation_input_tokens, resp.usage.cache_read_input_tokens)

第一次请求写入缓存，cache_creation_input_tokens 有值；有效期内的后续请求命中缓存，cache_read_input_tokens 有值。

确认是否命中

通过 OpenAI 兼容接口调用其他厂商的模型时，缓存字段返回与否取决于具体模型。每次请求实际扣了多少，以控制台「用量明细」为准。缓存之外的省钱办法见如何控制 API 成本。