提示词缓存
大模型推理中的降本增效机制，通过保存已计算的KV Cache并在前缀匹配时复用，避免重复prefill计算，从而降低首字延迟和API调用成本
核心事实
时间轴 (近 90 天)
不同AI服务商的缓存粒度、命中条件和计费方式存在差异，例如有的按缓存写入token和缓存读取token分别计价，有的设置最小可缓存token长度。
随着提示词缓存技术的成熟，可能会出现更多灵活的缓存时长选项，甚至自动优化的缓存策略。
Reddit用户讨论反映了用户希望更灵活地控制缓存时长以适应不同工作流的普遍需求。
主流AI服务商（如OpenAI、Anthropic）的缓存定价策略通常对长缓存收取一定的存储费用，但会大幅降低重复请求的输入成本。
12小时缓存策略尤其适合客服机器人、内容创作助手、编程助手和多轮复杂对话等场景。
混合使用策略：用12小时缓存存储共享指令，用30分钟缓存处理较新的对话内容，可以兼顾复用节省和避免为频繁变动的部分支付长缓存费用。
如果需要在一天内反复重用相同的上下文，12小时缓存带来的重复使用节省可能显著超过其额外成本。
默认的30分钟提示词缓存适合快速连续的对话。
Reddit原帖描述用户现在面临三种选择：坚持默认的30分钟缓存、切换到12小时缓存，或者将两者混合使用。
模型路由和提示词缓存的普及会直接压低单位请求的Token消耗，从而在调用量增长的同时使总Token曲线趋平。
还有 23 条时间轴事件
全部知识事实 (20)
提示词缓存能否命中取决于请求前缀的逐字节一致性，只要开头有一个字符不同，整段缓存就失效。
70%已验证Prompt缓存有效期通常只有几分钟到数小时，折扣幅度和缓存窗口可能随时调整
65%已验证Token 缓存（Prompt Caching）是大模型 API 中的成本优化机制，当同一段前缀在多次请求中重复出现时可缓存计算结果并收取更低费用
65%已验证缓存读取机制对重复出现的长提示词前缀保留KV缓存，命中时按极低价格计费，Opus 5.5泄露的缓存读取价格约为输入价格的1/20
65%已验证当多个请求共享相同前缀（如系统提示词）时，高效的KV Cache复用可以大幅降低计算开销
65%部分验证在 Anthropic 的 API 计费体系中，提示词缓存（prompt caching）允许将稳定前缀标记为缓存内容，后续相同前缀直接复用 KV 而不重新计算注意力，这部分 token 记为「缓存读取」。
75%待验证提示词缓存依赖Transformer的KV缓存机制，通过复用相同前缀已计算的KV向量跳过重复计算，节省GPU算力并降低首Token延迟
70%待验证12小时缓存策略尤其适合客服机器人、内容创作助手、编程助手和多轮复杂对话等场景。
50%待验证Reddit用户讨论反映了用户希望更灵活地控制缓存时长以适应不同工作流的普遍需求。
50%待验证不同AI服务商的缓存粒度、命中条件和计费方式存在差异，例如有的按缓存写入token和缓存读取token分别计价，有的设置最小可缓存token长度。
50%待验证Reddit原帖描述用户现在面临三种选择：坚持默认的30分钟缓存、切换到12小时缓存，或者将两者混合使用。
50%待验证默认的30分钟提示词缓存适合快速连续的对话。
50%待验证主流AI服务商（如OpenAI、Anthropic）的缓存定价策略通常对长缓存收取一定的存储费用，但会大幅降低重复请求的输入成本。
50%待验证混合使用策略：用12小时缓存存储共享指令，用30分钟缓存处理较新的对话内容，可以兼顾复用节省和避免为频繁变动的部分支付长缓存费用。
50%待验证提示词缓存（prompt caching）可对重复出现的长上下文复用计算结果，显著降低重复计费。
50%待验证提示词缓存通常有较短的生命周期（分钟级），并以服务商、模型、内容前缀为键。
50%待验证切换服务商后，新 provider 的缓存中没有此前的前缀，整段上下文需按全价重新处理。
50%待验证主流大模型服务商（如 Anthropic、OpenAI）均支持在服务端缓存请求前缀，后续请求中与缓存内容完全一致的前缀部分可按折扣计费且无需重新计算。
50%待验证提示词缓存要求请求前缀逐字节匹配，且缓存通常有存活时间（如5分钟到1小时），超时后需重新写入。
50%待验证在RAG场景中，检索上下文每次查询都在变，如果把它放在提示词靠前位置会破坏后续内容的缓存命中，因此通常将静态系统提示词放在最前以享受缓存，动态检索文档块放在后面。
50%