StreamingLLM 完全拆解：attention sink 与大模型的无限流式生成

引子：一场不能重来的长对话#

把大模型部署成聊天助手、实时翻译、代码补全这样的服务时，会话往往没有终点：用户会一直聊下去，系统提示、工具定义和对话历史持续累积。这种场景有一个共同点——模型必须基于一段不断变长的历史继续生成。这类应用在论文里被称为流式应用（Streaming Application），它同时撞上两个问题：

第一个问题是显存与算力随对话线性膨胀。 解码阶段每生成一个 token，模型都要把该 token 在各层的 Key 和 Value 向量写进 KV Cache，供后续所有 token 的注意力读取。以 32 层、32 个注意力头的 Llama-2-7B 为例，每个 token 的 KV 占用为：

其中 $L_{layer}$ 是层数，$H_{kv}$ 是 KV 头数（Llama-2-7B 是 MHA，KV 头数等于注意力头数），$d_{head}=128$ 是头维度，$b$ 是每元素字节数（FP16 为 2）。一次 10 万 token 的长对话就要约 50 GB 显存只放 KV——单张 A100/H100 的 80 GB 显存在装下权重后根本撑不住。注意力计算量也随历史长度线性上涨：生成第 $T$ 个 token 时要对 $T$ 个历史 token 逐一遍历，越往后每说一个字越贵。

第二个问题是模型根本不会用超出训练长度的文本。 绝大多数模型在预训练时只在固定窗口（例如 Llama-2 的 4096 token）内见过注意力，把它们放到更长的输入上，困惑度会迅速劣化。换句话说，即使显存无限，“把整段历史一直喂给全注意力”这条路也走不通。

两个问题合起来，指向一个朴素直觉：既然模型用不上太老的内容，干脆只保留最近的一段历史不就行了？ 这就是滑窗注意力（Window Attention）——只缓存最近 $L$ 个 token 的 KV，更老的一律丢弃。它来自 Longformer 等早期工作，内存和每 token 计算量都被限制在常数 $L$ 内，看起来是流式推理的天然答案。但 2023 年的研究者们发现了一个反直觉的事实：一旦序列长度超过窗口、第一个 token 的 KV 被驱逐，模型就彻底崩了——Llama-2-13B 的语言建模困惑度从正常的 5.4 直接暴涨到 5158.07，几乎是在随机输出。

这背后是一整个此前无人解释的结构性现象。2023 年 9 月 29 日，MIT（Guangxuan Xiao、Song Han）与 Meta AI（Yuandong Tian、Mike Lewis）等研究者（Beidi Chen 亦参与）将论文 《Efficient Streaming Language Models with Attention Sinks》 提交到 arXiv，并于次年发表于 ICLR 2024。论文给出了一个被后续工作反复引用的核心概念——注意力汇聚点（Attention Sink），以及一个不训练任何参数就能让模型在无限长序列上稳定工作的方案：StreamingLLM。它只做一件事：在滑窗之外，永远保留最开头几个 token 的 KV。

这篇文章把这套机制完整拆开：先看滑窗注意力为什么崩、attention sink 从何而来（这部分是理解一切的关键），再拆 StreamingLLM 的两段式 KV 缓存与位置编码处理，然后是”预训练时种一个专职 sink token”的实验，最后用论文数据讨论它的效果、边界与后续影响。

一张总览图：这个问题的解空间长什么样#

论文 Figure 1 把流式场景下的候选方案全部画在一起。图中场景是：模型在长度 $L$（如 4096）的窗口内预训练，现在要预测第 $T$ 个 token（$T \gg L$）：

