AI 集群为什么需要统一资源管理，几十台服务器和几千块 GPU 应该怎样协调

AI 集群为什么需要统一资源管理？几十台服务器和几千块 GPU 怎样协调

一台服务器只有几块GPU时，资源管理并不复杂。管理员可以直接登录服务器，查看GPU是否空闲，然后运行训练任务。

但当规模扩大到几十台甚至上百台服务器、数百乃至数千块GPU以后，事情就完全不同了。

此时真正困难的已经不是“有没有GPU”，而是如何知道哪块GPU可以使用、哪些GPU彼此连接最快、任务需要多少CPU和内存、数据应该从哪里读取，以及多个训练任务怎样避免互相抢占资源。

因此，大型AI集群需要统一的资源管理和调度机制。它的核心任务并不是简单地把GPU“分出去”，而是把计算、GPU、网络、存储以及任务之间的关系统一考虑，尽可能让昂贵的GPU保持高利用率，同时避免因为错误的资源分配导致训练速度大幅下降。

一、为什么几十台服务器不能各管各的

假设一个企业有50台GPU服务器，每台服务器安装8块GPU，总共就是400块GPU。

如果没有统一调度系统，每个团队都自己寻找空闲服务器，很快就会出现一种非常典型的情况。

有人需要8块GPU进行大模型训练，却发现没有一台服务器能够提供完整的8块空闲GPU；与此同时，其他服务器上可能分别还有2块、3块或者4块GPU处于空闲状态。

从整个集群来看，可能还有几十块GPU没有被使用，但从某一个具体任务来看，却没有足够的连续资源。

这就是资源碎片化。

而且GPU并不是完全相同的资源。

集群中可能同时存在不同型号的GPU，不同GPU拥有不同的显存容量、计算能力和互联方式。一个任务可能需要80GB显存的GPU，另一个任务只需要较小显存的设备。如果调度系统只按照“GPU数量”进行分配，就可能出现资源分配错误。

因此，大型集群需要把GPU从单纯的硬件设备抽象成可以被调度系统识别的资源。

二、Kubernetes到底是怎样管理GPU的

以Kubernetes为例，一个Node通常对应一台物理服务器或者虚拟机，而GPU则属于这个Node上的专用硬件资源。

Kubernetes通过Device Plugin机制让节点向集群管理系统报告GPU等专用设备。NVIDIA官方Device Plugin会把GPU暴露为类似nvidia.com/gpu这样的扩展资源，调度器据此判断一个节点上还有多少GPU可以分配。

因此，不能简单理解为“每一块GPU就是一个Kubernetes节点”。

更准确的关系是：

服务器 → Kubernetes Node → GPU等专用资源 → Pod中的任务。

例如一台服务器拥有8块GPU，Kubernetes可以知道这个Node拥有8个可分配的nvidia.com/gpu资源。

某个训练任务申请4块GPU后，调度器就会寻找满足CPU、内存、GPU等条件的节点，然后把任务安排过去。Kubernetes对这类扩展资源进行资源核算，并要求Pod的资源请求得到满足后才能完成调度。

这就是统一资源管理最基本的一层。

三、GPU数量够，不代表任务就能跑得快

AI集群与普通Web服务器最大的区别之一，是硬件之间的通信关系非常重要。

假设一台服务器里面有8块GPU。

如果这些GPU之间拥有高速互联，那么训练任务可以在GPU之间快速交换数据。

但如果一个训练任务需要使用分布在不同服务器上的32块GPU，那么GPU之间的通信就必须经过服务器之间的网络。

这时候，网络就成为计算性能的一部分。

NVIDIA针对集群工作负载的架构说明也强调，多节点GPU工作负载通常需要高速互联网络，例如InfiniBand或RoCE，同时GPU之间还可能通过NVLink和NVSwitch进行高速通信。

因此，调度器不能只问一个问题：

“哪里还有8块GPU？”

更应该考虑：

“哪里有8块合适的GPU，而且它们之间的连接关系适合这个任务？”

