本文来源于阿里云社区电子书《阿里云产品四月刊》
《阿里云产品四月刊》—一文解读：阿里云 AI 基础设施的演进与挑战（1）https://developer.aliyun.com/article/1554151
如何释放云上性能？
对于大模型训练的技术栈，由 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%。
《阿里云产品四月刊》—一文解读：阿里云 AI 基础设施的演进与挑战（3）https://developer.aliyun.com/article/1554149
