DeepSeek API 的缓存计费怎么算？命中价与未命中价差多少

DeepSeek 官方定价页把输入价拆成「缓存命中」和「缓存未命中」两档，两者差距很大——命中价只有未命中价的一个零头。这意味着对固定前缀占比高的应用，缓存不是可选优化，而是决定成本量级的关键开关。

本文价格以 DeepSeek 官方中文定价页为准（2026-09-28 重新核对，来源见文末；初版核对于 2026-08-06，当时的数字已经失效），价格随时可能调整，做预算前请自行到官方页面确认。

官方定价页给出的价格结构

按 2026-09-28 的官方中文定价页，DeepSeek 提供两个模型，上下文均为 1M、最大输出 384K。价格单位为人民币元 / 百万 token，并且分高峰、空闲两个时段，空闲价是高峰价的一半：

计费项	deepseek-flash 高峰	deepseek-flash 空闲	deepseek-v4-pro 高峰	deepseek-v4-pro 空闲
输入（缓存命中）	0.04	0.02	0.30	0.15
输入（缓存未命中）	2	1	9	4.5
输出	8	4	27	13.5

deepseek-flash 对应的模型已升级为 DeepSeek-V4.1-Flash。旧名 deepseek-v4-flash 仍可调用，但官方写明对应模型已下线，请求由 V4.1-Flash 服务、按 Flash 价格计费。

这组数字里最值得注意的是命中价与未命中价的比例：Flash 是 2%，Pro 约 3.3%，两个时段的比例一样。换句话说，命中的那部分输入只收一个零头。

美元价在英文版定价页，本次没有核对，这里不给换算值。

同样的数据也收录在本站的价格对比表里，每行都带官方链接与核对日期，可以直接点开验证。

这个价格结构意味着什么

假设你的请求里有一大半是固定前缀（system prompt、工具定义、常驻知识），而且缓存能稳定命中，那么你的实际输入均价会显著低于表上那个未命中价。固定前缀占比越高、命中率越稳，实际均价越接近命中价那一端。

反过来，如果你的请求前缀每次都不一样，缓存命中率接近零，那你付的就是完整的未命中价——同样的调用量，账单可以差出好几倍。

所以对 DeepSeek 这种价格结构的模型，优化命中率的性价比远高于纠结选哪个档。先把前缀设计好，再谈换模型。怎么把命中率做上去，见提示缓存命中率上不去？八个常见原因。

两个档怎么选

按上面的价格表，Pro 的未命中输入价是 Flash 的 4.5 倍，输出价约 3.4 倍，缓存命中价 7.5 倍。另外有一条硬分界：官方标注 Flash 支持图像理解、Pro 不支持，输入里有图片就只能选 Flash。纯文本任务的选择逻辑和其他厂商的轻重档一样：

先用便宜档跑一批真实样本，看效果够不够。够就没必要上贵档——省下的是几倍的钱。

不够时先排查是不是 prompt 的问题。很多「小模型不行」的结论，实际是提示写得不够具体、缺少示例、没给输出格式约束。改完再测一遍，常常就够用了。

确实需要更强能力时再上 pro，而且可以只在难任务上用。两级分流的做法：先用 flash 跑，带一个置信度或校验步骤，不通过再升级到 pro。这样贵档只承担少数请求。

分时计价：一个必须留意的变量

官方定价页的现行规则是高峰/空闲分时计价：空闲时段价格是高峰时段的一半。高峰时段为北京时间周一至周五（不含中国法定节假日）9:00–12:00、14:00–18:00；其余时段，包括周末和法定节假日全天，都是空闲时段。

对成本估算的影响是实打实的：如果你的业务流量集中在工作日白天，大部分调用都落在高峰时段，拿空闲价去估会低估一倍。

应对办法有两个方向：

能错峰的错峰。 批量处理、离线分析、数据清洗这类不要求实时的任务，挪到空闲时段跑，同样的调用量直接半价。这是纯收益，没有副作用。

不能错峰的按高峰价估。 实时业务没法挪，那就在预算里按高峰价算，别用空闲价给自己一个好看的数字。

分时规则此前几经预告和调整，建议在做正式预算前再核一次官方页面。

怎么把这些数代进预算

1. 用 token 计算器量出单次请求的输入输出 token。
2. 把输入拆成「固定前缀」和「变化部分」，估一个命中率。
3. 实际输入成本 ≈ 固定前缀 × 命中价 + 变化部分 × 未命中价。
4. 加上输出成本，乘调用量，再按高峰/空闲时段的调用占比做修正。
5. 结果代进月成本估算器和其他厂商对比。

第 2 步的命中率是整个估算里最不确定的一项，建议给一个区间（悲观 / 乐观各算一遍），而不是拍一个数。

什么样的应用最受益

从这个价格结构反推，最适合的应用有三个特征。

一、system prompt 长而稳定。 角色设定、输出规范、领域知识写得越详细，固定前缀越长，缓存能覆盖的比例越高。有意思的是，这和「压缩 prompt 省钱」的直觉相反——在缓存命中稳定的前提下，长 prompt 的边际成本很低，你反而可以把指令写得更充分来提升效果。

二、调用频率高。 缓存有存活时间，频率高才能在存活期内多次复用。低频调用的场景，缓存往往等不到复用就过期了。

三、工具定义多。 Agent 类应用挂着大量工具，工具 schema 每次都要发。这部分是典型的固定前缀，交给缓存后收益很直接。

反过来，如果你的请求前缀高度个性化（每个用户一套设定）、或者调用很稀疏，那缓存帮不上太多忙，成本优化要往别的方向想——见大模型 API 降本十招。

一个实操建议：先验证命中，再谈优化

开了缓存不等于命中了。建议上线后先做一件事：从响应的 usage 字段里取缓存命中的 token 数，记进日志，算出命中率。

命中率接近零的话，先别急着算成本，去查前缀是不是被污染了——时间戳、请求 ID、用户信息、集合遍历顺序，这四类是最常见的元凶。排查方法见提示缓存命中率上不去？八个常见原因。

确认命中之后再回来算账，那时候的数字才有意义。

关于本文数据

本文所有价格均来自 DeepSeek 官方中文定价页 api-docs.deepseek.com/zh-cn/quick_start/pricing，核对日期 2026-09-28（初版 2026-08-06 引用的美元价已经失效）。模型命名、上下文长度、分时规则同样以该页为准。

厂商调价、模型改名、政策生效都可能发生在本文发布之后，做预算请以你查询当天的官方页面为准。想看其他厂商的计费口径，读国产大模型 API 价格对比；想了解缓存的通用计费结构，读提示缓存是怎么计费的。

三个高频问题

问：缓存命中价这么低，是不是可以把 prompt 写得很长？ 在命中稳定的前提下，长前缀的边际成本确实很低。但要注意两点：第一次写入仍按未命中价计；长上下文还可能影响模型的注意力分配，不是越长越好。

问：分时计价会不会影响缓存价？ 会。官方价格表里缓存命中价同样分高峰、空闲两档，空闲是高峰的一半，命中价与未命中价的比例在两个时段保持不变。

问：两个档位的缓存机制一样吗？ 官方定价页对两个档都列了命中与未命中价，机制是一致的，差别在绝对数值上。

一句话记住

在缓存命中价只有未命中价 2%～3.3% 的价格结构下，命中率就是你的实际单价。同样的调用量、同样的模型，前缀设计得好与不好，账单可以差出好几倍。所以拿到这类定价结构的第一件事不是比档位，而是把请求前缀钉死、把命中率监控起来。