关于人工智能:大模型时代的异构计算平台

导读 

本文整顿自 2023 年 2 月 QCon 寰球软件开发大会（北京站）AI 基础架构专题的同名主题分享。

ChatGPT、Bard 以及将和大家见面的“文心一言”等利用，均是基于各厂商本人推出的大模型进行构建。GPT-3 有 1750 亿参数，文心大模型有 2600 亿参数。

以应用 NVIDIA GPU A100 对 GPT-3 进行训练为例，实践上单卡须要消耗 32 年的工夫，千卡规模的分布式集群，通过各种优化后，依然须要 34 天能力实现训练。

此次演讲介绍了大模型的训练对基础设施的挑战，比方算力墙、存储墙、单机和集群高性能网络设计、图接入和后端减速、模型的拆分和映射等，分享了百度智能云的应答办法和工程实际，构建了从框架到集群、软硬联合的全栈基础设施，减速了大模型端到端训练。

近两年对 AI 技术架构影响最大的就是大模型。在大模型产生、迭代和演进的过程中，它对底层的基础设施提出了新的挑战。

明天的分享次要分为四个局部，第一局部是从业务视角来介绍大模型带来的要害变动。第二局部分享是在大模型时代，大模型训练对基础设施提出的挑战以及百度智能云的应答办法。第三局部是联合大模型和平台建设的需要，解说百度智能云所做的软硬联合的联结优化。第四局部则是百度智能云对大模型将来的倒退、对基础设施新要求的一些思考。

一、GPT- 3 开启大模型时代

大模型时代是由 GPT-3 开启的，该模型有如下几个特点：

第一个特点是该模型的参数有极大的晋升，单个模型达到了 1750 亿的参数，这也带来了准确性的大幅晋升。从右边图中咱们能够看到，随着模型参数越来越多，模型的准确性也在一直晋升。

左边图则展现了它更令人震惊的特点：基于预训练好的 1750 亿参数的模型，只须要通过大量样本的训练，就能够靠近 BERT 应用大样本训练后的成果。这在肯定水平上反映了模型的规模变大，就能够带来模型性能和模型通用性上的晋升。

除此之外，GPT-3 还在数学计算、浏览了解、多轮问答等工作上均体现出了肯定的通用型，仅通过大量样本就能够让模型达到较高的、甚至近似于人类的准确度。

正因而，大模型也给 AI 整体研发模式带来了新的变动。在将来，咱们可能会先预训练一个大模型，再针对具体的工作，通过大量的样本做 Fine-tune，就能够失去不错的训练成果。而不须要像当初训练模型时，每个工作都须要从零开始，残缺地做迭代和训练。

百度很早就开始训练大模型，领有 2600 亿参数的文心大模型就是在 2021 年公布的。当初随着 Stable Diffusion、AIGC 文生图，以及最近大火的聊天机器人 ChatGPT 等受到整个社会的关注，让大家真正意识到大模型时代到了。

各厂商也在布局大模型相干的产品，Google 此前刚公布了 Bard，百度也行将在 3 月份推出“文心一言”。

大模型训练到底有什么不同的特点呢？

大模型有一个 Scaling Law，如右边图所示，随着模型的参数规模和训练数据越来越多，成果就会越来越好。

但这里有个前提，参数肯定要足够大，并且数据集足以撑持整个参数的训练。而这带来结果就是计算量呈指数回升。对于一个一般的小模型来说，单机单卡就能够搞定。但对于大模型来说，它对训练量的要求就须要有大规模的资源去撑持它的训练。

以 GPT-3 为例，它是一个有 1750 亿参数的模型，须要 3000 亿条词语的训练能力撑持它达到一个不错的成果。它的计算量在论文外面评估是 314 ZFLOPs。比照 NVIDIA GPU A100，一张卡还是只是 312 TFLOPS 的 AI 算力，这两头相对数值相差了 9 个数量级。

所以为了更好地反对大模型的的计算、训练和演进，如何去设计、开发基础设施就成了十分重要的问题。

二、大模型基础设施全景图

这是百度智能云面向大模型的基础设施全景图。这是一个笼罩了从框架到集群，软硬联合的全栈基础设施。

在大模型中基础设施不再仅仅涵盖底层的硬件、网络等传统的基础设施。咱们还须要把所有的相干资源都纳入到基础设施的领域之中。

