Gemini: Fast Failure Recovery in Distributed Training with In-Memory Checkpoints

Gemini：利用内存检查点在分布式训练中实现快速故障恢复

作者/机构: Zhuang Wang (莱斯大学), Zhen Jia (亚马逊网络服务), Shuai Zheng (亚马逊网络服务), Zhen Zhang (亚马逊网络服务), Xinwei Fu (亚马逊网络服务), T. S. Eugene Ng (莱斯大学), Yida Wang (亚马逊网络服务)

A1 主要贡献

本文介绍了一个名为 Gemini 的分布式训练系统，旨在通过利用主机CPU内存的高聚合带宽进行检查点操作，从而为大规模模型训练实现快速的故障恢复。

核心问题：
大规模深度学习模型的训练因涉及大量资源和长时间运行而频繁遭遇故障。现有的故障恢复方案依赖于将检查点存储在远程持久化存储中，但受限于远程存储的低带宽，导致恢复成本高昂。具体表现为：
1. 恢复时间长：从远程存储中检索检查点需要数十分钟。
2. 训练进度损失大：由于检查点操作耗时，其频率很低（例如数小时一次），导致故障发生时会丢失数小时的训练进度。
这使得现有方案无法高效处理训练故障，例如在OPT-175B的训练中，约有178,000个GPU小时因各类训练故障而被浪费。

研究目标：
本文的目标是设计一个能够显著降低故障恢复开销的分布式训练系统。具体而言，系统应能实现：
1. 快速的检查点检索：将检索时间从数十分钟缩短至秒级。
2. 高频率的检查点操作：理想情况下，实现每个训练迭代都进行一次检查点操作。
通过这两个目标，最大限度地减少因故障导致的“浪费时间”（包括丢失的训练时间和检查点检索时间）。

创新点与主要贡献：
为实现上述目标，Gemini系统利用CPU内存进行检查点存储，并解决了由此带来的两个核心挑战。其主要贡献如下：
1. 首次利用CPU内存检查点实现高效故障恢复：据我们所知，Gemini是第一个利用CPU内存检查点为大规模模型训练实现高效故障恢复的系统。它设计了一个分层存储架构，将用于故障恢复的检查点存储在本地和远程CPU内存中，同时将用于其他目的（如迁移学习）的检查点存储在远程持久化存储中。
2. 可证明的近乎最优的检查点放置策略：为了解决CPU内存中检查点因机器故障而失效的问题，本文提出了一种检查点放置策略。该策略旨在最大化从CPU内存成功恢复故障的概率。我们证明了，当参与训练的机器数量能被副本数量整除时，该策略是最优的；在其他情况下，该策略也是近乎最优的，并给出了其性能边界。
3. 最小化训练干扰的通信调度算法：为了解决检查点流量与训练流量共享网络资源可能导致的性能干扰问题，本文提出了一种通信调度算法。该算法通过将检查点流量流水线化，并将其穿插在训练计算过程中的网络空闲时段，从而最小化甚至消除对训练吞吐量的影响。

A3 背景知识/关键观察/设计原则

2.1 模型训练中的故障恢复

模型训练中的频繁故障。由于大规模模型训练涉及大量GPU且耗时漫长，开发者观察到许多故障。例如，训练OPT-175B模型使用了992个NVIDIA A100 GPU，在两个月的时间里遇到了大约110次故障【索引14，OPT-175B logbook. https://github.com/facebookresearch/metaseq/tree/main/projects/OPT/chronicles, 2023】。在训练BLOOM模型期间也报告了类似情况【索引3，BLOOM Chronicles. https://github.com/bigscience-workshop/bigscience/blob/master/train/tr11-176B-ml/chronicles.md, 2022】。

故障恢复浪费的时间。我们注意到大规模模型训练故障导致了计算资源的严重浪费。模型状态（即可学习参数和优化器状态）在训练期间驻留在GPU内存中。当故障发生时，必须通过检索最新的检查点来回滚模型状态以进行故障恢复。如图1所示，故障发生在第310次迭代，但最新的可用检查点在第200次迭代。故障恢复后，从第200次到第310次迭代的训练进度丢失了。此外，在故障恢复过程中检索最新检查点会产生开销。

浪费时间的定义与构成。我们将浪费时间定义为故障前丢失的训练过程所花费的时间与故障恢复期间检索最新检查点的时间之和。如图1所示，浪费时间描述了因故障而暂停的训练过程的时间跨度，即就训练过程而言浪费的计算资源时间。它由三个因素决定：
* 检查点时间（$t_{checkpoint}$），即完成一次模型状态检查点所需的时间。
* 检查点频率（$F_c$），决定训练系统将模型状态保存到存储系统的频率。
* 检索时间（$t_{retrieval}$），即检索最新完整检查点所需的时间。

平均浪费时间公式。本文使用平均浪费时间作为评估检查点解决方案性能的主要指标，因为故障可能在任何时候发生，浪费的时间也各不相同。最佳情况是故障恰好在检查点完成后发生，浪费时间为 $t_{checkpoint} + t_{retrieval}$。最坏情况是故障恰好在检查点完成前发生，浪费时间为 $t_{checkpoint} + 1/F_c + t_{retrieval}$。假设故障在两个连续检查点之间均匀分布，平均浪费时间（表示为 $T_{wasted}$）可以表示为：

检查点频率的约束条件。此外，还存在以下约束条件，其中 $t_{iteration}$ 是迭代时间。一个检查点必须在其前一个检查点完成后才能开始，并且由于模型状态在每次迭代中更新一次，因此在一次迭代内进行多次检查点没有必要。

减少浪费时间的关键。为了减少浪费时间，关键在于减少检查点时间 $t_{checkpoint}$ 以实现更高的检查点频率 $F_c$，而最优频率 $F_c$ 是每次迭代一次，即 $1/t_{iteration}$。

2.2 现有解决方案的局限性

现有方案因使用远程持久存储而无法实现高检查点频率。现有解决方案在特定频率下对模型状态进行检查点，并将检查点持久化到远程持久存储系统【索引48，Jayashree Mohan, Amar Phanishayee, and Vijay Chidambaram. Checkfreq: Frequent, fine-grained DNN checkpointing. In FAST, volume 21, pages 203–216, 2021】【索引65，Teven Le Scao, et al. BLOOM: A 176B-parameter open-access multilingual language model. arXiv preprint arXiv:2211.05100, 2022】。通常做法是，现有解决方案以低频率进行检查点，例如在BLOOM训练中每三小时一次【索引3，BLOOM Chronicles. https://github.com/bigscience-workshop/bigscience/blob/master/train/tr11-176B-ml/chronicles.md, 2022】，以减少所需的存储容量。当故障发生时，会浪费数小时的计算资源。考虑到训练涉及数千个GPU，并且在训练过程中会经历数百次故障，总的计算资源浪费是巨大的，训练时间 slowdown 可达43%【索引44，Kiwan Maeng, et al. Understanding and improving failure tolerant training for deep learning recommendation with partial recovery. Proceedings of Machine Learning and Systems, 3:637–651, 2021】。任意增加检查点频率是不可行的，因为检查点频率受限于远程持久存储的带宽【索引28，Assaf Eisenman, et al. Check-N-Run: a checkpointing system for training deep learning recommendation models. In 19th USENIX Symposium on Networked Systems Design and Implementation (NSDI 22), pages 929–943, 2022】。例如，当带宽为20Gbps时，将MT-NLG【索引68，Shaden Smith, et al. Using DeepSpeed and Megatron to train Megatron-Turing NLG 530B, a large-scale generative language model. arXiv preprint arXiv:2201.11990, 2022】的模型状态检查点到远程持久存储需要42分钟。根据公式(1)，故障恢复的平均浪费时间为105分钟，这使得训练系统效率低下。

