arXiv 2605.05117·2026-05-09 — 次浏览
Prompt 缓存经济：73% 的 LLM 成本隐藏在可缓存前缀中
Hyeonji Lee, Tara Mukherjee, Daniel Roa-Bell · CMU / Anyscale
1,400 万生产 LLM 请求的轨迹分析：73% 的输入 token 在 5 分钟窗口内跨请求重复。量化跨供应商的 prompt 缓存成本节省 — Anthropic 5 分钟 TTL 捕获 81% 的节省。
关于生产 prompt 缓存重用的最大规模实证研究。作者分析了来自三个 SaaS 部署（聊天代理、代码审查、RAG 流水线）的 1,400 万 LLM 请求，并将输入 token 分为”可缓存前缀”与”请求独特尾部”。
标题数字
| 指标 | 数值 |
|---|---|
| 在可缓存前缀中复发的输入 token 中位数 % | 73.4% |
| 95 百分位 % | 91.2% |
| 若所有可缓存前缀命中缓存的成本节省 | 输入成本减少 64% |
| 实际实现的成本节省（Anthropic 5 分钟 TTL） | 减少 38%（理论值的 52%） |
Anthropic 出货的 5 分钟 TTL 涵盖大部分会话内重用，但错过约一半跨会话重用（例如，喝咖啡后回来的用户）。作者建模 TTL 扩展，发现 30 分钟 TTL 将捕获 89% 的理论节省 — 但供应商端基础设施成本更高。
应用分解
- 聊天代理：79% 可缓存（系统 prompt + 少样本示例稳定）
- 代码审查：84% 可缓存（审查清单 + 仓库上下文主导）
- RAG 流水线：51% 可缓存（检索块每次查询变化，但系统 prompt 固定）
缓存失效模式
最昂贵的缓存错误是会话中途更新系统 prompt。单一字节变化会使该对话的整个前缀缓存失效。作者发现 3.1% 的会话有至少一次会话中系统 prompt 变更，这些会话付出单版本会话 2.4 倍的成本。
从业者注记
对任何大规模运行 LLM 工作负载的人，三个要点：(1) 停止在生产中迭代系统 prompt — 对其版本化并原子部署。(2) 如果你在 OpenAI 上没有启用 prompt 缓存，你正让 30-50% 的输入成本流失；切换到缓存端点。(3) Anthropic 的 5 分钟 TTL 是实用的默认值，但值得衡量你的会话是否超过它 — 如果是，将你的 prompt 结构化为把最大稳定块放在前面，这样缓存存活最久。