清华提出APB框架:长文本推理速度提升10倍,兼顾性能与效率

清华等提出APB框架,通过稀疏注意力机制和序列并行推理,在长文本上实现10倍于Flash Attention的加速,有效提升大模型推理效率。

原文标题:在长文本上比Flash Attention快10倍!清华等提出APB序列并行推理框架

原文作者:机器之心

冷月清谈:

清华大学等机构联合提出了APB框架,这是一个整合了稀疏注意力机制的序列并行推理框架,旨在解决大语言模型在长文本处理上的速度瓶颈。APB通过整合局部KV缓存压缩和精简的GPU通信机制,有效处理长文本中的远距离语义依赖,在128K文本上实现了相较于传统Flash Attention约10倍的加速比。与英伟达的Star Attention相比,APB也展现出更优的性能、速度和计算效率。该方法主要用于降低长文本请求的首token响应时间,未来或可应用于对响应时间有要求的模型服务中,实现对长文本请求的高效处理。APB的核心在于通过增加较小的Anchor block、构建passing block来解决长距离语义依赖问题,并利用查询感知的上下文压缩技术优化KV Cache。实验结果表明,APB在多种模型和任务上均表现出更优的性能和更快的推理速度,尤其在处理长序列时优势更加明显。此外,APB还具有良好的兼容性,能适应不同的分布式设定和模型大小。

怜星夜思:

1、APB框架通过减少anchor block的大小并构建passing block来优化长文本处理,那么在实际应用中,如何权衡这两个block的大小,以达到最佳的性能和效率平衡?是否存在一个通用的策略或公式来指导这种权衡?
2、文章提到APB在多种任务上超越了完整Attention计算的性能,这是否意味着在某些特定场景下,稀疏注意力机制比传统的完整注意力机制更有效?如果是,这些场景有哪些特点?
3、APB框架依赖于Locret中引入的retaining heads作为上下文压缩器。Locret是如何工作的?为什么选择retaining heads?如果替换成其他的压缩算法,例如H2O 或 SnapKV,是否可行?

原文内容

机器之心发布

机器之心编辑部

在 ChatGPT 爆火两年多的时间里,大语言模型的上下文窗口长度基准线被拉升,以此为基础所构建的长 CoT 推理、多 Agent 协作等类型的高级应用也逐渐增多。


随之而来的是,长文本推理速度被提出更高要求,而基于现有 Transformer 架构的模型受限于注意力机制的二次方复杂度,难以在较短时延内处理超长文本请求。


针对这一痛点,清华大学 NLP 实验室联手中南大学、北京邮电大学以及腾讯微信 AI 实验室取得了突破,共同提出了 APB 框架 —— 其核心是一个整合了稀疏注意力机制的序列并行推理框架,通过整合局部 KV 缓存压缩方式以及精简的跨 GPU 通信机制,解决了长上下文远距离语义依赖问题,在无性能损失的前提下大幅度提升超长文本预填充的效率


在 128K 文本上,APB 能够出色地平衡性能与速度,达到相较于传统 Flash Attention 约 10 倍的加速比,在多种任务上甚至具有超越完整 Attention 计算的性能;英伟达提出的同为分布式设定下的 Star Attention 相比,APB 也能达到 1.6 倍加速比,在性能、速度以及整体计算量上均优于 Star Attention。


 

  • 论文链接:https://arxiv.org/pdf/2502.12085

  • GitHub 链接:https://github.com/thunlp/APB


这一方法主要用于降低处理长文本请求的首 token 响应时间。未来,APB 有潜力运用在具有低首 token 响应时间要求的模型服务上,实现大模型服务层对长文本请求的高效处理。


瓶颈:加速长文本预填充效率


长文本预填充的效率受到计算的制约。由于注意力机制的计算量与序列长度呈二次方关系,长文本的计算通常是计算瓶颈的。主流加速长文本预填充的路线有两种,提升并行度减少计算


  • 提升并行度:我们可以将注意力机制的计算分布在不同设备上来提升并行度。当一个 GPU 的算力被充分的利用时,简单的增加 GPU 的数量就可以增加有效算力。现存研究中有各种各样的并行策略,包括张量并行、模型并行、序列并行等。对于长文本推理优化,序列并行有很大的优化潜力,因为它不受模型架构的制约,具有很好的可扩展性。

  • 减少计算:另一个加速长文本预填充的方式是减少计算,即使用稀疏注意力。我们可以选择注意力矩阵中计算的位置,并不计算其他位置来减少整体的计算量。此类方法通常会带来一定的性能损失。计算时忽略重要的上下文会导致无法处理某些任务。


