一文解读：阿里云 AI 基础设施的演进与挑战

云布道师

2024 年 4 月 18-19 日，2024 中国生成式 AI 大会在北京 JW 万豪酒店举行，阿里云高级技术专家、阿里云异构计算 AI 推理团队负责人李鹏受邀在【AI Infra】专场发表题为《AI 基础设施的演进与挑战》的主题演讲。李鹏从 AIGC 对云基础设施的挑战、如何进一步释放云上性能、AIGC 场景下训练和推理最佳实践三个方向逐一展开分享。

大模型的发展给计算体系结构带来了功耗墙、内存墙和通讯墙等多重挑战。其中，在大模型训练层面，用户在模型装载、模型并行、通信等环节面临各种现实问题；在大模型推理层面，用户在显存、带宽、量化上面临性能瓶颈。

对于如何更好地释放云上性能助力 AIGC 应用创新？“阿里云弹性计算为云上客户提供了 ECS GPU DeepGPU 增强工具包，帮助用户在云上高效地构建 AI 训练和 AI 推理基础设施，从而提高算力利用效率。”李鹏介绍到。目前，阿里云 ECS DeepGPU 已经帮助众多客户实现性能的大幅提升。其中，LLM 微调训练场景下性能最高可提升 80%，Stable Difussion 推理场景下性能最高可提升 60%。

以下是全文内容，供阅览。
李鹏 <a class= 阿里云高级技术专家 & 阿里云异构计算AI推理团队负责人 " />
从 2023 年开始，生成式 AI 爆发，文生视频、文生图、文生文等场景有很多大模型/通用大模型产生，我也和我们的产品团队、架构师团队一起与阿里云客户做过多次技术分享交流，看到了企业客户开始逐渐将生成式 AI 技术应用到实际的业务当中。
在这里插入图片描述
从我的感受来讲，如今越来越多的云上客户拥抱生成式 AI 的场景，大模型的接受度也越来越高，比如电子商务、影视、内容资讯和办公软件、游戏等典型的行业。

上图左侧是 2024GTC 大会上展示的一张关于模型发展对算力需求的曲线图。从2018 年开始这条绿色曲线，从 Transformer 模型、到如今的 GPT、再到最新的 1.8 万亿参数大模型，对算力需求呈现了 10 倍规模递增的爆炸性增长，训练场景对算力的需求非常大。

另外根据估算，如果要训练一个 GPT-3、1750 亿参数的模型，训练的计算量大概在3640 PFLOP * 天，对芯片的需求大概需要 1024 张 A100 跑一个月的时间，这是一个相当大的千卡规模，换算到成本上则是一笔非常巨大的计算开销。总体来说，当前阶段的 GPU 算力价格相对较贵，再到推理/微调本身的算力需求和成本，也可以看到部署的成本也比较高，开销同样较大。

AIGC 对云基础设施的挑战

在这里插入图片描述
谈到大模型发展对体系结构的挑战，首先看到的是功耗墙的问题。以 NVIDIA GPU 举例，2017 年开始，V100 的功耗只有 250 瓦，递增到 A100 功耗接近 400 瓦，H100 功耗 700 瓦，到最新 B200 功耗大概到了 1000 瓦，算力成倍增长，计算功耗也会增加的越来越多。最近业界也有许多讨论说到 AI 的尽头是能源，随着计算需求的增大，会带来能源上更大的需求。

第二个体系结构挑战就是内存墙。所谓内存墙，计算过程数据在 CPU 和 GPU 之间会做搬移/交换，如今 PCIE 的体系结构逐渐成为数据交换和传输的瓶颈。可以看到，像 NVIDIA 也在 Grace Hopper 架构上推出了 NVlink C2C 方案，能够大幅提升整个数据传输的速率。

第三个是通讯墙。尤其对于训练来说，分布式训练规模还是非常大的，从去年的千卡规模到了如今万卡甚至十万卡规模，分布式训练场景下如何增加机器之间的互联带宽也是一个巨大的挑战。从国内外各个厂商的一些进展来看，在 A100 上会采用 800G互联的带宽，在 H100 上会有 3.2T 带宽，也就是更大的互联带宽。所以现在看到的趋势就是硬件堆砌的趋势，总结下来就是会有更大的显存、更高的显存带宽，还有更高的 CPU 和 GPU 之间的互联带宽，最后还有 PCIE 本身的向下迭代。

上图是以 NVIDIA GPU 举例，展示了 Ampere 从这一代架构开始到后面的 Blackwell 芯片的一些特点变化，体现在算力维度就是计算规模会越来越高，过往的不到 1PFlops、如今要到 1P 以上，且显存大小也会越来越大，从前的 80G 到如今的100G+的规模；显存带宽也是非常重要的指标，也在不断增加，这也反映了未来硬件、尤其是 AI 计算上硬件规格的变化。

