让LLM模型输入token无限长

背景

增加LLM的输入token已经有很多的研究，但是思路无外乎：模型抽取局部特征通过上层通过模型融合预测最终解，以及这个思路的一些变种。然而这些思路其实都没能很彻底的解决无限长token问题，根据《EFFICIENT STREAMING LANGUAGE MODELS WITH ATTENTION SINKS》这篇工作的研究原因在于：注意力陷阱。也就是说影响输入token长度的应该有两个原因：

1.如何让模型学会抽取局部特征

2.如何解决注意力陷阱

那么什么是“注意力陷阱”呢？为什么“注意力陷阱”会影响输入长度。所谓的“注意力陷阱”就是说即使初始标记在语义上并不重要，也会对初始标记产生强烈的关注分数作为“陷阱”。那么为什么“注意力陷阱”会影响输入token长度，原因在于token输入的注意力占比太大当初始化注意力因为缓冲区消耗被挤出计算会极大影响预测准确性。那么有没什么办法解决这个问题呢？作者给出的解决方案就是既然初始化注意力这么重要，那能不能我们就把这些值存在一个永久不可擦出地方也就是每次都带上，因为要每次带上那最好这些值表示不要太占空间，所以作者利用4bit空间来表示这些信息，并且做了各种消融实验发现4bit是最优，再少就会丢失精度。

论文翻译

部署大型语言模型（LLM）在多轮对话等流式应用中，其中预期会有较长的交互，迫切需要解决两个主要挑战。首先，在解码阶段，缓存先前标记的关键和值状态（KV）会消耗大量内存。其次，流行的LLM不能推广到比训练序列长度更长的文本。窗口注意力，其中只缓存最近的KVs，是一种自然的方法，但我们展示了当文本长度超过缓存大小时它会失败。我们观察到一个有趣的现象，即“关注陷阱”，即使初始标记在语义上并不重要，也会对初始标记产生强烈的关注分数作为“陷阱”。基于上述分析，我们引入了StreamingLLM，这是一个高效的框架，使经过有限长度注意窗口训练的LLM能够在不需要任何微调的情况下推广到无限序列长度。我们展示了StreamingLLM可以使Llama-2、MPT、Falcon和Pythia在多达400万个标记或更多的情况下执行稳定且高效的语言建模。此外，我们发现在预训练期间添加一个占位符标记作为专用的关注“陷阱”可以进一步提高流式部署的性能。在流式设置中，StreamingLLM的性能比滑动窗口重新计算基线提高了多达22.2倍的速度。代码和数据集可在链接中找到。

1 引言
大型语言模型（LLMs）（Radford等人，2018；Brown等人，2020；Zhang等人，2022；OpenAI，2023；Touvron等人，2023a;b）正变得无处不在，驱动着许多自然语言处理应用，如对话系统（Schulman等人，2022；Taori等人，2023；Chiang等人，2023）、文档摘要（Goyal＆Durrett，2020；Zhang等人，2023a）、代码补全（Chen等人，2021；Rozière等人，2023）和问答系统（Kamalloo等人，2023）。为了发挥预训练LLMs的全部潜力，它们应该能够高效准确地执行长序列生成。例如，一个理想的聊天机器人助手可以稳定地处理最近一整天的对话内容。然而，对于LLM来说，要推广到比它们在预训练中训练的更长的序列长度（例如Llama-2 Touvron等人（2023b）的4K）非常具有挑战性。
原因是在预训练期间，LLMs受到了注意力窗口的限制。尽管已经付出了大量努力来扩大这个窗口大小（Chen等人，2023；kaiokendev，2023；Peng等人，2023）并提高对长输入的训练（Dao等人，2022；Dao，2023）和推理（Pope等人，2022；Xiao等人，2023；Anagnostidis等人，2023；Zhang等人，2023b）效率，但可接受的序列长度仍然本质上是有限的，这不允许持续部署。
在本文中，我们首先介绍了LLM流式应用的概念，并提出了以下问题：
我们是否可以部署LLM以处理无限长度的输入，而不牺牲效率和性能？
当应用LLMs用于无限输入流时，会出现两个主要挑战：

