在着手编写这本手册之前，我自以为理解了 GPU 利用率的概念。

树叶人

在着手编写这本手册之前，我自以为理解了 GPU 利用率的概念。

我曾一度将三个截然不同的概念混为一谈：内核（kernel）启动的任务、实际驻留在 GPU 上的任务，以及当前准备好发射（issue）的任务。它们并非同一回事。

以一个包含 240 个线程块（block）、每个块 256 个线程的内核为例。这意味着共有 61,440 个逻辑线程，即 1,920 个 NVIDIA Warp（线程束）。然而，这些 Warp 并非同时在物理上驻留。线程块能否进入流多处理器（SM）执行，取决于寄存器、共享内存、线程数上限、Warp 数上限及线程块数上限等约束条件。即便某个 Warp 已经驻留，它仍可能处于等待内存数据、算术运算依赖解除或同步完成的状态。调度器只能从那些真正具备发射条件的 Warp 中进行选择。

这也改变了我解读性能数据的方式。

“占用率”（Occupancy）反映的是驻留情况，即实际驻留的 Warp 数量与架构允许的最大数量之比。而 GPU 利用率衡量的则是另一回事。在 NVML 中，它基本上是指在采样窗口期间，至少有一个内核正在执行的时间占比。

因此，即便 GPU 显示利用率为 100%，Tensor Core（张量核心）或 HBM（高带宽内存）带宽也未必处于饱和状态；此时可能存在某个子系统成为瓶颈，导致 GPU 的大部分资源仍未得到充分利用。

内存方面也存在类似的误区。寄存器、共享内存、L1 缓存、L2 缓存和 HBM 绝不仅仅是速度逐级递减的存储单元；它们在作用域、容量、管理机制和访问行为上各不相同。

模型能装入 HBM 仅说明其容量适配，但这几乎无法揭示实际的数据传输量、访存合并（coalescing）效率、数据复用率，也无法说明内存是否为制约内核性能的瓶颈。

FlashAttention 就是一个很好的例子：尽管稠密注意力（dense attention）的数学运算逻辑保持不变，但其执行调度方式经过了重组，从而减少了 HBM 与片上存储之间的数据传输。

Tensor Core 是我过去在认知上过度简化了的另一个概念。它们是专用于矩阵乘累加运算的硬件，对 AI 领域至关重要，但它们并不负责“运行整个模型”。归约（reduction）、索引、逐元素（elementwise）运算、同步、内存数据移动、内核启动以及大量其他指令，依然需要通过 GPU 的其他组件来处理。过了一段时间，我不再纠结于“为什么 GPU 占用率没达到 100%？”这个问题，而是转而思考一个更有价值的问题：当下究竟是什么在制约着有效进展？

这最终演变成了一份长达 42 页的手册。

内容涵盖了 SM、Warp、调度器、占用率（occupancy）、延迟隐藏、寄存器、共享内存、缓存、HBM、内存合并访问（coalescing）、Tensor Core、GEMM 映射、精度、利用率，以及那些极易被误读的性能数据。

值得一读。