超长序列在生成任务场景变得越来越重要，尤其在超长文本理解、视频生成等场景。阿里自研训练引擎 TorchAcc，提出了超长序列训练方案 FlashSequence，通过 2D Context Parallel 和 Hybrid FSDP 混合分布式策略，结合显存优化、计算优化、通信优化等技术，实现了 Million 级别的超长序列模型高效训练。

 

一、超长序列生成任务应用场景

首先介绍超长序列各种应用，在实际的业务中的各种应用场景。其实除了视频生成任务之外，还有一些超长文本的理解，一些图像的生成，文本的摘要等等各种各种业务场景下，对于超长序列都有非常强的需求。超长序列到底给这些业务场景带来什么样的价值，更多的是可以理解更长的上下文文本，同时对于超长的信息能够做更好的逻辑性的理解和认知。实际上，超长序列功能，在language model的这种落地和应用场景下，有很大的一个推动作用。所以提出的解决方案也希望能够给 large language model的应用场景有很好的推动作用。

 

二、面临的训练难题

操作序列对于实际的训练过程中，有什么样的难题和挑战需要去解决。拿一个非常实际的视频生成的例子来介绍。首先在视频生成的例子中，常常会需要先把训练的video交给 vae encoder layer, 转换成更低向量的空间里去，最终通过position的一些方法，把它变成一个向量，交给DiT 的模型训练，最终DiT的模型的输出是去到了之后的向量的表达，转换成实际的视频。在这个过程中，可以看到到底哪里有一个超长的序列。

其实超长序列就在 encoder 的后面。其实这个序列对于视频生成的任务，常常需要达到几万到几百万的一个数量级。那对于这样的一个超长的序列，实际上，通过深入的去分析，主要是有两方面的一个问题，一个是算力，一个是选择的需求。

1.算力需求

首先，算力的需求很核心的两个关键因素就是S和H，过去一般常见的模型里，H 大小大部分是在2K到8K左右。那但是在超长序列的场景 S 会远远大于这个 H，S比如说拉玛三到8K，常见的已经达到64K。Large language model 视频生成的任务可能达到几十K或者是million级别。从此可以看到在这个超长序列场景下，S 的长度大小是远远大于H 的，通过公式可以算出来。

随着 S 和 H 的增长，计算的增长是非常快的，做过大约的预估，比如去训练一个视频的DiT的模型，只是拿一个简单的7B模型来举例子。假设要训练一个7B的模型，同时要训练一个1亿条样本的任务，大约要需要花多久。做的预估是需要2000张A800的卡，大约需要训练11.2个月。数字是非常夸张的，但虽说夸张，还是比较理想的数字。在实际的训练过程中，会有很多的任务的费用的问题，集群的问题网络的问题，显卡的问题，还是会大大的拖慢进展。

只是训练单独的一条样本。实际上在训练过程中还要去反复的调参调模型效果，调模型的细节，这些总体来看，要训练模型是非常夸张的。这是算力的需求。

2.显存需求

显存的需求常规来说，去训练一个模型，显存的占用基本上可以分为两大类。那我们去看一个7B，尤其是超长序列的模型，可能比模型的大小一般 7 B十几B这种规模，但实际上对于现存的开销并不算大，但如果进一步看占比，做一些量化的评分分析评估，对于100万的大小大约是8000个G，也就相当于100张A800的显卡才能放得下，在算力需求和显存的需求之外，可以看到训练一个超长的序列，对于算力，对于显存的开销是非常庞大的，需要有非常多的计算资源来支撑任务。

3.其他难题

无限制的堆砌计算资源就可以很轻松的去解决实际问题吗？首先如果堆砌大量的资源需要庞大资源，如何利高效利用，所以需要设计一个非常高效的分支策略来降低网络的通信的占比，提高 GPU 利用率，超长模型的计算量收益是非常高的，是不是真的愿意等十一个月甚至甚至更长的时间，那如何去优化计算的需求，将计算量能尽可能降低或者是说，尽可能的提升gpu利用率其实都是非常重要的一个关键因素。显存开销一百张卡，实际上在为了提高数据并行的并发肯定不希望模型副本需要利用这么多卡训练。还有就是带宽，通过网络带宽和分布式策略结合，整体对模型者提升，做到最高利率，这是通过超长序列对分布式框架的问题。

 

三、FlashSequence 解决方案

通过显存优化、计算优化、分布式优化三方面的协同，最终才能给用户带来极致的性能。

1. 分布式优化