1. 在解码阶段，基于Transformer的LLMs缓存所有先前标记的关键和值状态（KV），如图1（a）所示，这可能导致内存使用过多和解码延迟增加（Pope等人，2022）。
2. 现有模型的长度外推能力有限，即当序列长度超过预训练期间设置的注意力窗口大小时，性能会下降（Press等人，2022；Chen等人，2023）。
   一种直观的方法，被称为窗口注意力（Beltagy等人，2020）（图1 b），仅维护最近标记的KV状态的固定大小的滑动窗口。尽管它确保在缓存首次填充后内存使用和解码速度保持不变，但一旦序列长度超过缓存大小，即使仅仅驱逐第一个标记的KV，如图3所示，模型也会崩溃。另一种策略是滑动窗口重新计算（如图1 c所示），它为每个生成的标记重新构建最近标记的KV状态。虽然它提供了强大的性能，但由于在其窗口内进行二次注意力计算，因此这种方法速度明显较慢，对于实际的流式应用来说并不实用。

图1：StreamingLLM与现有方法的示意图。 预训练的语言模型在长度为L的文本上进行训练，预测第T个标记（T ≫ L）。 （a）密集注意力具有O(T2)的时间复杂度和逐渐增加的缓存大小。 当文本长度超过预训练文本长度时，其性能会下降。 （b）窗口注意力缓存最近的L个标记的KV。 在推理中效率高，但一旦开始标记的键和值被驱逐，性能就会急剧下降。 （c）滑动窗口与重新计算从L个最近的标记重新构建每个新标记的KV状态。 尽管在长文本上表现良好，但其O(TL2)复杂性，源自上下文重新计算中的二次注意力，使其速度明显较慢。 （d）StreamingLLM保留了关注陷阱（几个初始标记）以进行稳定的关注计算，并与最近的标记结合使用。 它高效且在扩展文本上提供稳定的性能。 使用Llama-2-13B模型在PG-19测试集中的第一本书（65K标记）上测量了困惑度。

一种直观的方法，被称为窗口注意力（Beltagy等人，2020）（图1 b），仅维护最近标记的KV状态的固定大小的滑动窗口。尽管它确保在缓存初始填充后内存使用和解码速度保持不变，但一旦序列长度超过缓存大小，即使只是驱逐第一个标记的KV，如图3所示，模型也会崩溃。另一种策略是滑动窗口重新计算（如图1 c所示），它为每个生成的标记重新构建最近标记的KV状态。尽管它提供了强大的性能，但由于在其窗口内进行二次注意力计算，因此这种方法速度明显较慢，使其在实际的流式应用中变得不切实际。

为了理解窗口注意力的失败，我们发现了自回归LLMs的一个有趣现象：大量的注意力分数被分配给初始标记，无论它们与语言建模任务的相关性如何，如图2所示。我们将这些标记称为“关注陷阱”。尽管它们缺乏语义重要性，但它们收集了显著的关注分数。我们将这个现象归因于Softmax操作，它要求关注分数对所有上下文标记进行求和以得到1。因此，即使当前查询在许多先前标记中没有强烈的匹配，模型仍然需要将这些不需要的关注值分配到某个地方，以便它们总和为1。初始标记作为关注陷阱标记的原因很直观：由于自回归语言建模的特性，几乎所有后续标记都能看到初始标记，使它们更容易被训练成关注陷阱。

图2：Llama-2-7B在256个长度为16的句子上的平均关注对数的可视化。观察结果包括：（1）在第一层和第二层（层0和层1）的关注图表现出“局部”模式，最近的标记受到更多的关注。 （2）在底部两层之外，模型在所有层和头部中都强烈关注初始标记。

基于以上的见解，我们提出了StreamingLLM，这是一个简单而高效的框架，可以使使用有限注意窗口训练的LLMs在不进行微调的情况下处理无限长度的文本。StreamingLLM利用了关注陷阱具有高关注值的事实，保留它们可以维持关注分数分布接近正常。因此，StreamingLLM只需保留关注陷阱标记的KV（仅需4个初始标记即可），与滑动窗口的KV一起来锚定关注计算，并稳定模型的性能。使用StreamingLLM，包括Llama-2-[7, 13, 70]B，MPT-[7, 30]B，Falcon-[7, 40]B和Pythia-[2.9,6.9,12]B在可靠地对400万标记进行建模，甚至可能更多。与唯一可行的基线方法，即滑动窗口重新计算相比，StreamingLLM实现了高达22.2倍的加速，实现了LLMs的流式使用。

