AI 基准 —— MLPerf、cuBLAS、nvbandwidth、NCCL-tests、NeMo 烧机

GPU 集群和传统 HPC 集群的验收哲学不同：HPC 看 HPL 一个数字，AI 集群看的是算力 + 显存 + 互联 + 集合通信 + 真实训练 token/s 一连串数字。本文按 NVIDIA SA 实战视角串完。

AI 集群验收三阶段

graph TB
  S1[1. 节点级
HPL, HPL-MxP
nvbandwidth
cublasMatmulBench
DCGM diag]
  S2[2. 机柜/Pod 级
nccl-tests
SHARP 验证]
  S3[3. 应用级
NeMo / Megatron 真训练
token/sec]
  S1 --> S2 --> S3

每一阶段都不能跳——单卡过了不代表机柜过；机柜过了不代表大模型训练 MFU 达标。

第 1 阶段（节点级）

nvbandwidth —— H2D / D2H / D2D 带宽

nvbandwidth 是 NVIDIA 官方的 GPU 带宽测试工具。

1
2
3
4
5
6
# 编译（需要 boost）
cmake .
make -j $(nproc)

# 列出所有 case
./nvbandwidth -h

两种执行单元：CE vs SM

Copy Engine (CE)：

1
2
3
4
5
6
7
CE 是 GPU 内部的 DMA（Direct Memory Access）引擎，独立于 SM
当 CPU/GPU 发起 CE 拷贝时，向 DMA 控制器发一组描述符
（源地址、目的地址、数据大小），DMA 接管 PCIe / NVLink 总线和显存控制器，直接搬比特流
仅搬数据，不能做计算或格式转换；数量、吞吐硬件 fix

cudaMemcpy / cudaMemcpyAsync 通常底层就用 CE
CE 测出来的数值是 NVLink 理论的 ~80% 即合格

Streaming Multiprocessor (SM)：

1
2
3
4
5
6
7
8
9
10
SM 是流式多处理器（含 CUDA Core、寄存器、shared memory、Load/Store）
SM 拷贝是把搬运当成 CUDA Kernel 跑
GPU 启动成千上万线程，每线程负责一小块数据
线程通过 PTX 的 LD/ST 指令搬数据
极依赖内存合并（Memory Coalescing）：一个 Warp 32 线程同时访连续地址
显存控制器会合并成 128 字节宽事务，打满 HBM 带宽

SM 在做带宽测试时显然干不了别的（计算）
SM 效率会更低，~75-80% 算合理
典型地，CE 比 SM 效率高（CE 是专用 DMA 硬件）

使用模式

1
2
3
4
5
6
7
8
9
# 列出所有测试
./nvbandwidth -t list

# 跑 host-to-device、device-to-host、device-to-device 全套
./nvbandwidth -t 0,1,2,3

# 只跑特定测试
./nvbandwidth -t host_to_device_memcpy_ce
./nvbandwidth -t device_to_device_memcpy_write_sm

期望数值

1
2
3
4
5
6
7
H100 SXM5 单卡：
  H2D PCIe Gen5 x16：  ~52 GB/s（理论 64）
  D2H PCIe Gen5 x16：  ~52 GB/s
  D2D NVLink 4 双向：  ~720 GB/s（理论 900）

B200 SXM5 单卡：
  D2D NVLink 5 双向：  ~1500 GB/s（理论 1800）

低于上述 80% 一般是 PCIe lane / NVLink 链路问题。

GEMM 算力测试

测算力 = 测 GEMM（General Matrix Multiply）—— 几乎所有 AI workload 的基础原语。

关键调优要点

1
2
3
4
5
6
7
8
锁频：测试前必须 nvidia-smi -lgc <clock> 锁 GPU 频率
      否则 GPU Boost 会抖动，无法横向对比

Warmup：所有工具计时前必须预热（空跑几圈）
        否则第一次包含 PTX JIT 编译或库加载时间，数据不准

矩阵尺寸：要测出峰值算力，M, N, K 必须足够大（4096+）
         且最好是 8 或 16 倍数（Tensor Core 对齐）

工具家族

cublasMatmulBench（NVIDIA 内部 / NDA 工具，集成在 benchmark guide）：

1
2
3
4
5
6
7
8
9
10
# INT8
cublasMatmulBench -P=bisb_imma -m=8192 -n=3456 -k=16384 -T=1000 -ta=1 -B=0
# FP16
cublasMatmulBench -P=hsh -m=12288 -n=9216 -k=32768 -T=1000 -tb=1 -B=0
# TF32
cublasMatmulBench -P=sss_fast_tf32 -m=8192 -n=3456 -k=16384 -T=1000 -ta=1 -B=0
# FP32
cublasMatmulBench -P=ddd -m=3456 -n=2048 -k=16384 -T=1000 -tb=1 -B=0
# FP64
cublasMatmulBench -P=sss -m=3456 -n=2048 -k=16384 -T=1000 -tb=1 -B=0

GEMM CublasLt —— 公开 Python 版：

1
https://github.com/Azure/AI-benchmarking-guide/blob/main/Benchmarks/NVIDIA/GEMMCublasLt.py

