第二章：Transformer解码器原理：自注意力机制与KV Cache的硬件视角

大家好，我是你们的老朋友。今天咱们来聊聊Transformer解码器里最核心的两个东西——自注意力机制和KV Cache。说实话，这两个概念我当年刚接触时也绕了不少弯路。尤其是KV Cache，很多人只知其名，不知其所以然。今天我就从硬件视角，带大家彻底搞明白：为什么KV Cache是显存杀手？

2.1 自注意力机制：解码器的灵魂

先说说自注意力。你想想看，一个模型要生成下一个词，它得知道前面已经说了什么吧？自注意力就是干这个的——让每个位置都能“看到”之前的所有位置。

公式其实不复杂：

Attention(Q, K, V) = softmax(Q × K^T / √d) × V

Q是查询，K是键，V是值。说白了，Q问“我该关注谁？”，K回答“我有什么信息？”，V给出“具体内容”。

我在项目中遇到过一个问题：刚开始做推理时，每次生成一个token，都要把前面所有token的K和V重新算一遍。这效率低得让人抓狂。后来我才意识到——其实K和V是可以复用的。

2.2 KV Cache：显存杀手登场

好，既然K和V可以复用，那我们就把它存起来。这就是KV Cache的由来。

KV Cache说白了就是一个缓存表。每生成一个token，就把它的K和V存进去。下次生成新token时，直接从缓存里取之前的K、V，省掉重复计算。

但问题来了——这个缓存有多大？

我们来算一笔账：

参数	数值
模型层数	32层
注意力头数	32头
每头维度	128
序列长度	2048
数据类型	FP16 (2字节)

每个token的KV Cache大小 = 2 × 32 × 32 × 128 × 2 = 524,288 字节 ≈ 0.5 MB

2048个token呢？0.5 MB × 2048 ≈ 1 GB

嗯，这里要注意：这还只是单条序列。如果你同时处理多个请求，显存消耗直接翻倍。我见过一个项目，8张A100跑推理，KV Cache占了60%以上的显存。你说它是不是显存杀手？

2.3 硬件视角：为什么KV Cache这么吃显存？

从硬件角度看，KV Cache的问题在于：

• 存储密度低：每个token的K、V都是高维向量，没法压缩
• 访问模式差：每次生成新token，都要读取所有之前的K、V，内存带宽压力大
• 生命周期长：整个生成过程中，KV Cache一直占着显存不放

我个人的习惯是，在硬件选型时，会先估算KV Cache的峰值占用。比如一个7B模型，序列长度4096，batch size 64，KV Cache就能吃掉几十GB显存。这时候你再看A100的80GB显存，其实也没那么宽裕。

2.4 优化思路：怎么跟显存杀手过招？

既然KV Cache是显存杀手，那我们就得想办法对付它。我总结了几种常见思路：

1. 量化：把FP16降到INT8，显存直接减半。代价是精度略有损失，但推理场景下通常可以接受。
2. 共享KV Cache：多个请求如果前缀相同，可以共享KV Cache。这在对话场景里特别有用。
3. 滑动窗口：只保留最近N个token的KV Cache，远的直接丢掉。适合长序列场景。
4. 稀疏注意力：不是所有位置都需要关注，只关注部分位置，减少KV Cache大小。

2.5 核心逻辑图：KV Cache的生死循环

下面这张图，我画了KV Cache在推理过程中的完整生命周期。从生成第一个token开始，到最终输出结束，每一步都离不开它。

从这张图你能看到，KV Cache的读写是串行的。每个新token都要读取全部历史K、V，这导致内存带宽成为瓶颈。我实测过，在A100上，当序列长度超过2048时，内存带宽利用率能到90%以上，计算单元反而在等数据。

2.6 实战建议：部署时怎么应对？

最后，给几个实战建议：

• 估算显存：部署前，用公式算一下KV Cache的峰值占用。公式很简单：层数 × 头数 × 每头维度 × 序列长度 × 2 × 数据类型字节数
• 监控指标：上线后，盯着KV Cache的显存占用和内存带宽利用率。这两个指标能告诉你瓶颈在哪。
• 动态调整：如果显存吃紧，可以动态降低batch size或序列长度。别等到OOM再处理。

好了，这一章就到这里。下一章我们聊聊更具体的——怎么在GPU上高效实现自注意力。到时候我会分享一些我踩过的坑，保证让你少走弯路。