4、性能分析基础概念：吞吐量、延迟、占用率、内存带宽、计算吞吐、指令混合、瓶颈类型（计算/内存/延迟/占用率）

在进入 NVIDIA Nsight Compute 的实操之前，必须先建立一套统一的性能分析语言。GPU 性能优化并非盲目调整参数，而是基于量化指标定位瓶颈、验证假设的工程过程。本章将围绕七个核心概念展开：吞吐量（Throughput）、延迟（Latency）、占用率（Occupancy）、内存带宽（Memory Bandwidth）、计算吞吐（Compute Throughput）、指令混合（Instruction Mix）以及瓶颈类型（计算/内存/延迟/占用率）。这些概念共同构成了内核性能分析的“仪表盘”，只有读懂它们，才能准确判断内核是受限于硬件资源、访存模式还是调度效率。

上图展示了本章概念之间的逻辑关系：吞吐量、延迟和占用率是描述内核行为的三个基础测量指标；它们进一步映射到内存带宽、计算吞吐和指令混合等硬件资源维度；最终，这些资源维度的利用率决定了内核属于哪种瓶颈类型。Nsight Compute 的分析流程正是沿着这条路径，从采集数据到定位瓶颈，再到指导优化。

4.1 核心原理：三个基础指标与两个资源维度

吞吐量（Throughput） 指单位时间内完成的操作数或数据量，通常以 GFLOP/s（浮点运算/秒）、GB/s（字节/秒）或 Instruction/s（指令/秒）为单位。在 GPU 中，吞吐量反映的是硬件执行单元的利用效率。例如，一个内核的 FP32 计算吞吐量达到 80% 的理论峰值，意味着流处理器（SM）中的 FP32 单元大部分时间处于忙碌状态。

延迟（Latency） 指单个操作从发出到完成所需的时间，通常以时钟周期或纳秒为单位。GPU 通过大量线程并行来隐藏延迟，但延迟本身仍然影响性能。例如，全局内存访问延迟约为 400-800 个周期，如果线程数量不足，这些延迟周期将直接暴露为流水线空泡。

占用率（Occupancy） 指每个 SM 上活跃的线程束（Warp）数量与最大可容纳线程束数量的比值。高占用率是隐藏延迟的关键手段，但并非越高越好——过高的占用率可能导致寄存器溢出或缓存抖动。

内存带宽（Memory Bandwidth） 是 GPU 从 DRAM 或 L2 缓存读取/写入数据的速率。现代 GPU 的 HBM2e 带宽可达 1-2 TB/s，但实际有效带宽取决于访问模式（合并访问、缓存命中率等）。

计算吞吐（Compute Throughput） 指 SM 上各类计算单元（FP32、FP64、INT32、Tensor Core、SFU）的运算速率。不同精度的峰值吞吐差异巨大，例如 A100 的 FP32 峰值约为 19.5 TFLOPS，而 Tensor Core 的 FP16 峰值可达 312 TFLOPS。

指令混合（Instruction Mix） 指内核执行的各种指令类型（加载/存储、算术、控制流、转换等）所占的比例。指令混合决定了哪些执行单元是潜在瓶颈。例如，一个内核如果包含大量 MUFU.EX2（指数运算）指令，则 SFU（特殊函数单元）可能成为瓶颈。

4.2 判断方法：SOL 模型与瓶颈分类

Nsight Compute 的核心分析框架是 Speed of Light（SOL） 模型。该模型将内核的实际执行时间与理论最短时间（基于硬件峰值）进行对比，从而量化“距离理论极限还有多远”。SOL 模型主要分为两个维度：

• Memory SOL：实际内存吞吐 / 理论峰值内存带宽。如果该值接近 100%，说明内核受限于内存带宽。
• Compute SOL：实际计算吞吐 / 理论峰值计算吞吐。如果该值接近 100%，说明内核受限于计算单元。

根据 SOL 结果，瓶颈类型可分为四类：

