3. GPU硬件架构与性能模型
聊到AI训练性能监控，绕不开GPU硬件。很多同学上来就调batch size、改学习率，结果发现性能瓶颈根本不在算法层面。我个人习惯是，拿到一个训练任务，先看硬件在干什么。说白了，你得知道GPU的“肌肉”长什么样，才能知道它什么时候在“用力”，什么时候在“摸鱼”。
3.1 NVIDIA GPU架构概览：从Volta到Hopper
这几年NVIDIA的架构迭代很快。从Volta（V100）到Turing（T4/RTX 2080），再到Ampere（A100/RTX 3090），然后是Hopper（H100）。每一代都在强化矩阵运算和显存带宽。
我印象最深的是从V100换到A100那次。同样的模型，训练时间直接砍半。为什么？因为A100的Tensor Core支持了更灵活的精度混合，而且显存带宽从900 GB/s飙到了2 TB/s。你想想看，数据搬运快了，计算单元才能吃饱。
核心变化点：
- SM（流式多处理器）数量增加：V100有80个SM，A100有108个，H100有132个。
- Tensor Core升级：从第一代到第四代，支持的数据类型越来越多（FP16、BF16、TF32、FP8）。
- 显存带宽翻倍：H100的HBM3带宽达到了3.35 TB/s。
关键认知：GPU不是“单核巨无霸”，而是“多核蚂蚁军团”。每个SM就是一个独立的小处理器，能同时跑几百个线程。性能优化的本质，就是让这些“蚂蚁”别闲着。
3.2 SM与Tensor Core：计算核心的微观世界
SM是GPU的基本计算单元。每个SM内部包含：
- CUDA Core：负责标量运算（加减乘除、逻辑判断）。
- Tensor Core：专门做矩阵乘加运算（D = A × B + C）。
- 共享内存（Shared Memory）：SM内部的高速缓存，延迟极低。
- 寄存器文件（Register File）：每个线程私有的“小本本”，容量有限但速度最快。
Tensor Core是AI训练的“核武器”。为什么？因为神经网络里90%以上的计算量是矩阵乘法。Tensor Core一个时钟周期能完成4×4矩阵的乘加，而CUDA Core需要多个周期。我在项目中遇到过，把FP32的卷积换成TF32精度，速度提升了2.5倍，精度损失几乎为零。
实战技巧：用nvidia-smi看GPU利用率时，如果Volatile GPU-Util在90%以上，但训练速度还是慢，别急着加batch size。先看看Tensor Core有没有被用上。用nsys profile抓一下kernel，如果看到大量volta_fp16_s884gemm之类的名字，说明Tensor Core在干活。
3.3 内存层次结构：数据搬运的艺术
GPU的内存层次，说白了就是“越近越快，越远越慢，但容量也越大”。理解这个，你才能看懂为什么某些操作会成为瓶颈。
| 层级 | 容量 | 带宽 | 延迟 | 作用 |
|---|---|---|---|---|
| 寄存器 | ~256 KB / SM | ~20 TB/s | ~1 cycle | 线程私有变量 |
| 共享内存 | ~48-164 KB / SM | ~10 TB/s | ~20 cycles | 线程块内数据共享 |
| L1缓存 | ~128-256 KB / SM | ~5 TB/s | ~30 cycles | 数据局部性缓存 |
| L2缓存 | ~40 MB（A100） | ~2 TB/s | ~200 cycles | 跨SM数据共享 |
| HBM显存 | ~40-80 GB | ~2 TB/s（A100） | ~400 cycles | 主存储 |
嗯，这里要注意。很多同学写CUDA kernel时，喜欢直接从显存取数据。结果就是SM在“等数据”，利用率上不去。我曾经调试过一个模型，发现L2缓存命中率只有30%，大量时间花在访存上。后来把数据分块，用共享内存做中间缓存，训练速度直接提升了40%。
避坑指南：我曾经在调优一个Transformer模型时，发现显存带宽利用率只有60%。查了半天，原来是数据在HBM中的存储布局不对，导致访存不连续。GPU喜欢“连续读取”，你跳着读，它就慢。所以数据预处理时，尽量保证内存布局是NHWC（通道在后）而不是NCHW（通道在前），对带宽利用率更友好。
3.4 Roofline模型：一眼看出瓶颈在哪
Roofline模型是我做性能分析时最常用的工具。它把性能问题分成两类：
- 计算受限（Compute Bound）：计算单元在忙，但数据搬运跟不上。
- 访存受限（Memory Bound）：数据搬运很快，但计算单元在等数据。
怎么判断？看一个指标：算术强度（Arithmetic Intensity）。它等于“总计算量（FLOPs）”除以“总访存量（Bytes）”。
举个例子：一个矩阵乘法（M×K × K×N），计算量是2×M×N×K FLOPs，访存量是(M×K + K×N + M×N) Bytes。如果M=N=K=1024，算术强度大约是512 FLOPs/Byte。而A100的峰值计算是312 TFLOPS（FP16），带宽是2 TB/s。那么“计算上限”就是312 TFLOPS，“访存上限”是2 TB/s × 算术强度。如果算术强度低于某个阈值（约156 FLOPs/Byte），就是访存受限。
核心公式：
实际性能 = min(峰值计算性能, 峰值带宽 × 算术强度)
当算术强度低时，性能被带宽卡住；当算术强度高时，性能被计算卡住。
我习惯在训练前先跑一个profiling，算出每个算子的算术强度。如果发现某个算子的算术强度只有10 FLOPs/Byte，那它大概率是访存瓶颈。这时候别想着优化计算，而是该考虑：能不能合并访存？能不能用更小的精度？能不能用Tensor Core一次处理更多数据？
下面这张图是我自己总结的Roofline模型结构，帮你快速定位瓶颈：
你看这张图，横轴是算术强度，纵轴是性能。红色虚线是计算上限，蓝色斜线是访存上限。实际性能（绿色曲线）永远在这两条线之下。拐点就是“平衡点”——算术强度高于它，就是计算受限；低于它，就是访存受限。
我每次做性能诊断，都会把关键算子标在这张图上。如果某个点落在访存受限区，我就去优化数据布局、合并访存。如果落在计算受限区，我就考虑用Tensor Core、降低精度。说白了，Roofline模型就是一张“地图”，告诉你该往哪个方向走。
实用工具：NVIDIA的Nsight Compute自带Roofline分析功能。你跑完profiling，它会自动画出每个kernel的Roofline位置。我建议你养成习惯，每次调优前先看一眼这个图，比瞎调参数高效得多。
好了，这一章的内容就到这里。GPU硬件架构和Roofline模型是性能监控的“内功心法”。理解了这些，你再看nvidia-smi的输出，就不会只盯着“利用率”这一个数字了。你会知道：SM在忙什么？Tensor Core有没有干活？数据搬运是不是瓶颈？