2.3 机遇与挑战

最小化故障恢复的浪费时间对提高分布式训练系统效率至关重要。尤其是在大规模模型训练中。接下来我们探讨实现这一目标的机遇，并讨论所识别的挑战。

利用CPU内存进行检查点操作的机遇。低带宽严重限制了向远程持久存储进行检查点的频率。我们观察到GPU机器中的CPU内存足以存储几个检查点。表1比较了用于大规模模型训练的公有云中流行GPU实例的GPU和CPU内存，表明CPU内存远大于GPU内存。这一观察为Gemini将最新检查点存储在CPU内存中提供了绝佳机会。Gemini可以利用连接GPU实例的网络进行检查点操作。由于该网络为训练进行了优化，其带宽远高于远程持久存储的带宽【索引16，P4d.24xlarge in AWS. https://aws.amazon.com/ec2/instance-types/p4/, 2023】。因此，Gemini可以实现比现有解决方案高得多的故障恢复检查点频率。

解耦不同用途的检查点。一个担忧是CPU内存大小不足以存储用于故障恢复之外目的（如迁移学习【索引56，Sinno Jialin Pan and Qiang Yang. A survey on transfer learning. IEEE Transactions on knowledge and data engineering, 22(10):1345–1359, 2010】和模型调试【索引23，Yu Chen, Zhenming Liu, Bin Ren, and Xin Jin. On efficient constructions of checkpoints. In International Conference on Machine Learning, pages 1627–136. PMLR, 2020】【索引28，Assaf Eisenman, et al. Check-N-Run: a checkpointing system for training deep learning recommendation models. In 19th USENIX Symposium on Networked Systems Design and Implementation (NSDI 22), pages 929–943, 2022】）的检查点历史记录。为了解决这个问题，Gemini将不同目的的检查点解耦。它仅将用于故障恢复的检查点存储在CPU内存中，而将用于其他目的的检查点存储在远程持久存储中。

面临的挑战。向CPU内存进行检查点操作虽然可以实现比现有解决方案高得多的频率，从而减少浪费的时间，但也带来了新的挑战。
1. 如何最大化从CPU内存中存储的检查点进行故障恢复的概率？ 尽管向CPU内存进行检查点操作可以实现高频率，但当故障发生时，CPU内存中检查点的可用性无法得到保证。在CPU内存中检查点不可用的情况下，我们不得不回退到使用存储在远程持久存储中的低频检查点进行故障恢复，导致大量时间浪费。
2. 如何最小化检查点流量对模型训练的干扰？ 当将检查点存储在CPU内存中时，用于训练和检查点的通信流量必须共享同一网络。若无精心设计，检查点流量会干扰训练流量，损害训练吞吐量。这种干扰开销不容忽视，因为它可能对每次迭代产生负面影响，这会大大削弱通过向CPU内存进行检查点操作所带来的好处。

A2 方法细节

3 Gemini系统架构

我们提出了Gemini，它通过实现高检查点频率（甚至每次迭代一次）来优化分布式训练中的故障恢复开销。它通过将检查点写入CPU内存来最小化浪费时间，并解决了前述的两个挑战。图2展示了Gemini的架构，该架构由两个模块组成：1）检查点创建模块（3.1节）；2）故障恢复模块（3.2节）。这两个模块协同工作，一旦发生故障便恢复训练。

3.1 检查点创建模块

Gemini采用解耦和分层存储设计进行检查点操作。在Gemini中，检查点创建模块将每个GPU机器的检查点存储到不同的目的地，包括本地CPU内存、其他机器上的远程CPU内存以及远程持久存储。检查点创建模块将用于故障恢复的检查点存储在本地和远程CPU内存中。这些检查点由Gemini的检查点创建模块管理，对用户透明。另一方面，用于其他目的的检查点，如迁移学习【索引56，Sinno Jialin Pan and Qiang Yang. A survey on transfer learning. IEEE Transactions on knowledge and data engineering, 22(10):1345–1359, 2010】和模型调试【索引28，Assaf Eisenman, et al. Check-N-Run: a checkpointing system for training deep learning recommendation models. In 19th USENIX Symposium on Networked Systems Design and Implementation (NSDI 22), pages 929–943, 2022】，则存储在远程持久存储中并由用户管理。在故障恢复期间，检查点首先从本地CPU内存中检索，如果本地CPU内存中不可用，则从远程CPU内存中检索。如果本地和远程CPU内存中的检查点都不可用，Gemini将从远程持久存储中检索检查点。

检查点创建模块的工作流程。如图2所示，每个训练机器都有一个Gemini工作代理，用于向CPU内存进行检查点操作。将用于故障恢复的检查点放置在CPU内存的何处决定了故障恢复的能力。为了最大化从CPU内存中恢复故障的概率，我们提出了一种可证明的近乎最优的检查点放置策略，用于向CPU内存进行检查点操作（第4节）。Gemini在训练初始化时确定检查点放置策略。在运行时，每台机器上的Gemini工作代理根据放置策略和检查点频率将检查点从GPU内存传送到CPU内存。为了最小化甚至消除检查点流量对模型训练的干扰，我们提出了一种流量调度算法，该算法将检查点流量流水线化并与训练流量交错进行（第5节）。

3.2 故障恢复模块

Gemini故障恢复模块的组成。Gemini的故障恢复模块有四个组件：一组Gemini工作代理、一个Gemini根代理、一个分布式键值存储和一个云操作员。工作代理监控自己机器的健康状态，并在分布式键值存储【索引9，etcd. https://etcd.io/, 2023】【索引29，Robert Escriva, Bernard Wong, and Emin Gün Sirer. HyperDex: A distributed, searchable key-value store. In Proceedings of the ACM SIGCOMM 2012 conference, pages 25–36, 2012】【索引30，Roxana Geambasu, et al. Comet: An active distributed key-value store. In OSDI, pages 323–336, 2010】中更新它。唯一的根代理运行在一个带有工作代理的常规训练机器上。运行根代理的训练机器被称为根机器。根代理定期从分布式键值存储中检查每台训练机器的健康状态。云操作员管理训练计算资源，并根据需要用健康的机器替换故障机器。