具体来说，它大略分为几个层级：‍‍

• 最下面的是模型层，包含内外部公布的模型和一些配套组件。比方百度的飞桨 PaddlePaddle 和 Fleet，Fleet 是在飞桨上做的分布式策略。同时在开源社区，比方 PyTorch 有 DeepSpeed/Megatron 等一些基于 PyTorch 框架做的大模型训练的框架和减速能力。
• 在框架之下咱们还会做减速库的相干能力，包含 AI 算子减速、通信减速等。
• 再上面是一些偏资源管理或者偏集群治理的相干能力。
• 最底下是硬件资源，比方单机单卡、异构芯片、网络相干的能力。

以上就是整个基础设施的全景。明天我会先重点从 AI 框架动手，接着再延长到减速层和硬件层，分享百度智能云的一些具体工作。

首先从最下面的 AI 框架动手。

对于传统的在单卡上进行的小模型训练，咱们应用训练数据不停做前向、反向梯度更新就能够实现整个训练。 而大模型的训练，次要存在两点挑战：算力墙和存储墙。

算力墙指的是如果要实现 GPT-3 这种须要 314 ZFLOPs 算力的模型训练，而单卡只有 312 TFLOPS 算力时，咱们如何通过分布式的办法去突破单算力工夫太长的问题。毕竟一张卡训练一个模型耗时 32 年，显著是不可行的。

其次是存储墙。对大模型来说这是更大的挑战。当单卡放不下模型的时候，模型肯定要有一些切分的办法。

举个例子，千亿级别大模型的存储（包含参数、训练两头值等）须要 2 TB 的存储空间，而单卡的显存目前最大只有 80 GB。因而，大模型的训练须要一些切分策略以解决单卡放不下的问题。

首先是算力墙，即解决单卡算力有余的问题。

一个很简略也是大家最相熟的想法就是数据并行，将训练样本切到不同的卡上。整体来说，咱们当初察看到的大模型训练过程中，次要采纳的是同步的数据更新策略。

重点来说说存储墙问题的解决。其中要害就是模型切分的策略和办法。

第一个切分办法是流水线并行。

咱们用下图的例子来做一个阐明。对于一个模型来说，它是由很多层组成的，训练时先做前向，再做反向。比方图中 0、1、2 三层在一张卡上放不下，咱们按层进行切分后，会把这个模型中的某些层放到第一张卡上。比方下图中，绿色区域代表 GPU 0，红色区域代表 GPU 1。咱们能够将前几层放到 GPU 0 上，其余几层放到 GPU 1 上。数据在流动的时候，会先在 GPU 0 上做两次前向，而后在 GPU 1 上做一次前向和一次反向，再返回到 GPU 0 上做两次反向。因为这个过程特地像流水线，所以咱们把它叫做流水线并行。

但流水线并行有个次要的问题，即流水线气泡。因为数据间会存在依赖关系，梯度依赖于后面层的计算，所以在数据流动的过程中，就会产生气泡，也就造成了空等。针对这样的问题，咱们通过调整不同 mini-batch 的执行策略来缩小气泡的空等工夫。

下面是算法工程师或者框架工程师的视角来看该问题。而从基础设施工程师的视角来看，咱们更关注的是它会给基础设施带来何种不同的变动。

这里重点关注它的通信语义。它在前向和反向之间，它要传递本人的激活值和梯度值，这就会带来额定的 Send/Receive 操作。而 Send/Receive 是点到点的，咱们在后文中会提到应答的方法。

以上就是第一种突破存储墙的并行模型切分的策略：流水线并行。

第二种切分办法是张量并行， 它解决的是单层参数过大的问题。

模型尽管有很多层，但其中某一层的计算量很大。此时咱们冀望将这一层的计算量在机器之间或者在卡间进行独特计算。从算法工程师的视角来看，解决的办法就是将不同的输出切分成几块，而后别离用不同的块别离做局部计算，最初再做聚合。

但从基础设施工程师的视角来看，咱们还是关注这个过程中引入了哪些额定的操作。刚刚提到的场景中，额定操作就是图中的 f 和 g。f 和 g 别离代表的什么意思？在做前向的时候，f 是一个不变的操作，通过 f 把 x 透传过来，前面做局部的计算即可。但在最初做后果聚合的时候，还须要把整个数值持续往下传递。对于这种状况，就要引入 g 的操作。g 就是 AllReduce 的操作，它在语义上就是将两个不同的数值做一次聚合，以保障输入 z 在两张卡上都能拿到雷同数据。

