聊聊字节 AML 万卡工作 MegaScale: Scaling Large Language Model Tr...

作者丨无恶不作
来源丨https://zhuanlan.zhihu.com/p/684619370 编辑丨GiantPandaCV

1. 摘要

字节介绍了用于训练大规模语言模型（LLM）的生产系统 MegaScale。在这个系统上高效稳定的在万卡级别进行千亿级别模型训练。同时考虑到训练计算的高效性，通过模型块和优化器设计、计算和通信重叠、算子优化、数据流水线和网络性能调优来共同设计算法和系统组件。考虑到LLM训练作业的长时间跨度。许多稳定性问题只有在大规模下才会出现，而深入的可观测性是解决这些问题的关键。我们开发了一套诊断工具，用于监控系统组件和堆栈中的事件，识别根本原因，并得出有效的技术来实现容错和减轻滞后现象。在使用 12,288 个 GPU 训练 175B 的 LLM 模型时，MegaScale 实现了 55.2% 的模型 FLOPs 利用率（MFU），相比 Megatron-LM 提高了 1.34 倍的MFU。

2.整体介绍

大规模语言模型（LLM）已成为人工智能（AI）中一项具有变革性的技术。LLM的最新进展显著提升了它们的能力。LLM 在机器翻译、文本摘要和对话代理等广泛领域展示了巨大潜力。训练 LLM 是一项艰巨的任务，需要大量的计算资源。scaling law 规定了模型大小和训练数据大小是决定模型能力的关键因素。为了实现最先进的模型能力，许多工作致力于在数千亿甚至数万亿参数 tokens 大型模型上进行训练。这里介绍了字节面对数十亿用户的场景，有着广阔的人工智能场景。LLM 训练的规模之大从系统的角度引入了两个特定的挑战：

• 第一个挑战是在大规模情况下实现高效的训练。模型 FLOPs 利用率（MFU），即吞吐量与理论最大吞吐量（假设使用100%的峰值FLOPs）之间的比率最大化。（集合通信，op优化、数据预处理和GPU内存消耗等因素对 MFU 产生重要影响）

• 第二个挑战是在大规模情况下实现高稳定性的训练，即在整个训练过程中保持高训练效率。从生产的角度来看，稳定性尤为重要，因为 LLM 的训练时间很长。（故障和滞后对于大模型训练资源浪费是巨大的）

在这篇论文中，介绍了 MegaScale，一个用于大规模训练 LLM 的生产系统的设计、实现和工程经验。MegaScale 能够将 LLM 训练扩展到超过 10,000 个GPU。我们能够利用大量GPU的计算能力来高效稳定地训练 LLM。在构建和运行 MegaScale 时，我们应用了两个系统原则：算法与系统的协同设计和深入的可视化性。修改/优化包括：并行Transformer、滑动窗口注意力和LAMB 优化器。利用混合并行策略，包括数据并行、流水线并行、张量并行和序列并行。重要的是，针对每种并行策略的模式设计了定制的技术，以最大程度地增加通信和计算之间的重叠。应用 prefetching 和 treebased loading 来优化数据流水线。利用 non-blocking asynchronous operations 操作，并消除大规模集体通信组初始化的全局 barriers。设计了自定义的网络拓扑，减少了 ECMP 哈希冲突，定制了拥塞控制，并调整了重传超时参数以实现高网络性能。（通读论文后发现，这篇论文对现世的技术都做了很细致修改和优化，确实是投入了很大的人力和物力）

3.优化介绍

本节将深入探讨用于优化大模型训练的方法，以实现高效的大规模训练效果。（全是干货，高能预警）

3.1 算法优化

3.1.1 Parallel transformer block

采用这种方法，attention block 和 MLP block 的计算可以并行执行，从而减少计算时间。先前的研究表明，这种修改不会降低具有数千亿参数的模型的质量。如下图1所示。

图1

3.1.2 Sliding window attention (SWA)