根代理的故障处理机制。如果根代理检测到训练机器故障，根代理会根据故障类型采取相应措施（第6节）。例如，当需要更换训练机器时，根代理会与云操作员交互以完成机器更换，并指导被替换的机器从何处检索其检查点。

根机器故障的处理。工作代理也定期在分布式键值存储中检查根机器的健康状态。当根机器的健康状态在预定义的时间阈值内未更新时，则检测到根机器故障。在根机器故障的情况下，一个存活的工作机器将被提升为根机器，并初始化一个新的工作机器来替换故障的机器。Gemini依赖于分布式键值存储中的领导者选举方法【索引40，Leslie Lamport. Paxos made simple. ACM SIGACT News, 32(4):51–58, 2001】【索引52，Diego Ongaro and John Ousterhout. In search of an understandable consensus algorithm. In 2014 USENIX Annual Technical Conference, pages 305–319, 2014】来进行根机器的选择。

4 面向CPU内存的检查点放置

问题的提出。为了减少浪费的时间，Gemini将检查点写入CPU内存以实现高频率。然而，当某些GPU机器与训练断开连接时，存储在CPU内存中的检查点可能会变得无法用于恢复。在这种情况下，Gemini必须从远程持久存储中获取数据进行恢复，导致大量时间浪费。增加更多的检查点副本可以减少CPU内存中检查点不可用的可能性，但也会增加CPU内存使用量和与训练流量的网络带宽竞争。除了副本数量，我们的研究揭示，检查点放置策略，即在哪里存储检查点副本，也会影响这种可能性，如图3所示。因此，我们的目标是找出在给定特定副本数量下，能够最大化从CPU内存进行故障恢复概率的最佳放置策略。这个问题可以被形式化如下：

问题1。给定$N$台机器和$k$个检查点副本，什么是将$k$个副本分布在$N$台机器中的最优放置策略，以最大化从CPU内存进行故障恢复的概率？

混合放置策略算法。我们设计了一种如算法1所述的混合放置策略来解决问题1。该算法的输入是机器数量$N$和副本数量$k$。输出是机器分组分配和具体策略。如果机器数量$N$可以被副本数量$k$整除，我们将对所有参与训练的机器应用分组放置策略。$N$台机器被分成$N/k$个组，每个组有$k$台机器。在训练期间，每台机器将其检查点广播到同一组中的$k-1$台机器。它还将一个检查点写入自己的CPU内存作为本地副本，这是Gemini分层检查点解决方案中的一个层级。否则，当$N$不能被$k$整除时，我们将$N$台机器分成$\lfloor N/k \rfloor$个组，并对前$\lfloor N/k \rfloor - 1$个组应用分组放置策略。对于最后的$N-k(\lfloor N/k \rfloor-1)$台机器，我们应用环形放置策略，其中每台机器将其GPU内存中的检查点写入其本地CPU内存，并向其左侧的连续$k-1$台机器发送检查点。无论采用何种放置策略，Gemini都会将检查点从GPU内存复制到本地CPU内存，并将其视为本地副本。这有两个优点：1）它可以减轻与训练流量的网络带宽争用；2）对于某些故障类型，例如软件故障（参见6.1节），Gemini可以直接从本地副本恢复训练以加速检查点检索。我们之所以倾向于分组放置策略，是因为与具有相同副本数量的环形放置策略相比，它从CPU内存恢复的可能性更大。我们还有关于混合放置策略性能的定理1。证明请参见附录A。

输入: N 是GPU机器的数量，k 是检查点副本的数量。
输出: 分组列表G和策略。
1 Function placement_strategy(N, k):
2   G = []
3   g = ⌊N/k⌋
4   for i ← 0 to g-1 do
5     gi = []
6     for j ← 1 to k do
7       gi.append(i * k + j)
8     end
9     G.append(gi)
10  end
11  strategy = ”group”
12  if N is not divisible by k then
13    strategy = ”mixed”
      // 将剩余的机器添加到最后一个组
14    for j ← g * k + 1 to N do
15      G[-1].append(j)
16    end
17  end
18  return G, strategy

定理1。针对检查点放置问题1：1. 当$N$可被$k$整除时，混合放置策略（等同于分组放置策略）是最优放置策略。

放置策略示例。图3a展示了一个$N=4$和$k=2$的分组放置策略示例。有两个组，每个组有两台机器。每台机器都有一个本地检查点，即其本地机器的检查点，以及一个远程检查点，即来自同一组中另一台机器的检查点。图3b展示了一个$N=4$和$k=2$的环形放置策略示例，其中所有机器形成一个环形结构以进行CPU内存检查点。假设两台机器同时发生故障。使用分组放置策略，除了机器1和2或机器3和4同时发生故障（总共两种可能情况）外，训练可以从CPU内存中恢复故障。然而，使用环形放置策略，任何两台连续机器的并发故障（总共四种可能情况）都将导致存储在CPU内存中的一个检查点的两个副本都丢失。因此，使用分组放置策略时，训练必须从远程持久存储中获取数据进行故障恢复的概率比使用环形放置策略时低50%。图3c也展示了一个$N=5$和$k=2$的混合放置策略示例，其中前两台机器形成一个组，后三台机器形成一个环。

故障恢复概率的计算。通过分组放置策略，我们使用推论1计算Gemini可以从CPU内存中恢复故障的概率。证明请参见附录B。根据推论1，当机器数量$N$为16，副本数量$k$为2，故障机器$f$为2时，概率为93.3%，并且随着$N$的增加而增加。这意味着使用两个检查点副本，Gemini在大多数情况下可以从CPU内存恢复训练。

推论1。当$N$可被$k$整除且$f$台机器同时断开连接时，Gemini从CPU内存恢复故障的概率是：

5 最小化训练干扰

频繁地将检查点写入远程CPU内存可能会因与训练流量潜在的网络带宽竞争而妨碍整体训练性能。我们的主要目标是在不损害训练性能的情况下最小化浪费的时间。在本节中，我们将解释Gemini如何减轻由频繁检查点引起的干扰。我们首先探讨最小化检查点对模型训练影响的可能性（第5.1节），然后讨论我们为克服这些挑战所采取的挑战和方法（第5.2节）。最后，我们详细阐述了在Gemini中使用的具体算法和机制（第5.3节和第5.4节）。

5.1 流量交错

