❝同样的问题问了三遍Token 费用交了三份钱。❞一、先搞清楚钱花在哪了大模型的计费逻辑其实很简单「按 Token 数收费」输入输出分开算。但问题来了——很多场景下你的输入其实在重复。举个例子你做了一个财报分析助手用户上传一份 50 页的年报大约 10 万 Token然后问了三个问题这家公司去年营收多少利润同比增长了吗现金流怎么样按传统方式每次提问你都得把那 10 万 Token 的财报重新发给模型。三个问题就是 30 万 Token 的输入费用。「但实际上那份财报从头到尾都没变过。」这就是缓存要解决的问题「重复的内容只计算一次后面再用就从缓存读取费用大幅降低。」二、各家的缓存机制目前主流大模型都支持某种形式的缓存。我把它们分成三类第一类自动缓存OpenAI、Gemini这类最省心「你什么都不用做系统自动帮你缓存」。OpenAI 从 2024 年底开始对所有 GPT-4o 和 GPT-4o-mini 的请求自动启用缓存。只要你的请求前缀比如 System Prompt 文档内容和之前的请求一样就会自动命中缓存。「缓存命中后输入费用直接打 5 折。」Gemini 也类似缓存命中部分可以省 75%。听起来很美好对吧但有个坑「缓存只保留几分钟到十几分钟」。如果你的用户用完就走下次来又是新的一笔账。第二类手动标记Anthropic ClaudeClaude 的缓存需要你主动告诉它这部分内容我想缓存。怎么告诉在消息里加一个cache_control标记{ role: user, content: [ { type: text, text: 这是一份很长的文档内容..., cache_control: { type: ephemeral } } ] }Claude 的优势是「信息更透明」。它会在返回结果里告诉你cache_creation_input_tokens本次创建缓存用了多少 Tokencache_read_input_tokens本次从缓存读取了多少 Token「缓存命中的部分费用只有原价的 10%」——这是各家里折扣最狠的。但缺点也明显缓存只保留 5 分钟而且第一次创建缓存还要多付 25% 的写入费。适合短时间内高频使用同一份上下文的场景。第三类硬盘缓存派DeepSeekDeepSeek 玩了个不一样的——「把缓存存到硬盘上」。这带来一个巨大优势「缓存可以保留几小时甚至几天」。传统的内存缓存用户中午问完问题晚上再来问缓存早就没了。但 DeepSeek 的硬盘缓存可以一直在那等着你。而且它完全自动不需要任何配置。每个请求都会自动触发缓存构建后续请求如果前缀重复就直接命中。「缓存命中部分费用是 0.1 元/百万 Token比正常价格低了整整一个数量级。」它的返回结果也很清晰{ usage: { prompt_tokens: 10000, prompt_cache_hit_tokens: 9500, prompt_cache_miss_tokens: 500 } }一目了然9500 个 Token 命中缓存只有 500 个需要正常计费。三、缓存到底是怎么实现的聊完各家的使用方式你可能会好奇缓存背后的技术原理是什么为什么前缀一样就能命中硬盘缓存和内存缓存有什么本质区别这一节我们来掀开盖子看看。1. KV CacheTransformer 的记忆本要理解 Prompt 缓存首先得知道大模型推理时有个东西叫「KV Cache」。简单说Transformer 模型在处理输入时会为每一层、每个 Token 计算一组 Key 和 Value 向量这就是 Attention 机制的核心。这些 K/V 向量在后续生成过程中会被反复用到。如果没有 KV Cache模型每生成一个新 Token就得把之前所有 Token 的 K/V 重新算一遍——这显然是巨大的浪费。所以模型会把已经计算过的 K/V 存起来这就是 KV Cache。输入: [System Prompt] [文档] [问题] └─────────────────────┘ └──┘ 已计算,存入 KV Cache 新增部分,增量计算「Prompt 缓存本质上就是把这些 KV Cache 保存下来供后续请求复用。」2. 前缀匹配机制为什么顺序很重要这里有个关键点「KV Cache 只能按前缀复用」。为什么因为 Transformer 是自回归模型每个位置的 K/V 都依赖于它前面所有位置的信息。如果中间某个 Token 变了后面所有的 K/V 都会受影响只能重新计算。请求 A: [角色设定] [规则说明] [文档内容] [问题1] 请求 B: [角色设定] [规则说明] [文档内容] [问题2] └────────────────────────────┘ └────┘ 前缀完全相同 不同 可以复用 需重算这就是为什么所有缓存方案都强调前缀匹配——不是内容相同而是从头开始连续相同。举个反例请求 A: [角色设定] [文档内容] [问题] 请求 B: [文档内容] [角色设定] [问题] ← 顺序变了缓存完全失效内容一模一样只是顺序变了缓存就用不上了。3. 自动缓存 vs 手动标记两种实现思路各家的缓存机制虽然使用方式不同底层实现思路大体分两种自动打点机制OpenAI/Gemini/DeepSeek这类方案的核心思想是「模型服务端自动识别可缓存的边界」。具体来说服务端会对请求内容计算哈希签名按固定粒度通常 64-128 Token切分成块逐块检查是否与之前的请求匹配匹配上的块直接读取缓存没匹配的块重新计算请求内容[块1][块2][块3][块4][块5][块6][块7] 缓存状态[命中][命中][命中][命中][命中][未命中][未命中] ↑ 缓存边界这种方式对用户完全透明不需要任何配置。但代价是「服务端需要维护大量的缓存索引」而且用户无法精确控制缓存行为。显式标记机制Anthropic ClaudeClaude 走了另一条路「让用户明确告诉模型哪些内容需要缓存」。{ content: [ { type: text, text: 这部分我要缓存, cache_control: { type: ephemeral } // 明确标记 }, { type: text, text: 这部分不缓存 } ] }模型收到带cache_control标记的内容后会为标记的内容块计算 KV Cache生成一个缓存 ID后续请求带上相同的内容块时直接读取缓存这种方式的优势是「精确可控」你可以只缓存真正需要的部分避免浪费。但需要手动管理缓存边界对开发者要求更高。4. 内存缓存 vs 硬盘缓存持久性的代价OpenAI 和 Claude 用的都是「内存缓存」RAMDeepSeek 用的是「硬盘缓存」SSD。为什么这个区别很重要看看两者的特点内存缓存硬盘缓存读写速度极快纳秒级较快微秒级容量成本贵RAM 价格高便宜SSD 大量部署持久性短进程重启就没了长断电也能保留典型时长5-15 分钟数小时~数天内存缓存的问题是「容量有限只能用 LRU 淘汰策略不活跃的缓存很快就会被挤掉。」而且模型服务通常是分布式部署请求可能被分发到不同的节点缓存命中率进一步下降。DeepSeek 的硬盘缓存选择了另一条路用 SSD 阵列存储 KV Cache容量大幅提升为每个用户/请求前缀建立持久化的缓存索引请求来了先查硬盘命中就直接加载到显存里用代价是「首次请求会慢几秒」需要把 KV Cache 从硬盘加载到显存但换来的是长达数天的缓存存活期。5. 缓存粒度64 Token 和 1024 Token 的区别各家对最小缓存单元的设定不同DeepSeek64 TokenOpenAI/Claude/Gemini1024-2048 Token为什么差这么多这涉及到「缓存管理的复杂度和空间开销」。粒度越小理论上缓存命中率越高——两个请求只要有 64 Token 的公共前缀就能部分命中。但代价是「缓存索引会变得很大」查找和匹配的开销也会上升。粒度越大管理更简单但「短内容就享受不到缓存红利了」。比如你的 System Prompt 只有 500 Token在 OpenAI 那里根本不会被缓存。DeepSeek 能做到 64 Token 的细粒度很可能是因为它的硬盘缓存架构允许维护更大的索引空间而内存缓存受限于 RAM 容量不得不用更粗的粒度来控制开销。理解了这些原理你就能明白为什么改变前缀顺序会导致缓存失效在开头加时间戳是个坏主意DeepSeek 的缓存能活那么久Claude 需要手动标记才能获得最优效果四、灵魂拷问我到底能省多少钱来算一笔真实的账。假设你有一个文档问答助手用户上传一份 5 万 Token 的文档然后平均会问 5 个问题。「不用缓存的情况」以 GPT-4o 为例每次输入50000 Token × 5 次 250000 Token 费用250000 × $2.5/百万 $0.625「用缓存的情况」首次输入50000 Token正常价 后续 4 次50000 × 4 200000 Token缓存价5 折 费用50000 × $2.5/百万 200000 × $1.25/百万 $0.375 节省40%如果换成 DeepSeek 的硬盘缓存呢首次输入50000 Token¥1/百万 ¥0.05 后续 4 次200000 Token¥0.1/百万 ¥0.02 总费用¥0.07同样的场景「DeepSeek 的费用不到 GPT-4o 的十分之一」。当然模型能力有差异这个账不能简单对比。但如果你的场景对模型要求不是特别高缓存机制的差异确实能带来可观的成本优势。五、怎么知道缓存有没有生效这是很多人忽略的问题缓存开了但怎么确认它真的在工作各家都会在 API 返回的usage字段里告诉你缓存命中情况模型缓存命中字段OpenAIusage.prompt_tokens_details.cached_tokensClaudeusage.cache_read_input_tokensGeminiusage.cachedContentTokenCountDeepSeekusage.prompt_cache_hit_tokens简单写个监控把每次请求的缓存命中率记录下来def log_cache_stats(response): usage response.usage total usage.prompt_tokens cached usage.prompt_tokens_details.cached_tokens # OpenAI 为例 hit_rate cached / total * 100 if total 0 else 0 print(f缓存命中率: {hit_rate:.1f}% ({cached}/{total}))如果你发现命中率长期很低那就得检查一下是不是哪里出了问题。六、工程实战如何组织上下文以最大化缓存命中聊了原理和常见问题但真正落地时你会发现「最核心的工作其实是上下文的组织方式」。1. 黄金法则稳定内容永远放前面这是最重要的一条原则。根据前缀匹配机制「只有从头开始连续相同的部分才能命中缓存」。所以你的上下文组织应该遵循这个顺序[稳定度高的内容] → [稳定度中的内容] → [稳定度低的内容] → [动态内容]「反面教材」有些开发者喜欢在 System Prompt 开头加时间戳或请求 ID# ❌ 错误做法 system_prompt f当前时间{datetime.now()}请求ID{uuid4()}\n你是一个客服助手... # ✅ 正确做法 system_prompt 你是一个客服助手... # 时间信息放到最后或者用工具调用获取一个动态字符放在开头整个缓存链就断了。2. 内容分层把 Prompt 当作洋葱来设计在实际生产中我们通常会把 Prompt 拆分成多个独立的层每层有自己的更新频率class PromptBuilder: def __init__(self): # 第 1 层核心人设几乎永不变 self.core_persona 你是一个专业的金融分析师具备以下能力 - 解读财务报表 - 分析行业趋势 - 给出投资建议 # 第 2 层通用规则很少变 self.rules 请遵循以下规则 1. 所有分析必须基于提供的数据不要编造 2. 涉及具体数字时要标注来源 3. 风险提示要放在建议之后 # 第 3 层领域知识按需加载 self.domain_knowledge None # 第 4 层示例按场景切换 self.examples None def build(self, user_query, context_docsNone, examplesNone): layers [ self.core_persona, self.rules, ] if context_docs: layers.append(f参考文档\n{context_docs}) if examples: layers.append(f参考示例\n{examples}) layers.append(f用户问题{user_query}) return\n\n.join(layers)这样设计的好处是「即使领域知识或示例变了核心人设和规则的缓存还能命中」。3. 多租户场景按租户隔离 vs 共享前缀如果你的应用服务多个客户多租户有两种组织策略「策略 A每个租户独立前缀」租户 A[租户A的System Prompt] [租户A的知识库] [用户输入] 租户 B[租户B的System Prompt] [租户B的知识库] [用户输入]优点每个租户的缓存完全独立互不干扰 缺点缓存利用率低因为不同租户之间无法共享「策略 B共享通用前缀 租户差异后置」所有租户[通用System Prompt] [通用规则] [租户特定配置] [用户输入]优点通用部分可以跨租户复用缓存命中率高 缺点需要仔细设计通用和特定的边界「我的建议」如果租户数量多且差异不大比如 SaaS 产品优先用策略 B。如果租户差异很大比如定制化项目用策略 A。掌握了这些组织技巧你就能在不改业务逻辑的情况下把缓存命中率从 30% 提升到 80% 以上。七、写在最后大模型的缓存机制本质上是在帮你做一件事「为重复的工作只付一次钱」。它不是什么高深的技术优化而是实实在在的成本控制手段。对于月调用量上百万 Token 的应用来说用好缓存省下的钱可能比换一个便宜模型还多。最后总结一张表方便你按需选择OpenAIClaudeGeminiDeepSeek配置难度⭐ 自动⭐⭐⭐ 手动⭐ 自动⭐ 自动缓存时长5-15分钟5分钟可配置数小时~天价格折扣50%90%75%90%最小 Token10241024102464适合场景高频短对话精细化控制长时缓存低频长文档❝觉得有用的话「点赞 在看 收藏⭐」一键三连下次找起来方便也能让更多人看到。❞点击 头像关注我一起探索 AI 领域的更多可能 ✌️
省90%成本！你还在为大模型调用费发愁吗？
❝同样的问题问了三遍Token 费用交了三份钱。❞一、先搞清楚钱花在哪了大模型的计费逻辑其实很简单「按 Token 数收费」输入输出分开算。但问题来了——很多场景下你的输入其实在重复。举个例子你做了一个财报分析助手用户上传一份 50 页的年报大约 10 万 Token然后问了三个问题这家公司去年营收多少利润同比增长了吗现金流怎么样按传统方式每次提问你都得把那 10 万 Token 的财报重新发给模型。三个问题就是 30 万 Token 的输入费用。「但实际上那份财报从头到尾都没变过。」这就是缓存要解决的问题「重复的内容只计算一次后面再用就从缓存读取费用大幅降低。」二、各家的缓存机制目前主流大模型都支持某种形式的缓存。我把它们分成三类第一类自动缓存OpenAI、Gemini这类最省心「你什么都不用做系统自动帮你缓存」。OpenAI 从 2024 年底开始对所有 GPT-4o 和 GPT-4o-mini 的请求自动启用缓存。只要你的请求前缀比如 System Prompt 文档内容和之前的请求一样就会自动命中缓存。「缓存命中后输入费用直接打 5 折。」Gemini 也类似缓存命中部分可以省 75%。听起来很美好对吧但有个坑「缓存只保留几分钟到十几分钟」。如果你的用户用完就走下次来又是新的一笔账。第二类手动标记Anthropic ClaudeClaude 的缓存需要你主动告诉它这部分内容我想缓存。怎么告诉在消息里加一个cache_control标记{ role: user, content: [ { type: text, text: 这是一份很长的文档内容..., cache_control: { type: ephemeral } } ] }Claude 的优势是「信息更透明」。它会在返回结果里告诉你cache_creation_input_tokens本次创建缓存用了多少 Tokencache_read_input_tokens本次从缓存读取了多少 Token「缓存命中的部分费用只有原价的 10%」——这是各家里折扣最狠的。但缺点也明显缓存只保留 5 分钟而且第一次创建缓存还要多付 25% 的写入费。适合短时间内高频使用同一份上下文的场景。第三类硬盘缓存派DeepSeekDeepSeek 玩了个不一样的——「把缓存存到硬盘上」。这带来一个巨大优势「缓存可以保留几小时甚至几天」。传统的内存缓存用户中午问完问题晚上再来问缓存早就没了。但 DeepSeek 的硬盘缓存可以一直在那等着你。而且它完全自动不需要任何配置。每个请求都会自动触发缓存构建后续请求如果前缀重复就直接命中。「缓存命中部分费用是 0.1 元/百万 Token比正常价格低了整整一个数量级。」它的返回结果也很清晰{ usage: { prompt_tokens: 10000, prompt_cache_hit_tokens: 9500, prompt_cache_miss_tokens: 500 } }一目了然9500 个 Token 命中缓存只有 500 个需要正常计费。三、缓存到底是怎么实现的聊完各家的使用方式你可能会好奇缓存背后的技术原理是什么为什么前缀一样就能命中硬盘缓存和内存缓存有什么本质区别这一节我们来掀开盖子看看。1. KV CacheTransformer 的记忆本要理解 Prompt 缓存首先得知道大模型推理时有个东西叫「KV Cache」。简单说Transformer 模型在处理输入时会为每一层、每个 Token 计算一组 Key 和 Value 向量这就是 Attention 机制的核心。这些 K/V 向量在后续生成过程中会被反复用到。如果没有 KV Cache模型每生成一个新 Token就得把之前所有 Token 的 K/V 重新算一遍——这显然是巨大的浪费。所以模型会把已经计算过的 K/V 存起来这就是 KV Cache。输入: [System Prompt] [文档] [问题] └─────────────────────┘ └──┘ 已计算,存入 KV Cache 新增部分,增量计算「Prompt 缓存本质上就是把这些 KV Cache 保存下来供后续请求复用。」2. 前缀匹配机制为什么顺序很重要这里有个关键点「KV Cache 只能按前缀复用」。为什么因为 Transformer 是自回归模型每个位置的 K/V 都依赖于它前面所有位置的信息。如果中间某个 Token 变了后面所有的 K/V 都会受影响只能重新计算。请求 A: [角色设定] [规则说明] [文档内容] [问题1] 请求 B: [角色设定] [规则说明] [文档内容] [问题2] └────────────────────────────┘ └────┘ 前缀完全相同 不同 可以复用 需重算这就是为什么所有缓存方案都强调前缀匹配——不是内容相同而是从头开始连续相同。举个反例请求 A: [角色设定] [文档内容] [问题] 请求 B: [文档内容] [角色设定] [问题] ← 顺序变了缓存完全失效内容一模一样只是顺序变了缓存就用不上了。3. 自动缓存 vs 手动标记两种实现思路各家的缓存机制虽然使用方式不同底层实现思路大体分两种自动打点机制OpenAI/Gemini/DeepSeek这类方案的核心思想是「模型服务端自动识别可缓存的边界」。具体来说服务端会对请求内容计算哈希签名按固定粒度通常 64-128 Token切分成块逐块检查是否与之前的请求匹配匹配上的块直接读取缓存没匹配的块重新计算请求内容[块1][块2][块3][块4][块5][块6][块7] 缓存状态[命中][命中][命中][命中][命中][未命中][未命中] ↑ 缓存边界这种方式对用户完全透明不需要任何配置。但代价是「服务端需要维护大量的缓存索引」而且用户无法精确控制缓存行为。显式标记机制Anthropic ClaudeClaude 走了另一条路「让用户明确告诉模型哪些内容需要缓存」。{ content: [ { type: text, text: 这部分我要缓存, cache_control: { type: ephemeral } // 明确标记 }, { type: text, text: 这部分不缓存 } ] }模型收到带cache_control标记的内容后会为标记的内容块计算 KV Cache生成一个缓存 ID后续请求带上相同的内容块时直接读取缓存这种方式的优势是「精确可控」你可以只缓存真正需要的部分避免浪费。但需要手动管理缓存边界对开发者要求更高。4. 内存缓存 vs 硬盘缓存持久性的代价OpenAI 和 Claude 用的都是「内存缓存」RAMDeepSeek 用的是「硬盘缓存」SSD。为什么这个区别很重要看看两者的特点内存缓存硬盘缓存读写速度极快纳秒级较快微秒级容量成本贵RAM 价格高便宜SSD 大量部署持久性短进程重启就没了长断电也能保留典型时长5-15 分钟数小时~数天内存缓存的问题是「容量有限只能用 LRU 淘汰策略不活跃的缓存很快就会被挤掉。」而且模型服务通常是分布式部署请求可能被分发到不同的节点缓存命中率进一步下降。DeepSeek 的硬盘缓存选择了另一条路用 SSD 阵列存储 KV Cache容量大幅提升为每个用户/请求前缀建立持久化的缓存索引请求来了先查硬盘命中就直接加载到显存里用代价是「首次请求会慢几秒」需要把 KV Cache 从硬盘加载到显存但换来的是长达数天的缓存存活期。5. 缓存粒度64 Token 和 1024 Token 的区别各家对最小缓存单元的设定不同DeepSeek64 TokenOpenAI/Claude/Gemini1024-2048 Token为什么差这么多这涉及到「缓存管理的复杂度和空间开销」。粒度越小理论上缓存命中率越高——两个请求只要有 64 Token 的公共前缀就能部分命中。但代价是「缓存索引会变得很大」查找和匹配的开销也会上升。粒度越大管理更简单但「短内容就享受不到缓存红利了」。比如你的 System Prompt 只有 500 Token在 OpenAI 那里根本不会被缓存。DeepSeek 能做到 64 Token 的细粒度很可能是因为它的硬盘缓存架构允许维护更大的索引空间而内存缓存受限于 RAM 容量不得不用更粗的粒度来控制开销。理解了这些原理你就能明白为什么改变前缀顺序会导致缓存失效在开头加时间戳是个坏主意DeepSeek 的缓存能活那么久Claude 需要手动标记才能获得最优效果四、灵魂拷问我到底能省多少钱来算一笔真实的账。假设你有一个文档问答助手用户上传一份 5 万 Token 的文档然后平均会问 5 个问题。「不用缓存的情况」以 GPT-4o 为例每次输入50000 Token × 5 次 250000 Token 费用250000 × $2.5/百万 $0.625「用缓存的情况」首次输入50000 Token正常价 后续 4 次50000 × 4 200000 Token缓存价5 折 费用50000 × $2.5/百万 200000 × $1.25/百万 $0.375 节省40%如果换成 DeepSeek 的硬盘缓存呢首次输入50000 Token¥1/百万 ¥0.05 后续 4 次200000 Token¥0.1/百万 ¥0.02 总费用¥0.07同样的场景「DeepSeek 的费用不到 GPT-4o 的十分之一」。当然模型能力有差异这个账不能简单对比。但如果你的场景对模型要求不是特别高缓存机制的差异确实能带来可观的成本优势。五、怎么知道缓存有没有生效这是很多人忽略的问题缓存开了但怎么确认它真的在工作各家都会在 API 返回的usage字段里告诉你缓存命中情况模型缓存命中字段OpenAIusage.prompt_tokens_details.cached_tokensClaudeusage.cache_read_input_tokensGeminiusage.cachedContentTokenCountDeepSeekusage.prompt_cache_hit_tokens简单写个监控把每次请求的缓存命中率记录下来def log_cache_stats(response): usage response.usage total usage.prompt_tokens cached usage.prompt_tokens_details.cached_tokens # OpenAI 为例 hit_rate cached / total * 100 if total 0 else 0 print(f缓存命中率: {hit_rate:.1f}% ({cached}/{total}))如果你发现命中率长期很低那就得检查一下是不是哪里出了问题。六、工程实战如何组织上下文以最大化缓存命中聊了原理和常见问题但真正落地时你会发现「最核心的工作其实是上下文的组织方式」。1. 黄金法则稳定内容永远放前面这是最重要的一条原则。根据前缀匹配机制「只有从头开始连续相同的部分才能命中缓存」。所以你的上下文组织应该遵循这个顺序[稳定度高的内容] → [稳定度中的内容] → [稳定度低的内容] → [动态内容]「反面教材」有些开发者喜欢在 System Prompt 开头加时间戳或请求 ID# ❌ 错误做法 system_prompt f当前时间{datetime.now()}请求ID{uuid4()}\n你是一个客服助手... # ✅ 正确做法 system_prompt 你是一个客服助手... # 时间信息放到最后或者用工具调用获取一个动态字符放在开头整个缓存链就断了。2. 内容分层把 Prompt 当作洋葱来设计在实际生产中我们通常会把 Prompt 拆分成多个独立的层每层有自己的更新频率class PromptBuilder: def __init__(self): # 第 1 层核心人设几乎永不变 self.core_persona 你是一个专业的金融分析师具备以下能力 - 解读财务报表 - 分析行业趋势 - 给出投资建议 # 第 2 层通用规则很少变 self.rules 请遵循以下规则 1. 所有分析必须基于提供的数据不要编造 2. 涉及具体数字时要标注来源 3. 风险提示要放在建议之后 # 第 3 层领域知识按需加载 self.domain_knowledge None # 第 4 层示例按场景切换 self.examples None def build(self, user_query, context_docsNone, examplesNone): layers [ self.core_persona, self.rules, ] if context_docs: layers.append(f参考文档\n{context_docs}) if examples: layers.append(f参考示例\n{examples}) layers.append(f用户问题{user_query}) return\n\n.join(layers)这样设计的好处是「即使领域知识或示例变了核心人设和规则的缓存还能命中」。3. 多租户场景按租户隔离 vs 共享前缀如果你的应用服务多个客户多租户有两种组织策略「策略 A每个租户独立前缀」租户 A[租户A的System Prompt] [租户A的知识库] [用户输入] 租户 B[租户B的System Prompt] [租户B的知识库] [用户输入]优点每个租户的缓存完全独立互不干扰 缺点缓存利用率低因为不同租户之间无法共享「策略 B共享通用前缀 租户差异后置」所有租户[通用System Prompt] [通用规则] [租户特定配置] [用户输入]优点通用部分可以跨租户复用缓存命中率高 缺点需要仔细设计通用和特定的边界「我的建议」如果租户数量多且差异不大比如 SaaS 产品优先用策略 B。如果租户差异很大比如定制化项目用策略 A。掌握了这些组织技巧你就能在不改业务逻辑的情况下把缓存命中率从 30% 提升到 80% 以上。七、写在最后大模型的缓存机制本质上是在帮你做一件事「为重复的工作只付一次钱」。它不是什么高深的技术优化而是实实在在的成本控制手段。对于月调用量上百万 Token 的应用来说用好缓存省下的钱可能比换一个便宜模型还多。最后总结一张表方便你按需选择OpenAIClaudeGeminiDeepSeek配置难度⭐ 自动⭐⭐⭐ 手动⭐ 自动⭐ 自动缓存时长5-15分钟5分钟可配置数小时~天价格折扣50%90%75%90%最小 Token10241024102464适合场景高频短对话精细化控制长时缓存低频长文档❝觉得有用的话「点赞 在看 收藏⭐」一键三连下次找起来方便也能让更多人看到。❞点击 头像关注我一起探索 AI 领域的更多可能 ✌️