• 图 (a) 稠密注意力（Dense Attention）：缓存全部历史 KV。每生成一个 token 的注意力成本是 $O(T)$，总成本 $O(T^2)$，缓存随 $T$ 线性增长；且一旦文本长度超过预训练窗口，性能开始下降。两条失败原因它全占了。
• 图 (b) 滑窗注意力（Window Attention）：只缓存最近 $L$ 个 token 的 KV，内存与单步成本恒定，高效。但论文用实验证明：一旦文本长度超过缓存大小、开头 token 的 KV 被驱逐，性能断崖式下跌（后文细讲）。
• 图 (c) 滑窗 + 重计算（Sliding Window with Re-computation）：不缓存 KV，每生成一个新 token 都把最近 $L$ 个 token 重新前向一遍、现场重算它们的 KV。质量没问题（等价于每次只看一个新鲜滑窗），但单步成本是 $O(L^2)$（窗内二次注意力），整体 $O(T \cdot L^2)$，慢到无法用于实际流式场景。
• 图 (d) StreamingLLM：保留开头几个 token 作为 attention sink 稳定注意力计算，再叠加最近的 token。单步成本 $O(L)$、内存恒定，同时困惑度不劣化。

注意一个微妙的对比：图 (b) 与图 (d) 的差别只在于开头那几个 token 的 KV。图 (b) 驱逐它们，图 (d) 保留它们，于是前者崩溃、后者稳定——这就是整篇论文的杠杆点。理解”为什么区区几个 token 的 KV 有这么大威力”，需要先理解滑窗注意力到底是怎么崩的。

观察一：滑窗注意力崩在哪一刻#

论文首先做了一个”定位实验”（Figure 3）：在 2 万 token 的文本上做语言建模，逐个位置测量困惑度。测试了 Llama-2、MPT、Falcon、Pythia 等多个模型家族，得到三条一致的规律：

1. 稠密注意力在输入长度超过预训练窗口时失效。Llama-2 训练窗口是 4096，困惑度曲线在约 4K token 处开始陡升。这是位置编码外推失败的典型表现——模型没有在那么远的相对距离上训练过。
2. 滑窗注意力在输入长度超过缓存大小时崩塌。论文在实验里把缓存大小设成训练窗口的一半（Llama-2 用 2048、其余用 1024，便于把失效点看得更清楚），于是窗口注意力在 2048/1024 之前与稠密注意力表现一致，一到窗口边界——即最老的 token 即将被驱逐的瞬间——困惑度直接冲上天。
3. StreamingLLM 全程稳定，困惑度与”滑窗 + 重计算”这个质量上界几乎重合。

第二个发现值得细品：滑窗注意力的崩溃点精确出现在缓存容量耗尽、第一个 token 的 KV 被驱逐的那一刻，而不是”序列太长导致计算退化”。也就是说，崩塌不是渐进的性能衰减，而是一次”删掉一个 token”引发的瞬间雪崩。

论文用 Llama-2-13B 在 PG19 测试集第一本书（6.5 万 token）上量化了这个雪崩（论文 Table 1）：

表格中 “x + y” 记法是全篇的核心记号：保留开头 $x$ 个 token 的 KV，加上最近 $y$ 个 token 的 KV。0+1024 就是纯滑窗；把开头 4 个 token 加回来（4+1020），困惑度从 5158.07 回到 5.40——恢复了整整三个数量级，达到正常水平。注意最后一行：把原来的开头 4 个 token 替换成 4 个毫无语义的换行符 “\n”，效果几乎一样（5.60）。这组对照实验透露了关键信息：模型在意的不是开头 token 写了什么，而是它们出现在开头这个位置。

观察二：模型把注意力”倾泻”给了开头#

为什么删掉一个没有语义价值的 token 会引发崩溃？论文可视化了 Llama-2-7B 的注意力分布（Figure 2：在 256 个长度为 16 的句子上平均的注意力 logits）：

图里能看到两条清晰规律：

• 最底下的两层（layer 0、1）呈现”局部注意力”模式：最近的一两个 token 获得最多关注，符合”底层在抄近邻词”的直觉。
• 从第 3 层往上，几乎所有层、几乎所有注意力头都把最大注意力给了第一个 token：在热力图上，位置 0（第一个 token）那一列在绝大多数子图里明显亮于其他列。

