DeepSeek API 大规模应用硬盘缓存技术：大模型平民化的关键一步

—— 兼论大模型API价格战的深层逻辑、用户体验优化与技术普惠

图片来源：DeepSeek 官方文档

在人工智能大模型领域竞争白热化的当下，DeepSeek 近期宣布其 API 服务创新性地采用了硬盘缓存技术，并随之祭出震撼性的价格调整——缓存命中部分的价格相较于之前的价格直接降至十分之一，再次刷新了行业价格底线。作为长期关注大模型技术和产业趋势的第三方评论家，笔者认为，DeepSeek 此举不仅是一次由技术革新驱动的成本革命，更是对大模型API用户体验的深度优化，以及加速大模型技术普惠化的重要一步。

技术革新：硬盘缓存的精妙之处与性能跃升

大模型 API 的高昂成本和延迟问题，长期制约着其广泛应用。DeepSeek 深刻洞察到，用户请求中普遍存在的上下文重复性是造成这些问题的关键。例如，多轮对话中，每一轮都需要重复输入之前的对话历史；长文本处理任务中，Prompt 中常常包含重复引用的部分。重复计算 Token 既浪费算力，又增加延迟。

针对这一痛点，DeepSeek 创造性地引入了上下文硬盘缓存技术。其核心原理是将预测未来可能重复使用的上下文内容，例如对话历史、系统预设、Few-shot 示例等，智能缓存至分布式的硬盘阵列中。当用户发起新的 API 请求时，系统将自动检测输入的前缀部分是否与缓存内容匹配 (注意：必须是前缀完全一致才能命中缓存)。如果命中，系统便可直接从高速硬盘缓存中读取重复部分，无需重新计算，从而实现延迟大幅降低和成本显著削减的双重优化。

为了更清晰地理解缓存的工作方式，我们来看几个 DeepSeek 官方提供的示例：

例一：多轮对话场景

核心特点：后续对话轮次自动命中上一轮的上下文缓存。

在多轮对话中，用户通常会围绕一个主题进行连续提问。DeepSeek 的硬盘缓存可以有效地复用对话上下文。例如，在以下对话场景中：

第一次请求：

messages: [
{"role": "system", "content": "你是一位乐于助人的助手"},
{"role": "user", "content": "中国的首都是哪里？"}
]

第二次请求：

messages: [
{"role": "system", "content": "你是一位乐于助人的助手"},
{"role": "user", "content": "中国的首都是哪里？"},
{"role": "assistant", "content": "中国的首都是北京。"},
{"role": "user", "content": "美国的首都是哪里？"}
]

图片来源：DeepSeek 官方文档

多轮对话场景下的缓存命中示例：后续对话轮次自动命中上一轮的上下文缓存。

在第二次请求时，由于前缀部分（system 消息 + 第一个 user 消息）与第一次请求完全相同，这部分内容将被缓存命中，无需重复计算，从而降低延迟和成本。

根据 DeepSeek 官方数据，对于128K 输入且大部分重复的极端场景，实测首 token 延迟从 13 秒骤降至 500 毫秒，性能提升幅度惊人。即使在非极端场景下，也能有效降低延迟，提升用户体验。

更值得称赞的是，DeepSeek 的硬盘缓存服务完全自动化运行，对用户无感。无需用户修改任何代码或更换 API 接口，即可直接享受缓存带来的性能和价格优势。用户可以通过 API 返回的 usage 字段中新增的 prompt_cache_hit_tokens (缓存命中 tokens 数) 和 prompt_cache_miss_tokens (未命中 tokens 数)字段，实时监控缓存命中情况，从而更好地评估和优化缓存效果。

DeepSeek 能够率先大规模应用硬盘缓存技术，与其先进的模型架构密不可分。DeepSeek V2 提出的 MLA 结构 (Multi-head Latent Attention)，在保证模型性能的同时，显著压缩了上下文 KV Cache 的大小，使得将 KV Cache 存储到低成本的硬盘上成为可能，为硬盘缓存技术的落地奠定了基础。

理解 DeepSeek-R1 API 缓存命中与价格的关系：使用 DeepSeek-R1 API 常见问题

应用场景：从长文本问答到代码分析，边界无限拓展

