过去一两年大语言模型的技术和应用有非常大的进展，业界也非常关注大模型在部署推理层面上的性能问题，怎么样更好的做推理优化？今天非常高兴能够利用这个机会和大家交流我们在过去一段时间在大模型推理优化这块的工作。我今要讲的内容主要会从这几个方面展开：首先我会简要回顾大模型推理需求挑战的背景，大模型推理优化的基础上架构是怎么样的。之后我从下面四个方面去展开讲大模型优化技术的要点，包括高性能算子、运行时量化压缩以及分布式调度这四个方面。

一、大模型推理优化概述

首先是大模型部署挑战的来源，从部署的视角来看，大模型规模增长的挑战主要是两方面：

一方面是参数的规模，另一方面是上下文的规模。参数规模相信大家已经比较熟悉了。主流的大模型服务所使用的模型参数规模至少都是千亿量级的，最前沿的会到万亿量级的参数规模，是一个非常大的参数规模。这张图展示的是过去一两年比较受关注的、典型的大模型支持上下文的规模，从GPT3的2K的规模到24年初发布的gamaner 1.5的100万的上下文参数规模，基本在一年左右的时间增长了2-3个量级，所以上下文规模的增长也是非常的显著的。参数规模和上下文规模的增长会非常直接的给大模型部署推理时显存的开销、缓存的开销以及计算的开销都带来巨大的增长。这是非常直接在推理方面性能的挑战。

基于大模型推理的技术挑战，以及近年来业界技术的发展，包括我们自己在实践中的一些经验，我们认为大模型推理优化可以从展示的这个技术栈来开展。最底层是具体的加速硬件，我们在阿里云上也会提供多样的异构硬件。硬件之上是部署平台，在阿里云PAI平台上有PAI ES部署平台，基于这个部署平台可以提供相应的部署管理或扩缩容功能。平台之上的几层就是我今天主要要讲的内容。

自下而上有基础的高性能算子以及量化压缩的这部分。中间需要一个高效的运行式框架，能够很好的集成，如请求处理、batch调度、promptcache、以及高效解码等。基于这个框架，如果想进一步在分布式的情况下提升大模型推理的性能，我们还需要考虑怎么样设计一个合理的分布式的架构和相应的调度策略。整体上这是我们认为在当下这个大模型部署推理优化问题的背景之下应该去关注的技术栈。

接下来我就会详细的展开上面这一层重点的四个层面。

二、高性能算子

首先是高性能算子，大模型架构已不算太复杂，但是要把算子计算本身的优化做对、做到极致还是有些难度的，不是特别容易的事情。比如我们要能够适应兼容主流大模型架构的需求，并且达到接近理论上限的性能优化，也非常有发展势头。左边这个图表展示的是group web extension的算子性能，橙色的柱状图是自研的baby N高性能算子库的性能指标，靠左边蓝色的柱状图是业界比较流行的开源的算子库——flash pencil里的pencil算法的性能指标。

纵坐标是license(延迟)。输入quree不同的长度，性能优化空间非常大。右边展示的是在处理面常用的量化矩阵算子的性能，同样橙色的是自研的blade n高性能算子库的性能，蓝色的是业界近期比较受关注的性能，比较优的算子库——marlin算子库的性能。在矩阵成的计算上，在不同情况下可以进一步获得性能收益。当battle更大之后，性能收益会更明显。从这两个案例我想讲的是在最基础的层面上，还需把高性能算子做的非常扎实。

除了实现非常扎实的、非常高性能、非常极致的优化外，我们希望部署能够更好的灵活扩展到多样的硬件知识，还希望底层算子库也能具备很好的扩展性。我们前几年在pai平台上有非常多在AI编译技术方面的积累，基于过往AI编辑技术积累，针对大语言模型场景研发了一套自动算子生成的算子库——flash n。 这张图上展示我们自己和自己比，我们基于编译技术自动生成算子refreshing，用橙色表示，和基于专家手工调优机制、调优范围的实现，在大语言模型场景，一些典型的计算，包括IMS nom、democrat动态量化、配置tension、jam等算法对比。

虽然基于自动生成在某些区间上面会有上下起伏，但基本和专家手工优化、调整的范围是相当的。基于这个技术架构能更好的扩展到更多样的硬件平台。我们今天看到除了MV的cuda生态的GPU,也有AMD GPU ，对于云计算平台来说，最重要的是怎么样能够给平台上的客户更多样、更加灵活的选择，能够使用到更好、更适合的底层硬件支持。补充一下flash n的自研算子库也在这方面开源，大家如果感兴趣可以关注一下。这部分就是关于高性能算子库实践。

