Prompt Caching提示缓存加速与降本

可视化演示

通过二维投影展示词向量的语义聚类关系，选中单词可查看与其语义最近的邻居词及余弦相似度。

缓存工作原理

夜晚十一点，面馆后厨的灯还亮着。老板发现，每天最耗时的不是煮面，而是熬汤——葱姜爆香、猪骨焯水、文火慢炖，两小时起跳。于是他改成清晨统一熬一大锅高汤，客人点单时，后厨只需要舀汤、下面、加料。Prompt Caching 就是大模型 API 的“高汤策略”：既然你每次都发送同样的系统提示词和历史对话，为什么每次都要从头“熬”一遍？

大模型读到一段 Prompt，并不是“看一遍”就完事——它要把每个 Token 都编码成一堆中间状态（业内称为 KV Cache，你可以把它想象成“熬好的汤底”），然后才能开始生成回答。Prompt 越长，这锅“汤”熬得越久、越贵。提示缓存的原理，正是把这锅“汤底”暂存在服务端：下一次请求到来时，API 先检查开头部分是否与缓存前缀逐 Token 完全一致，且是否还在保鲜期（TTL）内。两个条件都满足，就直接复用“汤底”，只对新出现的尾巴做计算——首 Token 延迟（TTFT，即从发出请求到收到第一个字的耗时）大幅下降，费用也按缓存价结算。

反过来，只要前缀里多了一个空格、改了一个字，或者间隔太久，那锅汤就得倒掉重熬——这就是“缓存未命中”，一切按原价、原延迟计算。所以，面馆最爱“老顾客点老配方”；API 缓存也最爱“同一前缀反复请求”。

成本节省模型

打烊后，老板算了一笔账：如果每碗面都从零熬汤，光汤底成本就要 3 元；清晨批量熬好，复用一次汤底只要 1.5 元。省下的 1.5 元，就是“不重复劳动”的奖励。API 账单里同样有这行奖励：命中的输入 Token 只按折扣价计费，未命中的部分仍是原价。

以 OpenAI 为例（GPT-4o 系列）：标准输入约 $2.5/百万 Token，命中后的缓存输入 $1.25/百万 Token，相当于五折；Anthropic 则把价格拆成“写缓存”（原价 1.25 倍）和“读缓存”（原价 0.1 倍）两笔——头一次写入稍贵，之后每次读取只要一折。要量化到底能省多少钱，可以把复杂的价格规则抽象成两个数字：命中比例和折扣力度。

设 $h$ 为本批请求中命中缓存的 Token 占比，$d$ 为命中价折扣（命中价 ÷ 原价），那么实际输入费用是：

举个例子：某请求输入 8000 Token，其中 6000 是稳定前缀（$h=75\%$），缓存五折，调用 1000 次、输入单价 $3/百万 Token$。无缓存总费用是 $24 美元；启用缓存后只需 $15 美元，整整省下 37.5%。换句话说，你的“面钱”越来越接近“只买配料”的价钱。

主流厂商支持

同样是“高汤策略”，各家面馆的规矩完全不同：有的老板内向，默默在后厨备好汤，客人不用打招呼（OpenAI）；有的老板要求你提前“订锅”，才给你留汤（Anthropic）；还有的老板只在汤量足够大时才批量熬（Gemini）。

OpenAI 提供自动缓存：无需改任何代码，只要 Prompt 总长 ≥ 1024 Token，且前缀在约 5-10 分钟的滑动窗口内重复出现，命中部分就自动按折扣价计费。Anthropic 提供显式缓存：必须在系统提示词或消息中通过 cache_control 断点“预订汤底”，写缓存按原价 1.25 倍、读缓存按 0.1 倍计费，TTL 可选 5 分钟或 1 小时。Gemini 则是隐式缓存：当前缀足够长（数万 Token 级别）时自动生效，开发者几乎无感知。

各家定价可以统一写成如下分段函数：

选哪家面馆，取决于你的点单习惯：整天点一样的招牌面，显式“订锅”反而更省钱；点单天马行空，自动备汤更省心。理解各家计费差异，是把缓存红利吃到嘴里的第一步。

最佳实践方法

想让“高汤”次次都能被复用，最笨也最有效的办法是：别换汤底配方。把稳定的东西（系统提示词、示例、背景资料）放在 Prompt 最前面，把每次都变的东西（新问题、动态参数）放到最后——后厨才能精准地“只加料，不换汤”。

具体做法有四条：第一，系统提示词、few-shot 示例、知识库背景统一放在 Prompt 头部，逐字保持不变；第二，别在系统提示词里塞“当前时间”“随机 ID”这类动态内容，它们会让整锅汤失效；第三，多轮对话中，把历史消息按固定顺序拼在前部，最新的用户问题放在尾部；第四，批量任务用同一个模板加不同的末尾参数，模板天然成为可复用的前缀。

要判断你的 Prompt 能否吃上缓存，只需核对下面三个条件是否同时成立：

面馆的招牌之所以畅销，是因为老板十年不换配方；你的 Prompt 结构稳定，缓存命中率自然水涨船高。这套“稳定置前、变化置后”的布局，就是提示缓存时代的 Prompt 排版美学。