最后，我们确认了关注陷阱假设，并演示了可以预训练语言模型以仅需要单个关注陷阱标记来进行流式部署。具体而言，我们建议在所有训练样本的开头添加一个额外的可学习标记，可以作为指定的关注陷阱。通过从头开始预训练具有1.6亿参数的语言模型，我们证明添加这个单一的关注陷阱标记可以在流式情况下保持模型的性能。这与普通模型形成对比，后者需要重新引入多个初始标记作为关注陷阱以达到相同的性能水平。

2 相关工作

已经开展了大量关于将LLMs应用于长文本的研究，主要集中在三个主要方面：长度外推、上下文窗口扩展以及改进LLMs对长文本的利用。尽管这些方向看似相关，但值得注意的是，一个方向的进展不一定会导致另一个方向的进展。例如，扩展LLMs的上下文大小并不会提高模型在上下文大小之外的性能，而且这两种方法都不能确保对长上下文的有效使用。我们的StreamingLLM框架主要属于第一类，其中LLMs应用于远远超过预训练窗口大小的文本，甚至可能是无限长度的文本。我们不扩展LLMs的注意窗口大小，也不增强模型在长文本上的内存和使用。最后两个类别与我们的重点无关，但可以与我们的技术集成。

长度外推旨在使在较短文本上训练的语言模型能够在测试期间处理更长的文本。研究的一个主要方向是为Transformer模型开发相对位置编码方法，使它们能够在其训练窗口之外工作。一个这样的倡议是Rotary Position Embeddings（RoPE）（Su等人，2021），它将每个注意力层中的查询和键进行了相对位置集成的转换。尽管有所希望，但随后的研究（Press等人，2022；Chen等人，2023）表明，RoPE在超出训练窗口的文本上表现不佳。另一种方法，ALiBi（Press等人，2022），根据它们之间的距离对查询-键关注分数进行了偏置，从而引入了相对位置信息。尽管这展示出了改进的外推性能，但我们对MPT模型的测试突出显示，当文本长度远远大于训练长度时，它会崩溃。然而，当前的方法尚未实现无限长度的外推，导致没有现有的LLMs适用于流式应用。

上下文窗口扩展旨在扩展LLMs的上下文窗口，使其能够在一次前向传递中处理更多的标记。主要的工作线路解决了训练效率问题。考虑到训练期间注意力计算的二次复杂性，开发具有长上下文的LLM既是计算上的挑战，又是内存挑战。解决方案范围从系统优化，如FlashAttention（Dao等人，2022；Dao，2023），该方法加速了注意力计算并减小了内存占用，到用于效率的近似注意方法（Zaheer等人，2020；Beltagy等人，2020；Wang等人，2020；Kitaev等人，2020），这些方法为效率而牺牲了模型质量。最近，有大量工作关于使用RoPE扩展预训练的LLMs（Chen等人，2023；kaiokendev，2023；bloc97，2023；Peng等人，2023），涉及位置插值和微调。然而，所有上述技术仅将LLMs的上下文窗口扩展到有限程度，这不符合我们论文的主要关注点，即处理无限输入。

改进LLMs对长文本的利用旨在优化LLMs以更好地捕捉和利用上下文中的内容，而不仅仅将它们视为输入。正如Liu等人和Li等人所强调的那样，前两个方向的成功不一定会转化为对长上下文的有效利用。在LLMs内有效使用长上下文仍然是一个挑战。我们的工作集中于稳定利用最近的标记，从而实现LLMs的流式应用。

图3：在包含20K标记的文本上的语言建模困惑度，涵盖了各种LLM。观察结果揭示了一致的趋势：（1）当输入长度超过预训练的注意窗口大小时，密集关注失效。 （2）当输入长度超过缓存大小时，即初始标记被驱逐时，窗口关注崩溃。 （3）StreamingLLM表现出稳定的性能，其困惑度几乎与具有重新计算的滑动窗口的基线相匹配。

3 STREAMINGLLM

3.1 窗口注意力的失败和关注陷阱

窗口注意力技术虽然在推理过程中提供了效率，但导致了极高的语言建模困惑度。因此，该模型的性能不适合在流式应用中部署。在本节中，我们使用关注陷阱的概念来解释窗口关注的失败，这也是StreamingLLM背后的灵感来源。

识别困惑度激增点。图3显示了在包含20K标记的文本上进行语言建模的困惑度。很明显，当文本长度超过缓存大小时，困惑度会激增，这是由于排除了初始标记。这表明，不管初始标记距离正在预测的标记有多远，它们都对维护LLMs的稳定性至关重要。

