📚 课程目录第4章性能分析工具链

4. 性能分析工具链

聊到AI训练的性能分析，我见过不少团队一上来就调batch size、改学习率，折腾半天发现瓶颈根本不在模型上。说白了，你得先搞清楚“时间都去哪儿了”，才能对症下药。这一章，我就带你捋一遍我平时最常用的几个工具——从系统级到算子级，一层层往下挖。

核心思路：性能分析不是玄学，而是一个“由粗到细”的排查过程。先看硬件利用率，再看框架开销，最后定位到具体算子。

4.1 系统级监控：nvidia-smi 与 nvtop

这两个工具，我习惯把它们当成“体检仪”。训练跑起来，第一件事就是看看GPU在干嘛。

4.1.1 nvidia-smi：最基础的“听诊器”

nvidia-smi 是NVIDIA官方自带的命令行工具。你只要在终端敲一下，就能看到GPU的实时状态。

# 实时监控，每秒刷新一次
watch -n 1 nvidia-smi

# 查看更详细的GPU进程信息
nvidia-smi pmon -s u -d 1

我个人习惯重点关注这几个指标：

GPU-Util：计算核心利用率。如果低于80%，说明GPU在“等饭吃”。
Memory-Usage：显存占用。爆显存是训练崩溃的头号杀手。
Volatile GPU-Util：这个值跳动很大，别只看瞬间值，要看趋势。

注意：GPU-Util 高不代表效率高。我曾经遇到过GPU-Util 99%，但实际吞吐量很低的情况——后来发现是数据加载线程卡住了，GPU一直在空转等待。

4.1.2 nvtop：GPU版的“htop”

nvtop 是个第三方工具，界面比 nvidia-smi 友好得多。它用彩色图表展示每个GPU核心、显存、PCIe带宽的使用情况。

# 安装（Ubuntu）
sudo apt install nvtop

# 运行
nvtop

嗯，这里要注意：nvtop 依赖 libdrm 和 ncurses，有些老系统可能需要手动编译。我建议你直接装最新版，不然图表显示可能不全。

用 nvtop 你能直观看到：

哪个进程在吃显存
PCIe 传输是否成为瓶颈（带宽利用率持续>80%就要警惕）
GPU 温度与功耗——降频往往从温度过高开始

4.2 框架级分析：PyTorch Profiler

系统级工具只能告诉你“GPU忙不忙”，但说不清“为什么忙”。这时候就该 PyTorch Profiler 上场了。

4.2.1 基本用法

PyTorch 自带的 profiler 可以记录每个操作的耗时、显存分配、CUDA kernel 启动情况。

import torch
from torch.profiler import profile, record_function, ProfilerActivity

with profile(
    activities=[ProfilerActivity.CPU, ProfilerActivity.CUDA],
    record_shapes=True,
    profile_memory=True,
    with_stack=True
) as prof:
    with record_function("model_inference"):
        output = model(input_tensor)
        loss = loss_fn(output, target)
        loss.backward()

# 打印按时间排序的表格
print(prof.key_averages().table(sort_by="cuda_time_total", row_limit=20))

# 导出为 Chrome trace 格式
prof.export_chrome_trace("trace.json")

小技巧：导出的 trace.json 可以用 Chrome 浏览器打开 chrome://tracing 来可视化。你能看到每个算子在时间轴上的起止位置，一眼就能发现“空档期”。

4.2.2 我常用的分析套路

拿到 profiler 输出后，我一般按这个顺序排查：

看 CPU 耗时 vs CUDA 耗时：如果 CPU 耗时远大于 CUDA 耗时，说明数据预处理或 Python 开销是瓶颈。
看显存分配次数：频繁的 tensor 创建和销毁会触发大量内存分配，拖慢速度。我建议用 torch.cuda.empty_cache() 只在必要时调用。
看 kernel 启动密度：如果每个 kernel 都很小（比如 1-2 微秒），说明算子融合不够，可以考虑用 torch.jit.script 或 torch.compile。

避坑指南：我曾经在 profiler 里看到一个叫 aten::copy_ 的操作占了 30% 的时间。查了半天，发现是模型里有个 .cpu() 调用，把 tensor 从 GPU 拷回了 CPU。去掉之后，训练速度直接翻倍。

4.3 深度诊断：Nsight Systems 与 Nsight Compute

PyTorch Profiler 能解决大部分问题，但遇到“玄学”性能问题时，就得请出 NVIDIA 的官方神器了。

4.3.1 Nsight Systems：系统级时间线分析

Nsight Systems 能捕获整个训练过程的完整时间线，包括 CPU 线程、GPU 流、CUDA API 调用、内存操作等。它比 PyTorch Profiler 更底层，能看到驱动和硬件层面的行为。

# 命令行采集
nsys profile -o my_trace -t cuda,nvtx,osrt python train.py

# 图形界面查看
nsys-ui my_trace.qdrep

我个人最喜欢它的“GPU 流视图”。你能看到每个 CUDA stream 上 kernel 的执行情况。如果发现某个 stream 长时间空闲，而另一个 stream 在排队，说明并行度没用好。

4.3.2 Nsight Compute：算子级微观分析

当 Nsight Systems 告诉你某个 kernel 是热点，但你不清楚它为什么慢时，就用 Nsight Compute 去“解剖”它。

# 对指定 kernel 做详细分析
ncu --kernel-name "my_kernel" --set full -o kernel_report python train.py

它会告诉你：

计算吞吐量：是否达到了硬件理论峰值？
内存带宽利用率：是计算密集还是访存密集？
warp 占用率：SM 上同时活跃的 warp 数量，太低说明资源受限。
指令重放：bank conflict 或 shared memory 访问模式不佳会导致指令重放，白白浪费周期。

注意：Nsight Compute 的分析会显著拖慢程序运行速度（可能慢 10-100 倍）。我建议只对单个 step 或单个 kernel 做分析，别对整个训练过程跑。

4.4 工具链协同：一张图看懂排查流程

这么多工具，什么时候用哪个？我画了张图，帮你理清思路。

你看，这个流程是层层递进的。我一般先跑 nvidia-smi 看个大概，如果 GPU 利用率低，就用 PyTorch Profiler 查框架开销。如果发现某个 kernel 特别慢，再上 Nsight Compute 做微观分析。Nsight Systems 则是在前两者都搞不定时，用来查系统级交互问题的“杀手锏”。

我的建议：别一上来就开 Nsight Compute。它就像用显微镜看蚂蚁打架——信息太多反而抓不住重点。先从粗粒度工具入手，逐步缩小范围，这才是高效的做法。

好了，这五个工具的组合拳，基本能覆盖你训练过程中 90% 的性能问题。下次训练跑得慢，别急着调参数，先拿起这些工具“诊断”一下。你会发现，很多问题其实出在你想不到的地方。