LLM prompt caching 可以让高价 API 在重复上下文场景下比利用率不足的本地 GPU 更便宜。但它也可能完全无法节省成本。决定因素不是模型的标价，而是前缀复用、缓存写入成本、读取折扣、过期、驱逐、利用率，以及失败工作的成本。
受众： 负责 LLM 平台成本、延迟或基础设施决策的高级实践者。
实用规则：在购买 GPU 容量之前，先在真实工作负载上测量缓存读取和失效情况。 一项新的企业编码代理案例研究以惊人的 99.3% 缓存命中率说明了这一点，但其作者研究的是一名开发者、两个连续的 28 天周期、不同的模型系列，以及一个生产代码库。应将这篇论文视为测量提示，而不是云端与本地方案的裁决。
LLM prompt caching 改变了什么
LLM 处理输入大致分为两个阶段：
在服务层，前缀缓存可以为 prompt 前缀存储可复用的 attention 或 key-value 状态。后续请求如果包含相同且符合条件的前缀，就可以跳过部分重复的 prefill 工作。变化的后缀仍然需要处理，模型也仍然会解码生成新的答案。
这一点很重要。Prompt caching 不是响应缓存。它不会返回已存储的答案，不会缩短输出，不会修复薄弱的 prompt，也不保证端到端延迟更低。它主要针对重复的输入计算，并且通常会改善首 token 时间。
最初的 Prompt Cache 论文 对可复用的 prompt 模块进行了形式化，并报告了原型在 GPU 上 8×、在 CPU 上 60× 的首 token 时间改进。这些结果来自论文测试的模型、硬件、prompt 和实现，并不是对当前商业 API 的预测。
99.3% 案例研究：有用但边界狭窄的证据
一篇发表于 2026 年 7 月的预印本 *Inference Economics of Enterprise Coding Agents*，比较了一个生产单体代码库中连续两个 28 天周期：
作者分析了 LLM 遥测数据和 Git 历史。他们报告称，API 周期的 prompt-cache 命中率为 99.3%，API 的有效成本为每百万处理 token 0.573 美元，而共享本地部署分配的摊销单位成本为 2.83 美元。API 处理的 token 数量多出 16.9 倍，而本地硬件利用率较低，因此这些标准化 token 价格并不能解决基础设施问题。
总成本结果会因资源分配方式而不同。按照论文中的台湾市场和劳动力假设，共享本地容量使估算的真实总拥有成本降低了 40.1%。专用本地预留容量的成本比使用缓存 API 高 43.8%。本地周期还对应着更高的修复提交比例：74.9%，而 API 周期为 45.9%。
作者测量了什么
作者推断了什么
该研究无法证明什么
研究设计不是随机化的，并且采用了连续周期。两个周期之间，代码库、开发者、任务组合和工作方式都可能发生变化。模型能力、服务栈、harness 和量化方式也同时发生了变化。第一作者知道研究假设。修复提交标签是代理指标，而不是独立的缺陷审计。原始生产遥测数据和完整的重放环境没有公开。
更持久的结论比标题中的数字更窄：前缀复用和 GPU 利用率可能压倒标价比较，而修复工作可能压倒 token 节省。
在计算命中率前定义测量契约
除非明确分母，否则“缓存命中率”是含糊的。一个 dashboard 可能用缓存 token 除以符合条件的前缀 token；另一个可能用发生任何缓存读取的请求数除以全部请求数；第三个可能将缓存 token 作为总输入的比例，其中包括未缓存的后缀。
请使用分开的指标：
将 provider 报告的使用字段与自行推导的指标分开。token 数量也会随着模型 tokenizer 和模板变化；LLM tokenizer tax 解释→说明了为什么原始字符数不能很好地替代 token 统计。
当前 API 和自托管行为并不统一
以下快照于 2026 年 7 月 30 日核查。用于采购或计费前，请重新检查链接的文档。
| Platform | Cache control | Observable signal | Operational constraint |
|---|---|---|---|
| --- | --- | --- | --- |
| OpenAI API | GPT-5.6 支持隐式和显式 prompt caching | `cached_tokens` 和 `cache_write_tokens` | 当前 GPT-5.6 指南规定显式写入按未缓存输入价格的 1.25× 计费；读取享受折扣 |
| Anthropic API | 自动缓存或显式 block breakpoint | 分开的缓存创建和读取用量 | 前缀顺序为 tools、system，然后是 messages；默认 TTL 为 5 分钟，也可付费使用 1 小时选项 |
| Gemini Interactions API | Gemini 2.5 及更新模型默认启用隐式 context caching | `usage.total_cached_tokens` | 通用内容应放在开头；当前最低要求按模型为 2,048 至 4,096 token |
| vLLM | 可在 engine 中启用 Automatic Prefix Caching | Engine 指标和请求计时 | 团队需要自行负责容量、驱逐、隔离、升级和可观测性 |
OpenAI 当前的模型指南建议 GPT-5.6 用户监控缓存写入和读取，因为显式写入的成本高于未缓存输入。Anthropic 的 prompt-caching 文档说明了 5 分钟写入按基础输入价格的 1.25× 计费、1 小时写入按 2× 计费，以及缓存读取按 0.1× 计费。Google 的 context-caching 指南表示，Interactions API 会自动启用隐式缓存，并在用量中报告缓存 token。vLLM 的 Automatic Prefix Caching 示例展示了自托管 engine 中相同的共享前缀理念。
这些实现共享的是一种原则，而不是可移植的计费契约。最低前缀长度、缓存范围、保留时间、存储费用、使用字段和隔离方式都可能不同。
*在改变基础设施前先测量缓存：稳定前缀，运行冷启动和热启动测试，强制失效，然后比较总成本。*
可复用前缀的盈亏平衡公式
设：
忽略存储费用，每个请求的平均可复用前缀费用为：
`(W + (N - 1) × R) / N`
当满足以下条件时，缓存处理该前缀的成本低于未缓存处理：
`N > (W - R) / (U - R)`
该公式只隔离了可复用前缀。它不包括变化后缀、输出 token、可缓存长度下限、存储费用、驱逐导致的未命中、并发影响、工程人力和失败任务。
以一个有日期的示例说明，2026 年 7 月 30 日 Anthropic 的 5 分钟倍数为 `U = 1`、`W = 1.25` 和 `R = 0.1`。仅考虑输入时，阈值为 `N > 1.28`，因此对于符合条件的前缀，在缓存生命周期内的第二次使用就能摊薄更高的写入费用。这并不意味着总共两次 API 调用就能让缓存获利。较短的前缀、较长的未缓存后缀、一次缓存未命中或昂贵的输出，都可能抹去节省。
将该公式作为成本模型的单元测试。用当前 provider 契约和测量到的工作负载值替换每个变量。
为什么看似稳定的 prompt 仍然会缓存未命中
大多数未命中源于 prompt 构建，而不是模型。
易变数据出现得太早
时间戳、请求 ID、随机 nonce、用户名或新检索结果如果出现在前部，就会改变其后的每个 token。将稳定的 tools、策略、模板和可复用文档放在前面。将请求特定数据移到可复用前缀或显式 breakpoint 之后。
序列化在请求之间发生变化
JSON 键顺序、空白、工具顺序和文档顺序可能改变原本等价的前缀。使用确定性序列化。在语义允许的情况下，按照稳定标识符对工具定义和检索文档排序。
上下文管理器破坏了前缀连续性
激进的裁剪可以节省输入 token，却会使缓存前缀失效。TokenPilot 是一篇发表于 2026 年 6 月的进行中预印本，将其视为联合优化问题。作者稳定摄取过程，并延迟驱逐，直到上下文失去任务价值。他们报告称，在两个 benchmark 和两种执行模式中，成本降低了 56% 至 87%，同时保持了有竞争力的任务表现。这些结果需要在论文工作负载和 LightMem2 集成之外进行复现。
缓存在真实负载下过期或被驱逐
热启动本地测试可能掩盖 TTL 边界和容量压力。自托管前缀缓存与其他 KV-cache 系统一样，都受有限内存现实的约束。更深入的 KV-cache 驱逐指南→介绍了为什么并发和序列长度上升时复用可能崩溃。
模型或模板发生变化
模型版本、tokenizer、chat template、图像 detail 设置、工具 schema 或安全前导语都可能创建新的前缀。将发布和 prompt 迁移视为缓存失效事件。
当前 vLLM 工程讨论说明了这种压力。上下文感知保留提案认为并发 agent 工作负载可能驱逐有价值的前缀，而语义 KV-cache 提案则探索精确匹配之外的复用。这些是开放的设计讨论，不是生产保证或采用率测量。
可复现的 prompt-cache 测试
使用与为真实工作评测 AI 模型→相同的任务集。缓存测试增加受控的前缀变更和基础设施核算。
1. 固定具有代表性的工作负载
从生产流量或隐私安全的重放数据集中选择 30 至 100 个任务。保留真实的前缀长度、后缀长度、输出长度、工具、文档和并发分布。在运行测试前定义任务成功标准。
不要针对一个很长的演示 prompt 进行优化。缓存友好的客服工作流和缓存不友好的研究工作流可能具有完全相反的经济性。
2. 拆分稳定内容和易变内容
为每个 prompt 片段标注：
构建确定性的 prompt assembler。记录不透明的前缀版本或带密钥的 hash，使每个请求都能标识其尝试复用的前缀。不要将 secret 或原始客户内容放入日志。
3. 运行受控矩阵
对于每个任务类别，测量：
| Trial | Change | Question answered |
|---|---|---|
| --- | --- | --- |
| Cold | 没有可复用状态的新前缀 | 基线写入或 prefill 成本是多少？ |
| Warm | 完全相同的符合条件前缀 | provider 或 engine 是否报告读取？ |
| Early mutation | 更改开头附近的一个 token | 有多少复用会消失？ |
| Late mutation | 只更改后缀 | 稳定前缀是否仍可复用？ |
| TTL boundary | 在过期前后重复请求 | 生产流量有多大概率及时到达？ |
| Concurrency | 分阶段增加并行请求 | 驱逐或调度是否会降低复用？ |
| Version change | 更改模型、工具或模板 | 哪些部署会使缓存失效？ |
运行足够多次重复测试，以便报告分布，而不是单个延迟数字。将 p50 和 p95 首 token 时间与端到端延迟分开。
4. 同时记录计费和质量
记录：
精确前缀状态复用应避免重复的 prefill 计算，但这并不能免除质量检查。模型、量化级别、路由策略或服务栈的变化，即使缓存机制本身正确，也可能改变输出质量。
5. 计算三种成本视角
如果本地方案依赖持续的利用率，就测试利用率假设。GPU 采购不会因为电子表格把每个闲置小时都分配给未来需求，就自动变得经济。
云端 API、本地 GPU，还是混合路由？
这个决策很少是二选一。
在以下情况下优先使用缓存 API
在以下情况下优先使用共享本地容量
在以下情况下使用混合路由
免费或补贴 endpoint 有助于原型开发，但不会消除工作负载核算的必要性。免费 AI models API 案例研究→是区分访问价格与生产可靠性的有用起点。
Prompt-cache 安全需要单独测试
缓存会产生依赖数据的时序：复用的前缀可能比未命中时更快返回第一个 token。一项 ICML 2025 审计使用时序测量测试了真实 API，并报告称，在研究期间的七家 provider 中发现了跨用户缓存共享的证据。
这一结果是具有历史性的、特定于 provider 的证据。它不能说明这些服务今天如何隔离缓存。
向当前 provider 和内部平台负责人询问：
对于自托管系统，应加入跨租户时序和驱逐测试。不要仅仅为了调试缓存，就将可复用的敏感前缀写入日志。存储 hash、token 数量、版本标识符和符合政策的元数据。
决策清单
不要仅凭标价批准 GPU 采购或 API 迁移。应要求提供：
Prompt caching 很有价值，因为重复上下文很常见。但将它作为采购捷径很危险，因为复用情况取决于工作负载。测量前缀，测量未命中，然后比较总成本。
Claim checks
| Important claim | Evidence type | Check and limitation |
|---|---|---|
| --- | --- | --- |
| 编码代理研究报告了 99.3% 的 prompt-cache 命中率 | Primary research，2026 年 7 月预印本 | 一名开发者、一个代码库、两个连续周期；结果不可直接迁移 |
| 论文报告 API 每百万处理 token 成本为 0.573 美元，而共享本地分配为 2.83 美元 | Primary research | API 处理的 token 数量多出 16.9 倍，且本地利用率较低；总支出和 TCO 是更有力的比较 |
| 共享本地容量节省了 40.1% 的 TCO，而专用容量成本高出 43.8% | Primary research | 取决于论文中的硬件、分配、台湾市场、劳动力和质量假设 |
| Prefix caching 会复用重复 prompt 片段的 attention 状态 | Peer-reviewed primary research and official engine docs | 它减少重复的 prefill 工作；解码和变化后缀的工作仍然存在 |
| Anthropic 的 5 分钟缓存写入成本为基础输入的 1.25×，读取成本为 0.1× | Official documentation，2026 年 7 月 30 日核查 | 价格和支持的模型可能变化；示例不包括输出、后缀和存储 |
| 在 Interactions API 中，Gemini 隐式缓存默认用于 Gemini 2.5 及更新版本 | Official documentation，2026 年 7 月 7 日更新 | 最低 token 数量和显式缓存支持因 API 和模型而异 |
| TokenPilot 在其测试设置中报告了 56%–87% 的成本降低 | Primary research，进行中的预印本 | 两个 benchmark 和特定集成；需要独立复现 |
| 当缓存范围跨越用户时，prompt-cache 时序可能泄露信息 | ICML 2025 primary research | 对所测试 provider 的历史审计；不要据此推断当前 vendor 行为 |