DeepSeek 的 Input Cache（输入缓存）是什么？一文讲清原理、作用和使用技巧

在使用 DeepSeek API 时，你可能会看到一个概念：Input Cache（输入缓存）。

很多人第一次看到都会有几个疑问：

• Input Cache 是什么？
• 它缓存的是 Prompt 还是回答？
• 为什么开启缓存后响应更快、费用更低？
• 开发时怎样才能提高缓存命中率？

本文就从这些问题出发，介绍 Input Cache 的工作原理以及在实际开发中的使用建议。

---

一、为什么需要 Input Cache？

先来看一次普通的大模型调用过程。

假设我们发送下面这样一段 Prompt：

你是一名专业的 Java 面试官。

请根据下面要求生成面试题：

要求：
1. 包括 Java 基础
2. 包括 JVM
3. 包括 Spring
4. 包括 MySQL
5. 每道题附答案

现在请生成 20 道题。

对于模型来说，它并不是直接"读懂"这段文字，而是需要经过一系列计算：

Prompt
    │
    ▼
Tokenizer 分词
    │
    ▼
Token
    │
    ▼
Embedding
    │
    ▼
Transformer 多层计算
    │
    ▼
生成回答

真正消耗 GPU 算力的是 Transformer 对输入进行编码计算。

如果每次请求都包含几千甚至上万 Token，而这些内容又基本相同，那么模型每次都重新计算一遍，就会浪费大量算力和时间。

因此，大模型服务通常都会引入 Input Cache 来减少重复计算。

---

二、什么是 Input Cache？

Input Cache 可以理解为：

把模型已经计算过的输入内容缓存起来，当下次请求拥有相同的前缀时，直接复用之前的计算结果，而不是重新计算。

例如第一次请求：

你是一名 Java 老师。

请根据下面要求生成试题：

要求：
1.
2.
3.
4.
5.

生成 Java 集合相关试题。

第二次请求：

你是一名 Java 老师。

请根据下面要求生成试题：

要求：
1.
2.
3.
4.
5.

生成 JVM 相关试题。

可以发现：

只有最后一句不同。

前面的 Prompt 完全一致。

第一次请求：

固定 Prompt
        │
        ▼
GPU 完整计算
        │
        ▼
缓存中间结果

第二次请求：

固定 Prompt
        │
        ▼
直接读取缓存
        │
        ▼
只计算后面新增内容

因此：

• 响应速度更快；
• GPU 计算量更少；
• API 成本更低。

---

三、缓存的到底是什么？

很多人以为 Input Cache 缓存的是回答，其实并不是。

它缓存的是：

模型处理输入 Prompt 时产生的中间计算结果（KV Cache）。

也就是说，缓存的是：

Prompt
    │
    ▼
Transformer 编码计算
    │
    ▼
KV Cache（缓存）

而不是：

Prompt
    │
    ▼
最终回答

所以，即使输入前半部分相同，只要最后的问题不同，模型依然可以生成完全不同的回答。

例如：

第一次：

介绍 Python。

第二次：

介绍 Java。

虽然最终回答不同，但前面的系统 Prompt 可以直接复用缓存。

---

四、缓存的是计算过程，不是最终回答

这是 Input Cache 最容易产生误解的地方。

很多人第一次看到"缓存"两个字，就会认为：

模型是不是把回答一起缓存了？下次直接返回？

答案是否定的。

DeepSeek 的输入缓存不会缓存最终回答，缓存的是模型处理输入时产生的中间状态，包括：

• 输入 Prompt 的重复前缀
• 长上下文对应的中间计算结果
• 可复用的 KV Cache（Key-Value Cache）状态

也就是说，它缓存的是：

模型"读懂前面这段 Prompt"所完成的计算。

而不是：

模型最后生成的回答。

例如第一次请求：

你是一位 Java 面试官……

请生成 Java 集合相关的面试题。

第二次请求：

你是一位 Java 面试官……

请生成 JVM 相关的面试题。

由于前面的 Prompt 完全一致，模型可以直接复用已经计算好的上下文状态，只需要继续处理最后变化的内容。

需要注意的是，即使命中了缓存，模型仍然会重新生成回答。

因此：

• 回答仍然需要重新推理；
• temperature、top_p 等采样参数依然会生效；
• 输出仍然可能存在随机性。

换句话说，Input Cache 只是减少了模型理解输入的计算量，并没有跳过回答生成这一过程。

DeepSeek 官方文档也明确说明：输入缓存只匹配用户输入的前缀部分，输出仍然需要继续推理，因此依然会受到 temperature、top_p 等参数的影响。

---

五、什么情况下能够命中缓存？

