原论文链接：https://arxiv.org/abs/2402.15627
摘要
我们介绍了MegaScale的设计、实现和工程经验，这是一个用于训练大语言模型（LLMs）的生产系统，其规模超过10,000个GPU。在这个规模上训练LLMs带来了前所未有的训练效率和稳定性挑战。我们采取全栈方法，共同设计算法和系统组件，涵盖模型块和优化器设计、计算与通信重叠、操作符优化、数据管道和网络性能调优。在生产中，保持整个训练过程的高效率（即稳定性）是一个重要考虑因素，因为LLM训练作业的持续时间很长。许多严重的稳定性问题只在大规模时才显现出来，深入的可观察性是解决这些问题的关键。我们开发了一套诊断工具，用于监控堆栈深处的系统组件和事件，识别根本原因，并得出有效的技术实现容错和减轻落后者的影响。在12,288个GPU上训练一个175B LLM模型时，MegaScale实现了55.2%的模型FLOPs利用率（MFU），与Megatron-LM相比，MFU提高了1.34倍。我们分享了识别和修复故障和落后者的操作经验。我们希望通过从系统的角度阐述问题和分享我们的经验，这项工作能够激发未来的LLM系统研究。
1 引言
大语言模型（LLMs）[1]已经成为人工智能（AI）领域的变革性技术。LLMs的最新进展显著提高了它们的能力。LLMs在机器翻译、文本摘要和对话等多个领域展示了巨大的潜力[2]。作为一家服务数十亿用户的公司，我们一直在积极地将AI整合到我们的产品中，并将LLMs作为塑造我们产品未来的高优先级。
训练LLMs是一项艰巨的任务，需要巨大的计算资源。伸缩法则[3]规定，模型大小和训练数据大小是决定模型能力的关键因素。为了实现最先进的模型能力，许多努力都致力于在数千亿甚至数万亿的标记上训练具有数千亿甚至数万亿参数的大型模型。例如，GPT-3[4]有1750亿参数，PaLM[5]有5400亿参数。这个领域的主要参与者构建了数万个GPU的大规模AI集群来训练LLMs。
将LLM训练扩展到数万个GPU带来了前所未有的挑战。作为我们产品的核心，我们在训练深度神经网络（DNNs）方面有丰富的经验。然而，像ResNet[6]这样的模型只需要数十或数百个GPU。与这些模型相比，训练LLMs的规模是无与伦比的。
虽然我们不是第一次构建和运营大规模GPU集群，但这些集群通常由许多训练作业共享。现在，在LLM训练的背景下，一个作业就占用了数万个GPU并占用了所有资源。LLM训练的规模从系统的角度引入了两个具体挑战。
第一个挑战是在规模上实现高训练效率。模型FLOPs利用率（MFU）是观察到的吞吐量与假设峰值FLOPs为100%时的理论最大吞吐量的比率[7]。这是一个标准的评估训练效率的指标，直接转化为端到端训练速度。LLM训练并不是令人尴尬的并行。为了训练一个LLM，模型被分割在GPU上，GPU之间进行大量通信以取得进展。除了通信，操作符优化、数据预处理和GPU内存消耗等因素也显著影响MFU。
第二个挑战是在规模上实现高训练稳定性，即在整个训练过程中保持高训练效率。从生产的角度来看，稳定性尤为重要，因为LLMs的训练时间很长。用一万亿个标记训练一个LLM可能需要数周时间。这个规模和时间比常规DNN训练作业的规模和时间大得多。对于LLM训练来说，故障和落后者是常态而不是例外。在这样的规模下，故障和落后者的后果是毁灭性的。故障非常昂贵，考虑到规模之大，减少恢复时间至关重要。一个落后者不仅影响自己的工作，还会拖慢涉及数万个GPU的整个作业。
在本文中，我们介绍了MegaScale的设计、实现和工程经验，这是一个用于大规模训练LLMs的生产系统。MegaScale使我们能够将LLM训练扩展到超过10,000个GPU。我们能够利用大量GPU的力量，以高训练效率和稳定性训练LLMs。在构建和运营MegaScale时，我们应用了两个系统原则：算法-系统共同设计和深入可观察性。
MegaScale是一个专门为LLM训练定制的系统。算法-系统共同设计是最大化专用系统性能的关键原则，在计算机系统中得到了广泛应用。我们将这一原则应用于LLM训练的MegaScale，采用全栈方法涵盖了所有重要的系统组件。
我们对模型架构进行了多项修改，并结合了有效的优化技术，包括并行transformer块[5]、滑动窗口注意力[8]和LAMB优化器[9]。我们利用混合并行策略，结合数据并行、流水线并行、张量并行和序列并行。重要的是，我们根据每种并行策略的模式设计了定制技术，以最大化通信和计算之间的重叠。我们应用预取和基于树的加载来优化数据管道。我们利用非阻塞异步操作，并消除了大规模集体通信组初始化的全局屏障。我们设计了自定义网络拓扑，减少了ECMP哈希冲突，定制了拥塞控制，并调整了重传超时参数以提高网络性能。
大规模系统中的稳定性问题，包括故障和落后者，众所周知难以诊断和修复。许多严重的稳定性问题只在大规模时才显现出来，可能源于堆栈深处的软件和硬件故障。鉴于系统的规模和复杂性，手动识别和解决每个问题是不可行的。我们应用深入可观察性的原则来构建一套诊断工具。通过“深入可观察性”，我们指的是一种全面的监控和可视化策略，它超越了表面级别的指标，收集系统堆栈每个组件的详细、细粒度数据，旨在创建系统性能的多维视图。
这套工具允许我们诊断系统并识别根本原因，揭示导致稳定性问题的复杂相互作用和依赖关系。我们开发了一个健壮的训练框架来自动化故障定位和恢复。我们设计了包含各种信息形式的心跳消息，以便于实时异常检测并提供早期警告。我们实施了一系列诊断测试来识别导致中断的节点。我们优化了检查点和恢复程序以减少中断。为了解决由落后者引起的微妙情况，我们开发了一个性能分析工具来记录细粒度的CUDA事件，并从分布式视图生成系统范围的热图和时间线跟踪，并开发了一个3D并行训练可视化工具，以显示用于诊断的秩之间的数据依赖关系。
MegaScale已部署在我们的数据中心，用于训练我们产品中的LLMs。多年来，我们已经构建了几个不同规模和硬件配置的AI集群。我们最大的AI集群拥有超过10,000个GPU。在训练效率方面，MegaScale在12,288个GPU上训练标准175Btransformer模型时实现了55.2%的MFU，与最先进的开源训练框架Megatron-LM[10]相比提高了1.34倍。在模型收敛和稳定性方面，我们展示了MegaScale在数周内训练一个拥有数千亿参数的专有模型在多万亿标记上的实时生产运行。在这几周内，损失继续收敛，MegaScale在出现故障的情况下修复和恢复训练过程超过100次。我们还分享了诊断和修复一些有趣问题的经验。我们正在GitHub上开源那些可以惠及社区的组件。
2 背景
LLMs的训练以其庞大的模型架构和海量数据集为特征，计算密集度高。并行策略将训练过程分布在多个设备上。
数据并行。它在多个设备上复制模型和优化器状态，数据均匀分配给所有设备。每个模型副本并行执行前向和后向传播计算。每次迭代完成后，所有模型副本同步以更新模型。零冗余优化器（ZeRO）[11]不是复制模型状态（如优化器状态、梯度和参数），而是将这些状态在每个数据并行进程中分片。因此，传统的聚合梯度的all-reduce操作被分解为单独的reduce-scatter和all-gather操作。这是因为每个数据并行进程只保留总状态的一部分。ZeRO分为三个逐步优化阶段。值得注意的是，第二阶段通常被采用来分片优化器状态和梯度，同时确保不引入额外的通信开销（图1）。
流水线并行。它将模型层分布在多个设备上，每个设备拥有模型的一部分。同时，每个训练批次被细分为多个微批次进行流水线执行。为了减少流水线气泡，提出了各种流水线调度策略，例如GPipe[12]、PipeDream 1F1B[13]等。Megatron-LM[7]采用了交错的1F1B调度。每个工作器上的每个流水线阶段被细分为多个虚拟阶段，这代表了模型的一个子集，称为模型块。最初，工作器进入热身阶段，执行有限数量的飞行微批次的前向传递。热身之后，每个工作器进入稳定阶段，工作器执行一次前向传递，然后执行一次后向传递，通常缩写为1F1B。在完成一个批次后，工作器在冷却阶段完成任何剩余的飞行微批次的后向传递。图2展示了一个三阶段流水线，每个阶段进一步分为两个虚拟阶段。
张量并行。它将单个操作符分布在多个设备上，每个设备并行执行计算的一部分。根据特定的分区策略及其与模型中先前和后续操作符的关系，分区可能需要参与的GPU之间进行通信，以分割输入然后合并输出。例如，我们可以在多个GPU之间分割MLP和自注意力块中的GEMM，以利用更多的计算单元。一些其他操作，如LayerNorm和Dropout，计算强度较低，但需要相当数量的激活内存。提出了另一种称为序列并行的张量并行形式，以沿序列维度分布这些操作符，有效减少激活内存占用。
并行策略的组合。这些并行策略可以组合成3D并行，以在许多GPU上扩展LLMs的训练[10]。鉴于张量并行相关的高通信开销，最好将此类通信限制在单个集群节点内。相反，数据并行和流水线并行更适合节点间通信。在这种情况下，我们选择优先构建数据并行组而不是流水线并行，这可以减轻数据并行的跨小节点通信。
3 大规模高效训练
在LLMs领域，大规模高效训练变得至关重要。随着我们深入更深层次和更广泛的模型，计算需求急剧增加。在不损害模型准确性的情况下处理这些计算需求，需要采用最先进的算法优化、通信策略、数据管道管理和网络性能调优技术。本节深入探讨了用于优化大型模型训练的方法，以实现大规模训练的高效率。
3.1 算法优化
我们在算法层面进行了一些修改，并结合了最近的优化，以提高训练效率，同时不影响准确性。我们在§6.2中验证了这些技术对模型收敛性的影响。
并行transformer块[14]。我们采用transformer块的并行版本，代替标准的序列化公式。具体来说，transformer块的标准公式可以从
y = x+MLP(LN(x+Attention(LN(x)))) (1)
重新格式化为
y = x+MLP(LN(x)) +Attention(LN(x)) (2)
这种方法使得注意力块和MLP块的计算可以并行执行，从而减少了计算时间。先前的工作[5]表明，这种修改不会降低具有数千亿参数的模型的质量。
滑动窗口注意力（SWA）。滑动窗口注意力[8]是一种稀疏注意力机制，它在输入序列中的每个标记周围使用固定大小的窗口。计算复杂度为O(s×w)，其中s是输入序列长度，w是固定窗口大小。滑动窗口注意力比全自注意力更高效，其计算复杂度为O(s×s)，因为w≪s。
过去的工作[8]和我们的微基准测试（§6.2）表明，通过堆叠这种窗口化注意力的层，可以保留整个输入的信息，同时创建大的感受野。这使得训练速度更快，同时不影响准确性。
LAMB优化器。大规模的高效训练通常受到批量大小限制的阻碍。特别是，增加批量大小可能会对模型收敛产生不利影响。LAMB优化器[9]已被证明能够使BERT的训练批量大小扩展到64K，而不影响准确性。在LLM环境中，我们的实验发现LAMB可以将批量大小扩展到4×，而不会损失准确性。通过交错的流水线并行，原始调度在训练四个步骤时包含4个vp−1m流水线气泡[7]，而训练一个步骤的4×批量大小的流水线气泡是1vp−14m。因此，MegaScale通过LAMB优化器减少了87.5%的流水线气泡。
3.2 三维并行中的通信重叠
为了减少迭代时间，我们系统地分析了三维并行中所有操作符之间的计算与通信依赖关系，并设计了技术来隐藏所有非关键路径操作的开销。在数据并行中的重叠。如图1所示，对于数据并行，两个主要的通信操作脱颖而出。一个是all-gather操作，它在前向传递期间从其他数据并行等级的工作者获取最新的模型参数。另一个是reduce-scatter操作，它在后向传递期间收集梯度。
在三维并行中，单个设备可能托管多个模型块。重叠是基于模型块实现的，以最大化带宽利用率。all-gather操作在模型块的前向传递之前触发，reduce-scatter操作在它的后向传递之后开始。这导致了一个挑战，即第一个all-gather操作和最后一个reduce-scatter操作无法隐藏。受到PyTorch FSDP [15]的启发，初始的all-gather操作在每次迭代的开始时被预取，允许它与数据加载操作重叠，有效地将通信时间减少1/(2 * vpp_size)。
我们还首先启动高优先级的通信以最大化重叠。通信操作符的优先级由依赖于通信结果的相应计算操作符的顺序决定。
流水线并行中的重叠。流水线并行具有点对点的发送/接收通信。MegaScale使用在2中提到的交错1F1B调度方法。我们注意到，在热身阶段，前向传递仅依赖于其先前的接收。因此，我们解耦了通常一起实现并可能被较慢的一个阻塞的发送和接收。通过打破这种依赖关系，我们使得发送操作能够与计算重叠，如图4左半部分所示。冷却阶段可以看作是热身阶段的逆过程，允许应用相同的技术。至于稳定阶段，前向和后向计算都与相邻的通信操作无关。以后向为例，如图4右半部分所示，它的先前接收是为了下一个前向计算，而发送是为了前一阶段的后向计算。因此，发送和接收操作可以异步启动，与计算重叠。
张量/序列并行中的重叠。张量并行通常用于在计算密集型操作中划分权重，而像LayerNorm和Dropout这样的操作则沿序列维度划分以节省GPU内存。这需要在GPU之间进行all-gather和reduce-scatter操作以收集输入和重新分配输出。图3a展示了并行transformer块架构中的这种通信模式。这里两个通信操作符在关键路径上。为了消除这种开销，我们选择将all-gather和reduce-scatter与FFN路径上的并行线性操作融合（图3b）。由于FFN路径上的GEMM内核较大，通信可以更好地隐藏。我们将GEMM内核分解成小块，并与通信一起流水线执行（图3c）。这种策略也可以在后向传递中类似地应用。
3.3 高效操作符
尽管MegatronLM中的GEMM操作符已经进行了优化，但我们在其他操作符中发现了进一步增强的机会。对于注意力部分，我们采用了FlashAttention-2 [16]，它改进了不同线程块和warp之间的工作分配。对于LayerNorm和GeLU，我们观察到它们由先前实现中的细粒度内核组成。通过将这些内核融合在一起，我们减少了与启动多个内核相关的开销，并有助于优化内存访问模式，从而实现更好的性能。
3.4 数据流水线
数据预处理和加载经常被忽视。然而，这些操作在每个训练步骤开始时创造了不可忽视的GPU空闲时间。优化这些操作对于训练过程的效率至关重要。
异步数据预处理。数据预处理不在关键路径上。因此，当GPU工作者在每个训练步骤结束时同步梯度时，可以开始后续步骤的数据预处理，这隐藏了预处理的开销。
冗余数据加载器消除。在分布式训练的典型数据加载阶段，每个GPU工作者都配备了自己的数据加载器，负责将训练数据读入CPU内存，然后转发到GPU。这导致工作者之间为磁盘读取带宽竞争，从而创建瓶颈。值得注意的是，我们观察到，在LLM训练设置中，同一台机器内的GPU工作者处于相同的张量并行组。因此，它们对每次迭代的输入本质上是相同的。基于这一观察，我们采用了两层基于树的方法。我们在每台机器上使用一个专用的数据加载器将训练数据读入共享内存。随后，每个GPU工作者负责将必要的数据复制到自己的GPU内存。这消除了冗余读取，并显著提高了数据传输的效率。
3.5 集体通信组初始化
在分布式训练中，初始化阶段涉及在GPU工作者之间建立NVIDIA集体通信库（NCCL）通信组。由于这种开销在小规模场景中相对较小，因此默认使用torch.distributed。随着GPU数量扩展到超过一万个，naive实现引入的开销变得无法忍受。我们在§6中对同一AI集群进行了实验，我们的实证测量表明，在2,048个NVIDIA Ampere GPU上，Megatron-LM的初始化时间大约为1047秒。虽然与训练持续时间相比这可能相对较小，但它对常规测试和迭代开发（例如，在超参数调整和调试中的轻微代码调整）构成了重大障碍。它还妨碍了快速重启和恢复机制的实施。
为了解决这个问题，我们对torch.distributed [17]进行了详细的分析，并确定了过度初始化时间的两个主要原因。第一个问题在于同步步骤，其中每个进程在初始化特定通信组结束时参与了一个屏障操作。这个屏障使用TCPStore，这是Pytorch中的一种内部分布式KeyValue Store实现，它以单线程、阻塞的读写方式操作。我们用Redis替换了TCPStore，它是非阻塞和异步的。这将2,048个GPU上的初始化时间减少到361秒。第二个问题与全球屏障的不慎使用有关。每个进程在初始化其相应的通信组后执行一个全局屏障。我们精心设计了通信组的初始化顺序，以最小化全球屏障的需求。这种方法将全局屏障的时间复杂度从O(n^2)降低到O(n)。通过这些优化，2048个GPU上的初始化时间减少到5秒以下，而在超过10,000个GPU上减少到30秒以下。
3.6 网络性能调优
我们分析了三维并行中跨机器的流量，并设计了技术来提高网络性能。
网络拓扑。我们的数据中心网络是基于Broadcom Tomahawk 4芯片构建的高性能交换机。
每个Tomahawk芯片的总带宽为25.6Tbps，具有64×400Gbps端口。三层交换机以CLOS类似的拓扑连接，以连接超过10,000个GPU。
每层交换机的下行链路和上行链路的带宽百分比为1:1。也就是说，32个端口用作下行链路，32个端口用作上行链路。网络提供了高带宽和小直径。每个节点都可以在有限的跳数内与其他节点通信。
减少ECMP哈希冲突。我们精心设计了网络拓扑，并调度网络流量以减少ECMP哈希冲突。首先，在机架顶部（ToR）交换机级别，一个400G下行链路端口被分成两个具有特定AOC电缆的200G下行链路端口。由于每个上行链路的带宽是下行链路的两倍，冲突概率降低了。其次，服务器上的八个200G NIC以多轨方式连接到八个不同的交换机。通过同一组ToR交换机连接的GPU服务器数量可以达到64。我们策略性地调度我们训练任务中的数据密集型节点在同一个机架顶部（ToR）交换机下运行。这种方法显著减少了通信所需的交换机跳数，并进一步降低了ECMP哈希冲突的概率。
拥塞控制。在分布式训练中，当规模使用默认的DCQCN [19]协议时，所有到所有的通信可能会导致拥塞和优先级流控制（PFC）[18]水平升高。过度使用PFC可能会导致头部阻塞（HoL）[19]，从而降低网络吞吐量。为了缓解这些问题，我们开发了一个算法，结合了Swift [20]和DCQCN的原则，该算法将往返时间（RTT）的精确测量与显式拥塞通知（ECN）的快速拥塞响应能力相结合。这种方法显著提高了吞吐量，并最小化了与PFC相关的拥塞。
重传超时设置。NCCL中的参数可以设置以控制重传定时器和重试次数。我们调整这些参数以在链路抖动时快速恢复。为了进一步减少恢复时间，我们在NIC上启用了adap_retrans功能。这个功能可以在更短的间隔内进行重传，并在链路抖动周期短时帮助更快地恢复传输。
4 容错性
随着训练集群扩展到超过数万个GPU，软件和硬件故障几乎不可避免。我们为LLM训练引入了一个健壮的训练框架，实现了自动故障识别和快速恢复，使得在最小化人为干预和对正在进行的训练任务影响的情况下实现容错性。
4.1 健壮的训练工作流程
如图5所示，在接收到提交的训练任务后，驱动进程与自定义的Kubernetes接口，分配计算资源并为每个执行器启动相应的Pod。一个执行器管理一个节点。一旦执行器完成了一系列的初始化任务，它就在每个GPU上创建训练进程和一个健壮的训练守护进程，该守护进程定期向驱动发送心跳。这些心跳封装了各种形式的信息，以实现实时异常检测和早期警告（§4.2）。当驱动进程检测到特定训练进程的异常状态，或者在预定义的时间窗口内未收到执行器的心跳时，它会触发故障恢复程序。驱动将暂停所有执行器中的正在进行的训练任务，并命令它们运行一系列自我检查诊断（§4.3）。这些诊断测试被精心设计为轻量级但全面，涵盖了大多数常见的硬件和软件故障。一旦识别出问题节点，驱动将提交要被封锁的节点的IP地址，以及在这些节点上运行的Pod的信息，到Kubernetes，Kubernetes将驱逐故障节点，并用通过我们诊断测试的健康节点补充集群。此外，我们提供了一个用户界面，允许手动驱逐节点，特别是对于那些通过手动分析识别的节点，如§5所述。恢复过程完成后，驱动从最新的检查点恢复训练。我们优化了检查点和恢复过程，以最小化训练进度的损失（§4.4）。
4.2 数据收集与分析
心跳消息包括执行器的基本信息，如IP地址、Pod名称和硬件信息等。此外，还报告训练进程的当前状态，使驱动程序能够及时检测到任何明显的异常。训练进程的标准输出/标准错误日志也包含在内。它们将被实时聚合、过滤和分析。如果检测到特定的警告或错误关键词，驱动程序将报告实时诊断信息。此外，还包括RDMA流量指标，作为网络利用率和效率的指标。训练过程中的一些异常可能不会表现为明确的错误，给人一种训练按预期进行的假象。在这种情况下，RDMA流量指标是一个关键的指标。鉴于训练任务的周期性，每一步的网络流量特征应该表现出类似的模式。因此，RDMA流量的任何显著下降或异常波动都是潜在异常的信号。一旦检测到这种不规则性，驱动程序将发出警报以供手动调查。如果流量完全停止，驱动程序将自动启动故障恢复程序。
为了增强对训练稳定性和性能的监控，我们开发了一个精度达到毫秒级的监控系统。采用不同级别的监控来跟踪各种指标。第二级监控通常用于评估整体健康状况，并排除对训练的常见配置影响。例如，ECN/PFC/QoS配置、链路抖动或任何其他NIC问题。另一方面，毫秒级监控用于确定网络是否拥塞，以及数据并行和管道并行的数据传输速度是否达到了物理极限。
4.3 诊断测试
在自我检查诊断中存在执行时间和准确性之间的权衡。延长的诊断持续时间可能会对有效训练时间产生不利影响，而高误报率可能导致实际上功能正常的机器被不必要地排除。通过迭代实验和优化，我们部署了一系列轻量级诊断测试，有效地覆盖了实际训练过程中遇到的广泛的硬件和软件故障。
主机内网络测试。为了诊断主机内网络的潜在瓶颈，我们使用内部开发的工具测试两件事。回环测试测量所有RDMA NIC（RNIC）到各种主机内端点（包括内存节点和GPU）的回环带宽。它在主机内进行全网格测试，覆盖所有可能的链路组合。这使我们能够根据端到端带宽结果推断特定链路的带宽降级和PCIe配置的不规则性。第二个RNIC到RNIC测试检查同一主机上不同RNIC之间的连通性和带宽性能。这些测试提供了关于RNIC是否符合硬件速度规格以及底层路由配置是否正确配置的见解。
NCCL测试。为了识别GPU通信中的潜在故障，我们在单个节点内的GPU之间运行一个全对全测试，观察带宽是否与预期基准一致。一旦通过主机内通信测试，每个节点还在同一ToR交换机下的相邻机器上进行一个all-reduce测试，以评估节点间的GPU通信。
4.4 快速检查点和恢复
在识别并清除故障机器后，驱动程序需要通过加载最近检查点的模型权重和优化器状态来恢复训练。确保最新的检查点尽可能接近故障发生时的训练进度状态至关重要，以最小化计算和时间损失。这要求我们在训练期间增加检查点的频率。然而，我们也希望减少检查点过程引入的延迟，特别是阻碍训练进度的关键路径上的延迟，从而影响整体系统吞吐量。
为了实现快速检查点，我们引入了一个优化的两阶段方法。在第一阶段，每个GPU工作器将其芯片状态写入主机内存，然后继续训练过程。在优化Pytorch的序列化机制和使用固定内存之后，由于高PCIe带宽，这个过程可以减少到几秒钟，从而最小程度地中断正在进行的训练过程。在第二阶段，一个后台进程接管，异步地将状态从主机内存传输到分布式文件系统（在我们的部署中是HDFS）进行集中维护。这种将操作分为两个阶段的方法允许GPU工作器在转储其状态后几乎立即恢复训练，而将更耗时的写入HDFS的过程卸载到一个单独的、非阻塞进程中。
在从检查点恢复的上下文中，它是关键路径，因为没有最后的检查点就不能开始训练。瓶颈是HDFS的带宽，特别是当每个GPU工作器需要读取其对应的状态分区时。为了缓解这个瓶颈，我们提出了一个优化的数据检索策略。我们认识到，多个GPU工作器通常共享相同的状态分区，例如，同一数据并行组中的工作器。因此，我们指定组中的单个工作器从HDFS读取共享状态分区，从而线性减少负载。然后，这个工作器将状态分区广播给所有共享相同数据的其他GPU工作器。这种方法有效地缓解了HDFS的带宽限制，导致恢复时间大幅减少。
5 训练故障排除
尽管我们强大的训练框架能够自动发现、定位并解决大多数常见故障，但仍有一些硬件异常是概率性的，无法通过机器自检发现。有些异常可能使系统看起来正常运行，但实际上显著降低了训练效率。为了解决这些微妙的情况，我们实施了几个定制的监控和分析工具，旨在支持逐案异常检测。
5.1 使用CUDA事件监控进行性能诊断
在数万个GPU的规模上，我们观察到，与小规模实验不同，不同的运行表现出不同的计算效率。即使在相同的配置下，这种不一致性仍然存在，如图6所示。我们还观察到，在这种规模下，训练任务的性能并不一致。各种训练任务的MFU（每秒百万浮点运算次数）随时间逐渐下降。虽然这让我们怀疑个别机器之间的差异，但在单个GPU GEMM 微基准测试下并未检测到明显的差异。
为了诊断这些性能问题，我们开发了一个性能分析工具，该工具记录了运行期间每台机器等级上关键代码段的执行时间。与之前的torch profiler或MegatronLM计时器等工具不同，我们的工具基于CUDA事件方法计时事件。这种方法最小化了CUDA同步的需求，从而防止了性能下降，使我们能够在生产训练作业中一致地运行它。
这个工具提供两种可视化模式，并且可以从不同的角度分析收集到的数据。第一种模式使用热图显示来自不同维度的机器之间的时间消耗差异，如图7所示。我们收集了跨设备的计算阶段（前向和后向）的延迟数据，并平均了跨步骤的延迟。聚合后的数据使用热图进行可视化。热图揭示了一小部分机器（大约0.5%）在训练期间表现出显著较慢的性能，从而阻碍了整体训练进度。训练效率主要由最慢机器的性能（即落后者）决定，导致不同运行之间的训练效率不一致，因为集群内的机器调度是随机的。在排除这些异常机器后，跨运行的峰值MFU变得一致。
另一种模式以追踪格式显示机器上的事件时间线，从不同的分布式视图（数据并行、管道并行、张量并行）展示。传统的分析器，如PyTorch分析器，主要设计用于单节点活动分析。这种方法在分布式训练场景中提供的洞察有限，因为在这些场景中，执行依赖经常跨越多个节点。通过将各种等级的追踪跨度聚合到一个单一的时间线上，我们获得了全面的视角，揭示了数据并行等级之间的整体执行顺序、管道气泡和同步特性。图8展示了我们的分布式追踪器如何可视化管道并行的实际执行，通过整合管道并行组中的事件数据，详细说明了不同管道阶段之间的数据依赖关系。
CUDA事件计时器的每条数据都存储在一个远程分析数据库中，允许轻松检索任何步骤事件的详细信息。虽然计时器数据以逐行格式写入本地文件，但一个单独的流处理程序随后会实时将这个日志文件与Kafka队列同步。分析数据库通过消费这个Kafka队列中的数据保持更新，使得在不中断训练作业的情况下进行实时分析。所有监控功能在实际生产训练期间都已开启，与训练时间相比，开销微不足道。
5.2 三维并行训练可视化
通过三维并行和我们的优化技术（§3），数据流和任务序列化的场景变得极其复杂。每个GPU工作节点可能在任何给定时刻参与多个同步或异步操作，导致它们之间存在复杂的依赖关系。这种复杂性放大了故障诊断的挑战：当单个GPU工作节点遇到故障时，整个节点集群可能会在NCCL通信操作中停滞，最终导致系统范围的超时。从外部看，这种情况表现为一种通用的阻塞，但其根本原因通常被大量超时消息所掩盖。为了快速定位问题节点，我们让每个GPU工作节点在通信超时时记录其正在进行的事件。然后，这些日志被用来构建基于三维并行设置中逻辑拓扑的数据依赖性的视觉表示。
如图7所示，三维并行训练中的集群在逻辑上可以被划分为三个维度：张量并行、流水线并行和数据并行。当我们选择一个特定的GPU工作节点时，它会显示其在逻辑拓扑中的位置、数据流的方向以及它涉及的不同通信操作。重要的是，在发生错误的情况下，如果有任何错误消息，该工具提供了直接访问工作节点错误消息的功能。这作为一个强大的工具，用于诊断训练异常，使得能够更快地识别和解决故障。
考虑前面提到的情况，当有缺陷的GPU在执行NCCL通信操作时概率性地导致阻塞。这种阻塞可以使整个机器挂起，导致其他依赖节点的级联超时，最终导致整个训练过程瘫痪。为了迅速识别这些故障节点，我们利用三维并行训练可视化工具。由于等待故障节点而超时的节点将在退出时记录其正在进行的操作。相比之下，有故障GPU的节点会挂起，不会记录任何此类信息。因此，通过检查日志和可视化中的数据流，可以轻松地定位这些问题节点。一旦识别出来，这些节点可以通过强大的训练框架手动隔离并标记以进行维护，如4.1节所述。
6 经验
在本节中，我们描述了我们在MegaScale部署和运营的经验。我们为LLM训练构建了专用的AI集群。多年来，我们已经迭代了多个版本的专用AI集群架构，并且目前运营着多个具有不同规模和硬件配置的AI集群。我们使用这些AI集群来训练各种模型，从计算机视觉和推荐模型到LLM。随着LLM的重要性日益增加，我们正在构建更大的AI集群以满足LLM训练的需求。截至2023年9月，我们生产中用于LLM训练的最大AI集群包含超过10,000个NVIDIA Ampere GPU。我们也正在基于最新的NVIDIA Hopper GPU构建大型集群，因为NVIDIA正在增加生产。
6.1 训练性能
MegaScale是建立在Megatron-LM [7]之上的，这是一个集成了三维并行技术并利用硬件资源的最新开源LLM训练框架。我们的实验使用了Github [21]上的Megatron-LM（提交哈希：285068c8），选择它是因为在我们几个月前的实验开始时，它的稳定性和功能集。我们对Megatron-LM和MegaScale使用相同的批量大小进行公平比较。我们使用了两种模型大小：175B参数和530B参数。我们分别对175B和530B模型使用六和三个交错阶段的交错流水线并行调度[22]。对于所有情况，序列长度为2,048，词汇量大小为64,000。
表1显示了模型配置的详细信息。
可扩展性。图9比较了在训练530B模型时，将批量大小设置为调整后的学习率的GPU数量的Megatron-LM和MegaScale的MFU结果。我们看到MegaScale的MFU比Megatron-LM高出多达6.1%。随着规模的增加，Megatron-LM的MFU由于更多的落后者和通信而下降了1.6%，而MegaScale由于三维并行通信重叠而具有接近线性的可扩展性。
在表2中，我们通过增加GPU数量并保持恒定的批量大小来评估Megatron-LM和MegaScale在175B模型上的强扩展训练性能。这个实验设置更加现实，因为批量大小受到收敛效应的约束，不能无限地随着GPU数量的增加而扩展。
MegaScale在所有设置中实现了高达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 vs. 11,200）是由于175B和530B模型的不同三维并行配置。
消融研究。我们评估了MegaScale优化技术的有效性。表3显示了在256个GPU上训练175B模型时，不同优化的MFU改进分解。基线是原始的Megatron-LM，其MFU为47.7%。值得注意的是，在这次评估中，Megatron-LM和MegaScale都开启了网络优化。我们首先将两种算法技术，即并行transformer块和滑动窗口注意力，应用于Megatron-LM，实现了5.6%的MFU改进。通信是大规模LLM训练的主要瓶颈，而MegaScale的三维并行通信重叠隐藏了开销，并通过6.2%的MFU加速了训练。我们进一步采用高效的操作符，获得了1.7%的加速。其他优化，如数据流水线优化和6.3节中提到的有问题的代码消除，进一步实现了1.1%的性能提升。最后，我们使用LAMB优化器将批量大小从256扩展到768，这显著延长了交错流水线并行中的稳定阶段，并实现了3.0%的MFU改进。总之，通过所有这些优化，MegaScale的MFU数量比基线高出17.6%。
6.2 模型收敛和稳定性
模型收敛微基准测试。我们首先进行微基准实验，以验证算法技术不会影响模型的收敛。由于资源限制，微基准测试是在13B（十亿）参数模型上进行的。
如图10a所示，尽管MegaScale采用了包括并行transformer块和滑动窗口注意力在内的算法技术，但在训练超过100B（百亿）个token时，它与基线相比实现了可比较的损失结果。我们还评估了LAMB优化器的效果，如图10b所示，这表明LAMB优化器在大约250B个token后，以四倍批量大小实现了与ADAM优化器相同的损失。基于这些观察，我们在生产训练中开启了所有算法优化。
实际生产LLM训练中的模型收敛和稳定性。我们展示了一个真实生产运行中的模型收敛和稳定性。这个运行在多万亿个token上训练了一个拥有数千亿参数的专有模型。这个运行使用了超过10,000个GPU，并持续了数周时间。图11显示了损失继续收敛的情况，不同的颜色表示训练已重启。在这次运行的数周内，我们经历了100多次训练重启。借助强大的训练框架，超过90%的软件和硬件故障被自动识别并修复，这些技术在§4中有详细描述。其余问题则在§5描述的故障排除工具的帮助下得到处理。
6.3 发现并解决的问题
我们对上述生产训练作业数周的故障记录进行了分析。我们的发现表明，其中超过90%的异常是自动检测、定位并使用我们强大的训练框架恢复的，例如CUDA错误和分段错误。检测故障和执行诊断测试所需的平均时间不到10分钟。此外，系统能够在最新检查点之后的15分钟内赶上训练进度，保持超过90%的有效训练时间比率，这是通过迭代次数乘以迭代训练时间除以总训练时间计算得出的。下面我们展示了我们在诊断和修复一些需要使用§5中故障排除工具分析的有趣问题的经验。
计算落后者。基于我们对CUDA事件计时器的利用，我们在多个实验设置中做出了另一个相关观察。我们注意到，特定的主机执行相同前向计算所需的时间比其他等级大约多10%。这种在不同实验中的一致性让我们得出结论，问题不在于软件，而是某些集群中的机器固有的问题。在隔离并从集群中移除这些有问题的主机后，我们观察到MFU（混合精度训练吞吐量）大约提高了0.7%。
MFU下降。在这种大规模训练实验中，我们观察到的另一个现象是训练效率并没有随时间保持一致。相反，随着训练的进展，我们训练作业的MFU逐渐下降。通过基于CUDA事件计时器指标的逐步分析，我们注意到几个关键发现。虽然每个训练步骤消耗的时间在增加，但前向、后向和优化器计算所花费的时间保持稳定，无论步骤数量如何增加。这让我们推断时间增加必须归因于集体通信开销。通过逆时间顺序检查，我们确定了最后一个集体通信步骤是数据并行中的梯度减少-分散。如果这个步骤被延迟，每个步骤的总时间就会延长。由于我们观察到网络带宽基本稳定，我们排除了通信速度减慢作为时间增加的因素。
根据集体通信的同步特性，这让我们得出一个结论：一些等级比其他等级晚些启动减少-分散操作，迫使等待最慢的等级赶上。在一个缩小规模的实验中，每个数据并行组只涉及两个等级，我们测量了减少-分散调用的启动时间，并发现它们并不是一致的错开，而是相互波动。此外，随着执行更多步骤，这种时间错开的大小增加。具体来说，等级A最初可能落后于等级B，但最终可能以越来越大的差距超过等级B的速度。最终，所有等级都等待最慢的等级。为了追溯这种时间偏差的根本原因，我们发现变异发生在前向计算阶段。深入挖掘代码，我们将这种不规则性归因于某些代码段引起的波动。例如，不规则的垃圾回收可能会干扰训练过程，某些PyTorch操作可能会导致性能波动。这些操作处于关键路径上，但在训练过程中可能会受到影响。在修改或移除这些有问题的代码段后，我们不再观察到MFU显著下降，如图12所示。
频繁的网络接口闪烁问题。我们偶尔会遇到由于网络接口频繁闪烁而导致的训练停滞或训练速度下降问题。当网络接口闪烁现象发生时，网络接口首先会断开，然后再次连接。断开和连接之间的间隔通常持续几秒钟。在断开过程中，所有正在传输的数据包都会被丢弃。我们学到的第一个教训是，应该明确将超时阈值设置为更大的值，否则默认值会使NCCL非常快地超时，并在网卡再次上线之前返回完成错误。我们学到的第二个教训是，这个问题的根本原因是网络卡、AOC电缆和交换机之间的链接质量差。通过在网络卡信号强度、AOC电缆质量和交换机侧信号强度上进行较低级别的质量控制，可以将闪烁频率降低到一个令人满意的水平。
7 相关工作
LLM训练。已经投入了大量的努力来训练预训练的LLM，包括像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预训练的经验，填补了这一空白。
预训练后，预训练的基础模型可以进一步微调以更好地适应下游任务。这导致了一系列的对话模型的出现，例如ChatGPT。然而，值得注意的是，微调所需的计算能力和数据需求远低于预训练。通过应用量化[38–41]和低秩适应[42]等优化技术，即使资源有限，也可以有效地完成微调。
LLM优化。除了本文前面提到的技术，还有许多其他工作旨在提高LLM的效率。提出了稀疏或线性注意力[43–45]，以使内存消耗大致线性增长。一些研究旨在设计新的架构而不是传统的变换器架构来解决效率问题，例如RWKV [46]和RetNet [47]。许多最近的研究致力于开发LLM的通信加速技术。一些工作通过梯度压缩[48]或混合精度训练[49]减少通信流量，而其他工作则安排通信以与计算重叠。许多流行的机器学习框架，如TensorFlow [50]和PyTorch [51]，默认支持通过反向传播与通信重叠。最近的工作[52–55]通过张量分割进一步重叠梯度同步与前向计算，但代价是额外的开销。一些工作[56,57]引入了固定的陈旧性到训练流程中，以实现完全重叠的通信和通信。然而，陈旧性可能会降低模型性能。
数据中心的诊断工具。已经开发了许多诊断工具来识别和精确定位数据中心中的硬件和软件问题。Pingmesh [58]是一个基于终端主机的主动探测系统。通过发送探测ping包并进行数据分析，测量网络范围内的RTT和丢包。提供网络范围内的SLA，并检测包括数据包黑洞和数据包静默丢失在内的网络问题。EverFlow [59]、LossRadar [60]、NetBouncer [61]利用交换机的能力来诊断详细的网络问题，如网络路径故障或特定网络端口故障。NetBouncer利用IP-in-IP隧道技术进行路径探测。EverFlow需要将网络数据包镜像到一个集中式服务器进行调试。Hostping [62]是一个基于终端主机的诊断系统，专注于内部主机瓶颈。它主动感知复杂的GPU服务器PCIe/NVLINK互连，并进行回环带宽和延迟测试。
大规模分布式系统的容错。容错一直是大规模分布式系统的主要关注点，在这个系统中可能发生各种硬件和软件故障。过去提出了许多容错技术，以满足不同系统和部署场景的需求。反应式容错技术用于在故障发生时减少对系统的影响。这一类技术有很多，如重试[63]、复制[63]、检查点[64]和消息日志[65]。这些技术会产生一些系统开销以从故障中恢复。主动容错技术保持健康组件作为故障组件的备份，消除了从故障和错误中恢复的需要，例如预防性迁移[66–68]和负载均衡[69]。然而，这些方法通常假设故障是可以预测的，而对于真实的大规模分布式系统来说，由于系统的复杂性，预测故障是一个挑战。
8 结论
在本文中，我们深入研究了MegaScale的设计、实现和部署，这是一个为在超过10,000个GPU规模上训练LLM而构建的生产级系统。
MegaScale利用算法-系统共同设计来优化训练效率。在12,288个GPU上训练一个175B LLM模型时，MegaScale实现了55.2%的MFU，比Megatron-LM提高了1.34倍。我们强调在整个训练过程中需要容错，并实现了一个定制的健壮训练框架，以自动定位和修复故障。我们提供了一套全面的监控工具，用于深入观察系统组件和事件，便于复杂异常的根本原因识别。我们相信，我们的工作不仅为那些从事LLM训练的人提供了实用的见解，而且为这个快速发展领域的未来研究铺平了道路。
参考文献
[1] T. Brown, B. Mann, N. Ryder, M. Subbiah, J. D. Kaplan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry,
A. Askell, et al., “Language models are few-shot learners,” Advances in neural information processing systems,vol. 33, pp. 1877–1901, 2020.
[2] “Introducing chatgpt.” https://openai.com/blog/chatgpt, 2022.
[3] J. Kaplan, S. McCandlish, T. Henighan, T. B. Brown,B. Chess, R. Child, S. Gray, A. Radford, J. Wu, and D. Amodei, “Scaling laws for neural language models,” 2020.
[4] L. Floridi and M. Chiriatti, “Gpt-3: Its nature, scope,limits, and consequences,” Minds and Machines, vol. 30,pp. 681–694, 2020.
[5] A. Chowdhery, S. Narang, J. Devlin, M. Bosma,G. Mishra, A. Roberts, P. Barham, H. W. Chung, C. Sutton, S. Gehrmann, et al., “Palm: Scaling language modeling with pathways,” arXiv preprint arXiv:2204.02311,2022.
[6] K. He, X. Zhang, S. Ren, and J. Sun, “Deep residual learning for image recognition,” in IEEE Conference on Computer Vision and Pattern Recognition, 2016.
[7] D. Narayanan, M. Shoeybi, J. Casper, P. LeGresley, M. Patwary, V. A. Korthikanti, D. Vainbrand, P. Kashinkunti, J. Bernauer, B. Catanzaro, A. Phanishayee, and M. Zaharia, “Efficient large-scale language model training on gpu clusters using megatron-lm,” 2021.
[8] I. Beltagy, M. E. Peters, and A. Cohan, “Longformer:The long-document transformer,” 2020.
[9] Y. You, J. Li, S. Reddi, J. Hseu, S. Kumar, S. Bhojanapalli, X. Song, J. Demmel, K. Keutzer, and C.-J. Hsieh,“Large batch optimization for deep learning: Training bert in 76 minutes,” in International Conference on Learning Representations, 2020.
[10] M. Shoeybi, M. Patwary, R. Puri, P. LeGresley, J. Casper, and B. Catanzaro, “Megatron-lm: Training multi-billion parameter language models using model parallelism,” 2020.
[11] S. Rajbhandari, J. Rasley, O. Ruwase, and Y. He, “Zero: Memory optimizations toward training trillion parameter models.” ArXiv, May 2020.
[12] Y. Huang, Y. Cheng, A. Bapna, O. Firat, D. Chen,M. Chen, H. Lee, J. Ngiam, Q. V. Le, Y. Wu, et al.,“GPipe: Efficient Training of Giant Neural Networks using Pipeline Parallelism ,” in NeurIPS, 2019.
[13] D. Narayanan, A. Harlap, A. Phanishayee, V. Seshadri, N. R. Devanur, G. R. Ganger, P. B. Gibbons, and M. Zaharia, “Pipedream: Generalized pipeline parallelism for dnn training,” in ACM SOSP, 2019.
[14] B. Wang and A. Komatsuzaki, “GPT-J-6B: A 6 Billion Parameter Autoregressive Language Model.” https://github.com/kingoflolz/mesh-transformer-jax, May 2021.
[15] Y. Zhao, A. Gu, R. Varma, L. Luo, C.-C. Huang, M. Xu, L. Wright, H. Shojanazeri, M. Ott, S. Shleifer,A. Desmaison, C. Balioglu, P. Damania, B. Nguyen,G. Chauhan, Y. Hao, A. Mathews, and S. Li, “Pytorchfsdp: Experiences on scaling fully sharded data parallel,”2023.
[16] T. Dao, “Flashattention-2: Faster attention with better parallelism and work partitioning,” arXiv preprint arXiv:2307.08691, 2023.
[17] S. Li, Y. Zhao, R. Varma, O. Salpekar, P. Noordhuis, T. Li, A. Paszke, J. Smith, B. Vaughan, P. Damania, and S. Chintala, “Pytorch distributed: Experiences on accelerating data parallel training,” 2020.
[18] I. Group, “Ieee 802.1 qbb - priority-based flow control.” https://1.ieee802.org/dcb/802-1qbb/, 2009.
[19] Y. Zhu, H. Eran, D. Firestone, C. Guo, M. Lipshteyn, Y. Liron, J. Padhye, S. Raindel, M. H. Yahia, and M. Zhang, “Congestion Control for Large-scale RDMA Deployments,” ACM SIGCOMM Computer Communication Review, vol. 45, no. 4, pp. 523–536, 2015.
[20] G. Kumar, N. Dukkipati, K. Jang, H. M. Wassel, X. Wu, B. Montazeri, Y. Wang, K. Springborn, C. Alfeld, M. Ryan, et al., “Swift: Delay is Simple and Effective for Congestion Control in the Datacenter,” in SIGCOMM,pp. 514–528, 2020.
[21] “Megatron-LM.” https://github.com/NVIDIA/Megatron-LM/tree/main, 2021.
[22] V. A. Korthikanti, J. Casper, S. Lym, L. McAfee, M. Andersch, M. Shoeybi, and B. Catanzaro, “Reducing activation recomputation in large transformer models,” Proceedings of Machine Learning and Systems, vol. 5, 2023.
[23] OpenAI, “Gpt-4 technical report,” 2023.
[24] D. Lepikhin, H. Lee, Y. Xu, D. Chen, O. Firat, Y. Huang,M. Krikun, N. Shazeer, and Z. Chen, “Gshard: Scaling giant models with conditional computation and automatic sharding,” 2020.
[25] A. Askell, Y. Bai, A. Chen, D. Drain, D. Ganguli, T. Henighan, A. Jones, N. Joseph, B. Mann, N. DasSarma, N. Elhage, Z. Hatfield-Dodds, D. Hernandez, J. Kernion, K. Ndousse, C. Olsson, D. Amodei, T. Brown, J. Clark, S. McCandlish, C. Olah, and J. Kaplan, “A general language assistant as a laboratory for alignment,” 2021.
[26] J. Wei, M. Bosma, V. Y. Zhao, K. Guu, A. W. Yu,B. Lester, N. Du, A. M. Dai, and Q. V. Le, “Finetuned language models are zero-shot learners,” 2022.
[27] S. Smith, M. Patwary, B. Norick, P. LeGresley, S. Rajbhandari, J. Casper, Z. Liu, S. Prabhumoye, G. Zerveas, V. Korthikanti, E. Zhang, R. Child, R. Y. Aminabadi, J. Bernauer, X. Song, M. Shoeybi, Y. He, M. Houston, S. Tiwary, and B. Catanzaro, “Using deepspeed and megatron to train megatron-turing nlg 530b, a largescale generative language model,” 2022.
[28] J. Hoffmann, S. Borgeaud, A. Mensch, E. Buchatskaya, T. Cai, E. Rutherford, D. de Las Casas, L. A. Hendricks, J. Welbl, A. Clark, T. Hennigan, E. Noland, K. Millican, G. van den Driessche, B. Damoc, A. Guy, S. Osindero, K. Simonyan, E. Elsen, J. W. Rae, O. Vinyals,
and L. Sifre, “Training compute-optimal large language models,” 2022.
[29] H. Su, X. Zhou, H. Yu, X. Shen, Y. Chen, Z. Zhu, Y. Yu, and J. Zhou, “Welm: A well-read pre-trained language model for chinese,” 2023.
[30] S. Zhang, S. Roller, N. Goyal, M. Artetxe, M. Chen, S. ChenG, C. Dewan, M. Diab, X. Li, X. V. Lin, T. Mihaylov, M. Ott, S. Shleifer, K. Shuster, D. Simig, P. S.Koura, A. Sridhar, T. Wang, and L. Zettlemoyer, “Opt:Open pre-trained transformer language models,” 2022.
[31] T. L. Scao, A. Fan, C. Akiki, E. Pavlick, S. Ilic, D. Hess- ´low, R. Castagné, A. S. Luccioni, F. Yvon, M. Gallé,et al., “Bloom: A 176b-parameter open-access multilingual language model,” arXiv preprint arXiv:2211.05100,2022.
[32] H. Touvron, T. Lavril, G. Izacard, X. Martinet, M.-A.Lachaux, T. Lacroix, B. Rozière, N. Goyal, E. Hambro,F. Azhar, A. Rodriguez, A. Joulin, E. Grave, and G. Lample, “Llama: Open and efficient foundation language models,” 2023.
[33] H. Touvron, L. Martin, K. Stone, P. Albert, A. Almahairi, Y. Babaei, N. Bashlykov, S. Batra, P. Bhargava,S. Bhosale, D. Bikel, L. Blecher, C. C. Ferrer, M. Chen,G. Cucurull, D. Esiobu, J. Fernandes, J. Fu, W. Fu,B. Fuller, C. Gao, V. Goswami, N. Goyal, A. Hartshorn,S. Hosseini, R. Hou, H. Inan, M. Kardas, V. Kerkez,M. Khabsa, I. Kloumann, A. Korenev, P. S. Koura, M.-A. Lachaux, T. Lavril, J. Lee, D. Liskovich, Y. Lu,Y. Mao, X. Martinet, T. Mihaylov, P. Mishra, I. Molybog,Y. Nie, A. Poulton, J. Reizenstein, R. Rungta, K. Saladi,A. Schelten, R. Silva, E. M. Smith, R. Subramanian,X. E. Tan, B. Tang, R. Taylor, A. Williams, J. X. Kuan,P. Xu, Z. Yan, I. Zarov, Y. Zhang, A. Fan, M. Kambadur,S. Narang, A. Rodriguez, R. Stojnic, S. Edunov, and T. Scialom, “Llama 2: Open foundation and fine-tuned chat models,” 2023.
[34] R. Taori, I. Gulrajani, T. Zhang, Y. Dubois, X. Li,C. Guestrin, P. Liang, and T. B. Hashimoto, “Stanford alpaca: An instruction-following llama model.” https://github.com/tatsu-lab/stanford_alpaca, 2023.
[35] W.-L. Chiang, Z. Li, Z. Lin, Y. Sheng, Z. Wu, H. Zhang, L. Zheng, S. Zhuang, Y. Zhuang, J. E. Gonzalez, I. Stoica, and E. P. Xing, “Vicuna: An open-source chatbot impressing gpt-4 with 90%* chatgpt quality,” 2023.
[36] X. Geng, A. Gudibande, H. Liu, E. Wallace, P. Abbeel,S. Levine, and D. Song, “Koala: A dialogue model for academic research.” Blog post, April 2023.
[37] Y. Ji, Y. Deng, Y. Gong, Y. Peng, Q. Niu, B. Ma, andX. Li, “Belle: Be everyone’s large language model engine.” https://github.com/LianjiaTech/BELLE, 2023.
[38] Z. Li, E. Wallace, S. Shen, K. Lin, K. Keutzer, D. Klein, and J. Gonzalez, “Train big, then compress: Rethinking model size for efficient training and inference of transformers,” in International Conference on Machine Learning (ICML), 2020.
[39] G. Xiao, J. Lin, M. Seznec, J. Demouth, and S. Han, “Smoothquant: Accurate and efficient post-training quantization for large language models,” arXiv, 2022.
[40] E. Frantar, S. Ashkboos, T. Hoefler, and D. Alistarh,“Gptq: Accurate post-training quantization for generative pre-trained transformers,” arXiv, 2022.
[41] T. Dettmers, M. Lewis, Y. Belkada, and L. Zettlemoyer, “Llm. int8 (): 8-bit matrix multiplication for transformers at scale,” arXiv, 2022.
[42] E. J. Hu, Y. Shen, P. Wallis, Z. Allen-Zhu, Y. Li, S. Wang,L. Wang, and W. Chen, “Lora: Low-rank adaptation of large language models,” 2021.
[43] R. Child, S. Gray, A. Radford, and I. Sutskever, “Generating long sequences with sparse transformers,” 2019.
[44] A. Katharopoulos, A. Vyas, N. Pappas, and F. Fleuret, “Transformers are rnns: Fast autoregressive transformers with linear attention,” 2020.
[45] C. Zhu, W. Ping, C. Xiao, M. Shoeybi, T. Goldstein, A. Anandkumar, and B. Catanzaro, “Long-short transformer: Efficient transformers for language and vision,” 2021.
[46] B. Peng, E. Alcaide, Q. Anthony, A. Albalak, S. Arcadinho, H. Cao, X. Cheng, M. Chung, M. Grella, K. K. GV, X. He, H. Hou, P. Kazienko, J. Kocon, J. Kong, B. Koptyra, H. Lau, K. S. I. Mantri, F. Mom, A. Saito, X. Tang, B. Wang, J. S. Wind, S. Wozniak, R. Zhang, Z. Zhang,Q. Zhao, P. Zhou, J. Zhu, and R.-J. Zhu, “Rwkv: Reinventing rnns for the transformer era,” 2023.
[47] Y. Sun, L. Dong, S. Huang, S. Ma, Y. Xia, J. Xue,J. Wang, and F. Wei, “Retentive network: A successor to transformer for large language models,” 2023.
[48] D. Alistarh, D. Grubic, J. Li, R. Tomioka, and M. Vojnovic, “QSGD: Communication-Efficient SGD via Gradient Quantization and Encoding,” in NeurIPS, 2017.
[49] P. Micikevicius, S. Narang, J. Alben, G. F. Diamos, E. Elsen, D. García, B. Ginsburg, M. Houston,O. Kuchaiev, G. Venkatesh, and H. Wu, “Mixed Precision Training,” in ICLR, 2018.
[50] M. Abadi, P. Barham, J. Chen, Z. Chen, A. Davis,J. Dean, M. Devin, S. Ghemawat, G. Irving, M. Isard,et al., “Tensorflow: A system for large-scale machine learning,” in OSDI, 2016.
[51] A. Paszke, S. Gross, F. Massa, A. Lerer, J. Bradbury, G. Chanan, T. Killeen, Z. Lin, N. Gimelshein, L. Antiga, et al., “PyTorch: An Imperative Style, HighPerformance Deep Learning Library ,” in NeurIPS, 2019.
[52] A. Jayarajan, J. Wei, G. Gibson, A. Fedorova, and G. Pekhimenko, “Priority-based Parameter Propagation for Distributed DNN Training ,” in MLSys, 2019.
[53] S. H. Hashemi, S. Abdu Jyothi, and R. Campbell, “TicTac: Accelerating Distributed Deep Learning with Communication Scheduling,” in MLSys, 2019.
[54] Y. Peng, Y. Zhu, Y. Chen, Y. Bao, B. Yi, C. Lan, C. Wu,and C. Guo, “A generic communication scheduler for distributed DNN training acceleration,” in SOSP, 2019.
[55] Y. Bao, Y. Peng, Y. Chen, and C. Wu, “Preemptive All-reduce Scheduling for Expediting Distributed DNN Training,” in INFOCOM, 2020.
[56] Y. Li, M. Yu, S. Li, S. Avestimehr, N. S. Kim, and A. Schwing, “Pipe-SGD: A Decentralized Pipelined SGD Framework for Distributed Deep Net Training,” in NeurIPS, 2018.
[57] Y. Chen, C. Xie, M. Ma, J. Gu, Y. Peng, H. Lin, C. Wu, and Y. Zhu, “Sapipe: Staleness-aware pipeline for data parallel dnn training,” Advances in Neural Information Processing Systems, vol. 35, pp. 17981–17993, 2022.
[58] C. Guo, L. Yuan, D. Xiang, Y. Dang, R. Huang, D. Maltz, Z. Liu, V. Wang, B. Pang, H. Chen, Z.-W. Lin, and V. Kurien, “Pingmesh: A large-scale system for data center network latency measurement and analysis,” SIGCOMM Comput. Commun. Rev., vol. 45, p. 139–152, aug 2015.
[59] Y. Zhu, N. Kang, J. Cao, A. Greenberg, G. Lu, R. Mahajan, D. Maltz, L. Yuan, M. Zhang, B. Y. Zhao, and H. Zheng, “Packet-level telemetry in large datacenter networks,” SIGCOMM Comput. Commun. Rev., vol. 45, p. 479–491, aug 2015.
[60] Y. Li, R. Miao, C. Kim, and M. Yu, “Lossradar: Fast detection of lost packets in data center networks,” in Proceedings of the 12th International on Conference on Emerging Networking EXperiments and Technologies, CoNEXT ’16, (New York, NY, USA), p. 481–495, Association for Computing Machinery, 2016.
[61] C. Tan, Z. Jin, C. Guo, T. Zhang, H. Wu, K. Deng, D. Bi, and D. Xiang, “Netbouncer: Active device and link failure localization in data center networks,” in Proceedings of the 16th USENIX Conference on Networked Systems Design and Implementation, NSDI’19, (USA), p. 599–613, USENIX Association, 2019.
[62] K. Liu, Z. Jiang, J. Zhang, H. Wei, X. Zhong, L. Tan, T. Pan, and T. Huang, “Hostping: Diagnosing intrahost network bottlenecks in RDMA servers,” in 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23), (Boston, MA), pp. 15–29, USENIX Association, April 2023.
[63] S. Haider, N. R. Ansari, M. Akbar, and M. R. Perwez, “Fault tolerance in distributed paradigms,” 2011.[64] Y. Peng, Y. Bao, Y. Chen, C. Wu, and C. Guo, “Optimus: an efficient dynamic resource scheduler for deep learning clusters,” in Proceedings of the Thirteenth EuroSys Conference, pp. 1–14, 2018.
[65] A. S. Tanenbaum, Distributed systems principles and paradigms. 2007.
[66] S. Chakravorty, C. L. Mendes, and L. V. Kalé, “Proactive fault tolerance in mpi applications via task migration,” in International Conference on High-Performance Computing, pp. 485–496, Springer, 2006.
[67] S. Chakravorty, C. Mendes, and L. V. Kale, “Proactive fault tolerance in large systems,” in HPCRI Workshop in conjunction with HPCA, vol. 2005, pp. 1–7, Citeseer, 2005.
[68] Y. Chen, Y. Peng, Y. Bao, C. Wu, Y. Zhu, and C. Guo,“Elastic parameter server load distribution in deep learning clusters,” in Proceedings of the 11th ACM Symposium on Cloud Computing, pp. 507–521, 2020.
[69] I. Behera and C. R. Tripathy, “Performance modelling and analysis of mobile grid computing systems,” International Journal of Grid and Utility Computing, vol. 5, no. 1, pp. 11–20, 2014.
