4. Nsight Systems基础分析：Timeline视图解读，CPU/GPU并发活动分析，API追踪（CUDA、OpenMP、MPI），Trace文件生成与加载
好，咱们直接进入正题。Nsight Systems 这个工具，说白了就是给你一双「透视眼」，让你看清楚 GPU 在忙什么、CPU 在等什么。我刚开始调优的时候，全靠猜，后来用了它，才发现之前好多优化方向都是错的。
核心思想：Nsight Systems 不是帮你算「这行代码跑了多久」，而是帮你回答「为什么这么慢」。它关注的是整个系统的并发与等待。
4.1 Timeline 视图：你的第一道防线
打开一个 trace 文件，你首先看到的就是 Timeline。嗯，这里要注意，别被花花绿绿的条条吓到。我习惯先看整体，再放大细节。
Timeline 上主要有三类信息：
- CPU 活动行：显示每个 CPU 线程在干啥。比如在跑计算、在等锁、还是在调用 CUDA API。
- GPU 活动行：显示 GPU 上的 kernel 执行、内存拷贝、以及 Stream 的调度情况。
- API 追踪行：显示 CUDA Runtime API、OpenMP 指令、MPI 通信的调用时间线。
你想想看，如果 GPU 的 kernel 执行之间有大段空白，那八成是 CPU 提交任务太慢，或者数据还没准备好。我曾经在一个项目里，发现 GPU 利用率只有 30%，放大 Timeline 一看，原来是 CPU 在等 MPI 通信，白白浪费了 GPU 算力。
我的小技巧：先按 Ctrl + A 全选，然后看「GPU Utilization」这个指标。如果低于 80%，就说明有优化空间。然后顺着 Timeline 找「空隙」——那些 GPU 空闲、CPU 却在忙的区间。
4.2 CPU/GPU 并发活动分析：谁在等谁？
这是 Nsight Systems 最核心的能力。它把 CPU 和 GPU 的活动放在同一个时间轴上，让你一眼看出「谁在等谁」。
常见的并发问题：
- CPU 串行提交：CPU 一个一个地提交 kernel，中间有大量延迟。解决办法是用 CUDA Stream 实现异步提交。
- GPU 等待数据：GPU 在等 CPU 把数据拷贝过来。这时候你会看到
cudaMemcpy占用了大量时间。 - MPI 通信阻塞：多卡训练时，一个 rank 在等另一个 rank 发数据，导致所有 GPU 都停下来。
我记得有一次压测一个 8 卡节点，发现性能始终上不去。打开 Timeline 一看，好家伙，7 张卡都在等第 0 张卡做完 AllReduce。后来改成 NCCL 的拓扑感知通信，性能直接翻倍。
避坑指南：我曾经以为 GPU 利用率高就代表性能好。结果发现 GPU 在跑一个很慢的 kernel，利用率是 100%，但吞吐量很低。所以一定要结合 kernel 的执行时间来看，别被利用率骗了。
4.3 API 追踪：CUDA、OpenMP、MPI
Nsight Systems 可以追踪三种主要的并行 API。我一般会同时开启，因为现代 HPC 应用往往是混合并行的。
CUDA API 追踪：
- 能看到每个
cudaMemcpy、cudaLaunchKernel的调用时间。 - 注意看
cudaStreamSynchronize的调用——它往往是性能杀手。
OpenMP 追踪：
- 能看到每个 parallel region 的创建、线程 fork/join 的开销。
- 如果发现 parallel region 很短（比如只有几微秒），那线程管理的开销可能比计算本身还大。
MPI 追踪：
- 能看到每个
MPI_Send、MPI_Recv、MPI_Allreduce的耗时。 - 重点关注通信是否与计算重叠。理想情况是：GPU 在算的时候，CPU 在发数据。
实战经验：我习惯在代码里加一些 nvtxRangePush / nvtxRangePop 标记，这样在 Timeline 上就能看到「这是前向传播」、「这是梯度同步」。否则一堆 kernel 名字，根本分不清谁是谁。
4.4 Trace 文件生成与加载
生成 trace 文件其实很简单，但有几个坑要注意。
生成命令：
nsys profile -o my_trace -t cuda,openmp,mpi --mpi-impl=openmpi ./my_app参数说明：
| 参数 | 作用 | 我的建议 |
|---|---|---|
-o |
指定输出文件名 | 别用默认名，否则容易覆盖 |
-t |
指定追踪哪些 API | 我一般全开，除非文件太大 |
--mpi-impl |
指定 MPI 实现 | 不指定的话可能追踪不到 MPI 调用 |
--capture-range=cudaProfilerApi |
只追踪指定范围 | 适合大型应用，避免文件爆炸 |
注意：Trace 文件可能会非常大。我曾经跑一个 64 卡的训练任务，生成了 2GB 的 trace 文件。加载的时候差点把笔记本卡死。建议先用 --capture-range 只追踪关键部分，或者用 --duration 限制追踪时间。
加载 trace 文件：
直接用 nsys-ui my_trace.qdstrm 打开。如果是在远程服务器上，可以用 nsys-ui --host=server_ip 远程加载。我个人习惯把 trace 文件下载到本地看，因为 GUI 响应更快。
4.5 知识体系总览
下面这张图是我自己总结的 Nsight Systems 分析流程，你可以照着这个思路来排查性能问题。
这张图的核心逻辑是：先看整体，再分三个方向深入分析，最后汇总到瓶颈定位。我每次做压测都走这个流程，基本不会漏掉关键问题。
最后提醒一句：不要试图一次分析所有问题。先抓大放小，把 GPU 利用率提上去，再优化单个 kernel。我见过太多人花一周优化一个 kernel 到 10%，结果发现另一个 kernel 占了 90% 的时间——白忙活。
好了，这一章的内容就这些。下一章我们会深入 Timeline 的细节，教你怎么用「Range」和「Statistics」视图做定量分析。