利用网络空闲时间进行检查点通信。现代分布式训练，如大规模模型训练，依赖于集体通信操作进行同步。例如，在ZeRO【索引62，Samyam Rajbhandari, Jeff Rasley, Olatunji Ruwase, and Yuxiong He. ZeRO: Memory optimizations toward training trillion parameter models. In SC20: International Conference for High Performance Computing, Networking, Storage and Analysis, pages 1–16. IEEE, 2020】中，每个GPU在正向和反向传播的计算之前，都需要从其他GPU获取每一层的参数。当某一层参数未就绪但前一层的计算已完成时，这些通信操作会阻塞计算。我们将用于模型计算的通信流量，包括梯度同步和参数获取，称为训练流量。图4a显示了模型计算过程中的训练流量示例。当向远程CPU内存进行检查点操作时，其流量（称为检查点流量）与训练流量共享同一网络，导致潜在的网络资源争用，可能会延迟训练流量并妨碍计算。如果在后续迭代开始时执行检查点操作，它会阻塞训练过程，并给模型训练带来不可忽略的开销，如图4b所示。这严重抵消了通过向CPU内存进行检查点操作而减少浪费时间所带来的好处。因此，Gemini必须仔细编排检查点流量，以最小化其对训练吞吐量的干扰。幸运的是，我们观察到网络在与计算重叠的时间段内有空闲时段，这在大规模模型训练中自然发生。这一观察为Gemini在这些空闲时段插入检查点流量，并使检查点通信与计算重叠提供了绝佳机会，如图4c所示。

5.2 困难与方法

Gemini的设计思路与挑战。Gemini需要将检查点从本地GPU内存写入远程机器的CPU内存。它首先使用GPU到GPU的通信在机器之间发送检查点，以便将检查点流量与训练流量交错，后者也使用机器间的直接GPU到GPU通信【索引41，Ang Li, et al. Evaluating modern GPU interconnect. IEEE Transactions on Parallel and Distributed Systems, 31(1):94–110, 2019】【索引64，Davide Rossetti and S Team. GPUDirect: Integrating the GPU with a network interface. In GPU Technology Conference, page 185, 2015】。之后，它通过GPU到CPU的复制将检查点从远程机器的GPU内存传输到它们的CPU内存。这种设计允许在应用层调度训练流量和检查点流量，而无需依赖网络层。Gemini通过利用现有的GPU间通信库（如NCCL【索引1】）以统一的方式编排这两种类型的流量。然而，这种设计引发了两个实际困难。

困难：额外的GPU内存消耗。天真地将整个检查点从本地GPU发送到远程GPU会消耗大量GPU内存，可能引发GPU内存不足（OOM）并导致训练过程崩溃，如图5b所示。在大规模模型训练中，检查点大小巨大。例如，GPT2-100B【索引87，Zhen Zhang, et al. MiCS: Near-linear scaling for training gigantic model on public. Proceedings of the VLDB Endowment, 16(1):37–50, 2022】在每个GPU上的检查点大小为9.4GB。此外，大部分GPU内存已被用于存储模型参数、梯度和中间结果。因此，在大型模型训练期间，远程GPU不太可能容纳整个检查点。

方法：分区检查点。虽然一个几GB的完整检查点对于远程GPU来说太大了，但我们根据我们的性能分析结果观察到，每个GPU在训练期间通常有几百MB的可用内存。Gemini首先为检查点通信保留一个小的GPU内存缓冲区，然后将一个完整的检查点分成小块，并分别传输这些小块。远程GPU在一次通信完成后将接收到的块移动到CPU内存，使缓冲区可用于下一次通信。图5c说明了分区检查点的过程。

困难：本地GPU到CPU复制开销。向远程CPU内存进行检查点操作包括在接收端进行GPU到CPU复制的程序。在GPU到CPU复制完成之前，发送方无法传输新的检查点块，这导致GPU到GPU通信时间线中出现通信气泡，如图5c所示。由于GPU到CPU内存的复制带宽与机器间的GPU到GPU网络带宽相当，气泡时间可能接近机器间的GPU到GPU检查点通信时间，这可能加剧对模型训练的干扰。

方法：流水线化检查点传输。Gemini使用流水线机制，使检查点通信能够充分利用网络空闲时间。它将保留的GPU内存缓冲区分割成多个子缓冲区，并将检查点分块以适应这些子缓冲区。Gemini交替使用这些子缓冲区来传输检查点块。当将一个块从GPU复制到CPU内存时，Gemini可以同时在一个单独的子缓冲区中使用GPU到GPU通信接收一个新的检查点块。图5d展示了一个使用两个子缓冲区的示例。机器间的GPU到GPU通信与本地GPU到CPU内存复制重叠，空闲时间被充分用于检查点流量。

算法2：检查点分区算法

5.3 检查点分区算法

Gemini使用检查点分区算法（算法2）来为传输流水线划分检查点。给定一组分析出的网络空闲时间段 $T = \{t_1, t_2, . . . , t_m\}$（在5.4节讨论），算法2生成一个检查点分区的调度。假设Gemini中有$b$个GPU缓冲区，每个缓冲区的大小为$S/b$，其中$S$是总共保留的GPU内存大小。假设有$k$个检查点副本，其中$k-1$个副本发送到远程CPU内存，一个存储在本地。假设发送大小为$s$的分区到接收方的时间长度为$f(s) = \alpha + s/\beta$，其中$\alpha$是传输的启动时间，$\beta$是网络带宽【索引21，Ammar Ahmad Awan, et al. Optimized broadcast for deep learning workloads on dense-GPU InfiniBand clusters. In Proceedings of the 25th European MPI Users’ Group Meeting, pages 1–9, 2018】【索引72，Rajeev Thakur, Rolf Rabenseifner, and William Gropp. Optimization of collective communication operations in MPICH. The International Journal of High Performance Computing Applications, 19(1), 2005】【索引87，Zhen Zhang, et al. MiCS: Near-linear scaling for training gigantic model on public. Proceedings of the VLDB Endowment, 16(1):37–50, 2022】。

算法2的工作逻辑。算法2使用一个系数$\gamma \in (0, 1)$来考虑分析出的时间段在迭代间的变化（第7行）。由于每个缓冲区的大小是$S/b$，最大的检查点块大小也是$S/b$。算法通过多轮检查在每个空闲时间段内可以插入多少个块。在每一轮中，它将$f(S/b)$与剩余的空闲时间（remain_timespan）进行比较。如果remain_timespan更大，它将size设置为最大块大小$S/b$（第9-10行）；否则，它将大小设置为在remain_timespan期间可以传输的流量大小（第11行）。然后，它将size与剩余的检查点大小（remain_ckpt）进行比较，并取较小者作为块大小（第14行）。接着，它相应地更新remain_timespan和remain_ckpt以进行下一轮（第15-19行）。当remain_ckpt等于零时，算法完成一个检查点的分区。如果为了更高的CPU内存故障恢复率而有多个检查点副本，算法将remain_ckpt重置为检查点大小，并再次为新的检查点确定分区（第21-23行）。算法在所有检查点都分区完毕后返回schedule。

在一次迭代内完成检查点。然而，仍然可能出现检查点所需的总时间无法容纳在可用的网络空闲时间段内的情况。在这种情况下，Gemini将未完成的检查点流量放置在最后一个空闲时间段，因为算法2将最后一个空闲时间段的间隔设置为正无穷大（第2行）。尽管在这种情况下检查点通信会阻碍更新操作并延长迭代时间，Gemini可以通过降低检查点频率来分摊所产生的开销。

