技术分享 | 如何利用 GPU 云服务器加速 AIGC 训练

2023-07-13
北京
本文字数：5755 字
阅读完需：约 19 分钟

2023 年 7 月 5 日，阿里云弹性计算团队与智东西公开课联合出品的系列课程【阿里云弹性计算技术公开课】正式播出，当前系列课程共分为七节，阿里云高级开发工程师于子淇作为第三位课程主讲人，带来了主题为《如何利用 GPU 云服务器加速 AIGC 训练》的课程分享，本次课程同步在阿里云官网、钉钉视频号、阿里云微信视频号、阿里云开发者微信视频号、阿里云创新中心直播平台 &视频号等多平台同步播出。

阿里云 GPU 云服务器提供 GPU 加速计算能力，能够实现 GPU 计算资源的即开即用和弹性伸缩。同时，配备阿里云自研的弹性 RDMA 网络，可以实现秒级的大规模 RDMA 组网，满足大模型计算过程中海量数据的高效传输需求。面向开发者，阿里云还推出了 AI 计算部署工具 FastGPU，使开发者无需关注计算、存储、网络等资源的部署操作，即可达到简单适配、一键部署、随处运行的效果。

【完整课程直播】

本篇文章根据于子淇的课程整理而成，供读者阅览：

大家好，我是来自阿里云弹性计算团队的高级开发工程师于子淇，本次给大家分享的内容的主题是：如何利用 GPU 云服务器加速 AIGC 训练，这个分享比较偏向于实践，重点会讲一下神龙 AI 训练加速套件 AIACC 2.0 在大模型上的优化案例。

一、LLM 模型的实现原理以及典型模型

现如今大模型和 AIGC 是比较火的话题，拥有较大的使用场景，比如通义千问、ChatGPT、智能对话机器人等等，这些是能够产生实际落地价值的，更贴进大众的生活，所以大模型会是未来 AI 发展的一个主航道。

提到 AIGC，全称是 AI Generated Content，是指 AI 内容生成，本质上是一种生成式 AI。它所覆盖的范围比较广，包括 LLM，即大语言模型。从广义上来讲，大语言模型就是从大规模数据集上进行自监督训练，参数量级在 10 亿、百亿甚至更多。这种语言模型训练任务可以分为以下两个部分：

· Pretrain：大量数据提取共性特征，作为不同场景的基础模型，它的定位是通用性，对训练资源要求比较高，也是各大公司想要实现通用基础模型的必要途径；

· Finetune：少量数据适应特定领域模型，它面向的是下游任务，定位在于特定性，这个在目前这种大语言模型场景下对训练要求也很高，也是各个公司希望基于自己已有的基础模型和特有数据集，做定制化产业升级和创新应用开发的实现方式。

LLM 模型实现的架构包括 encoder 和 decoder，由上图右侧结构图所示，这是目前主流的大语言模型的发展方向。左边子图是 encoder only 的结构，比如传统的 bert 模型；中间子图的是 encoder-decoder，也就是最原始的 transform base 的模型，比如 T5 模型；右侧子图是 decoder only 的结构，这个模型结构应用比较多的场景，比如 Open AI 始终坚持的 GPT、ChatGPT 以及 Meta 实现的 LLaMA 等等。从上图右侧树图能够看出，主流的架构趋势是 decoder-only。

说到大语言模型，不可避免的话题就是扩展性的问题。这个扩展性可能会有多个维度，包含数据集和模型的参数量。横坐标是模型的参数量规模，纵坐标是模型的精度、表现能力，按照之前的扩展定律来看是近似线性的，这个也好理解，参数量越大，模型越准确，但最新的研究表明，在有一些任务上，模型在没有达到阈值规模之前，效果接近于随机，而达到阈值之后，性能大幅提高，也就是规模越大，才真正解锁了大语言模型的潜在能力，比如具体在 10B-100B 提升最明显。到此为止，我们总结为，大模型参数在 10B+的参数量级，也就是百亿以上。

接下来我们来看下具体的训练细节。

模型的实现，主流是基于 transformer-base 的 decoder-only 架构。如上图右侧所示，这个是 Google 提出的标准 transformer-base 模型，即 encoder-decoder，但前面提到大多都采用 decoder-only 架构，也就是红色框部分。