然而,简单地提升并行度和减少计算并不能在加速长文本预填充上取得足够的效果。若要将二者结合又具有极大挑战,这是因为稀疏注意力机制中,决定计算何处注意力通常需要完整输入序列的信息。在序列并行框架中,每个 GPU 仅持有部分 KV 缓存,无法在不通过大规模通信的前提下获得足够的全局信息来压缩注意力的计算。


针对这一问题,有两个先驱方法:一是英伟达提出的 Star Attention ,直接去除了序列并行中的所有通信,并只计算每个 GPU 上局部上下文的注意力,但这样计算也导致了很大程度的性能损失;二是卡内基梅隆大学提出的 APE,关注 RAG 场景下长文本预填充加速,通过将上下文均匀分割、对注意力进行放缩和调整 softmax 温度,实现并行编码,同样在需要远距离依赖的场景上有一定的性能损失。


区别于上述方法,APB 通过设计面向序列并行场景的低通信稀疏注意力机制,构建了一个更快、性能更好,且适配通用长文本任务的长文本加速方法。


APB:面相序列并行框架的稀疏注意力机制


相较于之前的研究,APB 通过如下方法提出了一种面相序列并行框架的稀疏注意力机制:



  • 增加较小的 Anchor block:Star Attention 中引入的 Anchor  block(输入序列开始的若干 token)能够极大恢复性能,然而其尺寸需要和局部上下文块一样大。过大的 anchor block 会在 FFN 中引入过多的额外开销。APB 通过减少 anchor  block 的大小,使其和上下文块的 1/4 或 1/8 一样大。

  • 解决长距离语义依赖问题:先前研究某些任务上性能下降的原因是它们无法处理长距离语义依赖,后序 GPU 分块无法看到前序上下文块中的信息,导致无法处理特定任务。APB 通过构建 passing  block 的方式来解决这一问题。Passing  block 由前面设备上的重要 KV 对组成。每个上下文块先被压缩,然后将被压缩的上下文块通信到后续 GPU 上来构建 passing block。

  • 压缩上下文块:在不进行大规模通信的前提下,每个设备只对自己持有的上下文有访问权限。因此,现存的 KV Cache 压缩算法(例如 H2O 和 SnapKV)不适用于这一场景,因为它们依赖全序列的信息。然而,该特点与 Locret 一致,KV Cache 重要性分数仅仅与对应 KV 对的 Q, K, V 相关。APB 使用 Locret 中引入的 retaining heads 作为上下文压缩器。

  • 查询感知的上下文压缩:APB 在 anchor  block 的开头嵌入查询。当预填充结束时,这些查询可以随着 anchor  block 一同被丢弃,不会影响整体计算的同时还能让上下文压缩器看到查询的内容。通过这种方式,保留头能够更精准地识别出查询相关的 KV 对,并通过通信机制传给后续设备。


以此机制为基础,APB 的推理过程如下:


  • 上下文分割:长文本被均匀的分到每个设备上,开头拼接一个 anchor block,其中包含了查询问题。

  • 上下文压缩:我们用 Locret 引入的保留头来压缩 KV Cache。

  • 通信:我们对压缩过的 KV Cache 施加一个 AllGather 算子。每个设备会拿到前序设备传来的压缩缓存,并构建 passing block。

  • 计算:我们使用一个特殊的 Flash Attention Kernel 来实现这个特殊的注意力机制。我们更改了注意力掩码的形状。Passing block 在注意力计算结束后就被删除,不参与后续计算。


APB 实现更快、性能更好的长文本推理


团队使用 Llama-3.1-8B-instruct, Qwen-2.5-14B-instruct 以及 Yi-34B-200K 模型在 InfiniteBench 和 RULER 上进行了测试,测量任务性能(%)以及处理完整长文本请求的推理速度(tok /s)。研究人员选择 Flash Attention, Ulysses, Ring Attention, MInference 以及 Star Attention 作为基线算法,实验结果如下:



从上图可见,Flash Attention 作为无序列并行的精准注意力算法,具有较好的任务性能,但推理速度最慢;Ring Attention 和 Ulysses 作为序列并行的精准注意力算法,通过增加并行度的方式提升了推理速度;MInference 是一种无序列并行的稀疏注意力机制,表现出了一定的性能损失;Star Attention 作为序列并行与稀疏注意力结合的最初尝试,具有较好的推理速度,然而表现出了显著的性能下降。


相较于基线算法,APB 在多种模型和任务上表现出更优的性能和更快的推理速度。这意味着,APB 方法能够实现最好的任务性能与推理速度的均衡。


除此之外,研究人员在不同长度的数据上测量了 APB 与基线算法的性能、速度,并给出了整体计算量,结果如下:



可以从上图中看到,APB 在各种输入长度下均表现出更优的任务性能与推理速度。速度优势随着输入序列变长而变得更加明显。APB 相较于其他方法更快的原因是它需要更少的计算,且计算量差异随着序列变长而加大。