将检查点从GPU移动到本地CPU。根据我们在第4节讨论的放置策略，每台机器还需要将其检查点从GPU内存复制到其本地CPU内存。这个检查点复制不会产生跨机器的流量。Gemini也对这个副本进行分区，并将其GPU到CPU的复制与训练流量的通信重叠。这样，本地GPU到CPU复制其自己的检查点与其他检查点之间没有干扰。

5.4 在线分析

Gemini采用在线分析方法来捕获网络空闲时间。在训练的前几个迭代（例如，我们的实现中是20个迭代）中，Gemini不进行检查点操作，以便捕获模型训练期间的网络空闲时间段。它记录一次迭代中所有通信操作的开始和结束时间，以推导出通信流量的时间线。然后，Gemini获取每个空闲时间段的平均时间间隔，用于后续的检查点流量调度。我们观察到，分析出的时间线在各个迭代中几乎保持不变，这与之前的研究一致【索引77，Zhuang Wang, Haibin Lin, Yibo Zhu, and TS Eugene Ng. Hi-speed DNN training with espresso. In EuroSys 23, pages 867–882, 2023】【索引79，Zhuang Wang, et al. DRAGONN: Distributed randomized approximate gradients of neural networks. In International Conference on Machine Learning, pages 23274–23291. PMLR, 2022】【索引86，Zhen Zhang, et al. Is network the bottleneck of distributed training? In Proceedings of the Workshop on Network Meets AI & ML, pages 8–13, 2020】。测量的归一化标准差小于10%。Gemini使用这些空闲时间段间隔，根据第5.3节描述的算法2，来确定每个空闲时间段中的检查点分区。

6 从故障中恢复训练

Gemini通过混合检查点放置和流量交错算法实现了高频检查点。在本节中，我们将解释当故障发生时，Gemini如何使用这些检查点来恢复训练。我们首先定义我们的故障分类，然后描述Gemini如何相应地恢复训练。

6.1 故障类型

故障分类。在大型模型训练期间可能发生各种故障【索引36，Myeongjae Jeon, et al. Analysis of large-scale multitenant GPU clusters for DNN training workloads. In USENIX Annual Technical Conference, pages 947–960, 2019】【索引55，George Ostrouchov, et al. GPU lifetimes on Titan supercomputer. In SC20, pages 1–14. IEEE, 2020】【索引70，Amir Taherin, et al. Examining failures and repairs on supercomputers with multi-GPU compute nodes. In DSN, pages 305–313. IEEE, 2021】【索引75，Devesh Tiwari, et al. Understanding GPU errors on large-scale HPC systems. In HPCA, pages 331–342. IEEE, 2015】，这些故障有不同的根本原因和后果。我们从恢复的角度将这些故障分为两类：软件故障和硬件故障，遵循文献【索引31，Phillipa Gill, Navendu Jain, and Nachiappan Nagappan. Understanding network failures in data centers. In SIGCOMM, pages 350–361, 2011】【索引36】【索引55】【索引70】【索引74，Devesh Tiwari, et al. Reliability lessons learned from GPU experience with the Titan supercomputer. In SC, pages 1–12, 2015】【索引75】的做法。

软件故障。由软件中的错误或数据中的错误引起。软件故障可以通过重启训练过程来修复，而无需更换硬件。

硬件故障。由硬件问题引起，如GPU故障和网络故障。例如，由辐射引起的位损坏可能导致双比特错误，从而导致数据损坏【索引36】【索引75】。连接GPU机器的网络链路和交换机可能会失败【索引31】【索引71，Cheng Tan, et al. NetBouncer: Active device and link failure localization in data center networks. In NSDI, pages 599–614, 2019】，使它们与训练断开连接。这些故障可能在单台机器或多台机器上同时发生。训练集群通常会检测有问题的机器，然后在恢复训练之前用健康的机器替换它们。

6.2 故障恢复机制

现有解决方案的恢复机制。现有的检查点解决方案【索引28，Assaf Eisenman, et al. Check-N-Run. In NSDI 22, pages 929–943, 2022】【索引65，Teven Le Scao, et al. BLOOM. arXiv preprint arXiv:2211.05100, 2022】【索引85，Susan Zhang, et al. OPT: Open pre-trained transformer language models. arXiv preprint arXiv:2205.01068, 2022】不区分软件故障和硬件故障。如图6a所示，无论故障类型如何，它们总是从远程持久存储中检索检查点，导致昂贵的浪费时间。在本小节中，我们将分别介绍Gemini对两种故障类型的恢复机制。

(a) 现有解决方案对任何类型的故障。所有检查点总是从远程持久存储中检索。

软件故障恢复。从软件故障中恢复不需要从其他机器获取检查点，并且训练配置（例如，机器的排名ID）保持不变。当发生软件故障时，训练过程被中断，但硬件保持健康，所有存储在CPU内存中的检查点仍然可以访问。因为每台机器都存储了自己检查点的副本，所有机器都可以直接从它们的本地检查点恢复训练，如图6b所示。

硬件故障恢复：Case 1。当发生硬件故障时，训练系统需要替换故障的机器。Gemini中的根代理与云操作员（例如，AWS中的Auto Scaling Group平台）交互，以用健康的机器替换故障机器。从硬件故障中恢复训练时，有两种情况：1）在算法1分配的每个检查点放置组中仍然有健康的机器，2）至少有一个检查点放置组中所有机器同时发生故障。我们接下来将讨论这两种情况。在Case 1中，由于每个检查点放置组仍然有维护检查点副本的健康机器，Gemini可以从它们那里为新加入的机器获取检查点副本，然后恢复训练进度。图6c展示了一个有四台机器的示例，其中机器2和机器4刚刚同时发生故障。根代理用两台健康的机器替换了这两台故障机器。这两台新加入的机器替换了它们的位置，重用了它们的机器排名ID，并从存活的机器中检索它们的检查点。因为机器2的检查点副本存储在机器1中，所以机器2'（替换机器2的机器）从机器1中检索检查点以进行故障恢复。机器4'也从机器3中检索检查点。没有发生故障的机器可以直接从它们的本地检查点重新开始训练。

硬件故障恢复：Case 2。在这种情况下，机器必须从远程持久存储中检索检查点，以确保所有机器一致地恢复训练。尽管部分模型检查点在存活的GPU机器中仍然可以访问，但它们与远程持久存储中的检查点不一致，因为它们是从不同的迭代编号存储的。在实践中，大型模型训练期间的大多数故障是软件故障或单台机器被替换的硬件故障；同时发生两台或更多台机器故障的情况很少见【索引3，BLOOM Chronicles. 2022】【索引14，OPT-175B logbook. 2023】。即使同时发生多台机器故障，由于检查点放置策略，Gemini在大多数情况下仍然可以从CPU内存中恢复故障，我们将在7.2节中讨论。

