【论文阅读】MegaScale: Scaling Large Language Model Training to More Than 10,000 GPUs

zj.Liu

已于 2024-12-01 20:50:59 修改

阅读量1.1k

点赞数 29

分类专栏：论文阅读文章标签：论文阅读

于 2024-11-29 00:13:47 首次发布

本文链接：https://blog.csdn.net/qq_52050257/article/details/144061556

版权

论文阅读专栏收录该内容

7 篇文章

订阅专栏

【论文阅读】

MegaScale: Scaling Large Language Model Training to More Than 10,000 GPUs

摘要

原文翻译：
我们介绍了构建和部署MegaScale的设计、实现和工程经验，MegaScale是一个用于在超过10,000个GPU的规模上训练大型语言模型（LLMs）的生产系统。在这个规模上训练LLMs给训练效率和稳定性带来了前所未有的挑战。我们采取了一种全栈方法，共同设计了模型块和优化器设计、计算与通信重叠、操作符优化、数据管道和网络性能调整的算法和系统组件。在生产中，鉴于LLM训练作业的长期性，在整个训练过程中保持高效率（即稳定性）是一个重要的考虑因素。许多难以解决的稳定性问题只有在大规模情况下才会出现，深入的可观测性是解决这些问题的关键。我们开发了一套诊断工具，用于监控系统组件和深层栈中的事件，识别根本原因，并得出实现容错和减轻落后者的有效技术。MegaScale在12,288个GPU上训练一个175B LLM模型时实现了55.2%的模型FLOPs利用率（MFU），比Megatron-LM提高了1.34倍的MFU。我们分享了在识别和修复失败和落后者方面的操作经验。我们希望通过从系统的角度阐明问题和分享我们的经验，这项工作可以激发未来的LLM系统研究。

       摘要介绍了MegaScale系统，这是一个为了在极端大规模（超过10,000个GPU）上训练大型语言模型而设计的系统。这种规模的训练对系统的效率和稳定性提出了巨大挑战，因此作者采取了全栈方法，即从算法到系统层面的组件都进行了协同设计和优化。这种设计包括了模型和优化器的设计、计算与通信的重叠执行、操作符的优化、数据管道的管理和网络性能的调整。
       作者特别强调了稳定性的重要性，因为大型语言模型的训练任务通常需要很长时间，而且只有在大规模部署时才会出现一些难以解决的稳定性问题。为了解决这些问题，作者开发了一系列深入监控系统组件和事件的诊断工具，这些工具可以帮助识别问题的根本原因，并实现系统的容错和减轻性能落后的GPU节点的影响。
       MegaScale系统在实际应用中取得了显著的性能提升，相比于现有的Megatron-LM框架，MFU提高了1.34倍。

一、引言

原文翻译：
大型语言模型（LLMs）已成为人工智能（AI）中的变革性技术。LLMs的最新进展显著提高了它们的能力。LLMs在多个领域展现出巨大潜力，如机器翻译、文本摘要和对话代理。作为一家服务数十亿用户的公司，我们一直在积极将AI整合到我们的产品中，并将LLMs作为塑造我们产品未来的高度优先事项。
训练LLMs是一项艰巨的任务，需要巨大的计算资源。扩展法则规定，模型大小和训练数据大小是决定模型能力的关键因素。为了实现最先进的模型能力，许多努力都致力于训练具有数千亿甚至数万亿参数的大型模型，这些模型在数千亿甚至数万亿的令牌上进行训练。例如，GPT-3有1750亿参数，PaLM[5]有5400亿参数。该领域的主要参与者构建了拥有数万个GPU的大规模AI集群来训练LLMs。

这段内容强调了大型语言模型（LLMs）在人工智能领域的重要性和影响力。然而，训练这些大型模型是一项挑战性的任务，因为它需要巨大的计算资源。

       将LLM训练扩展到数万个GPU带来了前所未有的挑战。由于AI一直是我们许多产品的核心，我们在训练深度神经网络（DNNs）方面拥有丰富的经验。然而，像ResNet[6]这样的模型训练仅需要数十或数百个GPU。与这些模型相比，LLMs的训练规模是空前的。虽然我们在构建和运营大规模GPU集群方面并不陌生，但这些集群通常由许多训练作业共享。现在，在LLM训练的背景下，一个单一作业就占据了数万个GPU并占用了所有资源。LLM训练的巨大规模从系统的角度引入了两个具体的挑战。
       第一个挑战是实现大规模的高训练效率。模型FLOPs利用率（MFU）是观察到的吞吐量与假设达到100%峰值FLOPs的理论最大吞吐量之比[7]。这是一个标准指标，用于评估训练效率，直接转化为端到端的训练速度。LLM训练并不是简单的并行任务。为了训练一个LLM，模型被分割到多个GPU上，这些GPU之间需要进行大量的通信以取得进展。除了通信之外，操作符优化、数据预处理和GPU内存消耗等其他因素也对MFU有显著影响。
       第二个挑战是实现大规模的高训练稳定性，即在整个训练过程中保持高训练效率。从生产的角度来看，稳定性尤其重要，因为LLMs需要很长时间来训练。用一万亿个令牌训练一个LLM可能需要数周时间。规模和时间比常规DNN训练作业大得多。对于LLM训练来说，故障和落后者是常态而非例外。在如此大的规模下，故障和落后者的后果是灾难性的。故障非常昂贵，而且鉴于规模庞大，减少恢复时间至关重要。一个落后者不仅影响自己的工作，还会拖慢涉及数万个GPU的整个作业。

这段内容讨论了在数万个GPU上进行大型语言模型（LLMs）训练时面临的两个主要挑战：效率和稳定性。

MegaScale是一个为LLM训练量身定制的专用系统。算法-系统共同设计是提高专用系统性能的关键原则，在计算机系统中得到了广泛应用。我们在LLM训练的背景下，采用全栈方法将这一原则应用于MegaScale，涵盖了所有重要的系统组件。我们对模型架构进行了几项修改，并纳入了有效的优化技术，包括并行变换器块[5]、滑动窗口注意力[8]和LAMB优化器[9]。我们利用混合并行策略，结合了数据并行、流水线并行、张量并行和序列并行。重要的是，我们根据每种并行策略的模式设计了定制技术，以最大化通信和计算之间的重叠。我们应用预取和基于树的加载来优化数据管道。我们利用非阻塞异步操作，并消除了大规模集体通信组初始化的全局障碍。我们设计了自定义网络拓扑，减少了ECMP哈希冲突，定制了拥塞控制，并调整了重传超时参数以提高网络性能。

这段内容描述了MegaScale系统的核心设计理念和实现方法，旨在为大型语言模型（LLM）训练提供高性能的计算支持。

