关于缓存与成本优化

什么是 Prompt Caching？

当你发送包含大量固定上下文（如系统提示词、知识库）的请求时，模型会将这部分内容缓存起来。后续请求如果复用了相同的上下文，就可以直接读取缓存，无需重新计算。

缓存命中率 = 缓存读取的 token 数 ÷ 总输入 token 数 × 100%

缓存命中的好处：

• 降低延迟：跳过已缓存部分的处理，首字响应更快
• 降低成本：缓存读取的 token 按更低价格计费（通常为原价的 10%-25%）

哪些模型支持 Prompt Caching？

不同模型对 Prompt Caching 的支持程度并不完全一致，建议以控制台说明、实际返回结果和上游模型能力为准。

当前建议：

如何提升缓存命中率

1. 固定前缀，动态内容放在后面

{
  "messages": [
    {"role": "system", "content": "【固定的系统提示词，2000字...】"},
    {"role": "user", "content": "【用户的动态问题】"}
  ]
}

system prompt 保持不变 → 缓存命中；user message 每次不同 → 正常计费。

2. 合理设置缓存断点

将大段固定内容放在 messages 的前面几条，动态内容放在后面。模型从头开始匹配缓存，遇到不同内容时停止。

3. 控制请求间隔

缓存有有效期（通常 5-10 分钟）。如果两次请求间隔过长，缓存可能已过期。对于高频调用场景，缓存命中率自然更高。

4. 统一模板，避免微小差异

以下两个请求不会命中缓存：

• "你是一个专业的助手。"
• "你是一个专业的助手 "（多了空格）

即使内容几乎相同，任何字符差异都会导致缓存失效。建议使用统一的 prompt 模板。

5. 复用同一模型和 API 密钥

不同模型之间不共享缓存。同一模型 + 同一前缀 = 最高命中率。

其他成本优化建议

选择合适的模型

不是所有任务都需要最强模型：

控制 max_tokens

设置合理的 max_tokens 避免模型生成过长的无用内容。例如，如果你只需要"是/否"的判断，设 max_tokens: 10 就够了。

精简 system prompt

过长的 system prompt 会增加每次请求的输入 token 成本。保持 prompt 精炼，去掉不必要的描述。