AI 推理加速原理解析与工程实践分享_文化 & 方法_Baidu AICLOUD

【AICon】如何构建高效的 RAG 系统？RAG 技术在实际应用中遇到的挑战及应对策略？>>> 了解详情 



 写点什么

本文整理自同名线上分享，是 12 月份「百度百舸 - 云原生 AI」技术公开课的第三期。

系列主题页：百度智能云公开课

第 1 期：云原生 AI 的资源调度和 AI 工作流引擎设计分享

第 2 期：AI 训练加速原理解析与工程实践分享

第 3 期：AI 推理加速原理解析与工程实践分享

第 4 期：视觉大模型训练和推理加速

番外篇：双引擎 GPU 容器虚拟化，用户态和内核态的技术解析和实践分享

这次分享将端到端分析 AI 推理过程以及痛点，介绍业界典型的推理加速思路和具体方案，并介绍百度智能云在这方面的一些实践成果。

本次分享我们将介绍如何加速 AI 推理过程。内容主要包括四部分：

第一部分，端到端的分析 AI 推理的过程以及这个过程中的痛点；

第二部分，我们将介绍业界典型的推理加速思路及具体方案；

第三部分，介绍百度百舸平台的 AI 推理加速套件 AIAK-Inference 的加速方案；

最后一部分，我们则将通过 demo 的方式，演示 AIAK-Inference 的使用方式及加速效果。

AI 推理的痛点

AI 推理是将用户输入的数据，通过训练好的模型产生有价值信息的过程。具体的是将训练好的 AI 模型部署到提供算力的硬件上，并通过 HTTP/RPC 等接口对外提供服务。

这个过程的参与者主要有 2 类人，一类是 AI 算法工程师，他们希望能将自己研发的模型高效的部署到线上，并为模型最终的效果负责。另外一类人则是基础架构工程师，他们负责管理异构算力集群，并为集群的资源利用效率负责。这两类人群的痛点分别如下：

对 AI 算法工程师来说，他们希望自己训练的复杂模型可以更快的提供服务。而对于基础架构工程师来说，他们则希望可以将价格昂贵的 GPU 资源发挥出最好的效能。这两类问题都需要解决。

如果我们从端到端的视角再来分析下整个 AI 推理过程，会发现这两类用户的痛点目前没有得到很好的解决。

用户对 GPU 的使用初始于业务系统，用户根据业务需求搭建模型，并为最终模型的效果负责。

业务系统构建完成后，会从资源管理系统中申请资源，而资源管理器则会将 GPU 卡分配给业务系统，这个管理器只会为资源分配率负责，而不会关心资源分配后的业务使用效率。

用户在申请到资源后，会通过 AI 框架执行模型的计算过程。AI 框架更专注为用户提供易用的模型构建接口，而不会为业务的推理效率和资源利用率负责。

最后 AI 框架在使用异构硬件算力时，只能使用基础的加速包或工具，而不会专门结合业务特点进行优化。总的来看，整个过程中没有专门的工具为 GPU 算力的利用效率负责。

为此，我们需要 AI 推理加速，针对用户训练好的模型，进行针对性的加速，缩短业务推理时间，同时提升资源利用率。

推理加速的业界解决方案

为了系统性的分析和进行推理加速方案，我们首先需要能够定义推理加速的优化目标。为此我们先简单回顾下 GPU 的硬件架构和执行模式。

从硬件上看，GPU 的强大算力来源于多 SM 处理器，每个 SM 中包含多个 ALU 计算单元和专有的 Tensor Core 处理单元。对 GPU 来说，当所有 SM 上的所有计算单元都在进行计算时，我们认为其算力得到了充分的发挥。

GPU 无法自己独立工作，其工作任务还是由 CPU 进行触发的。

整体的工作流程可以看做是 CPU 将需要执行的计算任务异步的交给 GPU，GPU 拿到任务后，会将 Kernel 调度到相应的 SM 上，而 SM 内部的线程则会按照任务的描述进行执行。当 CPU 不发起新的任务时，则 GPU 的处理单元就处在空闲状态。

通过这两个层面的分析，我们知道要想将 GPU 的算力充分发挥，其核心就是保持 GPU 上有任务，同时对单个 GPU 计算任务，使其可以尽量充分的用好 SM 处理器。

针对这两个层面的使用情况，NVIDIA 提供了相应的牵引指标 GPU 利用率和 SM 利用率：GPU 利用率被定义为在采样间隔内，GPU 上有任务在执行的时间。而 SM 利用率则被定义为在采样间隔内，每个 SM 有 warp 活跃时间的平均值。

我们可以通过 2 个 case 来比较下这两个指标的差异。在下图的 case 1 中，由于 CPU 异步发射任务到 GPU 上，GPU 很快就处理完了，于是就出现了等待下一个任务的空隙。在这种情况下，按照定义，GPU 利用率比较低，SM 利用率也相对较低。两个指标都能反应这种情况没有充分利用 GPU 资源。

针对下图的第二个 case，对于某一个 Kernel 来说，由于计算实现、参数配置等一系列问题，它只使用了 1 个 SM 处理器，而剩下的 3 个 SM 处理器（假设只有 4 个 SM 处理器）空闲。

