摘要
我们分享了MegaScale的设计、实现和工程经验——一个可以在超过10,000个GPU上训练大语言模型（LLM）的生产系统。在这个规模上训练LLM，不仅是让人头大的训练效率和稳定性问题，更是对我们的智慧和耐心的一次全面考验。
为了应对这些挑战，我们采取了全栈方案，精心设计了从模型和优化器设计到计算与通信重叠，再到算子优化、数据管道和网络性能调优的每一个细节。想要在LLM训练这场马拉松中保持高效稳定，必须时刻注意各种潜在问题。毕竟，很多“妖魔鬼怪”只有在大规模训练中才会现形，而深入的可观测性正是我们的法宝。
为此，我们开发了一套“火眼金睛”诊断工具，可以深入监控系统组件和事件，识别根本原因，找到有效的解决办法，实现容错并缓解“拖后腿”的问题。我们的MegaScale系统在12,288个GPU上训练175B LLM模型时，模型FLOPs利用率（MFU）达到了55.2%，比起Megatron-LM，提升了1.34倍。
1.引言
训练LLM是一项艰巨的任务，需要大量计算资源。按照扩展定律，模型的规模和训练数据的规模是决定模型能力的关键因素。将LLM训练扩展到成千上万个GPU上带来了前所未有的挑战：
第一个挑战是在大规模下实现高效的训练。模型FLOPs利用率（MFU）是实际吞吐量与假设达到100%峰值FLOPs时的理论最大吞吐量的比率。这是评估训练效率的标准指标，直接关系到端到端的训练速度。LLM训练并不是令人愉快的并行计算。为了训练一个LLM，模型被拆分到不同的GPU上，而这些GPU需要频繁通信才能继续训练。除了通信之外，算子优化、数据预处理和GPU内存消耗等因素也对MFU有显著影响。
第二个挑战是在大规模下保持高训练稳定性，即在整个训练过程中维持高效训练。因为LLM的训练时间很长，使用一万亿个标记训练一个LLM可能需要数周时间。其规模和时间比普通DNN训练任务要大几个数量级。对于LLM训练来说，失败和滞后几乎是常态。在这种规模下，失败和滞后的后果是毁灭性的。失败代价昂贵，考虑到大规模，缩短恢复时间至关重要。滞后不仅影响自身工作，还会拖慢涉及成千上万个GPU的整个任务。
在本文中，我们介绍了MegaScale的设计、实现和工程经验，这是一套用于大规模训练LLM的生产系统。MegaScale让我们能够在超过10,000个GPU上进行LLM训练，以实现高效和稳定的训练。在构建和运营MegaScale时，我们应用了两大系统原则：算法-系统协同设计和深入可观察性。
MegaScale是一款专为LLM训练量身定制的系统。算法-系统协同设计是专用系统中最大化性能的关键原则，已在计算机系统中广泛应用。我们将这一原则应用于LLM训练的全栈方法中，涵盖所有重要的系统组件。我们对模型架构进行了多项修改，并引入了有效的优化技术，包括并行Transformer块、滑动窗口注意力和LAMB优化器。我们利用混合并行策略，结合数据并行、流水线并行、张量并行和序列并行。重要的是，我们设计了基于每种并行策略的自定义技术，以最大化通信与计算的重叠。我们通过预取和基于树的加载优化数据管道，利用非阻塞异步操作，消除大规模集体通信组初始化的全局障碍。我们设计了自定义网络拓扑，减少了ECMP哈希冲突，定制了拥塞控制，并调整了重传超时参数，以实现高网络性能。
在大规模系统中，稳定性问题（包括故障和滞后）难以诊断和修复。许多棘手的稳定性问题只在大规模时才会出现，可能源自系统堆栈中各种软件和硬件故障。考虑到系统的规模和复杂性，手动识别和解决每一个问题几乎是不可能的。我们应用了深入可观察性原则，构建了一套诊断工具。所谓“深入可观察性”，指的是一种全面的监控和可视化策略，超越表面指标，收集系统堆栈每个组件的详细、细粒度数据，旨在创建多维的系统性能视图。这套工具使我们能够诊断系统，识别根本原因，通过揭示导致稳定性问题的复杂交互和依赖关系来解决问题。我们开发了一个强大的训练框架，以自动化故障定位和恢复。我们设计了包含各种信息的心跳消息，以促进实时异常检测并提供早期预警。我们实施了一套诊断测试，以识别导致中断的节点。我们优化了检查点和恢复程序，以减少中断。为了解决滞后导致的微妙情况，我们开发了一个性能分析工具，记录细粒度的CUDA事件，从分布式视角生成系统范围的热图和时间线跟踪，并开发了一个3D并行训练可视化工具，以显示排名之间的数据依赖关系以便诊断。
训练容错的工作也可以结合 另外一篇文章来一起学习：NSDI 2024 大型语言模型负载特征分析 6.1章节；
MegaScale已在我们的数据中心部署，在训练效率方面，MegaScale在12,288个GPU上训练一个标准的175B Transformer模型时，达到了55.2%的MFU，比最先进的开源训练框架Megatron-LM提高了1.34倍。
2.背景
训练大语言模型（LLM）不仅需要庞大的模型架构，还要处理海量数据，因此计算强度非常高。为了应对这种高强度的计算需求，通常会采用并行策略，将训练过程分布在多个设备上。
数据并行：它会在多个设备上复制模型和优化器状态，并将数据均匀分配到各个设备。每个模型副本会并行地执行前向和后向传播计算。在每次迭代结束时，所有模型副本会同步更新模型。为了避免重复存储模型状态（如优化器状态、梯度和参数），Zero Redundancy Optimizer（ZeRO）提出了一种新的方法：将这些状态在每个数据并行进程之间分片。这样一来，传统的梯度聚合操作被拆分成了单独的reduce-scatter和all-gather操作，因为每个数据并行进程只保留总状态的一部分。ZeRO优化分为三个递进阶段，第二阶段尤其常用，它在分片优化器状态和梯度的同时，不增加额外的通信开销（如图1所示）。
流水线并行：它将模型的各层分布在多个设备上，每个设备负责模型的一部分。同时，每个训练批次会被细分为多个微批次，进行流水线执行。为了减少流水线的“气泡”，提出了各种流水线调度策略，例如，GPipe、PipeDream 1F1B等。Megatron-LM采用了交错的1F1B调度。每个工作者的流水线阶段被细分为多个虚拟阶段，代表一组层，称为模型块。
在开始时，工作者会进入预热阶段，执行有限数量的前向传播微批次。预热完成后，每个工作者进入稳定阶段，在这个阶段中，工作者会进行一次前向传播，然后紧接着进行一次后向传播，简称为1F1B。完成一个批次后，工作者在冷却阶段为所有剩余的在执行中的微批次完成后向传播。图2展示了一个三阶段的流水线，每个阶段进一步细分为两个虚拟阶段。
张量并行：它将单个操作符分布到多个设备上，每个设备并行执行一部分计算。根据具体的分区策略及其与模型中前后操作符的关系，分区可能需要参与的GPU之间进行通信，以分割输入并合并输出。例如，我们可以将MLP和自注意力模块中的GEMM操作分布到多个GPU上，以利用更多的计算单元。像LayerNorm和Dropout这样的操作虽然计算量较小，但需要大量的激活内存。另一种称为序列并行的张量并行方法，将这些操作沿着序列维度分布，从而有效减少激活内存的占用。
并行策略的组合：这些并行策略可以结合成3D并行，以便在多个GPU上扩展LLM的训练。考虑到张量并行带来的高通信开销，最好将这种通信限制在单个集群节点内。相反，数据并行和流水线并行更适合跨节点通信。在这种情况下，我们选择优先构建数据并行组，而不是流水线并行，这可以减少数据并行中跨小型集群的通信。
3.大规模有效训练
3.1.算法优化
我们在算法层面进行了一些修改，并结合最近的优化技术，以提高训练效率，同时保持模型的准确性。我们在第6.2节验证了这些技术对模型收敛的影响。
并行Transformer块：我们采用了Transformer块的并行版本，而不是标准的串行形式。具体来说，Transformer块的标准公式可以通过重新格式化来实现，这种方法使得注意力块和MLP块的计算可以并行执行，从而减少计算时间。之前的研究显示，这种修改不会降低具有数百亿参数的模型的质量。
滑动窗口注意力（SWA）：滑动窗口注意力是一种稀疏注意力机制，它在输入序列中的每个标记周围采用固定大小的窗口。计算复杂度为O(s×w)，其中s是输入序列长度，w是固定窗口大小。与全自注意力的计算复杂度为O(s×s)相比，滑动窗口注意力更高效，特别是当w << s时。过去的研究和我们的微基准测试（第6.2节）表明，通过堆叠这种窗口化注意力的层，可以保留整个输入序列的信息，从而实现更快的训练而不损失准确性。
LAMB优化器：在大规模训练中，有效训练通常受到批量大小约束的限制。特别是，增加批量大小可能会对模型的收敛性产生不利影响。LAMB优化器已被证明能够将BERT的训练批量大小扩展到64K而不影响准确性。在LLM设置中，我们的实验发现，LAMB可以将批量大小扩展到4倍而不损失准确性，MegaScale通过LAMB优化器减少了87.5％的管线泡沫。
3.2 3D并行中的通信重叠
为了优化迭代时间，我们系统分析了3D并行中所有操作符的计算与通信依赖关系，并设计了技术来隐藏所有非关键路径操作的开销。
数据并行中的通信重叠：如图1所示，主要包括两种通信操作。一种是all-gather操作，在前向传播期间从其他数据并行等级的工作节点获取最新的模型参数。另一种是reduce-scatter操作，在后向传播中收集梯度。在3D并行中，单个设备可能托管多个模型块。重叠操作是基于模型块实现的，以最大化带宽利用率。all-gather操作在模型块的前向传播之前触发，而reduce-scatter操作在其后向传播之后开始。受PyTorch FSDP启发，初始的all-gather操作在每次迭代开始时预先获取，允许它与数据加载操作重叠，有效地将通信时间减少了1/(2 * vpp_size)倍。我们还首先启动高优先级通信以最大化重叠。通信操作的优先级由依赖通信结果的计算操作的顺序确定。
流水线并行中的通讯重叠：流水线并行特点是点对点的发送/接收通信。MegaScale使用了第2节提到的交错的1F1B调度方法。我们注意到在预热阶段，前向传播仅依赖于其之前的接收操作。因此，我们解耦了通常一起实现且可能被较慢操作阻塞的发送和接收操作。通过打破这种依赖关系，我们使发送操作能够与计算重叠，如图4左侧所示。冷却阶段可以看作是预热阶段技术的逆应用。至于稳定阶段，前向和后向计算都独立于相邻的通信操作。以后向计算为例，如图4右侧所示，它的前一个接收操作是为下一步前向计算而设计的，而发送操作则用于前一阶段的后向计算。因此，发送和接收操作可以异步启动，以与计算重叠进行。
张量/序列并行中的通讯重叠：张量并行常用于在计算密集型操作中分割权重，而诸如LayerNorm和Dropout这样的操作则沿着序列维度进行分割，以节省GPU内存。这导致需要进行全收集和减少分散操作，用于跨多个GPU收集输入和重新分配输出。图3a展示了并行Transformer块架构中的这种通信模式。在这里，两个通信操作位于关键路径上。为了消除这种开销，我们选择将全收集和减少分散与FFN路径上的并行线性操作融合在一起（图3b）。由于FFN路径上的GEMM内核较大，通信可以更好地隐藏。我们将GEMM内核分解为小块，并与通信进行流水线执行（图3c）。这种策略同样可以应用于后向传播过程中。
3.3 高效算子
尽管在Megatron-LM中对GEMM操作进行了优化，我们发现在其他操作符中仍存在进一步增强的机会。对于注意力部分，我们采用了FlashAttention-2，该方法改进了不同线程块和warp之间的工作分区。对于LayerNorm和GeLU，我们观察到它们在以往实现中由精细的内核组成。通过将这些内核融合在一起，我们减少了启动多个内核所带来的开销，并帮助优化内存访问模式，从而实现更好的性能。
3.4 数据流水线
数据预处理和加载经常被忽视，然而，这些操作在每个训练步骤开始时会导致显著的GPU空闲时间。优化这些操作对训练过程的效率至关重要。
异步数据预处理：数据预处理不在关键路径上。因此，当GPU工作者在每个训练步骤结束时同步梯度时，可以开始进行下一步骤的数据预处理，从而隐藏预处理的开销。
消除冗余数据加载器：在分布式训练的典型数据加载阶段，每个GPU工作者都配备了自己的数据加载器，负责将训练数据读入CPU内存，然后转发到GPU。这导致了工作者之间竞争磁盘读取带宽，从而创建了瓶颈。值得注意的是，在LLM训练设置中，同一台机器内的GPU工作者属于同一个张量并行组。因此，它们每次迭代的输入本质上是相同的。基于这一观察，我们采用了基于两层树的方法。我们在每台机器上使用单独的数据加载器将训练数据读入共享内存。随后，每个GPU工作者负责将必要的数据复制到自己的GPU内存中。这消除了冗余的读取操作，显著提升了数据传输的效率。
3.5 集合通讯初始化
在分布式训练中，初始化阶段涉及在GPU工作节点之间建立NVIDIA Collective Communications Library (NCCL)通信组。在小规模情境下，这种开销相对可忽略，因此默认使用torch.distributed。然而，当GPU数量扩展到一万以上时，原始实现带来的开销变得难以忍受。我们在第6节在同一AI集群上进行了实验，实证测量显示，Megatron-LM在2048个NVIDIA Ampere GPU上的初始化时间约为1047秒。虽然与训练持续时间相比这可能较小，但它对于日常测试和迭代开发（例如在调整超参数和调试过程中进行微小代码调整）造成了重大障碍。同时，它还阻碍了快速重启和恢复机制的实施。
为解决这一问题，我们对torch.distributed进行了详细分析，并确定了导致初始化时间过长的两个主要原因。第一个问题出现在同步步骤中，即每个进程在初始化特定通信组后会参与一个屏障操作。这个屏障使用TCPStore，它是PyTorch中一个单线程、阻塞式读写的分布式KeyValue存储实现。我们将TCPStore替换为Redis，后者是非阻塞和异步的，将2048个GPU上的初始化时间缩短至361秒。第二个问题与全局屏障的不慎使用有关。每个进程在初始化其对应的通信组后执行一个全局屏障。我们精心设计了通信组初始化的顺序，以最小化对全局屏障的需求。这一方法将全局屏障的时间复杂度从O(n^2)降低到O(n)。在2048个GPU上，初始化时间缩短至不到5秒；在一万多个GPU上，优化后的时间也降至不到30秒。
3.6 网络性能调优
我们分析了3D并行中的跨机器通信流量，并设计了提升网络性能的技术。
网络拓扑：我们的数据中心网络采用基于Broadcom Tomahawk 4芯片的高性能交换机构建。每个Tomahawk芯片的总带宽为25.6Tbps，拥有64个400Gbps端口。三层交换机按照CLOS拓扑连接，连接超过1万台GPU。每层交换机的下行和上行带宽比例为1:1，即32个端口用于下行，32个端口用于上行。该网络提供高带宽且直径较小，每个节点可以在有限的跳数内与其他节点通信。
减少ECMP哈希冲突：我们仔细设计网络拓扑并调度网络流量以减少ECMP哈希冲突。首先，在机架顶部（ToR）交换机层面，将一个400G下行端口通过特定的AOC电缆分成两个200G下行端口。由于每个上行端口的带宽是下行端口的两倍，冲突概率减少。其次，服务器上的八个200G NIC以多轨方式连接到八个不同的交换机。同一组ToR交换机可以连接64台GPU服务器。我们策略性地调度数据密集型节点在同一个ToR交换机下操作，大幅减少通信所需的交换机跳数，并进一步降低ECMP哈希冲突的概率。
拥塞控制：在分布式训练中，全互通信可能导致拥塞，并在大规模使用默认的DCQCN协议时引发优先级流控制（PFC）的高水平。过度使用PFC会导致队头阻塞，从而降低网络吞吐量。为解决这些问题，我们开发了一种结合Swift和DCQCN原则的算法，该算法结合了RTT的精确测量和ECN的快速拥塞响应能力。这种方法显著提升了吞吐量并减少了与PFC相关的拥塞。
重传超时设置：可以通过设置NCCL中的参数来控制重传计时器和重试次数。我们调整这些参数以便在链路波动时快速恢复。为了进一步减少恢复时间，我们在NIC上启用了adap_retrans功能。该功能使重传间隔更短，在链路波动周期较短时能够更快恢复传输。
4.容错
随着训练集群扩展到数万台GPU，软硬件故障几乎不可避免。我们引入了一个强大的训练框架，用于大规模语言模型（LLM）的训练，实现自动故障识别和快速恢复，从而在最小人工干预和对正在进行的训练任务影响微乎其微的情况下，实现容错能力。
4.1 稳健的训练工作流程
如图5所示，在接收到提交的训练任务后，驱动进程通过自定义的Kubernetes接口分配计算资源，并为每个执行器（executor）启动相应的Pod。每个执行器管理一个节点。一旦执行器完成一系列初始化任务，它将在每个GPU上创建训练进程，并启动一个稳健的训练守护进程，定期向驱动发送心跳信号。这些心跳信号封装了各种信息，以实现实时异常检测和早期预警。当驱动进程检测到某个训练进程状态异常，或者在预定义的时间窗口内未能收到某个执行器的心跳信号时，它会触发故障恢复程序。驱动将暂停所有执行器上的正在进行的训练任务，并命令它们运行一系列自检诊断。这些诊断测试经过精心设计，轻量且全面，涵盖了大多数常见的软硬件故障。一旦识别出有问题的节点，驱动会将这些节点的IP地址和运行的Pod信息提交给K8S，K8S会驱逐故障节点，并补充通过诊断测试的等量健康节点。此外，我们提供了一个用户界面，允许手动驱逐节点，特别是针对那些通过手动分析识别出的节点。在恢复过程完成后，驱动会从最新的检查点恢复训练。我们优化了检查点和恢复过程，以最大限度地减少训练进度的损失。
4.2 数据收集与分析
心跳消息包含执行器的基本信息，如IP地址、Pod名称和硬件信息等。此外，还会报告当前训练进程的状态，使驱动程序能够及时检测任何明显的异常。训练进程的stdout/stderr日志也会被包括在内，并实时进行汇总、过滤和分析。如果检测到特定的警告或错误关键字，驱动程序会报告实时诊断信息。此外，还包括RDMA流量指标，作为网络利用率和效率的指示器。某些训练过程中的异常可能不会表现为明显的错误，表面上看训练进程似乎正常进行。在这种情况下，RDMA流量指标成为关键指示器。鉴于训练任务的周期性，每个步骤的网络流量特征应表现出类似的模式。因此，RDMA流量的显著下降或异常波动是潜在异常的信号。一旦检测到这些不规则情况，驱动程序会发出警报，进行人工调查。如果流量完全停止，驱动程序会自动启动故障恢复程序。
为了增强对训练稳定性和性能的监控，我们开发了精度达到毫秒级的监控系统。不同层级的监控用于跟踪各种指标。秒级监控通常用于评估整体健康状态，并排除配置对训练的常见影响。例如，ECN/PFC/QoS配置、链路抖动或任何其他网络接口卡（NIC）问题。毫秒级监控则用于确定网络是否拥堵，以及数据并行和流水线并行的数据传输速度是否达到了物理极限。
4.3 诊断测试
在自检诊断中，执行时间和准确性之间存在权衡。过长的诊断时间会对有效训练时间产生不利影响，而高误报率会导致实际功能正常的机器被不必要地排除。通过反复实验和优化，我们部署了一套轻量级诊断测试，能够有效覆盖实际训练过程中遇到的各种硬件和软件故障。
主机内网络测试：为了诊断主机内网络的潜在瓶颈，我们使用内部开发的工具进行两项测试。环回测试（Loopback test）测量所有RDMA网卡（RNICs）到各种主机内端点（包括内存节点和GPU）的环回带宽。它在主机内进行全网测试，覆盖所有可能的链路组合。这使我们能够根据端到端的带宽结果推断特定链路的带宽下降和PCIe配置的不规则情况。第二项RNIC-to-RNIC测试检查同一主机上不同RNICs之间的连接性和带宽性能。这些测试提供了RNICs是否符合硬件速度规格以及底层路由配置是否正确的见解。
NCCL测试：为了识别GPU通信中的潜在故障，我们在单个节点内的GPU之间运行全互连测试，以观察带宽是否符合预期基准。一旦通过主机内通信测试，每个节点还会与同一ToR交换机下的邻近机器进行全规约测试，以评估节点间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或Megatron-LM timer）不同，我们的工具基于CUDA事件方法进行计时。这种方法减少了对CUDA同步的需求，防止了性能下降，使我们能够在生产训练任务中持续运行该工具。该工具提供了两种可视化模式，并可以从不同角度分析收集的数据。
第一种模式使用热图显示各机器在不同维度上的时间消耗差异，如图7所示。我们收集设备间计算阶段（前向和后向）的延迟数据，并对步骤之间的延迟进行平均。汇总的数据通过热图可视化。热图揭示了一小部分机器（约0.5%）在训练期间表现出显著较慢的性能，从而阻碍了整体训练进度。训练效率主要取决于最慢的机器的性能（即滞后者），由于集群内的机器调度是随机的，因此导致了不同运行间训练效率的不一致。在排除这些异常机器后，不同运行的最高MFU变得一致。
另一种模式以跟踪格式显示不同分布式视角（数据并行、流水线并行、张量并行）中的机器事件时间线。传统的分析工具，如PyTorch Profiler，主要设计用于单节点活动分析。这种方法在执行依赖性经常跨多个节点的分布式训练场景中提供的洞察有限。通过将各种等级的跟踪跨度汇总到单一时间线上，我们可以获得全面视角，揭示整体执行顺序、流水线气泡和数据并行等级间的同步特性。图8展示了我们的分布式跟踪器如何可视化流水线并行的实际执行情况，通过整合流水线并行组中的事件数据，详细描述了不同流水线阶段之间的数据依赖性。
每个CUDA事件计时器的数据都存储在一个远程分析数据库中，方便检索任何步骤事件的详细信息。虽然计时器数据以逐行格式写入本地文件，但一个单独的流处理过程会实时将该日志文件与Kafka队列同步。分析数据库通过从Kafka队列中消费数据保持更新，实现不中断训练作业的即时分析。所有监控功能在实际生产训练中都被启用，相对于训练时间来说，这些功能的开销可以忽略不计。
5.2 3D并行训练可视化
在3D并行和我们的优化技术的支持下，数据流和任务排序的景象变得异常复杂。每个GPU工作者可能在任意时刻都在执行多个同步或异步操作，导致它们之间产生复杂的依赖关系。这种复杂性加大了故障诊断的难度：当一个GPU工作者出现故障时，整个节点集群可能在NCCL通信操作中停滞，最终导致系统级的超时。从外部看，这种情况表现为通用的阻塞，但根本原因通常埋藏在大量的超时消息中。为了迅速定位问题节点，我们让每个GPU工作者在通信超时时记录其当前的事件。这些日志随后用于构建基于3D并行设置中的逻辑拓扑的数据依赖关系的可视化表示。
如图7所示，3D并行训练中的集群可以逻辑地分为三个维度：张量并行、流水线并行和数据并行。当我们选择一个特定的GPU工作者时，它显示其在逻辑拓扑中的位置、数据流的方向以及其参与的不同通信操作。重要的是，在发生错误时，该工具可以直接访问工作者的错误信息。这成为诊断训练异常的强大工具，使得故障的识别和解决更为迅速。
例如，当有缺陷的GPU在执行NCCL通信操作时概率性地导致阻塞，这种阻塞可能会挂起整个机器，导致其他依赖节点的级联超时，最终导致整个训练过程的瘫痪。为了迅速识别这些故障节点，我们利用3D并行训练可视化工具。由于等待故障节点而超时的节点会在退出时记录其当前操作，而有故障GPU的节点则会挂起而不记录任何信息。因此，通过检查日志和可视化中的数据流，可以轻松定位这些问题节点。一旦识别出这些节点，可以通过4.1中描述的稳健训练框架手动隔离并标记这些节点以进行维护。
6.相关工作
LLM优化：除了本文先前提到的技术，还有许多其他工作致力于提高LLM的效率。例如，稀疏或线性注意力机制被提出，以使内存消耗大致线性增长。若干研究旨在设计新架构，而非传统的Transformer架构，以解决效率问题，如RWKV和RetNet。许多最近的研究专注于为LLM开发通信加速技术。有些工作通过梯度压缩或混合精度训练来减少通信流量，而另一些工作则安排通信与计算重叠。许多流行的机器学习框架，如TensorFlow和PyTorch，默认启用通信与反向传播的重叠。最近的工作通过张量分区进一步将梯度同步与前向计算重叠，但这会带来额外的开销。一些工作引入固定延迟到训练管道中，以实现全面的通信重叠，但这种延迟可能会降低模型性能。
数据中心的诊断工具：许多诊断工具已经开发出来，用于识别和定位数据中心中的硬件和软件问题。Pingmesh是一个基于终端主机的主动探测系统。通过发送探测ping包并进行数据分析，测量网络全局的RTT和丢包率，并提供网络全局的SLA，检测包括包黑洞和包静默丢弃在内的网络问题。EverFlow、LossRadar、NetBouncer 利用交换机的能力来诊断详细的网络问题，如网络路径故障或特定网络端口故障。NetBouncer利用IP-in-IP隧道技术进行路径探测。EverFlow需要将网络包镜像到集中服务器进行调试。Hostping是一个基于终端主机的诊断系统，专注于主机内瓶颈。它积极感知复杂的GPU服务器PCIe/NVLINK互连，并进行环回带宽和延迟测试。
大规模分布式系统中的容错：容错一直是大规模分布式系统中的一个主要关注点，这类系统中可能会发生各种硬件和软件故障。过去提出了许多容错技术，以满足不同系统和部署场景的需求。反应性容错技术用于在故障发生时减少对系统的影响。该类别中的许多技术包括重试、复制、检查点和消息日志。这些技术会产生一些系统开销以从故障中恢复。主动容错技术则在故障组件出现之前保持健康组件作为备份，避免了从故障和错误中恢复的需要，如预防性迁移和负载均衡。然而，这些方法通常假设故障是可预测的，而对于实际的大规模分布式系统，由于系统的复杂性，预测故障是具有挑战性的。
7.总结
在本文中，我们深入探讨了MegaScale的设计、实现和部署，这是一种用于在超过10,000个GPU规模上训练大型语言模型（LLMs）的生产级系统。MegaScale利用算法与系统的协同设计来优化训练效率。在使用12,288个GPU训练1750亿参数的LLM模型时，MegaScale达到了55.2%的MFU，相较于Megatron-LM提高了1.34倍。我们强调了在整个训练过程中容错机制的重要性，并实施了定制的稳健训练框架，以自动定位和修复故障。我们提供了一套全面的监控工具，对系统组件和事件进行深入观察，便于复杂异常的根本原因识别。