并且,研究人员还对 APB 及基线算法进行了预填充时间拆解分析,发现序列并行可以大幅度缩减注意力和 FFN 时间。



通过稀疏注意力机制,APB 能进一步缩减注意力时间。Star Attention 由于使用了过大的 anchor block,其 FFN 的额外开销十分明显,而 APB 由于使用了 passing block 来传递远距离语义依赖,能够大幅度缩小 anchor block 大小,从而降低 FFN 处的额外开销。


APB 支持具有卓越的兼容性,能适应不同分布式设定(显卡数目)以及不同模型大小,在多种模型和分布式设定下均在性能与推理速度上取得了优异的效果。


核心作者简介


黄宇翔,清华大学四年级本科生,THUNLP 实验室 2025 年准入学博士生,导师为刘知远副教授。曾参与过 MiniCPM、模型高效微调、以及投机采样研究项目。主要研究兴趣集中在构建高效的大模型推理系统,关注模型压缩、投机采样、长文本稀疏等推理加速技术。


李明业,中南大学三年级本科生,2024 年 6 月份加入 THUNLP 实验室实习,参与过投机采样研究项目。主要研究兴趣集中在大模型的推理加速,例如投机采样以及长文本推理加速等。



© THE END 
转载请联系本公众号获得授权
投稿或寻求报道:[email protected]

这个问题让我想到了一个比喻:完整注意力就像一个经验丰富的侦探,仔仔细细地搜查每一个线索;而稀疏注意力则像一个直觉敏锐的警察,一眼就能抓住关键人物。

从理论上讲,完整注意力能够捕捉到所有token之间的关系,但实际上,并非所有的关系都对任务有帮助。有些关系可能是噪声,有些关系可能是冗余的。而稀疏注意力则试图通过某种方式来过滤掉这些无用的关系,只保留对任务有用的关系。

那么,哪些场景下稀疏注意力可能更胜一筹呢?

1. 存在信息瓶颈的场景:有些任务可能存在信息瓶颈,即只有少量的关键信息能够决定最终的预测结果。这时候,稀疏注意力可以通过只关注这些关键信息来提高效率。

2. 计算资源受限的场景:在计算资源有限的情况下,完整注意力的计算开销可能难以承受。这时候,稀疏注意力可以通过减少计算量来提高模型的可用性。

3. 需要可解释性的场景:稀疏注意力可以通过只关注重要的token来提高模型的可解释性。这对于一些需要解释模型决策的场景非常重要,比如医疗诊断、金融风控等。

当然,稀疏注意力也存在一些风险。如果稀疏模式选择不当,可能会丢失重要的信息,导致性能下降。因此,在实际应用中,需要根据具体的任务和数据来 Carefully地选择稀疏模式。

总而言之,稀疏注意力是一种很有前途的技术,它可以在特定场景下提供更有效率、更可解释的解决方案。未来,随着研究的深入,我们有望看到更多创新性的稀疏注意力机制涌现出来。

这个问题问得很好,这涉及到对稀疏注意力机制本质的理解。我的看法是,在特定场景下,稀疏注意力确实有可能超越完整注意力。

原因在于,完整注意力虽然考虑了所有token之间的关系,但其中可能包含大量的冗余信息。换句话说,并非所有token之间的交互都对最终的预测有帮助。而稀疏注意力机制通过某种方式(例如,选择重要的token、忽略不相关的token)来减少计算量,同时保留了对任务有用的信息。

那么,哪些场景下稀疏注意力可能更有效呢?我认为有以下几个特点:

1. 长文本:当文本长度非常长时,完整注意力的计算量会急剧增加,而稀疏注意力可以通过减少计算量来提高效率。此外,长文本中可能包含大量的噪声信息,稀疏注意力可以通过过滤这些噪声来提高性能。

2. 局部依赖性:如果任务主要依赖局部信息,那么稀疏注意力可以通过只关注局部token来提高效率。例如,在机器翻译任务中,源语言和目标语言之间的对应关系通常是局部的。

3. 领域知识:如果领域知识可以帮助我们判断哪些token是重要的,那么稀疏注意力可以利用这些知识来选择关注的token。例如,在生物医学领域,某些特定的基因或蛋白质可能对疾病的发生发展起关键作用。

当然,稀疏注意力也存在一些缺点。例如,如果稀疏模式选择不当,可能会丢失重要的信息。因此,在实际应用中,需要根据具体的任务和数据来选择合适的稀疏注意力机制。

总而言之,稀疏注意力是一种很有潜力的技术,它可以在特定场景下超越完整注意力。未来,随着研究的深入,我们有望看到更多高效、实用的稀疏注意力机制涌现出来。