对于这种情况，由于 GPU 上有 Kernel 在执行，在这个时间段内 GPU 利用率仍然是 100%，但 SM 利用率只有 25%。可以看到这种场景下，SM 利用率可以反应计算任务效率不高的问题，而 GPU 利用率则无法反应此类问题。

因此我们认为 SM 利用率可以更精细的反应 GPU 算力发挥情况。因此我们把 SM 利用率当做 AI 推理加速的牵引指标。

有了牵引指标，结合模型执行的流程，我们就可以在逻辑上将优化方案分为三类：

第一类优化是模型精简类，即在模型真正执行之前就对模型的计算量进行精简，从而提升推理速度。这部分业界常见的优化方向包括量化、减枝、蒸馏和 NAS 等；

第二类和第三类则是当模型已经交由推理引擎在 GPU 上执行时，如何更好的提升 GPU 的利用效率。

我们由 SM 利用率公式做一个近似可以导出这两类优化方案，分别是尽可能让 GPU 上有计算任务和单个计算任务在 GPU 上执行效率更高。这两类优化方案常见的手段分别是算子融合和单算子优化。

接下来分别介绍这三类优化方案。

在模型精简上，通常大家会采用量化、减枝和蒸馏等手段。

简单来说，量化就是将模型中的计算类型进行压缩，从而降低计算量。常见的手段包括离线量化和量化训练两类。

离线量化是指在模型训练完成后，离线的对计算算子进行量化，这种方案通常易用性较好，对算法开发人员几乎透明，但对模型精度会有一定损失；
量化训练则是在模型训练过程中就显示插入量化相关的操作，这样通常会有更好的精度，但需要算法开发同学准备相关数据。

而减枝则是通过将模型中对结果影响较小的一些计算进行移除，从而降低计算量。

蒸馏则通常是将一个复杂的大模型通过降维的知识传递层，将大模型中的复杂计算，减少为效果相当的更小规模的计算，从而实现降低计算量，提升推理效率的效果。下图中是百度文心 3.0 大模型知识蒸馏的过程。

这些模型精简的方案，由于涉及到对精度的影响，通常需要算法工程师介入，协同优化。

第二类优化则是算子融合，算子融合顾名思义是指将多个计算算子合并成一个大算子的过程。

例如对于 BERT Base 这个模型，经过 PyTorch 原生 jit 编译生成的 TorchScript 图中有 800 多个小算子，这些小算子会带来 2 类问题：一是这些算子通常执行过程较短，因此会造成大量的 GPU 空闲时间；二是由于不同的任务之间还有数据的依赖，因此也会带来额外的访存开销。

目前针对算子融合，业界通常会采用手写或自动化生成的方式发现可融合的模式，并提供融合后的算子。例如针对 Transformer 结构，NVIDIA 开发了 FasterTransformer 这个库，其中包括针对多种 Transformer 类结构模型的具体融合算子。

例如下图中，针对 batch GEMM Q x K、Softmax、batch GEMM for QK x V 和长尾的 transpose 等操作，FasterTransformer 提供 Fused Multi-head Attention 等融合后算子。BERT Base 在经过 FasterTransformer 的算子融合优化后，数量可以降到 100 个左右。

第三类优化则是单算子优化。单算子优化是根据单个算子，结合计算模式和硬件架构特点，调整 GPU 核函数的实现方法，从而提升具体算子的执行效率。单算子优化中，最经典的例子就是对通用矩阵乘（GEMM）的优化。下图是 NVIDIA Cutlass 库对 GEMM 操作的抽象：

Cutlass 结合 GPU Global Memory、Shared Memory、Register File 这几层存储架构和 block、warp、thread 和 tensor core 这几层计算抽象，设计了一系列计算模板，并提供相关可优化参数（切分大小等），方便开发者开发高性能的 GEMM 实现。

以上就是业界常见的几类 AI 推理加速的方法和业界的一些解决方案。接下来我们重点介绍下 AIAK-Inference 是如何站在巨人的肩膀上，提供性能更好的推理加速方案。

AIAK-Inference 推理加速套件简介

AIAK-Inference 是百度智能云提出的 AI 推理加速套件，是百度百舸整体方案中的一部分。

AIAK-Inference 旨在优化在百度智能云上采购的 GPU 等异构算力的推理效率，降低推理延迟，提升推理吞吐。只要通过百度百舸方案提供的 GPU 算力，都可以使用 AIAK-Inference 进行推理加速。

AIAK-Inference 的整体架构如下图所示，整体分为 4 个层次，分别解决的问题如下：

图接入：解决多框架动态图 / 静态图捕获问题，将动态图转换为推理友好的静态图；
后端抽象：支持将业界多种优化方案统一整合，通过计时的方式选择最优的加速后端；
具体加速后端，支持业界多种开源加速后端，包括飞桨提供的 FastDeploy 等；此外还有一套自研加速后端，通过图优化、图转换和加速运行时三部分对模型进行整体的推理加速；
算子库：除了使能业界最优的常见计算算子库，还针对具体场景的重点计算模式进行定制化开发，提供场景加速的算子库。