这还不是短序列的偶然现象。论文附录 F 做了定量测量：在 4096 token 的长序列上，统计第 4096 个 token 对第一个 token 的注意力分数——多数层里这个分数超过总注意力的一半（论文 Figure 12），且头与头之间的方差很小。也就是说”看开头”不是个别头的怪癖，而是模型的系统性行为。

论文把这类承受了巨额注意力、但自身不携带多少语义价值的 token 命名为 attention sink（后文简称 sink）。sink 的特征是：无论它是什么内容、离当前位置多远，模型都会稳定地把大量注意力质量堆在它上面。

StreamingLLM：4 个 sink + 滚动 KV 缓存#

基于上述观察，StreamingLLM 的方案简单到令人惊讶：在滑窗的基础上，把最开头的几个 token（默认 4 个）的 KV 永远留在缓存里。不需要任何训练或微调，直接套用到任何使用相对位置编码（RoPE 或 ALiBi）的自回归模型上。

论文 Figure 4 画出了它的 KV 缓存结构：

缓存概念上分两段：

1. Attention Sinks：最开头 $x$ 个 token（论文默认 $x=4$）的 KV，永远驻留、永不驱逐。它们的作用不是提供信息，而是稳定注意力计算——让 softmax 的分母始终包含模型习惯的那块”压舱石”。
2. Rolling KV Cache：最近 $y$ 个 token 的 KV，随生成滚动更新：每生成一个新 token，把它追加进队尾，同时把最老的 token 逐出队头。

用 “x + y” 记法描述就是 4 + L（论文实验中 Llama-2 用 4+2044 左右、Falcon/MPT/Pythia 用 4+1020 左右——缓存总大小取训练窗口的一半，纯粹为了在图上把三种方案的失效点分开）。于是整个系统在任何时刻的 KV 总量恒定为 $x + y$，与已经生成了多少 token 完全无关：每生成一个新 token，注意力成本恒为 $O(y)$、内存恒为 $O(x+y)$，这就是”无限流式”的含义——生成第 1 万个 token 与第 4 百万个 token 的开销完全相同。

1
class StreamingLLMCache:
2
    def __init__(self, num_sinks: int = 4, window_size: int = 2048):
3
        self.num_sinks = num_sinks        # 永远驻留的 sink 数量
4
        self.window_size = window_size    # rolling 区容量
5
        self.rolling: deque = deque()     # rolling 区，队头最老、队尾最新
6

7
    def append(self, token_kv):
8
        """新 token 的 KV（RoPE 模型存旋转前的原始 K）入队"""
9
        if len(self.rolling) == self.window_size:
10
            self.rolling.popleft()        # 驱逐最老的 rolling token
11
        self.rolling.append(token_kv)     # 新 token 追加到队尾
12

13
    def position_ids(self):
14
        """每次解码时使用的统一位置编号（论文的核心细节）"""
15
        return list(range(self.num_sinks)) + \
16
               list(range(self.num_sinks, self.num_sinks + len(self.rolling)))

为什么是 4 个 sink，而不是 1 个#

一个自然的问题：既然 sink 是”位置角色”，为什么默认保留 4 个开头 token 而不是 1 个？论文做了系统的消融（Table 2），在 40 万 token 的 PG19 拼接测试集上改变 sink 数量：

三条清晰的规律：

1. 0 个 sink（纯滑窗）全军覆没，困惑度在 17.9 到 3359.95 之间，模型基本在随机说话。
2. Falcon、MPT、Pythia 放 1 个 sink 就基本恢复；Llama-2-7B 不行——1 个 sink 只有 11.88，要到 4 个才收敛到 9.59。
3. 超过 4 个后收益递减（Llama-2 8 个 sink 只从 9.59 降到 9.54），所以默认取 4。

