无为做网站石家庄网站建设高端

无为做网站,石家庄网站建设高端,黑龙江建设厅网站官网,建设宠物店网站GPU 可以执行与 TPU 相同的集合操作#xff1a;ReduceScatter、AllGathers、AllReduces 和 AllToAlls。与 TPU 不同的是#xff0c;这些操作的工作方式会根据执行位置的不同而有所差异#xff1a;是在节点级别#xff08;通过 NVLink#xff09;还是在更高级别#xff08…GPU 可以执行与 TPU 相同的集合操作ReduceScatter、AllGathers、AllReduces 和 AllToAlls。与 TPU 不同的是这些操作的工作方式会根据执行位置的不同而有所差异是在节点级别通过 NVLink还是在更高级别通过 InfiniBand执行。NVIDIA 在NVSHMEM和NCCL 读作“nickel”库中实现了这些集合操作。NCCL 已在此处开源。虽然 NCCL 根据延迟要求/拓扑结构使用多种实现方式详情请见此处但接下来我们将讨论在交换树结构上的理论最优模型。节点内集体AllGather 或 ReduceScatter对于节点级别的 AllGather 或 ReduceScatter 操作您可以像在 TPU 上一样围绕环形结构执行这些操作并在每次跳跃时使用完整的 GPU 间带宽。您可以任意排列 GPU 的顺序并使用完整的 GPU 间带宽将数组的一部分沿环形结构发送。每次跳跃的成本是T跳bytes/(N∗GPU 出口带宽)因此总成本为:你会注意到这与 TPU 上的情况完全相同。对于 AllReduce 操作你可以像往常一样组合 RS 和 AG但成本会翻倍。**图**带宽最优的一维环形AllGather算法。对于B字节的数据该算法通过顶层交换机发送V/X字节次数为X-1次。如果您担心延迟例如如果您的数组非常小您可以进行树形归约其中先对 2 个元素进行 AllReduce 操作然后对 4 个元素进行 AllReduce 操作最后对 8 个元素进行 AllReduce 操作总共进行 2 次 AllReduce 操作。log(N)​​啤酒花代替N− 1尽管总成本仍然相同。小测验 1 [AllGather 时间]使用 8xH100 节点带宽为 450 GB/s 全双工AllGather(bf16[B X , F]) 需要多长时间B 1 0 2 4F 1 6 , 3 8 4。答我们总共有字节单向带宽为 450e9。这大约需要T通讯 ( 2 ⋅B⋅F) / 450e9或者更确切地说利用所提供的数值我们可以大致得出以下结果。或者更准确地说。所有 GPU 之间相互连接节点内的 GPU 之间可以完全互联这使得所有 GPU 的全连接通信非常容易。每个 GPU 只需直接向目标节点发送数据即可。在节点内对于 B 字节的数据每个 GPU 都有B/N字节和发送(B/N2字节到N− 1目标节点总数为。相比之下TPU 的成本是B/ ( 4W)因此在单个节点内我们理论上可以获得 2 倍的运行时加速B/ 4W​对比B/ 8W​。对于混合专家MoE模型我们经常需要进行稀疏或不规则的AllToAll映射其中我们保证最多k的N输出维度上的分片非零也就是说T所有的一切​→K[B,N]最多k的N每个轴上的数值均不为零。这降低了成本。k/N总计约对于弹性模量我们通常是独立随机地选取非零值因此存在出现数值少于零值的概率。k非零值大约( N − 1 ) / N ⋅ min ( k / N , 1 ) ⋅ B / ( W ⋅ N )小测验 2 [AllToAll 时间]使用 8xH100 节点单向带宽为 450 GB/sAllToAll X-N (bf16[B X , N]) 需要多长时间如果我们知道 8 个条目中只有 4 个非零结果又会如何答案由以上可知在稠密情况下成本为 或者B/ (W⋅N)如果我们只知道1/2​​条目将不包含填充内容我们可以发送大约占总成本的一半。要点数组上的 AllToAll 的成本B单个节点内 GPU 上的字节数约为T通讯 (B⋅ ( 8 − 1 ) ) / ( 82⋅WGPU出口) ≈B/ ( 8 ⋅WGPU出口​对于一个破旧的顶部-kk) AllToAll这将进一步减少到(B⋅k) / ( 6 4 ⋅WGPU 出口​。实测结果以下是 8 个 H100 节点上 AllReduce 带宽的实测结果。算法带宽 (Algo BW) 为实测带宽字节/运行时间总线带宽 (Bus BW) 的计算方法如下理论上这可以衡量实际链路带宽。你会注意到我们确实达到了接近 370GB/s 的速率虽然低于 450GB/s但也相当接近尽管每个设备仅能达到约 10GB。这意味着尽管这些估算在理论上是正确的但需要传输大量数据才能实现。**图**禁用 SHARP 的 8xH100 节点的 AllReduce 吞吐量。蓝色曲线为经验链路带宽计算方法如下根据实测数据即使使用10GB的超大容量阵列我们也无法达到宣称的450GB/s带宽。这是一个实际存在的问题因为它显著地使我们能够提出的任何理论论断变得复杂。例如即使是对一个大小合理的数组例如 LLaMA-3 70B 的 MLP大小为 1000bf16[8192, 28672]或采用 8 路分片bf16[8192, 3584] 58MB执行 AllReduce 操作其吞吐量也只能达到约 150GB/s而峰值吞吐量可达 450GB/s。相比之下TPU 在消息大小远小于此的情况下即可达到峰值带宽参见附录 B。在网络缩减方面自 Hopper 架构以来NVIDIA 交换机就支持“SHARP”可扩展分层聚合和缩减协议该协议允许“网络内缩减”。这意味着网络交换机本身可以执行缩减操作并将结果复用或“多播”到多个目标 GPU**图示**不使用 SHARP 的 AllReduce 算法的理论成本是实际成本的两倍因为它需要两次经过每个 GPU。实际上速度提升仅约为 30%数据来自 NCCL 2.27.5。理论上这几乎可以将 AllReduce 的成本减半因为这意味着每个 GPU 都可以将其数据发送到顶层交换机由顶层交换机执行归约并将结果广播到每个 GPU而无需两次向每个 GPU 发送数据同时还可以减少网络延迟。请注意这是精确值没有误差。1/N1 /N因为每个GPU都会输出首先接收其本地分片的部分缩减版本入口。完成还原操作然后退出再次然后完全简化的结果进入进入结果恰好BB已接收字节数。然而在实际应用中我们发现启用 SHARP 后带宽仅提升了约 30%而预期提升幅度为 75%。这使得我们的有效总带宽仅达到约 480GB/s远未达到 2 倍。**图**节点内启用和禁用 NVIDIA SHARP 时 AllReduce 算法带宽的实测结果。峰值吞吐量提升约 30%而理论上算法应该能够实现接近 75% 的提升。要点理论上NVIDIA SHARP大多数NVIDIA交换机都支持应该可以降低AllReduce的成本。B来自大约的字节到然而在实际应用中带宽提升仅约为 30%。由于 LLM 中纯粹的 AllReduce 操作相当少见因此这种提升意义不大。跨节点集体当我们超越节点级别时成本就变得更加微妙了。对树进行归约时可以考虑从下往上进行归约首先在节点内部进行归约然后在叶节点级别进行归约最后在树干级别进行归约每一层都使用常规算法。特别是对于 AllReduce 来说可以看到这可以减少我们整体传输的数据量因为在节点级别进行 AllReduce 之后我们只需要进行外部传输即可。B字节数直到叶子节点而不是*BN。这样做成本有多高初步估算由于我们拥有完整的二分带宽AllGather 或 ReduceScatter 的成本大致等于缓冲区大小以字节为单位除以节点出口带宽H100 上为 400GB/s而与树归约的任何细节无关。在哪里在节点对于上述 H100 网络每个节点有 8 条 400Gbps IB 链路出口出口流量通常为 400GB/s。最直观的理解方式是想象对集群中的每个节点进行环形缩减。由于采用了胖树拓扑结构我们总能构造出一个环。在节点在任意两个节点之间建立出口并执行常规缩减操作。节点级缩减几乎永远不会成为瓶颈因为它具有更高的整体带宽和更低的延迟尽管通常成本较高。其他类型的集合除非启用 SHARP否则 AllReduce 的成本仍然是上述值的两倍。NVIDIA 也销售启用 SHARP 的 IB 交换机但并非所有供应商都提供。AllToAll 在不同节点间变化较大因为它们不像 AllReduce 那样具有“分层”结构。如果我们想将数据从每个 GPU 发送到其他所有 GPU就无法在节点级别充分利用二分查找带宽。这意味着如果我们有一个跨越多个节点的 N 路 AllToAllMN/ 8节点成本为这实际上只有 50GB/s 的带宽而不是 400GB/s。我们从B/ ( 8 ∗ 450e9 )在单个 H100 节点内B/ ( 2 ⋅ 400e9 )跨越 2 个节点时性能下降超过 4 倍。以下是1024GPU DGX H100 SuperPod架构的概述我们使用术语“集体带宽”来描述我们可以从 GPU 或节点输出数据的有效带宽。它也是。要点在节点级别之外对 B 字节执行 AllGather 或 ReduceScatter 操作的成本大致为B黑白​​节点出口即B/ 400e9在 H100 DGX SuperPod 上除非启用 SHARP否则 AllReduce 的成本是原来的两倍。整体拓扑结构为胖树形旨在确保任意两个节点对之间带宽恒定。数组按不同轴分片时归约操作考虑如下归约操作的成本这里我们正在对一个本身沿另一个轴分片的数组进行全归约操作在TPU上这项操作的总成本降低了……倍。与未分片版本相比因为我们发送的是分片版本。每个轴的数据量都相同。在 GPU 上成本取决于哪个轴是“内部”轴节点内轴还是节点间轴以及每个分片是否跨越多个节点。假设是内轴数组有通过计算总字节数总体成本有效降低了。但前提是跨越多个节点其中 N 为 GPU 的数量再次D节点是节点中 GPU 的数量节点的度。如您所见如果YD节点这样我们在节点层面上取得了优势但通常看不到整体运行时间的减少而如果YD节点速度提升与所跨越的节点数成正比。如果我们想要精确地描述环的简化那么对于树 AllGather X (A Y { U X })假设 Y 是内轴一般规则是在哪里S我​其中 M * N * … 表示树中第 i 层以下子节点的大小。这大致意味着我们覆盖的 GPU 或节点越多可用带宽就越大但仅限于该节点内部。随堂测验 3 [沿两个轴分片]假设我们想要进行众人聚集​​​​AllGatherX​( bf16 [DX​F和​] 在哪里是单个SU256个芯片的内轴。这需要多长时间DF 和答案我们可以将其分为两种情况即 Y ≤ 8 和 Y 8。我们仍然受限于叶开关所以答案和往常一样是T通讯 2 ∗D∗F∗ ( 3 2 − 1 ) / ( 3 2 ∗ 4 0 0e9 )当 Y 8 时根据以上内容大致可知对于D 8192F 32,768我们有**图**随着内轴跨越更多节点分片 AllGather 的理论成本。注意如果我们采用 8 路并行模型实际上可以将节点级缩减的成本降低 8 倍但总体成本保持不变因此它是免费的但对提高整体带宽没有帮助。测验 4集体问题 1 [SU AllGather]仅考虑一个具有 M 个节点且每个节点有 N 个 GPU 的 SU。在 AllGather 期间节点级交换机究竟会接收和发送多少字节的数据顶层交换机的情况又如何答让我们一步一步来逐个分析简化过程的各个组成部分每个GPU发送B/M N向交换机发送字节总流入量为N B/M NB/M字节入口。我们完全退出B/M字节数直至脊柱交换机。我们进入B∗ (M− 1 ) /M来自脊柱交换机的字节我们离开B−B/M N字节N次数总共NN∗ (B−B/M N) N B−B/M。总计为B入口和北​出口处存在瓶颈因此我们应该会受到出口处的瓶颈影响总时间将是TAllGather​B⋅ (M− 1 ) / (M⋅W节点​) B⋅ (M− 1 ) / (M⋅ 400e9 )。问题 2 [单节点 SHARP AR]考虑一个单节点每个节点有 N 个 GPU。在使用 SHARP网络内归约进行 AllReduce 时交换机究竟会接收和发送多少字节的数据答和以前一样我们一步一步来。每个GPU发送B∗ (N− 1 ) /N字节所以我们有N∗B∗ (N− 1 ) /NB∗ (N− 1 )已进入。我们将部分和累加起来然后寄回。B/N每个GPU分配的字节数因此NN∗B/NB字节数已传出。我们在本地对残差进行部分求和然后将结果发送回交换机。总和为N∗B/NB已接收字节数。我们捕获所有分片并进行多播发送B∗ (N− 1 ) /N到N目的地总计B∗ (N− 1 ) /N∗NB∗ (N− 1 )已离开。因此总数为B∗ (N− 1 ) BB N流入和流出的字节数。这支持了总吞吐量恰好为零。问题 3 [跨节点 SHARP AR]考虑一个分布在 N 个 GPU 的单个节点上的数组 bf16[D X , F Y ]。AllReduce(bf16[D, F Y ] { U X }) 需要多长时间假设我们进行的是网络内归约。解释一下如果节点不止一个结果会有什么不同答我们可以尝试修改上面问题的答案。基本上我们首先出口B∗ (X− 1 ) /X Y然后从每个GPU发送字节B/X Y将数据发送到每个GPU然后将相同数量的数据发送回交换机然后再发送B∗ (X− 1 ) /X Y回到每个GPU。总计为进出都需要时间所以总时间为T通讯​N B/ (Y∗N∗W关联) N∗ 2D F/ (Y∗N∗W关联) 2 ∗D∗F/ (Y∗W关联​因此总时间确实会减少。。如果涉及多个节点我们可以进行与上述大致相同的缩减操作但当我们从节点级交换机发出数据时我们需要发送所有 B 字节而不仅仅是 B 字节。这是因为我们需要将每个碎片分开。问题 4 [脊柱水平 AR 成本]考虑与上述相同的设置但有Y 2 5 6因此AR 发生在脊柱层面。AllReduce 需要多长时间同样您可以假设所有费用均在网络内扣除。答这使我们能够充分利用主干层惊人的带宽。我们在 4 个节点上拥有 25.6TB/s 的带宽因此 AllReduce 带宽为 6.4TB/s。使用 SHARP这只需2 * D * F / 6.4e12几秒钟即可完成。