硬盘缓存技术的应用场景非常广泛，几乎所有涉及上下文输入的大模型应用都能从中受益。原文中列举了以下典型场景，并提供了更具体的示例：

• 长预设提示词的问答助手：
  • 核心特点：固定的 System Prompt 可以被缓存，降低每次请求的成本。
  • 例如：

例二：长文本问答场景

核心特点：相同文档的多次分析可命中缓存。

用户需要分析同一份财报，并进行不同的提问：

第一次请求：

messages: [
{"role": "system", "content": "你是一位资深的财报分析师..."},
{"role": "user", "content": "<财报内容>\n\n请总结一下这份财报的关键信息。"}
]

第二次请求：

messages: [
{"role": "system", "content": "你是一位资深的财报分析师..."},
{"role": "user", "content": "<财报内容>\n\n请分析一下这份财报的盈利情况。"}
]

在第二次请求中，由于 system 消息 和 user 消息中的 <财报内容> 这部分前缀与第一次请求相同，因此这部分内容可以被缓存命中，节省计算资源。

• 多轮对话的角色扮演类应用：
• 核心特点：对话历史的重复利用率高，缓存效果显著。
• （例一已详细展示）
• 针对固定文本集合的数据分析：
  • 核心特点：对同一份文档的多次分析和问答，前缀重复度高。
  • 例如，对同一份财报或法律文档进行多次分析和问答。（例二已详细展示）
• 代码仓库级别的代码分析与排障工具：
  • 核心特点：代码分析任务往往涉及大量上下文，缓存可以有效降低成本。
• Few-shot 学习：
  • 核心特点：作为 Prompt 前缀的 Few-shot 示例可以被缓存，降低多次 Few-shot 调用的成本。
  • 例如：

例三：Few-shot 学习场景

核心特点：相同的 Few-shot 示例作为前缀可命中缓存。

用户使用 Few-shot 学习来提升模型在历史知识问答方面的效果：

第一次请求：

messages: [
{"role": "system", "content": "你是一位历史学专家，用户将提供一系列问题，你的回答应当简明扼要，并以`Answer:`开头"},
{"role": "user", "content": "请问秦始皇统一六国是在哪一年？"},
{"role": "assistant", "content": "Answer:公元前221年"},
{"role": "user", "content": "请问汉朝的建立者是谁？"},
{"role": "assistant", "content": "Answer:刘邦"},
{"role": "user", "content": "请问唐朝最后一任皇帝是谁"},
{"role": "assistant", "content": "Answer:李柷"},
{"role": "user", "content": "请问明朝的开国皇帝是谁？"},
{"role": "assistant", "content": "Answer:朱元璋"},
{"role": "user", "content": "请问清朝的开国皇帝是谁？"}
]

第二次请求：

messages: [
{"role": "system", "content": "你是一位历史学专家，用户将提供一系列问题，你的回答应当简明扼要，并以`Answer:`开头"},
{"role": "user", "content": "请问秦始皇统一六国是在哪一年？"},
{"role": "assistant", "content": "Answer:公元前221年"},
{"role": "user", "content": "请问汉朝的建立者是谁？"},
{"role": "assistant", "content": "Answer:刘邦"},
{"role": "user", "content": "请问唐朝最后一任皇帝是谁"},
{"role": "assistant", "content": "Answer:李柷"},
{"role": "user", "content": "请问明朝的开国皇帝是谁？"},
{"role": "assistant", "content": "Answer:朱元璋"},
{"role": "user", "content": "请问商朝是什么时候灭亡的"},
]

在第二次请求中，由于使用了相同的 4-shot 示例 作为前缀，这部分内容可以被缓存命中，只有最后一个问题需要重新计算，从而显著降低 Few-shot 学习的成本。

图片来源：DeepSeek 官方文档

数据分析场景下的缓存命中示例：相同前缀的请求可命中缓存 (注：此处图片沿用原文数据分析示例，更侧重表达前缀重复的概念，Few-shot 示例场景可同理理解)

这些场景只是冰山一角。硬盘缓存技术的应用，真正打开了长上下文大模型 API 的应用想象空间。例如，我们可以构建更强大的长文本创作工具，处理更复杂的知识密集型任务，开发更具深度和记忆力的对话式 AI 应用。

