GPU利用率背后的真相：避免被商家100%数据误导

对致力于人工智能技术研发的团队而言，我们强烈推荐在管理GPU集群时同步监测SM效率与GPU利用率。SM效率能够更精确地反映GPU实际计算效能，而GPU利用率则主要体现系统是否处于空闲状态。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

原文链接：https://www.trainy.ai/blog/gpu-utilization-misleading

前言

在机器学习项目中，评估GPU运行状态时最常见的指标就是GPU利用率，这个数值一般通过终端执行nvidia-smi命令获取。众多系统监控工具也普遍将GPU利用率作为核心性能参数。然而，这一指标往往不能全面反映GPU的实际运算能力。事实上，单纯执行内存读写操作而不涉及任何数学计算，也能让GPU利用率达到100%。本文将剖析这一局限性背后的成因，并分享我们在探索过程中获得的关键见解。

我们已实施了PyTorch性能优化指南中列举的绝大多数改进方案，具体包括：

• 通过调整数据加载器参数（如num_workers、batch_size、pin_memory、prefetch_factor等）充分释放GPU潜能
• 采用混合精度训练（FP16或BF16）最大化TensorCore使用效能
• 运用Apex或DeepSpeed等框架中的融合优化器（如FusedAdam或FusedAdamW）
• 选用专为训练任务设计的计算实例与网络架构（如H100 SXM或A100 SXM），并优先选择新一代硬件平台（H100 > A100 > V100）

这些看似简单的调整使我们同时实现了100%的GPU利用率和显著的功耗表现，这无疑是个良好的开端。为了判断是否存在进一步优化的空间，我们计算了训练负载的模型FLOPS利用率（MFU）。

简要回顾：MFU（模型FLOPS利用率）是评估GPU性能的重要指标之一，由Google的PaLM论文率先引入。它定义为“观测到的计算吞吐量（每秒执行的指令数量）相对于系统在峰值FLOPs下运行的理论最大吞吐量的比率”。简而言之，这个指标量化了工作负载每秒执行的浮点运算数相对于GPU最大理论计算能力的比例。其主要不足之处在于计算过程相对复杂，需要依赖具体的模型参数和框架实现。

令人遗憾的是，该训练过程仅达到了约20%的MFU。作为参照，当前主流的大语言模型训练通常能达到35%-45%的MFU水平。这就引出了一个核心问题：为什么在GPU利用率达到100%的同时，我们仅利用了GPU理论计算峰值20%的性能？

要解答这个性能差异，需要深入理解GPU利用率的实际含义。

GPU利用率究竟是什么？

NVIDIA官方文档对GPU利用率的定义较为含糊：“报告GPU计算资源和内存接口的当前使用率”。

Datadog的NVML技术文档提供了更精准的解释：“在过去的采样周期内，一个或多个内核在GPU上执行的时间百分比”。要理解这个定义为何具有误导性，我们需要简要了解GPU的工作原理。

GPU由众多核心和多组处理器构成。在NVIDIA架构中，这些处理器称为流多处理器（SM）；在AMD硬件中则称为计算单元（CU）。下图展示了包含144个SM的GH100 GPU架构。

这些多处理器可以视为监督一组工作核心的“工头”。当启动CUDA内核时，工作负载会由一个或多个SM在CUDA核心上执行。如下图所示，GH100芯片上的单个SM包含众多CUDA核心。

因此，GPU利用率仅仅指示在给定时刻是否有内核正在执行。它既无法反映内核是否充分利用了所有可用核心，也不能体现工作负载是否最大化发挥了GPU的并行计算能力。在极端情况下，仅通过内存操作无需任何数学计算即可实现100%利用率，而此时实际FLOPs为零。

回到我们的核心问题，这个定义恰好解释了GPU利用率与MFU百分比之间的差距！显然仍有大量性能潜力未被发掘，我们的任务就是找到这些优化空间。

深入挖掘

下一步是对模型训练循环进行性能剖析。我们使用PyTorch Profiler工具获得了更深入的洞察。

如下所示，Softmax内核显示出高GPU利用率但SM效率较低的特征。这立即触发了警报，因为Softmax实现是LLM中著名的性能瓶颈，具有内存绑定的特性。众多内核融合技术（如FlashAttention）正是为此而开发，旨在缓解这一问题。较低的SM效率指标暗示模型执行存在潜在低效环节。

SM效率代表什么？

SM效率（也称SM活跃度）是NVIDIA GPU上的重要指标，描述在给定时间间隔内活跃SM的百分比。如前所述，SM负责监督一组CUDA核心。例如，NVIDIA H100 GPU拥有132个SM，每个SM包含128个核心，总计16,896个计算核心。通过监测SM效率，我们可以评估CUDA内核是否有效利用了流多处理器。举例来说，如果一个内核持续运行10秒但仅使用1个SM，在H100上将报告100%利用率，但SM效率仅为1/132≈0.7%。

这正是我们需要的指标！通过逐层监测SM效率，我们能够确定优化潜力最大的低垂果实。

实施优化

在识别出利用率不足的内核后，我们着手优化相关层级。由于这是基于Transformer的架构，大部分收益来自于融合Transformer块内的操作。下图总结了我们应用的优化方案。

融合是指用单个GPU内核（通过CUDA或Triton实现）替换PyTorch原生多层定义，将所有操作整合到一个内核中。加速源于某些层（如Softmax）在内存访问上花费的时间超过计算时间；融合减少了这些开销。FlashAttention就是此类融合内核的典范。其他需要融合的内核包括MLP、dropout、层归一化和残差加法操作。

我们并未自行编写这些内核。大多数已在FlashAttention等库中实现，这些库提供nn.Module形式，无需从零创建自定义torch.autograd.Function。此外，这些实现通常经过硬件优化，不仅速度更快，还能降低内存使用。

主要挑战在于定位并替换代码中的相应层。虽然torch.compile试图自动化处理，但截至本文撰写时，它与FSDP等高级分布式策略兼容性欠佳，且由于图断裂问题，实际加速效果有限。未来编译器或许能自动完成此过程，但目前仍需手动集成融合实现。

成果显著：训练时间缩短4倍，MFU从初始的20%提升至38%。这些改进主要源自内核融合，并辅以根据模型规模和可用3.2 Tbps Infiniband网络选择合适的模型并行级别。

结论

我们强烈建议AI团队在管理GPU集群时同步监测SM效率和GPU利用率。SM效率提供了更准确的GPU计算效能表征，而GPU利用率主要指示系统是否空闲。当然，计算MFU也很有价值，但不适合持续性的逐层监测。NVIDIA DCGM（数据中心GPU管理器）默认包含SM活跃度指标。

还有更细粒度的指标，如SM占用率（PyTorch Profiler中的Achieved Occupancy），可洞察每个SM的工作负载。但理解这些指标不如最大化SM效率直观。如需深入了解，建议参详PyTorch Profiler博客、DCGM文档、Nsight内核剖析指南以及Nsight技术文档。