GPU集群性能剖析与瓶颈定位 - 第2节

一、性能指标与度量：核心性能指标

聊GPU集群性能，咱们得先搞清楚一件事——你到底该看什么？

我见过不少团队，一上来就盯着GPU利用率看，觉得利用率90%+就万事大吉。结果呢？训练一个模型比预期慢了3倍。为什么？因为利用率高不代表效率高，可能都在等数据呢。

所以，我们先来拆解几个核心指标。我个人习惯把它们分成四类：算力、带宽、延迟、吞吐量。

1.1 算力 TFLOPS

TFLOPS，说白了就是GPU每秒能处理多少万亿次浮点运算。这是GPU的「硬实力」。

但要注意，TFLOPS分两种：

• 峰值算力：理论最大值，厂商宣传用的。比如A100宣称FP16是312 TFLOPS。
• 实际算力：你真正能跑出来的。我测过很多次，实际能到峰值的70%-80%就算不错了。

举个例子。我曾经帮一个团队调优，他们用V100跑BERT，FP16算力利用率只有40%。查了半天，发现是小算子太多，GPU核心频繁切换上下文。后来做了算子融合，利用率直接飙到75%。

1.2 显存带宽

算力再高，数据喂不进去也是白搭。显存带宽就是GPU和显存之间的「高速公路」宽度。

我习惯用一个公式来判断是否瓶颈：

计算时间 vs 数据传输时间

如果 计算时间 < 数据传输时间 → 带宽瓶颈
如果 计算时间 > 数据传输时间 → 算力瓶颈

嗯，这里要注意。很多模型训练慢，不是GPU算不动，而是显存带宽不够，GPU核心在「等数据」。这种现象叫内存墙。

GPU型号	显存带宽	典型瓶颈场景
A100 80GB	2 TB/s	大模型训练（LLM）
V100 32GB	900 GB/s	CNN训练、推理
T4 16GB	320 GB/s	小模型推理、视频处理

我遇到过最典型的案例：一个推荐系统模型，每次迭代计算量很小，但需要频繁读取Embedding表。结果显存带宽成了瓶颈，GPU利用率只有30%。后来换了A100，带宽翻倍，训练速度直接快了1.8倍。

1.3 延迟

延迟，就是一次操作从发出到完成的时间。在GPU场景里，我主要关注两类：

• 计算延迟：一次kernel启动到结束的时间
• 通信延迟：多卡之间数据同步的时间

你想想看，如果通信延迟占了总时间的40%，那你的多卡训练效率能高吗？

1.4 吞吐量

吞吐量是最终用户关心的指标。对于训练来说，就是每秒处理多少样本（samples/sec）。对于推理来说，就是每秒处理多少请求（QPS）。

吞吐量 = 算力 × 利用率 ÷ 每个样本需要的计算量

这个公式看着简单，但实际中利用率很难达到理想值。我见过一个团队，模型推理吞吐量只有理论值的30%。查下来发现是数据预处理太慢，GPU一直在空转。

二、监控工具介绍

指标说完了，怎么拿到这些数据？我常用的工具就三个：nvidia-smi、DCGM、Prometheus。

2.1 nvidia-smi

这是NVIDIA自带的命令行工具，最基础也最常用。我每天上线的第一件事就是跑一下：

nvidia-smi -l 1  # 每秒刷新一次

它能看什么？

• GPU利用率（%）
• 显存使用量
• 温度、功耗
• PCIe带宽

但说实话，nvidia-smi只能看个大概。它显示的「GPU-Util」其实是计算单元忙碌的时间比例，不代表真正的算力利用率。我曾经被这个指标坑过——利用率95%，但实际算力只有50%。

2.2 DCGM

DCGM（Data Center GPU Manager）是NVIDIA为数据中心设计的监控工具。我个人非常推荐，尤其是在集群场景下。

它比nvidia-smi强在哪？

• 支持远程监控
• 可以采集历史数据
• 有健康检查功能
• 支持Prometheus集成

我一般这样用：

# 启动DCGM
dcgmi start

# 查看所有GPU的实时指标
dcgmi dmon -e 1001,1002,1003

DCGM能采集100多个指标，但我常用的就几个：

• 1001：GPU利用率
• 1002：显存利用率
• 1004：温度
• 1005：功耗
• 1009：PCIe读写带宽

2.3 Prometheus + Grafana

这是集群监控的标配。DCGM暴露指标，Prometheus采集存储，Grafana可视化。

我习惯的架构是这样的：

每个节点 → DCGM Exporter → Prometheus → Grafana

DCGM Exporter是NVIDIA官方提供的，直接暴露/metrics接口。Prometheus配置一下就能拉数据。

我曾经帮一个客户搭建过，从部署到出图，大概花了2小时。效果嘛，一眼就能看出哪个节点有瓶颈。

三、性能基准测试方法

工具装好了，怎么测？我有一套标准流程。

3.1 单卡基准测试

先测单卡，排除网络和通信干扰。我用的是NVIDIA官方的cuda-samples：

# 测试算力
./bandwidthTest

# 测试带宽
./simpleP2P

# 测试矩阵乘法性能
./matrixMul

嗯，这里要注意。跑基准测试时，一定要确保GPU没有被其他进程占用。我习惯先跑nvidia-smi确认一下。

3.2 多卡基准测试

多卡测试主要看通信效率。我用NCCL的测试工具：

# 测试AllReduce性能
./all_reduce_perf -b 128M -e 8G -f 2

# 测试P2P带宽
./sendrecv_perf -b 128M -e 8G

我遇到过最离谱的情况：8卡V100，理论通信带宽应该是600 GB/s（NVLink），实际测出来只有200 GB/s。查了半天，发现是PCIe Switch配置有问题。

3.3 端到端模型测试

基准测试通过后，一定要跑真实模型。我一般用这几个：

• ResNet-50：测CNN训练性能
• BERT-Large：测NLP模型性能
• GPT-3 1.3B：测大模型训练性能

每个模型跑10个epoch，记录：

• 平均吞吐量（samples/sec）
• GPU利用率
• 显存峰值
• 通信开销占比

四、知识体系总览

说了这么多，我画了一张图帮你理清思路：

这张图把整个指标体系串起来了。从左到右，从指标到工具再到方法，每一步都有对应的手段。我个人习惯是：先跑基准测试，再看监控数据，最后定位瓶颈。

好了，这一章的内容就到这里。记住一句话：没有测量就没有优化。先把这些指标和工具用起来，你才能知道你的GPU集群到底跑得怎么样。

想要更多资料，联系可可