DeepSeek API 创新采用硬盘缓存，价格再降一个数量级

说个有意思的事儿——在大模型API的实际使用中，用户的输入其实有相当比例是重复的。比如，很多人的prompt里习惯性地带着大段的固定引用；再比如，多轮对话场景下，每一轮都得把历史对话一股脑儿地再喂进去一次。这个“重复劳动”背后，意味着一大笔计算资源被白白浪费掉了。

于是，DeepSeek搞了个硬核操作：启用上下文硬盘缓存技术。简单说，就是把那些预计未来会被反复用到的东西，提前存到分布式的硬盘阵列里。这样一来，下次再遇到同样的输入，直接读缓存就行，根本不用重新算一遍。这招不仅把服务的首token延迟打了下来，还顺带把使用成本杀到了一个新低。缓存命中的部分，DeepSeek的收费是0.1元每百万tokens——用一杯奶茶钱就能跑通很多以前想都不敢想的场景。大模型的价格，就这么实打实地又降了一个数量级。

如何用好这个缓存？门槛低到不需要你动任何代码

硬盘缓存服务已经全面上线，而且完全是个“透明”的优化。用户不需要改代码，不用换接口，系统自动帮你跑，自动按实际命中情况计费。说白了，你什么都不用做，就能享受降价福利。

不过要提一个关键点：缓存命中是有条件的。只有当两个请求的

（也就是从第0个token开始就一样）时，才算卦中。中间开始的重复，不好意思，缓存是不认的。以下两个经典场景就很典型：

• 多轮对话：
  下一轮对话会直接命中上一轮生成好的上下文缓存。

• 数据分析：
  后续带有相同前缀的请求，也能精准命中上下文缓存。

那么，实际中哪些应用最能从中受益？

• 带有长预设提示词的问答助手类应用（相当于每次请求的“开场白”都很长且固定）
• 角色扮演类应用——既要长角色设定，又有多轮对话，简直是缓存的天选之子
• 针对固定文本集合频繁提问的数据分析类应用
• 代码仓库级别的代码分析与排障工具
• 还有更多等待被挖掘的场景

如何查询命中情况？API返回里多了两个字段

为了方便用户实时监测缓存是不是真的在干活，DeepSeek在API返回的usage里加了两个新字段：

1. prompt_cache_hit_tokens：
   本次请求中，缓存命中的token数（按0.1元/百万tokens计费）

2. prompt_cache_miss_tokens：
   没有命中的token数（按1元/百万tokens计费）

一目了然，谁是“好学生”，谁是“坏账”，清清楚楚。

关键是延迟也被压下来了

对于那种输入很长、重复内容又多的请求，API的首token延迟会迎来质变。举个极端点的例子：一个128K的输入，里面大部分内容都是重复的，实测下来，首token延迟从原先的13秒直接降到了500毫秒——这不是优化，这是换了个世界。

费用能省多少？

最高可以节省90%。但注意，这个数据是理想化的，需要针对缓存特性做专门优化。不过，哪怕你啥也不优化，就按历史使用情况走，数据显示整体费用也能节省超过50%。缓存本身不收额外费用，只有0.1元每百万tokens的使用费，而缓存占用的存储空间是完全免费的。

安全性怎么保障？

这个担心可以放一放。系统在设计之初就考虑了各种潜在安全风险。每个用户的缓存是逻辑隔离的，彼此互不可见，从底层机制上保护了用户数据的安全与隐私。长时间不用的缓存会自动清空，不会长期保留，更不会被挪作他用。

为什么DeepSeek能率先做到这件事？

根据公开信息，DeepSeek很可能是全球第一家大范围采用硬盘缓存的大模型API厂商。背后的技术功臣，是DeepSeek V2提出的MLA结构。它在提升模型效果的同时，极为“优雅”地压缩了上下文KV Cache的大小，让存储所需的传输带宽和存储容量都大幅减少。这样一来，才有底气把KV Cache存到成本更低、容量更大的硬盘上——这步棋，别人不是不想走，是技术上还没法走。

最后聊聊并发和限流

DeepSeek的API服务是按每天1万亿的规模来设计的。对所有用户都不限流、不限并发，同时保证服务质量。所以，放心大胆地往上冲吧。