在大规模系统中，包括故障和落后者在内的稳定性问题通常很难诊断和修复。许多严重的稳定性问题只有在大规模情况下才会出现，这可能源于栈中深层次的软件和硬件故障。鉴于系统的规模和复杂性，手动识别和解决每一个问题是不切实际的。我们应用深入可观测性的原则来构建一套诊断工具。通过“深入可观测性”，我们指的是一种全面的监控和可视化策略，它超越了表面级别的指标，收集系统栈每个组件的详细、细粒度数据，旨在创建系统性能的多维视图。这套工具允许我们通过揭示复杂的交互和依赖关系，诊断系统并确定根本原因，这些交互和依赖关系导致了稳定性问题。我们开发了一个健壮的训练框架来自动化故障定位和恢复。我们设计了包含各种信息的心跳消息，以促进实时异常检测并提供早期警告。我们实施了一系列诊断测试来识别造成干扰的节点。我们优化了检查点和恢复程序以减少中断。为了解决由落后者引起的微妙案例，我们开发了一个性能分析工具来记录细粒度的CUDA事件，并从分布式视图生成全系统的热图和时间线追踪，以及开发了一个3D并行训练可视化工具，以显示等级之间的数据依赖关系，用于诊断。

这段内容讨论了在大规模系统，特别是大型语言模型（LLM）训练中，如何诊断和解决稳定性问题。由于这些问题可能源于软件和硬件的深层次故障，手动处理每个问题在实际操作中是不可行的。因此，作者采用了深入可观测性的原则来构建诊断工具，这些工具能够提供系统性能的多维视图，帮助识别和解决稳定性问题。

MegaScale被部署在我们的数据中心中，用于训练我们产品的LLMs。多年来，我们构建了几个不同规模和硬件配置的AI集群。我们最大的AI集群拥有超过10,000个GPU。在训练效率方面，MegaScale在12,288个GPU上训练一个标准的175B transformer模型时实现了55.2%的MFU，与最先进的开源训练框架Megatron-LM[10]相比提高了1.34倍。在模型收敛和稳定性方面，我们展示了MegaScale在数周内训练一个拥有数千亿参数的专有模型在多万亿个token上的真实生产运行情况。几周内，损失持续收敛，MegaScale在出现故障的情况下超过100次修复和恢复训练过程。我们还分享了诊断和修复一些有趣问题的经验。我们正在努力在GitHub上开源一些可以惠及社区的组件。

MegaScale系统在实际生产环境中的部署和性能表现。

二、背景

原文翻译：
LLMs的训练是计算密集型，以其庞大的模型架构和海量数据集为特征。并行策略将训练过程分布在多个设备上。
数据并行。它在多个设备上复制模型和优化器状态，并将数据均匀分配给所有设备。每个模型副本并行执行前向和反向传播计算。在每次迭代完成后，所有模型副本同步以更新模型。零冗余优化器（ZeRO）不是复制模型状态（如优化器状态、梯度和参数），而是将这些状态在每个数据并行进程中分割。因此，传统的聚合梯度的all-reduce操作被分解为单独的reduce-scatter和all-gather操作。这是因为每个数据并行进程只保留总状态的一部分。ZeRO分为三个递增的优化阶段。特别是，第二阶段通常被采用来分割优化器状态和梯度，同时确保不引入额外的通信开销（图1）。

这段内容解释了数据并行的概念以及零冗余优化器（ZeRO）在数据并行训练中的应用。

原文翻译：
流水线并行性。它将模型层分配到多个设备上，每个设备拥有模型的一部分。同时，每个训练批次被细分为多个微批次以进行流水线执行。为了减少流水线中的空闲时间（pipeline bubbles），提出了各种流水线调度策略，例如GPipe[12]、PipeDream 1F1B[13]等。Megatron-LM[7]采用了交错的1F1B调度策略。每个工作节点上的每个流水线阶段被细分为多个虚拟阶段，这些虚拟阶段代表模型的一个子集，称为模型块。最初，工作节点进入热身阶段，为有限数量的正在进行的微批次执行前向传播。热身之后，每个工作节点进入稳定阶段，在这个阶段工作节点执行一个前向传播后跟一个反向传播，通常缩写为1F1B。在完成一个批次后，工作节点在冷却阶段为任何剩余的在飞行微批次完成反向传播。图2展示了一个三阶段的流水线。

这段内容解释了流水线并行性的概念以及Megatron-LM采用的Interleaved 1F1B pipeline在大型语言模型（LLM）训练中的应用。

原文翻译：
张量并行性。它将单个操作符分布在多个设备上，每个设备并行执行计算的一部分。根据特定的分区策略以及与模型中先前和后续操作符的关系，分区可能需要参与的GPU之间进行通信，以分割输入然后合并输出。例如，我们可以在多个GPU之间分割MLP（多层感知机）和自注意力块中的GEMMs（通用矩阵乘法），以利用更多的计算单元。其他一些操作，如LayerNorm（层归一化）和Dropout（丢弃法），计算强度较低，但需要大量的激活内存。另一种称为序列并行性的张量并行性被提出，用于沿序列维度分布这些操作符，以有效减少激活内存占用。

这段内容解释了张量并行性的概念及被称为序列并行性的张量并行性在大型语言模型（LLM）训练中的应用。

原文翻译：
并行策略的组合。这些并行策略可以被组合成3D并行性，以在多个GPU上扩展LLMs的训练[10]。考虑到与张量并行性相关的高通信开销，最好将此类通信限制在单个集群节点内。相反，数据并行性和流水线并行性更适用于节点间的通信。在这种情况下，我们选择优先构建数据并行性组而不是流水线并行性，这可以减少数据并行性跨小集群（minipod）的通信。

不同的并行策略结合起来，张量并行在节点内部，数据并行和流水线并行在节点间。

三、大规模高效训练

原文翻译：
在大型语言模型（LLMs）领域，大规模的高效训练变得至关重要。随着我们深入到更深层和更广泛的模型中，计算需求呈爆炸性增长。在不牺牲模型准确性的前提下处理这些计算需求，需要采用最先进的算法优化、通信策略、数据管道管理和网络性能调整技术。本节深入探讨了用于优化大型模型训练的方法，以实现大规模的高训练效率。

本段指出当下满足更大计算需求的几个方向：算法优化、通信策略、数据管道管理和网络性能调整技术，并开始本文所采用方法介绍。

3.1 算法优化

原文翻译：
我们在算法层面进行了一些修改，并纳入了最近的优化，以提高训练效率，同时不牺牲准确性。我们将在第6.2节中验证这些技术对模型收敛性的影响。并行变换器块[14]。我们采用了变换器块的并行版本，取代了标准的串行公式。具体来说，变换器块的标准公式可以从 y = x + MLP(LN(x + Attention(LN(x)))) (1) 重新格式化为 y = x + MLP(LN(x)) + Attention(LN(x)) (2)。通过这种方法，注意力块和多层感知机（MLP）块的计算可以并行执行，从而减少了计算时间。先前的研究表明[5]，这种修改不会降低具有数百亿参数的模型的质量。

修改transform块公式，使注意力块和多层感知机（MLP）块的计算并行执行，减少计算时间。

原文翻译：
滑动窗口注意力（SWA）。滑动窗口注意力[8]是一种稀疏注意力机制，它采用固定大小的窗口围绕输入序列中的每个token。计算复杂度为O(s × w)，其中s是输入序列长度，w是固定窗口大小。滑动窗口注意力比全自注意力更高效，后者的计算复杂度为O(s × s)，前提是w远小于s。过去的研究[8]和我们的微基准测试（第6.2节）表明，通过堆叠这种窗口注意力层创建的大感受野可以保留整个输入的信息。这使得训练更快，同时不牺牲准确性。

