GPU 性能剖析：Nsight Systems 与 Nsight Compute 实战

定位顺序（自顶向下）：
1. nsys 看全局：CPU 是否在等 GPU？GPU 是否有大段空闲？
   → 有空闲 = 调度/拷贝/同步问题，先解决
2. nsys 看热点：哪个 Kernel 占的时间最多？占比多少？
   → 找出 Top-N Kernel，才算进入 Kernel 优化
3. ncu 看内部：热点 Kernel 为何慢？算力/带宽/延迟哪个受限？
   → 拿到具体指标，才知道该改什么

# 基本采集：整个进程
nsys profile -o report_name --force-overwrite true python infer.py

# 只采 CUDA/NVTX 相关，减少噪音
nsys profile -t cuda,nvtx,osrt -o report_name ./app

# 延迟采集：跳过预热阶段，只采稳态（避免冷启动干扰）
nsys profile --delay 10 --duration 20 -o report_name ./app

# 加上 GPU 计数器采样（功耗/利用率/温度）
nsys profile --gpu-metrics-device=0 -o report_name ./app

# 命令行汇总：Kernel 耗时排行 + CUDA API 耗时排行
nsys stats --report cuda_gpu_kern_sum,cuda_api_sum report_name.nsys-rep

① GPU 空闲间隙（Gap）
   Kernel A 结束到 Kernel B 开始之间有没有空隙？
   → 有空隙 = CPU 提交慢 / 同步阻塞 / 启动开销大
   → 小 Kernel 密集场景，空隙可能吃掉 30%+ 时间

② CPU 是否在等 GPU
   看 CPU 线程状态：是否长时间停在 cudaStreamSynchronize / cudaMemcpy
   → 说明 CPU 被同步拖住，应改异步（async copy + stream）

③ 数据传输占比
   H2D / D2H 拷贝是否与计算重叠？
   → 未重叠的拷贝是纯浪费，应上 pinned memory + 多流

④ 同步点
   cudaDeviceSynchronize 是否频繁？每次同步都会打断流水线

典型症状 → 结论对照：
GPU 利用率 30%，时间线大段空白   → 启动/调度瓶颈（CPU 提交慢或同步多）
Kernel 之间有细密空隙            → 小 Kernel 启动开销（考虑融合/CUDA Graph）
D2H 拷贝与 Kernel 串行不重叠     → 拷贝未异步化（pinned + stream）
CPU 长期停在 Sync 上             → 同步点过多（去同步化）

import torch.cuda.nvtx as nvtx

def generate(prompt):
    nvtx.range_push("prefill")
    # ... 预填充计算
    nvtx.range_pop()

    nvtx.range_push("decode")
    for _ in range(max_tokens):
        # ... 逐 token 解码
        pass
    nvtx.range_pop()

# 上下文管理器写法（更安全，异常也会 pop）
with nvtx.range("embedding"):
    vec = embed(prompt)

# 采集时带上 nvtx，时间线会显示自定义区间
nsys profile -t cuda,nvtx -o report ./app

# 剖析指定 Kernel（按名字匹配），采集完整指标集
ncu --kernel-name regex:flash --set full -o k_report ./app

# 快速概览：只看 roofline 与瓶颈提示
ncu --set default --launch-count 5 ./app

# 指定指标集合
ncu --metrics sm__throughput.avg.pct_of_peak_sustained_elapsed,\
gpu__compute_memory_throughput.avg.pct_of_peak_sustained_elapsed ./app

# 只剖析第 N 次调用（跳过预热）
ncu --launch-skip 20 --launch-count 1 ./app

① 占用率（Occupancy）
   Achieved Occupancy：实际活跃 warp / 理论最大 warp
   → 低占用率常见原因：寄存器压力、共享内存超限、block 太小
   → 但低占用不一定是问题：访存受限的 Kernel 不需要高占用

