【论文】略读笔记85-前沿-GPU碎片调度
📖《Beware of Fragmentation: Scheduling GPU-Sharing Workloads with Fragmentation Gradient Descent》
2023 年 香港科技大学、阿里巴巴团队 发表于 CCF-A 类会议 ATC。
🎯需求
大型科技公司正在其服务器机群中堆积大量 GPU，以运行各种机器学习 (ML) 工作负载。然而，这些昂贵的设备往往利用率严重不足。
- 图形处理器（GPU）被广泛部署在生产集群中，用于加速大量人工智能应用中的机器学习（ML）任务。与 CPU 和其他资源相比，GPU 的成本要高得多，但在生产集群中往往利用率不足，据报道，利用率仅在从 25% 到 50% 以下不等。
- GPU 利用率低的主要原因是，大量 ML 任务（主要是推理）无法充分利用现代 GPU 的能力，而近年来 GPU 的性能已呈指数级增长。预计在可预见的未来，这一趋势还将继续。
🚧现状
历史解决方案1：GPU共享
为了解决这个问题，人们开发了 GPU 共享技术，以便在单个 GPU 上运行多个 ML 任务。
- 通过虚拟化或英伟达公司 Ampere 架构支持的多实例 GPU（MIG）功能，使多个 ML 任务能够在单个 GPU 上安全运行，并保证隔离。
然而，我们对阿里巴巴生产跟踪的分析表明，在大型集群中，分配部分 GPU 可能会导致严重的 GPU 碎片化，导致数百个 GPU 无法分配。
- 仅仅启用GPU共享并不一定能够提高利用率。在许多情况下，分配部分GPU会导致碎片化，从而阻止剩余的GPU资源被分配。
- 图 1 在玩具示例（Toy Example）中说明了这个问题。
- 考虑一个由两个节点A和B组成的集群，节点A具有⟨9个CPU，1个GPU⟩，节点B具有⟨6个CPU，1个GPU⟩。
- 有两个任务A和B分别在两个节点上运行，每个任务分别需要⟨6个CPU，0.75个GPU⟩和⟨2个CPU，0.25个GPU⟩。
- 情况1：如果不启用GPU共享，即使这些任务无法充分利用整个GPU，它们也会被分配一个完整的GPU（图1，左）。
- 情况2：通过使用GPU共享技术分配部分GPU可以解决这个问题（图1，中）。现在假设又有一个任务A的实例到达，尽管集群有足够的总GPU资源（0.25 + 0.75 = 1个GPU），但它仍然无法在任何一个节点上运行。
- 我们在支持 GPU 共享的生产集群中广泛观察到了 GPU 碎片现象。
- 图 2 显示了从一个 1280 GPU 集群收集到的 7 天跟踪。
- 平均而言，GPU allocations 分配总量占总容量的 77.6%（橙色虚线）。
- 这些 allocations 分配（很多是部分 GPU）分布在几乎所有 GPU 设备上（蓝色实线），
- 导致 21-42% 的 unallocated 未分配 GPU 资源成为当前工作负载无法利用的碎片（红色虚线）。
- 一般来说，更高的 allocations 分配会导致更严重的碎片化。
- 根据我们的运行经验，尽管集群仍有足够的闲置 GPU，但有关调度失败的投诉通常会在高峰时段激增，这表明碎片化现象非常严重。
- 图 2 显示了从一个 1280 GPU 集群收集到的 7 天跟踪。
历史解决方案2：打包 packing
解决碎片问题的有效方法是进行打包。
- 回到前面的例子，调度器可以将两个原始任务打包到节点 A，从而将整个节点 B 留给任务 A 的新实例（图 1，右）。
- 大量工作将工作负载调度表述为多维装箱问题（multi-dimensional bin packing problem），其中任务和节点分别被建模为球和箱，球和箱的大小取决于多个资源维度，目标是将球打包到最少的箱中。
- 人们提出了许多启发式方法来调度集群工作负载，如最佳拟合、向量排列评分和 “GPU打包”。
但现有的资源打包算法无法解决这一问题，因此 GPU 共享要求在经典的 bin packing 之外采用新的调度方案。
- 然而，我们的实验表明，这些启发式方法都不能很好地调度 GPU 共享工作负载（第 6 节）。
- 我们认为，根本原因在于，当一个节点拥有多个 GPU 时，该问题与经典的 bin packing 本质上是不同的。
- 考虑两种自然的 bin packing 方案。
- （1）第一种是将服务器的多个 GPU 建模为一个具有总容量的大型设备。这种方案将所有未分配的 GPU 集中在一起，单个 GPU 上的碎片变得无关紧要，而现实情况并非如此（笔者理解：GPU虚拟化还不够成熟，不像CPU虚拟化可以忽略单节点多个CPU间区别）。
- （2）另外一种，我们也可以将服务器上的多个 GPU 视为不同的 “资源维度”。然而，与 CPU 和内存等其他资源不同的是，这些 GPU 并不是独立的，而是可以互换的，任务可以在任何一个 GPU 上运行，这就要求在经典的 bin packing 之外采用新的表述方式。
🛩创新
在本文中，我们为 GPU 共享工作负载开发了一种新颖的碎片感知调度方法。我们首先提出了一种新的碎片化测量方法，以统计量化不同来源造成的 GPU 碎片化程度。在这一指标的基础上，我们建议将 GPU 共享工作负载调度为碎片最陡峭的下降方向，我们称这种方法为碎片梯度下降（FGD）。直观地说，FGD 对任务进行打包，以尽量减少 GPU 碎片的增长，从而实现最大的 GPU 分配率。
- （1）我们的方法的核心是一个新的分析框架，它可以统计地量化集群中的 GPU 碎片化程度。
- 给定一个任务，我们识别出每个节点上不能用于运行该任务的 GPU（例如，缺乏足够的 GPU 或其他资源）。从该任务的角度来看，这些 GPU 都是碎片化的，因为它们的剩余资源都无法利用。
- 现在，我们来考虑目标工作负载，它由一组我们感兴趣的任务（如 ML 推理和训练）组成。我们将 GPU 碎片化程度量化为无法分配给从目标工作负载中随机抽取的任务的 GPU 的预期数量。直观地说，它衡量的是目标工作负载无法利用的 GPU 资源的预期数量。
- 我们可以将碎片分析进一步细分为不同的原因，如节点的 GPU 不足或搁浅，或工作负载与节点规格不匹配等。这种分析为操作员推理集群状态提供了更多见解（第 3 节）。
- （2）基于GPU碎片化分析，我们提出了一种简单而有效的启发式方法，将工作负载调度到碎片化最陡下降的方向，我们称之为碎片化梯度下降或FGD。
- 对于提交的每个GPU任务，FGD会选择一个节点及其可用的GPU来运行该任务，以使由于这一决定导致的GPU碎片化增长最小化（§4）。
- 通过这样做，FGD可以最小化GPU碎片化，从而节省大量昂贵的资源用于更多的工作负载。
📊效果
我们在 Kubernetes 中实施了 FGD 作为一种新的调度程序，并在由 6200 多个 GPU 组成的模拟集群上使用生产跟踪评估了其性能。与现有的基于打包的调度程序相比，FGD 最多减少了 49% 的未分配 GPU，从而提高了 290 个 GPU 的利用率。
- 我们在 Kubernetes 第5节）中实现了一种新的调度器FGD，并在包含超过1200个节点和6200个GPU的模拟集群上使用生产工作负载和合成工作负载跟踪对其性能进行了评估（第6节）。
- FGD在各种设置中始终优于现有的基于打包的调度算法：它最多可减少49%未分配的GPU，使290个GPU能够在大型生产集群中得到利用。
- 我们的实现包括调度器和模拟器，以及用于评估的跟踪数据，均已开源软件形式提供。
⛳️讨论与未来机会
（1）调度无关的碎片化度量。
- 我们提出的碎片化度量量化了当前集群的碎片化程度，仅考虑即将到来的任务。这种狭窄的焦点确保了调度器独立性。
- 具体来说，如果我们考虑两个或多个即将到来的任务，每个节点在评估由第二个任务测量的碎片化时，需要确定第一个任务是否已经消耗了其资源。这一确定过程会涉及调度策略。
- 相比之下，我们的一步碎片化度量仅基于节点剩余资源是否能完全被下一个任务利用来确定节点是否碎片化，不依赖于调度器或其他节点。
（2）与其他启发式方法相结合。
- 在集群资源丰富且几乎没有碎片化观察到的早期阶段，调度器可能会由于受到单步碎片化度量的指导而表现不佳。然而，可以通过将碎片化指导的调度启发式方法与其他启发式方法结合使用来应对这一初始阶段。例如，如果未检测到碎片化的增加，调度器可以退回到最佳适应的方法。
🧠疑问
- 在大规模场景下，传统装箱方法是否能够有足够高的效率应付任务？本论文方法似乎效率能够达标、但是碎片能优化到什么程度，如果多调度器并行可能还会有更进一步的问题？需要实验进一步验证。
- 任务持续时间有多长？本文只关注当下的“碎片率最优方向”，长期看是否会因为任务在不同时间结束，导致碎片问题和预期不一致？
- 希望这篇博客对你有帮助！如果你有任何问题或需要进一步的帮助，请随时提问。
- 如果你喜欢这篇文章，欢迎动动小手给我一个follow或star。
🗺参考文献
- 标题: 【论文】略读笔记85-前沿-GPU碎片调度
- 作者: Fre5h1nd
- 创建于 : 2025-06-10 15:13:13
- 更新于 : 2025-06-11 16:47:08
- 链接: https://freshwlnd.github.io/2025/06/10/literature/literatureNotes85/
- 版权声明: 本文章采用 CC BY-NC-SA 4.0 进行许可。
评论