提出滑动窗口注意力，以取代full self-attention。在窗口大小远小于输入序列大小的情况下，通过多个滑动窗口的堆叠，可以在加快计算速度的同时，保持准确性。

原文翻译：
LAMB优化器。大规模高效训练常常受到每次迭代训练样本数量限制的阻碍。特别是，增加每次迭代训练样本数量可能会对模型收敛产生不利影响。LAMB优化器[9]已被证明能够将BERT的训练批量大小扩展到64K，而不会影响准确性。在LLM环境中，我们的实验发现LAMB可以将批量大小扩展到4倍，而不会损失准确性。在使用交错流水线并行性时，原始调度在以1×批量大小训练四个步骤时包含(4/v)(p-1)/m个流水线气泡[7]，而以4×批量大小训练一个步骤的流水线气泡为(1/v)(p-1)/4m。因此，MegaScale通过LAMB优化器减少了87.5%的流水线气泡。

本文使用LAMB优化器在将batch扩大四倍的同时，减少了87.5%的pipeline bubbles。 76分钟训练BERT！谷歌大脑新型优化器LAMB加速大批量训练

3.2 3D并行性中的通信重叠

原文翻译：
为了减少迭代时间，我们系统地分析了3D并行性中所有操作符的计算和通信之间的依赖关系，并设计了技术来隐藏所有非关键路径操作的开销。
数据并行性中的重叠。如图1所示，对于数据并行性，两个主要的通信操作非常突出。一个是all-gather操作，它在前向传播过程中从其他数据并行级的计算单元那里获取最新的模型参数。另一个是reduce-scatter操作，在反向传播过程中收集梯度。在3D并行性中，单个设备可能托管多个模型块。重叠是在模型块的基础上实现的，以最大限度地利用带宽。all-gather操作在模型块的前向传播之前触发，而reduce-scatter操作在其反向传播之后开始。这导致了一个挑战，即第一个all-gather操作和最后一个reduce-scatter操作无法被隐藏。受PyTorch FSDP[15]的启发，初始的all-gather操作在每次迭代的开始预先获取，允许它与数据加载操作重叠，有效地将通信时间减少了1/(2 * vpp_size)的因素。我们也首先启动高优先级的通信，以最大化重叠。通信操作的优先级由依赖于通信结果的相应计算操作的顺序决定。

在前文中的零冗余优化器（ZeRO）将数据并行分割的情况下，在单设备托管多个模型块的基础上，将其前向传播之前的all-gather和后向传播之后的reduce-scatter阶段隐藏。本论文将其因发生顺序导致无法隐藏的初始all-gather隐藏在迭代开始的获取阶段，似乎并未对最后一个reduce-scatter进行处理。 Zero 论文精读

原文翻译：
流水线并行性中的重叠。流水线并行性特点是点对点的发送/接收通信。MegaScale使用了在2中提到的交错1F1B调度方法。我们注意到在热身阶段，前向传播只依赖于其先前的接收操作。因此，我们将发送和接收操作解耦，这两者通常一起实现，并且可能被较慢的操作阻塞。通过打破这种依赖性，我们使得发送操作能够与计算重叠，如图4的左部分所示。冷却阶段可以看作是热身阶段的逆过程，允许应用相同的技术。至于稳定阶段，前向和反向计算都独立于相邻的通信操作。以反向传播为例，如图4的右部分所示，其先前的接收是为了下一个前向计算，而发送是为了前一阶段的反向计算。因此，发送和接收操作可以异步启动，与计算重叠。

流水线并行使用交错1F1B调度方法。其中发送与接收阶段和前后向传播串发，本文将发送与接收解耦，在前向传播时发送接收下个后向阶段数据，在后向传播阶段发送接收下个前向阶段数据，以达到隐藏收发阶段的目的，实现重叠，减少训练时间。

原文翻译：
张量/序列并行性中的重叠。张量并行性通常用于在计算密集型操作中分割权重，而像LayerNorm和Dropout这样的操作则沿着序列维度进行分割以节省GPU内存。这需要在GPU之间进行all-gather（收集）和reduce-scatter（分散）操作，以收集输入和重新分配输出。图3a展示了这种通信模式在并行变换器块架构中的情况。在这里，两个通信操作位于关键路径上。为了消除这个开销，我们选择将all-gather和reduce-scatter与FFN（前馈神经网络）路径上的并行Linears（线性层）融合（图3b）。由于FFN路径上的GEMM（通用矩阵乘法）内核更大，通信可以更好地被隐藏。我们将GEMM内核分解成小块，并与通信一起流水线执行（图3c）。这种策略也可以类似地应用于反向传播。

(a) PTB与SP和TP的结合：在这个模型中，LayerNorm层之后进行All-Gather操作，这是为了在序列并行性（SP）中收集数据。接着是QKV（Query, Key, Value）和ColParallelLinear层，这些层在张量并行性（TP）中被分割，意味着不同的GPU将处理数据的不同部分。Self Attention层之后是RowParallelLinear层，这一层在TP中被分割，以进一步并行化计算。最后，Reduce-Scatter操作用于将计算结果分散到各个GPU上。 (b) 将通信融合到Linears中：通过将All-Gather操作的结果直接融合到ColParallelLinear层中，可以减少通信开销。这种方法允许通信和计算操作同时进行，从而提高效率。 (c) 如何将通信融合到Linears中？与GEMM重叠通信：在这个示例中，展示了如何将通信与通用矩阵乘法（GEMM）操作重叠。通过将大的GEMM内核分解成小块，并流水线化执行，可以在执行计算的同时进行通信。这种方法允许在不牺牲计算效率的情况下，更有效地隐藏通信开销。

张量/序列并行中，将通信与计算结合，利用GEMM使通信与计算同时进行，以达到隐藏通信开销，减少训练时间的目的。

3.3高效操作符

原文翻译：
尽管Megatron-LM中的GEMM操作符已经过优化，我们还是发现了在其他操作符中进一步提升效率的机会。对于注意力部分，我们采用了FlashAttention-2[16]，它改善了不同线程块和线程束之间的工作分配。对于LayerNorm和GeLU，我们观察到它们在之前的实现中由细粒度的内核组成。通过将这些内核融合在一起，我们减少了启动多个内核所带来的开销，并有助于优化内存访问模式，从而实现了更好的性能。
FlashAttention-2简介：FlashAttention-2是一种针对Transformer模型中的注意力机制的优化算法，它旨在提升GPU上的计算性能。这种算法专注于减少非矩阵乘法（matmul）的浮点运算，以充分利用GPU上的专用计算单元，如Nvidia GPU上的Tensor Cores，这些单元在处理matmul操作时性能显著优化。
Self Attention就像是一个团队中的每个人都要和其他人交流信息来完成任务。但是，当团队非常大的时候，这种交流就会变得非常复杂和耗时。FlashAttention-2就像是对这种交流方式进行了优化，通过减少不必要的交流（减少非matmul操作），使得信息分享更加高效。它还改进了团队成员之间的任务分配，让每个人都能更充分地利用自己的时间，而不是等待别人。这样，整个团队就可以更快地完成任务，而且可以处理更大的项目（更长的上下文序列）。这不仅提高了速度，还提高了处理大型项目的能力，而且在整个过程中更加节省资源。

