GPU 调度究竟在调度什么，AI 训练任务如何获得 CPU、GPU、内存和网络资源

GPU调度在AI训练中究竟解决什么问题

在人工智能训练系统中，GPU是最重要的计算资源之一。随着大模型参数规模不断增加，单台服务器往往需要同时使用多张GPU，甚至需要多个服务器组成GPU集群。此时，如何把训练任务合理分配到GPU上，就成为AI基础设施中的重要问题。

所谓GPU调度，并不是简单地“把任务交给GPU”。真正的GPU调度涉及GPU数量、显存容量、CPU、系统内存、存储以及GPU之间和服务器之间的网络通信等多个方面。一个训练任务即使获得了足够数量的GPU，如果CPU供数不足、显存不够或者GPU之间通信效率太低，最终的训练速度仍然可能非常慢。

首先需要区分GPU资源调度和GPU内部计算调度。

在集群层面，调度系统主要负责决定一个训练任务应该运行在哪些GPU节点上，以及分配多少GPU资源。例如，一个训练任务可能需要4张GPU，调度系统需要寻找具有足够GPU资源的节点，并根据CPU、内存以及其他资源限制决定是否能够启动任务。

但是，调度系统通常不会直接决定GPU内部某一个计算核心执行哪一条指令。GPU内部的线程块、线程束以及计算资源如何执行，是由GPU硬件、驱动程序和计算运行时共同完成的。

因此，所谓“GPU调度”实际上包含两个不同层次：上层是集群和任务级资源调度，下层则是GPU自身的计算调度。两者不能混为一谈。

AI训练还高度依赖CPU和GPU之间的数据传输。

以常见的深度学习训练流程为例，训练数据通常首先从SSD、网络存储等设备读取到系统内存，然后经过数据预处理，再传输到GPU显存。CPU负责数据加载、预处理以及部分控制逻辑，而GPU负责大量矩阵运算和张量计算。

如果数据加载速度跟不上GPU的计算速度，GPU就可能出现等待状态。此时即使服务器拥有非常强大的GPU，整体训练效率也可能受到限制。

因此，AI训练中的GPU利用率并不只取决于GPU本身。数据读取速度、CPU处理能力、PCIe带宽、内存带宽以及数据加载程序的设计，都可能影响最终性能。

显存则是另一个关键限制。

GPU显存需要存放模型参数、梯度、优化器状态以及训练过程中产生的激活值等数据。对于大型模型，显存容量往往比计算能力更加容易成为限制因素。

如果一个模型能够完整放入单张GPU，那么可以使用单GPU训练。如果模型能够放入多张GPU，并且采用数据并行训练，每张GPU通常保存一份模型副本，然后处理不同的数据批次。

数据并行的优势是实现相对简单，但缺点也很明显：每张GPU都需要保存完整模型。

如果模型本身就无法放入单张GPU显存，就需要采用其他方式。例如，可以使用张量并行，将模型中的计算和参数分布到多个GPU；也可以采用流水线并行，将模型不同阶段放到不同GPU上。此外，FSDP、ZeRO以及各种CPU或NVMe offload技术，也可以通过重新组织参数、梯度和优化器状态的存储方式降低单张GPU的显存压力。

多GPU训练的另一个核心问题是通信。

当多个GPU共同训练一个模型时，它们需要交换大量数据。数据并行训练中，每张GPU计算自己的局部梯度后，通常需要通过AllReduce等集合通信操作进行梯度同步。

AllReduce并不是简单地把一个GPU的数据广播给所有其他GPU。实际系统可以使用Ring AllReduce、Tree等不同算法，根据GPU数量、网络拓扑和通信环境选择不同的实现方式。

当GPU数量增加以后，通信可能逐渐成为训练系统的主要瓶颈。

例如，两张GPU之间的数据交换相对简单，但当几十张甚至数百张GPU共同训练时，GPU之间需要交换的数据量会急剧增加。此时，GPU之间的互联方式、服务器内部PCIe拓扑、NVLink或NVSwitch以及服务器之间的网络结构都会影响训练效率。

在服务器内部，高端GPU系统通常会使用NVLink或NVSwitch提高GPU之间的数据交换效率。与传统PCIe连接相比，这类高速互联可以提供更高的GPU间通信带宽。

不过，不能简单地把某一个带宽数字理解为所有情况下的实际通信速度。实际性能还受到GPU拓扑、通信算法、消息大小、软件栈以及同时运行的其他任务影响。