为什么删除初始标记的KV后LLMs会崩溃？我们在图2中可视化了Llama-2-7B和其他模型的所有层和头部的注意图。我们发现，在底部两层之外，模型在所有层和头部都一直关注初始标记。这意味着很明显：删除这些初始标记的KV将删除SoftMax函数（公式1中）中在关注计算中的分母的相当大的部分。这种改变会导致注意分数的分布显著偏离正常推理设置中所期望的分布。

有两种可能的解释来解释初始标记在语言建模中的重要性：（1）它们的语义非常重要，或者（2）模型学到了对它们的绝对位置的偏见。为了区分这两种可能性，我们进行了实验（表1），其中前四个标记被替换为换行符标记“\n”。观察结果表明，模型仍然明显强调这些初始换行符标记。此外，重新引入它们可以将语言建模的困惑度恢复到与具有原始初始标记相当的水平。这表明，与其语义值相比，起始标记的绝对位置更为重要。

LLMs将初始标记作为关注陷阱。为了解释为什么模型会不成比例地关注初始标记，而不考虑它们与语言建模的语义相关性，我们引入了“关注陷阱”的概念。SoftMax函数（公式1）的性质要求所有被关注的标记都不具有零值。这要求在所有层和所有头部中从其他标记中汇总一些信息，即使当前的嵌入已经包含足够的自包含信息来进行预测。因此，模型倾向于将不必要的关注值转储到特定的标记上。在量化异常值领域也有类似的观察（Xiao等人，2023；Bondarenko等人，2023），因此提出了SoftMax-Off-by-One（Miller，2023）作为潜在的解决方案。

为什么各种自回归LLMs，如Llama-2、MPT、Falcon和Pythia，都会一致关注初始标记作为它们的关注陷阱，而不是其他标记？我们的解释很简单：由于自回归语言建模的顺序性质，初始标记对所有后续标记都是可见的，而后来的标记只对有限数量的后续标记可见。因此，初始标记更容易被训练成关注陷阱，捕获不必要的注意力。

我们已经注意到，通常训练LLMs以利用多个初始标记作为关注陷阱，而不仅仅是一个。正如图2所示，引入四个初始标记作为关注陷阱足以恢复LLM的性能。相比之下，只添加一个或两个无法实现完全恢复。我们认为这种模式之所以出现是因为这些模型在预训练期间没有包含一致的起始标记，该标记适用于所有输入样本。虽然Llama-2在每个段落之前都使用“”标记，但它是在文本分块之前应用的，结果是大部分是随机标记占据了第零位置。缺乏统一的起始标记导致模型使用多个初始标记作为关注陷阱。我们假设通过在所有训练样本的开头引入一个稳定的可学习标记，它可以作为一个专注的关注陷阱，消除了需要多个初始标记以确保一致的流式处理的需要。我们将在第5.3节中验证这一假设。

窗口关注在长文本上性能较差。当我们在最近的1020个标记旁边重新引入初始的四个标记时，困惑度得以恢复（4+1020）。用原始的“\n”（4个“\n”+1020）替代也实现了类似的困惑度恢复。缓存配置x+y表示添加x个初始标记和y个最近的标记。困惑度是在PG19测试集中的第一本书（65K标记）上测得的。

3.2 带有注意力陷阱的滚动KV缓存

为了使已经训练过的LLMs能够进行流式处理，我们提出了一种简单的方法，可以在不需要对模型进行微调的情况下恢复窗口关注的困惑度。除了当前的滑动窗口标记，我们还在注意计算中重新引入了一些起始标记的KV。StreamingLLM中的KV缓存可以在概念上分为两部分，如图4所示：(1) 关注陷阱 (四个初始标记) 稳定了关注计算；(2) 滚动KV缓存保留了最近的标记，对语言建模至关重要。StreamingLLM的设计是多功能的，可以无缝地集成到任何使用相对位置编码的自回归语言模型中，例如RoPE (Su等人，2021) 和ALiBi (Press等人，2022)。

在确定相对距离并为标记添加位置信息时，StreamingLLM关注的是缓存中的位置，而不是原始文本中的位置。这种区别对于StreamingLLM的性能至关重要。例如，如果当前的缓存包含标记[0, 1, 2, 3, 6, 7, 8]，并且正在解码第9个标记，那么分配的位置将是[0, 1, 2, 3, 4, 5, 6, 7]，而不是原始文本中的位置，原始文本中的位置将是[0, 1, 2, 3, 6, 7, 8, 9]。