参考：Claude带来的启发

Claude创新推出API长文本缓存功能，大幅提升处理效率与降低成本

朴素、有效的RAG检索策略：稀疏+密集混合检索并重排，并利用“提示缓存”为文本块生成整体文档相关的上下文

成本优势：价格直降数量级，普惠大模型生态

DeepSeek API 的价格调整力度堪称“史诗级”。缓存命中部分的价格仅为 0.1 元/百万 tokens，而未命中部分也仅为 1 元/百万 tokens。相比之前的价格，缓存命中部分直接降低了一个数量级。

根据 DeepSeek 官方数据，最高可节省 90% 的费用，即使不做任何优化，用户整体也能节省超过 50% 的费用。这种成本优势对于降低大模型应用门槛，加速大模型普及具有重要意义。

更值得关注的是 DeepSeek 的定价策略。缓存命中和未命中部分采用阶梯定价，鼓励用户尽可能利用缓存，优化 Prompt 设计，提高缓存命中率，从而进一步降低成本。同时，缓存服务本身和缓存存储空间均不收取任何额外费用，真正做到了普惠用户。

图片来源：DeepSeek 官方文档

DeepSeek API 价格大幅降低，缓存命中价格仅为 0.1 元/百万 tokens

DeepSeek API 的大幅降价，无疑将加速大模型价格战的演进。但与以往单纯的价格比拼不同，DeepSeek 的降价是基于技术创新和成本优化的理性降价，更具可持续性和行业推动力。这种健康的价格竞争，最终将惠及整个大模型生态，让更多开发者和企业能够以更低的成本享受到先进的大模型技术。

不限流不限并发，安全可靠的缓存服务

除了性能和价格优势，DeepSeek API 的稳定性和安全性也值得信赖。DeepSeek API 服务按照每天 1 万亿 tokens 的容量进行设计，对所有用户均不限流、不限并发，保证了在高负载情况下的服务质量。

在数据安全方面，DeepSeek 也做了充分考虑。每个用户的缓存是独立的，逻辑上相互隔离，确保用户数据的安全和隐私。长时间不用的缓存会自动清空 (通常为几个小时到几天)，不会长期保留，也不会用于其他用途，进一步降低了潜在的安全风险。

需要注意的是，缓存系统以 64 tokens 为一个存储单元，不足 64 tokens 的内容不会被缓存。同时，缓存系统是“尽力而为”，不保证 100% 缓存命中。此外，缓存构建需要秒级耗时，但对于长上下文场景来说，这点耗时完全可以接受。

模型升级与未来展望

值得一提的是，DeepSeek 在推出硬盘缓存技术的同时，也宣布 deepseek-chat 模型已升级为 DeepSeek-V3，deepseek-reasoner 模型为新模型 DeepSeek-R1。新模型在性能和能力上均有提升，而价格却大幅降低，进一步提升了 DeepSeek API 的竞争力。

根据官方价格信息，DeepSeek-V3 API (deepseek-chat) 在 2025年2月8日 24:00 前 享受优惠价格，缓存命中输入价格仅为 0.1 元/百万 tokens，未命中输入价格为 1 元/百万 tokens，输出价格为 2 元/百万 tokens。 而 DeepSeek-R1 API (deepseek-reasoner) 则定位为推理模型，拥有 32K 思维链长度 和 8K 最大输出长度，输入价格（缓存命中）为 1 元/百万 tokens，输入价格（未命中）为 4 元/百万 tokens，输出价格为 16 元/百万 tokens (包含思维链和最终答案的所有 tokens)。

DeepSeek 的一系列创新举措，展现了其持续技术投入和用户至上的理念。我们有理由相信，在 DeepSeek 以及更多创新力量的推动下，大模型技术将加速成熟，走向普惠，为各行各业带来更深远的变革。

结语

DeepSeek API 创新性地采用硬盘缓存技术，并大幅降低价格，是一次具有里程碑意义的突破。它不仅解决了大模型 API 长期存在的成本和延迟痛点，更通过技术创新，为用户带来了更优质、更普惠的大模型服务。DeepSeek 的这一步，或将重新定义大模型 API 的竞争格局，加速人工智能技术的普及和应用，最终构建一个更加繁荣、开放、普惠的大模型生态。