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

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

本指南为工程和 FinOps 团队提供一套实用的提示缓存工作流：识别可适用流量、将提示塑造成便于复用的形式、埋点缓存指标、计算净节省，并在不掩盖质量或可靠性回归的情况下逐步推广。它还包含一个为期七天的审计流程，可将提供方的使用字段转化为“推进”“修复”或“停止”的决策。

提示缓存 ROI：快速答案

当某个工作流会在提供方保留窗口内，反复发送一个较大且字节完全相同的前缀时，提示缓存通常值得测试。仅仅因为模型宣传了折扣缓存 token，并不意味着它自动就划算。

在更改生产提示之前，先通过下面这个三部分门槛：

核心计算公式是：

net_savings = uncached_baseline_cost
            - observed_cached_workflow_cost
            - incremental_engineering_and_operations_cost

roi_percent = net_savings
            / incremental_engineering_and_operations_cost
            × 100

如果实现成本由多个缓存标识共享，应将其按预期评估周期摊销，而不是把整个项目成本都分配给某一条记录。

2026 年提示缓存有什么变化？

提示缓存不再是一种统一的折扣机制。如今不同提供方的设计差异已足够大，若仍用一张通用的“缓存 token 更便宜”电子表格，可能会得出错误答案。

例如，OpenAI 当前的 GPT-5.6 文档描述了自动前缀匹配、显式的 prompt_cache_key 和 cache_control 控制，以及单独的 cache-read 和 cache-write 使用量。该模型的 cache write 可能带有溢价，因此盈亏平衡计算必须把创建或延长缓存的成本也包括进去——不能只算折扣后的读取成本。OpenAI 还在受支持的请求的 usage 字段中公开 cached、uncached 和 cache-write 的 token 细节。

Anthropic 使用显式缓存断点和 TTL 选择。Gemini 的显式上下文缓存可能会增加存储费用。DeepSeek 记录了带有单独命中率和未命中率的自动上下文缓存。这些设计都可以带来节省，但它们需要不同的遥测和公式。

什么是提示缓存？

提示缓存允许 LLM 提供方复用其最近处理过的提示内容所对应的计算。对于重复输入 token 中可复用的部分，提供方可以按更低的缓存输入费率计费并处理，或者采用单独的 cache-read 价格，而不是按正常费率对每个重复输入 token 计费和处理。

可复用内容通常是稳定的提示前缀。常见示例如下：

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

不同提供商的实现各不相同。OpenAI 文档说明了对符合条件的提示前缀进行自动缓存，并在 API 使用情况中暴露缓存令牌细节；受支持的新模型也可以暴露缓存写入细节。Anthropic 支持显式缓存断点和多种生存时间选项。Google Gemini 支持带存储费用的显式上下文缓存，而 DeepSeek 文档说明了基于磁盘的自动上下文缓存，并对 cache-hit 和 cache-miss 输入采用不同费率。在将节省额计入预测之前，务必查阅提供商官方文档，确认当前模型支持情况和定价。

ROI 错误：衡量折扣而不是工作流

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

衡量真正重要的单位：

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

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

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

这可以防止出现一种误导性结果：令牌支出下降了，但重试、被拒绝的输出或人工复核却增加了。它还使提示缓存与更广泛的AI API 成本优化计划保持一致，而不是将缓存视为一个孤立的计费技巧。

六步提示缓存工作流

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

从请求轨迹入手，而不是凭直觉。按工作流对流量分组，并估算从一条请求开头到下一条请求开头，有多少输入令牌是完全相同的。

合适的候选项通常具有四个特征：

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

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

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

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

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

提示缓存通常依赖于从开头开始匹配提示词。前部哪怕只有很小的差异，也可能阻止其后所有内容的复用。

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

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

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

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

3. 定义缓存标识和失效策略

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

一个实用的缓存标识可以包含：

workflow + prompt_version + tool_schema_version + knowledge_version + model_family

在遥测中跟踪这个标识。当指令、工具契约或参考数据发生变化时，请递增相关版本。这样可以让成本变化变得可解释，并防止团队把预期失效误认为提供方故障。

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

4. 记录命中、未命中、写入和被接受结果

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

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

在可用时，请将提供方返回的用量字段作为计费的事实来源。如果提供方没有返回清晰的缓存命中标志，请谨慎地根据缓存 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