Input Cache 是否能够生效，取决于输入前缀是否一致。

这里需要特别注意：

不是意思相同，而是 Token 完全一致。

例如：

第一次：

你是一名 AI 老师。

第二次：

你是一名AI老师。

虽然人看起来几乎一样，但是：

AI 老师

AI老师

Tokenizer 分词后的结果可能已经不同，因此缓存无法命中。

再例如：

第一次：

生成 10 道题。

第二次：

生成 20 道题。

由于只有最后几个 Token 不同，因此前面的内容仍然可以命中缓存。

---

六、哪些内容最适合缓存？

一般来说，长期不变的 Prompt 最适合缓存。

1. System Prompt

例如：

你是一位专业 Java 老师。

输出 JSON。

严格遵循 Schema。

禁止输出 Markdown。

System Prompt 基本每次请求都相同，因此缓存命中率最高。

---

2. Few-shot 示例

例如：

输入：

......

输出：

......

输入：

......

输出：

......

Few-shot 示例通常有几百到几千 Token，非常适合缓存。

---

3. RAG 检索内容

例如：

知识库：

......

......

用户问题：

......

如果知识库内容没有变化，那么大部分 Token 都可以复用。

---

4. 固定业务规则

例如：

必须输出 JSON。

必须包含以下字段。

禁止解释。

禁止 Markdown。

这些规则建议始终保持一致。

---

七、哪些情况不会命中缓存？

以下情况都会导致缓存命中率下降。

Prompt 经常变化

例如：

当前时间：

2026-07-20

下一次：

当前时间：

2026-07-21

由于 Token 已经变化，因此缓存失效。

---

每次加入随机 UUID

例如：

request_id=238947

下一次：

request_id=928374

同样无法命中缓存。

---

不断增长的聊天记录

例如：

用户

AI

用户

AI

......

随着历史越来越长，缓存收益会逐渐下降。

---

八、为什么 Input Cache 可以降低费用？

因为模型推理过程中，真正消耗算力的是：

输入编码阶段。

例如：

Prompt：

5000 Token

回答：

300 Token

模型的大部分计算，都发生在：

5000 Token
        │
        ▼
Transformer 编码

如果这 5000 Token 可以直接读取缓存，那么 GPU 就不用重复计算。

因此：

很多模型厂商都会对：

Cache Hit Token

采用更低的计费价格。

这也是为什么开启 Input Cache 后，API 成本通常会下降。

具体价格以 DeepSeek 官方文档为准。

---

九、开发时如何提高缓存命中率？

想充分利用 Input Cache，可以遵循以下几个原则。

1. 固定 System Prompt

不要每次动态拼接 Prompt。

例如：

你是一位专业老师……

尽量保持完全一致。

---

2. Few-shot 放在前面

Few-shot 示例尽量固定。

不要频繁修改示例内容。

---

3. 固定内容放前面

推荐按照下面的顺序组织 Prompt：

System Prompt

↓

Few-shot

↓

知识库内容

↓

用户问题

这样只有最后的问题发生变化，前面的内容都可以命中缓存。

---

4. 避免在固定 Prompt 中加入动态信息

例如：

当前时间

随机 UUID

随机编号

当前日期

都会降低缓存命中率。

---

十、Input Cache 与聊天记忆（Memory）的区别

很多人容易把 Input Cache 和 Memory 混为一谈。

实际上，它们解决的是两个完全不同的问题。

Input Cache	Memory
减少重复计算	保存历史上下文
缓存 Prompt 的计算结果	记录用户历史信息
提高响应速度	提高回答连续性
降低 API 成本	增强长期记忆能力
用户几乎无感知	用户能够感知

简单来说：

• Input Cache 关注的是性能优化。
• Memory 关注的是上下文记忆。

两者可以同时存在，并不会互相替代。

---

总结

Input Cache 本质上是一种推理优化技术。

它不会缓存模型最终生成的回答，而是缓存模型处理输入时产生的中间计算结果。当多个请求拥有相同的前缀 Prompt 时，模型可以直接复用这些计算结果，只对新增或变化的部分继续推理。

对于 RAG、智能客服、Agent、AI 出题系统等需要频繁调用大模型的应用来说，合理设计 Prompt 结构、提高缓存命中率，可以带来以下收益：

• 减少重复计算，提高响应速度；
• 降低 GPU 算力消耗，减少 API 成本；
• 提高系统吞吐量，在高并发场景下表现更稳定。

一句话总结：

Input Cache 的本质不是缓存回答，而是缓存模型理解输入时的计算过程。通过复用相同 Prompt 前缀的计算结果，实现"少算一次"，从而达到提速、降本的目的。