AI HPC 场景下的 Slurm 和 K8S

Slurm 和 Kubernetes 的作用

Slurm 和 Kubernetes 解决类似问题并提供类似服务，两者都可以用于模型训练或其他高性能计算任务。仅关注其功能的关键方面，它们都可以被称为”工作负载管理器”。

在 AI HPC 场景中，他们被期望承担以下角色：

1. 作为用户访问其计算能力的入口点。
2. ”持有“并管理硬件资源。
3. 实施用于分配资源和执行用户工作负载的调度算法。

工作负载管理器在训练中的作用

模型训练是一项极其复杂的任务。这不仅在智力上具有挑战性，而且还需要对大量硬件和软件进行精心管理。幸运的是，您可以将这种复杂性的一部分委托给工作负载管理器。

对于严格的训练，可能会需要大量的服务器、机架、高性能 GPU、GPU 交换、高吞吐量和低延迟网络、各种存储技术等。工作负载其可以帮助高效利用这些资源，并在员工或部门之间公平分配它们。

What is Slurm

Slurm 是一个强大的工作负载管理器，在 HPC 领域非常流行。全球 500 强超级计算机中有一半以上都使用它。

虽然 Slurm 最初并不是为模型训练而设计的，但它已经很好地适应了当前的需求（例如，通过支持 GPU 计算）。其最初的设计也比 Kubernetes 更接近当前的 ML 需求。

用户通过连接到集群中的节点之一并执行命令行实用程序来与 Slurm 进行交互。该体系结构的一个重要特征是用户无法从本地计算机运行客户端实用程序。相反，他们建立到集群的 SSH 会话并在那里工作：将作业定义为 bash 脚本、执行它们、管理集群并从文件中读取作业输出。用户体验非常老式且“Linux 风格”。

What is Kubernetes

Kubernetes 或 K8s，是容器化应用程序的通用编排平台。这是一个拥有众多贡献者的开源项目，最初由 Google 于 2014 年开发，专门用于管理云中的容器。

虽然每个后端开发人员可能都听说过 Kubernetes，但它在 HPC 领域的声誉并不那么普遍。然而，大多数机器学习工程师可能都在某种程度上熟悉它。

值得注意的是，Kubernetes 最初并不是为模型训练而设计的。然而，其通用性和可扩展性使其能够适应其目的。有些人更喜欢使用扩展（称为 Kubernetes Operator）如 KubeRay 用于机器学习任务。普通设置和一些自行编写的自定义解决方案也被广泛使用。

Slurm 和 Kubernetes 的区别

TL;DR:

• Kubernetes 的优势在于其通用性和强大的容器编排能力。
• Slurm 的优势在于其针对 HPC 场景的资源管理和调度能力。

关注点和目标

Slurm

• 假设系统大小是固定的
  • 并且工作负载是无限的
  • 队列优先级至关重要
• Slurm 管理 HPC 任务
  • 作业排队和优先级
  • 作业统计
  • 控制用户计算资源访问（cgroups、pam_slurm_adopt）
  • 大规模并发作业支持（MPI、PMIx、nss_slurm、sbcast）
• 作业通常是临时脚本，通过命令行提交
  • RESTful API 未广泛使用

Kubernetes

• Kubernetes 旨在管理长时间运行的进程
  • 设计于编排多个微服务
• 云原生假设系统有无限可用资源
  • 并且工作负载有限
• 不关注优先级，默认所有工作负载同时运行
• 调度颗粒度固定在节点级别
  • 通过插件管理 GPU
  • 没有 CPU 亲和模型
• 服务默认容器化
• 系统通常可编程

优势和劣势

Slurm 的优势

使用 Slurm 进行模型训练的人可以使用专门针对 HPC 的所有复杂功能。

它的调度器既聪明又高效，超越了竞争对手。它是为超级计算机设计的，可以处理大规模（数万个节点，每秒数百个作业）。

Slurm实现了对硬件资源的深度控制。例如，它区分CPU插槽、CPU核心和超线程。您甚至可以选择物理上更接近 PCI 总线的 CPU。它还支持GPU分片和网络拓扑（您可以分配这样一组节点，以便它们之间的数据传输经过最少数量的交换机）。

此外，Slurm 具有高度可扩展性，可使用各种插件，这些插件可以成为运行 ML 工作负载的重要资产。例如，您可能想使用容器化插件 Pyxis ，NVIDIA 的开源产品。您甚至可以编写插件，而且并不太复杂。

Slurm 的劣势