所以从基础设施工程师的视角来看，就会看到它引入额定的 AllReduce 的通信操作。该操作的通信量还是比拟大的，因为外面的参数规模比拟大。咱们在后文中也会提到应答的办法。

这是第二种能够突破存储墙的优化办法。

第三种切分办法是分组参数切片。 该办法在肯定水平上缩小了数据并行中的显存冗余。传统的数据运行中，每张卡都会有本人的模型参数和优化器状态。因为它们在各自的训练过程中还须要做同步和更新，这些状态在不同卡上都有残缺备份，

对于上述过程，其实就是同样的数据和参数，在不同的卡上做了冗余的存储。因为大模型对存储空间要求特地高，所以这样的冗余存储是不可承受的。为了解决这个问题，咱们将模型参数做了切分，每张卡上只保留一部分参数。

在真正须要计算的时候，咱们用工夫换空间：将其中的参数先做同步，等计算实现之后，再抛弃这些冗余数据。通过这种形式能够进一步压缩对显存的需要，能够更好地在现有的机器上做训练。

同样，站在基础设施工程师的视角来看，咱们就须要引入 Broadcast 这样的通信操作，通信的内容就是这些优化器的状态与模型的参数。

以上就是第三种突破存储墙的优化办法。

除了下面提到的显存优化的办法和策略之外，还有一种办法是缩小模型的计算量。

当数据量足够大的时候，模型的参数越多，模型的精度越好。然而随着参数的减少，计算量也随之减少，就须要更多的资源，与此同时计算的工夫也会更长。

那如何保障在参数规模不变的状况下缩小计算量呢？其中一个解决方案就是条件计算：依据肯定的条件（即右图中的 Gating 层，或者称为路由层），去抉择激活其中局部参数。

举个例子，在右侧图中，咱们将参数切分为三份，样本依据模型的条件，只激活局部的参数来在专家网络 2 中进行计算。而专家 1 和专家 3 中的局部参数则不做计算。这样就能够在保障参数规模的同时，缩小其中的计算量。

以上就是基于条件计算的形式来缩小计算量的办法。

业界基于上述办法，咱们提出了混合专家的模式 ，就是将模型形象为多个专家，每张卡解决其中不同的样本。具体来说就是在模型层插入了一些路由的抉择，而后依据这种抉择只激活其中的一部分参数。同时，不同的卡上会保留不同专家的参数。这样，在样本散发的过程中就会分到不同的卡下来做计算。

然而站在基础设施工程师的视角来看，咱们发现这个过程中引入了 All2All 的操作。如下方右图所示，在多个 Device 上，存储了 0、1、2、3 这样的样本。Device 外面的数值则示意适宜被哪张卡来计算，或者说它适宜被哪个专家来计算。比方 0 示意适宜被 0 号专家，也就是 0 号卡来计算，以此类推。每张卡均会去判断存储的数据别离适宜被谁来计算，比方 1 号卡，它判断出局部参数适宜被 0 号卡计算，另一部分参数适宜被 1 号卡计算。而后下一个动作就是把样本散发到不同的卡下来。

通过如上操作之后，0 号卡上全为 0 的样本，1 号卡上全为 1 的样本。以上过程在通信里就叫 All2All。这个操作从基础设施工程师的视角来看是一个比拟重的操作，咱们须要在此基础上做一些相干的优化。咱们在后文中也会有进一步介绍。

在这个模式里，咱们察看到的一个景象是，如果采纳混合专家的模式，它在同样参数的模型下，训练的精度不如方才提到的各种并行策略、混合叠加策略好，大家须要依据本人的理论状况来酌情抉择。

刚刚介绍了几种并行策略，接下来分享下百度智能云的一个外部实战。

咱们用飞桨训练了一个有 2600 亿参数的大模型，重叠了一些优化过的 Transformer 类的层。咱们能够依照横切竖切的形式给它做一个切分，比方竖切就是采纳流水线并行策略将模型按 Transformer 层进行切分。横切则是采纳模型并行策略 / 张量并行策略对 Transformer 外部的 MetaMul 这种大的矩阵乘的计算做切分。同时咱们再辅以数据并行的纵向优化，以及配合在数据并行上做的分组模型参数切分的显存优化。通过如上四种形式，咱们推出了飞桨的 4D 混合并行训练的框架。