batchBLAS —— CUDA Samples 自带：

1
cuda_samples / 4_CUDA_Libraries / batchCUBLAS

MAMF Finder（开源）：

1
2
https://github.com/stas00/ml-engineering/blob/master/compute/accelerator/benchmarks/mamf-finder.py
帮你找出最高 achievable GEMM 算力（"Maximum Achievable Matmul FLOPS"）

期望算力（dense throughput）

1
2
3
4
5
6
7
8
9
10
11
H100 SXM5：
  FP8：     3958 TFLOPS dense
  FP16/BF16： 1979 TFLOPS dense
  TF32：    989 TFLOPS dense
  FP64：    67 TFLOPS dense

B200 SXM5：
  FP4：     18000 TFLOPS dense
  FP8：     9000 TFLOPS dense
  FP16/BF16： 2250 TFLOPS dense
  FP64：    40 TFLOPS dense

跑出来 ≥ 90% 理论值算合格。低于 80% 排查锁频 / NUMA / cuBLAS 版本。

DCGM diag —— 节点健康自检

NVIDIA DCGM 是 GPU 监控 + 诊断工具：

1
2
3
4
dcgmi diag -r 1   # 快速 (~30s)
dcgmi diag -r 2   # 中等 (~5min)
dcgmi diag -r 3   # 完整（含压力测试，~30min）
dcgmi diag -r 4   # 长时（含 thermal stress, ~1h+）

-r 3 通常够节点初验。-r 4 用于客户怀疑 thermal throttle 时跑长时间压测。

第 2 阶段（机柜 / Pod 级）

NCCL-tests —— 集合通信带宽

NCCL-tests 是事实标准。前一篇已展开测试列表（all_reduce_perf 等）和 algbw / busbw 区别。

NVL72 / 多机不同规模 busbw 基线

1
2
3
4
5
6
7
单机 8 卡 H100 NVLink 4：     AllReduce busbw ~370-400 GB/s
单机 8 卡 B200 NVLink 5：     AllReduce busbw ~700-900 GB/s
NVL72 72 卡 NVLink 5：       AllReduce busbw ~700-900 GB/s
跨节点 H100 + IB NDR 单端口：  ~50 GB/s 量级
跨节点 H100 + IB NDR 双端口：  ~100 GB/s
SuperPOD H100 256-GPU NVLink Network：达到 100+ GB/s
SHARP 启用后大规模 AllReduce：~2× 提升

待补充：完整 NVL72 / NVL576 / DGX SuperPOD 不同 message size 的 busbw 表。

排障思路

1
2
3
4
5
1. NCCL_DEBUG=INFO 看选了哪个 algorithm + protocol
2. 拓扑：nvidia-smi topo -m 看 NVLink / PCIe / SYS 矩阵
3. 网络：nccl-tests 加 -x NCCL_IB_HCA=mlx5_0,mlx5_1 显式指定
4. SHARP：NCCL_COLLNET_ENABLE=1
5. P2P：NCCL_P2P_LEVEL 控制是否走 P2P / 强制走 NIC

ClusterKit —— SuperPOD 验收快速 sanity check

NVIDIA HPC-X 自带的集群验证工具集：

1
2
3
4
clusterkit 主入口
单对 / 全对 latency-bandwidth
GPU↔GPU、CPU↔GPU 多组合
报告生成与 baseline 比对

ClusterKit 是 SuperPOD 验收里”几分钟出全图”的工具，比手工拼 nccl-tests 高效。

完整使用示例多在 Partner / NVIDIA 内部 RA，等待补充。

MLPerf

MLCommons MLPerf 是行业内 NVIDIA / Google / Intel / AMD 加速器对比的标准入口。

主要类别：

1
2
3
4
5
6
MLPerf Training      — pretraining / fine-tuning
MLPerf Inference     — Datacenter / Edge
MLPerf HPC           — 科学计算
MLPerf Storage       — 存储吞吐
MLPerf Power         — 能效
MLPerf Client/Mobile/Tiny — 端侧

NVIDIA 通常以 DGX / HGX / GB200 系统提交：

1
2
详细工程报告：     NVIDIA blog 与 GitHub repo nvidia/MLPerf*
复现工件：         NeMo / Megatron / TensorRT-LLM 等

待补充：跟踪最新一轮 MLPerf Training/Inference 中 NVIDIA 的 SoTA 数字。

怎么读 MLPerf 结果

1
2
3
4
5
Closed Division：    严格规则，能直接横比
Open Division：      开放优化，看创新方向
"提交规模"：         看 GPU 数（8 / 64 / 1024 / 11000+）
"模型 / 任务"：       Llama-2 70B, GPT-3 175B, BERT, ResNet-50, RNN-T, Stable Diffusion ...
"指标"：             Training time-to-train（分钟）/ Inference QPS、samples/sec

NVIDIA 几乎每轮都是榜首——这是 NVIDIA 卖 GPU 的”市场背书”。但 SoTA 数字基于”DGX SuperPOD 万卡级 + 整套 SW stack”——客户实际能不能复现要看自己软硬件配置。