Slurm 的缺点也源于其对 HPC 的强烈关注。虽然它提供了许多功能，但缺乏通用性。 Slurm 仅非常适合大小有限的集群上的时间有限的工作负载。这是机器学习的一个相关问题，因为进行训练的人通常也想进行推理。推理在 Slurm 上效果不佳，因此他们必须维护一个单独的系统，这也需要昂贵的硬件资源。

Slurm 对自动缩放的支持不是很好——它主要是为固定缩放而设计的。尽管它提供了一些更轻松地扩展集群的技术，但它不是本地设置的选项。尽管如此，大多数云解决方案都有它。

虽然 Slurm 集群的初始引导非常简单，但随着时间的推移，我不能说同样的维护它。 Slurm 有一个非常烦人的要求：所有节点必须相同（Linux 用户和组 ID、软件版本等）。这个负担往往落在用户的肩上。 Slurm 管理员的日子也并不轻松：不同云平台上有很多针对 Kubernetes 的“托管”解决方案，但 Slurm 却没有真正的“托管”解决方案，因此管理员必须各司其职，不能退休。

用户体验既可以被视为优点，也可以被视为缺点。如果您在大学时了解过 Slurm，那么这种 bash 脚本可能会很方便。但如果没有，您将找不到用户友好的用户界面。此外，没有最新的 Python 框架，因此 ML 工程师有时必须从 IDE 切换。

另一个考虑因素是，许多大公司默认使用 Kubernetes作为其基础设施，而 Slurm 并不能很好地配合它。有些人不得不使用 Kubernetes，尽管他们更喜欢 Slurm。

Kubernetes 的优势

Kubernetes 的主要好处是它的通用性。人们仅使用它就可以解决所有任务，包括计算密集型任务（例如训练）和一些生产服务（例如推理）。他们甚至可以在同一系统中托管他们的公司网站。它已成为事实上的标准，并且通常被视为底层基础设施的一部分。

市场上有许多托管解决方案可以让您的生活变得更加轻松。即使在本地安装，机器学习工程师也很少需要自己解决 Kubernetes 的问题，因为有专门的专家来解决这个问题。这与 Slurm 不同，在 Slurm 中，维护节点处于相同状态是共同的责任。

自动缩放是 Kubernetes 的一个关键功能。 K8s 主要针对公共云环境而设计，在该环境中始终可以获得额外的计算能力。如果您想要启动超出集群当前容量的工作负载，集群会自动扩展以满足新的需求。缩小集群规模对机器学习领域也有利，因为需求会随着时间的推移而变化，并且在特定时刻购买不需要的硬件太不经济。

Kubernetes 提供了一些开箱即用的高可用性。您可以将工作负载配置为在出现问题时自动重新启动（即使在不同的硬件上），几乎不费吹灰之力。

借助 KubeRay 等许多第三方解决方案，Kubernetes 培训可以为您提供用户友好的 ML 方法，包括图形用户界面和 Python 框架。 Slurm 也可以提供一些东西，但它的局限性要大得多。

Kubernetes 的劣势

Kubernetes 非常强大和简洁，在 ML 之外的某个地方，甚至可能没有选择是否使用它。然而，当某样东西在所有方面都擅长时，它通常并不是在任何方面都是最好的。这就是 Kubernetes 的主要问题的根源。虽然它适用，但它并不针对模型训练，因此缺乏 Slurm 的许多与 HPC 相关的高级功能。 Kubernetes 甚至不是为运行时间有限的工作负载而设计的——它最初是为运行条件无限的微服务应用程序而创建的。

特别是，Kubernetes缺乏先进的调度。普通版本甚至无法提供在多个节点上运行单个作业的方法。流行的扩展也不以高效调度而闻名（无论是在作业中的主机数量还是每秒作业数量方面，尽管后者很少与训练相关）。保留节点的详细语法也与您可能习惯的 Slurm 相去甚远。

Kubernetes 也无法像 Slurm 那样提供如此精细的硬件管理。虽然理论上可以使用设备插件等实现相同的功能，但 Slurm 目前在该领域提供了更多功能。

Kubernetes 的许多缺点可以通过第三方扩展来缓解。在实践中，公司需要在其集群中安装额外的 Kubernetes Operator 。该列表通常很长：NVIDIA GPU Operator、NVIDIA Network Operator、MPI Operator、Training Operator，一些共享文件系统和数据库的解决方案等。这使系统的引导变得非常复杂。然而，一旦安装完毕，如果您不进行修改，一切都会或多或少地顺利进行。