设计4D并行的策略，实际上们的分支策略其实一般来说做一个很好的分支策略，很核心的一个诉求就是能做到把所有的注意都放置在这个GPU 的显存上。同时，分布式策略尽量高效，那这里就设计了自地的并行化，分别包含了两个2D的并行，首先为了解决 parallelism 部分，采用了 FSDP的分布式策略进行切分。当其他资源特别夸张的时候，FSDP 的切割力度会非常的碎。一个可能需要切2000份，这时候通信的要求变得会非常高。因此，在实际的应用过程中也不会单纯的只使用这个 FSDP本身，会引入数据并行来降低FSDP的切分力度。那除此之外，在 FSDP本身还要做一些非常细致的优化。

很重要的一部分是 activation 部分，是我们现在超长序列的场景下最难解决的问题，因为它本来占用量就很大，需要设计一种全新的策略去解决比较大的问题。比较成熟的对于这种超长序列的解决方案就有 ulyesses 和 ring， 对这两种策略进行分别的去结合，因为 ulyesses 的部分是对 activation head维度进行的切分，切分之后接着往下走 activation 部分的计算但是对 head 的切分是有一定局限性的，因为数目是有限的，所以必须从另外一个维度进一步的切分，就又引入了 ring activation ，通过这两种分布策略的结合可以很好的进行部分切分，可以做到在分布式层面能做到很好的性能，尽可能的去降低集群之间的通信。

2.计算优化

flash 的计算实际上呈平方比的关系，平方比的关系的部分就在attention的部分。因此，当我们去分析长序列的模型，会看到如果模型的序列越来越长，整个分析训练过程中，他们那基本上都是被flashattention 所占用。所以如何优化 flashattention 或如何让flashattention跑在它最极致的性能上，非常的重要。

因此，发动了各种不同规格不同配置的Flashattention的性能。纵坐标是它的性能，横坐标是 sqslength，不同的颜色代表了不同的head的维度。可以看到，当横坐标逐渐变长的时候，flashattention计算性能慢慢的趋于稳定，但是横坐标比较小的时候，比如在 2K 到 8K 之间时候，看到不同的 head 数量，其实它的科目的计算性能是有非常大的差异的。如果选定了一个具体的横坐标数值，做计算优化有什么空间，分布式策略采用结合的方法切到不同的维度。

也正是因为分布式策略会切到不同的 head，所以最终通过分布式策略切完之后，交给flashattention 的head 等方面都会有变化。所以只有结合具体的方布式策略以及优化，最终才能达到一个比较好的计算性能。flashsequence 是基于 torchAcc 来实现的， torchAcc 底层集成通过编这两个编译的内容将访存密集型算子进行融合。计算融合的带来的好处是，访存的数量和次数，以及返存的量都会大幅的降低。把多个不同的算子融合成一个算子，以及多个算子之中间的存储也会节省掉。因此，对于flashsequence 通过 torchAcc 的优化，将计算访存密集型算子的16%降低到 7%。

3. 显存优化

采用了一种深层的显存优化策略，显存优化很重要的策略就是选择 G 参数的GC。如果还需要进一步去压缩显存的时候，大家还需要去做一些offload。Offload 的策略一般的优先级会低于GC，原因就是因为offload 需要把GPU显存拷贝到内存里去，在需要的时候再拷贝到显存里，需要频繁的走PCRE，它的带宽还没有想象中那么高，因此这种传输是很难被掩盖的，但是在超长序列场景下有一点不同，因为我们序列比较长，因为序列长，所以计算长，成正比的关系，所以当计算时间比较长的时候，就可以很好的利用这个特点，就用计算的时间来掩盖 offload attention 的传输。在超长序列场景下，反而会一反过去的往常行为习惯，优先使用 off load 来做显存的优化。

同时支持了这种参数控制，当它达到一定长度的时候，off load 是很容易被掩盖掉的，但是并不是想无限制的 off load 就可以。因为CPU的内存也是有限制的，当CPU的内存受到限制的时候，还需要引入一些其他的方法来做这个显存优化。又引入了GC，GC通过对模型的细致的剖析，会选择对于算子，对于计算影响比较小，对于显存影响比较大的特色去进行GC，通过两者的组合，可以很高效的去利用非常有限的GPU的显存。

在实际的训练过程中，理论预估的显存实际跑的时候会远远大于理论预估显存，原因通过仔细的分析会发现，其实训练任务中会有大量的碎片化的问题。实际上在过去各种场景下其实是非常普遍的。设计的时候，会设计一种基于 operatorschedule的方案。实际上在碎片化的场景下，显存的空间始终是够的，但是它比较零碎。当需要生成比较大的显存空间的时候，通过 operatorschedule 的方案就可以很好的解决这个问题。

