课程导入：学习目标、课程适用人群、GPU性能分析的整体流程与工具链概览
在现代高性能计算与深度学习训练推理场景中，GPU 早已从单纯的图形加速器演变为通用并行计算引擎。然而，绝大多数开发者在面对“GPU 利用率低”“显存不足”“kernel 启动间隙过大”“CPU 与 GPU 同步开销高”等问题时，往往只能凭借经验猜测瓶颈所在。NVIDIA 提供的 Nsight Systems 与 Nsight Compute 正是打破这种“黑盒”状态的核心工具：前者从系统级视角呈现 CPU/GPU 时间线、API 调用、内存拷贝与内核执行的重叠关系，后者则深入 GPU 内部，剖析每个 kernel 的指令吞吐、访存效率、寄存器压力与调度行为。本章作为整个课程的导入，将明确学习目标、适用人群，并建立 GPU 性能分析的整体流程与工具链框架，为后续 29 个章节的深入展开奠定方法论基础。
1.1 学习目标：从“能跑”到“跑得快”的认知跃迁
本课程的核心目标不是教会你机械地点击 Nsight 界面按钮，而是帮助你建立一套可复用的 GPU 性能分析方法论。完成本课程后，学习者应当具备以下四项核心能力：
- 系统级瓶颈识别能力：能够通过 Nsight Systems 的时间线视图，快速判断应用是受限于 CPU 启动开销、PCIe 传输带宽、kernel 执行效率，还是三者之间的不良重叠。这是性能分析的第一步，也是最容易出错的一步。
- 内核级微观剖析能力：能够使用 Nsight Compute 深入单个 kernel，解读指令执行吞吐、访存事务效率、warp 占用率、寄存器溢出等硬件级指标，并据此定位到具体的代码行或算法结构问题。
- 性能假设验证能力：能够基于分析数据提出可验证的性能假设（例如“增加 block 数量可以提升占用率”），并通过修改配置或代码进行 A/B 测试，用数据而非直觉驱动优化。
- 工具链协同使用能力：理解 Nsight Systems 与 Nsight Compute 的分工边界，知道何时该用哪个工具，以及如何将两者结果关联起来形成完整的性能画像。
课程适用人群：本课程主要面向三类学习者——① 使用 CUDA/C++ 进行高性能计算开发的工程师，需要定位 kernel 效率瓶颈；② 深度学习框架（PyTorch/TensorFlow）的高级用户，希望理解 GPU 资源利用情况并优化训练/推理性能；③ 从事异构计算平台调优的系统软件工程师，需要掌握从应用层到硬件层的完整分析链路。课程默认学习者具备基本的 CUDA 编程经验（了解 thread/block/grid 概念），但不要求有性能分析工具的使用基础。
1.2 GPU 性能分析的整体流程：六步闭环方法论
GPU 性能分析不是一次性的“体检”，而是一个持续迭代的闭环过程。我们将整个流程抽象为六个阶段，每个阶段都有明确的输入、输出与决策点。
| 阶段 | 核心任务 | 主要工具 | 关键输出 |
|---|---|---|---|
| ① 建立基线 | 在未优化状态下记录应用的运行时间、资源占用、吞吐量等基础数据 | nsys profile、ncu --metrics | 基线性能报告（时间、带宽、利用率） |
| ② 系统级定位 | 从时间线角度识别瓶颈所在层级（CPU/GPU/传输） | Nsight Systems | 时间线火焰图、API 调用统计、空隙分析 |
| ③ 内核级深挖 | 对关键 kernel 进行指令级与硬件级剖析 | Nsight Compute | kernel 性能报告（吞吐、占用、访存） |
| ④ 假设验证 | 基于分析结果提出优化假设，并通过小规模实验验证 | 修改代码 + 重新 profile | 假设验证结论（有效/无效） |
| ⑤ 优化实施 | 将验证有效的优化方案集成到代码中 | 代码编辑器 + 编译器 | 优化后的代码版本 |
| ⑥ 回归对比 | 在相同条件下重新测量，确认性能提升并检查是否引入新瓶颈 | nsys profile、ncu | 优化前后对比报告 |
这个流程的核心原则是“先系统后内核，先宏观后微观”。很多初学者容易犯的错误是直接跳到 Nsight Compute 去分析某个 kernel 的指令效率，却忽略了该 kernel 可能只占整个应用运行时间的 5%。系统级分析的价值在于帮助你找到“最重要的 20% 代码”，而内核级分析则负责把这 20% 的代码榨干性能。
1.3 工具链全景：Nsight Systems 与 Nsight Compute 的分工与协作
NVIDIA 的性能分析工具链以 Nsight Systems（系统级）和 Nsight Compute（内核级）为两大支柱，辅以命令行工具（nsys、ncu）和可视化界面（Nsight GUI）。理解两者的分工是高效分析的前提。
Nsight Systems 的定位是“全局视野”。它记录整个应用运行期间的时间线，包括 CPU 线程活动、CUDA API 调用、GPU kernel 执行、内存拷贝、CUDA 事件、NVTX 标记等。它的优势在于能够揭示跨层级的时序关系——例如，CPU 是否在等待 GPU 完成某个 kernel？内存拷贝是否与计算重叠？多个 kernel 之间是否存在不必要的串行依赖？Nsight Systems 的输出是“时间线 + 统计摘要”，适合回答“瓶颈在哪里”的问题。
Nsight Compute 的定位是“微观解剖”。它针对单个 kernel 提供数百项硬件计数器数据，包括 SM 占用率、寄存器使用、共享内存 bank 冲突、全局内存合并率、指令混合、warp 状态等。它的优势在于能够揭示硬件资源利用效率——例如，kernel 是否因为寄存器溢出导致本地内存访问？是否因为分支发散导致 warp 执行效率低下？Nsight Compute 的输出是“kernel 性能报告 + 源码关联”，适合回答“为什么这个 kernel 慢”的问题。
工具选择经验：当你不确定应用瓶颈在哪时，先用 nsys profile --trace=cuda,nvtx,osrt ./your_app 获取系统级时间线。如果发现某个 kernel 占用超过总时间 30%，再针对该 kernel 运行 ncu --set full ./your_app 进行深度剖析。切勿一开始就使用 Nsight Compute 的 full 模式，因为其开销极大（可能使运行时间增加 10-100 倍），不适合长时间运行的应用。
1.4 实战场景：一个典型的性能分析会话拆解
为了帮助大家建立直观认识，我们以一个简化的图像处理应用为例，演示完整的分析流程。该应用的功能是对一批高分辨率图像进行滤波和特征提取，运行在 NVIDIA A100 GPU 上。
初始现象与目标：应用总运行时间为 850ms，客户要求优化到 500ms 以内。初步观察发现 GPU 利用率（通过 nvidia-smi）在 40%-60% 之间波动，但无法确定瓶颈所在。
第一步：系统级分析。运行 nsys profile --trace=cuda,nvtx -o baseline ./image_pipeline，得到时间线报告。关键发现：
- CPU 端在 kernel 启动之间花费了约 120ms 执行图像解码和预处理（非 CUDA 操作），这部分与 GPU 计算完全串行。
- 存在 3 次明显的 H2D（主机到设备）内存拷贝，每次约 15ms，总计 45ms，且这些拷贝与 kernel 执行没有重叠。
- 两个主要 kernel（filter_kernel 和 feature_kernel）分别耗时 180ms 和 220ms，两者之间存在约 30ms 的空隙，原因是 CPU 在启动第二个 kernel 前需要完成一个同步操作。
第二步：内核级深挖。针对耗时最长的 feature_kernel，运行 ncu --set full -k feature_kernel -o feature_report ./image_pipeline。关键指标：
- SM 占用率仅 45%，远低于 A100 的理论上限。原因是每个线程使用了 64 个寄存器，限制了 block 数量。
- 全局内存加载效率为 62%，存在非合并访问模式——线程访问的地址跨度大于 128 字节。
- 指令混合显示有 18% 的整数运算指令，其中大部分是地址计算，可以通过使用
__ldg()或纹理路径优化。
第三步：假设验证与优化。基于以上数据，提出两个假设：① 将图像预处理移到 GPU 端（使用 CUDA kernel 替代 CPU 代码），消除 120ms 的串行开销；② 将 feature_kernel 的 block 大小从 256 调整为 512，并修改索引计算方式以改善内存合并。实施后重新测量：
| 指标 | 优化前 | 优化后 | 变化 |
|---|---|---|---|
| 总运行时间 | 850ms | 520ms | -38.8% |
| GPU 利用率 | 40-60% | 75-85% | +25% |
| H2D 拷贝时间 | 45ms | 18ms（合并后） | -60% |
| feature_kernel 耗时 | 220ms | 145ms | -34% |
复盘经验：本次优化中，系统级分析贡献了约 60% 的性能提升（消除串行预处理 + 合并拷贝），内核级优化贡献了约 40%。这验证了“先系统后内核”方法论的有效性。同时，我们也注意到优化后 CPU 端出现了新的瓶颈——图像解码的 CPU 代码成为新的热点，这将是下一轮迭代的起点。
常见误区提醒：① 不要盲目追求 100% GPU 利用率——对于短小 kernel 或延迟敏感型应用，过高的占用率可能意味着过度占用资源导致其他任务排队；② 不要忽略 CPU 端开销——GPU 性能分析工具往往聚焦 GPU，但 CPU 端的 API 调用、内存分配、线程同步同样可能成为瓶颈；③ 不要在一次分析中同时修改多个变量——这会导致无法归因性能变化的具体来源。
1.5 总结与学习路径建议
本章作为课程导入，建立了三个核心认知：第一，GPU 性能分析是一个从系统级到内核级的分层递进过程，需要遵循“先宏观定位，再微观深挖”的原则；第二，Nsight Systems 与 Nsight Compute 是互补而非替代关系，前者回答“哪里慢”，后者回答“为什么慢”；第三，性能优化是迭代闭环，每次优化后必须回归验证，并警惕新瓶颈的引入。