滑动窗口 attention 是一种稀疏注意力机制，它在输入序列中的每个标记周围使用一个固定大小的窗口。其计算复杂度为O(s×w)，其中 s 是输入序列的长度，w 是固定的窗口大小。相对于计算复杂度为O(s×s)的完全自注意力机制，滑动窗口注意力更加高效，前提是w ≪ s。先前的研究和字节的基准测试表明，通过堆叠这种窗口注意力的层，可以保留整个输入的信息，从而实现更快的训练而不降低准确性。

3.1.3 LAMB optimizer

在大规模训练中，通常会受到 batch size 的限制。特别是，增加 batch size 可能会对模型的收敛产生不利影响。LAMB优化器已经证明可以将 BERT 的训练 batch size 扩展到 64K 而不降低准确性。在LLM设置中，字节的实验证明，LAMB 可以将 batch size 扩展到 4 倍而不损失准确性。因此，通过 LAMB 优化器，MegaScale 减少了87.5%的 pipeline bubbles。

3.2 集合通信优化

3.2.1 Overlapping in data parallelism

在 3D 并行中，单个设备可能承载多个 model chunks。为了最大限度地利用带宽，重叠计算是基于 model chunks 进行的。all-gather 操作在模型块的前向传递之前触发，减少 reduce-scatter 操作在其后向传递之后开始。这导致了一个挑战，即无法隐藏第一个 all-gather 操作和最后一个 reduce-scatter 操作。受 PyTorch FSDP 的启发，初始的 all-gather 操作在每次迭代开始时预取，使其能够与数据加载操作重叠，有效地将通信时间减少了1 /（2 * vpp_size）的因子。我们还首先启动高优先级的通信，以最大程度地实现重叠。通信操作的优先级由依赖于通信结果的相应计算操作的顺序确定。如下图 2 所示。

图2

all-gather 操作能够与数据加载操作重叠。

3.2.2 Overlapping in pipeline parallelism

在 pipeline parallelism 中的重叠计算。pipeline parallelism 采用 point-to-point 的发送/接收通信方式。MegaScale使用了前文提到的 interleaved 1F1B 调度方法。我们注意到，在热身阶段，前向传递只依赖于其前一个接收操作。因此，我们将发送和接收操作解耦，这两个操作通常是一起实现的，并且可能被较慢的操作阻塞。通过打破这种依赖关系，我们使发送操作能够与计算重叠，如下图 3 左侧所示。冷却阶段可以看作是热身阶段的逆过程，允许对相同技术进行逆向应用。至于稳定阶段，前向和后向计算都不依赖于相邻的通信操作。以后向计算为例，如下图3右侧所示，它的前一个接收操作是为下一个前向计算而进行的，而发送操作是为前一阶段的后向计算而进行的。因此，发送和接收操作可以异步启动，与计算重叠进行。

图3

3.2.3 Overlapping in tensor/sequence parallelism

在张量/序列并行中的重叠计算。张量并行常用于在计算密集型操作中对权重进行分区，而像LayerNorm 和 Dropout 这样的操作则沿序列维度进行分区以节省 GPU 内存。这需要进行all-gather 和 reduce-scatter 操作，以便在 GPU 之间进行输入收集和输出重新分配。如下图 4 展示了 parallel transformer block 架构中的通信模式。在这里，这两个通信操作位于关键路径上。为了消除这种开销，选择将 all-gather 和 reduce-scatter 与 FFN 路径上的并行线性层融合在一起。由于 FFN 路径上的 GEMM 内核更大，通信可以更好地隐藏起来。将GEMM 内核分成小块，并将执行与通信进行流水线处理。这种策略可以类似地应用于反向传递中。

图4

3.3 Efficient Operators

• attention part：采用了FlashAttention-2

• LayerNorm 和 GeLU：将这些 kernel fuse 在一起，我们减少了启动多个 kernel 所带来的开销，并有助于优化内存访问模式，从而实现更好的性能。

