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

在大模型 API 的使用场景中，用户的输入有相当比例是重复的。举例说，用户的 prompt 往往有一些重复引用的部分；再举例说，多轮对话中，每一轮都要将前几轮的内容重复输入。

为此，DeepSeek 启用上下文硬盘缓存技术，把预计未来会重复使用的内容，缓存在分布式的硬盘阵列中。如果输入存在重复，则重复的部分只需要从缓存读取，无需计算。该技术不仅降低服务的延迟，还大幅削减最终的使用成本。

缓存命中的部分，DeepSeek 费用为 0.1元 每百万 tokens。至此，大模型的价格再降低一个数量级。

 如何使用 DeepSeek API 的缓存服务

硬盘缓存服务已经全面上线，用户无需修改代码，无需更换接口，硬盘缓存服务将自动运行，系统自动按照实际命中情况计费。

注意，只有当两个请求的前缀内容相同时（从第 0 个 token 开始相同），才算重复。中间开始的重复不能被缓存命中。

以下为两个经典场景的缓存举例：

多轮对话:下一轮对话会命中上一轮对话生成的上下文缓存

数据分析:后续具有相同前缀的请求会命中上下文缓存

 多种应用能从上下文硬盘缓存中受益：

• 具有长预设提示词的问答助手类应用

• 具有长角色设定与多轮对话的角色扮演类应用

• 针对固定文本集合进行频繁询问的数据分析类应用

• 代码仓库级别的代码分析与排障工具

• ...

 如何查询缓存命中情况

在 API 返回的 usage 中，增加了两个字段，帮助用户实时监测缓存的命中情况：

1. prompt_cache_hit_tokens：本次请求的输入中，缓存命中的 tokens 数（ 0.1 元 / 百万 tokens）
2. prompt_cache_miss_tokens：本次请求的输入中，缓存未命中的 tokens 数（1 元 / 百万 tokens）

 降低服务延迟

输入长、重复内容多的请求，API 服务的首 token 延迟将大幅降低。

举个极端的例子，对 128K 输入且大部分重复的请求，实测首 token 延迟从 13 秒降低到 500 毫秒。

 降低整体费用

最高可以节省 90% 的费用（需要针对缓存特性进行优化）。

即使不做任何优化，按历史使用情况，用户整体节省的费用也超过 50%。

缓存没有其它额外的费用，只有0.1 元每百万 tokens。缓存占用存储无需付费。

 缓存的安全性问题

本缓存系统在设计的时候已充分考虑了各种潜在的安全问题。

每个用户的缓存是独立的，逻辑上相互不可见，从底层确保用户数据的安全和隐私。

长时间不用的缓存会自动清空，不会长期保留，且不会用于其他用途。

 为何 DeepSeek API 能率先采用硬盘缓存

根据公开的信息，DeepSeek 可能是全球第一家在 API 服务中大范围采用硬盘缓存的大模型厂商。

这得益于 DeepSeek V2 提出的 MLA 结构，在提高模型效果的同时，大大压缩了上下文 KV Cache 的大小，使得存储所需要的传输带宽和存储容量均大幅减少，因此可以缓存到低成本的硬盘上。

 DeepSeek API 的并发和限流

DeepSeek API 服务按照每天 1 万亿的容量进行设计。对所有用户均不限流、不限并发、同时保证服务质量。请放心加大并发使用。

注1. 缓存系统以 64 tokens 为一个存储单元，不足 64 tokens 的内容不会被缓存

注2. 缓存系统是“尽力而为”，不保证 100% 缓存命中

注3. 缓存不再使用后会自动被清空，时间一般为几个小时到几天