第 3 阶段（应用级）

NeMo / Megatron Burn-in 烧机

集群级烧机测试通常用 NeMo / Megatron 跑真实 training step 数小时～数十小时，监控：

1
2
3
4
Tokens/sec 稳定性
GPU / HBM 温度
链路 down / NCCL timeout
训练 loss 曲线是否平滑

关键监控

1
2
3
DCGM Exporter → Prometheus → Grafana
NetQ / UFM 链路 telemetry
SLURM / Run:ai 任务日志

典型烧机配置

1
2
3
4
5
6
模型：           Llama-2 70B / GPT-3 175B / Llama-3 8B（轻量）
数据集：         合成数据或 C4 子集
精度：           BF16 + FP8 (TE)
batch / seq：    跟 NVIDIA reference recipe
并行：           TP=8 + PP=8 + DP=N（按集群规模）
时长：           24h（短）/ 72h（中）/ 7 天（长）

标准烧机时长 / 阈值多来自 RA，等待补充。

通过标准

1
2
3
4
5
6
Tokens/sec：     稳定（< 5% 抖动）
loss 曲线：      平滑下降，无 NaN / Inf
GPU 温度：       < 85°C 持续
HBM 温度：       < 95°C 持续
NCCL timeout：  0 次
节点重启：       0 次

任何一项失败 → 排查节点 / 链路 / 散热，整改后重测。

vLLM / TensorRT-LLM 推理验收

1
2
3
4
5
6
# vLLM 自带 benchmark
python -m vllm.entrypoints.openai.api_server --model meta-llama/Llama-3-70B
python benchmark_serving.py --num-prompts 1000 --request-rate 10

# TensorRT-LLM perf
trtllm-bench --model_path /path/to/llama3 --max_batch_size 32 throughput
1
2
3
4
5
6
观察：
  P50 / P99 TTFT（Time To First Token）
  P50 / P99 TPOT（Time Per Output Token）
  Throughput（tokens/sec）
  GPU 利用率（nvidia-smi dmon）
  HBM 占用

不同模型 / 量化 / 序列长度组合下数字差很多——验收前先和客户对齐”业务侧 SLA”，再选基线。

一张验收表

阶段 工具 通过标准
节点 DCGM diag -r 3 All PASS
节点 nvbandwidth NVLink ≥ 80% 理论
节点 cublasMatmulBench FP8/FP16 ≥ 90% peak
节点 HPL 效率 70-80%
节点 HPL-MxP Tensor Core 跑出
机柜 nccl-tests all_reduce busbw 符合基线
机柜 nccl-tests alltoall MoE 路径 OK
机柜 SHARP 启用 大消息 ~2× 提升
应用 NeMo / Megatron 24h+ tokens/sec 稳 / loss 平
应用 vLLM / TRT-LLM TTFT/TPOT 满足 SLA

为什么不能跳阶段

1
2
3
4
5
6
7
8
9
10
11
跳节点 → 集群：
  单卡有 thermal throttle，集群表现像"扩展性差"
  排查时 N×N 排错，浪费几天
  
跳机柜 → 应用：
  AllReduce busbw 不达标，但训练能跑（只是 MFU 低）
  → 客户拿到集群训练 MFU 30%，怀疑硬件
  → 实际是网络 ~30% 折损
  → 排查极困难
  
所以三阶段必须按顺序跑过

一些坑

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
1. 锁频忘了：
   GPU Boost 让单次 GEMM 跑出 110% 理论
   → 多次跑分波动 10%+
   
2. NUMA 没绑：
   nvidia-smi topo -m 显示 GPU 0 应该在 numa node 0
   实际 mpirun 把进程跑到 numa node 1
   → 跨 socket 链路加 30-50% 延迟
   
3. PCIe 降速：
   nvidia-smi 查"GPU Link Width"应该是 16x，"Link Generation"应该是 5
   实际 5 → 3，链路问题，需要重新插或换板
   
4. 容器版本不对：
   NVIDIA hpc-benchmarks 容器有不同版本（24.06 / 24.09 / 24.12）
   大模型测试要 PyTorch + CUDA + cuDNN + NCCL 全套版本对齐
   → 不对齐有时候慢一倍
   
5. 客户拿走 baseline 自己跑出来不一致：
   客户没跑 nvidia-smi -lgc 锁频
   客户用了不同 BIOS / Power Profile
   客户驱动版本不一致
   → 一定要把 reproduce 文档写细

小结

  • AI 集群验收三阶段：节点 → 机柜 → 应用，缺一不可
  • 节点级：nvbandwidth + cublasMatmulBench + DCGM diag + HPL
  • 机柜级：nccl-tests（busbw）+ ClusterKit + SHARP 验证
  • 应用级：NeMo/Megatron 24h+ burn-in + vLLM/TRT-LLM 推理 SLA
  • MLPerf 是行业标尺，看 SoTA 但客户复现要慎重
  • 锁频、NUMA、PCIe、版本是四大坑

下一篇讲服务器认证体系——CCC、CE、FCC、能效之星、NVIDIA-Certified。