3.4 Data Pipeline

• 异步数据预处理：数据预处理不在关键路径上。因此，在每个训练步骤结束时，当GPU 在同步梯度时，下一个步骤的数据预处理可以开始，这样就隐藏了预处理的开销。

• Redundant dataloader elimination：在分布式训练的典型数据加载阶段中，每个GPU工作器都配备有自己的数据加载器，负责将训练数据读入 CPU内存，然后将其传递给GPU。这导致工作器之间竞争磁盘读取带宽，从而创建了一个瓶颈。值得注意的是，在 LLM 训练设置中，同一台机器上的 GPU 工作器属于相同的张量并行组（通常tp放置在机内）。因此，它们每次迭代的输入本质上是相同的。基于这个观察，我们采用了一个基于两层tree-based 的方法。我们在每台机器上使用一个单独的专用数据加载器将训练数据读入一块共享内存中。随后，每个 GPU 负责将必要的数据复制到对应的 GPU 内存中。这消除了冗余的读取，并显著提高了数据传输的效率。

3.5 Collective Communication Group Initialization

在分布式训练中，初始化阶段涉及在 GPU之间建立NVIDIA Collective Communications Library (NCCL)通信组。当 GPU 数量扩展到一万多个时，使用torch.distributed的开销很大。字节在同一个AI集群上进行了实验，实证测量结果表明，在 2048 个NVIDIA Ampere GPU上，Megatron-LM 的初始化时间约为 1047 秒。重启次数较大时开销很大。

导致初始化时间过长的两个主要原因：

• 第一个问题出现在同步步骤中，每个进程在初始化特定通信组结束时都会进行 barrier 操作。PyTorch中使用 TCPStore 在内部对通信连接进行分布式键值存储，单线程的阻塞读写方式运行。将 TCPStore 替换为 非阻塞、异步的 Redis。这将在 2048 个GPU上将初始化时间缩短到 361 秒。(这部分按照我的理解画了如下图5示意图)
  

图5

• 第二个问题与全局 barrier 的不谨慎使用有关。每个进程在初始化其相应的通信组后都会执行一个全局 barrier。我们仔细设计了通信组初始化的顺序，以最小化对全局 barrier 的需求。这种方法将全局 barrier 的时间复杂度从O(n^2) 降低到 O(n)。经过这些优化，初始化时间在 2048 个 GPU 上缩短到不到 5 秒，在超过 10,000 个 GPU 上缩短到不到 30 秒。

3.6 Network Performance Tuning

网络拓扑结构。字节的数据中心网络采用基于 Broadcom Tomahawk 4 芯片的高性能交换机构建。每个 Tomahawk 芯片的总带宽为 25.6Tbps，具有 64 个400Gbps端口。三层交换机以类似 CLOS 的拓扑结构连接，用于连接超过 10,000 个 GPU。对于每一层的交换机，下行链路和上行链路之间的带宽比例为1:1。也就是说，32个端口用作下行链路，32个端口用作上行链路。该网络提供高带宽和小直径。每个节点可以在有限的跳数内与其他节点进行通信。

3.6.1 Reducing ECMP hashing conflicts

字节精心设计网络拓扑并安排网络流量，以减少 ECMP 哈希冲突。首先，在顶级机架交换机（ToR）级别，将一个 400 G下行链路端口分成两个带有特定 AOC 电缆的 200G 下行链路端口。由于每个上行链路的带宽是下行链路的两倍，冲突概率降低了。其次，服务器上的 8 个200G 网卡以多重连接方式连接到 8 个不同的交换机上。通过相同的一组 ToR 交换机连接的GPU 服务器数量可以达到 64 个。我们策略性地将我们训练任务中的数据密集节点调度到同一个机架顶部（ToR）交换机下运行。这种方法显著减少了通信所需的交换机跳数，并进一步降低了 ECMP 哈希冲突的概率。(这部分按照我的理解画了如下图6示意图)

