GPU集群基础：GPU架构、集群组成与资源管理基本概念
2.1 GPU核心架构：从SM到CUDA Core
要理解GPU集群的资源碎片化，首先必须清楚单个GPU内部的硬件组织方式。NVIDIA数据中心GPU（如A100、H100）采用SM（Streaming Multiprocessor，流式多处理器）作为基本计算单元。以A100为例，一颗GA100芯片包含108个SM，每个SM内部又划分为4个处理块，每个处理块包含16个FP32 CUDA Core、8个FP64 Core、16个INT32 Core以及4个Tensor Core。这种“GPU → GPC → SM → 处理块 → CUDA Core”的层级关系，决定了线程调度和显存访问的基本粒度。
关键硬件层级（A100为例）：
- CUDA Core：执行FP32/INT32算术运算的最小单元，1个时钟周期可完成1次运算。
- SM（流式多处理器）：包含CUDA Core、Tensor Core、共享内存（Shared Memory）、寄存器文件和调度器，是线程块（Thread Block）驻留和执行的物理场所。
- GPC（图形处理簇）：由多个SM组成，通过L2缓存切片与显存控制器相连。
- 显存（HBM2e/HBM3）：A100拥有40GB/80GB HBM2e，带宽高达2TB/s以上，是数据驻留和交换的主存储区域。
从资源管理的视角看，SM的数量决定了并行吞吐上限，而显存容量和带宽决定了数据驻留能力。当我们在集群层面讨论“卡”的分配时，实际上是在分配整张GPU的SM计算资源和显存资源。碎片化问题在单卡内部同样存在——例如一个仅需2GB显存的小任务，如果被分配到80GB的H100上，剩余78GB显存无法被其他任务利用，这就是“卡内碎片”的雏形。
2.2 集群组成：从单卡到大规模算力池
GPU集群的物理组成可以划分为四个层次：计算节点（服务器）→ 机架（Rack）→ Pod/超节点 → 集群。每个计算节点通常插有4~8张GPU卡（如DGX A100为8卡），通过PCIe Gen4/Gen5或NVLink-C2C互联。节点之间通过高速网络（InfiniBand或RoCE）连接，形成无阻塞或低阻塞的通信拓扑。
| 层次 | 典型规模 | 互联方式 | 带宽/延迟 | 资源管理视角 |
|---|---|---|---|---|
| GPU内部 | 108 SM / 卡 | NVLink 内部总线 | SM↔SM: 极高带宽 | SM调度、显存分配 |
| 单节点（8卡） | 8 GPU | NVLink + NVSwitch | 600GB/s（NVLink 3.0） | 节点内GPU亲和性调度 |
| 机架（Rack） | 4~8 节点 | InfiniBand HDR/NDR | 200~400Gb/s | 机架内拓扑感知 |
| Pod/超节点 | 32~64 节点 | Fat-Tree / Dragonfly | 跨机架延迟 ~1-2μs | 分区调度、网络隔离 |
| 集群 | 数百~数千节点 | 多层网络架构 | 跨Pod延迟 ~5-10μs | 全局资源池、配额管理 |
在集群资源管理系统中，GPU被视为可分配的计算资源单元，通常以“卡”为最小粒度进行调度。但现代调度器（如Kubernetes + Device Plugin、Slurm + GPU插件）已经支持更细粒度的分配：MIG（Multi-Instance GPU）可以将A100/H100切分为最多7个实例，每个实例拥有独立的SM和显存切片；显存虚拟化则允许按GB粒度分配显存，但计算资源仍共享。
2.3 资源管理基本概念：分配、隔离与碎片
资源管理的核心目标是将物理GPU资源抽象为可调度、可隔离、可回收的逻辑资源池。以下是必须掌握的关键概念：
- 资源抽象：将GPU的SM数、显存容量、显存带宽、NVLink带宽等物理属性抽象为可量化的资源指标。例如，一个“GPU资源单元”可以定义为“1卡 + 40GB显存 + 全部SM”。
- 资源分配：调度器根据任务需求（如“需要2卡，每卡16GB显存”）从资源池中寻找满足条件的空闲GPU或GPU切片，并建立独占或共享的绑定关系。
- 资源隔离：确保多个任务之间互不干扰。硬件层面依赖MIG、PCIe ACS、显存保护；软件层面依赖CUDA Context隔离、显存分配器隔离、cgroup限制。
- 资源碎片：当资源池中的空闲资源无法满足任何等待任务的完整需求时，这些零散资源即为碎片。碎片分为卡间碎片（多卡任务无法找到连续空闲卡）和卡内碎片（单卡剩余显存或SM不足）。
- 资源配额（Quota）：为不同团队或项目设定的资源使用上限，配额管理不当会加剧碎片化——例如某团队配额剩余2卡但任务需要4卡，这2卡对其他团队不可见。
核心公式：碎片率 = 1 −（可被任务利用的空闲资源 / 总空闲资源）。当碎片率超过30%时，集群的有效吞吐会显著下降，即使GPU平均利用率看似很高。
2.4 典型场景：多租户集群中的资源分配冲突
假设一个集群拥有32台8卡A100节点（共256卡），运行着三个团队的任务：
团队A：8个训练任务，每个需要4卡 + 40GB显存/卡
团队B：16个推理任务，每个需要1卡 + 8GB显存/卡
团队C：4个实验任务，每个需要2卡 + 80GB显存/卡（需整卡）如果调度器采用“整卡分配”策略，团队B的16个推理任务会占用16张整卡，每张卡仅使用8GB/80GB显存，造成72GB × 16 = 1.15TB显存浪费。如果采用MIG切片，可以将每张A100切分为1个40GB实例 + 4个10GB实例，但MIG切片数量有限（最多7个），且切片边界固定，无法灵活匹配8GB需求。
更复杂的情况是拓扑约束：团队A的4卡任务要求4张卡位于同一节点（NVLink互联），如果节点上已有2张卡被团队B的推理任务占用，剩余6张卡虽然总数足够，但无法满足“4卡同节点”的约束，导致这6张卡成为“拓扑碎片”。
常见误区：仅关注GPU利用率的百分比，而忽略碎片化。例如集群GPU利用率达到85%，但实际只有60%的显存被有效使用，且大量任务在排队等待“恰好合适”的资源组合。利用率高 ≠ 碎片少，必须同时监控“可调度率”和“资源匹配率”。
2.5 资源管理工具链与调度策略
当前主流的GPU集群资源管理工具包括：
- Slurm + GPU插件：支持整卡分配、MIG感知调度、节点拓扑约束（
--gpus-per-node、--constraint）。 - Kubernetes + NVIDIA Device Plugin：将GPU作为可扩展资源（
nvidia.com/gpu），支持MIG实例暴露、显存配额（通过nvidia.com/gpu.memory）。 - Volcano / Ray：面向AI作业的调度器，支持gang scheduling（同时调度一组GPU）和队列优先级。
- NVIDIA DCGM（数据中心GPU管理器）：提供细粒度的GPU监控指标，包括SM利用率、显存利用率、温度、功耗，用于碎片检测。
调度策略上，最佳适配（Best-Fit）算法优先选择剩余资源最少的GPU，以减少碎片；最差适配（Worst-Fit）则相反，优先选择资源最多的GPU，以保持大块连续空闲。实际生产环境通常采用混合策略：对延迟敏感的推理任务使用MIG隔离，对训练任务使用整卡或NVLink域感知调度。
2.6 复盘：资源碎片化的早期信号
在集群运维中，以下指标异常往往预示着碎片化正在加剧：
| 指标 | 正常范围 | 碎片化信号 | 建议动作 |
|---|---|---|---|
| GPU平均利用率 | 70-90% | >90% 但任务排队严重 | 检查资源匹配率 |
| 显存平均利用率 | 60-85% | <50% 且GPU利用率高 | 启用MIG或显存超分 |
| 任务排队时间 | <5分钟 | 超过30分钟 | 分析等待资源的具体需求 |
| 节点内GPU分配离散度 | 均匀分布 | 部分节点满载、部分节点空闲 | 调整拓扑感知策略 |
| 资源预留/超卖比例 | 预留<20% | 预留超过40% | 回收闲置预留资源 |