因为训练效率上来看 decoder-only 只有一半的模型架构，所以在效率和工程实现上都是较优的，比如 encoder-decoder 还需要做复杂的数据切分，无法满足通用的大语言模型训练；在任务效果表现上 zero-shot 的自监督训练（即无任何 tuning 数据）decoder-only 也是表现最好，并且数学推导来看 decoder-only 一般为三角阵，三角阵是满秩的，表达能力更强。

在并行策略上往往是我们做训练重点关心的地方，有多种并行方式，比如数据并行 DP、DDP、DeepSpeed-zero123，张量并行 TP、流水并行 PP，不同的切分会决定不同的通信方式，比如 DDP 主要是 allreduce；主流框架包括 DS、FSDP/megatron、colossalAI 等。

开源的模型有很多，LLAMA、chatGLM、GPT3 等，比较火的当属 LLaMA 了，下面是 Llama-13B+zero3 的训练方式，多个 GPU 之间不在是传统的单个 allreduce 集合通信了，而是换成了 allgather 和 reduce-scatter，因为本质上这两个算子的组合就是等价于一个 allreduce 算子，因为 zero3 的并行切分，拆解为 2 个通信算子之后，中间冗余的 parameter、gradient、optimizer-states 等 buffer 的冗余占用就可以释放，从而达到降低显存的效果，满足中大模型的承载能力，提高整体的吞吐性能。

当然，虽然看起来 zero 主要是做了显存的优化，但变相提高了计算效率，这就带来较大的通信压力，通信占比在 2 机场景下达到 30%以上，对于传统的 TCP/IP 的网络来说压力会很大，容易成为性能瓶颈，降低 GPU 利用率。

这就是大语言模型其中一个痛点，那么如何降低这种通信瓶颈呢？下面将介绍阿里云 eRDMA 的 GPU 实例。

二、基于阿里云 eRDMA 的 GPU 实例

eRDMA 也就是 elastic（弹性）RDMA。通过下图我们看一下 RDMA 的技术演进。

如左侧图所示，传统 TCP/IP 涉及到多层数据包的解析，需要走 CPU 进行数据搬移，这个会带来较大延迟，降低带宽表现。传统 TCP/IP 网络较慢，可能影响不大，但现在网络提速之后，CPU 的 overhead 就不可忽略了。

中间的图是 RDMA 的实现方式，应用层可以通过网卡直接完成数据搬移，bypass 了用户态和内核态的切换以及 CPU 搬移，只需要 CPU 发起数据通信的请求，由 RDMA 的 engine 来完成数据通信，CPU 只是被告知完成，从而大幅提高通信性能。

eRDMA 特性包括：

· RDMA 的生态兼容，无需修改任何代码，二进制兼容，通过标准的 verbs API 即可调用；

· 超大规模组网能力，支持 10 万级别 VM 组网以及跨 AZ 组网；

· 基于 ECS 的 VPC 网络，能够满足极致的弹性和多租户隔离。

从硬件角度的一些指标来看，带宽 200Gbps、时延最低 8µs、吞吐 30M message/s。

硬件架构上，为了满足大模型 transformer-base 对计算和承载能力的要求，GPU 采用 80GB 的 8 卡 A100，单机内部为 nvlink600GB/s 的高速带宽，节点间走 eRDMA 互联，能够提供最大 2x100G 带宽，并且实现跨 socket 均衡，即单机内部每 4 张 GPU 卡共用 100G 带宽；当然 200G 是 EBS/VPC/ERDMA 融合后共享带宽，所以实际分到的数据流带宽会小一些。

上图是 AI 训练场景的典型架构，eRDMA 位于底层通信链路，对上层应用提供无感加速能力，比如在 nccl 的场景下，无需任何修改，自动适配 eRDMA 通信协议。

下图是 eRDMA 实例相比传统 64G VPC 机型的性能提升，可以看到性能提升是比较明显的。整体带宽提升了一倍，延迟降低了 80%。

右边的数据图是 ebmgn7ex 相比 ebmgn7e 4 机训练性能提升比例，提升比例也很明显。

三、FastGPU 一键部署 LLaMA 流程以及 finetune 原理解析

这部分将介绍一键部署 LLaMA 流程，也就是前面提到的大语言模型及 finetune 原理解析。