图6 图7

3.6.1 拥塞控制

在分布式训练中，当默认使用 DCQCN 协议时，all-to-all 通信可能导致拥塞和过度使用优先级流控制（PFC）。过度使用 PFC 可能导致（HoL blocking），从而降低网络吞吐量。为了缓解这些问题，字节开发了一种算法，结合了 Swift 和 DCQCN 的原理，将往返时延（RTT）的精确测量与显式拥塞通知（ECN）的快速拥塞响应能力相结合。这种方法显著增强了吞吐量，并最小化与PFC 相关的拥塞问题。

3.6.2 Retransmit timeout setting

可以通过设置 NCCL 中的参数来控制重传计时器和重试次数，我们调整这些参数以实现在链路抖动下的快速恢复。为了进一步减少恢复时间，我们在网卡上启用了 adap_retrans 功能。该功能可以在较短的间隔内进行重传，并在链路抖动时间较短时更快地恢复传输。

4. Fault Tolerance

随着训练集群规模扩大到数万个 GPU，软件和硬件故障几乎是不可避免的。为了实现自动故障识别和快速恢复，在 LLM 训练中引入了一个强大的训练框架，实现了最小人为干预和对正在进行的训练任务几乎没有影响的容错能力。

图8

4.1 Robust Training Workflow

如图 8 所示，当接收到提交的训练任务时，驱动程序与自定义的 Kubernetes 接口进行交互，以分配计算资源并为每个执行器启动相应的 Pod。一个执行器管理一个节点。一旦执行器完成一系列的初始化任务，它会在每个 GPU 上创建训练进程和一个强大的训练守护进程，后者会定期向驱动程序发送心跳信号。这些心跳信号封装了各种形式的信息，以实现实时异常检测并提前发出警告。当驱动程序检测到特定训练进程的异常状态，或者在预定义的时间窗口内未收到执行器的心跳信号时，它将触发故障恢复过程。驱动程序会暂停所有执行器上正在进行的训练任务，并命令它们运行一系列自检诊断。

4.2 Data Collection and Analysis

心跳消息包括执行器的基本信息，如 IP 地址、Pod 名称和硬件信息等。此外，还报告了训练进程的当前状态，使驱动程序能够及时检测到任何明显的异常。训练进程的 stdout/stderr 日志也包括在内。它们将被实时聚合、过滤和分析。如果检测到特定的警告或错误关键词，驱动程序将报告实时的诊断信息。此外，RDMA 流量指标也包括在内，用作网络利用率和效率的指标。训练过程中的某些异常可能不会表现为明显的错误，使得训练似乎按预期进行。在这种情况下，RDMA 流量指标起到了关键的指示作用。由于训练任务的周期性特性，每个步骤的网络流量特征应该呈现类似的模式。因此，RDMA 流量的显著下降或异常波动是潜在异常的信号。在检测到这种异常情况时，驱动程序将发出警报以进行手动调查。如果流量完全停止，驱动程序将自动启动故障恢复过程。

为了增强对训练稳定性和性能的监控，字节开发了一个精度达到毫秒级的监控系统。采用不同级别的监控来跟踪各种指标。第二级监控通常用于评估整体健康状况，并排除对训练的常见配置影响。例如，ECN/PFC/QoS配置、链路抖动或其他网卡问题。另一方面，毫秒级监控用于确定网络是否拥塞，以及数据并行性和管道并行性的数据传输速度是否达到了物理限制。

4.3 Diagnostic Tests

在自检诊断中，执行时间和准确性之间存在权衡。延长诊断持续时间可能会对有效的训练时间产生不利影响，而高误报率可能会导致对实际上正常工作的机器进行不必要的排除。字节部署了一套轻量级的诊断测试，能够有效覆盖在实际训练过程中遇到的广泛硬件和软件故障。

