Efficient Streaming Language Models with Attention Sinks

StreamingLLM论文精读：为什么只保留开头几个Token，就能让模型持续生成数百万Token？

在普通大语言模型中，KV Cache会随着对话或文本长度不断增长。最直接的解决办法是只保留最近一段Token，也就是滑动窗口。

但论文发现了一个令人意外的现象：

一旦把最开头的几个Token从KV Cache中删除，模型困惑度会突然爆炸；只要把这些开头Token重新放回缓存，即使其余大量历史内容已经删除，模型又能恢复正常生成。

作者将这些持续吸收大量注意力、但语义上未必重要的初始Token称为：

Attention Sinks，注意力汇聚Token。

基于这一现象，论文提出StreamingLLM：

固定保留少量初始Attention Sink，再配合一个滚动的最近Token窗口，使模型能够在固定显存和固定单步计算量下持续生成。

一、论文基本信息

论文正式发表于ICLR 2024，并提供了公开实现。(ICLR 会议论文集)

二、StreamingLLM要解决什么问题

论文关注的是持续运行的语言模型，例如：

• 长时间运行的聊天助手；

• 不断接收日志的分析系统；

• 持续输入字幕或语音转录；

• 长时间代码补全；

• 连续新闻或社交媒体流；

• 永不重置的多轮交互服务。

这些应用并不一定要求模型记住从开始到现在的全部内容，但要求模型：

1. 能持续接收新Token；

2. 不因输入总长度增加而耗尽显存；

3. 不需要周期性清空KV Cache；

4. 始终能够基于最近上下文稳定生成。

论文指出，传统大语言模型在这种场景中面临两个问题：

• KV Cache随输入长度线性增长；

• 输入长度超过预训练窗口后，模型本身也可能出现位置外推失败。(arXiv)

三、三种基础推理方式为什么都不理想

3.1 完整注意力

完整注意力保存此前所有Token的Key和Value。

它的优点是历史内容都可以被访问，但代价是：

• KV Cache持续增长；

• 单步注意力需要访问越来越多历史Token；

• 长时间运行最终会显存不足；

• 输入超过训练窗口后，位置编码也可能失效。

因此，完整注意力不能支持真正持续运行的流式服务。

3.2 普通滑动窗口

普通窗口注意力只保存最近固定数量的Token。

例如缓存大小为1024时：

• 始终保留最近1024个Token；

• 每加入一个新Token，就删除最早的一个；

• KV显存保持固定；

• 单步注意力计算量保持固定。

从系统角度看，这似乎是最理想的方案。

但论文发现，当序列长度刚刚超过窗口大小、最初Token第一次被删除时，模型困惑度就会突然爆炸。也就是说，问题并不是逐渐遗忘旧内容，而是整个注意力分布突然失去稳定性。(arXiv)

3.3 滑动窗口加重新计算

另一种方法是保留最近一段原始文本，但每生成一个新Token，都重新将窗口内全部文本输入模型，重新计算其KV。

这种方式通常能够保持较好的语言建模质量，因为窗口内Token每次都会获得连续、正确的位置。

但它存在严重的重复计算：

• 窗口越大，每一步重新计算的Token越多；

• 解码成本随窗口大小近似二次增加；

• 无法充分复用已有KV。

论文把它作为高质量参考基线，但认为其速度不适合实际流式应用。(arXiv)

四、什么是Attention Sink

作者分析LLaMA-2等模型的注意力图后发现：

• 最底部少数层通常更关注最近Token；

• 从较深层开始，大量注意力头持续关注序列开头的几个Token；

• 即使这些Token与当前预测没有明显语义关系，它们仍然获得很高注意力。

作者把这种现象称为：

Attention Sink：某些Token充当注意力分数的“汇聚池”，吸收模型暂时没有必要分配给其他内容的注意力。

论文观察到，通常保留最初4个Token就足以恢复稳定，而只保留1个或2个初始Token，在部分模型上仍然不够。(arXiv)

五、为什么初始Token会成为注意力汇聚点

5.1 论文给出的Softmax解释

注意力经过Softmax归一化后，所有历史Token的注意力权重必须加起来等于1。

有些情况下，当前Query可能只需要自身或少量局部信息，但注意力仍必须将全部概率质量分配出去。

作者认为，模型会把部分“不必要的注意力”分配给某些固定Token，这些Token便逐渐成为Attention Sink。(arXiv)

可以将其理解为：

模型并不一定需要从这些Token中读取重要语义，而是需要一个稳定的位置来容纳多余注意力权重。