② 计算吞吐（Compute Throughput）
   sm__throughput.avg.pct_of_peak_sustained_elapsed
   → 接近 100% = 算力受限（compute-bound）

③ 内存吞吐（Memory Throughput）
   gpu__compute_memory_throughput.avg.pct_of_peak_sustained_elapsed
   → 接近 100% = 带宽受限（memory-bound）

④ 停顿原因（Warp Stall Reasons）
   Stall Long Scoreboard → 等全局内存（访存延迟）
   Stall Barrier        → 等 __syncthreads
   Stall MIO Throttle   → 共享内存/特殊功能单元排队
   Stall Not Selected   → 可发射的 warp 太多（其实是好事）

算术强度低（< 硬件拐点）→ 落在带宽屋顶线下 → memory-bound
   → 优化方向：减少访存字节（量化、融合、共享内存复用）
算术强度高（> 硬件拐点）→ 落在算力屋顶线下 → compute-bound
   → 优化方向：用 Tensor Core、减少冗余计算、提高并行度
离两条屋顶线都很远 → 延迟/占用率问题 → 调 block/寄存器/提高并行

① 耗时放大
   --set full 可能重放几十次，一个 1ms 的 Kernel 要花几十 ms 采完
   → 长 Kernel / 大模型场景，优先用 --section 精确采集

② 状态污染
   重放会重复执行 Kernel 的副作用（如原子加、写全局内存）
   → 对「会改状态」的 Kernel，采集前后要做隔离或用 --replay-mode

③ 只适合稳态 Kernel
   依赖外部随机状态、时间戳的 Kernel 采集结果会失真

# 只采关键 section，避免全量重放
ncu --section SpeedOfLight --section Occupancy \
    --kernel-name regex:"attention" ./app

# 应用重放模式（快照/恢复内存状态，副作用更小）
ncu --replay-mode application --kernel-name regex:"gemm" ./app

一个高频误判：
「占用率低 → 一定是问题」
错。访存受限的 Kernel 靠少量 warp 打满带宽是正常的，
盲目提高占用率反而可能因寄存器/共享内存挤占而变慢。
判断标准：占用率低 + 吞吐也低，才是真问题。

多流场景：
□ 各 stream 是否真正并行？还是串行排队（false dependency）
□ 事件（event）等待是否成为隐式同步点
□ 拷贝流与计算流是否重叠

多卡场景（TP/PP）：
□ NCCL 通信 Kernel 占比多少？是否与计算重叠？
□ AllReduce/AllGather 是否落在关键路径上
□ 是否有卡在「等别的卡」（负载不均）

# 多进程剖析：每个 rank 一份报告
nsys profile -o rank_%p --force-overwrite true torchrun --nproc_per_node=4 app.py

# 只看 NCCL 通信占比
nsys stats --report cuda_gpu_kern_sum rank_*.nsys-rep | grep -i nccl

Step 1  建立基线
        nsys 采集稳态时间线 + ncu 采集 Top-3 Kernel 指标
        记录：端到端延迟、Kernel 总耗时、GPU 利用率

Step 2  定位第一瓶颈
        自顶向下：先看 nsys 找空隙/热点，再看 ncu 判受限类型

Step 3  单点优化
        只改一个地方（融合 / 量化 / 占用率 / 异步化）

Step 4  复测对比
        同一输入、同一预热，重跑 nsys/ncu，对比指标
        端到端是否变快？Kernel 指标是否改善？

Step 5  记录并迭代
        写进「调优日志」：改动 + 指标前后 + 结论
        当前瓶颈消除后，回到 Step 2 找下一个

# 最小化的剖析脚本（把两步串起来）
nsys profile -t cuda,nvtx --delay 5 --duration 15 -o base ./serve.sh
nsys stats --report cuda_gpu_kern_sum base.nsys-rep | head -20
# 挑出 Top-1 Kernel 名，再用 ncu 深挖
ncu --kernel-name regex:"<TopKernel>" --set default --launch-count 3 ./serve.sh