• Intra-host network tests
  针对主机内部网络的测试。为了诊断主机内部网络潜在的瓶颈，我们使用我们内部开发的工具进行两项测试。

  • 第一项是回环测试（Loopback test），它测量了所有RDMA网卡（RNIC）与各种主机内部终点（包括内存节点和GPU）之间的回环带宽。这使得能够根据端到端带宽结果推断链路特定的带宽降低和 PCIe 配置的异常。

  • 第二项是 RNIC 到 RNIC 的测试，它检查同一主机上不同 RNIC 之间的连接性和带宽性能。这些测试可以提供关于 RNIC 是否符合硬件速度规格以及底层路由配置是否正确的信息。通过这些测试，我们可以了解到主机内部网络的性能状况，以及可能存在的硬件或配置问题。

• NCCL tests：为了识别 GPU 通信中的潜在故障，我们在单个节点内的所有 GPU 之间运行全互连测试，观察带宽是否与预期的基准相符。一旦通过了主机内通信测试，每个节点还会在同一 ToR 交换机下与相邻机器进行全归约测试，以评估节点间的 GPU 通信。通过这些测试，我们可以检查 GPU 之间的通信性能，并确定是否存在潜在的故障或性能问题。这些测试有助于确保 GPU 之间的高效通信，并为训练任务提供良好的性能。

4.4 Fast Checkpointing and Recovery

在识别和驱逐故障节点之后，驱动程序需要通过加载最近的检查点中的模型权重和优化器状态来恢复训练。确保最新的检查点尽可能接近故障发生时的训练进度状态非常关键，以最小化计算和时间上的损失。这要求在训练过程中增加检查点的频率，同时减少加载 checkpoint 过程引入的延迟，特别是阻塞训练进度的关键路径上的时间，以提高整个系统的吞吐量。

为了实现快速的检查点操作，引入了一个优化的两阶段方法。

• 在第一阶段，每个 GPU 工作进程将其片上状态写入主机内存，然后继续训练过程。通过优化 PyTorch 的序列化机制和使用固定内存，由于高速的 PCIe 带宽，这个过程可以在几秒钟内完成，从而最小程度地中断正在进行的训练过程。

• 在第二阶段，一个后台进程接管，异步地将状态从主机内存传输到分布式文件系统（部署中为HDFS），以进行集中维护。将操作分解为两个阶段使得 GPU 工作进程在转储状态后几乎可以立即恢复训练，而写入 HDFS 的耗时过程则由一个独立的非阻塞进程来完成。

为了缓解了 HDFS 的带宽限制，同一数据并行组中的工作进程。因此，我们指定组中的一个工作进程从 HDFS 中读取共享的状态分区，从而线性减少负载。然后，这个工作进程将状态分区广播给所有共享相同数据的其他 GPU 工作进程。这种方法有效地缓解了HDFS的带宽限制，大大减少了恢复时间。

这些监控和分析工具的实施是为了应对那些不易察觉的问题，以确保训练过程的顺利进行。它们提供了额外的保障，帮助我们在面对硬件异常时能够更加全面地了解问题，并采取适当的措施来解决这些问题，以确保训练的成功进行。

5. Training Troubleshooting

对于一些硬件异常，无法通过自检发现的问题，字节实现了以下异常检测的监控和分析工具。

5.1 Performance Diagnosis with CUDA Event Monitor

在数万个 GPU 的规模下，我们观察到与规模较小的实验不同的是，不同的运行会展现出不同的计算效率。即使在相同的配置下，这种不一致性仍然存在，正如图 9 所示。还观察到在这个规模下，训练任务的性能并不一致。各种训练任务的最大工作集（MFU）随时间逐渐下降。虽然这使我们怀疑个别机器之间存在差异，但在单个 GPU 的 GEMM 微基准测试中没有发现明显的差异。

图9

