提示缓存工作流：LLM 应用的成本与 ROI 指南

提示缓存可以降低重复 LLM 请求的成本和延迟，但前提是工作流会产生稳定的前缀、足够的复用，以及可接受的缓存命中行为。开启该功能并不等于已经证明了投资回报。

本指南为工程和 FinOps 团队提供一套实用的提示缓存工作流：识别可用流量、为复用优化提示、埋点缓存指标、计算净节省，并在不掩盖质量或可靠性回归的前提下逐步上线。

什么是提示缓存？

提示缓存允许 LLM 提供商复用其最近处理过的提示内容的计算结果。对于重复输入的每个 token，提供商不再按正常费率进行处理和计费，而是可以对可复用部分适用更低的缓存输入费率，或者采用单独的缓存读取价格。

可复用内容通常是一个稳定的提示前缀。常见示例包括：

• 较长的系统提示和策略块。
• 每次 agent 轮次都会共享的工具定义。
• 被反复查询的大型文档、代码仓库映射或产品目录。
• 在分类或抽取任务中重复使用的 few-shot 示例。
• 被多个可能的下一步操作共享的对话历史。

各提供商的实现方式不同。OpenAI 文档说明了对符合条件的提示前缀进行自动缓存，并在 API 使用中暴露缓存 token 详情。Anthropic 支持显式缓存断点和多种 TTL 选项。Google Gemini 支持带存储费用的显式上下文缓存，而 DeepSeek 文档说明了基于磁盘的自动上下文缓存，并采用单独的缓存命中和缓存未命中输入费率。在将节省金额纳入预测之前，请务必先在提供商的官方文档中确认当前模型支持与定价。

ROI 的常见错误：衡量折扣，而不是工作流

缓存 token 折扣并不等同于净节省。该工作流还可能带来缓存写入费用、存储费用、额外请求、运维复杂度，或者当团队过度优化提示结构时引发质量回归。

请衡量真正重要的单位：

净提示缓存 ROI = 避免的未缓存输入成本 - 缓存写入/存储成本 - 实施与运营成本

对于生产决策，请将该结果与一个已接受的结果指标关联起来：

每个已接受任务的成本 = 总请求成本 / 已验证成功任务数

这样可以避免一种误导性的结果：token 支出下降了，但重试、被拒绝的输出或人工审核增加了。它也使提示缓存成为更广泛的 AI API 成本优化计划的一部分，而不是将缓存视为一个孤立的计费技巧。

六步提示缓存工作流

1. 找出具有真实前缀复用的工作负载

从请求轨迹入手，而不是凭直觉。按工作流对流量分组，并估算从一次请求到下一次请求，开头有多少输入 token 保持完全一致。

通常，优秀候选项具备四个特征：

1. 输入重复量大：可复用前缀相对于动态后缀而言占比显著。
2. 重复使用频繁：在提供方的有效缓存生命周期内，多次请求引用同一前缀。
3. 顺序稳定：系统指令、工具、示例和参考材料以相同顺序出现。
4. 基数低：应用复用的是数量可控的提示变体，而不是为每个用户都创建唯一前缀。

典型的高潜力工作流包括：使用稳定工具 schema 的编码代理、以共享知识包为依据的支持助手、文档问答会话、带重复示例的批量抽取，以及多轮研究代理。

不太适合的场景包括一次性的短提示、高度个性化的前缀、每次调用都会更改工具定义的请求，以及很少复用缓存条目的低吞吐任务。

为每个工作流建立一张基线表：

2. 将静态内容放在动态内容之前

提示缓存通常依赖于从开头开始匹配提示。前部哪怕很小的差异，也可能让后续所有内容都无法复用。

在提供方和 SDK 允许的情况下，请按以下顺序组织：

1. 稳定的系统指令
2. 稳定的策略与安全规则
3. 稳定的工具定义
4. 稳定的参考材料或示例
5. 半稳定的对话上下文
6. 动态用户输入和运行时值

不要把时间戳、请求 ID、用户特定标签、随机顺序的 JSON，或经常变化的功能开关放在提示开头附近。对工具 schema 进行规范化，并以确定性的方式序列化结构化内容。

这并不意味着可以把无关数据拼接成一个过大的前缀。请保持租户边界、授权规则和数据保留要求不变。更便宜的提示，不值得以隐私或隔离失败为代价。

3. 定义缓存身份和失效策略

即使提供方自动管理缓存，你的应用也需要一种明确的方式来推理提示版本。

一个实用的缓存身份可以包括：