这就是拓扑感知。

四、为什么GPU集群特别重视网络拓扑

对于普通网站来说，一台服务器放在机房A还是机房B，通常不会直接决定网页能不能打开。

但对于大模型训练来说，节点位置可能直接影响训练效率。

例如一个分布式训练任务需要在多个节点之间不断同步参数。如果其中一部分GPU之间通信速度很快，而另一部分GPU需要经过更复杂的网络路径，那么整个训练过程可能受到最慢通信链路的影响。

NVIDIA目前也提供了专门的拓扑发现和调度相关工具，用于把集群中的物理网络拓扑信息提供给Slurm、Kubernetes等工作负载调度系统。其官方文档明确指出，在大规模集群中，任务运行在哪些节点可能直接影响性能。

因此，大型AI集群的调度已经逐渐从“资源数量调度”发展到“资源加拓扑调度”。

五、GPU、CPU、内存和网络必须一起考虑

一个AI训练任务通常不会只需要GPU。

它还需要CPU负责数据预处理，需要系统内存缓存数据，需要本地NVMe或者共享存储提供训练数据，还需要高速网络进行节点之间的数据通信。

假设某个任务申请8块GPU，但所在服务器CPU性能不足，数据加载速度跟不上GPU计算速度，那么GPU可能大量时间处于等待状态。

这时候继续增加GPU并不能解决问题。

同样，如果GPU计算速度很快，但训练数据从远程存储读取速度太慢，GPU利用率也可能很低。

所以大型AI集群真正需要管理的是一组相互关联的资源：

GPU + CPU + 内存 + 本地存储 + 网络。

这也是为什么AI集群的资源调度比普通服务器集群更加复杂。

六、资源调度还要面对GPU型号不同的问题

假设一个集群里面同时存在A100、H100以及其他型号GPU。

如果所有任务都只写“我要4块GPU”，调度系统就无法充分理解任务需求。

有些任务可能需要大显存GPU，有些任务更关注计算能力，还有些任务必须使用特定的GPU架构或者软件环境。

因此，现代资源管理系统越来越强调“设备属性”和“资源类型”。

Kubernetes正在发展Dynamic Resource Allocation，也就是DRA机制，用更加灵活的方式描述和申请GPU等专用设备。

Kubernetes 1.36中，DRA已经进一步发展，并支持按照设备类别和优先级等方式提出资源需求。例如，一个工作负载可以表达对某种GPU的优先选择，并在首选设备不可用时使用其他符合条件的设备。

这对于拥有大量异构GPU的集群尤其重要。

七、GPU Operator解决的是什么问题

很多人容易把GPU Operator理解成“GPU集群调度器”，其实并不是。

NVIDIA GPU Operator主要解决的是GPU软件栈的部署和管理问题。

例如GPU驱动、NVIDIA Container Toolkit、Device Plugin以及GPU监控组件等，都需要正确安装和配置。GPU Operator可以帮助自动化管理这些组件，减少管理员逐台服务器安装和维护的工作量。

也就是说：

GPU Operator解决的是GPU基础环境管理问题；Kubernetes Scheduler等机制解决的是任务资源调度问题。

两者属于不同层次。

在实际集群中，它们可以配合使用。

八、资源调度还要解决“多人抢GPU”的问题

大型AI集群通常不只有一个团队使用。

研究人员可能运行模型训练，开发人员可能运行测试任务，生产系统还可能同时运行在线推理服务。

如果没有资源配额和优先级机制，一个大型训练任务可能一次占用大量GPU，使其他业务长时间等待。

Kubernetes可以通过ResourceQuota等机制限制某个Namespace可以申请的GPU数量。例如，可以限制一个团队最多同时申请一定数量的GPU。

在更复杂的环境中，还可以进一步使用优先级、抢占、队列以及Gang Scheduling等机制。

这时候资源管理的目标就从单纯的“把GPU利用起来”，变成了：

如何在多个团队、多个任务之间公平而高效地分配GPU。