为了诊断这些性能问题，我们开发了一个性能分析工具，记录每个机器排名在运行过程中关键代码段的执行时间。与之前的工具（如 torch 分析器或 MegatronLM 计时器）不同，我们的工具基于 CUDA events 方法计时。这种方法最大程度地减少了对 CUDA 同步的需求，从而防止性能下降，并使我们能够在生产训练作业中始终稳定地运行它。

这个工具提供了两种可视化模式，并可以从不同的角度分析收集到的数据。通过这个工具，我们可以更好地理解训练过程中的性能问题，并从不同的视角进行分析，以找出潜在的原因并采取相应的措施来解决这些问题。

• 第一种模式使用热图来显示不同维度上机器之间的时间消耗差异，如图 10 所示。字节收集了计算阶段（前向和后向）跨设备的延迟数据，并对步骤的延迟进行平均。聚合的数据使用热图进行可视化。热图显示，在训练过程中，大约有 0.5% 的机器表现出明显较慢的性能，从而影响整体的训练进度。训练效率主要由最慢的机器（即滞后者）的性能决定，这导致不同运行之间的训练效率不一致，因为集群内的机器调度是随机的。在排除这些异常机器之后，各次运行的 MFU 变得一致。
  

图10

• 另一种模式以跟踪格式显示不同分布式视图（数据并行、流水线并行、张量并行）上的机器事件时间线。传统的分析器（如PyTorch Profiler）主要设计用于单节点的活动分析。这种方法在执行依赖关系经常跨越多个节点的分布式训练场景中提供的信息有限。通过将各个 rank 的跟踪跨度聚合到一个时间线上，我们获得了全面的视角，揭示了整体的执行顺序、流水线 bubble 和数据并行排名之间的同步特性。图 11 显示了字节的分布式跟踪器如何可视化流水线并行的实际执行情况，通过在流水线并行组中整合事件数据，详细说明了不同流水线阶段之间的数据依赖关系。

图11

每个 CUDA events 计时器的数据都存储在远程分析数据库中，可以轻松地从任何步骤事件中检索详细信息。虽然计时器数据以逐行格式写入本地文件，但一个独立的流处理进程会实时将此日志文件与 Kafka 队列同步。分析数据库通过消费来自 Kafka 队列的数据保持更新，实现了即时分析而不中断训练作业。在真实的生产训练中，所有的监控功能都被打开，与训练时间相比，额外开销可以忽略不计。

5.2 3D Parallel Training Visualization

通过 3D 并行和字节的优化技术，数据流和任务序列的情况变得非常复杂。每个 GPU 工作节点在给定时刻可能同时进行多个同步或异步操作，导致它们之间存在复杂的依赖关系。这种复杂性增加了故障诊断的挑战：当单个GPU工作节点发生故障时，整个节点集群可能在 NCCL 通信操作中停滞，最终导致系统范围的超时。在外部，这种情况表现为通用的阻塞，但其根本原因往往被大量的超时消息所掩盖。为了快速定位有问题的节点，字节让每个 GPU 工作节点在通信超时时记录其正在进行的事件。然后，利用这些日志根据 3D 并行设置中的逻辑拓扑构建数据依赖的可视化表示。

通过构建基于逻辑拓扑的数据依赖可视化表示，能够更好地理解和分析在 3D 并行设置中的数据流和任务序列。这有助于我们快速定位故障节点，并深入了解故障的根本原因。通过这种可视化表示，我们能够更好地理解并解决由于故障而导致的节点间的通信问题，从而提高分布式训练的稳定性和可靠性。

6. 大模型训练经验

在这一部分，描述了 MegaScale 的部署和运营经验。为LLM（大型语言模型）训练构建了专用的 A I集群。截至2023年9月，在生产环境中用于 LLM 训练的最大 AI 集群包含超过10,000个NVIDIA Ampere GPU。字节还正在基于最新的 NVIDIA Hopper GPU 构建大规模集群，因为NVIDIA正在加快生产进度。

6.1 Training Performance