三、量化压缩

除了最基础的算子库实践，在大语言模型上还需关注参数规模、上下文规模带来的显著问题就是显存、缓存效率的问题。今天比较被主流接受的优化的手段是低精度的量化压缩。关于低频量化压缩基本的技术原理相信大家都有所了解，简单来说就是说使用更低比特的数值类型表示权重、存储权重，以及使用更比特的数据类型计算，我不会细致讲低比特量化的基本原理，主要想讲在我们的实践经验中观察到的问题或现象，实际并没有非常简单粗暴的策略定义什么样的量化模式，是最适合的。这张图展示的是在不同的模型负载和安全环境下面需要不同的量化策略或量化模式。

这是一个关于量化模型性能的示意图，不是实测数据，横坐标表示的是部署的硬件资源显存容量限制，纵坐标表示部署的实例能够达到的最大吞吐。当显存容量较小时，模型部署后能处理的并发量会比较少、比较低，处于低并发区间。这个时候推理计算是以decoding的计算为主，也可以认为它是性能瓶颈，主要受限于缓存区间。

随着实例显存容量的增加，能够达到更高的并发，计算区间以prifile计算占主导的模式，或者说它主要的瓶颈是受限于计算，随着显存容量增加、并发增加，通常系统的最大吞吐会增加，但之后会逐渐趋于饱和，受限于整体的硬件的计算算力。不同的颜色线表示不同的量化策略，在低并发或在缓存瓶颈的区间，黄色的线就是W4A16，权重以4比特压缩，计算用16比特进行的模式下比绿色的线W8A8，权重用8比特压缩，计算也用8比特进行的情况下有更高的吞吐。

因为用4比特压缩权重会获得更加明显、更加优的访存收益，需要搬运的权重数据量变少，随着吞吐、并发量的提升，到了高并发区间、计算瓶颈区间后，两者的对比相反，即绿色的线会比黄色线高， W8A8的量化模式比W4A16的吞吐高。

这时受限于计算，而W8A8是使用8比特的数值类型计算，能够利用上目前主流GPU的定制化或是IP8的参数算力。主要是想和大家解释一下，我们在做量化压缩时也需关注真实的worker真实的系统部署的规格，然后做更好的选择。最上面的红线是混合模式，称之为W4A8，也就是权重用4比特压缩，计算用8比特，通常在不同的区间上都会有更好的整体最大存储收益。

关于计算的性能方面，量化压缩还有一个非常关键的挑战就是如何获得最佳精度。做低比特的量化压缩通常无可避免的带来数值精度上的损失，因为使用了更少的信息表示一个浮点数对应的参数，这是无可避免的精度损失。目前主流的量化校准算法能在一定程度上弥精度损失，但是也没法做的特别好。

从我们的实践经验中发现，通过采用更加精细的自动混合策略，在校准阶段，如左图所示，上面蓝色的框对应的是在校准阶段，我们在每一层上可以精细的选择不同的、最适合这一层的数据或是误差特性的量化校准的算法策略、精度选择，甚至是一些误差补偿策略，是否使用这个策略组合，基于这个选择，我们能够更好的提升整体的量化精度效果。在不同计算负载的情况下，不同的量化模式也有不同的性能收益。

左图下面蓝底文字示意在推理时我们会在每一线性层的计算模块内根据计算的尺寸动态选择应该使用什么样的计算模式更优，比如使用A8W8最优，还是使用W4A16更优。基于这两个层面的自动混合量化的组合策略，我们能够在实际应用中取得一个最佳精度和性能的平衡，使量化压缩类似于千问这种真正综合型的大规模的场景范围具备很高的可用性，不仅是算法层面上或是单点技术层面上的方案。右边两个图表分别展示在精度和性能层面上通过自动量化组合策略能够获得的收益。右上角是性能相关的曲线，这是实测的相关曲线，横坐标是规划的KPS表示吞吐，纵坐标是生成token间的延迟，可理解为每生成一个token的响应延迟。这个曲线越平缓意味着可以在更高吞吐的情况下，依然保持较低的生成延迟。我们前面提到W8A8、W4 A16在不同的吞吐区间延迟的表现是不一样的，即橙色线和蓝色线中间是有交叉的，在不同区间表现不一样。