FastGPU 是一款针对阿里云 IaaS 资源的快速管理工具，可以将环境部署时间大幅缩短，变相节省了 GPU 资源的费用，面向各类开发者提供 IaaS 资源的易用性，可以提高开发者的效率。具体的细节就是从用户使用角度，通过 FastGPU 管理集群，或是控制当前集群的一些资源创建和释放等等，感兴趣的话可以在阿里云官网上查看了解。

上图为一键部署的流程。通过 FastGPU 一行命令，完成集群的创建、环境部署、LLaMA 模型训练以及推理服务构建的流程，这里是演示作用，因为 A100 资源较为紧缺，所以使用的是 V100 实例。两张图分别是 baseline 性能以及使用了 AIACC 之后的性能，从吞吐量来看 AIACC 性能提升 40%，具体 AIACC 是什么我们后面再展开。

访问推理服务，只需要打开浏览器输入本地的某个端口服务即可，因为 FastGPU 已经内部实现了 IP 白名单+端口转发到本地的功能，通过快速试用方式来大幅降低大模型的使用门槛。

下面分享 LLaMA 流程细节。

LLaMA 是 META 提出的对标 OpenAI 的 ChatGPT 的开源版本，提出的背景就是通过模型的性价比去降维打击。所谓模型性价比就是参数量和训练 tokens 的关系，右边这个图是实验验证扩展性的特点。汇总下来 LLAMA 提出的 2 个角度：

· 一个是训练质量保证，需要通过匹配最佳的数据集和模型大小来满足 scaling 扩展定律；

· 另外一个容易忽略的点，就是推理效率，降低模型参数量，通过更大的训练时间来保证相同的精度效果，从而推理时候可以在更小的模型上来降低推理部署的成本。

LLaMA 的模型结构，其实是基于 transformer-base 的实现，吸取了不同模型实现的优化点，比如 RMS 预先归一化（即在 norm 的输入层进行归一化而非输出层）、swiglu 激活、RoPE 旋转嵌入替代绝对编码。

所以 LLaMA 模型核心部分可能是通过完备的扩展性去实现模型效果的提升，最终 LLaMA 的效果上是比较惊人的，相比 GPT3 的 175B 模型，LLaMA-13B 基本持平 GPT3 的效果，而参数量只有不到十分之一，即便是 7B 也不会比 GPT3 差太多。

那么具体 finetune 是如何进行呢？

Finetune 主要是一种小样本训练，在 zero-shot、few-shot 场景下进行的，本质上就是减少人工标注的语料，简单理解为自监督或无监督训练，下游任务有常识推理、问答、阅读理解、数学推理、代码生成等等。

finetune 有多种类别，比如 prompt-tuning 为每个任务拼接 emb 层来训练 emb；prefix-tuning 利用 MLP 多层感知机来训练；p-tuning 引入 LSTM 训练等等。

上图主要以 LLaMA 系列的 alpaca 模型为例，Alapca 是斯坦福提出的，使用 self-instruction 进行微调。所谓的 self 就是指通过已有的强大的语言模型生成指令数据，然后进行全量 finetune 训练。

Alpaca 是通过 OpenAI 的 GPT3.5 生成了 52k 的训练数据，具体如上图右侧所示。

从 self-instruct 集合中生成 175 个由人类撰写的高质量指令-输出 pair 对，主要是规范一些期望输出的模版，然后这些作为种子集合输入到达芬奇 03 版本模型，生成更多的指令；最后就是把生成的 52k 高质量的数据用于 LLaMA,做有监督的 finetune 训练，生成最终的 Alpaca 模型。

本质上 self-instruct 就是让更高级的大语言模型去调教新模型，来达到“听话”的效果。

下面看一下推理的实际效果。

上图是开源的 WebUI 对话界面，这是没有 finetune 训练之前的基础 LLaMA 模型效果，输入的问题是你作为一名老师，教我如何学习人工智能，回答如右框所示，可以看到他的回答第一句就是不理解 teach 教学这个词的意思。这个就是原始模型在大规模语料下可能会存在的问题，生成结果文不对题，也就无法正确的生成结果。