对于对缓存写入和读取收取不同 token 费率的提供商或模型，计算一个可复用前缀的生命周期：

uncached_scenario = prefix_tokens × total_uses × uncached_rate

cached_scenario = prefix_tokens × cache_writes × write_rate
                + prefix_tokens × cache_reads × read_rate
                + storage_cost

prefix_net_savings = uncached_scenario - cached_scenario

不要假设 cache_writes = 1。前缀变更、条目过期、路由变更或显式刷新都可能导致再次写入。

你可以估算某个已缓存前缀需要复用多少次才能达到盈亏平衡：

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% 的缓存输入折扣那么可观。

上述费率仅用于说明，并非当前提供商报价。请用你合同约定或公开发布的费率替换它们，并在适用时包含缓存写入、存储、区域定价、服务层级和网关费用。

可复制的提示缓存 ROI 工作表

请在工作流和提示版本层级构建该工作表。混合的账户级命中率可能会掩盖一个盈利缓存和许多浪费缓存。

使用这些公式：

eligible_prefix_tokens = R × P
observed_cached_tokens = H × P

baseline_prefix_cost = eligible_prefix_tokens × U

observed_prefix_cost = (H × P × C)
                     + (W × P × CW)
                     + S

net_savings = baseline_prefix_cost - observed_prefix_cost - O

net_savings_per_accepted_task = net_savings / A

请使用一致的费率单位，例如每 token 美元或每百万 token 美元。如果只有一部分前缀被报告为已缓存，则将 H × P 替换为提供商报告的缓存 token 总数。

一次缓存写入的盈亏平衡捷径

当只有一次初始写入、没有单独的存储费用，并且后续每次使用都是命中时：

break_even_reads = (write_rate - uncached_rate)
                 / (uncached_rate - read_rate)

向上取整到下一个完整读取次数。如果写入费率等于正常的未缓存费率，则首次成功复用就会带来毛节省。如果写入带有溢价，则需要更多次读取。考虑到未命中、失效、存储和工程成本，真实生产环境中的盈亏平衡点会更高。

6. 通过受控实验逐步上线

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

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

让控制组和实验组承载等效流量。在可能的情况下，保持模型、服务层级、最大输出、采样设置、工具集和回退策略不变。否则，模型或路由变化可能会被误认为是缓存带来的收益。

在大规模上线之前，执行三项有意的失效测试：

1. 更改提示版本，并确认旧缓存没有被错误归因到新的工作流。
2. 更改或重新排序工具 schema，并验证由此产生的未命中在遥测中可见。
3. 触发已批准的回退路径，并确认缓存丢失和增量成本被归因到回退尝试。

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

为期七天的提示缓存 ROI 审计

一次简短的生产环境审计，比基于宣传性缓存折扣做出的预测更可靠。目标不是证明缓存通常有效，而是判断某一个具体工作流、提示版本、模型路由和保留策略是否能产生可重复的价值。

每天创建一条审计记录，并在整个测试期间持续保留未缓存的对照组。如果工作日和周末流量不同，请延长测试，直到两种模式都出现。不要把繁忙的处理日与安静的历史基线进行比较。

使用匹配队列，而不是全账户平均值

使用稳定规则将可比较的请求分配到对照组和处理组，例如工作流 ID 加租户 ID 的哈希。这可以降低客户构成、提示长度或任务难度解释结果的可能性。不要将失败或重试排除在成本总额之外；它们是生产经济性的一部分。

至少按以下维度对审计进行分段：

• 工作流和提示版本。
• 模型和提供商路由。
• 缓存保留模式或 TTL。
• 当提示存在实质性差异时的租户类别。
• 成功、重试、回退以及被拒绝输出的结果。

按账户汇总的缓存命中率有助于监控，但对投资决策的参考价值有限。一个高流量工作流可能掩盖数十个缓存标识，这些标识持续写入，却很少被读取。

增加置信度和方差检查

不要把某一天的正向节省视为推广信号。计算每日净节省，并检查其范围，而不仅仅是总量。

daily_net_savings = daily_uncached_baseline_cost
                  - daily_observed_cached_cost
                  - daily_operating_cost

quality_adjusted_savings = daily_net_savings
                         / daily_accepted_tasks

