大模型 API 的缓存计费差在哪？显式缓存和隐式缓存横评
事实依据为 2026-08-24 抓取的各厂商官方文档。本文只对比计费口径与命中规则，不写具体单价与折扣比例，那些数字变动频繁，请以官方定价页为准。
「缓存命中打几折」是这个话题里最没用的一个问题。因为各家连「什么算命中」都不是同一个定义：有的要你手动标记、有的完全自动还关不掉；有的必须完整匹配一整段前缀、有的按内容块往回数；有的只有命中一个价格位、有的写入和存储各收各的。拿 A 家的经验去估 B 家的账单，误差不在百分比量级，而在「以为省了却更贵了」这个量级。
第一层差异：要不要你动手
这是最基础也最先分叉的一层。把几家的官方表述放在一起看，大致分成三种形态。
完全自动、不用改代码。 DeepSeek 官方文档写的是上下文硬盘缓存技术对所有用户默认开启，用户无需修改代码即可享用，每一个请求都会触发缓存的构建。Kimi 的表述类似，官方明确列了三个「无需」——无需手动创建、无需引用缓存 ID、无需管理存活时间。智谱开放平台的上下文缓存文档也把它定位成隐式缓存，智能识别重复的上下文内容，无需手动配置。
自动和手动两套并存，而且互斥。 阿里云百炼给了显式缓存和隐式缓存两种模式，官方明确说明两者互斥，单个请求只能应用其中一种模式，并且隐式缓存无法关闭。显式缓存需要你主动为指定内容创建缓存，换来的是有效期内的确定性命中；隐式缓存不用配置，但官方直接写了「缓存命中率不确定」。
以显式为主。 Anthropic 的官方文档把 cache_control 断点放在核心位置，同时也支持自动缓存，并在文档开头就说明显式断点提供了长短两档可选的存活时间（具体时长以官方文档为准）。
如果你走的是聚合层，还要多考虑一层。OpenRouter 的官方文档里有一句概括很准确：大多数供应商会自动启用提示缓存，但有几家（文档点名了 Alibaba 和 Anthropic）需要你逐条消息去开启。
**这一层的实际影响是：**同一份代码接到不同厂商，缓存可能一直在生效，也可能一次都没命中过，而你从代码上完全看不出区别。
第二层差异：命中的判定规则
这是最容易想当然、也最容易白花钱的一层。很多人心里的模型是「前缀一样就算命中」，但没有一家是这么简单的。
DeepSeek 的判定单位是「缓存前缀单元」，必须完整匹配。 官方文档解释得很细：受滑动窗口注意力机制影响，每条缓存前缀是一个独立的完整单元，后续请求只有在完整匹配这个单元时才能命中。落盘时机有三种——每次请求的用户输入结束位置与模型输出结束位置会各产生一个单元；系统检测到多次请求之间存在公共前缀时，会把该公共前缀单独落盘；长输入长输出场景下还会按固定 token 间隔截取单元。
官方举的例子值得抄进自己的设计文档：第一轮请求内容是 A+B，第二轮是 A+B+C，第二轮能命中；但第一轮是 A+B、第二轮是 A+C，第二轮不能命中，因为 A+C 无法完整匹配 A+B 这个单元——不过系统这时会把公共前缀 A 单独落盘，等到第三轮 A+D 来的时候才能命中 A。也就是说，在这套规则下，同一份长文档的第一次和第二次提问都不会命中，从第三次开始才省钱。官方给的长文档问答例子就是这个结论。
阿里云百炼的显式缓存按内容块往回数。 官方文档说明，在 messages 中加入 "cache_control": {"type": "ephemeral"} 标记后，系统会以每个标记位置为终点，向前回溯有限个 content 块去尝试命中。命中时选取最长的匹配前缀作为命中块，并把该块的有效期重置；未命中时则从 messages 开头到标记之间的内容创建新的缓存块。文档里还有个很实际的提醒：缓存创建发生在模型响应之后，建议在创建请求完成后再尝试命中该缓存。回溯的块数是有上限的，多轮对话累积的消息条数一旦超过这个上限，前面那个缓存块就够不着了——这条上限的具体数值以官方文档为准，但设计多轮对话时必须知道它存在。
Anthropic 的写入只发生在你标的那个断点。 官方文档把它总结成一条核心原则：用 cache_control 标记一个块，只会写入一条缓存条目，即以该块结尾的前缀的哈希，系统不会为更靠前的任何位置写条目。因为哈希是累积的，所以断点放哪儿直接决定了能复用多少。
几乎每家都有一个「太短就不缓存」的下限。 Kimi 的缓存文档、阿里的缓存文档、OpenRouter 转述的 OpenAI 规则里都能看到这条，只是门槛数值各不相同，且显式模式和隐式模式的门槛还可能不一样。短 prompt 想靠缓存省钱基本没戏，具体门槛请查各家官方缓存文档。
第三层差异：一个价格位还是三个
大部分人只知道「命中价」，但完整的缓存计费最多可以有三个位置：
| 价格位 | 含义 | 谁会收 |
|---|---|---|
| 命中价 | 缓存读取的输入 token 单价 | 全部厂商都有，比标准输入便宜 |
| 写入价 | 建立缓存那次请求的额外开销 | 阿里的显式缓存、Anthropic 都按高于标准输入的比例计；隐式模式通常按标准输入计 |
| 存储费 | 缓存驻留期间的费用 | 智谱国际站的定价表把它单列成一列 |
阿里云百炼官方文档把两种模式的差别摆成了对照表：显式缓存用于创建缓存的 token 按高于标准输入的比例计费、命中按远低于标准输入的比例计费；隐式缓存的创建按标准输入价计、命中的折扣力度弱于显式。所以显式缓存不是「更麻烦但一样省」，而是「更麻烦、命中更确定、命中时更省，但没命中就白付了写入溢价」。
智谱国际站 Z.AI 的定价页里，文本模型表格有 Input、Cached Input、Cached Input Storage、Output 四列，其中存储那一列当前标注为限时免费。这说明缓存存储在有些家是一个独立的收费项，只是现在可能没收——限时的东西会到期，做长期预算时要留意这一列的存在。
OpenRouter 的提示缓存文档还提到一个反直觉的现象：某些供应商在缓存写入时的折扣是负的（也就是更贵），只有在缓存读取时才是正的。所以判断缓存到底赚不赚，必须把写入那一次也算进去。这个判断方法本站有专门一篇，见提示缓存是怎么计费的。
第四层差异：用量字段名根本不统一
这一条最琐碎，但它是你能不能验证「缓存到底生效了没有」的唯一手段。各家在响应里放的字段不一样：
- DeepSeek 在 usage 里加了两个字段：
prompt_cache_hit_tokens和prompt_cache_miss_tokens，分别是本次输入中命中和未命中的 token 数； - 智谱开放平台和 Z.AI 用的是
usage.prompt_tokens_details.cached_tokens，两边文档表述一致； - 阿里云百炼在 OpenAI 兼容协议下也是
prompt_tokens_details.cached_tokens，但在 Anthropic 兼容协议下读到的是cache_read_input_tokens——同一个平台，换个协议字段名就变了； - OpenRouter 在
prompt_tokens_details里同时给cached_tokens和cache_write_tokens，另外还有一个cache_discount字段直接告诉你这次省了多少。
写统一封装层的时候，这几个名字必须显式映射，不能指望一个字段名走天下。多家封装的思路可以参考接了好几家模型 API 怎么统一封装。
第五层差异：能活多久、和谁共享
存活时间的确定性差别很大。 阿里的显式缓存有一个明确的有效期，且命中后会重置计时；隐式缓存官方直接写「不确定，系统会定期清理长期未使用的缓存数据」。DeepSeek 的表述是缓存系统「尽力而为」，不保证百分之百命中，缓存构建耗时为秒级，不再使用后会自动清空。Anthropic 则提供了两档可选的存活时间。能不能把缓存当成一个可依赖的成本假设，取决于你用的是哪一档。
隔离边界也不一样。 DeepSeek 支持传 user_id 参数，官方说明它同时用于内容安全隔离、KVCache 隔离和调度隔离——也就是说不同 user_id 之间的缓存是隔开的，你的多租户设计会直接影响命中率。Anthropic 的文档则提醒缓存按工作区隔离，同一组织下不同工作区之间不共享，并且在不同云平台上的隔离粒度还有差异，用了多工作区就要重新审视缓存策略。
走聚合层还多一层风险。 OpenRouter 的文档写得很清楚：为了提高命中率，它使用供应商粘性路由，在一次用到缓存的请求之后，会把后续同模型的请求路由到同一个供应商端点，保持缓存是热的；粘性会话在一段时间无活动后过期，如果粘性供应商不可用会自动回退到下一个。它还支持传 session_id（或对应的请求头）来显式指定粘性路由的键，对开头消息会变化的多轮 Agent 场景尤其有用。反过来说，如果你在聚合层上手动指定了供应商顺序，粘性路由就不生效了，缓存也就跟着丢。
一张对照表：比的是规则不是价格
| 对比维度 | 常见的两种或三种做法 |
|---|---|
| 开启方式 | 全自动关不掉 / 自动与显式并存且互斥 / 以显式断点为主 |
| 命中判定 | 完整匹配缓存前缀单元 / 从标记位向前回溯有限个内容块 / 断点前缀哈希 |
| 最小长度 | 都有门槛，但数值不同，显式与隐式还可能分别设门槛 |
| 价格位 | 只有命中价 / 命中价加写入溢价 / 再加一项存储费 |
| 用量字段 | prompt_cache_hit_tokens 系 / cached_tokens 系 / cache_read_input_tokens 系 |
| 存活时间 | 明确有效期且命中重置 / 不承诺、定期清理 / 多档可选 |
| 隔离粒度 | 按调用方标识隔离 / 按工作区隔离 / 聚合层按会话粘性 |
这张表的用法是：换厂商之前，把这七行逐一填一遍。填不出来的那几行，就是你接入之后最可能出意外的地方。各家的具体价格数字见国产大模型 API 价格对比，那篇是统一口径的横评并标了核对日期。
所以该怎么决策
三个判断依次问自己就够了。
第一问：**我的前缀真的稳定吗。**system prompt、工具定义、知识文档这类内容如果每次都一样，缓存才有意义。每次请求前缀都不同的场景，写入费是净亏。
第二问：**同一份前缀会被复用几次。**从 DeepSeek 那个长文档例子能看出来，某些规则下前两次都不命中。如果你的业务是「每份文档只问一次」，缓存基本帮不上忙。
第三问：**我愿不愿意管显式缓存。**愿意管、且复用密度高，显式模式的确定性命中更划算；不愿意管，就老老实实用自动模式，把省下的部分当作意外之喜，不要写进预算假设。
如果三问下来发现缓存不适合你的场景，先看看批处理是不是更对路，两者省的不是同一笔钱，判断方法见提示缓存和批处理该用哪个。
核实边界
- 本文依据 2026-08-24 的抓取，逐字核到正文的官方页面包括：DeepSeek 的上下文硬盘缓存文档与模型价格页、Kimi 开放平台的上下文缓存文档与定价说明页、智谱开放平台的上下文缓存文档、Z.AI 的定价页与 Context Caching 文档、阿里云百炼的上下文缓存文档与计费文档、Anthropic 的提示缓存文档、OpenRouter 的提示缓存文档。
- 未核到的厂商：火山方舟（豆包）官方文档站为前端渲染，本次抓取只拿到导航骨架，正文未逐字核到，因此豆包没有进入本文任何一条对比；OpenAI 官方文档站本次网络不可达，文中涉及 OpenAI 缓存行为的表述均来自 OpenRouter 官方文档的转述，已在正文标明，未作为 OpenAI 官方口径引用。
- 本文没有写任何具体单价、折扣比例、最小缓存 token 门槛和存活时长数值。这几类都属于随时可能调整的参数，写死等于埋雷；文中一律改写为机制描述，并指向官方页面自查。
- 笔者没有上述任何厂商的付费账号，全文结论来自官方文档阅读，不含调用实测。