缓存监控调优

老板每天打烊都要翻账本：今天多少碗面复用了汤底？复用率低了，是配方换了，还是客人间隔太久？API 的返回结构里，也藏着同样的“账本”，只看你愿不愿意翻开。

OpenAI 在 usage.prompt_tokens_details 中返回 cached_tokens（命中缓存的 Token 数）；Anthropic 在 usage 中返回 cache_read_input_tokens 和 cache_creation_input_tokens（读取与写入的 Token 数）。把这些字段接入日志系统，就能逐日统计缓存命中率、节省金额，形成一张成本看板。

命中率的定义非常朴素——复用“汤底”的 Token 占总输入的比例：

账本不会说谎。命中率就是“后厨高汤复用率”，盯住它，你的成本优化就有了仪表盘；一旦发现它走低，立刻回到上一节检查 Prompt 结构。

适用场景展望

不是所有菜都适合提前熬汤——凉拌菜不用汤，一天只卖两碗的面也不值得备一大锅。缓存也一样，只在“底味稳定、出菜量大”的场景才划算。

高价值场景有三类：一是多轮对话机器人，历史消息是天然稳定前缀，用户每追问一轮都能命中；二是批量文档审核或翻译，同一套“审核标准”模板加每篇不同的文档，模板就是高汤；三是长文档与代码库问答，超大上下文被反复提问，命中的前缀极长，节省最明显。反过来，一次性随机问答、前缀经常变化、两次请求间隔超过 TTL 的场景，缓存帮不上忙。

对 Anthropic 式“写缓存要加价”的计费，可以算一笔回本账。设同一前缀被请求 $N$ 次：第一次写入付 1.25 倍原价，之后每次读取付 0.1 倍；而不用缓存的话，每次都是全价：

聪明的面馆只给招牌菜备汤底，聪明的工程师只为高复用前缀开缓存。先算清复用次数，再决定要不要“开锅”——这是提示缓存时代的成本铁律。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""模拟提示缓存(Prompt Caching)的成本节省: 对比有/无缓存的输入费用"""  class TokenCache:    """模拟大模型API的前缀缓存, 统计命中率与费用"""     def __init__(self, price=3.0, cached_price=1.5):        self.price = price                 # 普通输入价: $3 / 百万 Token        self.cached_price = cached_price   # 命中输入价: $1.5 / 百万 Token        self.cached_prefix = None          # 当前缓存的前缀内容        self.hit_count = 0                 # 命中次数        self.miss_count = 0                # 未命中次数     def request(self, total_tokens, prefix_tokens):        """发起一次请求: total_tokens 为输入总数, prefix_tokens 为稳定前缀"""        prefix = "P" * prefix_tokens        if self.cached_prefix == prefix:            self.hit_count += 1            hit = prefix_tokens            # 命中的 Token 数        else:            self.miss_count += 1            self.cached_prefix = prefix            hit = 0                        # 首次写入, 全部按原价        miss = total_tokens - hit        return (miss * self.price + hit * self.cached_price) / 1e6  def main():    cache = TokenCache()    # (总输入Token, 稳定前缀Token)  第二项为0表示前缀彻底变化    tasks = [(5000, 4000), (5400, 4000), (5100, 4000),             (5300, 4000), (6000, 0), (5200, 4000)]    total = 0.0    for total_tokens, prefix_tokens in tasks:        total += cache.request(total_tokens, prefix_tokens)    calls = cache.hit_count + cache.miss_count    hit_rate = cache.hit_count * 1.0 / calls    no_cache = sum(t * cache.price / 1e6 for t, _ in tasks)    print("请求次数: %d, 缓存命中率: %.1f%%" % (calls, hit_rate * 100))    print("无缓存费用: $%.4f" % no_cache)    print("使用缓存费用: $%.4f" % total)    print("节省金额: $%.4f (%.1f%%)" % (no_cache - total,          (1 - total / no_cache) * 100))  if __name__ == "__main__":    main()

1. class TokenCache:定义一个模拟缓存器的类，等价于“面馆后厨的汤底管理台账”
2. if self.cached_prefix == prefix:判断新请求前缀与缓存前缀是否逐字一致（命中判定）
3. self.hit_count += 1命中后记录一次“复用汤底”的账，后面用来算命中率
4. hit = 0 # 首次写入, 全部按原价没命中就重新熬汤，本次前缀按原价计费
5. return (miss * self.price + hit * self.cached_price) / 1e6按“未命中原价 + 命中折扣价”折算成美元返回单次费用
6. tasks = [(5000, 4000), (5400, 4000), (5100, 4000),模拟 6 次真实请求：总输入在变，但前缀稳定在 4000 Token；第 5 次前缀为 0，模拟一次“换汤底”
7. no_cache = sum(t * cache.price / 1e6 for t, _ in tasks)计算不使用缓存时的全价账单，作为对比的基准线
8. print("节省金额: $%.4f (%.1f%%)" % (no_cache - total,输出最终省下的“面钱”和节省率

常见误区

面试题