前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >大规模(万卡)集群训练平台设计方案 MegaScale: Scaling Large Language Model Training 视频教程

大规模(万卡)集群训练平台设计方案 MegaScale: Scaling Large Language Model Training 视频教程

原创
作者头像
爱串门的小马驹
发布2024-07-11 07:16:04
690
发布2024-07-11 07:16:04
举报
文章被收录于专栏:大规模集群

一、为什么要万卡训练集群:

大语言模型贼牛逼这个就不强调了哈,机器翻译,人机会话表现出巨大潜力和应用价值。模型大小和训练数据大小决定了模型能力,为实现最先进的模型,人们已经致力于万亿tokens训练具有万亿参数的大型模型。这就需要建立具有数万个GPU的大规模人工智能集群来训练LLM(大语言模型)。

二、万卡训练集群的挑战:

1、实现大规模高训练效率;(能不能把万卡的算力有效利用起来)

2、实现大规模高稳定性训练;(卡太多每个都可能故障,很容易出现各种故障)

三、万卡训练集群设计原则:

1、算法-系统协同设计

2、减少通信量/时间,通信和计算重叠

3、不降低精度情况下,优化计算过程

4、深度可观测性

万卡训练集群设计需考虑因素:

1、算法

2、分布式并行方案

3、数据加载

4、网络与通信

5、底层算子

6、集群容错与性能监测

视频教程

1.1 大规模/万卡集群训练平台MegaScale的挑战、设计原则、考虑因素、出现原因MegaScale: Scaling Large Language_哔哩哔哩_bilibili

1.2 大语言模型LLM训练优化,并行注意力、滑动窗口、增加batchsize单次训练数据量,万卡加速训练MegaScale Scaling Large_哔哩哔哩_bilibili

1.3 万卡分布式训练,ZeRO数据并行优化 通信与数据加载并行_哔哩哔哩_bilibili

1.5 万卡训练 张量并行优化 数据切片计算通信并行 大规模集群_哔哩哔哩_bilibili

1.6 大规模训练数据加载优化,消除多余加载器,数据加载通信并行,万卡集群MegaScale_哔哩哔哩_bilibili 1.7 大规模集群训练、通信初始化优化、网络拓扑_哔哩哔哩_bilibili

1.8 大规模集群网络拥塞控制 ECMP PFC DCQCN NCCL通信超时重传_哔哩哔哩_bilibili

1.9 底层算子融合为什么能加速计算_哔哩哔哩_bilibili

1.10 万卡集群集群容错性能监控 心跳检测 自行诊断 故障恢复_哔哩哔哩_bilibili

视频教程还在持续更新中

4.1 LLM算法优化

在不影响模型精度的情况下进行算法优化,以实现大规模的高训练效率。

4.1.1 并行注意力机制( parallel attention)

添加图片注释,不超过 140 字(可选)

如上面公式(1)所示,Attention算完的结果作为LN输入,LN才算。LN算完之后作为MLP输入,MLP才算,这是一个串行的计算过程,

改进为公式(2),LN算完之后,MLP和Attention可以并行的算。因此,并行注意力可以减少计算时间。

视频教程:1.2 大语言模型LLM训练优化,并行注意力、滑动窗口、增加batchsize单次训练数据量,万卡加速训练MegaScale Scaling Large_哔哩哔哩_bilibili

4.1.2 滑动窗口注意力机制(Sliding window attention (SWA))

添加图片注释,不超过 140 字(可选)

由于一句话是一个时间序列,我们在根据已有序列预测下一个字时,越靠前的字与我要预测字的相关性越弱。我们可以设置一个窗口,窗口之前的单词我们就忽略不计算了,减少计算量。每预测出一个单词,窗口就往回移动一格,预测下一个,所以叫滑动窗口。

就比如说,“爱串门的小”,我们预测下一个字,我们可以直接利用整个序列“爱串门的小”预测出“马”字。我们用“爱”一个字就预测不出“马”,距离太远,相关性太弱。我们可以设置长度为4当窗口,用“串门的小”就预测出“马”字了,忽略“爱”,减少计算量。但我们把“马”字预测出来了,预测下一个字时,我们把“爱”和“串”字都忽略,直接用“门的小马”预测下一个字,这里窗口是不是就往后滑动一格,忽略了“串”字。所以叫滑动窗口。

4.1.3 LAMB优化器

大规模训练受到批量大小限制。特别是,增加批量可能会影响模型收敛。LAMB可以将批量大小扩展到4倍,而不会损失准确性。为什么增大一批次训练数据量会减少训练时间,哈哈哈,爱串门的小马驹,贴心的给大家画了个图(怎么这么贴心,不点赞说不过去了啊),如下图所示,训练同样的数据耗时:

添加图片注释,不超过 140 字(可选)

4.2 分布式训练方案

4.2.1 数据并行通信重叠

添加图片注释,不超过 140 字(可选)

添加图片注释,不超过 140 字(可选)

其实向Pytorch的DDP和FSDP已经做了训练与通信重叠,如上面的图所示,比如后向计算过程中,计算完一部分就通信Reduce-Scatter通信,这样,后续的后向计算过程中,同时进行通信,计算通信就重叠了。

但这样存在问题,就是我后向计算完成之后,还会进行一次Reduce-Scatter通信,前向计算开始之前,至少需要进行一次Allgather操作,才能进行进行计算,这两次通信时,计算通信是没有重叠的。

因此可以在这两次通信过程中,预加载数据,来让通信与数据加载重叠

视频教程:1.3 万卡分布式训练,ZeRO数据并行优化 通信与数据加载并行_哔哩哔哩_bilibili

4.2.2 流水线并行通信重叠

添加图片注释,不超过 140 字(可选)

前向流水并行时,当一个GPU计算完发送数据给下个GPU当同时,就进行下一次计算。发送数据就和前向计算重叠了,即。

哈哈哈,反向时是不是也可以用同样当技术啊,发送数据时就进行下一次反向计算。我看有的博文说,这里是将recv和backward,个人感觉不是啊,只有收到数据后才能进行计算,这里还是send和backward重叠。(哈哈哈,同学们要对自己有信心,要勇于挑战专家,错了就错了及时纠正就好。哈哈哈,如果是我爱串门的小马驹错了,大不了发视频道歉,承认自己菜

由于前向和反向计算相对独立,是不是可以让前向的recv接收和backwark反向计算重叠,后向计算的recv和前向计算过程重叠。这里不就是,recv和计算重叠了么。

4.2.3 张量并行通信重叠

添加图片注释,不超过 140 字(可选)

这里的核心就是张量并行时,对数据进行分片:(1)对于allgather通信部分,allgather第一个数据片就进行计算,这样后续计算就和通信并行起来;(2)对于Reduce-Scatter通信部分,计算完第一个部分就进行Reduce-Scatter通信,这样后续计算就和通信并行起来了。

视频教程:1.5 万卡训练 张量并行优化 数据切片计算通信并行 大规模集群_哔哩哔哩_bilibili

4.3 数据预处理和加载优化

4.3.1 异步数据预处理

异步数据预处理,训练完成通信同步梯度时,就开始数据预处理/加载。

4.3.2 消除冗余数据加载器

每个GPU都有自己的数据加载器,将数据先读到CPU内存。同一张量并行组,他们输入相同,因此将数据加载到CPU内存只需一个数据加载器,然后各个GPU加载数据到自己显存。

视频教程:1.6 大规模训练数据加载优化,消除多余加载器,数据加载通信并行,万卡集群MegaScale_哔哩哔哩_bilibili

4.4 通信初始化优化

集合通信组初始化,随着集群规模增大,耗时便的无法忽略,影响调参和调试。

(1)同步步骤中使用当阻塞是基于Pytorch内部实现的TCPStore,它单线程、阻塞读写方式运行。 将TCPStore替换为Redis,它是非阻塞异步的。

(2)减少非必要当全局barrier阻塞同步。

4.5 集群

4.5.1 集群拓扑

三层交换机以类似 CLOS 的拓扑结构连接,两层就是spine-leaf如图所示,三层如下图所示。

添加图片注释,不超过 140 字(可选)

添加图片注释,不超过 140 字(可选)

4.5.2 减少 ECMP 哈希冲突

ECMP(Equal-Cost Multi-Path routing)等价多路径负载均衡。就是比如现在有两条路径都可以到达,ECMP根据IP、端口号等计算一个哈希值(这个我们NCCL源码解读1里面有讲到)。

通过计算哈希值,确定走哪条路径。由于IP、端口号等完全一致,计算出的哈希值也一页,可以保证同一会话始终走同一路径,防止会话中断。

如何减少ECMP 哈希冲突,这玩意真不了解,后面有时间再调研调研。

4.5.3 拥塞控制

IB(Infiniband)不是贼贵么,而且还是私有协议,但确定快。以太网就参考它,搞了RoCE v2,参考IB继承了IB无损网络的约束,所有提出PFC(Priority-based Flow Control)。PFC当交换机缓存快溢出的时候,直接就通知上游端口,粗暴的暂停任何数据发送。

DCQCN(Data Center Quantized Congestion Notification)就出生,DCQCN涉及三个东西,发送方网卡,交换机,接收方网卡。

1、交换机缓存不够了,按拥塞程度以概率给要转发的数据包打上标记,表示交换机快不行了。

2、接收网卡收到带标记的数据包,知道交换机快不行了,发送数据包给发送方网卡。

3、接收网卡收到交换机快不行的数据包,根据概率,减缓发送。一段时间没收到交换机快不行的包,开始提速。

4.5.4 超时重传设置

NCCL中的参数可以设置控制重传定时器和重试计数,NIC网卡自适应重传使能。

4.6 底层算子

添加图片注释,不超过 140 字(可选)

算子融合,优化计算过程。就比如说,上面的第一个计算,原本X是要进行两次乘法得到Y,先乘以2再乘以4,算子融合,X乘以8一次搞定,减少计算量。

算子融合不仅可以优化计算计算过程,有时也可以优化读写过程。比如上面的第二个计算,第一次读取X乘以2得到结果,再读取X加上结果得到Y,融合后只读取一次X就搞定了。

4.5 集群容错

1.10 万卡集群集群容错性能监控 心跳检测 自行诊断 故障恢复_哔哩哔哩_bilibili

添加图片注释,不超过 140 字(可选)

4.5.1 心跳检测

心跳消息监测异常,发现异常发出早期警告。

毫秒级监测:IP地址、Pod名称、硬件信息、训练状态、RDMA流量发现错误或者流量异常立即警报。

4.5.2 自行诊断

轻量级软硬件故障诊断,快速自动定位问题。

主机内网测试:(1)RDMA网卡到主机内端点(内存节点和GPU)带宽测试。

(2)同一主机上不同RDMA网卡之间的连接和带宽测试。

NCCL测试: (1)服务器内GPU之间alltoall测试。

(2)同一交换机下服务器allreduce测试

注:用Allreduce也可以测不同底层通信算子,reduce类通信和alltoall等非reduce类底层通信算子和协议不同。

4.5.3 故障恢复

双阶段checkpoint快速保存和调用

两阶段快速Checkpoint保存:第一阶段Checkpoint写入主机内存;

第二阶段模型训练同时, Checkpoint由内存写入HDFS。

两阶段快速Checkpoint调用:第一阶段单个GPU从HDFS读取Checkpoint;

第二阶段,广播给所有其它所有需相同数据的GPU。

4.5.4 性能监控可视化

性能监控需注意GPU与GPU的依赖关系,不是直接通过GPU运行的快慢来确定GPU的性能。当GPUA的输入是GPUB给的时候,可能是GPUA自己慢自己性能差,也可能是GPUB慢导致GPUA看起来运行慢。

添加图片注释,不超过 140 字(可选)

添加图片注释,不超过 140 字(可选)

结论:

在模型训练精度不变的情况下,实现了55.2%的算力利用率Model FLOPs Utilization (MFU),与最先进的开源训练框架Megatron LM相比,提升了1.34倍。

添加图片注释,不超过 140 字(可选)

添加图片注释,不超过 140 字(可选)

添加图片注释,不超过 140 字(可选)

原文链接:

[2402.15627] MegaScale: Scaling Large Language Model Training to More Than 10,000 GPUs (arxiv.org)

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、为什么要万卡训练集群:
  • 二、万卡训练集群的挑战:
  • 三、万卡训练集群设计原则:
  • 万卡训练集群设计需考虑因素:
  • 视频教程
  • 4.1 LLM算法优化
  • 4.1.1 并行注意力机制( parallel attention)
  • 4.1.2 滑动窗口注意力机制(Sliding window attention (SWA))
  • 4.1.3 LAMB优化器
  • 4.2 分布式训练方案
  • 4.2.1 数据并行通信重叠
  • 4.2.2 流水线并行通信重叠
  • 4.2.3 张量并行通信重叠
  • 4.3 数据预处理和加载优化
  • 4.3.1 异步数据预处理
  • 4.3.2 消除冗余数据加载器
  • 4.4 通信初始化优化
  • 4.5 集群
  • 4.5.1 集群拓扑
  • 4.5.2 减少 ECMP 哈希冲突
  • 4.5.3 拥塞控制
  • 4.5.4 超时重传设置
  • 4.6 底层算子
  • 4.5 集群容错
  • 4.5.1 心跳检测
  • 4.5.2 自行诊断
  • 4.5.3 故障恢复
  • 4.5.4 性能监控可视化
  • 结论:
  • 原文链接:
相关产品与服务
应用性能监控
应用性能监控(Application Performance Management,APM)是一款应用性能管理平台,基于实时多语言应用探针全量采集技术,为您提供分布式性能分析和故障自检能力。APM 协助您在复杂的业务系统里快速定位性能问题,降低 MTTR(平均故障恢复时间),实时了解并追踪应用性能,提升用户体验。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档