5.2 为什么偏偏是开头Token

在自回归注意力中，最开始的Token对后面几乎所有Token都可见。

相比之下：

• 第一个Token能被整个序列后续位置访问；

• 中间Token只能被它后面的部分位置访问；

• 最后几个Token仅被极少数后续位置访问。

因此，在预训练过程中，开头Token最容易被大量Query反复利用，最终形成稳定的注意力汇聚位置。(arXiv)

5.3 语义真的不重要吗

作者进行了一个关键实验。

他们把原始文本最初4个Token替换成4个换行符，但仍将这些位置的KV保留在缓存中。

结果显示：

• 保留原始前4个Token时，LLaMA-2-13B困惑度为5.40；

• 替换成4个换行Token后，困惑度为5.60；

• 完全删除初始Token、只保留最近1024个Token时，困惑度达到5158.07。

这说明恢复性能的关键更接近于初始位置及其训练形成的注意力模式，而不是最初几个Token具体表达了什么内容。(arXiv)

不过，“语义不重要”不能理解为这些Token在所有场景下都没有内容价值。它只是说明，在这个语言建模实验中，Attention Sink的主要作用不是携带原始文本开头的语义。

六、StreamingLLM的核心设计

StreamingLLM将固定大小的KV Cache分成两部分：

第一部分：Attention Sink

永久保留最开始的少量Token，默认是4个。

这些Token用于稳定Softmax注意力分布。

第二部分：Rolling Cache

保存最近的一段连续Token。

这些Token提供：

• 最近语义；

• 局部语法；

• 当前对话状态；

• 最近实体；

• 当前推理步骤。

因此，其缓存结构可以概括为：

最初4个Token + 最近若干Token

例如缓存总预算为1024，可以使用：

4个初始Token + 1020个最近Token

中间那些既不属于最初位置、也不属于最近窗口的Token会被删除。(arXiv)

七、StreamingLLM完整执行流程

假设模型总缓存预算为8个Token，其中：

• 前2个位置作为Attention Sink；

• 后6个位置作为滚动窗口。

随着文本不断到来，缓存可能经历：

初始阶段：

[0, 1, 2, 3, 4, 5, 6, 7]

继续生成后：

[0, 1, 4, 5, 6, 7, 8, 9]

再继续生成：

[0, 1, 6, 7, 8, 9, 10, 11]

其中：

• Token 0和1始终保留；

• 最近6个Token不断向前滚动；

• 中间旧Token被淘汰。

因此，无论模型总共处理了1万、100万还是400万Token，缓存大小都不会继续增长。

八、为什么位置编号必须重新排列

只删除KV还不够，位置编码也必须同步处理。

假设当前缓存保留的原始Token编号是：

[0, 1, 2, 3, 6, 7, 8]

现在准备处理Token 9。

如果仍然按照原始文本位置计算，位置编号将是：

[0, 1, 2, 3, 6, 7, 8, 9]

其中存在一个从3跳到6的断层。

StreamingLLM不使用这种原始全局位置，而是按照它们在当前缓存中的相对位置重新编号：

[0, 1, 2, 3, 4, 5, 6, 7]

这样，最近窗口中的Token始终位于模型训练时熟悉的位置范围内，而不会不断进入数十万或数百万的位置编号。(arXiv)

8.1 RoPE如何处理

对于使用RoPE的模型，论文缓存旋转位置编码处理之前的Key。

每次滚动窗口更新后，再按照新的缓存位置对Key施加RoPE变换。

这样可以避免将已经带有旧全局位置的Key直接用于新的连续窗口。(arXiv)

8.2 ALiBi如何处理

对于使用ALiBi的MPT模型，不需要重新旋转Key。

算法只需要根据当前缓存中的连续相对位置重新计算线性距离偏置，而不是保留原始文本中跳跃的位置距离。(arXiv)

九、为什么只保留最近Token还不够，而加入4个Sink就有效

普通滑动窗口删除初始Token后，模型不仅失去了几个旧Token，还改变了整个注意力归一化环境。

模型原本已经习惯：

一部分注意力可以被分配给初始Sink位置。

删除这些位置后，原本流向Sink的权重必须重新分配给剩余Token，导致：

• 局部Token获得异常高的注意力；

• 注意力分布偏离训练状态；

• 隐藏表示逐层累积偏差；

• 模型最终输出失去稳定性。

StreamingLLM重新加入初始Token，相当于恢复了训练时熟悉的注意力“锚点”。

论文在400K Token文本上测试不同初始Token数量：

结果说明：