在千亿参数模型的训练配置上，咱们采纳机内八卡做张量并行，同时配合数据并行进行一些分组参数切分操作。同时还应用多组机器组成流水线并行，以此来承载 2600 亿的模型参数。最初，再利用数据并行的形式进行分布式计算，从而实现模型的月级别训练。

以上就是咱们整个的模型并行参数模型并行策略的一个实战。

接下来，让咱们再回到基础设施的视角，评估模型训练中不同的切分策略对通信和算力的需要。

如表格所示，咱们依照千亿参数的规模，列出了不同切分形式所需的通信量和计算工夫。从整个训练过程来说，最好的成果是计算过程和通信过程能够齐全笼罩，或者相互重叠。

从这张表格中，咱们能够推算出千亿参数模型对集群、硬件、网络，包含整体通信模式上的需要。依据估算 1750 亿参数的模型在 1024 张 A100 卡上应用 3000 亿词语进行训练，须要 34 天就能够实现残缺的端到端训练。

以上就是咱们对硬件侧的评估。

有了硬件的需要，接下来就是单机和网络层面的选型。

在单机层面，因为须要在机内做大量的 AllReduce 和 Broadcast 操作，咱们心愿机内能够反对高性能，高带宽的连贯形式。所以咱们在选型中采纳了过后最先进的 A100 80G 的套餐，采纳 8 张 A100 组成单机。

此外，在内部的网络连接形式中，最重要的就是拓扑的连贯形式。咱们心愿网卡和 GPU 卡之间能尽可能在同一个 PCIe Switch 下，通过对称的形式能够更好地缩小整个训练过程中卡之间交互的吞吐瓶颈。同时也要尽量避免它们通过 CPU 的 PCIe Root Port。

说完单机，咱们再来看看集群网络的设计。

首先咱们先评估下需要，如果咱们对业务的预期是在一个月之内实现模型的端到端训练，就须要单作业训练中达到千卡级别，大模型训练集群达到万卡级别。因而，在网络设计的过程中，咱们应该兼顾两个点：

第一，为了满足流水线中的 Send/Receive 这种点到点的操作，须要缩小 P2P 的提早。

第二，因为 AI 训练中网络侧流量集中于同号卡 AllReduce 操作，咱们还心愿它有很高的通信吞吐。

针对这种通信需要。咱们设计了左边所示的三层 CLOS 架构的拓扑。这种拓扑跟传统形式相比，最重要的是做了八导轨的优化，让任一起号卡在不同机器中的通信中的跳步数尽可能少。

在 CLOS 架构中，最底下的一层是 Unit。每个 Unit 中有 20 台机器，咱们将每台机器中的同号 GPU 卡连贯到与对应编号的同一组 TOR 上。这样单个 Unit 内的所有同号卡，只须要一跳就能够实现通信，能够很好地晋升同号卡之间的通信。

然而，一个 Unit 中只有 20 台机器共 160 张卡，这个规模是达不到大模型训练要求的。所以咱们又设计了第二层 Leaf 层。Leaf 层将不同的 Unit 中的同号卡连到同一组 Leaf 的替换设施上，解决的仍然是同号卡互联的问题。通过这一层，咱们能够将 20 个 Unit 再做一次互联。到这里，咱们曾经能够连出 400 台机器共 3200 卡的规模。对于这样一个 3200 卡规模的集群来说，任意两张同号卡之间最多就跳到 3 跳即可实现通信。

如果咱们想反对异号卡的通信怎么办？咱们在下面又加了 Spine 层，进而解决了异号卡之间通信的问题。

通过这三层的架构，咱们便实现了一个反对 3200 卡间专门针对 AllReduce 操作优化的整体架构。如果是在 IB 的网络设备上，该架构能够反对 16000 卡的规模，这也是目前 IB 盒式组网的最大规模。

咱们将 CLOS 架构跟其余的一些网络架构做了比拟，比方 Dragonfly，Torus 等。跟它们相比，这套架构的网络带宽更加短缺、节点间的跳步数更加稳固，对于做可预期的训练性能的预计很有帮忙。