对图3中的Megatron-LM的自注意力部分改用FlashAttention-2，改善不同线程块和线程束之间的工作分配。并将LayerNorm和GeLU内核融合，减少启动开销。

3.4 数据管道

原文翻译：
数据预处理和加载通常被忽视。然而，这些操作在每个训练步骤的开始时会产生不可忽视的GPU空闲时间。优化这些操作对于训练过程的效率至关重要。
异步数据预处理。数据预处理并不在关键路径上。因此，在每个训练步骤的末尾，当GPU工作节点正在同步梯度时，后续步骤的数据预处理可以开始，这隐藏了预处理的开销。

在深度学习训练过程中，数据预处理和加载是两个重要步骤，它们对训练效率有着直接影响。异步数据预处理是一种技术，它允许数据预处理操作在后台进行，而不会影响GPU的计算工作。

原文翻译：
消除冗余的数据加载器。在分布式训练的典型数据加载阶段，每个GPU工作节点都配备了自己的数据加载器，负责将训练数据读入CPU内存，然后再转发到GPU。这导致工作节点之间为磁盘读取带宽而竞争，从而造成瓶颈。值得注意的是，在大型语言模型（LLM）训练环境中，同一机器内的GPU工作节点处于相同的张量并行组中。因此，它们每次迭代的输入本质上是相同的。基于这一观察，我们采用了两层的基于树的方法。我们在每台机器上使用一个单一的、专用的数据加载器将训练数据读入一块共享内存中。随后，每个GPU工作节点负责将必要的数据复制到自己的GPU内存中。这消除了冗余的读取操作，并显著提高了数据传输的效率。

在分布式训练中，每个GPU通常都有自己的数据加载器来处理数据的加载和预处理。这种方法可能会导致磁盘I/O竞争，因为所有的GPU都试图同时从磁盘读取数据，这可能会限制数据加载的速度，从而影响训练效率。为了解决这个问题，作者提出了一种两层的树状结构方法，使用单一数据加载器避免I/O竞争。

3.5 集体通信组初始化

原文翻译：
在分布式训练中，初始化阶段涉及在GPU工作节点之间建立NVIDIA集体通信库（NCCL）通信组。由于这种开销在小规模场景中相对较小，因此默认使用torch.distributed。随着GPU数量扩展到超过一万，朴素实现引入的开销变得难以忍受。我们在第6节中的同一AI集群上进行了实验，我们的实证测量表明，在2048个NVIDIA Ampere GPU上，Megatron-LM的初始化时间大约为1047秒。虽然与训练持续时间相比，这可能看起来相对较小，但它对常规测试和迭代开发（例如，超参数调整和调试中的小代码调整）构成了重大障碍。它也阻碍了快速重启和恢复机制的实施。
为了解决这个问题，我们对torch.distributed进行了详细分析[17]，并确定了初始化时间过长的两个主要原因。第一个问题在于同步步骤，每个进程在初始化特定通信组的末尾都涉及一个屏障操作。这个屏障使用TCPStore，这是Pytorch中的一个内部分布式键值存储实现，它以单线程、阻塞读写的方式运行。我们用Redis替换了TCPStore，Redis是非阻塞和异步的。这将初始化时间减少到了2048个GPU上的361秒。第二个问题与不小心使用全局屏障有关。每个进程在初始化其相应的通信组后执行一个全局屏障。我们精心设计了通信组初始化的顺序，以最大限度地减少对全局屏障的需求。这种方法将全局屏障的时间复杂度从O(n^2)降低到O(n)。优化后，初始化时间在2048个GPU上减少到不到5秒，在超过一万个GPU上减少到不到30秒。

集体通信组初始化确保所有GPU工作节点可以相互通信。在小规模分布式系统中开销可以忽略，通过测试得出在2048个NVIDIA Ampere GPU上初始化时间达到了1047秒，对常规测试和迭代开发构成了重大障碍。使用非阻塞和异步Redis替换了单线程、阻塞读写的方式运行的TCPStore将初始化时间减少到了2048个GPU上的361秒。后精心设计了通信组初始化的顺序，以最大限度地减少对全局屏障的需求，初始化时间在2048个GPU上减少到不到5秒，在超过一万个GPU上减少到不到30秒。

3.6 网络性能调优

原文翻译：
我们分析了3D并行性中跨机器的流量，并设计了提高网络性能的技术。
网络拓扑。我们的数据中心网络是基于Broadcom Tomahawk 4芯片构建的高性能交换机。每个Tomahawk芯片的总带宽为25.6Tbps，拥有64个×400Gbps端口。三层交换机以CLOS（胖树）类似的拓扑结构连接，以连接超过10,000个GPU。对于每层的交换机，下行链路（downlink）和上行链路（uplink）之间的带宽比例为1:1。也就是说，32个端口用作下行链路，32个端口用作上行链路。该网络提供了高带宽和小直径，每个节点都能在有限的跳数内与其他节点通信。

数据中心网络的物理布局和设计

原文翻译：
减少ECMP哈希冲突。我们精心设计了网络拓扑并安排网络流量以减少ECMP哈希冲突。首先，在机架顶部（ToR）交换机级别，一个400G下行端口被特定的AOC电缆分割成两个200G下行端口。由于每个上行链路的带宽是下行链路的两倍，冲突概率得以降低。其次，服务器上的八个200G网络接口卡（NICs）以多轨方式连接到八个不同的交换机。通过同一组ToR交换机连接的GPU服务器数量可以达到64个。我们策略性地安排训练任务中的数据密集型节点在同一个机架顶部（ToR）交换机下运行。这种方法显著减少了通信所需的交换机跳数，并进一步降低了ECMP哈希冲突的概率。
ECMP（Equal-Cost Multi-Path）哈希冲突是指在网络中，多个数据包可能因为哈希算法而被发送到同一个链路，导致该链路过载，而其他链路却未被充分利用。

通过分割下行端口、多轨连接和策略性调度降低ECMP哈希冲突的可能性。

分割下行端口：将一个高速下行端口分割成两个较慢的端口，可以平衡流量，减少单一链路的过载。
多轨连接：服务器的多个网络接口卡连接到不同的交换机，这样可以分散流量，避免单一链路过载。
策略性调度：通过将数据密集型节点安排在同一个ToR交换机下，可以减少数据在交换机之间的跳数，降低ECMP哈希冲突的可能性。