workflow + prompt_version + tool_schema_version + knowledge_version + model_family

在遥测中跟踪这个身份。当指令、工具契约或参考数据发生变化时，递增相应版本。这样可以让成本变化更容易解释，并避免团队把预期中的失效误认为提供方故障。

根据工作负载行为和供应商支持情况设置复用窗口。短生命周期的交互式代理可能只需要几分钟的复用时间；而周期性研究工作流如果存储成本仍低于重复输入处理成本，则可以考虑更长的显式缓存。

4. 跟踪命中、未命中、写入和接受结果

至少为每次尝试记录以下字段：

• 供应商、模型和工作流。
• 提示版本和缓存标识。
• 在可获取时，记录总输入、缓存/已读、缓存写入和输出 token 数。
• 缓存命中或推断命中状态。
• 输入、缓存、输出和总估算成本。
• 延迟、状态、重试次数和回退路径。
• 经验证的成功或已接受任务结果。

在可用时，使用供应商报告的 usage 字段作为计费事实来源。如果某个供应商没有返回清晰的缓存命中标志，请从缓存 token 数或计费记录中谨慎推断，并将该指标标注为推断值。

提示缓存遥测应与重试和模型回退放在同一 trace 中。否则，重试风暴可能看起来像一次成功的缓存优化。AI 可观测性实施清单展示了如何将每次尝试的成本与应用结果关联起来。

5. 计算节省和盈亏平衡用量

使用与供应商收费结构相匹配的模型。

对于具有折扣读取费率的自动缓存：

gross_savings = cache_read_tokens × (uncached_input_rate - cached_input_rate)
net_savings = gross_savings - incremental_operating_cost

对于带有写入和存储费用的显式缓存：

net_savings = avoided_uncached_cost
            - cache_write_cost
            - cache_storage_cost
            - incremental_operating_cost

你可以估算单个缓存前缀的复用盈亏平衡次数：

break_even_reuses =
  (cache_write_cost + storage_cost + implementation_cost_per_entry)
  / savings_per_cache_read

向上取整到下一个完整复用次数，然后为未命中、失效和流量波动增加余量。

ROI 示例

假设某工作流具有：

• 每月 40,000 次请求。
• 每次请求 18,000 个输入 token。
• 12,000 token 的稳定前缀。
• 70% 的有效缓存命中率。
• 未缓存输入费率为每百万 token 3 美元。
• 缓存输入费率为每百万 token 0.30 美元。
• 每月 350 美元的摊销工程和监控成本。

每月缓存 token 数：

40,000 × 12,000 × 70% = 336,000,000 cached input tokens

总节省：

336 million × ($3.00 - $0.30) / 1 million = $907.20

每月净节省：

$907.20 - $350 = $557.20

如果该工作流产生 32,000 个已接受任务，那么缓存每个已接受任务可带来约 $0.017 的节省。这在大规模场景下可能很有意义，但其结果远没有简单宣称 90% 的缓存输入折扣那么可观。

上述费率仅为示意，并非当前供应商报价。请用你们签约或公开的费率替换，并在适用时包含缓存写入、存储、区域定价、服务层级和网关费用。

6. 通过受控实验上线

将缓存作为一项可衡量对照组的工程变更来运行。

1. 选择一个复用率高的工作流。
2. 冻结评估集和验收标准。
3. 建立未缓存的成本、延迟和质量基线。
4. 只重构稳定前缀。
5. 让一小部分生产流量走缓存路径。
6. 比较命中率、每个已接受任务的成本、P95 延迟、错误和回退。
7. 只有在扣除运营成本后节省仍为正时才扩大范围。

将重试和回退策略与缓存逻辑分开。失败请求可能适合重试，可能在部分流式输出后不适合重放，或者更适合由等效模型处理。请使用明确的模型回退策略，不要把每次缓存未命中或超时都视为同一种故障。

提示缓存 KPI 仪表盘

按工作流和提示版本跟踪以下指标：

当重复前缀较小时，可能会出现较高命中率但节省有限的情况。若提示碎片化问题可以修复，即使命中率较低、前缀很大，也可能代表一个有价值的机会。应结合起来解读这些指标。

提示缓存的常见失败模式

动态值位于开头

时间戳、ID 和每用户元数据如果靠前，会使缓存碎片化。尽可能将它们移到稳定前缀之后。

工具 schema 在请求之间发生变化

Agent 往往会动态重建或重新排序工具定义。请规范顺序、移除无关工具，并有意地对 schema 进行版本管理。

