3.1 各家平台缓存语义对比

3.1 各家平台缓存语义对比

本节摘要：平台级 Prompt Caching 的底层全是前缀匹配，但"谁来决定断点、按什么粒度对齐、缓存多久"四家各不相同。读完你能在写代码前就判断：一份 messages 数组在 OpenAI、Anthropic、DeepSeek、Gemini 上分别会命中多大范围，以及该为哪家预留多少稳定前缀。

四家产品，一条底层逻辑

上一节把"平台把前缀复用产品化"这件事立起来了，这一节把它拆开看。四家云厂商的命名天差地别——OpenAI 叫自动前缀缓存，Anthropic 叫提示缓存，DeepSeek 叫上下文硬盘缓存，Gemini 同时有隐式与显式两种——但拨开名字，它们干的是同一件事：拿你这次请求的前缀，去比对之前某次请求算过的 KV，对得上的那段就按折扣价结算，对不上的那段全价重算。差别全在接口设计和计费细节上，不在原理上。

为什么原理必然收敛到前缀匹配？因为第2章讲清楚了：KV 是自回归逐 token 算出来的，第 N 个 token 的 KV 依赖前 N-1 个。所以只有"从开头连续相同"的前缀才能复用，中间哪怕换一个 token，后面的 KV 全部失效。平台没有魔法突破这个数学约束，它们只是把"比对"这件事从显存搬到了分布式存储，并加上了 TTL 和价签。

OpenAI：自动前缀缓存，无需标记

OpenAI 是四家里最"无感"的一个。你不写任何特殊字段，平台在后台默默对你的请求做前缀比对：只要某次请求的前缀和近期请求的前缀从开头连续相同、且长度跨过约 1024 个 token 的对齐边界，那段前缀就被命中，按折扣价计费。它的对齐单位是 1024 token——意思是缓存命中以 1024 token 为一块来结算，前缀长度不是凑到 1024 的整数倍，那段零头往往仍要全价算。

这种设计的甜头是零改造：你已有的 System Prompt 只要稳定地堆在头部，就自动享受折扣。代价是你完全控制不了断点位置。比如你希望"系统设定 + 工具定义"作为一段、"长参考文档"作为另一段分别缓存，OpenAI 不给你显式切分，它只会按自己的对齐逻辑去切。控制权的让渡，换来的是接入成本的最低。

Anthropic：cache_control 显式断点，最多四个

Anthropic 走另一条路——把断点交给你。你在 messages 或 tools 的某个位置打一个 cache_control 标记，告诉平台"从开头到这里算一段缓存"。一份请求里最多打四个断点，于是你能把提示词分层：系统设定一个断点、工具定义一个断点、参考资料一个断点，每段独立复用、独立计 TTL。

显式断点的好处是精细。比如你每天换一份参考资料但系统设定不变，两个断点让系统设定那段长期命中，参考那段按天失效，互不影响。代价是你要为每个断点满足"最小可缓存长度"——太短的段平台拒绝缓存，因为管理开销不划算。我更倾向这种设计：它逼你在写提示词时就想清楚"哪些东西是稳定的、哪些天天变"，而这种思考本身就是降本。

DeepSeek：自动上下文硬盘缓存，命中即折扣

DeepSeek 的上下文缓存思路接近 OpenAI 的"自动"，但明确把缓存落到了硬盘而非纯显存，因而能保留更久、容纳更长上下文。你同样不标记断点，平台按前缀精确匹配，命中那段按折扣价结算。它适合长 System Prompt、长上下文的业务——比如把一份几万 token 的知识库前置进请求，后续请求只要前缀相同就复用。

值得注意的是"硬盘"二字带来的工程含义：显存缓存贵但快，硬盘缓存便宜但取回时要再读一遍。平台替你权衡了这层，对你而言表现为"命中即折扣"的简单账单。它和 OpenAI 一样不给你断点，但容忍的前缀可以更长，这对 3.5 节的长文档场景很友好。

Gemini：implicit 与 explicit 双模式

Gemini 同时提供隐式与显式两种。隐式模式下平台自动识别可复用的前缀，类似 OpenAI；显式模式下你可以用缓存接口把一段内容显式存成一个缓存条目、拿到一个缓存标识，后续请求引用这个标识即可。显式模式的好处是跨请求、跨会话都能复用同一段长上下文，而不必每次都把那段原文重发一遍——你只发一个引用标识，省下的既是算力也是带宽。

双模式让它同时具备 OpenAI 的省心和 Anthropic 的精细。代价是你要理解两套语义、在合适的地方选合适的模式。"一份长文档要被很多不同问题反复问"用显式模式最划算；"请求结构固定只是尾部问题不同"用隐式模式即可。

图 3-1：四家平台缓存语义对比矩阵

一张表看清六维差异

把上面四家的六个关键维度并排放，差异一目了然。注意下表不写具体价格，只用倍率关系：缓存读价普遍在常规输入价的十分之一这个量级，缓存写价则略高于常规输入价（因为平台要为你多存一份）。

最小可缓存长度为什么存在

四家都设了最小长度门槛，这不是刁难。缓存一段前缀，平台要付出存储位、索引管理和命中比对的开销；一段只有几十 token 的前缀，管理成本可能比它省下的算力还高，所以平台用最小长度把"不划算的缓存"挡在门外。对你而言的启示很直接：如果你的稳定前缀很短（比如只有一句角色设定），可能根本进不了缓存，省不了钱——要么把稳定内容堆长，要么接受它不被缓存。这也解释了为什么长 System Prompt、长知识库才是平台缓存的主场，短提示词在这套机制里几乎占不到便宜。

怎么按业务形态选型

把接口差异翻译成选型：如果你的提示词结构固定、懒得改代码，OpenAI 和 DeepSeek 的自动模式最省心，只要前缀稳就能吃折扣；如果你的业务分层明显——系统设定常驻、参考资料按天换、用户数据每请求变——Anthropic 的显式断点能让你为每层独立设 TTL，精细但要多写字段；如果你的长文档要被很多会话反复问，Gemini 的显式模式跨会话复用最划算，不用每次重发原文。没有"最好"的平台，只有"最贴合你前缀变动规律"的那一个。先把自家前缀的变动频率摸清楚，再反过来选接口，顺序别反了。

共同原理：都是前缀匹配

把表看三遍，你会注意到一行共性——缓存键粒度全是某种形式的"前缀匹配"。这不是巧合，是 KV 自回归结构的必然结果。平台无论怎么包装，都绕不开"只有从开头连续相同的前缀能复用"这条铁律。所以判断一份提示词在哪家能命中，第一步不是看接口，而是看它的前缀有多稳定：系统设定、工具定义、参考资料这种"写了就不怎么动"的内容，天然适合塞进前缀；用户每次不同的问题、时间戳、会话变量，必须放到尾部。

这个判断是 3.4 节改造提示词的总纲，也是 3.2 节计费公式的前提——命中率本质上就是你"前缀稳定度"的函数。下一节我们就把"稳定度"翻译成钱：命中率每涨一点，单价降多少。

关键直觉：平台缓存的接口差异是表象，前缀匹配是内核。选平台时别被名词迷惑，先问自己"我的前缀能稳多久、稳多长"。