接下来我们看 finetune 之后的结果，相同的问题，回复内容的确是像老师的口吻直接讲学 AI 的价值和课程重要性，效果较为符合预期。

具体的 AIGC 一键部署可以参考阿里云 AIGC 试用的文档，里面介绍了基于阿里云 GPU 云服务器快速搭建各种不同的 AIGC 应用，比如 stablediffusion 文生图、LLaMA 指令微调等超多应用。

欢迎大家快速部署体验，可以直接浏览器搜索“阿里云 AIGC GPU 试用”这几个字即可进入。

四、基于 AIACC 的性能优化及效果展示

接下来分享 AIACC 的加速原理。

我们团队之前在 AIACC1.5 的版本拿过 DawnBench 竞赛的四项世界第一，训练部分性能最快，成本最低。还有推理同学拿到了推理性能最快、成本最低的奖项。

目前更新为 2.0 版本，下图是 AIACC-Training 2.0 的架构，主要包括 ACSpeed 通信优化以及 AGSpeed 计算优化。

上图分割线上方为通信优化，ACSpeed 实现为模块化的解耦设计，在兼容性、适用性和性能优化方面全面升级，从 AI 框架到 nccl runtime 以及协议栈侧均实现为 plugin 或者 backend 的方式，从而实现无感 IaaS+的中间件支持。

下面是 AGSpeed 计算优化，主要针对 pytorch 动态图特效，实现计算图编译优化，这里也分为 compiler 的前后端，前端实现动态到静态图的转换，后端实现 pass/tensor 等编译优化，从而加速训练的计算过程。

通信优化的背景是，分布式训练在多机场景下的通信带宽成为训练瓶颈。因此 ACSpeed 实现 c10d-plugin、nccl-runtime 的方式进行无感优化分布式训练，针对阿里云 VPC 网络基础设施在分布式场景下进行深度优化，并且针对 CIPU 提供网络层增强，即前面提到的 eRDMA 实例，传统使用 IB 网络的方式较为繁琐，包括 GID、HCA 等设置，通过 nccl-plugin 极大增强了易用性，目前已经集成到 eRDMA 大包驱动内部，用户可以完全无感使用 eRDMA 的网络能力。

上图框架图上画的有 Pytorch 和 TensorFlow 不同路径，主要是因为使用 Pytorch 客户较多，所以针对 Pytorch 做了定制的优化，可以一行代码修改快速优化 DDP 以及 FSDP 等不同的训练方式，对模型侧无感，即便不是 Pytorch，底层都是基于 NCCL 做通信的话也都可以直接走第二层 nccl-runtime 以及 nccl-plugin 获取纯通信优化。

目前算法层面实现了常用的 allreduce、allgather、reduce-scatter、reduce 等集合通信算法的优化版本，极大提升在阿里云 GPU 实例下的性能表现。

接下来是 AGSpeed 计算图的编译优化。

AGSpeed 计算图编译优化，主要背景也是 Torch 的火热程度，所以我们针对 Pytorch 进行计算图的定制优化，增强前后端覆盖度，保证训练 e2e 功能和性能。

· 前端引入并优化 Torchdynamo graph catch 机制/通过 online autotune 保障覆盖度和 SLA 的鲁棒性；

· 后端引入并优化 Nvfuser、inductor 等多种 optimizer，通过 plugin 方式增强编译优化性能。

上图是 AIACC2.0 的性能优化结果，左边是单独开启 ACSpeed 的性能，相比 DDP 提升 5-150%；右边是单独开启 AGSpeed 的性能，相比 Pytorch 提升 5-50%。

如果是单独只使用 nccl-runtime 以及 nccl-plugin 的通信优化，性能 SLA 主要是 nccl-test，是经典测试 GPU 多机多卡通信的 benchmark，下图展示的是 allgather 算子在两机 eRDMA 机型下的性能提升，在 30-100%，在端到端场景下会根据不同通信占比进行折算。

比如在某实际客户的某 A100 机型的 2 机场景下，Llama13B + zero3 的模型实现，集合通信使用的是 allgather+reduce-scatter 算子，通信压力较大，通过一行代码 import aiacc 后即可使能 AIACC 优化，集合通信部分替换为 aiacc_allgather 和 aiacc_reduce_scatter 算子，最终端到端的 llama13B 训练性能提升 37%。