原文翻译：
拥塞控制。在分布式训练中，当在大规模使用默认的DCQCN（数据中心拥塞通知）协议时，全员通信可能导致拥塞和优先流控制（PFC）水平的提高[18]。过度使用PFC可能导致队头（HoL）阻塞[19]，从而降低网络吞吐量。为了缓解这些问题，我们开发了一种算法，该算法结合了Swift[20]和DCQCN的原则，将往返时间（RTT）的精确测量与显式拥塞通知（ECN）的快速拥塞响应能力相结合。这种方法显著提高了吞吐量，并最小化了与PFC相关的拥塞。
ECN：显式拥塞通知（ECN）是一种网络协议，它允许网络设备在检测到拥塞时通知发送方，从而可以采取行动避免拥塞。 PFC：是一种网络拥塞控制机制，它用于在数据中心和高性能计算环境中管理网络流量，以避免拥塞和提高网络效率。
两者在控制机制上的不同如下：PFC：是一种基于优先级的流量控制机制。它允许网络在检测到拥塞时，通过发送暂停（pause）帧来通知发送端减少或停止发送某些优先级的数据流，以此来缓解拥塞。 ECN：是一种通知机制，它在检测到拥塞时，通过发送ECN帧来通知发送端网络即将发生或正在发生拥塞，从而触发发送端采取相应的减少发送速率的措施。

通过将往返时间（RTT）的精确测量与显式拥塞通知（ECN）的快速拥塞响应能力相结合，避免过度使用PFC可能导致队头（HoL）阻塞进而导致降低网络吞吐量。

原文翻译：
重传超时设置。NCCL中的参数可以设置以控制重传计时器和重试次数。我们调整这些参数以便在链路闪烁（link flapping）时快速恢复。为了进一步减少恢复时间，我们在网络接口卡（NIC）上启用了adap_retrans功能。此功能允许在更短的间隔内进行重传，并在链路闪烁周期短时帮助更快速地恢复传输。

重传超时应对链路闪烁现象。在NCCL中调整可控制重传计时器和重试次数的参数，并网络接口卡（NIC）上启用了adap_retrans功能，帮助在链路闪烁期间快速恢复。

四、容错能力

原文翻译：
随着集群集扩展到数万个GPU，软件和硬件故障几乎不可避免。我们引入了一个健壮的训练框架，用于LLM训练，它能够实现自动故障识别和快速恢复，使得在对正在进行的训练任务影响微乎其微的情况下，通过最小的人工干预实现容错。

4.1健壮的训练工作流

原文翻译：
如图5所示，在接收到提交的训练任务后，驱动程序通过与自定义的Kubernetes进行接口处理，为每个执行器分配计算资源并启动相应的Pod。一个执行器管理一个节点。一旦执行器完成了一系列初始化任务，它就在每个GPU上创建训练进程，并启动一个健壮的训练守护进程，该守护进程定期向驱动发送心跳信号。这些心跳信号封装了各种形式的信息，以实现实时异常检测并发出预警（第4.2节）。当驱动进程检测到特定训练进程的异常状态，或者在预定义的时间窗口内未能从执行器接收到心跳信号时，会触发故障恢复程序。驱动将暂停所有执行器上的进行中训练任务，并命令它们执行一系列自检诊断（第4.3节）。轻量级且全面的诊断测试，覆盖大多数常见的软硬件故障。一旦发现问题节点，驱动将上传被阻塞节点的IP地址，以及在它们上运行的Pod的信息，给Kubernetes，它将去除故障节点，并用通过诊断测试的健康节点补充集群集。此外，我们提供了一个用户界面，允许手动去除节点，特别是那些通过手动分析确定的节点，如第5节所述。恢复过程完成后，驱动从最新的检查点恢复训练。我们优化了检查点和恢复过程，以最小化训练进度的损失（第4.4节）。

本段指出执行器完成初始化后，在GPU创建训练进程的同时会启动守护进程。该守护进程定时向驱动程序发送封装了不同信息（正常、预警等）的心跳信号以达到实时常检测的目的。若发生异常或心跳信号未按时到达，触发故障回复程序。驱动暂停训练任务并进行自检，直至发现异常节点，将其去除并补充新节点。同时提供用户界面供手动去除节点。替换完成后，驱动从最新的检查点恢复训练。

4.2 数据收集与分析

原文翻译：
心跳信号包括执行器的基本信息，如IP地址、Pod名称和硬件信息等。此外，还报告训练进程的当前状态，使驱动程序能够及时检测任何明显的异常。训练进程的stdout/stderr日志也被包括在内。它们将被聚合、过滤并即时分析。如果检测到特定的警告或错误关键字，驱动程序将报告实时诊断信息。此外，还包括RDMA流量指标，作为网络利用率和效率的指标。训练过程中的一些异常可能不会表现为明显错误，给人一种训练按预期进行的假象。在这种情况下，RDMA流量指标是一个关键指标。鉴于训练任务的周期性，每个步骤的网络流量特征应该表现出类似的模式。因此，RDMA流量的任何显著下降或异常波动都是潜在异常的信号。在检测到这种不规则性时，驱动程序将发出警报以供手动调查。如果流量完全停止，驱动程序将自动启动故障恢复程序。为了增强对训练稳定性和性能的监控，我们开发了一个精确到毫秒级别的监控系统。采用不同级别的监控来跟踪各种指标。第二级监控通常用于评估整体健康状况，并排除对训练的常见配置影响。例如，ECN/PFC/QoS配置、链路闪烁或任何其他网络接口卡（NICs）问题。另一方面，毫秒级监控用于确定网络是否拥堵，以及数据并行性和管道并行性的数据传输速度是否已达到其物理极限。

在通过心跳信号检测异常之外，开发毫秒级分级监控系统，通过对RDMA流量等指标进行特征监测，当出现显著下降或异常波动时驱动程序发出警报，以供手动检查。若流量完全停止，驱动程序启动故障回复程序。二级监控通常评估整体健康状态

4.3 诊断测试

原文翻译：
在自检诊断中，执行时间和准确性之间存在权衡。延长诊断时间可能会对有效训练时间产生负面影响，而高误报率可能导致实际上功能正常的机器被不必要地去除。通过迭代实验和优化，我们已经部署了一套轻量级的诊断测试，这些测试能够有效覆盖在实际训练过程中遇到的广泛的硬件和软件故障。
主机内主机网络测试。为了诊断主机内部网络的潜在瓶颈，我们使用内部开发的工具来进行两种测试。回环测试（Loopback test）测量所有RDMA网卡（RNICs）到主机内各个端点的回环带宽，包括内存节点和GPU。它在主机内进行全网格测试，覆盖所有可能的链路组合。这使我们能够根据端到端的带宽结果推断特定链路的带宽降低和PCIe配置中的不规则性。第二个RNIC到RNIC测试检查同一主机上不同RNIC之间的连接性和带宽性能。这些测试提供了关于RNICs是否满足硬件速度规格以及底层路由配置是否正确配置的洞察。

主机内网络测试，主要对主机内部RDMA网卡到主机内部各端点进行回环带宽，和同主机RDMA网卡之间连接性与带宽性能进行测试。用于检测RDMA 网卡是否满足硬件速度规格以及底层路由配置是否正确配置。

原文翻译：
NCCL测试。为了识别GPU通信中的潜在故障，我们在单个节点内的GPU之间运行一个全对全测试，以观察带宽是否与预期的基准相符。一旦通过主机内通信测试，每个节点还需要与同一ToR（机架顶部）交换机下的邻近机器进行一个全归约测试，以评估节点间GPU通信。\

