Crux:GPU-Efficient Communication Scheduling for Deep Learning Training

研究背景

深度学习训练任务计算资源需求高，通常在由云服务商提供的大规模集群上运行，集群中可能有成千上万的 GPU。通常，大量任务在集群中同时执行并共享 GPU 资源，GPU 调度器则负责为这些任务分配 GPU。

然而，多个深度学习任务在同一 GPU 集群上共同执行时，会导致个别任务的训练时间增加和 GPU 利用率下降。由于 GPU 集群的利用率直接影响训练吞吐量和云服务提供商的利润，为了提高利润，需要最大化 GPU 集群的利用率。

研究内容

对深度学习训练（DLT）全生命周期进行分析，发现多个 DLT 任务之间的性能干扰主要源于通信争用。通信包括在同一主机或不同主机上的 GPU 之间同步模型参数、梯度和优化器。当多个 DLT 任务同时执行时，通信争用导致迭代时间显著增加。因此，解决通信争用问题对于提升 GPU 利用率至关重要。

研究亮点

仅进行作业调度只能减轻通信争用的严重程度，但不能消除这一现象。而现有的通信调度策略要么只解决了单一作业场景下的通信争用问题，要么没有考虑到深度学习训练任务本身的特性。本文提出的Crux则从GPU intensity这一概念着手解决作业间的通信争用问题，设计了一个兼具三方面功能的方案：（1）通信路径选择；（2）作业优先级赋值；（3）优先级压缩。

实验设计

实验方案包括两个部分：实际测试平台和模拟 GPU 集群。

  1. 实际测试平台：每个主机配备 8 个 GPU，通过 4 条链路连接到一个 ToR 交换机，每两个 GPU 通过共享链路连接到一个交换机。如果不同主机上的 GPU 需要通信，且不在同一个 ToR 交换机下，则需通过汇聚交换机进行通信。

  2. 模拟 GPU 集群：为了模拟多个任务的计算和通信过程，使用了真实 GPU 运行模型获取每次迭代的计算时间，并采用 alpha-beta 模型模拟通信。该模拟器假设有 8 个优先级，并基于从 2,000 多个 GPU 的生产追踪数据进行大规模模拟。使用了两种网络拓扑：

    • **Doublesided **：包括 6 个 ToR 交换机、12 个汇聚交换机和 32 个核心交换机，每个主机通过 8 条链路连接到两个 ToR 交换机。
    • **Two-layer Clos **：由 173 个 ToR 交换机和 16 个汇聚交换机构成，每个主机连接到一个 ToR。

  3. 性能指标：主要评估 GPU 集群的整体 GPU 利用率，以及各任务的端到端训练性能（即作业完成时间，JCT）。

  4. 实际测试平台中的实验：在测试平台中，将多个深度学习训练任务在有/无 Crux 的情况下同时运行。每个任务运行 ResNet、BERT 或 GPT 模型，分别代表小型、中型和大型任务。为了更直观地展示 Crux 的改进，还评估了每个任务单独运行时的训练性能，作为理想的训练表现基准。

  5. 消融实验：评估某个系统中不同模块或机制对整体性能的贡献。在这种实验中，研究者通常会移除或替换系统中的某个模块，并观察系统性能的变化，从而评估该模块的重要性。在你提供的例子中，意思是当评估某个机制（例如“优先级压缩”）的影响时，其他两个调度机制（如“路径选择”和“优先级分配”）都会采用它们的最优方案。这么做的目的是为了确保只测量被研究的机制对整体系统的影响，而不受到其他机制的干扰或次优方案的影响。简而言之，就是固定其他因素的最优状态，只对一个机制进行变动或调整，来观察该机制对整体效果的影响。

研究结论

Crux 引入了 GPU 强度的概念，将 GPU 利用率问题转化为流量优化问题。为了在实际多租户 GPU 集群中接近最优的流量调度，Crux 提出了基于 GPU 强度的路径选择、优先级分配和优先级压缩方法。评估结果表明，与最先进的方案相比，Crux 将集群 GPU 利用率提升了最多 23%。

研究展望

  1. 可以与其他调度机制结合（如作业调度，因为通信调度与作业调度互相不冲突），获得更高的GPU利用率。
  2. Crux可以调整以适应其他种类的网络拓扑结构（如Torus等），因为Crux基于GPU intensity，这是每个作业本身隐含的属性，独立于网络拓扑结构。

文章启示

  1. 有效的调度策略不仅要优化计算资源的利用，还需考虑通信资源的调度和管理。
  2. 理论模型和实际应用之间可能存在差距，需要考虑如何在保持算法可行性的同时，尽可能地接近实际情况。

局限性

  1. 计算与通信模式的简化：Crux 假设在一次迭代中，计算和通信是连续且简单重叠的模式，然而在实际深度学习训练任务中，计算和通信可能交替发生，且有复杂的重叠模式。

  2. 简化的修正因子计算：Crux 仅选择网络流量最大的任务作为参考任务，计算修正因子。然而，最优情况应考虑所有与当前任务存在通信争用的任务组合，这需要指数级的计算复杂度和细粒度的网络监控。

  3. 其他因素的忽略：通信性能还受到存储流量、任务通信时序以及特定集体通信算法的影响，例如存储相关的流量可能与通信流量混合。