备用机器。在硬件故障的情况下，期望云操作员立即提供健康的机器来替换故障机器。然而，这种替换操作在很大程度上取决于GPU云中健康机器的可用性，并且成功为当前训练工作负载预留新机器可能需要不确定的时间。为了最小化因机器替换导致的等待时间，训练集群可以预先分配几台备用机器。当一台机器遭受硬件故障时，一台备用机器可以立即变为活动状态以替换故障机器进行故障恢复。之后，根代理返回故障机器并请求另一台备用机器。Gemini允许用户根据他们的训练工作负载和GPU云中健康机器的可用性指定不同数量的备用机器。

故障检测。云操作员通常提供工具来检测训练故障并定位故障机器。例如，Amazon SageMaker【索引17，SageMaker. https://docs.aws.amazon.com/sagemaker/index.html, 2023】有用于故障类型检测和故障机器定位的工具。Gemini依赖这些工具来检测大型模型训练中的故障。此外，Gemini中的工作代理和根代理也定期向分布式键值存储发送心跳信号以进行故障检测。

A4 实验环境

• 数据集：使用 Wikipedia-en corpus【索引46，Stephen Merity, et al. Pointer sentinel mixture models. arXiv:1609.07843, 2016】进行训练。

• 模型架构：

  • 评估了包括GPT-2【索引61】，BERT【索引27】，和RoBERTa【索引43】在内的多种大型语言模型。
  • 通过调整层数、隐藏层大小和中间层大小来改变模型规模，具体参数如表2所示。例如，GPT-2 100B模型有96层，隐藏层大小为12288，注意力头数为96。
  • 所有模型使用512的序列长度和50265的词汇表大小，微批量大小设为8，并启用了混合精度训练和激活重计算【索引39，50】。优化器为Adam【索引38】。

  

  
  * 硬件配置：
  * 主要平台：16台Amazon EC2 p4d.24xlarge实例。
  * GPU: 每台实例配备8个NVIDIA A100 (40GB) GPU，通过NVSwitch互连。
  * CPU: 每台实例拥有1152GB CPU内存。
  * 网络: 实例间通过400Gbps的弹性光纤适配器（EFA）网络连接。
  * 次要平台：p3dn.24xlarge实例。
  * GPU: 每台实例配备8个NVIDIA V100 (32GB) GPU。
  * 网络: 实例间通过100Gbps的EFA网络连接。
  * 远程存储：使用AWS FSx【索引7】作为远程持久化存储，聚合带宽为20Gbps。
  * 软件配置：
  * 代码实现: Gemini在DeepSpeed【索引63】框架之上实现，并使用ZeRO-3【索引62】设置。
  * 依赖库: CUDA-11.6, DeepSpeed-v0.7.3, PyTorch-1.13, nccl-v2.14.3。
  * 协调服务: 使用etcd-v3.5【索引9】作为分布式键值存储实现。
  * 云管理: 依赖Amazon EC2 Auto Scaling Groups (ASG)【索引4】来管理GPU机器和故障替换。

A5 实验结果

7.2 训练效率

• 对训练吞吐量的影响：

  • 实验内容：在16台p4d.24xlarge实例上，对比了使用Gemini（每迭代一次检查点）和不使用检查点（vanilla DeepSpeed）时，训练GPT-2 100B、RoBERTa 100B和BERT 100B模型的迭代时间。
  • 实验结果：Gemini没有影响训练迭代时间（图7）。这是因为训练过程中的网络空闲时间足以容纳检查点流量，即使在插入检查点流量后仍有剩余空闲时间（图8）。
  • 结论：Gemini的流量交错算法能够成功地将检查点开销隐藏在计算过程中，实现每迭代检查点而无损训练吞吐量。
    

    

    
    

    

• 故障恢复中的浪费时间：

  • 实验内容：分析了Gemini在不同故障场景下（同时替换0、1、2、3台机器）从CPU内存恢复的概率，并计算了平均浪费时间。基线为Strawman（每3小时检查点）和HighFreq（尽可能高频地向远程存储检查点）。
  • 实验结果：
    • 恢复概率：使用2个副本时，即使在16台机器中有2台同时故障，从CPU内存恢复的概率也高达93.3%（图9）。Gemini的放置策略明显优于简单的环形策略。
    • 浪费时间：在可以从CPU内存恢复的情况下（如软件故障或单机硬件故障），Gemini将平均浪费时间减少了超过13倍（相比HighFreq）。在小概率无法从CPU内存恢复时（例如16台机器中2台故障且属于同一组，概率为6.7%），其性能降级为Strawman（图10）。
  • 结论：Gemini在绝大多数故障场景下能显著减少浪费时间。
    

    

    
    

    

• 检查点性能提升：

  • 实验内容：对比Gemini和基线方案在不同网络带宽和机器数量下的检查点时间。
  • 实验结果：
    • 检查点时间：Gemini的检查点时间随机器数量增加而减少，因为它利用了聚合网络带宽。在16台p4d.24xlarge实例（400Gbps网络）上，检查点时间缩短了超过250倍（图11）。
    • 检查点频率：Gemini实现了每迭代一次检查点，频率比HighFreq高8倍，比Strawman高170多倍（图12）。
  • 结论：Gemini通过利用CPU内存和集群内部网络，极大地提升了检查点性能。
    

    

    
    

    

• 通用性验证：

  • 实验内容：在p3dn.24xlarge实例（V100 GPU）上训练不同规模（10B、20B、40B）的GPT-2、RoBERTa和BERT模型。
  • 实验结果：Gemini同样没有对训练吞吐量产生影响，并且网络空闲时间足以容纳检查点流量（图13）。
  • 结论：Gemini的设计不限于特定硬件或模型，具有良好的通用性。
    

    

7.3 系统可扩展性

• 故障恢复的实际开销：

  • 实验内容：在GPT-2 100B训练中触发一次单实例硬件故障，并测量恢复过程各阶段的开销。
  • 实验结果：总开销包括故障检测（15秒）、检查点序列化（torch.save()，162秒）、实例替换（4-7分钟）和重启预热（4分钟以上）。软件故障总开销约7分钟，硬件故障（无备用机）约12分钟。相比之下，HighFreq方案每次检查点都需要约81秒的序列化开销，这会阻塞训练（图14）。
  • 结论：Gemini只在故障发生时产生一次性的序列化开销，而基于远程存储的高频方案则会在每次检查点时都产生阻塞性开销。
    

    

• 对高频故障和大规模集群的可扩展性（模拟）：

  • 实验内容：基于实测开销，模拟不同故障率和集群规模下的有效训练时间比例。
  • 实验结果：
    • 高频故障：即使每天发生8次故障，Gemini的有效训练时间比例仍接近无故障基线。而HighFreq因频繁的序列化开销，即使无故障其性能也损失了14.5%（图15a）。
    • 大规模集群：在1000台实例的规模下（假设每天1.5%的实例故障），Gemini的有效训练时间比例仍保持在91%左右，比HighFreq高54%（图15b）。
  • 结论：Gemini在高频故障场景和大规模集群下表现出优异的可扩展性。
    

    

