GPU算力管理原理机制与工作流程详解

好的，没问题。作为一名在云计算和高性能计算领域摸爬滚打多年的老兵，今天就来聊聊AI时代下GPU算力管理那些事儿。我们不谈花哨的Prompt，直接切入核心——当模型参数、数据量和并行度飞速膨胀时，底层的GPU资源到底该怎么管、怎么分，才能既反赌，又不浪费。 核心内容概览： 1. AI时代对GPU算力管理和分配提出了哪些全新挑战 2. 业界应对这些挑战的通用技术工具包 3. 从单卡到多机多卡，算力调度策略的演进脉络 一、前言 现在关于大模型的文章很多，大多集中在工程应用、算法优化、提示工程，或者像PAI、百炼这类产品组合上。但有一个关键环节往往被一笔带过——AI/ML训练任务本身的管理：任务流怎么分配？任务之间的调度关系怎么处理？数据集如何加速访问？这些支撑层面的内容，市场上讲得比较零散。 实际上，不同的AI任务对异构资源（GPU、CPU、内存）的调度、分配和隔离需求千差万别。调度策略选择不当，不仅训练时间会拉长，最终效果也可能打折扣。更现实的问题是，GPU卡越来越贵，如何通过精细化的调度，让每块GPU的利用率接近饱和，尽量减少空闲的核心，实现投入产出最大化，这已经是所有客户的刚需。 之前有一篇文章详细梳理了NVIDIA GPU架构的演进，以及它们如何通过提升核心结构、内存系统（HBM、L1/共享缓存）和互联技术（NVLink、NVSwitch）来应对大模型时代的挑战。这次我们把视角从硬件拉到任务调度本身。 （图片位置：AI任务对GPU资源的利用方式示意图） 上图展示了AI任务如何以任务视角切入GPU资源调度。从宏观到微观，大致可以分为几个层级： * **云边端层面**：在云-边-端、多云及混合组网下，任务如何在不同位置间分配和迁移。 * **GPU集群资源调度层面**：任务并行、串行，以及时间和空间的平衡。 * **多机多卡调度层面**：多机器组网时，资源调度如何感知高速网络的拓扑结构。 * **单机多卡调度层面**：资源调度如何感知GPU、CPU、PCIE、GDDR等组件的拓扑关系。 * **单卡调度层面**：单卡独占、单卡多任务、多任务隔离与共享。 这篇文章会从GPU算力出发，聚焦于AI时代「大参数、大数据、大并行」带来的真实挑战，看看客户如何借助云原生能力实现高效的GPU算力管理，最终获得更高的利用率和更优的投入产出比。坦白说，部分挑战目前还没有某个单一技术能完美解决，这需要从整体平台架构层面去通盘考虑。 二、AI时代对GPU算力管理的挑战 **2.1 云-边-端业务对算力调度的新挑战** 现在大多数客户的技术架构都在朝着多云/边缘云方向发展。这既是技术演进的必然，也是业务需求的推动。传统场景下，AI任务在单一云节点上跑，只需要一次调度——任务开始到结束，调度一次就行。但在云-边-端架构下，任务需要经历多次调度，会随着端侧的具体业务场景在云、边、端之间来回迁移。 举个典型的例子——汽车自动驾驶： * **云侧**：集中式AI能力，算力最强，但延迟最高。 * **边缘侧**：区域化中心AI能力（部分客户可能没有），算力次之，延迟次之。 * **端侧**：每辆汽车本地的AI芯片，算力最弱，但延迟最低（从几百ms到几十ms到几ms）。 具体场景是这样的：当驾驶员没有开启自动驾驶时，地图、游戏、音乐、智能助手等任务都跑在汽车芯片上。一旦开启自动驾驶，本地算力不够用，自动驾驶任务必须优先占用车载芯片，其他任务就得被调度到边缘或云侧。等到自动驾驶任务结束，云/边缘上的任务又得被调度回汽车芯片。这种频繁的跨层级任务迁移，对调度系统的灵活性要求极高。 **2.2 AI任务特征对时间与空间的挑战** 从微观层面看，计算核心（core）遵循分时调度原则，单线程占用的资源不会超过一个core。但从宏观上看，一个任务占用的资源可大可小——可能少于一个core，也可能横跨多个core、多台机器。AI训练任务的典型特征就是「大数据、大参数、大并行运算」，往往需要大量core参与数据搬运和训练。因此，任务可以分为串行和并行两类。 * **串行处理**：按顺序逐一执行任务，适用于计算资源有限但任务尺寸较大的情况。本质上是拿时间换资源。 * **并行处理**：同时执行多个任务片段，用更多的计算资源换取更短的训练时间，这就是并行加速。 现在的问题是：一方面，GPU资源极度紧俏，一卡难求；另一方面，即使买到了，机器内部的GPU拓扑结构、多台机器之间的拓扑结构，都会直接影响训练时长。更头疼的是，企业的AI任务五花八门，不可能为每种任务都单独定制GPU分配方案。所以，一个务实的思路是：把有限的GPU资源池化，通过统一的调度平台，让同一批GPU资源应对不同AI任务，实现资源利用率与任务效果的双赢。 **2.3 数据量对大规模计算调度的挑战** 随着模型参数量和训练数据量的持续增长，单机训练已经力不从心，集群训练成为主流。NVIDIA甚至推出了像GB200这样的多机组合集群。用户看到的虽然是一个单一的训练任务，但底层会被拆分成多个子服务，运行在不同GPU服务器的不同GPU卡上。 这里的核心挑战在于：如何管理和优化这些小服务之间的交互。当某个子任务需要的数据存储在另一台机器上时，如何快速把数据搬运过来？这才是决定整体训练效率的关键瓶颈。 **2.4 任务特性对算力管理的挑战** 以阿里云的GPU实例为例，gn8v、ebmgn8v等提供了从一机一卡、一机两卡到一机四卡、一机八卡等多种规格，适配不同的AI任务需求。但卡数的增加并不是纯粹的算力叠加，它直接影响资源调度的分配方式。比如，同一个AI任务在无NVLink的情况下，分配到同一个CPU下的多个GPU卡，与分配到不同CPU下的GPU卡相比，前者能减少CPU上下文接入和切换开销。但如果不同CPU下的GPU之间有高速数据交互链路（比如NVLink），跨CPU调度的性能影响就不大了。所以，在多机多卡场景下，机器的GPU、CPU、网络、内存等拓扑链路，对调度分配至关重要。 **2.5 多任务系统对任务管理的挑战** 现代计算已经从单机演进到集群，进一步扩展到跨集群、跨数据中心，乃至云边端协同融合计算。一方面，一个大型资源系统上可能同时运行着不同业务部门的各类任务；另一方面，单张GPU卡的核心越来越多。在GPU-to-GPU带宽有限的情况下，如何让不同业务方的任务既能并发运行，又能独立独享，同时对不同任务的数据缓存做隔离和QoS保障，这是必须考虑的问题。 三、GPU算力管理 **3.1 算力管理概览** （图片位置：算力管理概览图） 这里先抛开任务管理层（云-边-端和GPU集群任务调度），因为它们的实现已经不是单一产品或技术能解决的，需要客户从业务架构规划、AI任务管理平台、硬件拓扑选型等多个方面综合设计。本节主要聚焦于为满足不同GPU资源使用诉求，从单卡调度、单机多卡调度到多机多卡调度发展出来的基础技术。 **3.2 单GPU卡算力管理** **3.2.1 MPS（单卡多线程并行）** MPS（多进程服务）是CUDA API的一种替代性实现，与原有二进制代码兼容。它的运行时架构旨在透明支持协作式多进程CUDA应用，特别是MPI任务。NVIDIA在Pascal架构引入MPS，并在Volta架构中做了进一步完善。Volta MPS相比之前版本，主要改进包括： 1. **直接提交任务至GPU**：Volta MPS客户端可以直接向GPU提交任务，不再需要经过MPS服务器。 2. **独立的GPU地址空间**：每个客户端拥有独立的GPU地址空间，不与其他客户端共享。 3. **有限执行资源分配以保证QoS**：支持有限执行资源分配，确保服务质量。 **MPS优势** * **提高GPU利用率**：不同进程的内核和内存复制操作可以在GPU上并发执行，提升利用率，加快任务完成。 * **减少GPU上下文存储**：MPS服务器为所有客户端共享一份GPU存储和调度资源，减少资源占用。 * **减少GPU上下文切换**：通过共享调度资源，消除了进程间切换开销，提高效率。 **适用应用场景** MPS特别适合那些单进程无法饱和GPU的应用场景。通过在同一个节点上运行多个进程，可以增强并发性。对于每网格块数较少的应用，或者因每网格线程数少导致GPU占用率低的应用，使用MPS可以有效提升性能。在强扩展场景中，MPS能充分利用剩余GPU容量，让不同进程的内核并发执行。 **限制** **A. 系统限制** * **操作系统支持**：仅支持Linux。 * **Tegra平台支持**：仅Volta MPS支持Tegra。 * **GPU计算能力要求**：需要计算能力3.5或更高的GPU。若任一可见GPU低于3.5，MPS服务器无法启动。 * **UVA要求**：必须启用统一虚拟寻址（UVA），默认情况下计算能力2.0及以上GPU上的64位程序已启用。 * **页锁定主机内存限制**：受tmpfs文件系统（/dev/shm）大小限制。 * **独占模式限制**：应用于MPS服务器，Tegra平台不支持GPU计算模式。 * **用户限制**：一个系统只能有一个活跃的MPS服务器用户。 * **用户排队机制**：来自不同用户的MPS服务器激活请求会排队，可能导致串行独占访问。 * **行为归因**：系统监控工具（如nvidia-smi）将所有MPS客户端行为归因于MPS服务器进程。 **B. GPU计算模式限制** nvidia-smi支持三种计算模式： * PROHIBITED：GPU对所有计算应用不可用。 * EXCLUSIVE_PROCESS：GPU一次只分配给一个Context（CPU进程），单个CPU进程的线程可同时向GPU提交工作。 * DEFAULT：多个CPU进程可同时使用GPU。 使用MPS实际上会使EXCLUSIVE_PROCESS模式对所有客户端表现得像DEFAULT模式。MPS总是允许多个客户端通过MPS服务器使用GPU。建议在使用MPS时启用EXCLUSIVE_PROCESS模式，确保只有一个MPS服务器使用该GPU。 **C. 应用限制** * NVIDIA视频编解码SDK在Volta之前MPS客户端上不支持。 * 仅支持64位应用程序。 * 若使用CUDA驱动API，必须使用CUDA 4.0或更高版本头文件。 * 不支持动态并行特性。 * 服务器与客户端需相同UID。 * Volta之前MPS客户端不支持流回调。 * Volta之前MPS不支持包含主机节点的CUDA Graph。 * MPS客户端未同步终止可能导致未定义状态。 * 由MPS客户端创建的CUDA Context与非MPS Context之间的IPC通信在Volta MPS上支持。 参考文档：NVIDIA MPS官方文档 **3.2.2 MIG（单卡单显存多租户线程物理隔离）** MIG（多实例GPU）让每个实例的处理器在整个内存系统中拥有独立路径——片上交叉开关端口、L2缓存库、内存控制器和DRAM地址总线都唯一分配给一个实例。这意味着单个用户的工作负载可以以可预测的吞吐量和延迟运行，即使其他任务在冲击缓存或饱和DRAM接口。MIG可以分割可用的GPU计算资源（包括SM和GPU引擎如复制引擎或解码器），提供定义的服务质量和故障隔离。 从NVIDIA Ampere架构（计算能力>=8.0）开始的GPU支持MIG。以下为支持的GPU列表（此处应有图片）。 MIG中GPU分为GI（GPU Instance）和CI（Compute Instance），CI是GI的子集，共享GI的共享内存和带宽。GI之间在物理层面完全隔离。GI是GPU切片和GPU引擎（DMA、NVDEC等）的组合。GI提供内存级别的QoS，每个GPU内存切片获得总物理内存资源的1/8，每个GPU SM切片获得总SM数量的1/7。CI包含父GI的SM子集和其他引擎子集，共享内存和引擎。例如下图是A100可划分的MIG类型（图片位置）。 **相关特性** * **提高资源利用率**：MIG允许将GPU安全分割成最多七个独立实例，为多个用户提供独立资源。 * **多租户物理隔离**：确保一个客户不影响其他客户的工作和调度，提供增强隔离。 **相关限制** **A. 系统限制** * **操作系统支持**：仅Linux。 * **支持配置**：裸金属、容器。 * **GPU需要重置**：在A100/A30上设置MIG模式需要超级用户权限。 * **配置持久化**：MIG配置持久，重启不重置。 * **驱动限制**：需停止所有持有驱动模块句柄的守护进程。 * **权限配置**：切换MIG模式需要CAP_SYS_ADMIN能力，创建/销毁实例默认需超级用户，但可委派。 **B. 应用限制** * **图形API不支持**：OpenGL、Vulkan等。 * **不支持G2C**：GPU到GPU的P2P（PCIe或NVLink）。 * **物理隔离**：CUDA应用程序将计算实例及其父GPU实例视为单个CUDA设备。 * **跨实例调用限制**：不支持跨GPU实例的CUDA IPC，跨计算实例支持。 * **MPS支持**：在MIG之上支持MPS，最大客户端数按比例降低。 * **GDR支持**：支持GPUDirect RDMA。 参考文档：NVIDIA MIG用户指南 **3.2.3 阿里云cGPU（单卡算力和显存分配）** cGPU是阿里云基于内核虚拟GPU隔离的容器共享技术。多个容器共享一张GPU卡，实现业务安全隔离，提高硬件利用率，降低使用成本。它支持**显存或算力**两个维度的隔离和组合。 **适用应用场景** * **兼容性好**：适配标准Docker和Containerd，无缝兼容K8s。 * **操作简单**：无需重编译AI应用，运行时无需替换CUDA库。 * **资源灵活划分**：物理GPU资源可任意划分。 * **GPU实例规格无限制**：支持裸金属、虚拟化、vGPU等各种实例。 * **应用场景丰富**：支持在离线混部、CUDA AI和渲染应用。 * **功能强大**：支持高优先级抢占、热升级、多卡划分。 共享GPU调度的文件路径为`/proc/cgpu_km`，其目录结构如下（原文中有树形结构，此处保留文字描述）： ``` [root@xxx cgpu_km]# tree ├── 0 #GPU序号 │ ├── aaa7d95f0dbf #被调用在此的容器ID │ │ ├── highprio #容器优先级 │ │ ├── id │ │ ├── meminfo #显存和剩余显存大小 │ │ ├── memsize #容器内的显存大小 │ │ └── weight #容器获取显卡最大算力的权重，默认值为1 │ ├── free_weight #该GPU分配pod的权重 │ ├── major │ ├── max_inst #用于设置容器的最大数量，取值范围1~25 │ ├── policy #cGPU算力调度策略 │ └── prio_ratio #高优先级容器最大可抢占算力，范围20~99 ├── 1 │ ├── free_weight │ ├── major │ ├── max_inst │ ├── policy │ └── prio_ratio ├── default_memsize #如果没有设置ALIYUN_COM_GPU_MEM_CONTAINER参数 ├── inst_ctl ├── upgrade #控制热升级 └── version #cgpu设备版本号 ``` 关键环境变量： | 变量 | 说明 | | --- | --- | | ALIYUN_COM_GPU_MEM_DEV | 设置GPU实例上每张显卡的总显存大小，按GiB取整数。 | | ALIYUN_COM_GPU_MEM_CONTAINER | 设置容器内可见的显存大小，0或未设置表示禁用cGPU。 | **cGPU算力分配策略** cGPU服务加载cgpu_km模块时，会按容器最大数量（max_inst）为每张显卡设置时间片（X ms），用于分配GPU算力。 | Policy | 说明 | | --- | --- | | 平均调度（policy=0） | 创建容器时分配时间片，每个容器算力相同，为1/max_inst。 | | 抢占调度（policy=1） | 跳过未使用容器的调度，切换到下一个时间片。 | | 权重抢占调度（policy=2） | 设置ALIYUN_COM_GPU_SCHD_WEIGHT>1时启用，将多个时间片组合成更大时间片。 | | 固定算力调度（policy=3） | 通过指定WEIGHT和max_inst占比，固定算力百分比。 | | 算力弱调度（policy=4） | 隔离性弱于抢占调度。 | | 原生调度（policy=5） | 只做显存隔离，使用NVIDIA GPU驱动本身调度方式。 | **3.3 单机多卡GPU算力管理** **3.3.1 PCIE & NVLink & NVSwitch（单机多卡组合）** （图片位置：典型8卡机器内部拓扑示意图） PCIE可以在单机内实现多设备数据传输。上图是一个典型的8卡机器架构，GPU通过PCIE互联，但NIC（网卡）、NVMe、GPU共享PCIE总带宽。如果涉及跨CPU的GPU通信，还会受到CPU间链路限制。比如图中GPU0-GPU1受PCIE0影响，GPU3-GPU5需要经过两个CPU之间的交互。所以，资源调度所使用的GPU间拓扑结构，对任务整体性能影响很大。 除了PCIE，还可以使用NVLink——NVIDIA开发的双向GPU-GPU直接互连技术。NVLink 5.0提供高达1800 GB/s的带宽，比PCIE 5.0高出14倍。它连接Grace CPU和Hopper GPU，显著增强大规模AI模型处理能力。NVSwitch作为一个独立NVLink芯片，支持最多18个NVLink连接，进一步提升了多GPU环境的数据流通速度和并行处理效率。 不过有个细节：虽然GPU之间绕过了PCIE和网卡的限制，但GPU间的通信能力仍然取决于NVLink的数量。例如图中GPU0-GPU6只有1条NVLink，而GPU3-GPU5之间有2条。从Ampere架构开始，NVIDIA引入NVSwitch，使得单机内任何GPU卡之间的带宽链路变得一致。到了Hopper架构，NVLink甚至被引入到机器之间，实现了服务器组内多GPU卡的一致性互联。这也是为什么客户必须了解底层GPU拓扑架构——不同的架构需要适配不同的算力调度策略。 **3.3.2 阿里云cGPU（多卡算力和显存分配）** 在3.2.3中已经介绍过cGPU单卡层面的功能，下面给出多卡的算力和显存分配配置示例。 环境变量： | 变量 | 说明 | | --- | --- | | ALIYUN_COM_GPU_VISIBLE_DEVICES | 指定容器内可见的GPU显卡，如`0,1`表示分配第1和第2张显卡。 | | ALIYUN_COM_GPU_MEM_CONTAINER | 设置容器内每张卡的显存大小。例如`3`表示所有卡显存设为3G；`3,1`表示第1张卡3G、其余1G；`3,4,5,6`依次设置。未设置或包含0则禁用cGPU。 | **3.4 多机多卡GPU算力管理** **3.4.1 NVSwitch** 在Hopper架构中，NVIDIA推出了基于模块化MGX平台的GB200服务器，最多可以连接32个GPU。所有GPU线程能够访问高达19.5TB内存，总带宽高达900GB/s，以及14.4TB/s的带宽。 参考链接：NVIDIA Grace Hopper **3.4.2 RDMA** RDMA（远程直接内存访问）是一种高性能网络通信机制，允许一台计算机直接访问另一台计算机的内存，无需操作系统内核或CPU干预。这能显著减轻CPU负担，提升数据传输速度，降低延迟，增强计算效率。 **技术特点 - 优点** * **高性能与低延迟**：应用程序直接和网卡交互，绕过了内核和CPU切换，降低延迟。 * **高数据传输**：数据无需复制到网络层，减少拷贝开销。 * **大规模并行计算**：支持多个独立通信流，在节点间高效交换和同步数据。 * **快速内存访问**：允许远程节点直接访问本地内存。 * **硬件off-load**：将协议栈处理卸载到网卡硬件，减轻CPU负担。 **技术特点 - 缺点** * **专用硬件设备**：需要特定软硬件匹配。 * **安全性**：允许远程节点直接访问本地内存，可能带来安全问题。 * **编程复杂性**：需要对内存管理和并发机制有深入理解。 * **网络规模限制**：对网络稳定性和可靠性要求高。 * **高成本**：需要特定网卡硬件，厂商少。 **技术分类** 按照技术分类，RDMA可分为IB、RoCE和iWARP三种： | 技术分类 | IB | RoCE | RoCE v2 | iWARP | | --- | --- | --- | --- | --- | | 协议 | IB专有协议 | 以太网 | 以太网/UDP | 以太网/TCP | | 设备要求 | 专有硬件和交换机 | 支持已有以太网（PFC），网卡将RDMA操作转为以太网包 | 在RoCE基础上使用UDP包，支持Vxlan多租，支持跨交换机 | 使用TCP实现可靠传输 | | 性能 | 高 | 中 | 中 | 差 | | 成本 | 高 | 中 | 中 | 低 | | 设备厂商 | NVIDIA Mellanox | NVIDIA Mellanox、Intel | NVIDIA Mellanox、Intel | Intel、eRDMA（阿里云VPC） | **3.4.3 阿里云eRDMA** eRDMA是阿里云自研的云上弹性RDMA网络，底层链路复用VPC网络，采用全栈自研拥塞控制算法。它享有传统RDMA高吞吐、低延迟的特性，同时可支持秒级大规模RDMA组网，兼容传统HPC应用、AI应用和TCP/IP应用。 传统TCP/IP协议固有局限（拷贝开销大、协议栈厚重、拥塞控制复杂、上下文切换频繁），成为应用性能瓶颈。RDMA通过零拷贝和内核旁路大幅减少了延迟与CPU占用，但成本高、运维复杂。阿里云eRDMA旨在提供一种云端普及的解决方案，既保持低延迟优势，又降低部署门槛。**eRDMA默认采用iWarp模式，相比IB和RoCE，不需要专用RDMA设备，与默认VPC网络互通，成本最低，组网和弹性扩展能力强。** **功能优势** * **高性能**：继承RDMA优势，应用于VPC，提供低延迟性能。 * **普惠**：免费启用，购买实例勾选即可，无需额外付费。 * **规模部署**：自研CC算法适应VPC网络变化，在有损环境中保持良好性能。 * **弹性扩展**：基于神龙架构，支持动态添加和热迁移。 * **共享VPC网络**：通过ENI复用现有网络资源，无需改变组网即可激活RDMA功能。 详细文档参考：阿里云eRDMA官方文档 **3.4.4 GDR** GPUDirect RDMA（GDR）是在Kepler GPU和CUDA 5.0中引入的技术，利用PCI Express标准功能实现GPU与第三方设备（网络接口、视频采集设备、存储适配器）之间的直接数据交换。传统上，数据在GPU和另一设备间传输必须经过CPU，导致性能瓶颈和延迟增加。GPUDirect技术通过绕过CPU直接访问数据，显著提高系统性能。在设置GPUDirect RDMA通信时，从PCI Express设备角度看，所有物理地址对两个设备相同。物理地址空间中有称为PCI BAR的线性窗口，每个设备最多有六个BAR寄存器（最多六个活跃32位BAR区域，64位BAR消耗两个）。PCI Express设备以读写系统内存的方式读写对等设备的BAR地址。 参考链接：NVIDIA GPUDirect RDMA 四、小结 这篇文章主要梳理了在AI时代「大参数、大数据、大算力」需求下，GPU算力管理和分配面临的五大挑战。同时介绍了应对这些挑战时，从单卡算力管理、单机多卡算力管理到多机多卡算力管理发展出来的业界通用技术，包括NVIDIA的MPS、MIG、NVLink & NVSwitch，阿里云的cGPU、RDMA和eRDMA。这些技术的出现，为客户灵活按需调用GPU资源、将多GPU资源组合成统一集群创造了条件。 不过，对每块GPU卡进行算力资源管理、组网配置、环境部署，对AI科学家来说仍然是个巨大的挑战。更现实的是，客户的业务面向不同租户，不同租户有不同AI任务，所需的GPU资源、任务优先级、任务类型和时效性都千差万别。 因此，一个关键的结论是：需要一个中间平台层，把纷繁的GPU资源整合起来，面对不同AI任务需求，实现差异化的分配策略和互相隔离。这才是未来高效利用GPU算力的正确路径。