对于像RoPE这样的编码，我们在引入旋转变换之前缓存标记的Key。然后，在每个解码阶段将位置变换应用于滚动缓存中的键。另一方面，与ALiBi集成更直接。在这里，与其对注意力分数应用“跳跃”偏置，我们应用了连续的线性偏置。在缓存内分配位置嵌入的这种方法对于StreamingLLM的功能至关重要，确保模型在超出其预训练注意窗口大小的范围内仍能高效运行。

3.3 使用注意力陷阱进行预训练LLMs

正如第3.1节详细说明的，模型对多个初始标记的过度关注的一个重要原因是缺少指定的陷阱标记，用于卸载过多的注意力分数。因此，模型无意中将全局可见的标记，主要是初始标记，指定为关注陷阱。一个潜在的解决方法可以是有意包含一个全局可训练的关注陷阱标记，标记为“Sink Token”，它将用作不必要的注意力分数的存储库。或者，将传统的SoftMax函数替换为不需要所有上下文标记的注意力分数总和为1的变体，如SoftMax-off-by-One (Miller, 2023)，也可能是有效的。请注意，这种SoftMax替代方法等效于在注意力计算中使用具有全零Key和Value特征的标记。我们将这种方法标记为“Zero Sink”，以便与我们的框架保持一致。

为了验证，我们从头开始使用相同设置预训练了三个具有160百万参数的语言模型。第一个模型使用标准的SoftMax关注机制（Vanilla），第二个用SoftMax1（Zero Sink）替代了常规的关注机制，第三个在所有训练样本中添加了一个可学习的占位符标记（Sink Token）。如表3所示，虽然零陷阱在一定程度上缓解了关注陷阱问题，但模型仍然依赖其他初始标记作为关注陷阱。引入一个关注陷阱标记对稳定关注机制非常有效。简单地将此关注陷阱标记与最近的标记配对就足以锚定模型的性能，评估困惑度甚至略有改善。鉴于这些发现，我们建议未来的LLMs在所有样本中都使用关注陷阱标记进行训练，以优化流式部署。

表3：在预训练期间比较标准关注机制与在预训练期间添加零标记和可学习的关注陷阱标记。为了确保稳定的流式困惑度，标准模型需要多个初始标记。尽管Zero Sink表现出轻微的改善，但仍需要其他初始标记。相反，使用可学习的关注陷阱标记进行训练的模型只需添加关注陷阱标记即可展现稳定的流式困惑度。缓存配置x+y表示添加x个初始标记和y个最近的标记。困惑度是在PG19测试集中的第一个样本上评估的。

4 实验

我们使用四个最新的著名模型系列来评估StreamingLLM：Llama-2 (Touvron等人，2023b)、MPT (Team，2023)、PyThia (Biderman等人，2023)和Falcon (Almazrouei等人，2023)。值得注意的是，Llama-2、Falcon和Pythia都包含RoPE (Su等人，2021)，而MPT则使用ALiBi (Press等人，2022)——这是最近研究中最有影响力的两种位置编码技术。我们多样化的模型选择确保了我们的发现的有效性和稳健性。我们将StreamingLLM与已建立的基线进行了对比，例如密集关注、窗口关注和带有重新计算的滑动窗口方法。在所有后续的StreamingLLM实验中，除非另有说明，我们默认使用四个初始标记作为关注陷阱。

4.1 跨LLM系列和规模的长文本语言建模

我们首先使用合并的PG19 (Rae等人，2020)测试集来评估StreamingLLM的语言建模困惑度，该测试集包含100本长书籍。对于Llama-2模型，缓存大小设置为2048，而对于Falcon、Pythia和MPT模型，设置为1024。这是为了增强可视化清晰度而选择的预训练窗口大小的一半。

图3显示，StreamingLLM在跨足2万标记的文本的困惑度方面可以与预测基线（带有重新计算的滑动窗口）匹敌。与此同时，当输入长度超出其预训练窗口时，密集关注技术失败，窗口关注技术在输入长度超过缓存大小时遇到困难，导致初始标记被驱逐。在图5中，我们进一步证明了StreamingLLM可以可靠地处理异常长的文本，包括跨足400万标记的文本，覆盖了一系列的模型系列和规模，包括Llama-2-[7,13,70]B、Falcon-[7,40]B、Pythia-[2.8,6.9,12]B和MPT-[7,30]B。

