DeepSeek API 的缓存计费怎么算？命中价与未命中价差多少
DeepSeek 官方定价页把输入价拆成「缓存命中」和「缓存未命中」两档，两者差距很大——命中价只有未命中价的一个零头。这意味着对固定前缀占比高的应用，缓存不是可选优化，而是决定成本量级的关键开关。
本文价格逐条以 DeepSeek 官方定价页为准（核对于 2026-08-06，来源见文末），价格随时可能调整，做预算前请自行到官方页面确认。
官方定价页给出的价格结构
按官方定价页当日内容，DeepSeek 提供两个模型档，上下文长度均为 1M，价格单位为美元 / 百万 token：
deepseek-v4-flash：输入（缓存未命中）$0.14，输入（缓存命中）$0.0028，输出 $0.28。
deepseek-v4-pro：输入（缓存未命中）$0.435，输入（缓存命中）$0.003625，输出 $0.87。
这两组数字里最值得注意的是命中价与未命中价的比例——命中价低到只有未命中价的百分之几。换句话说，命中的那部分输入几乎等于免费。
同样的数据也收录在本站的价格对比表里，每行都带官方链接与核对日期，可以直接点开验证。
这个价格结构意味着什么
假设你的请求里有一大半是固定前缀（system prompt、工具定义、常驻知识），而且缓存能稳定命中，那么你的实际输入均价会显著低于表上那个未命中价。固定前缀占比越高、命中率越稳，实际均价越接近命中价那一端。
反过来，如果你的请求前缀每次都不一样，缓存命中率接近零，那你付的就是完整的未命中价——同样的调用量，账单可以差出好几倍。
所以对 DeepSeek 这种价格结构的模型，优化命中率的性价比远高于纠结选哪个档。先把前缀设计好，再谈换模型。怎么把命中率做上去，见提示缓存命中率上不去？八个常见原因。
两个档怎么选
flash 与 pro 的价格差大约是三倍（输入与输出都是这个量级）。选择逻辑和其他厂商的轻重档一样：
先用便宜档跑一批真实样本，看效果够不够。够就没必要上贵档——省下的是三倍的钱。
不够时先排查是不是 prompt 的问题。很多「小模型不行」的结论，实际是提示写得不够具体、缺少示例、没给输出格式约束。改完再测一遍，常常就够用了。
确实需要更强能力时再上 pro，而且可以只在难任务上用。两级分流的做法：先用 flash 跑，带一个置信度或校验步骤，不通过再升级到 pro。这样贵档只承担少数请求。
峰谷定价：一个必须留意的变量
官方定价页同时说明了峰谷定价政策——高峰时段的价格会是常规价格的两倍，高峰时段为北京时间每日 9:00–12:00 和 14:00–18:00；该政策的生效日期以官方公告为准。
对成本估算的影响是实打实的：如果你的业务流量恰好集中在工作时间，那大部分调用都落在高峰时段，按常规价估会低估一倍。
应对办法有两个方向：
能错峰的错峰。 批量处理、离线分析、数据清洗这类不要求实时的任务，挪到低谷时段跑。这是纯收益，没有副作用。
不能错峰的按上浮价估。 实时业务没法挪，那就在预算里按上浮后的价格算，别用常规价给自己一个好看的数字。
具体政策以官方公告为准——这类规则调整频繁，建议在做正式预算前再核一次。
怎么把这些数代进预算
- 用 token 计算器量出单次请求的输入输出 token。
- 把输入拆成「固定前缀」和「变化部分」，估一个命中率。
- 实际输入成本 ≈ 固定前缀 × 命中价 + 变化部分 × 未命中价。
- 加上输出成本，乘调用量，再按峰谷时段占比做修正。
- 结果代进月成本估算器和其他厂商对比。
第 2 步的命中率是整个估算里最不确定的一项，建议给一个区间（悲观 / 乐观各算一遍），而不是拍一个数。
什么样的应用最受益
从这个价格结构反推，最适合的应用有三个特征。
一、system prompt 长而稳定。 角色设定、输出规范、领域知识写得越详细，固定前缀越长，缓存能覆盖的比例越高。有意思的是，这和「压缩 prompt 省钱」的直觉相反——在缓存命中稳定的前提下，长 prompt 的边际成本很低，你反而可以把指令写得更充分来提升效果。
二、调用频率高。 缓存有存活时间，频率高才能在存活期内多次复用。低频调用的场景，缓存往往等不到复用就过期了。
三、工具定义多。 Agent 类应用挂着大量工具，工具 schema 每次都要发。这部分是典型的固定前缀，交给缓存后收益很直接。
反过来，如果你的请求前缀高度个性化（每个用户一套设定）、或者调用很稀疏，那缓存帮不上太多忙，成本优化要往别的方向想——见大模型 API 降本十招。
一个实操建议：先验证命中，再谈优化
开了缓存不等于命中了。建议上线后先做一件事：从响应的 usage 字段里取缓存命中的 token 数，记进日志，算出命中率。
命中率接近零的话，先别急着算成本，去查前缀是不是被污染了——时间戳、请求 ID、用户信息、集合遍历顺序，这四类是最常见的元凶。排查方法见提示缓存命中率上不去？八个常见原因。
确认命中之后再回来算账，那时候的数字才有意义。
关于本文数据
本文所有价格均来自 DeepSeek 官方定价页 api-docs.deepseek.com/quick_start/pricing，核对日期 2026-08-06。模型命名、上下文长度、峰谷政策同样以该页为准。
厂商调价、模型改名、政策生效都可能发生在本文发布之后，做预算请以你查询当天的官方页面为准。想看其他厂商的计费口径，读国产大模型 API 价格对比；想了解缓存的通用计费结构，读提示缓存是怎么计费的。
三个高频问题
问：缓存命中价这么低，是不是可以把 prompt 写得很长？ 在命中稳定的前提下，长前缀的边际成本确实很低。但要注意两点：第一次写入仍按未命中价计；长上下文还可能影响模型的注意力分配，不是越长越好。
问：峰谷定价会不会影响缓存价？ 以官方公告为准。做预算时保守一点，按上浮后估更稳妥。
问：两个档位的缓存机制一样吗？ 官方定价页对两个档都列了命中与未命中价，机制是一致的，差别在绝对数值上。
一句话记住
在缓存命中价与未命中价差出两个数量级的价格结构下，命中率就是你的实际单价。同样的调用量、同样的模型，前缀设计得好与不好，账单可以差出好几倍。所以拿到这类定价结构的第一件事不是比档位，而是把请求前缀钉死、把命中率监控起来。