以上就是从单机到集群网络的一整套建设思路。

三、软硬件联合的联结优化

大模型训练并不是把硬件买好了，放在那里就能够实现训练。咱们还须要对硬件和软件进行联结优化。

首先咱们先来说说计算优化。大模型的训练整体来看还是一个计算密集型的过程。在计算优化上，目前很多思路和想法都是基于动态图的多后端减速。用户构建的图，无论是飞桨、PyTorch 还是 TensorFlow，都会先通过图捕捉把动态图转换成动态图，而后再让动态图进入到后端进行减速。

下图是咱们整个基于动态图的多后端架构，它分为如下几局部 。

第一个是图接入，把动态图转换成动态图。

第二个是多后端接入的办法，通过不同的后端提供基于计时的选优能力。

第三个是图优化，咱们针对动态图做了一些计算上的优化和图转换，从而进一步晋升计算效率。

最初咱们会通过一些自定义的算子，整体减速大模型的训练过程。

上面咱们别离开展介绍一下。

大模型的训练架构中，第一局部是图接入。在 AI 框架里形容图的时候，通常分为动态图和动态图。

动态图是用户在执行之前先把图结构进去，再联合本人的理论输出做执行。联合这样的特点，在计算过程中能够提前做些编译上的优化或者调度的优化，能够更好地晋升训练性能。

但与之对应的是动态图的结构过程。用户轻易写了一些代码，在写的过程中就动静执行了。比方 PyTorch，在用户写完一条语句之后，它就会做相干的执行和求值。对用户来说，这种形式的益处就是很容易开发和调试。然而对于执行器或者对于减速过程来说，因为每次看到都是一部分很小的操作，反而不是很好优化。

为了解决这个问题，个别的想法就是把动态图和动态图做交融，应用动态图做开发，再通过动态图做执行。咱们当初看到的次要有两种实现的门路。

第一种就是基于 Python AST 去做动态的转换。比方咱们拿到用户写的 Python 源码，将其转换成 Python  AST 树后，再依据 AST 树去做 CodeGen。在这个过程中应用动态组图的办法和 API 就能够将 Python 的动静源码转换成动态图。

但这个过程中，最大的问题是 Python 语言的灵活性，导致动态的剖析没方法很好地了解语义，进而呈现动态图转动态图转换失败的状况。比方在动态剖析过程中，它没方法推断动静类型，又比方动态剖析没方法推断 range 的范畴，导致理论转换过程中常常失败。所以动态转换只能实用一些简略的模型场景。

第二条路线就是通过 Tracing 或者 Symbolic Tracing 的办法，去做简略的执行和模仿。Tracer 记录过程中遇到的一些计算节点，将这些计算节点记录下来之后，再通过回放或者重组的形式去后验结构一整个动态图。这种形式的益处是能够通过模仿一些输出的办法，或者通过一些结构非凡构造的办法来做整体动态图的捕捉和计算，进而能够较为胜利地捕捉到一条门路。

然而这个过程其实也存在一些问题。对于依赖输出的分支或者循环构造来说，因为 Tracer 是通过结构模仿输出的形式来结构动态图，因而 Tracer 只会走到其中一些分支，从而导致安全性上存在问题。

这几种办法比拟下来之后，咱们发现在 Python 现有的语言灵活性下，如果想让动态图残缺地转换成动态图，在现阶段基本上是一个不太可能实现的工作。因而咱们的重心就转移到了在云上如何给用户提供更平安易用的图转化能力。现阶段有如下几种计划。

第一个计划是自研基于 AST 代码替换的办法。该办法由百度智能云来提供相应的模型转换和优化的能力，对用户而言是无感的。比方，用户输出一段源码，然而其中局部代码（图中 XXXX、YYYY 所示）在做动态图捕捉、图优化、算子优化的过程中，咱们发现这部分代码无奈将动态图转换为动态图、或者代码有性能优化的空间。那么咱们就会写一段替换代码，如两头图所示。右边是咱们认为是能够被替换的一段 Python 代码，左边是咱们替换后的另一段 Python 代码。而后，咱们就会通过 AST 匹配的办法，把用户的输出和咱们的原始的指标模式做 AST 的转换，在这下面执行咱们子树的树匹配算法。