服务器之间的通信则通常依赖高速网络。

大型AI集群可能采用InfiniBand或者基于以太网的RoCE等高速网络技术。RDMA可以降低网络通信过程中CPU和操作系统内核的参与程度，从而减少通信开销。

在进一步采用GPUDirect RDMA等技术后，网络设备可以更加直接地访问GPU显存，从而减少数据在CPU和系统内存之间不必要的复制。

因此，大模型训练集群中的网络性能并不仅仅取决于“网卡是多少Gbps”。网络延迟、带宽、拓扑结构、交换机性能、拥塞控制以及通信库都会影响最终结果。

集群调度还需要考虑资源碎片问题。

例如，一台服务器可能有8张GPU，但其中已经有6张被其他任务占用。如果新的训练任务需要4张GPU，即使整个集群还有足够的GPU总数量，也可能无法在当前节点立即启动。

这就是GPU资源碎片化问题。

对于多租户AI集群，调度系统还需要考虑GPU类型和显存容量。一个任务可能要求特定型号的GPU，或者要求具有足够显存的GPU。如果调度系统只按照“GPU数量”分配资源，而忽略GPU型号和显存差异，就可能出现任务虽然成功启动，但性能远远达不到预期的情况。

Kubernetes环境中的GPU管理也需要区分不同组件。

Kubernetes本身负责容器和工作负载的调度，而GPU通常通过Device Plugin等机制向Kubernetes暴露为可调度资源。NVIDIA GPU Operator则主要负责在Kubernetes集群中自动部署和管理GPU驱动、Device Plugin、容器运行时相关组件以及监控等GPU软件栈。

因此，不能简单地说“GPU Operator就是GPU调度器”。在实际集群中，GPU资源发现、资源分配、节点调度和GPU软件栈管理通常由多个组件共同完成。

除了资源数量，GPU共享也是一个重要问题。

对于部分推理或者轻量级计算任务，可以通过MIG等技术把支持该功能的GPU划分成相互隔离的GPU实例，使多个任务共享一块物理GPU。也可以采用时间片等方式进行共享。

但是GPU共享并不意味着所有任务都能获得完全相同的性能。不同任务的计算量、显存需求、内存访问模式和通信需求都可能不同。因此，多租户环境中的调度系统还需要考虑公平性、优先级以及资源隔离。

GPU调度的最终目标，是尽可能减少GPU等待时间，同时提高整个集群的资源利用率。

例如，一个训练任务可能需要8张GPU持续运行数小时，而另一个推理任务只需要一张GPU运行几分钟。如果调度策略只考虑GPU数量，而不考虑任务持续时间、优先级和资源需求，就容易产生资源闲置或者任务长期排队的问题。

因此，实际AI集群通常会结合队列、优先级、资源配额、抢占以及拓扑感知等策略进行调度。

拓扑感知尤其重要。

如果一个训练任务需要8张GPU，那么把8张GPU放在同一台具有高速GPU互联的服务器中，通常比把它们分散到多台服务器上更有利于降低通信开销。但如果整个任务规模已经超过单台服务器能够提供的GPU数量，就必须跨节点通信，此时网络拓扑的重要性进一步提高。

从整个系统来看，AI训练性能实际上是计算、显存、数据和通信共同作用的结果。

GPU计算能力再强，如果数据无法及时送入GPU，计算资源仍然会被浪费；显存容量再大，如果GPU之间通信速度不足，多GPU训练仍然可能受到限制；网络带宽再高，如果调度策略导致大量资源碎片，同样无法发挥集群的整体性能。

因此，GPU调度真正解决的问题，并不是简单地“把GPU分给谁”，而是在有限资源条件下，让不同类型的AI任务尽可能合理地使用计算、显存、CPU、存储和网络资源。

对于小规模AI服务器，合理配置GPU、CPU、内存和存储，往往比复杂的调度系统更加重要。而对于拥有几十、几百甚至更多GPU的大型集群，资源调度、拓扑感知、通信优化和多租户隔离就会成为决定整体效率的重要基础设施。

归根结底，GPU调度是AI基础设施的一项资源管理技术。它连接的是训练任务与底层硬件，而真正高效的调度并不是单纯追求GPU利用率最高，而是在性能、资源利用率、公平性、稳定性和成本之间找到合理平衡。随着大模型训练规模不断扩大，这种综合资源调度能力的重要性也会越来越高。