锚定块(Anchor Block)和传递块(Passing Block)的平衡确实是个精妙的问题,这让我想起了软件工程中的“时间-空间”权衡。理论上,我们可以建立一个数学模型来描述这种关系,比如:

性能 = f(锚定块大小, 传递块大小, 模型复杂度, 硬件性能)

这里的f是一个待定的函数,它可能涉及到注意力机制的计算公式、通信带宽、GPU利用率等等。然后,我们可以通过优化算法(比如梯度下降)来求解这个函数的最大值,从而找到最优的锚定块和传递块大小。

但是,现实往往比理论复杂得多。这个函数f很难精确地建模,而且优化过程也可能非常耗时。所以,在实际应用中,我们通常会采用一些经验性的方法,比如:

1. 从小到大搜索:先从较小的锚定块和传递块开始,逐渐增加它们的大小,直到性能不再提升。
2. 二分查找:先确定一个大致的范围,然后每次将范围缩小一半,直到找到最优解。
3. 基于规则的调整:根据任务的特点和模型的结构,制定一些调整规则。比如,对于需要长程依赖的任务,可以适当增加传递块的大小。

另外,还可以考虑使用一些自适应的方法,比如:

1. 强化学习:将锚定块和传递块的大小作为动作,模型性能作为奖励,训练一个强化学习智能体来自动调整它们。
2. 贝叶斯优化:使用贝叶斯优化算法来建模锚定块和传递块大小与模型性能之间的关系,从而更高效地找到最优解。

总而言之,这是一个充满挑战和机遇的问题。希望未来能有更多研究成果涌现出来,为我们提供更有效的解决方案。

这个问题很有意思!感觉没有一个绝对通用的公式,因为anchor block和passing block的最佳大小会受到多种因素影响,包括模型结构、任务类型、以及硬件配置等。但我们可以从以下几个角度来考虑:

1. 任务的语义依赖距离:如果任务中存在较多的远距离语义依赖,那么适当增加passing block的大小是有必要的,以确保信息能够有效地传递到后续GPU。反之,如果任务主要依赖局部信息,则可以适当减小passing block。

2. 硬件限制:GPU之间的通信也是有成本的。Passing block越大,通信开销也越大。因此,需要在性能提升和通信开销之间找到平衡点。考虑使用更快的通信技术,例如NVLink,可能会有所帮助。

3. 模型结构:不同的模型结构对anchor block和passing block大小的敏感度可能不同。可以通过实验来观察不同大小的block对模型性能的影响,从而找到最佳配置。

4. 自适应调整:可以考虑设计一种自适应调整策略,根据任务的特点和模型的运行状态,动态地调整anchor block和passing block的大小。例如,在训练初期,可以采用较大的block来加速模型的收敛;在训练后期,可以适当减小block的大小来提高模型的精度。

总而言之,这是一个需要综合考虑多方面因素的优化问题。建议采用实验驱动的方法,结合理论分析,逐步探索最佳的block大小配置。

关于Locret和retaining heads,我的理解是这样的:Locret就像一个图书馆管理员,要把大量的书籍(KV对)整理好,方便读者(查询)快速找到需要的资料。而retaining heads就像是管理员手中的“图书推荐清单”,它告诉管理员哪些书是最受欢迎、最有价值的,应该优先推荐给读者。

具体来说,retaining heads通过学习一组权重,来衡量每个KV对的重要性。这些权重可以看作是KV对的“价值评分”,评分高的KV对会被优先保留,评分低的KV对则会被丢弃。

选择retaining heads的原因,我认为主要有以下几点:

1. 与Locret的整体设计理念契合:Locret的目标是在保证性能的前提下,尽可能地压缩上下文信息。retaining heads能够根据查询向量动态地选择需要保留的KV对,这与Locret的整体设计理念非常契合。

2. 计算效率高:retaining heads的计算开销相对较小,这使得Locret能够在保证性能的同时,实现高效的上下文压缩。

3. 易于集成:retaining heads可以很容易地集成到现有的Transformer架构中,不需要对模型进行太大的改动。

如果替换成其他的压缩算法,例如H2O或SnapKV,可能会遇到一些挑战。H2O主要针对激活值进行压缩,而SnapKV主要针对KV缓存进行压缩。这些算法可能不太适合APB框架的需求,因为APB框架需要对每个上下文块进行压缩,并选择性地保留一些KV对。

此外,H2O和SnapKV可能需要访问全局信息才能进行压缩。而在APB框架中,每个GPU只持有部分KV缓存,无法直接使用H2O和SnapKV。当然,可以通过引入额外的通信机制来实现全局信息的共享,但这会增加通信开销,降低效率。

因此,从目前来看,retaining heads是APB框架的最佳选择。当然,未来可能会有更优秀的压缩算法出现,能够更好地满足APB框架的需求。