• 不同模型需要的Sink数量略有差异；

• 1个Token有时已经有效，但不够稳定；

• 4个初始Token通常足够；

• 继续增加到8个收益很小。(arXiv)

十、StreamingLLM真的扩展了上下文窗口吗

没有。

这是理解这篇论文最重要的一点。

StreamingLLM可以持续处理无限增长的输入流，但模型在任意时刻实际看到的只有：

• 最初几个Sink Token；

• 最近固定数量的Token。

中间已经被删除的内容无法再次访问。

官方代码说明也明确指出：

• StreamingLLM没有扩大模型原始上下文窗口；

• 模型只识别当前最近窗口；

• 输入一本完整书时，它可能只能依据结尾部分生成摘要；

• 它适合持续对话和流式生成，不适合要求记住全部历史细节的长文理解。(GitHub)

因此，应该区分两个概念。

所谓“无限长度”，指的是：

输入流可以无限持续，而不是可访问记忆范围无限扩大。

十一、为什么论文能测试到400万Token

论文在拼接后的PG-19长文本上，让多个模型持续进行语言建模。

实验覆盖：

• LLaMA-2 7B、13B、70B；

• Falcon 7B、40B；

• Pythia 2.8B、6.9B、12B；

• MPT 7B、30B。

在超过400万Token的连续文本中，StreamingLLM的困惑度保持相对稳定。(arXiv)

但这个结果说明的是：

模型不会因为累计处理长度超过训练窗口而突然数值崩溃。

它并不证明模型仍然记得数百万Token之前发生的内容。

事实上，论文的StreamEval附录显示，当问题所需答案超出当前缓存范围后，准确率会快速下降，并最终降到零。(arXiv)

十二、流式问答实验

作者把ARC-Easy和ARC-Challenge中的问题连续拼接成一个长数据流，模拟不断进行的多轮问答。

模型使用1024个KV缓存位置。

结果如下：

完整Dense Cache在连续数据流中因显存增长而OOM；普通窗口在初始Token被删除后接近随机输出；StreamingLLM则接近逐题独立推理的结果。(arXiv)

这一实验非常适合StreamingLLM，因为每个新问题的答案主要依赖最近的题目，而不是很久之前的问答。

十三、StreamEval进一步说明了什么

作者设计了StreamEval，模拟持续输入信息并周期性提问。

默认设置中：

• 每输入10行新信息提出一次问题；

• 答案位于之前约20行的位置；

• 问题依赖相对较近的历史内容。

StreamingLLM在输入总长度接近120K Token时仍保持较合理的准确率，而Dense和普通窗口分别受训练长度和缓存淘汰影响。(arXiv)

但附录的距离实验揭示了它的边界：

当答案与问题之间的距离超过当前Rolling Cache容量后，准确率会逐渐下降，最终变为零。

例如在缓存为4+2044时，答案距离达到约2300 Token后准确率已经降为0；增加缓存可以推迟崩溃位置，但不能消除这一限制。(arXiv)

十四、LongBench结果揭示的局限

论文还在LongBench上测试长文问答和摘要。

使用4个Sink加3496个最近Token时，StreamingLLM通常低于“保留开头1750个和结尾1750个Token”的普通截断基线。

例如：

原因是长文问答中的重要指令、背景或事实可能位于文档开头，而4个Attention Sink只负责稳定注意力，并不能保存开头的实际语义内容。

当StreamingLLM也保留开头1750个Token时，表现才恢复到与截断基线接近。(arXiv)

这进一步证明：

Attention Sink提供的是数值稳定性，而不是长期语义记忆。

十五、专用Sink Token

15.1 为什么现有模型需要多个初始Token

现有大模型在预训练时，通常没有一个在所有训练样本中都稳定出现在第一个位置的特殊Token。

因此，模型可能将注意力汇聚功能分散到开头若干Token上，而不是集中到一个位置。

这也是为什么现有LLaMA、MPT和Pythia模型通常需要保留4个左右的初始Token。(arXiv)

15.2 作者提出专门训练一个Sink Token

作者提出在每个预训练样本最前面增加一个可学习的占位Token。

这个Token不需要表达实际语义，它的作用是：

专门吸收模型没有必要分配给其他内容的注意力权重。

这样，部署时只需要永久保留这一个Sink Token，而不必保留多个普通文本Token。(arXiv)

15.3 预训练实验

作者从头训练了160M参数模型，对比：

• 普通Softmax模型；

• 使用Zero Sink的模型；

• 加入可学习Sink Token的模型。

