大模型基础架构的变革：剖析Transformer的挑战者（下）

上一篇文章中，我们介绍了UniRepLKNet、StripedHyena、PanGu-π等有可能会替代Transformer的模型架构，这一篇文章我们将要介绍另外三个有可能会替代Transformer的模型架构，它们分别是StreamingLLM、SeTformer、Lightning Attention-2，想了解之前的内容，请前往《大模型基础架构的变革：剖析Transformer的挑战者（中）》一文查阅。

---

 

七、StreamingLLM

StreamingLLM是一种结合了模型固有的「注意力池」token和文本中最近 token 的滚动缓存进行处理无限文本的新型架构。

在流媒体应用程序（如多轮对话）中部署大型语言模型（LLM），迫切需要长时间的交互，但是存在两个主要的挑战。第一个挑战是在解码阶段，缓存以前的token的键值状态（KV）会消耗大量的内存；第二个挑战是主流的LLM不能推广到比训练序列长度更长的文本。窗口注意力只缓存最近的kv，这是一种自然的方法——但是作者发现，当文本长度超过缓存大小时，它就会失败。

因此观察到一个有趣的现象，即注意力池集，即保持初始token的KV将在很大程度上能够恢复窗口注意的性能。在论文中，作者首先证明了注意力池聚的出现是由于初始token作为“汇聚的强注意分数”，即使它们在语义上并不重要。基于上述分析，作者引入了StreamingLLM，这是一个非常有效的方法，使应用了有限长度注意窗口训练的LLM可以推广到无限序列长度，而无需任何微调。

目前业内对将LLM应用于长文本进行了广泛的研究，主要关注三个领域：长度外推、上下文窗口扩展，以及提高LLM对长文本的利用。.

长度外推的目的是使在较短文本上训练的语言模型能够在测试过程中处理较长的文本。一个主要的研究途径是开发Transformer模型的相对位置编码方法，使它们能够在训练窗口之外发挥作用。

上下文窗口扩展集中于扩展LLM的上下文窗口，允许在一次向前传递中处理更多的token。一个主要的工作方向是解决训练效率的问题。考虑到Transformer在训练过程中存在对注意力计算随token增长的二次复杂度，开发一个长上下文的LLM，无论是计算还是存储都面临着巨大的挑战。

对不同LLM中有20K token的文本进行语言建模困惑。观察结果显示出一致的趋势：

(1)一旦输入长度超过训练前的注意窗口大小，密集的注意就会失败。

(2)一旦输入长度超过缓存大小，窗口注意就会崩溃，即初始token被丢弃。

(3)streamingLLM表现出稳定的性能，其困惑几乎与滑动窗口的重新计算基线匹配。

改进LLM对长文本的利用，以更好地捕获和使用上下文中的内容，而不是仅仅将它们作为输入。在长度外推和上下文窗口扩展两个方向上的成功并不一定会转化为对冗长的上下文的有效利用。在LLM中解决这种对长期上下文的有效使用仍然是一个挑战。论文的主要工作集中于稳定地利用最新的token使LLM的无缝流应用。

作者最终证明了StreamingLLM可以使Llama-2、MPT、Falcon和Pythia能够使用多达400万个token来执行稳定和有效的语言建模。此外，作者还发现在训练前添加一个占位符token作为专用的注意力池可以进一步改善流媒体部署。在流媒体设置中，StreamingLLM的性能比滑动窗口重新计算基线高出了22.2倍的加速。

StreamingLLM与现有方法的说明：语言模型对长度为L的文本进行预训练预测token（T≫L）。

(a)密集注意具有O（T 2）时间复杂度和不断增加的缓存大小。当文本长度超过训练前的文本长度时，其性能就会下降。

(b)窗口注意缓存最近的L的token的KV。虽然在推断方面很有效，但一旦启动token的键和值被丢弃，性能就会急剧下降。

(c)滑动窗口具有重新计算的重建能力，它为每个新token的L的最近token重建KV状态。虽然它在长文本上表现良好，但它的O（T L²）复杂性，源于上下文重新计算中的二次注意，使得它的速度相当慢。

(d)StreamingLLM保持注意力池（几个初始token），以实现稳定的注意力计算，并结合最近的token。它非常高效，并且在扩展文本上提供了稳定的性能。在PG-19测试集的第一本书（65Ktoken）上的Llama-2-13B模型测量复杂性。

当对无限输入流应用llm时，出现了两个主要的挑战：

1.在解码阶段，基于Transformer的LLM缓存所有以前token的密钥和值状态（KV），这可能导致过度的内存使用和增加解码延迟。

2.现有模型具有有限的长度外推能力，即当序列长度超过训练前设置的注意窗口大小时，其性能会下降。

为窗口注意力只在最近的token的KV