瓶颈类型	判定标准（Nsight Compute 指标）	典型特征	优化方向
计算瓶颈（Compute Bound）	Compute SOL > 80%，Memory SOL < 60%	算术指令密集，SM 利用率高	降低精度、使用 Tensor Core、减少冗余计算
内存瓶颈（Memory Bound）	Memory SOL > 80%，Compute SOL < 60%	大量加载/存储指令，缓存命中率低	改善合并访问、使用共享内存、调整数据布局
延迟瓶颈（Latency Bound）	占用率低（< 30%），Stall 原因主要为 Long Scoreboard	线程数不足，依赖链长	增加线程块数量、减少寄存器使用、提高 ILP
占用率瓶颈（Occupancy Bound）	占用率受限（< 50%），且非延迟原因	寄存器/共享内存使用过多，线程块调度受限	减少资源占用、调整线程块大小、使用动态共享内存

在实际分析中，需要结合 Memory Workload Analysis 和 Compute Workload Analysis 两个视图。前者展示内存吞吐、缓存命中率、访问模式；后者展示各计算单元的利用率、指令混合和 warp 状态。

4.3 案例拆解：一个向量求和内核的瓶颈识别

假设我们有一个简单的向量求和内核：

__global__ void vector_add(const float* a, const float* b, float* c, int n) {
    int idx = blockIdx.x * blockDim.x + threadIdx.x;
    if (idx < n) {
        c[idx] = a[idx] + b[idx];
    }
}

使用 Nsight Compute 分析后，得到以下关键指标：

• Memory SOL：92%
• Compute SOL：15%
• 全局加载吞吐：1.2 TB/s（接近峰值）
• 全局存储吞吐：0.6 TB/s
• 占用率：87%
• 指令混合：LDG 占 40%，STG 占 20%，FADD 占 20%，其余为控制流

分析过程：Memory SOL 高达 92%，而 Compute SOL 仅 15%，说明内核明显受限于内存带宽。进一步查看指令混合，加载/存储指令占比 60%，算术指令仅 20%，这与内存瓶颈的特征完全吻合。占用率 87% 说明延迟隐藏良好，不是延迟瓶颈。

优化方案：由于是内存瓶颈，优化重点应放在减少内存流量上。可以考虑：

1. 使用 float4 向量化加载，将 4 个 float 合并为一次 128 位访问，减少指令数。
2. 使用共享内存进行分块处理，但本例中数据无复用，收益有限。
3. 使用只读缓存（__ldg）提高缓存命中率。

优化后结果：采用 float4 向量化后，加载指令数减少 75%，内存吞吐提升至 1.5 TB/s，内核执行时间缩短 35%。

4.4 常见误区与总结复盘

误区一：占用率越高越好。实际上，当占用率超过一定阈值（通常 50%-60%），继续提高占用率对隐藏延迟的边际收益递减，反而可能因寄存器溢出导致局部内存访问增加。应通过 Launch Statistics 视图检查实际占用率与理论占用率的差距。

误区二：只看 SOL 数值，忽略指令混合。SOL 只能告诉你“是否接近峰值”，但不能告诉你“为什么没达到峰值”。例如，Compute SOL 为 60%，可能是 FP32 单元利用率低，也可能是 SFU 单元过载。必须结合指令混合和单元利用率定位具体原因。

误区三：将延迟瓶颈误判为内存瓶颈。延迟瓶颈的特征是占用率低且 Stall 原因主要为 Long Scoreboard（等待内存返回），而内存瓶颈的特征是内存吞吐接近峰值。两者虽然都与内存相关，但优化方向截然不同：延迟瓶颈需要增加并行度，内存瓶颈需要减少数据流量。

误区四：忽略指令混合中的“隐藏”指令。例如，整数运算（INT32）和浮点运算（FP32）共享部分执行单元，如果内核中混有大量整数运算，会降低 FP32 吞吐。Nsight Compute 的 Compute Workload Analysis 会分别显示各单元利用率，应仔细查看。