通过这种形式，就能够把咱们原始输出的 XXXX、YYYY 变成 WWWW、HHHH，变成一个能够更好执行的计划，肯定水平上晋升了动态图转动态图的成功率，同时晋升了算子的性能，并能够做到用户根本无感的成果。

第二种是社区上的一些计划，尤其是 PyTorch 2.0 提出的 TorchDynamo 计划，这也是咱们目前看到的比拟适宜计算优化的计划。它能够实现局部的图捕捉，不反对的构造能够 fallback 回 Python。通过这样的形式，它能够肯定水平上把其中的局部子图吐给后端，而后后端再针对这些子图做进一步的计算减速。

当咱们将图整个捕捉完之后，接下来就要真正开始做计算减速了，即后端减速。

咱们认为，在 GPU 计算的时序图中比拟要害的其实是访存工夫和计算工夫。咱们从如下几个角度去减速这个工夫。

第一个是算子交融。算子交融次要的收益就是去掉 kernel launch 的工夫、晋升计算密度、缩小额定的访存。咱们将算子单位访存上的计算次数，定义为计算密度。

依据计算密度的不同，咱们把算子分为计算密集型和访存密集型两类。举个例子，像 GEMM 就是典型的计算密集型算子，像 Elementwise 就是典型的访存密集型的算子。咱们发现，“计算密集型算子 + 访存密集型的算子”和“访存密集型算子 + 访存密集型算子”之间，是能够做比拟好的交融的。

咱们的指标是将所有在 GPU 上执行的算子转化为偏计算密集性的算子，这样能够充分利用咱们的算力。

右边是咱们的一个例子，比方在 Transformer 的构造中，最重要的 Multihead Attention，是能够做一个很好的交融的。同时左边还有咱们发现一些其余模式，限于篇幅就不一一列举了。

另一类计算优化是对算子实现上的优化。

算子实现的实质问题是如何将计算逻辑和芯片架构相结合，从而更好地去实现整个计算过程。咱们目前看到三类计划：

第一类是手写算子。相干厂商会提供比方 cuBLAS、cuDNN 等算子库。它提供的的算子性能是最好的，然而它反对的操作无限，同时对定制开发的反对也比拟差。

第二类是半自动化模板，比方 CUTLASS。这种办法做了开源的形象，让开发人员能够在下面做二次开发。这也是咱们目前实现计算密集型与访存密集型算子交融中理论应用的办法。

第三个是基于搜寻的优化。咱们关注了社区上一些像 Halide，TVM 的编译办法。目前发现该办法在一些算子上是有成果的，但在另外一些算子上则还须要进一步打磨。

在实践中这三种办法各有劣势，因而咱们会通过计时抉择的形式来为大家提供最好的实现。

说完计算的优化，咱们再分享下通信优化的几种办法。

第一个是交换机哈希抵触问题的解决。下图是咱们做的一个试验，咱们起了一个 32 卡的工作，每次执行 30 次 AllReduce 操作。下图是咱们测进去通信带宽，能够看到它有很大的概率是会呈现降速。这是在大模型训练中比较严重的问题。

降速的起因是因为存在哈希抵触。尽管在网络设计上，交换机没有收敛比，即咱们网络设计上的带宽资源都是短缺的，然而因为应用了 RoCE 这种基于以太网四元组选路的办法，依然可能产生网络侧的流量抵触。

比方下图中的例子，绿色的机器之间要通信，红色的机器之间也要通信，那么在选路的过程中，就会因为哈希抵触导致大家的通信争抢到了同一带宽上，导致尽管整体的网络带宽是短缺的，然而仍然会造成部分网络热点，导致通信性能降速。

咱们的解决办法其实也很简略。在整个通信过程中有源 IP、源端口、目标 IP、目标端口这个四元组。其中源 IP、目标 IP、目标端口固定不变，而源端口是能够调整的。利用这个特点，咱们通过一直地调整源端口来抉择不同的门路，再通过整体的贪婪算法，尽量减少哈希抵触的产生。

通信优化中，除了方才说到在 AllReduce 上的一些优化，在 All2All 上也有肯定优化空间，尤其是咱们这种面向八导轨的专门定制过的网络。

该网络在整个 All2All 的操作上会给下层的 Spine 交换机较大的压力。优化办法是应用了 NCCL 外面的 Rail-Local All2All，或者 PXN 的优化。原理就是将异号卡之间的通信通过机内高性能的 NVLink 转换为同号卡之间的通信。