175B 模型的强扩展训练性能。在使用 3072 到 12288 个GPU进行训练时，将 batch size 设置为 6144。对于 256 到 1024 个GPU，由于 GPU 内存限制，我们将批量大小减小到 768。在此报告了训练 300B tokens 所需的训练时间。MFU 列中括号中的数字表示相较于Megatron-LM 的 MegaScale 加速比。

图12

Megatron-LM 和 MegaScale 在 530B 模型上的弱扩展训练性能，其中 batch size 与 GPU 数量成比例地进行了缩放。

图13

消融研究：字节评估了 MegaScale 优化技术的有效性。图 14 展示了在 256 个GPU上训练175B模型时，不同优化技术对 MFU 改进的详细情况。基准是原始的Megatron-LM，其MFU为 47.7%。值得注意的是，在这个评估中，Megatron-LM和MegaScale都开启了网络优化。我们首先对Megatron-LM应用了两种算法技术，即并行 Transformer 块和滑动窗口注意力，实现了 5.6% 的MFU改进。通信是大规模语言模型训练的主要瓶颈，而 MegaScale 的 3D 并行通信重叠隐藏了开销，并使训练加速了 6.2% 的MFU。进一步采用了高效的op，获得了 1.7% 的加速。其他优化技术，如数据流水线优化和 6.3 中提到的问题代码消除，进一步实现了 1.1% 的性能提升。最后，我们使用 LAMB 优化器将批量大小从 256 扩展到 768，这显著延长了交错流水线并行中的稳定阶段，并实现了 3.0% 的MFU改进。综上所述，通过所有这些优化，MegaScale 在 MFU 数量上比基准模型提高了 17.6%。

图14

这些结果表明，MegaScale的优化技术在提高训练性能方面非常有效。通过算法技术、通信优化、高效运算符以及其他优化措施的应用，MegaScale能够显著提高MFU并加速训练过程。这些优化技术的结合使得MegaScale在大规模语言模型训练中表现出色，并取得了显著的性能提升。这进一步证明了MegaScale作为一种高效的大规模训练解决方案的能力，并为加快语言模型研究和开发的进展提供了有力支持。

6.2 Model Convergence and Stability

图15

6.3 Problems Discovered and Fixed

字节对上述生产训练作业的故障记录进行了几周的分析。研究结果表明，在这些记录中，超过90%的异常情况都可以通过强大训练框架自动检测、定位和恢复，例如 CUDA 错误和segmentation fault。检测故障并执行诊断测试所需的平均时间不到10分钟。此外，系统可以在 latest checkpoints 后的 15 分钟内赶上训练进度，保持超过90%的有效训练时间比例。

这些结果表明，MegaScale 具备强大的故障诊断和修复能力。通过自动检测和定位异常情况，并在短时间内执行诊断测试，MegaScale 能够快速恢复训练过程，并保持高效的训练时间利用率。这为大规模语言模型的生产训练提供了可靠的保障，减少了故障对训练过程的影响，并提高了训练的稳定性和可靠性。同时，故障排除工具的应用也为我们解决一些复杂问题提供了有力的支持，进一步提升了训练的效率和可行性。

6.3.1 Computational stragglers

在利用CUDA events 计时器的基础上，字节在多个实验设置中进行了另一个相关观察。注意到，与其他节点相比，特定主机执行相同的前向计算大约需要多出 10% 的时间。在不同实验中的这种一致性观察让我们得出结论，问题不在于软件，而是集群中某些机器固有的问题。在将这些有问题的主机从集群中隔离和移除后，我们观察到MFU提高了约0.7%。

这个发现表明，在大规模语言模型的训练过程中，存在一些计算滞后的主机。这些主机的性能可能受到一些因素的影响，例如硬件配置或网络连接。通过识别并排除这些问题主机，能够提高整体的训练效率。0.7% 的 MFU 改进虽然看似不大，但在大规模训练中，这个改进可以显著提升训练速度和资源利用率。因此，解决计算滞后者问题对于实现高效的大规模语言模型训练是非常重要的。

