Slurm 集群中 GPU 调度、编排与执行各层职责解析

六块 GPU 空闲，一个只要四块 GPU 的任务却仍在等待。在考虑再增加一个平台之前，我们需要弄清楚：这些空闲设备究竟不满足哪一项约束。

调度决定工作负载在何时、何处获得资源。编排协调其环境与生命周期。执行则是应用在分配到的资源上进行计算的方式。在真实系统中，这些职责相互重叠，但把它们区分开来，有助于解释为什么一个任务即使拿到了 GPU，仍然难以产出有用的结果。

对于运行 Slurm HPC 集群或企业 AI 平台的团队来说，在决定改进什么时，这一区分很重要。任务在等待，是因为调度策略？是因为它的环境难以复现？还是因为它的执行策略需要一种现有集群无法提供的 GPU 组合？

每个问题都需要不同的干预手段。

这个任务何时、何地能获得资源？ 资源请求、队列优先级、可用性与策略

工作负载如何部署和管理？ 环境、依赖、生命周期与恢复

应用如何在分配到的资源上进行计算？ 软件兼容性、内存、工作分配与通信

这是一种对职责进行分类的方式，而不是把产品划入互斥的类别。Slurm 管理资源分配、启动并监控作业，并处理待处理任务。Kubernetes 管理容器化工作负载，并自带调度器。[1][4][5]

真正有用的问题是：在你的环境中，是哪一项职责在限制工作负载。

在 Slurm 中，GPU 可以配置为通用资源，即 GRES。作业请求资源，Slurm 根据请求和集群配置进行分配。请求可以指定 GPU 类型和数量；可用的选项还取决于 Slurm 的配置方式。[2]

GPU 请求与作业的其他需求并列。CPU 资源、主机内存、分区访问权限和调度策略同样影响作业能否获得分配。

分配让作业获得一组已定义的资源。Slurm 还提供了启动和监控其进程的框架。但这并不意味着每一块可用的 GPU 都能替代所请求的那一块。

设想一个用于说明的集群，共有八块 GPU： 四块属于一种配置类型；其中两块已被占用。 四块属于另一种配置类型；四块全部空闲。 一个待处理作业请求四块第一种类型的 GPU。 六块 GPU 空闲，但只有两块匹配所请求的类型。总库存大于该请求下有资格使用的容量。

这并不能说明该请求限制得不必要。所请求的类型可能反映了真实的内存或软件要求。在放宽它之前，团队需要确认应用能否使用替代方案并产出可接受的结果。

图 1. 说明性示例：六块 GPU 空闲，但只有两块匹配"请求四块 Type A"的要求。这一约束可能反映了真实的工作负载需求。

空闲 GPU 计数只是诊断的起点。下一步是检查具体的作业及其待处理原因。

AI 工作负载通常有一个超出单个进程的生命周期。它的环境必须准备好，输入必须可访问，计算要启动，输出要收集，失败要处理。

编排处理的就是这些运维层面的问题。工作流工具可以协调准备、训练和评估等步骤。基础设施平台可以管理部署和应用生命周期。具体职责取决于技术栈中的工具。

例如，Kubernetes 使用声明式配置和控制器来管理容器化工作负载。它的调度器将 Pod 匹配到合适的节点。完整的 AI 工作流可能仍需要额外工具来协调应用特定的依赖和步骤。[4][5]

可复现的环境可以解决部署问题。工作流引擎可以解决依赖问题。但这两项改变本身，都不能证明一个分布式训练作业能在能力不同的 GPU 上有效运行。

同样，把工作负载迁移到另一个集群，也无法回答它的运行时将如何处理该集群的硬件。

在评估编排层时，从运维问题入手：需要部署、协调或恢复什么？然后单独考察它所启动的应用的执行需求。

一旦资源分配完成、进程开始运行，应用仍然需要一个可行的执行策略。

对于分布式 AI 工作负载，这意味着要回答如下问题：

软件能否在每一块选定的 GPU 上运行？ 所选的并行化策略能否适配可用内存？ 进程之间必须传递哪些信息，频率如何？ 这次运行能否达到所需的结果质量和完成时间？

GPU 之间的差异在这个层面才变得重要。

例如，PyTorch 的 DistributedDataParallel 使用进程间同步。其文档说明，处理速度不均会导致较快的进程等待较慢的进程，并且用户有责任平衡工作负载分配。[6]

这并不意味着混合 GPU 总是不合适。它意味着资源分配不能替代一个能处理实际工作负载的执行策略。

一个集群可能在总量上拥有足够多的设备，但能满足特定应用要求的组合却很少。反过来，有些工作负载的灵活性可能比它们当前的资源请求所显示的更大。要确认这种灵活性，需要检查与测试。

可以。Slurm 支持由资源需求不同的组件构成的异构作业。它还支持跨作业组件启动应用，但受限于有文档记录的配置和应用限制。[3]

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）