模型之间的差异从何而来？论文给出的解释是预训练数据的开头格式不同：Llama-2 虽然给每个段落加 <s> 起始符，但这个符号加在文本切块（chunking）之前——切块后落在位置 0 的往往是随机 token，不同训练样本的”开头”并不一致。模型学不到”把第一个 token 当专用 sink”，只好把 sink 职责分摊到开头好几个 token 上；而 Falcon 等模型的开头格式更一致，模型就可以把职责集中到一个 token。这解释了为什么 Llama-2 需要更多 sink——sink 的个数取决于预训练时开头 token 的统计一致性。

这个解释同时给出一个可验证的预测：如果预训练时人为保证每个样本开头都有同一个固定 token，模型就应该只需要 1 个 sink。论文在下一节验证了它。

进阶：预训练时”种”一个专职 sink token#

推理期保留 4 个真 token 虽然不花钱，但毕竟挤占了缓存容量（在 4+2044 配置里占 4/2048 ≈ 0.2%，放大窗口时几乎可忽略，但对 4+252 这种小窗口就是 1.6%）。更重要的是，如果模型天生就有一个”专职” sink，流式部署的稳定性会更好。论文提出一个预训练侧的处方：在每个训练样本的开头加一个可学习的专用占位 token（sink token），让模型把垃圾都倒给它。

论文顺带分析了另一条”治本”路线——来自 Softmax-off-by-One 的思想：既然问题出在”softmax 要求权重和为 1”，那把分母多留 1 个单位，让多余质量有个不占 token 的出口：

这个变体等价于在注意力计算里前置一个 Key 和 Value 全为零的 token，论文把它叫做 Zero Sink，与可学习的 sink token 一起做了对照实验。

实验设置：用 Pythia-160M 的训练配方从零训练三个 1.6 亿参数模型——标准注意力（Vanilla）、Zero Sink、开头加可学习 sink token（Sink Token），在去重后的 Pile 数据集上各训 14.3 万步（8 张 A6000）。推理时在流式设置下测困惑度（Table 3，PG19 第一个样本，缓存 0+1024 到 4+1020）：

三个结论：

1. Vanilla 模型需要 4 个开头 token 才能稳住（18.05），与上一节的消融一致。
2. Zero Sink 没能兑现承诺：纯滑窗（0+1024）下困惑度 29214，比 Vanilla 的 27.87 还差得多——“分母加 1”只是多提供了一个质量出口，并没有阻止模型在训练中继续习得”把大量注意力堆到开头的真 token 上”的习惯，一旦驱逐照样雪崩。
3. Learnable Sink Token 完美生效：只保留 sink token 一个（1+1023）就达到 18.01，且加更多开头 token 不再有任何增益（18.01 → 18.01 → 18.02）。sink token 完全接管了”收集多余注意力”的职责，其他 token 不需要再兼职。

加 sink token 会不会伤模型？论文在两个维度做了检查：收敛曲线与 Vanilla 几乎重合；在 ARC、HellaSwag、LAMBADA、OpenbookQA、PIQA、Winogrande 等 7 个零样本基准上不仅不掉点，反而每一项都略高（例如 ARC-Challenge 从 18.6 到 19.6，HellaSwag 从 29.4 到 29.8）。注意力可视化（论文 Figure 7）显示，加了 sink token 的模型各层各头都显著地把注意力指向它，而给其他开头 token 的注意力明显减少——它真的在当垃圾桶。

附录 I 还追问了一个问题：两个 sink token 会不会更好？答案是不会：第二个 sink token 不带来任何增益（推理时模型会”平均地”依赖两个 sink，反而在只保留 1 个时需要 2 个才稳）。这与视觉 Transformer 里多个 “register” 有用的结论相反——对语言模型，一个专职 sink 就够了。

效果：四百万 token 不崩、流式问答不掉点#

4M token 语言建模#

论文把 PG19 测试集 100 本书拼接成超长流（跨书处有主题切换），对 Llama-2-[7,13,70]B、Falcon-[7,40]B、Pythia-[2.8,6.9,12]B、MPT-[7,30]B 共 9 个模型跑语言建模：