图5：StreamingLLM对于跨足400万标记的超长文本的语言建模困惑度，涵盖了各种LLM系列和模型规模。困惑度始终保持稳定。我们使用PG19的合并测试集（100本书籍）进行语言建模，困惑度的波动是由于书籍之间的切换造成的。

4.2 带有汇聚标记预训练结果

为了验证我们的建议，即在所有预训练样本中引入一个汇聚标记会改善流式LLM，我们在相同条件下训练了两个具有1.6亿参数的语言模型。其中一个模型遵循了原始的训练设置，另一个在每个训练样本的开头都加入了一个汇聚标记。我们的实验使用了Pythia-160M (Biderman等人，2023)的代码库，并遵循了其训练配方。我们在一个8xA6000 NVIDIA GPU服务器上使用去重的Pile (Gao等人，2020)数据集进行模型训练。除了将训练批次大小减小到256之外，我们保留了所有Pythia的训练配置，包括学习率调度、模型初始化和数据集排列。这两个模型都进行了143,000步的训练。

图6: 带有和没有汇聚标记的模型的预训练损失曲线。这两个模型具有类似的收敛趋势。

表4：在7个自然语言处理基准测试中的零样本准确率（以%表示），包括ARC-[Challenge, Easy]、HellaSwag、LAMBADA、OpenbookQA、PIQA和Winogrande。在预训练过程中加入汇聚标记不会损害模型性能。

汇聚和正常模型性能。在预训练期间引入一个汇聚标记对模型的汇聚和后续在各种NLP基准测试中的性能没有负面影响。如图6所示，与普通模型相比，使用汇聚标记进行训练的模型展现出类似的汇聚动态。我们在七个不同的NLP基准测试中评估了这两个模型，包括ARC-[Challenge, Easy] (Clark等人，2018)、HellaSwag (Zellers等人，2019)、LAMBADA (Paperno等人，2016)、OpenbookQA (Mihaylov等人，2018)、PIQA (Bisk等人，2020)和Winogrande (Sakaguchi等人，2019)。如表4所示，使用汇聚标记进行预训练的模型的性能与使用传统方法进行训练的模型相似。

流式性能。如表3所示，使用传统方法训练的模型和使用汇聚标记增强的模型之间的流式困惑度存在差异。值得注意的是，普通模型需要添加多个标记作为注意力汇聚来保持稳定的流式困惑度。相反，使用汇聚标记训练的模型仅使用汇聚标记就可以获得令人满意的流式性能。

注意可视化。图7对比了使用和不使用汇聚标记进行预训练的模型的注意力图。没有汇聚标记的模型，类似于Llama-2-7B (图2)，显示出早期层的局部关注和深层对初始标记的关注。相反，使用汇聚标记进行训练的模型在各个层和头上始终集中在汇聚标记上，表明了一种有效的注意力卸载机制。对汇聚标记的强烈关注，以及对其他初始标记的减少关注，解释了汇聚标记在提高模型的流式性能方面的有效性。

图8：StreamEval中的第一个示例

图7：对比了使用（左）和不使用（右）汇聚标记进行预训练的模型，每个图显示了256个句子的平均注意力日志，每个句子长16个标记，都显示了相同的层和头。主要观察结果：（1）没有汇聚标记的模型在较低层显示局部注意，而在较深层对初始标记的关注增加。 （2）有汇聚标记的情况下，所有层都明显注意到它，有效地收集了多余的注意力。 （3）有了汇聚标记，其他初始标记的注意力减少，支持指定汇聚标记以增强流媒体性能的好处。

表5：在ARC-[Easy, Challenge]数据集上的准确性（以%表示）。问题被连接起来以流式方式回答，以模拟真实的聊天环境。由于内存不足（OOM）错误，密集基线失败。窗口注意力的准确性较差。 StreamingLLM与单样本逐一基线的结果相媲美。窗口注意力和StreamingLLM的缓存大小为1024。

4.3 使用经过指令调整的模型进行流式问答的结果

为了展示StreamingLLM的真实世界适用性，我们模拟了使用经过指令调整的LLM在真实世界场景中常用的多轮问答。