如何释放云上性能？

在这里插入图片描述
对于大模型训练的技术栈，由 AI 训练算法与软件、Ai 训练硬件资源两个部分构成。

当前，主要是模型结构（主要是Transformer结构）、海量级数据以及梯度寻优算法，这三块构成 AI 训练的软件和算法。

AI 硬件就是 GPU 的计算卡，从单卡扩展到服务器（如8卡），再扩展到更大的服务器集群，做成千卡/万卡的规模，构成整个大模型训练硬件的计算资源。
在这里插入图片描述
大模型训练过程中有一个典型的现实问题：模型的加载和并行。以 GPT 175B 的模型举例来说，它需要的显存规模就训练来说大概需要 2800G，上图是以 A100 80G 为例，要解决的问题是我们需要多少张卡装载这个模型，装载模型后还需要如何去把训练效率提升，这就需要用模型并行技术来解决。

另外，还有互联的问题，互联有单机内部互联（NVlink），还有机器与机器之间的互联网络，这对于分布式训练来说非常重要，因为会在通信上产生一些开销。
在这里插入图片描述
大模型训练当中的模型装载
以 175B 模型为例，以 FP16 精度计算，模型参数大概 350G 显存，模型梯度也需要 350G，优化器需要的显存规模大概在 2100GB，合并起来大概是 2800GB 的规模，如今分布式训练的框架也有比较成熟的方案，像 NVIDIA 做的 Megatron-LM和微软开发的 DeepSpeed Zero 算法，能够解决模型装载和并行的问题。
在这里插入图片描述
大模型训练的并行方式
在大模型训练方式上，业界也有比较多的并行技术可以帮助提升训练效率，比如张量并行、流水线并行、数据并行等等。

TP 是张量并行(Tensor Parallel) ，是对模型的每个层做了一个层内的拆分。使用TP 能达到很好的 GPU
利用率。TP通信粒度是非常细的。TP 每计算完成一次层的拆分，就需要有一次通信来做 AllReduce 合并，虽然 TP 单次通信量较小，但是它通信频率频次都很高，对带宽的要求也很高。
PP 是流水线并行(Pipeline Parallel)，也就是模型的层与层之间拆分，把不同的层放到不同的 GPU 上。在计算过程中，必须顺序执行，后面的计算过程依赖于前面的计算结果。一个完整的 Pipeline运行起来需要将一个workload 切分成很小的多个 Workload，也就是需要将一个比较大 Batch size 切分成很多个小 Batch 才能保持流水线并行的高吞吐。
DP 是数据并行(Data Parallel)，数据并行是指将相同的参数复制到多个 GPU 上，通常称为“工作节点（workers）”，并为每个 GPU 分配不同的数据子集同时进行处理。数据并行需要把模型参数加载到单 GPU 显存里，而让多个 GPU 计算的代价就是需要存储参数的多个副本。更新数据并行的节点对应的参数副本时，需要协调节点以确保每个节点具有相同的参数。

在模型训练过程中，尤其是分布式训练场景下，我们还看到一些比较关键的问题，就是集合通信性能问题。比如，在 Tensor 并行的切分当中，实际上会产生一些allreduce 的操作，这些 allreduce 操作是夹杂在计算流当中的，会产生一个计算中断的问题，因此会带来计算效率的影响。现在有相应的集合通信算法，或者是一些优化实现被开发出来去解决集合通信性能的影响，上图截图中展示的是我们在做一些并行训练时发现的部分瓶颈。

在大模型推理时，我们需要关注三个方面：显存、带宽和量化。
显存，模型参数量大小决定了需要多少显存。
带宽，因为在大模型推理时实际上是访存密集型的计算方式，在计算当中需要频繁的访问显存，这种情况下带宽的规格是影响推理速度的首要因素。
量化，如今很多模型在发布时都会提供 FP16
精度的模型，还会给一些量化后的模型，低精度量化带来的效果是可以省下更多显存，也可以提高访存效率，因此现在很多大模型推理都会采用量化的方式。

总结来说：首先，大模型推理会有显存瓶颈；其次，在推理方面可以选择多卡推理，做 TP 方式切分，训练卡可以用在推理业务，且会有一些不错的效果。
在这里插入图片描述
上图展示的是我们在做一些模型微观性能分析时看到的一些状况，上面是典型的 Tranformer 结构，包含了像 attention 结构和 MLP 结构。在这些算子里面，我们通过微观的分析可以看到，大部分的计算都是矩阵乘运算，就是 GEMM 的操作，实际有 85% 的耗时都是访存，主要是去做显存的读取。