每条曲线的困惑度在 400 万 token 内保持平稳，只在书与书的交界处有可解释的小幅波动。作为对比，稠密注意力在 4K 处就失效了，而滑窗注意力在缓存边界处崩溃——两种失败模式都被绕开之后，剩下的只有”稳定”。

流式问答：模拟真实的多轮对话#

论文用两套评测检验真实场景。第一套直接把 ARC-Easy/Challenge 的全部问答对拼接成一条流，喂给 Llama-2-[7,13,70]B-Chat，在每道题的回答位置按精确匹配打分（Table 5，缓存 1024）：

模型 / 设置	ARC-Easy	ARC-Challenge
Llama-2-7B-Chat One-shot（逐个样本独立回答，上界参考）	71.25	53.16
Llama-2-7B-Chat Dense（全注意力）	OOM	OOM
Llama-2-7B-Chat Window（纯滑窗）	3.58	1.39
Llama-2-7B-Chat StreamingLLM	71.34	55.03

稠密注意力直接 OOM；纯滑窗掉到 3.58/1.39（几乎零分——不是”变笨”，是模型崩了在随机输出）；StreamingLLM 拿到 71.34/55.03，与逐个样本独立回答的上界相当，甚至略高（13B 和 70B 模型上同样如此，70B 的 ARC-Challenge 达到 80.20 vs one-shot 的 78.50）。

第二套是论文自建的 StreamEval 数据集，模拟”问题总是关于最近信息”的真实流式场景。它的结构（Figure 8）是：模型读 10 行新内容，被问一个问题，答案藏在 20 行之前——每个 query 的答案永远在窗口内，但要模型不被更早的无关内容干扰：

结果（Figure 9）：StreamingLLM 在输入长达 12 万 token 时仍保持合理精度；稠密注意力在预训练长度处失效，滑窗注意力在缓存边界处失效：

论文还用两个上下文扩展模型（LongChat-7B-v1.5-32K、Llama-2-7B-32K-Instruct）验证了与上下文扩展技术正交：StreamingLLM 语境下的”上下文扩展”就是把 rolling 缓存开大，让模型能利用更长的近期上下文。32K 长上下文模型经过长文本微调、位置编码插值后，仍然在超出窗口处失效——任何方案都绕不开”不要超过训练过的距离”，而 StreamingLLM 用”永远不超”回应了它。

边界：它不是长上下文，是”永远新鲜”的记忆#

把 StreamingLLM 讲透之后，必须强调它的边界——它不扩展模型的上下文窗口，也不增强模型对长文的利用。它只保证一件事：模型能无限稳定地”看着缓存里最近的内容”继续生成。老内容被驱逐后就真的消失了，模型既看不到、也”记不得”。

论文用 LongBench（长文本基准）上的实验把这个边界量化得很清楚（Table 8）。对 Llama-2-7B-Chat，LongBench 的默认做法是把超长输入截断成”开头 1750 + 结尾 1750”；论文对比了三种配置：

4+3496 远低于截断基线，因为 NarrativeQA 的答案藏在文档开头，被 rolling 缓存驱逐了；而把 sink 数量从 4 扩到 1750（相当于”开头全保留”），分数立刻追平截断基线（18.2 vs 18.7）。结论：StreamingLLM 的可用性完全取决于目标信息是否在缓存内——信息在缓存里，效果与截断基线相当；信息不在，模型就无从作答。

所以它的正确适用场景是：多轮对话、实时字幕与翻译、代码持续补全、语音助手、agent 的运行日志流这类”模型只需要最近一段上下文”的应用。论文在摘要里也明确不把上下文窗口扩展算作贡献。长文档问答应该用摘要、RAG 或专门的上下文管理，而不是指望无限流式方案。

影响：一次现象级发现的下游#

attention sink 的发现之所以重要，是因为它解释了一个此前被归咎于”玄学”的系统性现象，并给出可操作的应对。它的影响沿着几条线扩散：

