75 lines
2.4 KiB
Markdown
75 lines
2.4 KiB
Markdown
---
|
||
title: "滚动 KV 缓存 (Rolling KV Cache)"
|
||
created: 2026-05-14
|
||
updated: 2026-05-14
|
||
type: concept
|
||
tags: [llm, inference, kv-cache, streaming, attention]
|
||
sources: ["https://arxiv.org/abs/2309.17453"]
|
||
---
|
||
|
||
# 滚动 KV 缓存 (Rolling KV Cache)
|
||
|
||
## 定义
|
||
|
||
滚动 KV 缓存是 [[streaming-llm|StreamingLLM]] 框架的核心机制，将 KV 缓存分为两部分：
|
||
|
||
1. **Attention Sinks**（4 个初始 Token 的 KV）：稳定 SoftMax 注意力分布
|
||
2. **Rolling KV Cache**（最近 $L$ 个 Token 的 KV）：负责语义建模
|
||
|
||
两部分共同构成一个固定大小（$L+4$）的 KV 缓存，随着新 Token 的生成不断滚动更新。
|
||
|
||
## 数据结构
|
||
|
||
```
|
||
生成 Token 7 时:
|
||
[0][1][2][3] | [ ][ ][ ][4][5][6][7]
|
||
↑ Attention ↑ Rolling KV Cache
|
||
Sinks (最近 L 个)
|
||
|
||
生成 Token 8 时:
|
||
[0][1][2][3] | [ ][ ][ ][ ][5][6][7][8]
|
||
↑ 不变 ↑ Token 4 被逐出，Token 8 加入
|
||
```
|
||
|
||
## 关键设计决策
|
||
|
||
### 位置编码在 Cache 内部分配
|
||
|
||
StreamingLLM **不**保留原始文本中的位置索引，而是在 cache 内部分配连续位置：
|
||
|
||
- Cache 中 Token = `[0, 1, 2, 3, 6, 7, 8]`，解码第 9 个 Token
|
||
- 分配的位置 = `[0, 1, 2, 3, 4, 5, 6, 7]`
|
||
- **而非**原始位置 `[0, 1, 2, 3, 6, 7, 8, 9]`
|
||
|
||
> 这是 StreamingLLM 性能的关键——跳跃的位置索引会破坏相对位置编码的一致性。
|
||
|
||
### RoPE 兼容性
|
||
- 在应用旋转变换**之前**缓存 Key
|
||
- 每个解码步对滚动缓存中的 Key 重新应用位置变换
|
||
- 确保相对位置信息正确反映 cache 内的邻近关系
|
||
|
||
### ALiBi 兼容性
|
||
- 更直接：使用连续的线性偏置替代跳跃偏置
|
||
- 无需额外的重新计算
|
||
|
||
## 复杂度分析
|
||
|
||
| 操作 | 复杂度 |
|
||
|------|--------|
|
||
| 内存 | O(L + S) 固定大小，S=4 为 Sink Token 数 |
|
||
| 每 Token 解码时间 | O((L+S) · d)，恒定 |
|
||
| 累积时间（T Token） | O(T · (L+S) · d) |
|
||
|
||
其中 L 为滑动窗口大小，S 为保留的初始 Token 数，d 为模型维度。
|
||
|
||
## 与 Sliding Window Re-computation 的对比
|
||
|
||
Re-computation 对每个新 Token 重建 L 个 Token 的 KV（O(TL²) 累积），StreamingLLM 仅需 O(TL) → 最高 22.2× 加速。
|
||
|
||
## 相关概念
|
||
|
||
- [[streaming-llm|StreamingLLM]] — 框架主页
|
||
- [[attention-sinks|注意力汇]] — 滚动的锚定部分
|
||
- [[window-attention|窗口注意力]] — 不带 Sink 的滚动缓存
|
||
- [[kv-cache-bottleneck|KV 缓存瓶颈]] — 更广泛的 KV 优化
|