1. Prompt 缓存到底在解决什么问题第一次接触“Prompt 缓存”这个概念很多人会把它和传统的 HTTP 缓存、Redis 缓存混为一谈。实际上它要解决的是一个非常具体且烧钱的问题在大模型调用场景下如何避免为重复的系统提示词和上下文反复付费。我拿一个真实场景举例。假设你在做一个客服机器人每次用户提问时你都要把一段 3000 token 的系统提示词包含角色设定、业务规则、输出格式约束连同用户问题一起发给模型。如果一天有 10 万次调用这 3000 token 就要被重复计费 10 万次。按主流模型每百万 token 几美元到十几美元的价格算光系统提示词这一项一天就能烧掉几十甚至上百美元。而这段提示词在 99% 的请求里是完全一样的模型每次却要重新“读”一遍。Prompt 缓存的核心思路就是把不变的部分缓存起来让计费只针对变化的部分。这里的“不变的部分”通常指系统提示词、few-shot 示例、长文档上下文等前缀内容“变化的部分”则是用户当次的具体输入。理解了这一点你就能明白为什么缓存和计费是绑在一起讨论的——缓存的价值直接体现在账单上。适合读这篇内容的人包括正在做 LLM 应用开发、被 token 成本困扰的工程师需要给团队做成本优化的技术负责人以及想搞清楚 cache_control、断点这些概念到底怎么落地的人。下面我会从设计思路、核心机制、实操配置到踩坑排查把这件事讲透。2. 缓存机制的整体设计与选型考量2.1 为什么是“前缀缓存”而不是“结果缓存”很多人第一反应是既然请求重复那我直接把整个请求和响应存成键值对下次命中直接返回不就行了这个思路叫结果缓存听起来简单但在 LLM 场景下几乎不可行。原因在于用户输入哪怕差一个字语义就可能完全不同缓存命中率极低。而且大模型的输出本身带有随机性temperature 参数同一个问题两次回答不一样是正常的你缓存了结果反而可能返回过时的内容。更关键的是结果缓存无法处理“系统提示词相同但用户问题不同”这种最常见的场景——而这恰恰是成本大头。前缀缓存Prefix Caching则精准命中了这个痛点。它缓存的是请求的前缀部分也就是从第一个 token 开始、连续相同的那一段。系统提示词、固定的 few-shot 示例、长文档这些天然就是前缀。只要前缀一致后续用户问题怎么变都不影响缓存命中。这个设计的好处是命中率高、语义安全、计费逻辑清晰。2.2 计费模型背后的逻辑理解计费是理解缓存价值的关键。主流服务商的计费通常分三档计费类型说明相对价格普通输入 token未命中缓存的输入基准价 1x缓存写入 token首次建立缓存时的输入约 1.25x缓存读取 token命中缓存后读取的输入约 0.1x这张表是理解整个机制的钥匙。你会发现缓存写入比普通输入还贵这是很多人忽略的点。为什么因为服务商要额外做存储和索引成本更高。而缓存读取只要 0.1x便宜到几乎可以忽略。这就引出一个关键的决策逻辑只有当同一段前缀被复用的次数足够多时缓存才划算。如果一段提示词你只用一次那缓存写入的 1.25x 反而让你多花钱。我一般会算一笔账假设前缀是 P 个 token复用 N 次那么不缓存的总成本是 N×P缓存的总成本是 1.25×P (N-1)×0.1×P。令两者相等解出 N≈1.17也就是说复用 2 次以上缓存就开始省钱复用次数越多省得越狠。2.3 断点缓存的生命周期管理“断点”这个词在这里有两层含义容易混淆我分开说。第一层是缓存断点cache breakpoint指的是你在请求里显式标记“从这里开始的内容需要缓存”。它决定了缓存的边界在哪里。比如你把系统提示词标记为断点那么这段内容就会被写入缓存用户问题在断点之后不参与缓存。第二层是缓存失效断点指的是缓存什么时候过期。缓存不是永久的服务商通常设置 5 分钟左右的存活时间TTL每次命中会刷新这个时间。如果超过 TTL 没有新请求命中缓存就被清除下次请求需要重新写入。这个机制决定了你的应用必须保持一定的请求频率否则缓存频繁失效省钱的算盘就打空了。提示断点的位置选择直接决定缓存命中率。把最稳定、最长的内容放在断点之前把易变内容放在断点之后是基本原则。3. 核心细节解析与实操要点3.1 cache_control 参数怎么用以目前主流的实现方式为例缓存控制通常通过在消息结构里添加cache_control字段来实现。它的基本形态是这样的{ model: your-model, messages: [ { role: system, content: [ { type: text, text: 你是一个专业的客服助手以下是业务规则……此处省略3000字, cache_control: { type: ephemeral } } ] }, { role: user, content: 我的订单为什么还没发货 } ] }这里cache_control的type设为ephemeral意思是“临时缓存”对应前面说的 TTL 机制。这个字段加在哪条消息上就表示从请求开头到这条消息结束的内容都纳入缓存范围。注意它不是标记“这一条”而是标记“到这里为止的前缀”。实操中有个细节特别容易踩坑断点最多只能设 4 个不同服务商限制可能不同。这意味着你不能给每一段内容都打标记必须做取舍。我的经验是把最长的、最稳定的那段通常是系统提示词或长文档作为主断点其余短内容不值得单独设断点。3.2 断点位置的取舍策略断点放哪里是个需要结合业务反复调优的问题。我总结了三种典型场景场景一固定系统提示词 动态用户问题。这是最简单的断点放在系统提示词末尾即可。命中率取决于系统提示词是否真的固定——如果你在系统提示词里塞了当前时间、用户昵称这类变量那缓存永远命中不了。这是个高频错误我见过太多人把当前时间2024-xx-xx写进系统提示词结果缓存形同虚设。场景二多轮对话。多轮对话的缓存策略更复杂。因为历史消息会不断增长如果你把整个对话历史都缓存那每次新增一轮前缀就变了缓存失效。正确做法是把固定的系统提示词作为缓存断点对话历史放在断点之后。这样无论对话进行到第几轮系统提示词那部分始终命中缓存。场景三RAG 长文档。检索增强生成场景下同一篇文档可能被多个问题引用。这时可以把文档内容作为缓存断点让不同问题共享同一份文档的缓存。但要注意如果每次检索出的文档不同缓存命中率就会下降需要评估文档的复用频率。3.3 缓存命中的判定与监控缓存到底有没有命中不能靠猜。服务商的响应里通常会返回缓存相关的用量字段比如cache_creation_input_tokens写入缓存的 token 数和cache_read_input_tokens命中读取的 token 数。你要做的是把这些字段记录下来算命中率。我一般会监控三个指标缓存命中率命中读取 token / 总输入 token、缓存写入频率写入次数过多说明前缀不稳定、单次请求平均成本。如果命中率长期低于 50%说明你的断点策略有问题需要重新审视前缀的稳定性。注意缓存写入和读取是分开计费的监控时一定要把两者都统计进去否则会误判成本。4. 实操过程与核心环节实现4.1 从零搭建一个带缓存的调用流程我拿一个 Python 示例把完整流程走一遍。假设你用的是支持缓存的主流 SDK核心步骤分四步构造带断点的请求、发送、解析缓存用量、记录监控。import time def build_cached_request(system_prompt, user_question): return { model: your-model, messages: [ { role: system, content: [ { type: text, text: system_prompt, cache_control: {type: ephemeral} } ] }, { role: user, content: user_question } ] } def call_with_cache(client, system_prompt, user_question): req build_cached_request(system_prompt, user_question) resp client.messages.create(**req) usage resp.usage cache_write getattr(usage, cache_creation_input_tokens, 0) cache_read getattr(usage, cache_read_input_tokens, 0) normal_input usage.input_tokens return { text: resp.content[0].text, cache_write: cache_write, cache_read: cache_read, normal_input: normal_input }这段代码的关键在于cache_control的位置和用量字段的提取。第一次调用时cache_write会有值cache_read为 0第二次用同样的 system_prompt 调用时cache_read就会有值cache_write归零。你可以用这个特征来验证缓存是否生效。4.2 参数计算到底能省多少钱光说省钱不够得算出来。我拿一个具体例子演示。假设系统提示词 4000 token用户问题平均 200 token每天 5 万次调用模型输入价格按每百万 token 3 美元计算。不缓存的情况每次输入 4200 token总输入 5万×4200 2.1 亿 token成本 210×3 630 美元。缓存的情况第一次写入 4000 token按 1.25x 计后续 49999 次命中读取 4000 token按 0.1x 计用户问题 200 token 始终按 1x 计。缓存写入成本4000/1e6 × 3 × 1.25 0.015 美元缓存读取成本49999×4000/1e6 × 3 × 0.1 59.99 美元用户问题成本5万×200/1e6 × 3 30 美元总成本 ≈ 90 美元对比 630 美元省了约 85%。这个数字足够说明问题。但前提是缓存命中率要高如果 TTL 内没有持续请求缓存频繁失效写入成本就会累积省钱效果大打折扣。4.3 保持缓存活性的工程手段缓存 TTL 通常只有几分钟如果你的应用请求是稀疏的比如内部工具几分钟才来一个请求缓存很容易过期。我试过几种保持活性的办法第一种是预热请求。在业务低峰期定时发送一个只包含系统提示词的轻量请求把缓存“续命”。这个请求本身也消耗 token但比缓存失效后重新写入要便宜。第二种是合并请求。如果多个用户的问题可以批量处理尽量在时间上聚拢让缓存命中集中在 TTL 窗口内。第三种是调整断点粒度。如果系统提示词太长导致写入成本高可以考虑拆分把最核心的部分设为断点次要部分不缓存。这样即使缓存失效重新写入的成本也可控。提示预热请求的频率要略小于 TTL比如 TTL 是 5 分钟那就每 4 分钟预热一次留出安全余量。5. 常见问题与排查技巧实录5.1 缓存不命中的典型原因缓存明明配了却不命中是最让人抓狂的问题。我把踩过的坑整理成一张速查表现象可能原因排查方法cache_read 始终为 0前缀里有变量时间、ID检查系统提示词是否含动态内容命中率忽高忽低请求间隔超过 TTL统计请求时间分布写入成本异常高断点位置太靠后检查断点是否包含了易变内容换了模型后失效缓存不跨模型共享确认模型版本一致多轮对话命中率低历史消息参与了缓存把断点前移到系统提示词最常见的就是第一条。我见过一个项目系统提示词里写了“当前日期{today}”结果每天缓存只能命中当天跨天就失效。把日期从系统提示词里挪到用户消息里命中率立刻上去了。5.2 缓存与计费的边界问题有几个边界情况需要特别注意。第一缓存写入的 token 也计入总输入所以你在估算成本时不能只算读取部分。第二不同服务商的缓存不互通你在这家建的缓存换到另一家要重新建。第三缓存是按前缀精确匹配的哪怕差一个空格、一个标点都会导致不命中。这就要求你的提示词模板必须严格一致不能有随机的空白字符。还有个容易被忽略的点流式输出不影响缓存。缓存针对的是输入侧输出是流式还是非流式对缓存命中没有影响。但流式响应下用量字段可能出现在最后一个 chunk 里解析时要注意。5.3 独家避坑经验分享几个文档里不会写、但实际很要命的经验。经验一断点不要贪多。前面说过最多 4 个断点但我的建议是能用 1 个就别用 2 个。断点越多管理越复杂而且每个断点都会产生独立的写入成本。除非你有明确的多段复用需求否则一个主断点足够。经验二先测命中率再上生产。我习惯在灰度环境跑一周统计真实命中率。如果低于 60%说明前缀设计有问题别急着上生产否则可能比不缓存还贵。经验三把缓存用量写进日志。每次请求都记录 cache_write 和 cache_read这样出问题时能快速定位。我一般还会加个告警如果连续 10 次请求 cache_read 都是 0就触发提醒说明缓存可能挂了。经验四注意提示词版本管理。如果你更新了系统提示词旧缓存就失效了需要重新写入。所以提示词变更要尽量批量进行避免频繁小改导致缓存反复重建。6. 缓存策略的进阶玩法6.1 多级断点的组合使用当你确实有多段稳定内容时多级断点能进一步提升命中率。比如一个复杂应用前面是通用角色设定所有请求共享中间是业务领域规则同类请求共享后面是具体任务指令单类请求共享。这时可以设三个断点让不同层级的请求各取所需。但要注意多级断点的命中是“前缀式”的——如果第一段变了后面全部失效。所以层级顺序要按稳定性从高到低排列最稳定的放最前面。6.2 缓存与提示词工程的配合缓存策略会反过来影响你写提示词的方式。为了让前缀更稳定我会有意识地把提示词结构化为“固定部分 可变部分”固定部分尽量长、尽量通用可变部分尽量短、尽量靠后。这其实和提示词工程里“把指令放前面、把数据放后面”的原则是一致的两者可以协同优化。另外few-shot 示例是缓存的好朋友。如果你有 10 个示例把它们放在系统提示词里作为缓存前缀比每次动态拼接要省得多。前提是这些示例对所有请求都适用。6.3 成本监控的长期机制缓存优化不是一锤子买卖需要长期监控。我建议搭一个简单的看板跟踪每日的缓存命中率、写入次数、平均单次成本。当这些指标出现异常波动时及时排查。比如某天写入次数突然翻倍很可能是有人改了提示词模板导致前缀变化。这套机制跑顺之后你会发现 LLM 应用的成本变得可预测、可控制不再是月底看账单时的心惊肉跳。我自己在几个项目上落地下来输入侧成本普遍降到了原来的 15% 到 25%效果相当实在。最后分享一个我常用的判断标准如果你的系统提示词超过 1000 token且每天调用超过 1000 次那就值得上缓存。低于这个量级缓存的收益可能覆盖不了管理成本。这个阈值不是绝对的你可以根据自己的实际账单反推。 Prompt缓存实战：如何大幅降低大模型调用成本
1. Prompt 缓存到底在解决什么问题第一次接触“Prompt 缓存”这个概念很多人会把它和传统的 HTTP 缓存、Redis 缓存混为一谈。实际上它要解决的是一个非常具体且烧钱的问题在大模型调用场景下如何避免为重复的系统提示词和上下文反复付费。我拿一个真实场景举例。假设你在做一个客服机器人每次用户提问时你都要把一段 3000 token 的系统提示词包含角色设定、业务规则、输出格式约束连同用户问题一起发给模型。如果一天有 10 万次调用这 3000 token 就要被重复计费 10 万次。按主流模型每百万 token 几美元到十几美元的价格算光系统提示词这一项一天就能烧掉几十甚至上百美元。而这段提示词在 99% 的请求里是完全一样的模型每次却要重新“读”一遍。Prompt 缓存的核心思路就是把不变的部分缓存起来让计费只针对变化的部分。这里的“不变的部分”通常指系统提示词、few-shot 示例、长文档上下文等前缀内容“变化的部分”则是用户当次的具体输入。理解了这一点你就能明白为什么缓存和计费是绑在一起讨论的——缓存的价值直接体现在账单上。适合读这篇内容的人包括正在做 LLM 应用开发、被 token 成本困扰的工程师需要给团队做成本优化的技术负责人以及想搞清楚 cache_control、断点这些概念到底怎么落地的人。下面我会从设计思路、核心机制、实操配置到踩坑排查把这件事讲透。2. 缓存机制的整体设计与选型考量2.1 为什么是“前缀缓存”而不是“结果缓存”很多人第一反应是既然请求重复那我直接把整个请求和响应存成键值对下次命中直接返回不就行了这个思路叫结果缓存听起来简单但在 LLM 场景下几乎不可行。原因在于用户输入哪怕差一个字语义就可能完全不同缓存命中率极低。而且大模型的输出本身带有随机性temperature 参数同一个问题两次回答不一样是正常的你缓存了结果反而可能返回过时的内容。更关键的是结果缓存无法处理“系统提示词相同但用户问题不同”这种最常见的场景——而这恰恰是成本大头。前缀缓存Prefix Caching则精准命中了这个痛点。它缓存的是请求的前缀部分也就是从第一个 token 开始、连续相同的那一段。系统提示词、固定的 few-shot 示例、长文档这些天然就是前缀。只要前缀一致后续用户问题怎么变都不影响缓存命中。这个设计的好处是命中率高、语义安全、计费逻辑清晰。2.2 计费模型背后的逻辑理解计费是理解缓存价值的关键。主流服务商的计费通常分三档计费类型说明相对价格普通输入 token未命中缓存的输入基准价 1x缓存写入 token首次建立缓存时的输入约 1.25x缓存读取 token命中缓存后读取的输入约 0.1x这张表是理解整个机制的钥匙。你会发现缓存写入比普通输入还贵这是很多人忽略的点。为什么因为服务商要额外做存储和索引成本更高。而缓存读取只要 0.1x便宜到几乎可以忽略。这就引出一个关键的决策逻辑只有当同一段前缀被复用的次数足够多时缓存才划算。如果一段提示词你只用一次那缓存写入的 1.25x 反而让你多花钱。我一般会算一笔账假设前缀是 P 个 token复用 N 次那么不缓存的总成本是 N×P缓存的总成本是 1.25×P (N-1)×0.1×P。令两者相等解出 N≈1.17也就是说复用 2 次以上缓存就开始省钱复用次数越多省得越狠。2.3 断点缓存的生命周期管理“断点”这个词在这里有两层含义容易混淆我分开说。第一层是缓存断点cache breakpoint指的是你在请求里显式标记“从这里开始的内容需要缓存”。它决定了缓存的边界在哪里。比如你把系统提示词标记为断点那么这段内容就会被写入缓存用户问题在断点之后不参与缓存。第二层是缓存失效断点指的是缓存什么时候过期。缓存不是永久的服务商通常设置 5 分钟左右的存活时间TTL每次命中会刷新这个时间。如果超过 TTL 没有新请求命中缓存就被清除下次请求需要重新写入。这个机制决定了你的应用必须保持一定的请求频率否则缓存频繁失效省钱的算盘就打空了。提示断点的位置选择直接决定缓存命中率。把最稳定、最长的内容放在断点之前把易变内容放在断点之后是基本原则。3. 核心细节解析与实操要点3.1 cache_control 参数怎么用以目前主流的实现方式为例缓存控制通常通过在消息结构里添加cache_control字段来实现。它的基本形态是这样的{ model: your-model, messages: [ { role: system, content: [ { type: text, text: 你是一个专业的客服助手以下是业务规则……此处省略3000字, cache_control: { type: ephemeral } } ] }, { role: user, content: 我的订单为什么还没发货 } ] }这里cache_control的type设为ephemeral意思是“临时缓存”对应前面说的 TTL 机制。这个字段加在哪条消息上就表示从请求开头到这条消息结束的内容都纳入缓存范围。注意它不是标记“这一条”而是标记“到这里为止的前缀”。实操中有个细节特别容易踩坑断点最多只能设 4 个不同服务商限制可能不同。这意味着你不能给每一段内容都打标记必须做取舍。我的经验是把最长的、最稳定的那段通常是系统提示词或长文档作为主断点其余短内容不值得单独设断点。3.2 断点位置的取舍策略断点放哪里是个需要结合业务反复调优的问题。我总结了三种典型场景场景一固定系统提示词 动态用户问题。这是最简单的断点放在系统提示词末尾即可。命中率取决于系统提示词是否真的固定——如果你在系统提示词里塞了当前时间、用户昵称这类变量那缓存永远命中不了。这是个高频错误我见过太多人把当前时间2024-xx-xx写进系统提示词结果缓存形同虚设。场景二多轮对话。多轮对话的缓存策略更复杂。因为历史消息会不断增长如果你把整个对话历史都缓存那每次新增一轮前缀就变了缓存失效。正确做法是把固定的系统提示词作为缓存断点对话历史放在断点之后。这样无论对话进行到第几轮系统提示词那部分始终命中缓存。场景三RAG 长文档。检索增强生成场景下同一篇文档可能被多个问题引用。这时可以把文档内容作为缓存断点让不同问题共享同一份文档的缓存。但要注意如果每次检索出的文档不同缓存命中率就会下降需要评估文档的复用频率。3.3 缓存命中的判定与监控缓存到底有没有命中不能靠猜。服务商的响应里通常会返回缓存相关的用量字段比如cache_creation_input_tokens写入缓存的 token 数和cache_read_input_tokens命中读取的 token 数。你要做的是把这些字段记录下来算命中率。我一般会监控三个指标缓存命中率命中读取 token / 总输入 token、缓存写入频率写入次数过多说明前缀不稳定、单次请求平均成本。如果命中率长期低于 50%说明你的断点策略有问题需要重新审视前缀的稳定性。注意缓存写入和读取是分开计费的监控时一定要把两者都统计进去否则会误判成本。4. 实操过程与核心环节实现4.1 从零搭建一个带缓存的调用流程我拿一个 Python 示例把完整流程走一遍。假设你用的是支持缓存的主流 SDK核心步骤分四步构造带断点的请求、发送、解析缓存用量、记录监控。import time def build_cached_request(system_prompt, user_question): return { model: your-model, messages: [ { role: system, content: [ { type: text, text: system_prompt, cache_control: {type: ephemeral} } ] }, { role: user, content: user_question } ] } def call_with_cache(client, system_prompt, user_question): req build_cached_request(system_prompt, user_question) resp client.messages.create(**req) usage resp.usage cache_write getattr(usage, cache_creation_input_tokens, 0) cache_read getattr(usage, cache_read_input_tokens, 0) normal_input usage.input_tokens return { text: resp.content[0].text, cache_write: cache_write, cache_read: cache_read, normal_input: normal_input }这段代码的关键在于cache_control的位置和用量字段的提取。第一次调用时cache_write会有值cache_read为 0第二次用同样的 system_prompt 调用时cache_read就会有值cache_write归零。你可以用这个特征来验证缓存是否生效。4.2 参数计算到底能省多少钱光说省钱不够得算出来。我拿一个具体例子演示。假设系统提示词 4000 token用户问题平均 200 token每天 5 万次调用模型输入价格按每百万 token 3 美元计算。不缓存的情况每次输入 4200 token总输入 5万×4200 2.1 亿 token成本 210×3 630 美元。缓存的情况第一次写入 4000 token按 1.25x 计后续 49999 次命中读取 4000 token按 0.1x 计用户问题 200 token 始终按 1x 计。缓存写入成本4000/1e6 × 3 × 1.25 0.015 美元缓存读取成本49999×4000/1e6 × 3 × 0.1 59.99 美元用户问题成本5万×200/1e6 × 3 30 美元总成本 ≈ 90 美元对比 630 美元省了约 85%。这个数字足够说明问题。但前提是缓存命中率要高如果 TTL 内没有持续请求缓存频繁失效写入成本就会累积省钱效果大打折扣。4.3 保持缓存活性的工程手段缓存 TTL 通常只有几分钟如果你的应用请求是稀疏的比如内部工具几分钟才来一个请求缓存很容易过期。我试过几种保持活性的办法第一种是预热请求。在业务低峰期定时发送一个只包含系统提示词的轻量请求把缓存“续命”。这个请求本身也消耗 token但比缓存失效后重新写入要便宜。第二种是合并请求。如果多个用户的问题可以批量处理尽量在时间上聚拢让缓存命中集中在 TTL 窗口内。第三种是调整断点粒度。如果系统提示词太长导致写入成本高可以考虑拆分把最核心的部分设为断点次要部分不缓存。这样即使缓存失效重新写入的成本也可控。提示预热请求的频率要略小于 TTL比如 TTL 是 5 分钟那就每 4 分钟预热一次留出安全余量。5. 常见问题与排查技巧实录5.1 缓存不命中的典型原因缓存明明配了却不命中是最让人抓狂的问题。我把踩过的坑整理成一张速查表现象可能原因排查方法cache_read 始终为 0前缀里有变量时间、ID检查系统提示词是否含动态内容命中率忽高忽低请求间隔超过 TTL统计请求时间分布写入成本异常高断点位置太靠后检查断点是否包含了易变内容换了模型后失效缓存不跨模型共享确认模型版本一致多轮对话命中率低历史消息参与了缓存把断点前移到系统提示词最常见的就是第一条。我见过一个项目系统提示词里写了“当前日期{today}”结果每天缓存只能命中当天跨天就失效。把日期从系统提示词里挪到用户消息里命中率立刻上去了。5.2 缓存与计费的边界问题有几个边界情况需要特别注意。第一缓存写入的 token 也计入总输入所以你在估算成本时不能只算读取部分。第二不同服务商的缓存不互通你在这家建的缓存换到另一家要重新建。第三缓存是按前缀精确匹配的哪怕差一个空格、一个标点都会导致不命中。这就要求你的提示词模板必须严格一致不能有随机的空白字符。还有个容易被忽略的点流式输出不影响缓存。缓存针对的是输入侧输出是流式还是非流式对缓存命中没有影响。但流式响应下用量字段可能出现在最后一个 chunk 里解析时要注意。5.3 独家避坑经验分享几个文档里不会写、但实际很要命的经验。经验一断点不要贪多。前面说过最多 4 个断点但我的建议是能用 1 个就别用 2 个。断点越多管理越复杂而且每个断点都会产生独立的写入成本。除非你有明确的多段复用需求否则一个主断点足够。经验二先测命中率再上生产。我习惯在灰度环境跑一周统计真实命中率。如果低于 60%说明前缀设计有问题别急着上生产否则可能比不缓存还贵。经验三把缓存用量写进日志。每次请求都记录 cache_write 和 cache_read这样出问题时能快速定位。我一般还会加个告警如果连续 10 次请求 cache_read 都是 0就触发提醒说明缓存可能挂了。经验四注意提示词版本管理。如果你更新了系统提示词旧缓存就失效了需要重新写入。所以提示词变更要尽量批量进行避免频繁小改导致缓存反复重建。6. 缓存策略的进阶玩法6.1 多级断点的组合使用当你确实有多段稳定内容时多级断点能进一步提升命中率。比如一个复杂应用前面是通用角色设定所有请求共享中间是业务领域规则同类请求共享后面是具体任务指令单类请求共享。这时可以设三个断点让不同层级的请求各取所需。但要注意多级断点的命中是“前缀式”的——如果第一段变了后面全部失效。所以层级顺序要按稳定性从高到低排列最稳定的放最前面。6.2 缓存与提示词工程的配合缓存策略会反过来影响你写提示词的方式。为了让前缀更稳定我会有意识地把提示词结构化为“固定部分 可变部分”固定部分尽量长、尽量通用可变部分尽量短、尽量靠后。这其实和提示词工程里“把指令放前面、把数据放后面”的原则是一致的两者可以协同优化。另外few-shot 示例是缓存的好朋友。如果你有 10 个示例把它们放在系统提示词里作为缓存前缀比每次动态拼接要省得多。前提是这些示例对所有请求都适用。6.3 成本监控的长期机制缓存优化不是一锤子买卖需要长期监控。我建议搭一个简单的看板跟踪每日的缓存命中率、写入次数、平均单次成本。当这些指标出现异常波动时及时排查。比如某天写入次数突然翻倍很可能是有人改了提示词模板导致前缀变化。这套机制跑顺之后你会发现 LLM 应用的成本变得可预测、可控制不再是月底看账单时的心惊肉跳。我自己在几个项目上落地下来输入侧成本普遍降到了原来的 15% 到 25%效果相当实在。最后分享一个我常用的判断标准如果你的系统提示词超过 1000 token且每天调用超过 1000 次那就值得上缓存。低于这个量级缓存的收益可能覆盖不了管理成本。这个阈值不是绝对的你可以根据自己的实际账单反推。