大模型推理本身是自回归的方式，上一个生成出来的 token 会用在下一个 token 的计算，基本都是访存密集型计算。总结来说基于这些行为，在优化时我们会把attention 结构的许多算子以及 MLP 的算子分别融合成大的算子，这样会显著提高计算效率。
在这里插入图片描述
在大模型推理带宽需求方面，以 LLaMA 7B 在 A10 或者 A100 上的对比为例：如上图，红色曲线代表的是 A100 VS A10 QPS 的比例关系，在不同 batchsize 下，红色曲线基本上是一条水平的线，这从侧面印证了大模型推理基本是一个访存密集型的操作，它的上限是由 GPU 的 HBM 显存带宽决定的。
在这里插入图片描述
除此之外，在大模型推理时的一些通信性能也需要特别关注。这里强调一下通信性能是指单机内部多卡通信。举例来说跑一个 LLaMA 70B 的模型，是没办法在 A10 一张卡上装载，需要至少 8 张卡的规格才能把这个模型装载下来，因为计算时做了 TP切分，每张卡算一部分，计算完成后需要 AllReduce 通信的操作，我们针对通信开销做了一些性能分析，最明显的是推理卡上，A10 通信开销占比是比较高的，能够达到整个端到端性能开销的 31%，这个开销占比还是很高的，因此需要在这方面重点关注。

那如何优化通信的开销？通常来说比较直观的方法是如果有卡和卡之间的 Nvlink 互联，性能自然会有提升，因为 Nvlink 互联带宽还是比较高的。另外，如果 GPU 卡没有像 A100 这样的 Nvlink，则需要走 PCIE P2P 通信，这种通信方式也会从一方面帮助提高通信性能，在阿里云上我们团队通过亲和性分配调优，摸索出一套优化方法，能够在 4 卡、8 卡场景下把通信开销占比进一步优化，实现开销下降。
在这里插入图片描述
从今年年初 OpenAI 发布 Sora 之后，国外已经有机构给出了关于 Sora 这样视频模型算力需求的分析，因为它的模型结构和原来文生图的模型结构有区别，其中较为显著的区别是原来的 Unet 结构变成了 diffusion Transformer 的结构，通过结构上的变化和一些算力的估算，可以看到 Sora 视频模型不管是在训练和推理上都会有比较大的算力需求。

上图展示的就是国外某研究机构给出的算力需求，他们估算如果要训练 Sora 这样一个模型大概需要 4000-10000 张 H100 训练一个月，基本能训练出 Sora 这样的模型。在推理上这个需求也会比传统的大语言模型来得更高，估算结果是如果我们要生成像 Sora 这样的 5 分钟长视频，大概需要一张 H100 推理一个小时的时间，所以算力的需求还是非常高的。
在这里插入图片描述
下面为大家介绍一下阿里云弹性计算为云上客户在 AI 场景下提供的基础产品增强工具包 DeepGPU，这是针对生成式 AI 场景为用户提供的软件工具和解决方案，旨在帮助用户在云上构建训练/推理的 AI 基础设施时，提高其在使用 GPU 上训练和推理的效率。因为，目前普遍 AI 算力还较为昂贵，我们需要用工具包的方式帮助用户优化他们使用 GPU 的效率，同时我们也会提供像文生图和文生文等场景下的解决方案。目前，阿里云 ECS DeepGPU 已经帮助众多客户实现性能的大幅提升。其中，LLM 微调训练场景下性能最高可提升 80%，Stable Difussion 推理场景下性能最高可提升 60%。

AIGC 场景下训练和推理最佳实践

在这里插入图片描述
上图展示的是关于 SD 文生图场景下的微调训练案例，我们可以通过 DeepGPU 和阿里云 GPU 云服务器结合在一起，在客户的 SD 微调场景下，帮助客户提升15%-40%的端到端性能。

第二个是关于大语言模型场景的微调案例，可以看到有些客户想做一个垂直领域/垂直场景下的大模型，会有模型微调的需求。针对这一类模型微调需求，我们会做一些针对性的解决方案/优化方案，客户通过软硬结合的优化方法，性能最高可提升80%。
在这里插入图片描述
最后是关于大语言模型推理的客户案例。这个客户主要是做智能业务问答/咨询类业务，我们为客户在端到端的场景里面提供了方案，包括云服务器、容器环境、AI 套件、DeepGPU 等产品，帮助客户优化整个端到端的推理性能，最终帮助客户提升近5 倍的端到端的请求处理/推理的效率。