当我们采取混合策略，使用混合的W4A8方案，在每一负载区间都能取得更好的延时表现。右下角是我们在几个常见的评测任务上验证自动量化策略组合方式相比于目前主流的量化校验算法AWQ取得精度上的提升，基本在每一任务上都能取得相应的精度提升。这关于量化压缩，我们认为更精细的在算法校准、性能选择组合策略上的方案能做到更极致、更好的精度和性能的平衡。上面讲的算子以及量化压缩主要解决的是模型层面上模型本身的推理计算的性能问题。模型计算本身占据大语言模型服务推理中的主要部分。但我们发现，尤其当并发高、负载高了之后，在线服务的框架运行层面上的性能效率问题的影响也会被放大，甚至会显著影响到部署服务的吞吐。

四、高效运行时和高效解码

所以下面就会继续讲除了基础的模型层面上的优化之外，还需要进一步做运行时框架层面上的优化。这基于我们过往在真实的场景部署服务中发现的新问题，专门针对大语言模型在线服务场景设计的全异步运行时的框架。从左至右是当全生命周期内的一个请求从客户端到web server建立连接开始，会被异步提交至后面做模块的队列中等待被调度。在被batched调度模块处理后，被异步的提交至生成引擎部分，做高性能的、高效的batched influence处理。对于生成好的、采样出来的token，我们会异步做后处理，就是detokenization部分，然后获得生成结果，持续返回给最外部的客户端。

蓝色的部分和橙色的部分表示在prompt cache的调度模块，能够感知是否可复用已经处理过的prompt缓存信息。在Generation engine部分，我们也会提成像look at the decoding这样高效解码的策略。针对大语言模型来说，这些策略能非常有效的使推理计算和采样计算时能使用计算密度更高的batch，从而最大化的发挥算力资源。我们基于全异步运行框架，并且结合了prompt cache以及一些高效解码策略，获得一个真实的在线服务场景，尤其是高并发场景的最佳性能表现。

我们做了运行时框架部分性能的展示对比。我们选择了目前业界比较流行、比较受关注的两个框架对比。左侧橙色的柱状图表示的是VM框架，青色表示的是SGLang框架，蓝色表示的是我们自研的blade LLM定时框架，注意我们为了对比运行时本身的性能，没有启用量化压缩或高效解码等特殊的优化策略，主要对比基础情况下运行的表现。可以看到就是从64到512不同的并发测试中我们的运行时框架本身都能够取得相应的吞吐收益，并随着并发的增加，权益部运行式框架本身有更好的可扩展性。这是关于运行时框架部分，我们前面讲的高性能算子、量化压缩、运行时框架更多的是在实例内部，就是在部署在线服务时在实例内部需要解决性能问题。

五、分布式调度

但大模型推理的技术方案来源是模型参数、上下文规模都在以非常夸张的速度在增长。当规模增长到单实例资源不够的情况下应该怎么办？ 不要求想怎么样去提高规模化和可扩展能力。我们认为我们应该进一步从单实例到多实例考虑、设计、实现一个合理的、高效的、分布式的架构，以及相关策略。接下来我会讲分布式架构这方面做的一些工作，以及我们的理解。

这张图就是我们认为要解决从单实例到多实例分布式场景下进一步做模型推理优化需要解决的关键问题。我们设计了一个多层次的分布式架构，以及相应的调度机制来充分提升，当有比较大的部署集群时，怎么样最大化提高利用率，最大化的加速或提升部署性能。主要是三个层次，我自上而下讲一下这三个层次。第一个层次是在这个请求层面上的调度。中间每个蓝色的矩形框表示一个实例，我们有自研的nomics技术做请求层面上的调度，能根据全局的负载情况来分发请求， 并且能够动态迁移请求，使得所有的负载更均衡、更合理，资源利用更充分。如图上半部分的示例，在实例屏上只做像prepare的计算。

prefer的计算和defet计算具备非常不同的计算性能，一个更偏向是计算密集，一个更偏向访存密集。如果按照常规的方式放在一起做，它们之间会有性能层面的干扰。我们可以采用preferred code阶段分离策略，在实例0上只做prefail计算，在实例1只做decode计算，实例0到实例1中间做动态的请求迁移，做完prefail后，可以动态的把请求处理的下文先移到实例1，继续做decode计算。这样能够解耦prefail和decode两种不同的计算模式，使整体集群或在线服务能非常好的平衡最大吞吐，以及每个请求的响应延迟。当实例1上的某些请求随着生成进行，请求变得非常长，可能生成了几千，甚至几万的token数，请求长到实例之间不均衡。这时可以动态的将实例1的请求进一步的迁移到负载更低的实例2上，使集群上实例的请求和资源的利用更加均匀，这是在请求层面上的调度。

