LLM 推理核心链路&缓存命中讲解

幻灵尔依 2026-08-18 0 阅读8分钟

提问：

输入 Prompt  
↓  
Token 化  
↓  
Transformer 处理  
↓  
产生中间计算状态  
↓  
生成回答

Prompt Cache 主要缓存的是中间计算状态，常见实现里可以理解成 **KV Cache**。

帮我讲解这里面的所有名词，然后串起来

---

答案：

可以。你现在问到的是 LLM 推理最核心的一条链路。我先不讲复杂数学，而是把每个名词拆开，再把它们串成一条完整的“模型到底干了什么”。

先记住这张总图：

你输入一句话
     ↓
Prompt
     ↓
Tokenizer
     ↓
Token
     ↓
Embedding
     ↓
Transformer
     ↓
Attention
     ↓
KV Cache
     ↓
预测下一个 Token
     ↓
不断重复
     ↓
生成回答

而 Prompt Cache 本质上就是想办法把前面已经算过的东西保存下来，下一次不要重复计算。

---

一、先从 Prompt 开始

假设你问：

请解释什么是 JavaScript 闭包？

这整个输入就叫：

Prompt（提示词 / 输入提示）

Prompt 不一定只有你输入的这一句话。

在 Claude Code、Kimi Code、ChatGPT 这种 Agent 场景里，实际上可能是：

System Prompt
+
工具定义
+
项目规则
+
CLAUDE.md
+
历史对话
+
代码内容
+
你这次的问题

例如：

[System]
你是一个编程助手……

[Rules]
项目使用 Vue 2……

[History]
用户：帮我实现登录
AI：……

[Code]
src/login.vue……

[User]
把登录按钮改成蓝色

这些合起来，才是模型真正看到的 Prompt。

---

二、Prompt → Token

计算机不能直接理解：

请解释什么是 JavaScript 闭包？

所以第一步要做：

Tokenization（分词 / Token 化）

也就是把文字拆成模型认识的基本单位：

请解释什么是 JavaScript 闭包？
        ↓
Token Token Token Token Token Token ...

注意：

Token 不等于汉字，也不等于单词。

例如：

hello world

可能类似：

hello
world

而：

JavaScript

可能被拆成多个 token。

中文也可能一个汉字对应一个 token，也可能多个字符组成一个 token，具体取决于 tokenizer。

---

三、Token 是什么？

你可以把 Token 理解成：

模型处理文字时使用的“积木”。

例如为了方便理解，我们假设：

我喜欢吃苹果

被拆成：

我
喜欢
吃
苹果

模型实际处理的是：

[1234, 5678, 2345, 7890]

也就是说：

文字
 ↓
Token
 ↓
Token ID

所以模型实际上并不是直接处理：

我喜欢吃苹果

而是处理类似：

[1234, 5678, 2345, 7890]

---

四、Token ID → Embedding

接下来又出现一个非常重要的东西：

Embedding（嵌入 / 向量表示）

Token ID 本身没有什么语义。

比如：

1234

这个数字本身并不代表“苹果”。

模型需要把：

1234

转换成一个高维向量：

[0.12, -0.53, 0.81, ..., 0.27]

这就是 Embedding。

你可以粗略理解成：

"苹果"
   ↓
Token ID
   ↓
Embedding
   ↓
[0.12, -0.53, 0.81, ...]

这个向量是模型可以进行数学运算的形式。

---

五、然后进入 Transformer

这时候：

文字
 ↓
Token
 ↓
Token ID
 ↓
Embedding

模型终于拿到了可以计算的数据。

接下来进入：

Transformer

Transformer 是现代 GPT、Claude、Gemini、Kimi 等大语言模型的核心架构。

你可以把它理解成：

一个非常巨大的“语言计算网络”。

它里面有大量重复的 Transformer Block：

Transformer
│
├── Block 1
├── Block 2
├── Block 3
├── Block 4
├── ...
└── Block N

比如某个模型可能有几十层甚至上百层。

数据会一层一层经过这些 Block。

---

六、Transformer 里面最重要的东西：Attention

Transformer 最著名的机制就是：

Attention（注意力机制）

