提示缓存省钱实战：同样效果，账单砍掉70%

📅 2026/9/21 ✍️ 小文 📖 约 1 分钟

当你的系统提示、知识库前缀、few-shot示例每次都在重复付费时，提示缓存是立竿见影的降本手段。本文讲原理、适用条件与工程改造。

做 AI 应用的团队常有个隐形浪费：每次调用都在为同样的内容重复付费。 你的系统提示词有两千字，知识库前缀有一千 token，few-shot 示例又是几百 token——这些内容每次请求都一样，却被反复计费。提示缓存（Prompt Caching）就是来解决这个问题的。

一、提示缓存的原理

大模型推理时，处理输入是分阶段的。缓存机制的核心思想是：把不变的输入前缀的结果缓存起来，下次请求如果前缀完全相同，就直接复用，只对新增的部分做计算。

效果体现在两块：

  • 成本：缓存命中的 token 通常按原价的 10%~25% 计费，甚至更低。
  • 延迟：跳过前缀计算，首 token 响应时间显著缩短。

二、什么样的内容适合缓存

判断标准只有一条：在多轮或多次请求中稳定复现，且足够长。

典型的可缓存内容：

  1. 冗长的系统指令（角色设定、输出规范、安全规则）；
  2. 固定的知识库或文档前缀；
  3. 多轮对话里不变的 few-shot 示例；
  4. RAG 场景中作为公共前缀的模板与指令。

不适合缓存：每次都变的用户输入、动态拼接的中间结果。

三、关键约束：前缀必须逐字节一致

这是最容易翻车的地方。缓存命中要求从开头到缓存点完全一致——哪怕多一个空格、改一个标点，都会导致未命中。因此工程上要注意：

  • 把可变内容放在最后，不变内容放在最前；
  • 不要在系统提示里塞入带时间戳、随机数、会话 ID 的内容；
  • 拼接提示时用统一的模板函数，避免各处手写导致格式漂移。

四、改造示例

改造前（每次全量重复计费）：

prompt = (
    "你是客服助手，规则如下……（2000字）…\n"
    "知识库：" + full_kb + "（3000字）\n"      # full_kb 很长
    "用户问题：" + question
)

改造后（不变部分置前，显式标记缓存点）：

messages = [
    {"role": "system", "content": SYSTEM_RULES},          # 稳定，可缓存
    {"role": "system", "content": KB_PREFIX,              # 稳定，可缓存
     "cache_control": {"type": "ephemeral"}},
    {"role": "user", "content": question},                # 动态，放最后
]

多数主流 API 通过在内容的最后一个块上打 cache_control 标记来指定缓存边界。标记点之后的内容才会逐次计费。

五、算一笔账

假设每次请求固定前缀 4000 token，动态部分 500 token，每天 2 万次调用：

  • 无缓存：4500 × 20000 = 9000 万 token/天
  • 有缓存（前缀按 10% 计费）：(4000×0.1 + 500) × 20000 = 1800 万 token/天

成本直接降到原来的 20%。 对固定场景的应用，账单砍掉 70%~80% 是常态。

六、三个实施建议

1. 监控命中率。 缓存的价值全在命中率。上线后必须埋点统计，命中率低于 60% 说明前缀不够稳定，要回头查拼接逻辑。

2. 注意缓存有效期。 缓存通常有 TTL（几分钟到几小时），低频调用可能每次都失效。高频场景收益最大。

3. 和安全策略协同。 不要把敏感数据放进可缓存前缀——需确认厂商的隔离机制。

结语

提示缓存是 AI 成本优化里投入产出比最高、改造量最小的一招：不用换模型、不用重训，只需把提示词结构重排一下、加个标记。如果你还没做，今天就该去查你的账单里有多少是”重复前缀税”。

🏷️ #提示缓存#成本优化#LLM API#工程实践#Token
📤 分享到