第二个层面是需要更精细的在请求内做分布式调度。我想介绍一下我们自研的叫illustration技术，这个技术能够做到非常精细的在多实力之间分配，同一请求的KD cache的管理以及atantion计算。图的右下侧的示意，在实例1上有一个请求R1，它的请求长度过长，长到导致实例的显存资源都不够放下这一个请求，比今天包括千问在内比较先进的大语言模型服务至少支持128K的请求长度，甚至业界最长的长度可能会更长。请求长度过长，单个显存实例资源没法放下怎么办？这时仅靠动态迁移也不能解决问题，我们可以基于ESQL技术将R1的请求的一部分的上下文（对应的KV cache）迁移到实例2上。

R1的另外一部分会和实例2上其他请求一起去做相应的计算，实例1和实例2在技术的支持下，能做到逐层的协同计算共同完成R1请求所需推理的计算过程。这会使我们具有更加精细的分布式的调度空间，同时也使我们在支持模型更长的上下文或上下文长度变化非常大的情况下能够有更好的性能表现。

第三部分，在实例内部有多个加速链接、有多张GPU卡，这涉及到支持多样和灵活的模型并行策略，比如像tensor priority（张量并行策略）、PT（流水线并行策略）、ET（MOE模型expert并行策略）、DP（数据并行策略）等。目前在业界用的比较多的大语言模型的并行策略通常是通过TP解决单卡无法放下一个模型权重的问题。但是我们在实践中发现，根据不同的模型负载的情况，综合性的组合不同的并行策略，可使我们取得更好的整体模型部署性能。

关于分布式架构，我也举一个具体的、关于性能的例子。我们实际测试了基于ElasticAttention技术（非常精细的分布式的调度策略），能够加速prepare阶段的计算，同时也能提升典型情况下的整体吞吐。上面这张图表是在不同的输入长度，从32K到512K的这个长度下，以及不同的GPU的资源卡住的情况下，使用蓝色表示的柱状图ElasticAttention和不使用ElasticAttention，而使用相对常规的transfer的张量并行的方式支持模式下面的prefill阶段或首包延迟的性能表现。

ElasticAttention能够在每一个长度和相应的GPU卡住的情况下取得更好的手包延时的性能，最大加速会达到3倍的prefill加速，这是非常明显的收益。当请求非常长的时候，会有非常好的收益。除此之外，下面这张图展示的是一个更加综合性的常规实验，假设输入的请求分布在1-128k之间，可能会有不同长度的请求进来，采用ElasticAttention技术部署两个单卡的实例和按照TP的方式部署一个实例的性能表现对比。蓝色是49%最大吞吐收益，基于这样的分布式架构，我们能够在集群或分布式场景上取得进一步的性能收益。

基于上面讲的四个方面的技术要点，我们把相应的技术以及经验和实践沉淀在BladeLLM引擎框架之中。这张图是BladeLLM基本的系统的框图。最底层橙色部分是平台的部分，包括PAIEAS平台、云上多样的硬件，最上面是可以通过BladeLLM服务来支持多样的应用场景。BladeLLM引擎能够开箱即用的提供OpenAI兼容接口、流式/非流式的服务接口，也支持目前主流的模型架构。中间这个框图里面的模块是一些具体的技术点，我就不一一展开了。

最后再展示一个综合、典型的workload场景的性能示例。这是我们在千问72B量级模型做的一个综合性的性能评测。假设这个模型的平均的输入长度是2000，输出长度是300，在比较典型的情况下，这两张图表的横坐标都是规划后的QPS，左图的纵坐标是首token的延迟，右图的纵坐标是生成token之间的延迟，分别表示两种比较重要的、我们关注的延迟指标，曲线越平坦意味着它可在取得更高吞吐的情况下保持低延迟水平。以左图为例，在典型的负载情况下，相对较低的QBS或相对较高的QPS在相同负载情况下，通过典型的优化手段，面青色曲线是我们使用VM框架部署的IP设备的模型，以此作为基础的性能参考，能够取得2倍-3倍的加速收益。最下面蓝色曲线是开启W4A8的混合量化模式，以及split logically的高效解码模式能够取得的表现。

当纵坐标一致，即当延迟水平一样的情况下，需要满足实例在线服务的延迟水平可以取得大概两倍的吞吐，右边是类似的展示。当我们关注另一比较重要的延时指标的情况下，我们能取得2倍-3倍的延迟加速，或者在相应的延迟要求情况下，能取得1.6倍的吞吐。这是典型优化技术的性能展示。

我今天要讲的内容大概是这些。欢迎大家后续关注PAI平台的产品和服务，以及阿里云PAI团队在AI基础技术设施方面的技术进展，谢谢大家。