4、性能分析基础：关键性能指标（KPI）概览

在深入 Nsight Compute 的各类分析器之前，必须先建立一套统一的“度量语言”。GPU 性能优化并非凭感觉猜测，而是通过一组可量化、可对比的关键性能指标（KPI）来定位瓶颈。本章聚焦三个最核心的 KPI：吞吐量（Throughput）、占用率（Occupancy）与延迟（Latency）。理解这三者的定义、测量方式及相互制约关系，是读懂后续所有 Nsight Compute 报告的基础。

4.1 核心原理：三个 KPI 的物理含义

这三个指标分别从不同维度描述 GPU 的工作状态。吞吐量衡量“单位时间完成了多少工作”，占用率衡量“硬件资源被激活的程度”，延迟则衡量“一次操作从发出到完成的时间”。它们并非孤立存在，而是通过硬件架构紧密耦合。

  • 吞吐量（Throughput）：通常以 SM（Streaming Multiprocessor） 的指令执行速率或内存带宽利用率表示。Nsight Compute 中常见的 SM Busy、Memory Throughput 即属于此类。高吞吐量意味着计算单元或内存总线处于高负荷状态。
  • 占用率（Occupancy）：指每个 SM 上活跃的 Warp 数量与硬件最大支持 Warp 数量的比值。高占用率是隐藏延迟（Latency Hiding）的前提，但并非越高越好——过高的占用率可能导致缓存或寄存器溢出。
  • 延迟（Latency）：在 GPU 语境下，主要指内存访问延迟与指令依赖延迟。例如，一次全局内存 Load 操作可能需要 400~800 个时钟周期。延迟本身不可消除，但可以通过提高占用率来“隐藏”。

下图展示了三者之间的动态关系：当占用率提升时，更多 Warp 可被调度，从而掩盖内存延迟；但若吞吐量已接近硬件极限，再提升占用率反而可能因资源竞争导致延迟增加。

GPU 性能三 KPI 动态关系图 SM Warp 调度器 活跃 Warp 轮转调度 占用率 (Occupancy) 活跃 Warp / 最大 Warp 寄存器、共享内存限制 典型目标：50%~75% 延迟 (Latency) 内存访问 400~800 cycles 指令依赖延迟 不可消除，只能隐藏 吞吐量 (Throughput) SM 指令吞吐 / 内存带宽利用率 提供可调度 Warp 切换 Warp 隐藏延迟 持续发射指令 资源竞争反馈 优化目标：在延迟不可减的情况下，通过调整占用率与吞吐量的平衡点来逼近硬件极限

4.2 方法流程：如何从 Nsight Compute 中读取 KPI

Nsight Compute 的 SOL（Speed Of Light） 模型将硬件资源分为多个域，每个域都有对应的吞吐量指标。以下是标准分析流程：

  1. 获取基线数据：运行 ncu --set full ./your_app，生成完整报告。
  2. 查看 SOL 分析页：关注 Compute (SM) 与 Memory 两个吞吐量百分比。若两者均低于 60%，则可能存在调度或延迟问题。
  3. 检查占用率：在 Occupancy 部分查看理论占用率与实际占用率。理论值由启动配置决定，实际值受寄存器、共享内存限制。
  4. 分析延迟隐藏：查看 Warp State 统计，关注 Stalled 原因分布（如 Long Scoreboard 表示等待内存返回）。

一个典型的命令行输出片段如下：

Section: GPU Speed Of Light Throughput
-----------------------------  -----------  -----------
Compute (SM) Throughput                        58.61%
Memory Throughput                               42.37%
L1/TEX Cache Throughput                         31.20%
L2 Cache Throughput                             28.45%

Section: Occupancy
-----------------------------  -----------  -----------
Block Limit Registers                          8
Block Limit Shared Mem                        16
Block Limit Warps                              32
Theoretical Occupancy                         75%
Achieved Occupancy                            62%

注意：理论占用率是硬件允许的上限，实际占用率则反映了运行时 Warp 分配不均或尾部效应（Tail Effect）的影响。

4.3 案例场景：矩阵乘法中的 KPI 权衡

以 sgemm（单精度矩阵乘法）为例，假设核心逻辑如下：

__global__ void sgemm_kernel(float *A, float *B, float *C, int N) {
    int row = blockIdx.y * blockDim.y + threadIdx.y;
    int col = blockIdx.x * blockDim.x + threadIdx.x;
    float sum = 0.0f;
    for (int k = 0; k < N; ++k) {
        sum += A[row * N + k] * B[k * N + col];
    }
    C[row * N + col] = sum;
}

该朴素实现通常表现出以下 KPI 特征：

  • Memory Throughput 极高（>80%），因为每个线程直接访问全局内存，无数据复用。
  • Compute Throughput 极低（<10%），因为计算被内存等待完全拖住。
  • 实际占用率可能很高（>75%），但高占用率并未转化为高吞吐，因为所有 Warp 都在等待内存返回。

此时，Nsight Compute 的 Warp State 会显示大量 Long Scoreboard 停顿。优化方向并非继续提升占用率，而是引入 共享内存分块（Tiling） 以降低内存访问次数，从而提升计算吞吐量。优化后，Compute Throughput 可能升至 70%，而 Memory Throughput 降至 40%，整体执行时间缩短。

4.4 误区与复盘：常见 KPI 解读陷阱

误区一：盲目追求 100% 占用率。高占用率只是手段，不是目标。当计算吞吐量已接近峰值时，继续提升占用率只会增加资源竞争，导致缓存命中率下降。例如，一个寄存器使用量为 64 的 Kernel，若强行将占用率从 50% 提升到 100%，可能因寄存器溢出（Spill）到局部内存，反而使性能下降 30%。

误区二：只关注平均吞吐量，忽略延迟分布。Nsight Compute 报告中的 Memory Throughput 是平均值，但若访问模式存在严重的不连续性（如随机访问），即使平均带宽利用率不高，也会因长尾延迟导致性能骤降。应结合 L2 Cache Hit Rate 与 Memory Access Pattern 分析。

复盘建议：每次优化后，应同时记录三个 KPI 的变化，而非只看运行时间。若时间缩短但 Compute Throughput 未提升，说明优化可能只是减少了指令数；若时间未变但 Memory Throughput 下降，则可能是延迟隐藏能力变差。下表总结了典型场景的 KPI 组合特征：

瓶颈类型 Compute 吞吐 Memory 吞吐 实际占用率 典型 Warp 停顿原因
计算密集 高（>80%） 低（<30%） 中高 Short Scoreboard（指令依赖）
内存带宽受限 低（<20%） 高（>80%） 高 Long Scoreboard（等待显存）
延迟受限（低占用率） 中低 中低 低（<30%） Wait（无可用 Warp）
负载不均衡 中 中 波动大 Barrier / MIO Throttle

在实际项目中，建议将 Nsight Compute 的 SOL 分析页截图归档，并附上每次修改对应的 KPI 变化表。这样不仅便于定位问题，也能在团队评审时提供客观依据。记住：吞吐量告诉你硬件有多忙，占用率告诉你硬件有多少人可用，延迟告诉你为什么有人闲着。三者结合，才能准确描述 GPU 的真实执行状态。

← 上一章 📖 返回目录 下一章 →