通过NCCL（NVIDIA Collective Communications Library）测试来确保GPU之间的通信正常。测试分为两个阶段：首先是单个节点内GPU的全对全测试，其次是节点间GPU的全归约测试。

4.4 快速检查点和恢复

原文翻译：
       在识别并驱逐故障机器后，驱动程序需要通过从最近的检查点加载模型权重和优化器状态来恢复训练。确保最新的检查点尽可能接近故障发生时的训练进度状态，对于最小化计算和时间损失至关重要。这要求我们在训练期间增加检查点的频率。然而，我们也希望减少检查点过程引入的延迟，特别是关键路径上的时间，这会阻碍训练进度，从而影响整个系统的吞吐量。
       为了实现快速检查点，我们引入了一个具有两个阶段的优化方法。在第一阶段，每个GPU工作节点将其片上状态写入主机内存，然后继续训练过程。在优化了Pytorch的序列化机制和使用固定内存之后，由于高PCIe带宽，这个过程可以减少到几秒钟，从而最小化的中断正在进行的训练过程。在第二阶段，一个后台进程接管，异步地将状态从主机内存传输到分布式文件系统（我们部署中的HDFS）进行集中维护。将操作解耦为两个阶段允许GPU工作节点在转储状态后几乎立即恢复训练，而更耗时的写入HDFS的过程则被卸载到一个单独的、非阻塞进程中。
       在从检查点恢复的背景下，它处于关键路径上，因为没有最后的检查点，训练就不能开始。瓶颈在于HDFS的带宽，特别是当每个GPU工作节点需要读取其相应的状态分区时。为了缓解这个瓶颈，我们提出了一种优化的数据检索策略。我们认识到多个GPU工作节点经常共享相同的状态分区，例如，同一数据并行组中的工作节点。因此，我们指定组中的一个工作节点从HDFS读取共享的状态分区，从而线性减少负载。然后这个工作节点将状态分区广播给所有共享相同数据的其他GPU工作节点。这种方法有效缓解了HDFS的带宽限制，导致恢复时间大幅减少。

如何获得尽可能接近故障发生时的训练进度状态最新的检查点，对于最小化计算和时间损失至关重要。该方法有两步：首先，GPU将状态写入主机内存并继续训练；其次，后台进程异步地将状态传输到分布式文件系统。此外，因为多个GPU工作节点经常共享相同的状态分区，只需要组中一个节点从HDFS读取共享的状态分区后广播给组内其他共享该数据的工作节点，即可线性减少HDFS的带宽负载。

五、训练故障排除

原文翻译：
尽管我们健壮的训练框架能够自动发现、定位并解决大多数常见故障，但仍存在某些硬件异常，它们以概率性的方式出现，无法通过机器自检发现。一些异常可能会让系统看起来正常运行，但实际上显著降低了训练效率。为了解决这些微妙的情况，我们实施了几个定制的监控和分析工具，旨在支持逐案异常检测。

部分硬件故障具有偶发性，无法自检发现，因此作者开发了相应工具。

5.1 使用CUDA事件监控器进行性能诊断

原文翻译：
       在数万个GPU的规模下，我们观察到，与小规模实验不同，不同的运行表现出不同的计算效率。即使配置相同，这种不一致性仍然存在，如图6所示。我们还观察到，训练任务的性能在这种规模下并不一致。各种训练任务的MFU（模型FLOPs利用率）随着时间的推移逐渐下降。虽然这让我们怀疑个别机器之间的差异，但在单个GPU GEMM（通用矩阵乘法）微基准测试下没有检测到明显的变化。为了诊断这些性能问题，我们开发了一个性能分析工具，该工具记录了每次运行期间每个机器等级上关键代码段的执行时间。与之前的torch profiler或MegatronLM计时器等工具不同，我们的基于CUDA事件方法计时事件。这种方法最小化了CUDA同步的需求，从而防止了性能下降，使我们能够持续在生产训练任务中运行它。这个工具提供了两种可视化模式，并且可以从不同角度分析收集到的数据。
       第一种模式使用热图显示机器之间的时间消耗差异，从不同维度展示，如图7所示。我们收集了设备上计算阶段（前向和反向）的延迟数据，并在步骤上平均延迟。聚合数据使用热图进行可视化。热图揭示了一小部分机器（大约0.5%）在训练期间表现出明显较慢的性能，从而阻碍了整体训练进度。训练效率主要由最慢机器的性能（即落后者）决定，这导致了不同运行之间训练效率的不一致性，因为集群中的机器调度是随机的。在排除这些异常机器后，运行的峰值MFU变得一致。
       另一种模式以跟踪格式从不同分布式视图（数据并行性、流水线并行性、张量并行性）显示机器上的事件时间线。传统的分析器，如PyTorch Profiler，主要设计用于单节点活动分析。这种方法在分布式训练场景中提供的洞察有限，其中执行依赖经常跨越多个节点。通过将不同等级的跟踪跨度聚合到单一时间线上，我们获得了全面的视角，揭示了数据并行等级之间的整体执行顺序、流水线气泡和同步特性。图8展示了我们的分布式跟踪器如何可视化流水线并行性的实际执行，通过跨流水线并行组的事件数据整合，详细说明了不同流水线阶段之间的数据依赖关系。
       每个CUDA事件计时器的数据都存储在远程分析数据库中，允许轻松检索任何步骤事件的详细信息。虽然计时器数据以逐行格式写入本地文件，但一个单独的流处理程序随后实时将此日志文件与Kafka队列同步。分析数据库通过从这个Kafka队列消费数据保持更新，使得可以不中断训练任务的情况下进行即时分析。所有监控功能在实际生产训练期间开启，与训练时间相比，开销可以忽略不计。

本段中作者观察到不同训练任务性能不一致和训练任务MFU随时间的推移逐渐下降。排除机器差异的问题后。开发适用的性能分析工具，该工具基于CUDA事件记录每次运行期间每个机器等级上关键代码段的执行时间。且提供两种可视化模式：第一种模式使用热图显示机器之间的时间消耗差异，通过计算延迟数据揭示哪部分机器性能表现较差。导致训练效率不一致拖慢集群效率，排除异常机器后运行峰值MFU恢复一致。第二种模式跨越多个节点，从数据并行性、流水线并行性、张量并行性等分布式视图上，以跟踪的格式显示机器上的时间线。通过对不同等级的跟踪视图聚合到单一时间线上揭示数据并行等级之间的整体执行顺序、流水线气泡和同步特性。

5.2 3D并行训练可视化