工程线——StreamingLLM 发布后迅速进入主流推理栈：NVIDIA TensorRT-LLM 在 Llama 示例里提供了 StreamingLLM 支持，HuggingFace Transformers 通过 PR #26681 集成，Intel Extension for Transformers、HPC-AI Tech 的 SwiftInfer 相继跟进，CMU/UW/OctoAI 合作把它跑上了 iPhone。对 KV Cache 管理来说，它贡献了一条至今被默认遵守的规则：无论用什么驱逐或量化策略，开头几个 token 必须特殊对待。

学术线——“模型把注意力质量倾倒在特定 token 上”的视角启发了大量后续研究：长上下文 KV 压缩工作普遍把”开头 token + 最近 token”当作压缩后的保留集（如 SnapKV 等），前缀缓存（如 SGLang 的 RadixAttention）与”前缀 + 滑窗”类方案在机制上与它同源；BERT 的 [SEP]、ViT 的 register 等跨架构的对应物则证明这是 softmax 归一化约束的普遍后果。它还给量化社区的现象（离群值集中在固定位置）提供了一个注意力侧的镜像：结构性冗余是深度网络习得的稳定习惯，不是噪声。

一条仍然开放的路——sink 的存在本质上是 softmax “和为 1” 约束的代价。Softmax-off-by-One 式的改造可以在数学上去掉 sink 的成因，但会改变注意力语义、需要重新预训练；如何在不动模型的前提下让 sink 尽量少占用缓存（比如把 4 个真 token 压成更少的专用 token），至今仍是一个活跃方向。

小结#

StreamingLLM 这篇论文的核心贡献可以压缩成三句话：

1. 一个观察：自回归语言模型会把大量注意力质量倾泻到开头的几个 token 上——无论它们有没有语义价值。这是 softmax 归一化（质量必须守恒）与因果掩码（开头 token 对所有人可见）共同塑造的结构性结果，论文称之为 attention sink。
2. 一个方法：在滑窗注意力之外永远保留开头 4 个 token 的 KV（“4 + 窗口”），并把位置编号统一按缓存内顺序计算，就能在零微调、零参数增加的前提下，让 Llama-2/MPT/Falcon/Pythia 在 400 万 token 的文本上稳定建模，流式问答精度与单发回答相当，比唯一可行的重计算基线快最高 22.2 倍。
3. 一个处方：预训练时在每个样本开头放一个可学习的专职 sink token，模型就只需要这一个 token 来稳定流式推理，且不损失任何下游能力。

理解 attention sink，也就理解了一个贯穿推理系统的底层事实：KV Cache 里装的不仅是信息，还有模型的结构性习惯。后续读到 H2O 这类驱逐策略为何对开头 token 格外小心、各种稀疏注意力为何都保留滑窗与”常驻 token”、长上下文量化为何单独处理首部——都能在本文的机制里找到根源。

参考资料#

1. Efficient Streaming Language Models with Attention Sinks（论文，arXiv:2309.17453）
2. StreamingLLM 官方代码仓库（mit-han-lab/streaming-llm）
3. MIT Han Lab StreamingLLM 项目主页
4. NVIDIA TensorRT-LLM：Run LLaMa with StreamingLLM 官方示例（v0.8.0 版本文档）
5. HuggingFace Transformers 集成 StreamingLLM 的 PR #26681
6. Attention Is Off By One（Evan Miller，softmax-off-by-one 原博客）
7. RoFormer：RoPE 旋转位置编码原始论文
8. Train Short, Test Long：ALiBi 线性偏置注意力论文
9. Longformer：滑窗注意力的经典来源
10. PG19：长篇语言建模测试集
11. LongBench：长文本基准（论文用其量化 StreamingLLM 的边界）
12. SnapKV：受 attention sink 观察启发的 KV 压缩后续工作
13. Vision Transformers Need Registers：ViT 中与 attention sink 同源的寄存器现象