将一个模型的计算表达转化成一个计算图。通过对计算图的分析，会对所有算子的执行顺序进行排布，通过一个优化算法进行排布，除了对算子的执行顺据进行排布之外，还会对每个 attention 在内存在显存空间的地址位置也要通过算法去计算，尽量的降低这个碎片化。同时降低开销。通过这样一系列优化，发现碎片化的问题会从21%降到0.8%，通过这样的方法，可以让用户的任务可以更为稳定，不管是什么样的模型，什么样的规模，什么样的长序列，都会更为稳定的去训练。

 

四、FlashSequence 性能表现

性能表现方面，相对于 baseline 都有非常好的提升，最大性能提升 48%。不不仅仅是在于 FlashSequence 解决方案能够提供非常优秀的性能。更多的是将一种原本很难落地的运营场景，能让他很好的去应用在业务场景中，给用户、给我们的企业、给业务带来新的可能性，降低企业创新的成本。

 

五、TorchAcc

1.架构

通过 TorchAcc 了解优化是在什么样的情况下实现的，它底层依赖了什么的技术手段，才能将各种不同优化策略集中在一套框架中。TorchAcc 架构，从上往下是一个模型层。模型层依赖于它本身是一个分布式训练，AI训练加速的一个框架引擎，它提供了非常简单易用的接口，所以可以很轻松的去适配各种不同的模型，包括自然语言处理，视觉等，模型下面的是解决方案层，解决方案之下是TorchAcc最核心的三个层次。

从上往下，第一层的意义是希望把用户的模型转成一个计算图，在后面的优化包括自动公式显存，算子的调度融合都是基于计算图进行往下走的，只有有这样的计算图才可以在下层做更通用更有价值的一系列的优化，用两种capture技术，在过去的这种训练框架优化，基本上都只会采用一种技术，团队交流后发现单纯依赖一种方案是很难看到覆盖应用场景的。

因此结合才能更好的更完备的去解决 graphcapture的问题，交给第二层和第三层，可以运行一些动态类型的算子，每次有动态在过去大家做了一个静态的编辑器的时候，每遇到一次动态的输入或者动态的算子的时候，都需要进行重新的编译。之后不管有什么的动态性，只编译一次，会大幅的降低编译的次数，对用户和模型性能的提升都有非常大的好处。TorchAcc通过从软件层到硬件层业务上全链路优化，最终能够提供一个非常优秀的性能和体验。

2.特性

讲过TorchAcc架构，它的主要核心的几个特性，首先它有很好的兼容性，因为它是通过 TPSDAPI接口方式对外提供，而且，通过很通用的图的方式来进行优化，所以可以兼容各种不同的软件模型。其次，它通过 compiler 层介入不同的compiler，以及compiler是可以针对不同的硬件去优化。所以兼容性还包含了支持不同的硬件，支持云上的各种不同的硬件资源。通过对软件对硬件的协调，对用户提供最优性能，支持超长的序列，包括提供了一些非常丰富的策略，以及动态输入，自动的显存和计算的优化。

3.功能

那具体怎么用呢，用户的使用中会有很多的难题，考虑了这样的一个问题，不管用什么的策略什么样的显存优化策略还是分布策略，不能通过非常简单的api接口让用户把 torchacc 利用起来，那通过这样的设计，不管是一个高级算法开发者还是一个小白的用户，只需要关注在自身的业务逻辑上关注在自己的模型的研发上，底层那些复杂的业务逻辑和方式策略都能够通过 ai 来解决，通过简单的接口可以很轻松的将加速的手段用在业务逻辑当中，在各种不同常见的模型上性能提升，可以看到在各种常的模型上。

除了这个模型之外，还支持使用自定义各种模型，这个模型都有非常好的性能提升，其实本身 torchacc 带来的性能提升，除此之外希望它能够给用户以及企业业务带来的价值是，无需过度的每次开发一个业务每次尝试一个创新都需要花大量的时间去做底层的显存的方式的策略优化，因为来到一个新的模型需要把它scale到更大的这个规模，通过这样的性能提升，训练一个模型是需要上亿元成本的背景。通过这种简单的应用的接口，可以轻松的节省上百万甚至上千万的成本。希望它是一个性能效率多重的突破，给客户和业务方带来价值。