它解决一个核心问题：

当前这个 Token，应该关注上下文中的哪些 Token？

例如：

小明把苹果放在桌子上，因为它很红。

这里：

它

到底指什么？

模型需要判断：

它 → 苹果

而不是：

它 → 桌子

Attention 就是在做类似这样的事情。

---

七、Q / K / V 是什么？

Attention 里面又有三个超级重要的东西：

Q = Query
K = Key
V = Value

中文通常叫：

Query   查询
Key     键
Value   值

可以用图书馆来理解。

假设你现在问：

它指的是什么？

这就是：

Query

模型拿着 Query 去看其他 Token：

苹果
桌子
小明

每个 Token 都有：

Key
Value

模型先比较：

Query 和 Key

看看：

“我现在应该关注谁？”

然后决定：

苹果    → 0.8
桌子    → 0.1
小明    → 0.1

于是主要读取：

苹果对应的 Value

所以：

Q
 ↓
和 K 比较
 ↓
得到 Attention 权重
 ↓
加权读取 V
 ↓
得到新的信息

这就是 Attention 的核心思想。

---

八、那 KV Cache 到底是什么？

现在终于可以理解你最开始问的东西了。

假设模型正在处理：

你好，我是一名前端开发工程师，我最近在学习 AI Agent。

模型处理这些 Token 时，会在 Attention 中产生：

K
V

也就是：

Key
Value

这些计算结果之后还会继续被使用。

所以没必要每次都重新算。

于是模型可以把它们保存下来：

K
V
 ↓
KV Cache

也就是：

把已经处理过的 Token 对应的 Key / Value 缓存起来。

---

九、为什么叫 KV Cache，而不是 Attention Cache？

因为 Attention 里面有：

Q
K
V

但在自回归生成过程中：

Q 通常是当前新 Token 的查询，而过去 Token 的 K/V 可以复用。

所以缓存的重点就是：

K + V

因此叫：

KV Cache

---

十、用一个聊天过程理解 KV Cache

假设你说：

用户：我是一个前端开发工程师。

模型处理：

我是一个前端开发工程师

产生：

K1 V1
K2 V2
K3 V3
K4 V4
...

保存：

KV Cache
├── K1 V1
├── K2 V2
├── K3 V3
└── ...

然后模型开始生成：

ä½ 

接下来生成：

好

然后：

！

每生成一个新 Token，就继续产生新的 K/V：

KV Cache

旧：
K1 V1
K2 V2
K3 V3
...

新增：
Kn Vn

所以 KV Cache 会不断增长。

---

十一、那么“生成回答”到底是怎么回事？

这是理解 LLM 的另一个关键点：

LLM 本质上是在不断预测“下一个 Token”。

例如：

用户：
中国的首都是

模型计算：

中国的首都是
        ↓
预测下一个 Token
        ↓
北京

然后把：

北京

加入上下文：

中国的首都是北京

再预测：

下一 Token

可能得到：

。

继续：

中国的首都是北京。

再预测：

...

所以：

生成回答

实际上是：

预测 Token 1
 ↓
预测 Token 2
 ↓
预测 Token 3
 ↓
预测 Token 4
 ↓
...

这叫：

Autoregressive Generation（自回归生成）

---

十二、把整个过程串起来

现在我们把所有概念连起来。

你输入：

请帮我解释 Vue 的 computed。

第一步：Prompt

Prompt
↓
请帮我解释 Vue 的 computed。

---

第二步：Tokenizer

Prompt
↓
Tokenizer
↓
Token
↓
[Token1, Token2, Token3, ...]

---

第三步：Embedding

Token
↓
Embedding
↓
高维向量

---

第四步：Transformer

Embedding
↓
Transformer Block
↓
Transformer Block
↓
Transformer Block
↓
...

---

第五步：Attention

每一层里面会进行 Attention：

Q
K
V
 ↓
Attention
 ↓
新的隐藏状态

其中过去 Token 的：

K
V

可以缓存：

K + V
 ↓
KV Cache

---

第六步：预测下一个 Token

Transformer 最终得到：

隐藏状态
 ↓
Vocabulary 中每个 Token 的概率