7.4 流量交错算法的有效性

• 实验内容：在16台p3dn.24xlarge实例上训练GPT-2 40B，进行消融实验，对比不同检查点方案的迭代时间：
  1. Baseline：无检查点。
  2. Blocking：阻塞式检查点，在迭代开始时执行。
  3. Naïve interleave：简单的交错，但导致GPU内存溢出（OOM）。
  4. Interleave without pipeline：交错但不使用流水线，受GPU到CPU拷贝阻塞。
  5. Gemini：使用分区和流水线的完整流量交错算法。
• 实验结果：Blocking方案使迭代时间增加10.1%。Interleave without pipeline方案使迭代时间增加3.5%。而Gemini的迭代时间与Baseline几乎相同（图16）。
• 结论：Gemini的分区和流水线方法是消除检查点开销的关键，缺一不可。
  

  

A6 结论

本文提出了Gemini，一个专为大规模模型训练设计的、能够实现快速故障恢复的分布式训练系统。通过将检查点操作的目标存储从传统的远程持久化存储转移到集群内主机的CPU内存，Gemini成功实现了高频率的检查点（可达每个迭代一次），从而显著最小化了因故障造成的训练时间浪费。同时，Gemini通过创新的检查点放置策略和流量调度算法，解决了内存检查点带来的可用性保障和网络干扰两大挑战，实现了在不影响训练吞吐量的前提下进行高效的故障恢复。

实验结果表明，在GPU集群上的评估中，与现有解决方案相比，Gemini能够将故障恢复速度提高超过13倍，同时对训练吞吐量无任何损害。

未来工作：
尽管当前Gemini的实现是基于ZeRO-3并行策略，但其核心设计思想具有普适性。未来的工作计划将Gemini的设计推广应用到其他并行策略中，包括流水线并行、张量并行以及它们的混合模式。此外，团队还计划将Gemini应用于采用其他类型加速器（如AWS Trainium）的训练系统中。

A7 附录

A 定理1的证明

定理1。针对检查点放置问题1：
1. 当机器数$N$可被副本数$k$整除时，混合放置策略（等同于分组放置策略）是最优放置策略。
2. 当$N$不可被$k$整除时，混合放置策略最小化了检查点通信时间。其从CPU内存的故障恢复概率是近乎最优的，差距上限为$(2k - 3) / \binom{N}{k}$。

证明。我们首先引入两个关于检查点放置的观察结果。(1) 最优策略要求用$k$台不同的机器来存储每台机器的$k$个检查点副本，以最大化恢复概率。如果只用$k' < k$台机器来存储$k$个副本，其效果等同于只有$k'$个副本的策略。(2) 最优策略要求机器$i$存储一份自己的检查点副本，以最小化检查点时间。这样，每台机器只需发送$k-1$份副本；否则，需发送$k$份，导致更高的检查点时间。

通信时间最小化。无论$N$是否能被$k$整除，分组策略的检查点通信时间都是最小化的，因为每台机器发送和接收$k-1$个检查点副本。接下来我们分析从CPU内存恢复故障的概率。

恢复概率分析。假设有$f$台机器同时掉线。当$f < k$时，Gemini肯定可以从CPU内存恢复，因为在$k$个实例中总有可用的副本。我们主要讨论$f=k$的情况，因为$k+1$台机器同时掉线的故障率远低于$k$台机器同时掉线。

策略的形式化。对于机器$i$，我们用$C_i$表示存储其检查点的机器集合，共有$\binom{N}{k}$种可能的组合。一个策略可以表示为$S = \{C_1, C_2, ..., C_N\}$。由于可能存在$C_i = C_j$（当$i \neq j$时），我们定义$S' = \text{unique}(S)$，并令$u = |S'|$。$S'$中这$u$个集合的并集覆盖了所有$N$台机器，因为每台机器都存储一个本地检查点。

不可恢复的条件。我们用$F_d$表示$f$台掉线机器的集合。在我们的分析中，$f=k$。当$F_d$是$S'$中的一个元素时，Gemini无法从CPU内存恢复训练。因为这意味着某台机器的全部$k$个副本都丢失了，导致CPU内存中的模型检查点不完整且无效。$F_d$是$S'$中一个元素的概率是$u / \binom{N}{k}$，它与$u$线性相关。

概率上界。恢复失败概率的下界（即成功概率的上界）是$1 - \lceil N/k \rceil / \binom{N}{k}$，因为$u \ge N/k$。如果$u < N/k$，这$u$个集合的并集大小最多为$uk < N$，这与它们必须覆盖所有$N$台机器的要求相矛盾。

当N可被k整除时。分组放置策略可以达到这个上界。同一组中的机器拥有相同的检查点存储机器集合。因为有$N/k$个组，所以$S$中唯一集合的数量$u$就是$N/k$。因此，恢复失败的概率是$\lceil N/k \rceil / \binom{N}{k}$，这是概率的下界。因此，我们可以得出结论，当$N$可被$k$整除时，分组放置策略对于问题1是最优的。

当N不可被k整除时。对于前$\lfloor N/k \rfloor - 1$个组，同一组内的机器具有相同的检查点存储机器集合。对于最后一个组，每台机器都有一个不同的检查点存储机器集合，因此有$N - k(\lfloor N/k \rfloor - 1)$个唯一集合。因此，$S$中唯一集合的总数$u$为$N - (k-1)(\lfloor N/k \rfloor - 1)$。混合放置策略的概率与上界之间的差距上限为$(2k-3)/\binom{N}{k}$。由于$N \gg k$且$k$在实践中非常小，这个概率非常接近上界。□

B 推论1的证明

推论1。当$N$可被$k$整除且$f$台机器同时断开连接时，Gemini从CPU内存恢复故障的概率为：

证明。当$f < k$时，Gemini必然可以恢复故障，因为至少有一台机器上存有可用的检查点副本。我们接着考虑$k \le f \le N$的情况。

不可恢复的情况。根据算法1，在使用分组放置策略后，存在$N/k$个组。当$f$台机器同时发生故障时，如果存在$k$台故障机器恰好构成一个分组，这意味着CPU内存中存储的检查点变得不完整，训练必须从远程持久化存储恢复。

Case 1: $k \le f < 2k$。首先考虑这种情况。从$N$台机器中选择$f$台机器的总组合数为$\binom{N}{f}$。导致CPU内存中检查点不完整的组合数是：从$N/k$个组中选择1个组（$\binom{N/k}{1}$种方式），该组的$k$台机器全部故障，再从剩余的$N-k$台机器中选择$f-k$台故障机器（$\binom{N-k}{f-k}$种方式）。因此，导致不完整的组合数为$\binom{N/k}{1} \binom{N-k}{f-k}$。所以，Gemini能从CPU内存恢复故障的概率为：