将每日质量调整后节省的中位数作为主要汇总指标，然后报告最差的一天以及保持为正的天数占比。即使某个工作流平均节省很高，但如果反复出现负值日期，则可能对流量形态、过期时机或回退行为较为敏感。

如果流量较低，在审计开始前先定义最小观察次数。一条实用规则是，等到每个群组都有足够的已接受任务，能够包含正常重试、未命中，以及至少一个保留期到期周期。具体数量取决于工作流方差；不要把某个通用样本量描述为对所有应用都具有统计有效性。

Go、修复或停止的评估标准

在上线前设置止损规则。示例包括：被拒绝输出不可接受地增加、错误率回退、P95 延迟显著上升、出现意外的跨租户缓存标识，或每日支出超过团队预算容忍度。止损阈值应来自产品现有的服务目标和风险政策，而不是泛化的博客基准。

需要保留的审计记录

将最终决策与提示和路由配置一起存储，不要放在相互脱节的电子表格中。一个有用的审计记录应包括负责人、实验日期、提示哈希、工具模式哈希、模型路由、所用费率、原始用量字段映射、已接受任务定义、排除项、净节省、护栏结果、决策以及下次复审日期。

当定价、模型版本、保留行为或回退路由发生变化时，这份记录就尤其重要。当任何会实质影响写入、读取、存储或已接受结果的假设发生变化时，都应重新打开该决策。

提示缓存 KPI 仪表板

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

当重复前缀较小时，即使命中率很高，节省额也可能很弱。当前缀很大但命中率较低时，如果提示碎片化可以修复，仍然可能代表一个有价值的机会。应结合这些指标一起阅读。

常见的提示缓存失败模式

动态值放在开头

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

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

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

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

当流量稀疏或 TTL 过长时，显式创建缓存的成本可能高于它带来的收益。在延长保留时间之前，应按缓存标识衡量复用情况。

团队只优化 token 而忽略输出

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

默认认为提供商行为可以直接迁移

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

回退破坏缓存局部性

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

提供商实现检查清单

使用提供商适配器，而不是强行将每种实现塞进一个布尔型 cache_hit 字段：

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

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

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

现有 OpenAI 缓存仪表板的 2026 迁移检查

如果你的仪表板早于 GPT-5.6 支持，请确认它不会把所有未缓存的前缀 token 都归入普通输入成本。对于受支持的 GPT-5.6 请求，请单独检查 cache-write 使用情况，记录保留模式，并区分显式缓存写入与自动缓存读取。若仪表板仅跟踪 cached_tokens，在缓存创建费率更高时，可能会高估节省。

AI 网关的作用位置

统一的 AI 网关并不会让提供方缓存具备可移植性。每个提供方仍然控制其自身的缓存语义和计费方式。不过，网关可以为团队提供一个地方，用于统一模型标识、路由符合条件的工作负载、记录提供方特定的使用情况、比较每个已接受任务的成本，并执行回退或预算策略。

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

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

常见问题

提示缓存能节省多少成本？

节省幅度取决于可复用前缀、命中率、提供商定价、写入或存储费用以及实施成本。应根据实际观察到的缓存 token 来计算净节省，而不是把首页宣传的折扣直接应用到所有输入 token 上。

需要多少次缓存命中才能达到盈亏平衡？

这取决于写入溢价、读取折扣、存储费用和运营成本。如果写入按正常未缓存费率计费且没有存储费用，那么第一次成功读取就会带来总 token 节省。溢价写入或付费保留则需要更多复用。请根据所选模型的准确费率和实际观察到的缓存写入次数来计算盈亏平衡点。

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

没有通用的目标。一个有价值的命中率是能够带来正的净节省，并改善或保持每个已接受任务成本的命中率。大型前缀可以接受较低的命中率；较小的前缀可能需要非常高的复用率。

提示缓存能改善延迟吗？

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

我应该缓存整个对话吗？

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

缓存的提示可以跨提供商共享吗？

不可以。提供商侧提示缓存具有提供商特定性。如果路由切换了提供商或模型，除非提供商明确说明支持兼容复用，否则应将该请求视为大概率未命中。

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

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

从一个重复前缀开始

最佳的提示缓存工作流应刻意保持狭窄：选择一个成本高、复用率高的工作负载；将稳定内容前置；进行版本管理；衡量命中、未命中、延迟、质量和成本；然后计算净 ROI。

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