工作负载必须容器化并遵循云原生方法。并非每个分布式应用程序都可以在 K8s 中运行，尽管几乎所有分布式应用程序都可以以某种方式进行调整。

图表对比

特性	Kubernetes	Slurm
主要目标用户	条件性无限进程 (例如：微服务)	有限的 HPC 批处理作业
分布式作业支持	基础版 Kubernetes 中没有；自定义解决方案限制了最大节点数	开箱即用的良好支持
调度功能	当使用自定义调度解决方案时足够	高级
硬件管理的粒度	与硬件连接较弱，即使使用自定义解决方案也是如此	以最小的努力支持 CPU 核心亲和性、GPU 切分和网络拓扑
容器化	作业需要容器化	作业可以选择容器化或不容器化
引导启动的简易程度	中等 (需要安装许多需要协同工作的独立 Operator)	简单 (只需一个 Slurm 即可开始工作)
HPC 相关设施的实现	存在自定义解决方案，但不是很先进	综合功能：访问控制、优先级、QoS、计费、统计等
用户体验和入门门槛	适合具有大型科技公司经验的工程师；存在 Python 框架和 GUI 解决方案；云原生理念与其他系统并不接近	适合来自学术领域的人员；老式的 Bash 脚本和 Linux 管理对于其他人来说可能具有挑战性
集群扩展	简单 (尤其是在云端)	中等 (可以实现，但不是那么简单)
功能实现的速度	进展非常迅速	正在改进，但速度较慢
维护的简易程度	简单 (一切或多或少都能工作，只要你不去碰它)	困难 (保持节点状态一致很困难)
使用相同的资源进行训练和推理	允许使用相同的硬件进行训练和推理 (以及许多其他任务)	仅适用于训练，不适用于推理 (或任何其他无限期工作负载)

引用链接：NEBIUS

Slurm 和 Kubernetes 的集成方案

以下是 Slurm CTO Tim Wickberg 在 SC23 上提出的四个方案：

Slurm 调度 Kubernetes

• Slurm 管理所有集群资源
• Kubernetes 集群在 Slurm 批处理作业中临时创建
• 不是特别有用。。。

Kubernetes 和 Slurm 并行

• 在集群环境中同时运行 Slurm 和 Kubernetes
• 可能需要额外管理工具在两侧迁移节点
• Slurm 和 Kubernetes 缺乏统一管理/通信交互
• DELL 的 Omnia 目前采用此方案

Kubernetes 和 Slurm 交互

• 重叠两个控制层
• 安装 Slurm Kubernetes 调度插件
  • 让 Slurm 优先调度 Slurm 和 Kubernetes 的工作负载
• 由 kubelet 管理 Kubernetes 作业
• Slurm 作业同通过 Slurm 运行
  • 管理高吞吐量和大规模 MPI 工作负载
  • 提供传统 CLI 交互
• 已知限制：
  • Kubernetes 调度仍处于节点级粒度
  • Slurm 通常在作业开始前就预留了所需的资源，Kubernetes 的亲和性和反亲和性更多的是一种在调度时的偏好或约束

Kubernetes 编排 Slurm

• 在 Kubernetes 环境中运行 Slurm 集群
• 通过 Kubernetes Operator 实现资源自动缩放
  • Slurm 22.05+ 的动态节点支持
• 缺点
  • Kubernetes 工作负载在 Slurm 调度之外
  • Slurm 和 Kubernetes 工作负载之间的优先级难以确定

SUNK

• ScheMD 和 CoreWeave 合作开发
• Kubernetes 用于在裸机上管理和部署 Slurm 集群
• 部署 Kubenetes Operator，通过 REST API 监控 Slurm 集群状态
  • 通过添加/删除 pod 来动态伸缩节点
• 在 k8s 和 Slurm 之间具有双向状态同步的动态节点
• 支持 Pyxis 容器执行
• 缺点：
  • （尚未）开源，目前需要登记注册使用
  • 可预见的复杂性
• 参考官方介绍
• 架构图：
  

一些讨论链接

• 有什么方便的实验室共享 GPU 方案？
• 深度学习训练如何防止被炸显存
• 算法工程师的开发环境都是什么样的？
• Slurm and K8s collocation design
• Yet another question on Kubernetes cluster vs HPC cluster (Slurm)
• Scaling Kubernetes to 7,500 Nodes

参考资料

• https://nebius.com/blog/posts/model-pre-training/slurm-vs-k8s
• https://slurm.schedmd.com/SC23/Slurm-and-or-vs-Kubernetes.pdf