6.3.2 MFU decreasing

在这样的大规模训练实验中，字节观察到训练效率并不是始终保持一致的。相反，随着训练的进行，训练作业的 MFU 逐渐下降。通过基于CUDA events 计时器指标的逐步分析，我们注意到了几个关键发现。

• 不规则的垃圾回收可能会给训练过程引入干扰

• PyTorch 操作可能会导致性能波动。

在修改或删除这些有问题的代码段之后，不再观察到 MFU 的显著下降，如图16所示。

图16

这个发现表明，在大规模训练中，存在一些导致训练效率下降的代码段。这些代码段的波动性可能会干扰训练过程，导致某些进程的执行时间延迟，从而影响整体训练效率。通过识别并修改或删除这些有问题的代码段，我们能够提高训练的稳定性和效率，避免 MFU 的明显下降。这进一步证明了 MegaScale 的故障诊断和修复能力的重要性，以及故障排除工具在解决复杂问题中的作用。

6.3.3 Frequent network interface flapping problem

偶尔会遇到训练停滞或训练速度下降的问题，原因是频繁的网络接口抖动。当发生网络接口抖动现象时，网络接口首先会断开，然后再次连接。断开和重新连接之间的间隔通常持续几秒钟。在断开的过程中，所有正在传输的数据包都会丢失。

• 从中学到的第一个教训是应该将超时阈值明确地设置为较大的值（猜测是NCCL_IB_TIMEOUT），否则默认值会使 NCCL 的超时时间非常短，在网络卡重新连接之前就会返回完成错误。

• 学到的第二个教训是，这个问题的根本原因是网卡、AOC电缆和交换机之间的链路质量不好。通过对网络卡信号强度、AOC 电缆质量和交换机侧信号强度进行较低级别的质量控制，可以将抖动频率降低到令人满意的水平。

这个发现表明，频繁的网络接口抖动可能会对训练过程产生负面影响。由于网络接口抖动导致数据包丢失，可能会导致训练停滞或训练速度下降。为了解决这个问题，需要采取一些措施来改善链路质量，包括检查和调整网络卡信号强度、更换较低质量控制的 AOC 电缆以及优化交换机侧的信号强度。通过降低抖动频率，可以提高训练的稳定性和效率。这也强调了在大规模训练中网络基础设施的重要性，以及对网络连接质量的监控和维护的必要性。

7. 相关工作

EverFlow 、LossRadar 和NetBouncer 等工具利用交换机的能力来诊断网络问题，如网络路径故障或特定网络端口故障。NetBouncer利用IP-in-IP隧道技术进行路径探测。EverFlow需要将网络数据包镜像到集中服务器以进行调试。（见原文）

8. 总结

在这篇论文中，深入研究了 MegaScale 的设计、实现和部署。MegaScale 是一个用于在超过10,000 个GPU的规模上进行 LLM（Large Language Model）训练的生产级系统。MegaScale利用算法和系统的协同设计来优化训练效率。在使用 12,288 个GPU训练一个 175B 的 LLM 模型时，MegaScale 实现了 55.2% 的最大训练吞吐量（MFU），相比于 Megatron-LM 有1.34 倍的改进。强调在整个训练过程中需要容错能力，并实现了一个定制的鲁棒训练框架来自动定位和修复故障。提供了一套全面的监控工具，用于对系统组件和事件进行深入观察，有助于识别复杂异常的根本原因。字节这篇工作细致的修改/优化了现有 LLM 主流技术，给 LLM的训练的人员提供了实用的见解，也为这个快速发展的领域的未来研究铺平了道路。

9. 参考

1. https://arxiv.org/pdf/2402.1562

- The End -

GiantPandaCV

长按二维码关注我们

本公众号专注：

1. 技术分享；

2. 学术交流；

3. 资料共享。

欢迎关注我们，一起成长！