缓存条目已写入但很少被复用

当流量稀疏或 TTL 过长时，显式创建缓存的成本可能高于收益。请先按缓存标识衡量复用情况，再延长保留期。

团队优化 token 但忽视输出

输出令牌、重试以及人工审核可能会主导总成本。请继续衡量完整请求和已接受的结果。

假定提供商行为具有可移植性

自动前缀缓存、显式断点、存储计费、最小提示长度、符合条件的模型以及使用字段会因提供商而异。请构建一个提供商适配器，并使业务指标保持与提供商无关。

回退会破坏缓存局部性

切换提供商或模型家族可能会消除复用，因为缓存不可移植。这并不意味着应该禁用回退。它意味着可靠性和成本需要一套共享策略：在必要时进行故障切换，然后正确归因未命中和增量成本。

提供商实施检查清单

在为某个模型启用提示缓存之前，请确认：

• 缓存是自动的、显式的，还是两者兼有？
• 哪些模型和 API 端点支持它？
• 适用的最小提示长度是多少？
• 如何定义匹配前缀？
• 有哪些 TTL 或保留选项？
• 缓存写入、读取和存储是否分别计费？
• 哪些响应字段会暴露缓存令牌或缓存创建信息？
• 服务等级、区域、数据驻留或零保留设置会改变行为吗？
• 缓存是否按项目、账户、组织或其他边界隔离？
• 当请求回退到另一个模型或提供商时会发生什么？

请参考官方的 OpenAI 提示缓存指南、Anthropic 提示缓存文档、Google Gemini 上下文缓存指南以及 DeepSeek 上下文缓存指南，以获取当前实现细节。定价和模型可用性可能会变化，因此在每次重大的成本审查期间都应重新核对这些来源。

AI 网关的作用

统一的 AI 网关并不能使提供商缓存变得可移植。每个提供商仍然控制其自己的缓存语义和计费。不过，网关可以为团队提供一个统一的位置，用于规范化模型标识、路由符合条件的工作负载、记录特定提供商的使用情况、比较每个已接受任务的成本，以及执行回退或预算策略。

Flatkey 提供一个与 OpenAI 兼容的端点和统一余额，以便访问多个模型家族。这使得在不重建每个集成的情况下，更容易对有缓存和无缓存的工作流进行基准测试。在将某条路由视为已启用缓存之前，请先确认所选模型当前的缓存支持和提供商行为。

如果您正先整合现有客户端，请使用 OpenAI 兼容 API 网关迁移检查清单，并查看 Flatkey 当前的模型访问与定价。

常见问题

提示缓存可以节省多少成本？

节省幅度取决于可复用前缀、命中率、提供商定价、写入或存储费用以及实施成本。请根据实际观察到的缓存令牌计算净节省，而不是将表面折扣应用到所有输入令牌上。

什么样的缓存命中率算好？

没有通用的目标值。一个有用的命中率是能够带来正向净节省，并且改善或保持每个已接受任务的成本。较长的前缀可以证明较低命中率的合理性；较短的前缀可能需要非常高的复用率。

提示缓存会提升延迟吗？

对于缓存命中，它可以降低输入处理延迟，但效果取决于提供商、模型、提示大小、网络路径和工作负载。应跟踪 P50 和 P95 延迟，而不是假设存在固定的提升幅度。

我应该缓存整个对话吗？

通常你应该尽量保留一个稳定前缀，而不是盲目缓存所有内容。对话轮次会增长并变化。把稳定的指令、工具和参考内容放在前面，然后再追加会变化的历史记录和用户输入。

缓存的提示可以在不同提供商之间共享吗？

不可以。提供商侧的提示缓存是特定于提供商的。如果路由更改了提供商或模型，除非该提供商明确说明支持兼容复用，否则应将该请求视为很可能发生缓存未命中。

提示缓存对敏感数据安全吗？

请审查提供商针对你的账户和模型的数据处理、缓存隔离、保留、驻留以及零保留条款。不要为了成本优化而绕过安全、隐私或租户隔离要求。

从一个重复前缀开始

最佳的提示缓存工作流是有意收窄的：选择一个成本高、复用率高的工作负载；将稳定内容移到前面；为其建立版本；衡量命中、未命中、延迟、质量和成本；然后计算净 ROI。

当结果改善了每个已接受任务的成本时，再将该模式扩展到下一个工作流。当没有改善时，遥测数据会告诉你问题是提示碎片化、用量不足、保留时间太短、提供商定价，还是这本来就不是一个适合缓存的工作负载。