原文翻译：
       随着3D并行性和我们的优化技术（第3节），数据流和任务排序的格局变得极其复杂。每个GPU工作节点可能在任何给定时刻参与多个同步或异步操作，导致它们之间存在复杂的依赖关系。这种复杂性增加了故障诊断的挑战：当单个GPU工作节点遇到故障时，整个节点集群可能在NCCL通信操作中停滞，最终导致全系统超时。从外部看，这种情况表现为通用的阻塞，但根本原因往往埋藏在大量超时消息之下。为了快速定位问题节点，我们让每个GPU工作节点在通信超时时记录自己正在进行中的事件。然后使用这些日志构建基于3D并行设置中的逻辑拓扑的数据依赖性的视觉表示。
       如图7所示，3D并行训练中的集群在逻辑上可以被分割成三个维度：张量并行性、流水线并行性和数据并行性。当我们选择一个特定的GPU工作节点时，它会显示其在逻辑拓扑中的位置、数据流的方向以及它涉及的不同通信操作。重要的是，在发生错误的情况下，如果有任何错误消息，该工具可提供直接访问发生错误的工作节点的错误消息。这为诊断训练异常提供了一个强大的工具，使故障的识别和解决更加迅速。
       考虑前述情况，当有缺陷的GPU在执行NCCL通信操作时概率性地导致阻塞。这种阻塞可以使整个机器挂起，导致其他依赖节点的连锁超时，并最终导致整个训练过程瘫痪。为了迅速识别这些故障节点，我们利用3D并行训练可视化工具。由于等待故障节点而超时的节点将在退出时记录它们的进行中的操作。相比之下，有故障的GPU的节点被挂起，并没有记录任何此类信息。因此，通过检查日志和可视化中的数据流，可以轻松定位这些有问题的节点。一旦识别，这些节点可以通过4.1节中描述的健壮训练框架手动隔离并标记以进行维护。

当单个节点发生错误时，整个集群都会因大量超时导致在NCCL通信操作中停滞。每个节点在发生通信超时时记录自己正在执行的事件，依靠此记录可构建基于3D并行设置中的逻辑拓扑的数据依赖性的视觉表示。发生错误之后，该工具会直接提供可访问的错误节点的错误消息，可轻松定位错误节点，使故障识别和解决更加迅速。

六、经验

原文翻译：
在本节中，我们描述了MegaScale的部署和操作经验。我们为LLM训练构建了专用的AI集群。多年来，我们已经迭代了多个版本的专用AI集群架构，并且目前正在运营几个具有不同规模和硬件配置的AI集群。我们使用这些AI集群来训练广泛的模型，从计算机视觉和推荐模型到LLMs。随着LLMs的重要性日益增加，我们正在构建更大规模的AI集群以满足LLM训练的需求。截至2023年9月，我们用于LLM训练的生产中最大的AI集群包含超过10,000个NVIDIA Ampere GPU。因为NVIDIA产量不断增加，我们也正在基于最新的NVIDIA Hopper GPU构建大型集群。

本节重在介绍Mega部署与操作经验

6.1 训练性能

原文翻译：
       MegaScale建立在Megatron-LM[7]之上，这是一个最先进的开源LLM训练框架，它整合了3D并行性技术并利用了硬件资源。我们的实验使用了GitHub[21]上的MegatronLM，该框架在2023年1月11日提交，因其稳定性和在我们实验开始时的特性集而被选中。为了进行公平比较，我们对Megatron-LM和MegaScale使用了相同的批量大小。我们使用了两种模型大小：175B参数和530B参数。对于175B和530B模型，我们分别使用了具有六个和三个交错阶段的交错流水线并行调度[22]。所有情况的序列长度为2,048，词汇表大小为64,000。表1显示了模型配置的详细信息。

       可扩展性。图9比较了在训练530B模型时Megatron-LM和MegaScale的表现，我们设置批量大小为GPU数量，并调整学习率以显示MFU结果。我们看到MegaScale的MFU比Megatron-LM高出多达6.1%。随着规模的增加，Megatron-LM的MFU因更多的落后者和通信而下降了1.6%，而MegaScale由于3D并行通信重叠而具有接近线性的可扩展性。
       在表2中，我们通过增加GPU数量并保持恒定批量大小来评估Megatron-LM和MegaScale在175B模型上的强扩展训练性能。这种实验设置更为现实，因为批量大小受到收敛效果的约束，不能随着GPU数量的增加而无限扩展。在所有设置中，MegaScale实现了比Megatron-LM高达1.34倍的速度提升。随着GPU数量的增加，我们观察到MegaScale的MFU从59.1%下降到55.2%。这是预期的，因为批量大小是固定的，随着更多GPU的加入，计算与通信的比例降低。即使在最大的规模，即12,288个GPU上，MegaScale仍然比Megatron-LM高出14%的MFU。对于较小规模的训练，MegaScale相对于基线的速度提升范围从1.23倍到1.32倍。请注意，这里与之前实验中GPU的最大数量差异（例如，12,288与11,200）是由于175B和530B模型的不同3D并行性配置。
       消融研究。我们评估了MegaScale优化技术的有效性。表3显示了在256个GPU上训练175B模型时，不同优化带来的MFU改进分解。基线是原始的Megatron-LM，MFU为47.7%。值得注意的是，在这次评估中，网络优化对Megatron-LM和MegaScale都是开启的。我们首先将两种算法技术，parallel transformer block和sliding window attention，应用于Megatron-LM，实现了5.6%的MFU改进。通信是大规模LLM训练的主要瓶颈，MegaScale的3D并行通信重叠隐藏了开销，并通过6.2%的MFU加速了训练。我们进一步采用了efficient operators，获得了1.7%的加速。其他优化，如data pipeline optimizations和6.3节中提到的有问题的代码消除，进一步实现了1.1%的性能提升。最后，我们使用LAMB优化器将批次大小从256扩展到768，这显著延长了交错流水线并行性中的稳定阶段，并实现了3.0%的MFU改进。总的来说，采用所有这些优化，MegaScale在MFU数量上比基线高出17.6%。

6.2 模型收敛性和稳定性

原文翻译：
模型收敛性微基准测试。我们首先进行微基准测试实验，以验证算法技术不会影响模型收敛性。由于资源限制，微基准测试在13B模型上进行。如图10a所示，尽管MegaScale采用了包括并行变换器块和滑动窗口注意力在内的算法技术，但在训练超过100B个tokens时，它与基线相比实现了相当的损失结果。我们还评估了LAMB优化器的效果，如图10b所示，这表明LAMB优化器在批量大小为ADAM优化器的四倍时，在大约250B个tokens后实现了相同的损失。基于这些观察，我们在生产训练中开启了所有算法优化。

真实生产LLM训练中的模型收敛性和稳定性。我们展示了一个真实生产运行中的模型收敛性和稳定性。这个运行训练了一个拥有数千亿参数的专有模型，在数万亿个tokens上。这个运行使用了超过10,000个GPU，并持续了几周。图11显示损失继续收敛，不同颜色表示训练已重启。在这次运行的几周内，我们经历了100多次以上的训练重启。借助健壮的训练框架，超过90%的软件和硬件故障被自动识别并修复，这些技术在第4节中详细描述。其余的问题在第5节中描述的故障排除工具的帮助下得到处理。

6.3 发现并修复的问题

