Anthropic Prompt Caching 如何将 LLM 成本降低 90%

在生产级 AI 应用的开发过程中，从原型到大规模上线的转变往往伴随着一个令人措手不及的现实：大语言模型（LLM）的实际成本增长速度远超最初演示时的预算。在 n1n.ai，我们经常看到开发者们在面对高频 API 调用带来的账单时感到焦虑。典型的路径是这样的：你发布了一个功能（比如基于 Claude 3.5 Sonnet 的自动化故障根因分析 RCA），起初由于流量较小，账单几乎可以忽略不计。但到了第二个月，随着客户流量的增长，该项开支突然占到了收入的 5%。到了第三个月，财务部门开始询问这是否是“持续性趋势”，而工程团队不得不为八周前在账单还是“零头”时做出的架构决策进行辩护。

然而，这种成本失控是可以缓解的。核心不在于让模型变得多么“聪明”，而在于巧妙地处理请求中保持不变的部分。Anthropic 推出的提示词缓存（Prompt Caching）功能已成为业界的“减收神器”。在我们的 RCA 场景中，它将输入成本从全额费率降低到了十分之一，且缓存命中率稳定在 90% 以上。这不是理论上的推测，而是我们在 n1n.ai 平台上观察到的真实生产数据。

深入理解 Claude 提示词缓存的经济学

要理解这项技术带来的巨大收益，我们首先需要分析 Anthropic 对其核心模型（如 Claude 3.5 Haiku）的定价结构。对于这类高频分析模型，API 费用被细分为四个维度：

从这张表中可以读出两个关键点：首先，缓存读取比基础输入便宜 10 倍。同样的 Token，只要命中缓存，成本直接打一折。其次，缓存写入比基础输入贵 25%。这意味着，当你第一次将一段 Prompt 存入缓存时，你实际上是支付了一笔小额的“溢价”，以换取后续请求的巨额折扣。数学上的平衡点大约是 1.25 次——也就是说，如果在 5 分钟的生存时间（TTL）内，你的相同 Prompt 被调用了超过 1.25 次，你就开始省钱了。如果你的调用模式是完全随机且低频的“冷启动”，那么缓存反而会增加你的开销。因此，获胜的关键在于构建可重复的 Prompt 结构。

RCA 提示词的解构：哪些部分可以缓存？

一个典型的根因分析（RCA）请求通常包含五种 Token 来源。在使用 n1n.ai 调用 API 时，识别哪些是静态的、哪些是动态的至关重要：

1. 系统提示词 (System Prompt)：定义模型角色（如“你是一名资深 SRE”）、输出的 JSON 格式要求以及安全准则。这部分在所有租户和所有调用中都是 100% 相同的，通常占用 800 到 1500 个 Token。
2. 检索上下文 (RAG Context)：例如“该服务过去 3 次类似的故障记录”。虽然它会随服务变化，但在短时间内的批量分析中是静态的。通常占用 400 到 800 个 Token。
3. 单次事件数据 (Per-incident Events)：具体的日志流，如“14:32:01 发生 ConnectionPoolExhausted”。这是每个请求独有的，无法缓存。通常在 1500 到 3000 个 Token 之间。
4. 元数据 (Metadata)：如事件 ID、服务 ID 等微小但唯一的标识符。
5. 输出 Token：模型生成的分析报告，按固定输出费率计费，不涉及缓存。

在实际分布中，系统提示词和检索上下文（来源 1 和 2）占据了输入 Token 的 70% 到 80%。通过将这些内容以 $0.10 的价格进行缓存读取，而仅对剩余 20% 的动态内容支付全价，你的总输入成本将直接下降 60% 到 70%。结合故障频发时的超高命中率，综合成本降低 90% 并非难事。

技术实现：如何正确使用 cache_control

Anthropic 的 API 允许在 messages 数组中放置 cache_control 标记。每个标记都是一个独立的断点，系统会缓存该标记之前的所有内容。为了在多租户环境下最大化效率，你应该采用多段缓存策略：

// 针对 RCA 场景优化后的 Prompt 结构示例
const system = [
  {
    type: 'text',
    text: GLOBAL_SYSTEM_PROMPT, // 全局通用，1200 tokens
    cache_control: { type: 'ephemeral' },
  },
  {
    type: 'text',
    text: serviceSpecificContext, // 特定服务相关，600 tokens
    cache_control: { type: 'ephemeral' },
  },
]

核心原则：顺序至上。 缓存是按顺序匹配的前缀。你必须将最稳定的内容放在最前面。如果你错误地将动态的“事件数据”放在了“系统提示词”之前，那么由于前面的内容每次都在变，后面的系统提示词将永远无法匹配缓存。通过在 n1n.ai 上合理排列 Prompt 顺序，你可以确保每一笔支出都花在刀刃上。

避坑指南：为什么你的缓存没有生效？

即使配置了代码，开发者仍常遇到以下几个导致缓存失效的坑：

• 5 分钟 TTL 限制：缓存段在最后一次写入后 5 分钟失效。如果你的请求非常稀疏（例如每小时才一次），你将不断支付“写入溢价”却无法享受“读取折扣”。在这种情况下，考虑增加调用频率或放弃缓存。
• 空格与换行符漂移：缓存是基于字面量哈希的。如果你在 A 处使用了两个换行符 \n\n，而在 B 处使用了一个 \n，它们会被视为完全不同的 Key。请务必统一你的 Prompt 模板标准。
• 尾部动态内容泄露：一个常见的错误是在系统提示词中加入时间戳，例如“当前时间：2025-05-08 14:32:01”。这会导致该标记之后的所有缓存全部失效。请将所有动态变量移至 user 消息中。
• Schema 频繁变更：如果你正在频繁迭代 JSON 输出格式，每次修改都会导致缓存失效。建议在模型调优阶段结束后，再进行大规模的缓存部署。

总结：迈向低成本 AI 架构

通过将 Prompt Caching 与 Batch API（批量接口通常还有额外 50% 折扣）结合使用，Claude 3.5 Haiku 的单次 RCA 调用成本可以压低至约 $0.0033。相比之下，未经优化的实时 API 调用成本约为$0.0065。对于每天处理数百万次事件的企业级应用来说，这节省下来的不仅仅是金钱，更是产品的市场竞争力。

无论你是在使用 Claude 3.5 Sonnet、DeepSeek-V3 还是 OpenAI 的 o3 系列，提示词缓存的思想是通用的。通过将静态前缀与动态内容分离，你可以构建出既强大又经济的 AI 系统。现在就访问 n1n.ai 开启你的高效开发之旅。

获取免费 API 密钥，请访问 n1n.ai。