例如：

computed    35%
是一种       20%
用于         10%
...

模型选择下一个 Token。

---

第七步：继续生成

假设生成：

computed

然后再次：

Transformer
 ↓
预测下一个 Token

不断循环：

Token
 ↓
Transformer
 ↓
预测下一个 Token
 ↓
加入上下文
 ↓
Transformer
 ↓
预测下一个 Token
 ↓
...

直到：

EOS / 停止条件

---

十三、现在再理解 Prompt Cache

这就非常容易了。

假设第一次请求：

System Prompt
+
项目规则
+
10000 tokens 历史上下文
+
用户问题

模型需要处理前面的：

System Prompt
项目规则
历史上下文

并产生大量 Transformer 中间状态，其中包括 KV：

K1 V1
K2 V2
K3 V3
...
K10000 V10000

这些可以被缓存。

---

第二次请求：

System Prompt
+
项目规则
+
10000 tokens 历史上下文
+
新的用户问题

如果前面的 Prompt 前缀完全一致：

System Prompt
项目规则
历史上下文

那么服务端可以：

旧 Prompt
   ↓
已经算过
   ↓
KV Cache
   ↓
直接复用

不用重新从：

Token
 ↓
Embedding
 ↓
Transformer
 ↓
Attention

把这 10000 tokens 再完整处理一遍。

然后只需要从新的部分继续：

缓存的 KV
   +
新 Token
   ↓
Transformer
   ↓
生成回答

---

十四、所以你之前那个问题，现在可以精确回答了

你问：

两次输入相同，那么提示词命中，大模型就能直接返回结果，而不用计算吗？

现在答案可以精确到：

❌ 不是

而是：

第一次

Prompt
 ↓
Token
 ↓
Embedding
 ↓
Transformer
 ↓
Attention
 ↓
KV Cache
 ↓
生成回答

第二次：

相同 Prompt
 ↓
命中 Prompt Cache
 ↓
复用已经计算好的 KV
 ↓
只处理新增内容
 ↓
Transformer
 ↓
生成新的回答

所以：

Prompt Cache 节省的是“处理输入上下文”的计算，不是“生成答案”的计算。

---

十五、最后给你一张“脑内模型”

以后你看到：

Token
Embedding
Transformer
Attention
QKV
KV Cache
Prompt Cache
Context
Input Tokens
Output Tokens

可以直接套这张图：

                 用户输入
                    │
                    ▼
                 Prompt
                    │
                    ▼
                Tokenizer
                    │
                    ▼
                  Tokens
                    │
                    ▼
                Embedding
                    │
                    ▼
              ┌─────────────┐
              │ Transformer │
              │             │
              │  Attention  │
              │   Q K V     │
              │     │       │
              └─────┼───────┘
                    │
                 K + V
                    │
                    ▼
                KV Cache
                    │
                    │
                    ▼
             预测下一个 Token
                    │
                    ▼
             生成一个 Token
                    │
                    ▼
             再预测下一个 Token
                    │
                    ▼
                  ...
                    │
                    ▼
                  回答

而 Prompt Cache 可以理解成更高一层的工程优化：

第一次请求
────────────────────────
Prompt
 ↓
Transformer
 ↓
产生 KV
 ↓
保存 Cache


第二次请求
────────────────────────
相同 Prompt
 ↓
★ Cache Hit
 ↓
复用 KV
 ↓
新 Prompt
 ↓
Transformer
 ↓
生成新回答

最重要的三个关系：

Token
= 模型处理文字的基本单位

Transformer
= 真正进行语言理解/预测计算的核心网络

KV Cache
= 把 Transformer 在历史 Token 上算出来、后面还能复用的 K/V 中间结果保存下来

再往上一层：

Prompt Cache
= 利用这些可复用的计算状态，避免每次请求都重新处理相同的 Prompt 前缀

这也是为什么你在研究 Claude Code / Kimi Code / Pi 的 token 消耗和 cache 命中时，不能简单把 input tokens 理解成“模型这次从头计算了多少东西”。Input Token 是输入量，KV/Prompt Cache 是这些输入中有多少计算可以复用，这是两个维度。