普通模型需要保留多个初始Token才能稳定，而经过专用Sink Token预训练的模型只保留一个Sink即可恢复正常困惑度。

同时，加入Sink Token并没有损害普通零样本任务性能。七项任务中，Sink模型的结果与普通模型相近，部分指标还略高。(arXiv)

不过，这项结论只在160M小模型上通过从头训练验证，并没有在7B或70B模型上重新预训练验证。

十六、实际效率结果

StreamingLLM与滑动窗口重新计算方法具有相似的固定KV显存，但运行过程不同：

• 重新计算方法每一步都重新处理整个窗口；

• StreamingLLM直接复用已有KV，只计算新Token。

论文在单张NVIDIA A6000上测试LLaMA-2-7B和13B。

随着缓存窗口变大：

• 重新计算方法的每Token延迟近似二次增长；

• StreamingLLM的延迟增长更加缓慢；

• 最大报告加速达到22.2倍；

• 两种方法的KV内存占用处于相近水平。(arXiv)

16.1 怎样理解22.2倍加速

22.2倍是相对于：

每生成一个Token，都重新计算最近整个窗口KV的滑动窗口基线。

它不是相对于高效的普通KV Cache解码。

普通KV Cache只计算新Token，速度本来就很快，但缓存会无限增长；StreamingLLM的价值在于同时获得：

• 类似普通KV复用的单步效率；

• 与固定窗口类似的恒定内存；

• 比纯滑动窗口稳定得多的生成质量。

因此，22.2倍不能理解为：

StreamingLLM让标准大语言模型推理普遍加速22倍。

更准确地说：

在必须保持固定缓存且不能接受普通窗口崩溃时，StreamingLLM比窗口重新计算方案最高快22.2倍。

十七、缓存越大，效果一定越好吗

不一定。

论文测试不同StreamingLLM缓存大小后发现，增加最近Token数量并不总能降低困惑度。

例如MPT-7B：

LLaMA-2-7B则从较小窗口逐渐改善，到4+2044附近最好，但继续扩大到4+4092后又略有恶化。(arXiv)

这说明：

• 模型未必能够充分利用全部上下文；

• 更长缓存不一定带来更好预测；

• 位置外推和训练分布仍会影响结果；

• StreamingLLM主要解决稳定性，不解决长上下文利用效率。

十八、与H₂O的区别

上一篇H₂O和StreamingLLM都压缩KV Cache，但保留历史Token的规则完全不同。

StreamingLLM认为：

不需要寻找语义上重要的旧Token，只要保留注意力汇聚点，再保留最近窗口即可稳定生成。

H₂O则认为：

除最近Token外，还应动态保留历史上累计注意力较高的重要Token。

H₂O的历史集合随内容变化，而StreamingLLM的Sink位置固定。(GitHub)

18.1 两者谁更适合什么场景

StreamingLLM更适合

• 持续聊天；

• 实时日志或字幕流；

• 只依赖最近上下文；

• 希望实现尽可能简单；

• 不愿引入动态排序和注意力统计。

H₂O更适合

• 历史中存在可能长期有用的信息；

• 希望保留远距离关键词或实体；

• 能够接受动态缓存管理；

• 希望根据输入内容选择历史Token。

两种方法也可以组合：保留固定Attention Sink、最近窗口，再从中间历史中选择少量Heavy Hitters。

十九、它和真正的长上下文扩展有什么区别

真正的上下文扩展方法通常希望模型：

• 接收超过原训练窗口的长输入；

• 访问窗口内所有Token；

• 利用跨越数万Token的远距离信息；

• 完成长文问答、摘要和检索。

StreamingLLM并不完成这些目标。

它只是让模型在处理无限输入流时，始终使用有限的局部上下文。

官方实现将两类技术描述为正交关系：

• 长上下文扩展扩大模型一次能访问的窗口；

• StreamingLLM让这个有限窗口能够在无限输入流上持续滚动。

因此，StreamingLLM可以应用于32K模型，此时它能够保存更大的最近窗口；但仍然不能记住已被滚动窗口淘汰的全部历史。(GitHub)

二十、这篇论文真正证明了什么

论文并没有证明：

语言模型只需要最初4个Token和最近Token，就能理解任意长度文本。

它真正证明了两个现象。

第一，普通滑动窗口失败的原因不只是丢失语义

即使被删除的最初Token没有重要语义，移除它们仍会破坏模型注意力分布。

保留少量初始位置可以恢复稳定。

第二，持续生成长度和有效记忆长度可以分离