Case 2: $f \ge 2k$。然后考虑这种情况。如果我们使用与$k \le f < 2k$相同的方法来计算组合数，某些组合会被重复计算（比如两个组同时完全故障），因此导致不完整的总组合数小于$\binom{N/k}{1} \binom{N-k}{f-k}$。所以，Gemini能从CPU内存恢复故障的概率为：

合并两种情况。将这两种情况合并，我们便得到了推论1。□

方法细节中的引用汇总

• [1]
  • 引用位置: 5.2 节，在讨论如何统一调度训练和检查点流量时。
  • 原文描述: "...通过利用现有的GPU间通信库（如NCCL【索引1】）以统一的方式编排这两种类型的流量。"
• [3] BLOOM Chronicles. 2022
  • 引用位置: 2.1 节，说明大规模训练中故障的普遍性；2.2 节，举例说明现有方案的低检查点频率；6.2 节，说明多机同时故障的罕见性。
  • 原文描述: "在训练BLOOM模型期间也报告了类似情况【3】"；"...例如在BLOOM训练中每三小时一次【3】"；"...同时发生两台或更多台机器故障的情况很少见【3, 14】"。
• [9] etcd. 2023
  • 引用位置: 3.2 节，作为分布式键值存储的实现例子。
  • 原文描述: "工作代理监控自己机器的健康状态，并在分布式键值存储【9, 29, 30】中更新它。"
• [14] OPT-175B logbook. 2023
  • 引用位置: 2.1 节，作为大规模训练频繁故障的例子；6.2 节，说明多机同时故障的罕见性。
  • 原文描述: "例如，训练OPT-175B模型...遇到了大约110次故障【14】"；"...同时发生两台或更多台机器故障的情况很少见【3, 14】"。
• [16] P4d.24xlarge in AWS. 2023
  • 引用位置: 2.3.1 节，说明用于训练的内部网络带宽远高于远程存储。
  • 原文描述: "...其带宽远高于远程持久存储的带宽【16】。"
• [17] SageMaker. 2023
  • 引用位置: 6.2 节，作为云厂商提供的故障检测工具的例子。
  • 原文描述: "例如，Amazon SageMaker【17】有用于故障类型检测和故障机器定位的工具。"
• [21] Awan et al. 2018
  • 引用位置: 5.3 节，在定义检查点分区传输时间的公式时引用。
  • 原文描述: "...时间长度为$f(s) = \alpha + s/\beta$，其中$\alpha$是传输的启动时间，$\beta$是网络带宽【21, 72, 87】。"
• [23] Chen et al. 2020
  • 引用位置: 2.3.1 节，说明检查点的其他用途，如模型调试。
  • 原文描述: "...如迁移学习【56】和模型调试【23, 28】）的检查点历史记录。"
• [28] Eisenman et al. NSDI 22
  • 引用位置: 2.2 节，说明检查点频率受限于远程存储带宽；2.3.1 节，说明检查点的其他用途；3.1 节，作为用户管理的检查点用途的例子；6.2 节，作为现有检查点解决方案的例子。
  • 原文描述: "...因为检查点频率受限于远程持久存储的带宽【28】"；"...和模型调试【23, 28】"；"...如迁移学习【56】和模型调试【28】，则存储在远程持久存储中并由用户管理"；"现有的检查点解决方案【28, 65, 85】不区分软件故障和硬件故障。"
• [29] Escriva et al. 2012 & [30] Geambasu et al. 2010
  • 引用位置: 3.2 节，作为分布式键值存储的例子。
  • 原文描述: "工作代理监控自己机器的健康状态，并在分布式键值存储【9, 29, 30】中更新它。"
• [31] Gill et al. 2011 & [36] Jeon et al. 2019 & [55] Ostrouchov et al. 2020 & [70] Taherin et al. 2021 & [71] Tan et al. 2019 & [74] Tiwari et al. 2015 & [75] Tiwari et al. 2015
  • 引用位置: 6.1 节，用于支持对故障类型的分类和定义。
  • 原文描述: "在大型模型训练期间可能发生各种故障【36, 55, 70, 75】"；"我们从恢复的角度将这些故障分为两类...遵循文献【31, 36, 55, 70, 74, 75】的做法"；"由辐射引起的位损坏可能导致双比特错误，从而导致数据损坏【36, 75】"；"网络链路和交换机可能会失败【31, 71】"。
• [40] Lamport. 2001 & [52] Ongaro and Ousterhout. 2014
  • 引用位置: 3.2 节，说明根机器选举所依赖的方法。
  • 原文描述: "Gemini依赖于分布式键值存储中的领导者选举方法【40, 52】来进行根机器的选择。"
• [41] Li et al. 2019 & [64] Rossetti and Team. 2015
  • 引用位置: 5.2 节，说明训练流量也使用直接GPU-to-GPU通信。
  • 原文描述: "...后者也使用机器间的直接GPU-to-GPU通信【41, 64】。"
• [44] Maeng et al. 2021
  • 引用位置: 2.2 节，说明故障导致训练时间显著减慢。
  • 原文描述: "...训练时间 slowdown 可达43%【44】。"
• [48] Mohan et al. 2021 & [65] Scao et al. 2022
  • 引用位置: 2.2 节，作为现有检查点解决方案的例子。
  • 原文描述: "他们 checkpoint 模型状态...并持久化在远程持久存储系统【48, 65】。"
• [56] Pan and Yang. 2010
  • 引用位置: 2.3.1 节和 3.1 节，说明检查点的其他用途，如迁移学习。
  • 原文描述: "...如迁移学习【56】和模型调试..."
• [62] Rajbhandari et al. 2020
  • 引用位置: 5.1 节，以ZeRO为例说明分布式训练中的通信操作。
  • 原文描述: "例如，在ZeRO【62】中，每个GPU...都需要从其他GPU获取每一层的参数。"
• [68] Smith et al. 2022
  • 引用位置: 2.2 节，作为大型模型检查点耗时的例子。
  • 原文描述: "...将MT-NLG【68】的模型状态检查点到远程持久存储需要42分钟。"
• [72] Thakur et al. 2005 & [87] Zhang et al. 2022
  • 引用位置: 5.3 节，在定义检查点分区传输时间的公式时引用。
  • 原文描述: "...时间长度为$f(s) = \alpha + s/\beta$，其中$\alpha$是传输的启动时间，$\beta$是网络带宽【21, 72, 87】。"
• [77] Wang et al. 2023 & [79] Wang et al. 2022 & [86] Zhang et al. 2020
  • 引用位置: 5.4 节，用于支持“训练期间网络空闲时间线基本稳定”的观察。
  • 原文描述: "...我们观察到，分析出的时间线在各个迭代中几乎保持不变，这与之前的研究一致【77, 79, 86】。"
• [85] Zhang et al. 2022
  • 引用位置: 6.2 节，作为现有检查点解决方案的例子。
  • 原文描述: "现有的检查点解决方案【28, 65, 85】不区分软件故障和硬件故障。"