用提示缓存省成本

什么是提示缓存

当你调用 LLM API 时，模型需要先「读取」你发送的全部输入内容，再生成回复。对于长对话，每次请求都会带上完整的历史消息和系统提示，其中大部分内容与上一次请求完全相同。模型每次都要重新处理这些重复部分，既耗时也耗费 token。

提示缓存（Prompt Caching）就是让服务端把请求中重复的前缀部分暂时保存下来。当下一次请求包含相同前缀时，模型可以直接复用已缓存的计算结果，只处理新增的内容。

为什么长多轮对话需要它

多轮对话的上下文会像滚雪球一样增长。假设第一轮有 1000 token，每轮新增 500 token：

• 第二轮请求携带 1500 token
• 第三轮携带 2000 token
• 第十轮携带 5500 token

如果没有缓存，每次都要完整计费全部输入 token。而其中大部分前缀在之前的轮次中已经处理过。

提示缓存的作用就是把「重复的部分」和「新增的部分」区分开。缓存命中时，重复部分按更低的单价计费，只有新增内容按正常价格计算。

Claude 的缓存机制

Claude 的提示缓存通过显式标记来控制。你可以在请求中指定哪些内容块需要缓存，比如系统提示、工具定义、长文档或前几轮对话。

这种方式的好处是可控：

• 只有被标记的内容才会进入缓存体系
• 缓存有明确的生命周期，过期后自动失效
• 新增内容仍在缓存前缀之后正常处理

对于角色扮演、代码助手、客服机器人这类系统提示很长、对话轮次很多的场景，缓存能明显减少每次请求的实际计费 token 量。

缓存命中与未命中

缓存不是无条件生效的。以下情况会导致未命中：

• 前缀内容发生变化，哪怕只改了一个字
• 请求间隔超过缓存有效期
• 服务端缓存空间紧张，旧缓存被清理
• 不同 API key 或组织之间不共享缓存

因此，设计对话结构时，应尽量把稳定不变的内容放在前面，把频繁变化的内容放在后面。系统提示、任务说明、固定示例属于稳定前缀；用户新输入和动态检索结果属于变化内容。

在聚合站上使用缓存的注意事项

通过聚合站调用模型时，缓存机制由上游模型服务商控制，聚合站负责转发请求。你需要关注两点：

1. 缓存标记要正确传递。如果你在请求中使用了 Claude 的缓存控制字段，确认聚合站不会丢弃或修改它。
2. 计费方式以实际用量为准。聚合站按官方价乘以固定系数扣费，缓存命中的 token 会按上游的缓存价格计算，再乘以相同系数。

换句话说，缓存带来的单价差异会如实反映到你的账单里，不会因为经过聚合层而消失。

如何设计适合缓存的对话

• 把系统提示、角色设定、工具定义放在请求最前面，并标记为可缓存
• 保持这些前缀在整段对话中完全不变
• 不要在系统提示里插入时间戳、随机 ID 等每次都会变的内容
• 把检索到的文档或动态数据放在缓存前缀之后
• 控制对话轮次长度，及时截断或摘要过旧的历史

这些做法不仅提高缓存命中率，也让每次请求的 token 结构更清晰，便于排查成本来源。

小结

提示缓存解决的是长对话中重复前缀的重复计算问题。它不会改变模型能力，但会影响你为多少 token 付费。在长多轮对话场景下，合理使用缓存是控制成本最直接的手段之一。通过聚合站调用时，只要缓存标记正确传递，节省效果同样适用。