首先，我们将ARC-[Challenge, Easy]数据集中的所有问题-答案对连接起来，将连续流传递给Llama-2-[7,13,70]B-Chat模型，并使用精确匹配标准在每个答案位置评估模型完成情况。如表5所示，密集的关注结果导致内存不足（OOM）错误，表明它不适用于这种情况。虽然窗口关注方法效率很高，但当输入长度超过缓存大小时，由于随机输出，它的准确性较低。相反，StreamingLLM通过有效处理流式格式，在与一次性的逐一样本基线准确性相一致的情况下表现出色。

为了突出StreamingLLM更合适的情况，我们引入了一个数据集StreamEval，灵感来自LongEval（Li et al.，2023）基准。如图8所示，不同于LongEval的长跨度设置中的单个查询，我们在每10行新信息中查询模型。每个查询的答案一致在之前的20行，反映了问题通常涉及最近信息的实际情况。如图9所示，使用StreamingLLM的LLM即使在输入长度接近120K标记时仍保持合理的准确性。相比之下，密集和窗口关注都在预训练文本长度和KV缓存大小上失败。此外，我们还利用两个上下文扩展模型，LongChat-7b-v1.5-32k（Li et al.，2023）和Llama-2-7B-32K-Instruct（Together，2023），以展示StreamingLLM可以补充上下文扩展技术。在StreamingLLM中，上下文扩展意味着扩大流媒体LLM的最大缓存大小，从而使其能够捕获更广泛的本地信息。

图9：在StreamEval基准测试中的性能。准确度是基于100个样本的平均值。

图10：在X轴上根据缓存大小（注意力窗口大小）绘制的基于每个标记的解码延迟和内存使用量的比较，包括具有重新计算基线的滑动窗口方法和StreamingLLM。StreamingLLM实现了高达22.2倍的每个标记速度提升，并保持与重新计算基线类似的内存占用。

4.4 割离研究

初始标记的数量。在表2中，我们切割了添加不同数量的初始标记与最近标记对流式困惑的影响。结果显示，仅引入一个或两个初始标记是不足的，而四个初始标记的阈值似乎足够了，随后的添加只会产生边际效应。这个结果证明了我们在StreamingLLM中选择引入4个初始标记作为注意力汇聚的选择的合理性。

缓存大小。在表6中，我们评估了缓存大小对StreamingLLM困惑的影响。与直觉相反，增加缓存大小并不会一致地降低语言建模困惑。这种不一致性表明，这些模型可能无法充分利用它们接收到的整个上下文的效用。未来的研究工作应该致力于提高这些模型更好地利用广泛上下文的能力。

4.5 效率结果

我们将其解码延迟和内存使用情况与具有可接受性性能的滑动窗口与重新计算基线进行了基准测试。两种方法都使用Huggingface Transformers库（Wolf等，2020）实现，并在单个NVIDIA A6000 GPU上使用Llama-2-7B和Llama-2-13B模型进行测试。PG19测试集。如图10所示，随着缓存大小的增加，StreamingLLM的解码速度呈线性增长。具有重新计算基线的滑动窗口在解码延迟上呈二次增长。因此，StreamingLLM实现了令人印象深刻的速度提升，每个标记最多达到22.2倍。尽管其延迟较低，但StreamingLLM的内存占用与重新计算基线保持一致。

表格6：缓存大小对StreamingLLM性能的影响。增加StreamingLLM中的缓存大小并不一定会在所有模型上都降低困惑度，这表明这些模型可能没有充分利用所提供的上下文。缓存配置x+y表示将x个初始标记与y个最近的标记一起添加。困惑度是在连接的PG19测试集上评估的，共计400K个标记。

5.小结

将LLM部署到流媒体应用程序中是迫切需要的，但由于效率限制和对较长文本性能降低的挑战，这也存在一些问题。窗口注意力提供了部分解决方案，但当排除初始标记时，其性能会急剧下降。我们认识到这些标记作为“注意力汇集点”的作用，引入了StreamingLLM——一个简单而高效的框架，使LLM能够处理无限长度的文本而无需进行微调。通过将注意力集点与最近的标记结合使用，StreamingLLM可以高效地模拟长达400万个标记的文本。我们进一步展示，通过预训练模型引入一个专用的集点标记可以提高流媒体性能。StreamingLLM首先解耦了LLM的预训练窗口大小和实际文本生成长度，为LLM的流媒体部署铺平了道路。