原文翻译：
       我们对上述生产训练任务数周内的故障记录进行了分析。我们的发现表明，超过90%的异常情况是通过我们健壮的训练框架自动检测、定位并恢复的，例如CUDA错误和段错误。检测故障和执行诊断测试所需的平均时间少于10分钟。此外，系统能够在15分钟内从最新的检查点赶上崩溃前的训练进度，保持超过90%的有效训练时间率，这是通过迭代次数乘以迭代训练时间除以总训练时间来计算的。下面我们将展示我们在使用第5节中描述的故障排除工具分析和修复一些引人入胜的问题方面的经验。
       计算缓慢的任务。基于我们对CUDA事件计时器的使用，我们在多个实验设置中做出了另一个相关观察。我们注意到特定的主机执行相同的前向计算比其他等级多花费了大约10%的时间。这种在不同实验中的一致性使我们得出结论，问题不在于软件，而是集群中的某些机器固有的问题。在隔离并移除这些有问题的主机后，我们观察到MFU大约提高了0.7%。
       MFU下降。在这种大规模训练实验中，我们观察到的另一个现象是训练效率并没有随着时间的推移而保持一致。相反，随着训练的进行，我们训练任务的MFU逐渐下降。通过对CUDA事件计时器指标的逐步分析，我们注意到了几个关键发现。虽然每次训练步骤所消耗的时间在增加，但前向、反向和优化器计算所花费的时间保持稳定，无论步骤数量如何增加。这使我们推断时间增加必须归因于集体通信开销。通过逆时间顺序检查，我们确定了最后一个集体通信步骤作为数据并行性中的reduce-scatter。如果这个步骤被延迟，每次步骤的总时间就会延长。由于我们观察到网络带宽基本稳定，我们排除了通信速度减慢作为时间增加的因素。根据集体通信的同步特性，这使我们得出一个结论：一些等级比其他等级晚启动reduce-scatter操作，迫使等待最慢的等级赶上。在一个只涉及每个数据并行组两个等级的缩小规模实验中，我们测量了reduce-scatter调用的启动时间，发现它们并不是一致错开的，而是相反地波动。此外，随着执行更多步骤，这个时间错开的大小增加了。具体来说，等级A可能最初落后于等级B，但最终可能超过等级B的速度，并以越来越大的差距领先。最终，所有等级都等待最慢的等级。为了追溯这个时间偏差的根本原因，我们发现差异发生在前向计算阶段。深入代码，我们将这种不规则性归因于一些代码段引起的波动。例如，不规则的垃圾收集可能会对训练过程产生干扰，某些PyTorch操作可能导致性能波动。这些操作在关键路径上，但可能在训练过程中受到影响。在修改或删除那些有问题的代码段后，我们不再观察到MFU的显著下降，如图12所示。
       频繁的网络接口闪烁问题。我们偶尔会遇到由于网络接口频繁闪烁导致训练停滞或训练速度下降的问题。当网络接口闪烁现象发生时，网络接口首先断开，然后再次连接。断开和连接之间的间隔通常持续几秒钟。在断开过程中，所有传输中的数据包将被丢弃。我们学到的第一个教训是，应该明确设置一个较大的超时阈值，否则默认值将使NCCL在网络卡再次连接之前就超时，并返回完成错误。我们学到的第二个教训是，这个问题的根本原因是网络卡、AOC电缆和交换机之间的链接质量差。通过对网络卡信号强度、AOC电缆质量和交换机端信号强度进行低级别的质量控制，可以将闪烁频率降低到一个令人满意的水平。

七、相关工作

原文翻译：
       LLM训练。已经有很多努力投入到预训练LLMs的训练中，包括专有的模型如GPT-3[1]、GPT-4[23]、GShard[24]、PaLM[5]以及许多其他模型[25-29]，以及开源的替代品如OPT[30]、BLOOM[31]、Llama[32]、Llama-2[33]。该领域的现有技术报告主要集中在模型性能比较上，忽略了使此类训练成为可能的系统基础设施的具体细节。本文通过从系统角度分享我们在超过10,000个GPU规模上进行端到端LLM预训练的经验，填补了这一空白。
       预训练后，预训练的基础模型可以进一步微调以更好地适应下游任务。这导致了对话模型[34-37]的出现，以ChatGPT为例。然而，值得注意的是，微调所需的计算能力和数据需求远低于预训练。通过应用量化[38-41]和低秩适应[42]等优化技术，可以有效地用有限的资源完成微调。
       LLM优化。除了本文中提到的技术之外，还有很多其他工作旨在提高LLMs的效率。提出了稀疏或线性注意力[43-45]以使内存消耗大致线性增长。一些研究旨在设计新架构而不是传统的变换器架构来解决效率问题，如RWKV[46]和RetNet[47]。许多最近的研究致力于开发LLMs的通信加速技术。一些工作通过梯度压缩[48]或混合精度训练[49]来减少通信流量，而另一些则安排通信以与计算重叠。许多流行的机器学习框架，如TensorFlow[50]和PyTorch[51]，默认情况下允许通信与反向传播重叠。最近的工作[52-55]通过张量分割进一步将梯度同步与前向计算重叠，但代价是额外的开销。一些工作[56,57]引入了固定的延迟到训练管道中，以实现完全重叠通信和计算。然而，延迟可能会降低模型性能。
       数据中心的诊断工具。已经开发了许多诊断工具来识别和定位数据中心的硬件和软件问题。Pingmesh[58]是一种基于终端主机的主动探测系统。通过发送探测ping数据包并进行数据分析来测量网络范围的RTT（往返时间）和数据包丢失。提供网络范围的服务水平协议（SLAs）并检测包括数据包黑洞和数据包静默丢弃在内的网络问题。EverFlow[59]、LossRadar[60]、NetBouncer[61]利用交换机的能力来诊断详细的网络问题，如网络路径失败或特定网络端口失败。NetBouncer利用IP-in-IP隧道技术进行路径探测。EverFlow需要将网络数据包镜像到一个集中式服务器进行调试。Hostping[62]是一种基于终端主机的诊断系统，专注于主机内部瓶颈。它主动感知复杂的GPU服务器PCIe/NVLINK互连，并进行环回带宽和延迟测试。
       大规模分布式系统的容错性。容错性一直是大规模分布式系统中的一个主要关注点，其中可能发生各种硬件和软件故障。过去已经提出了许多容错技术来满足不同系统和部署场景的需求。反应性容错技术用于在故障发生时减少对系统的影响。这类技术有很多，如重试[63]、复制[63]、检查点[64]和消息记录[65]。这些技术需要一些系统开销来从故障中恢复。主动容错技术保持健康的组件作为备份，以替代故障组件，避免了从故障和错误中恢复的需要，例如预迁移[66-68]和负载均衡[69]。然而，这些方法通常假设故障是可预测的，而在真正的大规模分布式系统中，由于系统的复杂性，预测故障是具有挑战性的。

八、结论

原文翻译：
在本文中，我们深入探讨了MegaScale的设计、实现和部署，这是一个为在超过10,000个GPU规模上训练LLMs而构建的生产级系统。MegaScale利用算法-系统共同设计来优化训练效率。在12,288个GPU上训练一个175B的LLM模型时，MegaScale实现了55.2%的MFU，比Megatron-LM提高了1.34倍。我们强调了在整个训练过程中对容错性的需求，并实现了一个量身定制的健壮训练框架，以自动定位和修复故障。我们提供了一套全面的监控工具，用于深入观察系统组件和事件，便于识别复杂异常的根本原因。我们相信，我们的工作不仅为那些从事LLM训练的人提供了实用的见解，而且也为未来的LLM系统研究铺平了道路。