九、为什么GPU利用率低，并不一定是GPU的问题

很多人看到GPU利用率只有50%，第一反应是“GPU太多了”。

实际上，问题可能完全出在其他地方。

例如：

数据读取太慢；

CPU预处理速度不足；

网络通信延迟过高；

GPU之间同步时间过长；

显存容量不足；

模型没有充分利用GPU并行能力。

因此，评价AI集群不能只看GPU利用率一个指标。

真正需要观察的是GPU计算利用率、显存使用情况、CPU负载、网络吞吐、存储吞吐以及分布式通信效率。

NVIDIA的GPU Operator也提供基于DCGM的GPU监控能力，可以把GPU状态纳入集群监控体系。

十、训练集群和推理集群的资源需求并不一样

AI训练和AI推理虽然都使用GPU，但资源管理策略并不相同。

训练任务通常需要长时间占用大量GPU，并且非常关注GPU之间的高速通信。

例如一个大模型训练任务可能需要多个节点共同工作，此时节点之间的网络性能和GPU拓扑非常重要。

推理任务则可能更加关注响应延迟和并发数量。

一个在线推理服务未必需要整台服务器的全部GPU，如果GPU支持合适的共享或分区机制，就可能让多个业务共同使用一台服务器的GPU资源。

因此，同一个AI集群中往往需要同时支持不同类型的工作负载，而不是采用完全相同的调度方式。

十一、真正的大型AI集群是一套分层系统

到了几百甚至几千块GPU的规模以后，很难用一个软件解决所有问题。

实际系统通常是分层工作的。

底层是GPU服务器、CPU、内存、NVMe、网络设备以及GPU互联硬件。

再上一层是操作系统、GPU驱动、容器运行环境和网络驱动。

然后是Kubernetes或者Slurm等集群管理和调度系统。

在GPU资源管理层，还可能使用NVIDIA GPU Operator、Device Plugin或者DRA等机制。

再往上才是PyTorch、TensorFlow、NCCL等AI软件栈以及具体训练和推理任务。

每一层解决不同的问题。

如果把所有问题都归结为“GPU调度”，反而会让架构理解变得混乱。

十二、真正决定集群效率的是资源与拓扑的匹配

大型AI集群最理想的状态，并不是让每一块GPU永远保持100%利用率。

有时候为了完成一个大型训练任务，需要暂时保留部分GPU资源，等待能够形成合适的资源组合。

例如，一个需要8块GPU并且要求高速互联的任务，如果为了追求局部GPU利用率，把这8块GPU分散到多个通信条件较差的节点上，最终可能导致整个训练速度下降。

所以资源调度需要在两个目标之间寻找平衡：

资源利用率和任务性能。

Kubernetes本身已经提供了针对扩展资源的调度和资源装箱等机制，可以根据资源利用情况对节点进行评分，从而提高资源使用效率。

但对于大型AI集群，还必须进一步考虑GPU之间的物理拓扑、网络结构以及任务自身的通信需求。

总结

几十台服务器和几千块GPU并不是简单地把很多电脑连接起来。

当集群规模扩大以后，真正困难的是如何把不同型号的GPU、CPU、内存、存储和网络组织成一个能够被统一管理的资源池。

资源调度系统负责决定“任务放在哪里”，GPU设备管理机制负责让集群知道“有哪些GPU可以使用”，网络和拓扑管理机制则进一步决定“这些GPU之间通信是否高效”。

因此，AI集群的核心并不是单纯追求GPU数量，而是建立一套能够同时理解资源、任务和硬件拓扑的管理体系。

对于几十台服务器的小型集群，可以从Kubernetes或Slurm等成熟调度系统开始；随着GPU数量增加，再逐步引入GPU Operator、Device Plugin、DRA以及拓扑感知等机制。

当集群达到数百甚至数千块GPU时，真正决定成本和性能的，往往已经不是“买了多少GPU”，而是这些GPU能否被正确地组织、调度和高效通信。