模型可以在固定大小缓存下持续生成数百万Token，但它实际利用的仍然只是有限最近上下文。

也就是说：

• 运行时长度可以无限；

• 有效上下文长度仍然有限。

这一区分是理解StreamingLLM最重要的结论。

二十一、方法优点

21.1 无需微调

对已经训练好的LLaMA-2、MPT、Falcon和Pythia模型，只需要改变KV Cache管理方式，不需要重新训练。(arXiv)

21.2 缓存大小固定

无论总输入长度增长到多少，KV Cache只包含Sink和最近窗口，显存不会无限增长。

21.3 实现简单

它不需要：

• 计算Token重要性；

• 累积注意力；

• 动态排序；

• 训练压缩器；

• 保存额外摘要。

只需要永久保留少量初始KV，并滚动最近窗口。

21.4 支持多种位置编码

论文在RoPE和ALiBi模型上都进行了验证，并设计了对应的位置重排方法。(arXiv)

21.5 提供真实流式任务实验

论文不仅测量PG-19困惑度，也测试连续ARC问答、StreamEval以及实际解码延迟。

二十二、方法局限

22.1 不是真正的无限记忆

中间历史Token被删除后无法访问。模型只能记住Sink和最近窗口。

因此，它不能代替：

• 长上下文模型；

• 外部记忆；

• RAG；

• 历史摘要；

• 检索式对话记忆。

22.2 初始Sink不保存长期内容

Attention Sink主要维持注意力分布稳定，并不自动保存开头的任务要求或事实。

若系统提示或重要说明位于开头，仅保留4个Sink位置可能会删除其大部分实际语义。

LongBench结果已经显示，保留4个Sink不如保留完整开头文本。(arXiv)

22.3 对依赖远距离信息的任务无效

一旦答案或证据超出最近窗口，StreamEval准确率会逐渐下降并最终变为零。(arXiv)

因此，它更适合局部依赖的流式任务，而不是跨越整个输入历史的推理。

22.4 22.2倍基线需要谨慎理解

其对比对象是昂贵的窗口重新计算，而不是标准全KV解码。

与其他现代推理框架相比，实际加速幅度可能不同。

22.5 Sink数量具有模型依赖性

论文默认保留4个初始Token，但：

• Falcon可能1个已经足够；

• LLaMA-2保留1个时仍明显较差；

• 新模型可能具有不同注意力结构；

• 专门训练Sink Token后只需要1个。

因此，4并不是普遍最优常数。(arXiv)

22.6 专用Sink Token只在小模型上验证

作者从头训练的模型规模为160M。论文没有证明，在数十亿参数模型中加入专用Sink Token后，也一定能获得相同效果和训练稳定性。(arXiv)

22.7 Attention Sink的理论解释仍偏经验性

论文将其主要归因于Softmax归一化和初始Token的全局可见性。

这些解释与实验现象一致，但并不是对Attention Sink产生机制的完整严格证明。

二十三、这篇论文最重要的价值

StreamingLLM最重要的贡献并不是简单提出“保留第一个Token”。

它揭示了一个此前容易被忽视的问题：

KV Cache淘汰不仅会删除历史信息，还可能破坏模型在预训练阶段形成的注意力数值结构。

这意味着，设计KV Cache压缩方法时不能只考虑：

• 哪些Token语义重要；

• 哪些Token距离最近；

• 哪些Token注意力最高。

还要考虑：

删除某些位置后，模型的Softmax注意力分布是否仍然处于熟悉的状态。

StreamingLLM进一步区分了两种能力：

• 无限运行：模型可以永远继续接收和生成Token；

• 无限记忆：模型可以访问从开始到现在的全部历史。

StreamingLLM解决了前者，但没有解决后者。

二十四、一句话总结

StreamingLLM发现，自回归大语言模型会将最初几个Token作为Attention Sink，用来吸收大量与语义无关但Softmax必须分配的注意力；普通滑动窗口一旦删除这些初始KV，注意力分布便会发生剧烈偏移并导致困惑度崩溃。因此，StreamingLLM固定保留约4个初始Token，并配合滚动的最近Token窗口和重新排列的位置编码，使LLaMA-2、MPT、Falcon和Pythia能够以恒定KV Cache持续处理超过400万Token，并相对窗口重新计算最高加速22.2倍；但它没有扩大模型真正可访问的上下文，已被窗口删除的中间历史无法恢复，因此“无限流式生成”不等于“无限长上下文理解”。

下一篇仍可保持这一模板，并继续重点区分论文宣称的理论能力与真实部署边界。