通过这种形式，咱们将机间的本来要上到 Spine 层的所有的网络通信转换为机内通信，这样只须要做 TOR 层或者 Leaf 层通信就能够实现异号卡通信，在性能上也会有较大的晋升。

此外，除了在 RoCE 上做的这些优化，还有一个间接就能拿到成果的就是使能 Infiniband。比方方才提到的交换机哈希抵触，它本人的自适应路由就能够搞定。而对于 AllReduce 来说，它还有一些高级的个性如 Sharp，能够很好地把 AllReduce 计算操作的一部分卸载到咱们的网络设备中，以开释计算单元，同时晋升计算性能。通过这样的办法，咱们能够很好地将 AllReduce 的训练成果再次晋升。

方才讲完了计算和通信的优化，咱们接下来再从端到端去看这个问题。

从整个大模型训练来说，它其实分为两大部分，第一局部是模型代码，第二局部是高性能的网络。在这两个不同的层级上，有一个问题亟待解决：通过多种切分策略切分后的模型搁置到哪张卡上是最合适的？

咱们举个例子，在做张量并行的时候，咱们须要将一个张量的计算切分为两块。因为分块计算结果之间须要做大量的 AllReduce 操作，因而须要很高的带宽。

如果咱们将一个张量并行切完的两块别离放到不同机器的两张卡上，就会引入网络通信，造成性能问题。反之，如果咱们把这两块放到同一机器内，就能够高效实现计算工作，晋升训练效率。因而，搁置问题的外围诉求，就是要找到切分的模型和异构硬件间最合适或者说性能最好的映射关系。

在咱们晚期的模型训练中，是基于专家教训常识手工实现映射。比方下图就是咱们跟业务团队单干时，当咱们认为机内的带宽好，就倡议放到机内。如果咱们认为机间可能有改良时，就倡议放到机间。

那有没有工程化或者系统化的计划呢？

咱们外围的解法就是构建计算、通信的 Cost Model，而后基于 Cost Model 做搜寻优化。通过这种形式产出最优的映射。

在整个过程中会先将框架侧的模型网络做形象和切分，映射成一个计算框架图。同时会将单机和集群上的计算能力、通信能力做相干建模，建设集群的拓扑图。

当咱们有了右图右边的模型上的计算和通信需要，以及右图左边硬件上的计算和通信能力，咱们就能够通过图算法或者其余一些搜寻办法进行模型的拆分和映射，最终拿到右图下边的一个最优解。

在理论的大模型训练过程中，通过这种形式能够让最初的性能晋升 2.1 倍。

四、大模型倒退推动基础设施演进

最初和大家探讨下在将来，大模型会对基础设施提出哪些新的要求。

目前咱们看到的变动有三个。第一个是模型的参数，模型参数还会继续地增长，从 GPT-3 的 1750 亿到 PaLM 的 5400 亿。对于将来参数增长的最终值，咱们能够参考下大略有 60 万亿参数规模的人脑。

第二个是多模态训练。在将来咱们会解决更多的模态数据。不同的模态数据对存储、计算量、显存都会带来更多的挑战。

第三个是异构资源。在将来咱们会有越来越多的异构资源。在训练过程中，各种类型的算力，如何更好地应用它们也是一个亟待解决的挑战。

同时从业务角度看，在一个残缺的训练过程中可能还会有不同的类型的作业，可能同时会存在传统的 GPT-3 训练、强化学习训练、和数据标注工作。如何把这些异构的工作更好地搁置在咱们异构的集群上将会是一个更大的问题。

咱们当初看到的几个办法，其中一种办法是基于对立视图的端到端的优化：将整个模型和异构资源做视图上的对立，基于对立视图扩大 Cost Model，能够反对单任务多作业在异构资源集群下的搁置。联合弹性调度的能力，能够更好地感知集群资源的变动。

上文讲到的所有能力，都曾经全副交融到了百度百舸的· AI 异构计算平台中。

——END——

举荐浏览 ：

浅谈流动场景下的图算法在反作弊利用

Serverless：基于个性化服务画像的弹性伸缩实际

图片动画化利用中的动作合成办法

性能平台数据提速之路

采编式 AIGC 视频生产流程编排实际

百度工程师漫谈视频了解