Nsight Systems深度分析：Trace与Sample模式、CUDA API跟踪、GPU Kernel执行时间线、内存操作分析
说实话，Nsight Systems这个工具，我用了快十年了。从最早的命令行版本，到现在的图形化界面，它一直是我排查GPU性能问题的第一把刀。很多同学问我：「老师，性能分析到底从哪入手？」我的答案永远是——先打开Nsight Systems看一眼。
这一讲，咱们就把它掰开揉碎了讲清楚。不搞花架子，全是实战干货。
Trace模式 vs Sample模式：两种视角
Nsight Systems有两种核心的数据采集模式。我习惯把它们比作「录像」和「拍照」。
- Trace模式（录像）：记录每一个API调用、每一次Kernel启动、每一次内存拷贝。数据量巨大，但细节完整。
- Sample模式（拍照）：每隔一段时间采样一次CPU/GPU的状态。开销小，适合长时间运行的程序。
什么时候用哪个？我个人经验是这样的：
选型建议
- 调试阶段、定位具体瓶颈 → 用Trace模式
- 跑大规模训练、验证整体稳定性 → 用Sample模式
- 先Sample快速扫描，发现问题再用Trace深挖 → 我常用的组合拳
嗯，这里要注意一点。Trace模式如果开得太久，生成的文件可能几十个GB。我曾经有一次跑BERT训练，忘了关Trace，结果磁盘直接爆了……从那以后，我养成了习惯：先预估运行时间，再决定采集时长。
CUDA API跟踪：看穿CPU与GPU的交互
CUDA API跟踪，说白了就是看你的CPU在调用GPU时，到底干了什么。
打开Nsight Systems，在「CUDA API Trace」一栏，你会看到类似这样的时间线：
cudaMalloc → 分配显存
cudaMemcpy → 数据从CPU搬到GPU
cudaLaunchKernel → 启动Kernel
cudaDeviceSynchronize → 等待GPU完成
cudaFree → 释放显存每一行都对应一个API调用，旁边标注了耗时。我一般会先看两个指标：
- API调用频率：是不是频繁调用cudaMalloc/cudaFree？如果是，说明有内存泄漏或者分配策略不合理。
- 同步等待时间：cudaDeviceSynchronize是不是占了很大比例？如果是，说明GPU在等CPU，或者CPU在等GPU，总有一个人在摸鱼。
避坑指南
我曾经接手过一个项目，cudaMemcpy占了总时间的40%。一看代码，每次迭代都从CPU拷贝数据到GPU。改成pinned memory + 异步拷贝后，直接降到了5%。Nsight Systems的API跟踪，一眼就揪出了这个元凶。
GPU Kernel执行时间线：找到最慢的那个核
Kernel执行时间线，是Nsight Systems最核心的功能之一。它把每个Kernel的启动、执行、结束都画在时间轴上。
你想想看，一个深度学习模型可能有上百个Kernel。哪个最慢？哪个占用了最多的GPU资源？光靠猜是不行的。
在Nsight Systems的「GPU Activity」视图中，每个Kernel用不同颜色的方块表示。方块越长，执行时间越久。我一般会按以下步骤分析：
- 先看最长的几个方块——它们是主要瓶颈
- 再看方块之间的空隙——是不是有GPU空闲？
- 最后看Kernel的启动间隔——是不是CPU提交任务太慢？
举个例子，有一次我优化一个图像处理管线。Nsight Systems显示，一个叫resize_kernel的方块占了整个时间线的60%。我点进去一看，它的occupancy只有30%。说白了，就是SM利用率太低。后来我调整了block size和grid size，occupancy提到了70%，整体性能翻了一倍。
内存操作分析：数据搬运的隐形杀手
内存操作，往往是性能优化的盲区。很多人只盯着Kernel的执行时间，却忽略了数据搬运的开销。
Nsight Systems在「Memory Operations」视图中，会详细展示：
| 操作类型 | 带宽利用率 | 传输方向 | 常见问题 |
|---|---|---|---|
| cudaMemcpy H2D | 通常较低 | CPU → GPU | PCIe带宽瓶颈 |
| cudaMemcpy D2H | 通常较低 | GPU → CPU | 同步等待导致空闲 |
| cudaMemcpy D2D | 很高 | GPU内部 | 显存带宽是否打满 |
| Pinned Memory | 较高 | 双向 | 是否用了page-locked内存 |
我个人的习惯是：先看H2D和D2H的带宽利用率。如果低于50%，说明数据传输没有充分利用PCIe。这时候我会检查：
- 是不是用了pinned memory？
- 是不是可以合并多次小传输为一次大传输？
- 是不是可以用异步传输来隐藏延迟？
注意
不要盲目追求高带宽。有时候，减少传输次数比提高单次带宽更重要。我曾经见过一个案例，每次迭代传输1KB数据，频率高达每秒10000次。即使每次带宽很高，但PCIe的延迟开销已经把性能拖垮了。改成批量传输后，问题迎刃而解。
知识体系总览
下面这张图，是我自己总结的Nsight Systems分析框架。每次做性能分析，我都会对照着看一遍。
这张图的核心逻辑很简单：先选采集模式，再分析三个维度，最后落到优化目标上。每次做性能分析，我都会问自己三个问题：
- CPU在等GPU，还是GPU在等CPU？
- 哪个Kernel最慢？为什么慢？
- 数据搬运有没有浪费带宽？
这三个问题问完，80%的性能问题都能找到方向。剩下的20%，就需要结合Nsight Compute做更细粒度的Kernel分析了——那是下一讲的内容。
我的小习惯
每次拿到一个新的性能分析任务，我会先开Nsight Systems跑一次Sample模式，生成一个概览报告。然后对着报告，把耗时最长的前三个操作圈出来。接下来再用Trace模式，只针对这三个操作做深度分析。这样既节省时间，又不会漏掉关键问题。
好了，这一讲的内容就到这里。记住，工具只是手段，思路才是核心。Nsight Systems给你的是数据，怎么解读、怎么优化，还得靠你的经验和判断力。
想要更多资料，联系可可