GPU架构基础：现代GPU的硬件架构（SM、核心、内存层次）及其对性能指标的影响

核心原理：从“多核并行”到“海量线程吞吐”的设计哲学

CPU与GPU的根本差异不在于“核心数量”，而在于设计目标。CPU追求低延迟，通过大容量缓存、分支预测和乱序执行来加速单线程；GPU则追求高吞吐，通过数千个轻量级核心并行处理海量数据，用并行度掩盖延迟。NVIDIA现代GPU（从Volta到Hopper、Ada Lovelace）的基本计算单元是流式多处理器（SM，Streaming Multiprocessor），一个GPU由多个SM组成，例如A100有108个SM，H100有132个SM。

每个SM内部包含四个关键部件：CUDA核心（负责整数和浮点运算）、特殊功能单元（SFU）（计算超越函数如sin、cos）、加载/存储单元（LSU）（处理访存指令）以及张量核心（Tensor Core）（执行矩阵乘加运算，是AI训练和推理的加速引擎）。线程在GPU上以Warp（32个线程为一组）为单位调度，一个Warp中的线程在同一时刻执行同一条指令（SIMT模型），若发生分支发散，则不同路径会被串行执行，造成吞吐损失。

方法流程：SM资源如何决定Nsight Compute中的关键指标

在Nsight Compute中，SM占用率（SM Occupancy）是最直观的指标，它表示活跃Warp数量与SM最大可容纳Warp数量的比值。以A100为例，每个SM最多可容纳64个Warp（2048个线程），若内核只启动了1024个线程/SM，则占用率为50%。占用率受三方面限制：寄存器文件（A100每个SM有65536个32位寄存器）、共享内存容量（192 KB/SM）以及线程块（Block）数量上限（32个/SM）。

Nsight Compute的“Warp State”部分会统计Warp的停顿原因，包括：等待内存返回（Long Scoreboard）、等待固定延迟执行（Short Scoreboard）、等待屏障同步（Barrier）、等待数学管道（Math Pipe Throttle）等。这些停顿直接关联到硬件资源：若大量Warp处于“Long Scoreboard”状态，说明内存延迟未被充分隐藏，此时应提高占用率或优化数据局部性；若“Math Pipe Throttle”占比高，则说明计算指令已饱和，应考虑减少冗余计算或使用Tensor Core。

分析流程建议遵循以下步骤：

1. 打开Nsight Compute的Speed of Light页面，查看SM（计算）与内存带宽的利用率百分比，判断内核是计算密集型还是内存密集型。
2. 进入Occupancy页面，检查理论占用率与实际占用率的差距，确认是否存在寄存器溢出（Spill）或共享内存超限。
3. 查看Scheduler Statistics，了解每个SM的调度器（4个）在每个周期发出的指令数，理想值为4（每个调度器每周期发1条指令）。
4. 结合Warp State和Source Counters，定位具体停顿指令的代码行，分析是访存模式问题还是算法依赖问题。

案例/场景：矩阵乘法内核的瓶颈定位

假设我们编写了一个简单的SGEMM（单精度矩阵乘法）内核，在A100上运行，Nsight Compute报告如下：

Speed of Light:
  Compute (SM) Utilization: 35%
  Memory Bandwidth Utilization: 82%

Occupancy:
  Theoretical Occupancy: 75% (因寄存器限制)
  Achieved Occupancy: 72%

Warp State:
  Long Scoreboard: 58%
  Short Scoreboard: 12%
  Barrier: 8%
  Math Pipe Throttle: 15%
  Selected: 7%

从数据可以判断：内存带宽利用率（82%）远高于计算利用率（35%），且Warp主要停顿在Long Scoreboard（等待全局内存返回），说明这是一个内存密集型内核。虽然理论占用率有75%，但高延迟访存仍然暴露。优化方向不是继续提高占用率，而是：

• 使用共享内存分块（Tiling），将A和B矩阵的子块加载到共享内存，减少重复的全局内存访问。例如将分块大小设为32×32，每个Block加载2048个浮点数到共享内存。
• 确保合并访问（Coalesced Access）：相邻线程访问相邻内存地址。检查代码中是否有按列访问矩阵的情况，若有则改为按行访问或使用转置。
• 考虑使用Tensor Core：将数据转换为FP16或BF16精度（若应用允许），利用Tensor Core的4×4矩阵乘加指令，可将计算吞吐提升数倍，从而平衡计算与内存的利用率。

修改后重新运行，Speed of Light显示Compute Utilization提升至68%，Memory Bandwidth Utilization降至60%，整体执行时间缩短了约2.3倍。

误区/复盘：常见硬件理解错误与Nsight误读

下表总结了SM关键资源与Nsight Compute指标的对应关系，便于快速定位问题：