算力拉满，GPU 却在摸鱼：深度学习里的访存瓶颈
两个很常见的性能优化场景，背后其实是同一句话：瓶颈往往不在算力，而在数据搬运。一个发生在显存内部（HBM ↔ 计算单元），一个发生在 CPU 到 GPU 的传输路上。搞懂这一层，很多"优化了半天没效果"的怪事就解释得通了。
一、一个反直觉的现象：把 LayerNorm 从 FP32 换成 FP16，速度一点没涨
先看一个真实会踩的坑。
某个模型里 LayerNorm 占了不少时间，于是有人想当然地优化：既然 FP16 算力是 FP32 的两倍，那把 LayerNorm 的计算精度从 FP32 换成 FP16，是不是就能快一倍？
改完一测——速度纹丝不动。
这不是 bug，而是因为优化方向从一开始就错了。LayerNorm 的瓶颈根本不在算力上。要讲清楚这件事，得先请出一个判断"算子到底卡在哪"的工具：Roofline 模型。
二、Roofline 模型：先定位瓶颈，再谈优化
Roofline 模型用一张图回答一个问题：一个算子的性能，到底是被算力卡住，还是被显存带宽卡住？
它的横轴是算术强度，单位是 FLOPs/Byte，意思是"每从显存搬运 1 个字节，能顺带做多少次浮点运算"。纵轴是实际能达到的性能（FLOPs/s）。这张图被分成两个区域：
- 左侧的斜坡区（Memory-bound，带宽受限）：算术强度很低，数据读进来没做几次运算就得写回去。这时性能 = 算术强度 × 峰值带宽，性能被斜率（也就是显存带宽）牢牢摁住。
- 右侧的平台区（Compute-bound，算力受限）：算术强度足够高，数据复用得很充分。这时性能顶到峰值算力的天花板，被算力卡住。
两个区域的交界处叫"拐点"。一个算子落在拐点左边还是右边，决定了你该往哪个方向使劲。
用大白话比喻就是一个厨房：
- 算力是切菜厨师的手速；
- 显存带宽是食材从仓库运到灶台的传送带速度；
- 算术强度是"每运来一筐菜，厨师要在灶台上忙活多久"。
如果厨师每筐菜要颠勺炒十分钟（算术强度高），那瓶颈在厨师手速，给他换个手快的（提算力）确实有用——这是 compute-bound。 如果厨师拿到一筐菜两秒钟就处理完、然后干等下一筐（算术强度低），那瓶颈在传送带，这时候你把厨师换成动作快一倍的，菜上得也不会更快——这就是 memory-bound。
三、为什么 LayerNorm 是 Memory-bound
把 LayerNorm 拆开看一眼就明白了：它对每个元素做的事，无非是读进来、参与求均值和方差、减均值除标准差、再乘 γ 加 β，然后写回去。每个元素摊到的浮点运算就那么十来次，但读和写的字节数实打实地少不了。
算下来，它的算术强度（FLOPs/Byte）非常低，稳稳地落在 Roofline 图的左侧斜坡区。作为对比，矩阵乘法（GEMM）因为数据复用率极高，算术强度能到几百，妥妥落在右侧平台区——这才是该上 FP16/Tensor Core 的地方。
现在回到开头那个坑：把 LayerNorm 的计算从 FP32 换成 FP16，本质上只是把"算力天花板"抬高了一截，可它既没改变"峰值带宽"，也没改变"算术强度"。你人还卡在斜坡上呢，天花板抬得再高也够不着。
一句话：对 memory-bound 的算子提算力，等于给一个被传送带卡住的厨房换了个手更快的厨师——白搭。
四、那 FP16 到底怎么用才对？—— 让搬运的字节数减半
FP16 不是没用，而是用错了地方。对 memory-bound 算子，正确的用法不是"算得更快"，而是"搬得更少"。
具体做法是：把显存里存的数据格式本身存成 FP16。这样每次读写,传输的字节数直接砍掉一半。
为什么这就真能提速？因为对一个 memory-bound 的算子来说，它的运行时间约等于搬运的总字节数 ÷ 峰值带宽。字节数减半，时间也大致减半（实际中还有归约、γ/β、固定的 kernel 启动开销，所以是"接近减半"而非精确两倍）。换个角度看，分母（字节）减半，算术强度直接翻倍——这才是把算子往拐点方向推。
关键区别一定要记牢：FP16 提速的来源不是"算得快"，而是"过总线的字节少了一半"。计算精度对 memory-bound 算子几乎无所谓，传输数据量才是命门。
五、更治本的办法：算子融合（Kernel Fusion）
减少字节数还有一招更狠的——算子融合。
一个没融合的网络，算子之间是这么干活的：LayerNorm 把结果写回显存（HBM），下一个算子（比如加 Bias、过激活函数）再把它从显存读回来。每一次"写回去 + 读回来"，都是一趟昂贵的显存往返。对 memory-bound 的算子来说，这种中间结果的反复进出，就是时间的大头。
融合的思路是：把 LayerNorm 和它前后的操作（残差相加、加 Bias、激活函数等）合并成一个 Kernel，让中间结果待在寄存器或片上 SRAM 里，根本不落地到 HBM。少一趟显存往返，就省下一笔带宽。
举个直观的账：原本残差相加 → LayerNorm → Dropout三个独立算子，中间结果要在 HBM 上来回好几趟；融合成一个算子后，数据读进来在片上一口气算完再写出去，HBM 流量可能直接降到原来的三分之一。对带宽受限的算子，HBM 流量降多少，时间基本就降多少。
这也正是 FlashAttention 这类工作快的根本原因——它把整个 attention 的计算融进一个 Kernel，避免了巨大的中间矩阵在 HBM 上反复进出。本质上还是那句话：省的不是算力，是访存。
六、把镜头拉远：CPU → GPU 的搬运，藏着一模一样的坑
上面讲的是显存内部的"内存墙"。它有个孪生兄弟，藏在更外层——CPU 到 GPU 的数据通路上。同样的道理，换个楼层重演一遍。
场景是这样的：训练一个图像模型，GPU 利用率只有 60%。打开 Nsight Systems（nsys） 看 timeline，发现 GPU每算完一个 batch，就空闲一小段，然后才接着算下一个。
num_workers已经开到 8，prefetch_factor=2也加了，GPU 还是有空闲。再看代码，发现有人写了这么一段，并坚称"这样能让数据搬运异步进行"：
for images, labels in dataloader: # 以为 non_blocking=True 就异步了 images = images.cuda(non_blocking=True) labels = labels.cuda(non_blocking=True) outputs = model(images) loss = criterion(outputs, labels) loss.backward() optimizer.step()non_blocking=True加了，那段空闲却没消失。问题出在哪？
答案是：漏了一个绝对的先决条件。
七、non_blocking=True的隐藏前提：源数据必须是 Pinned Memory
要讲清楚，得先分清两种 CPU 内存：
- 可分页内存：普通申请的内存，操作系统可以随时把它换页到磁盘。CPU 张量默认就在这儿。
- 页锁定内存：被钉死在物理内存里、不会被换页的内存。
GPU 的异步拷贝（cudaMemcpyAsync）靠的是DMA——绕过 CPU，让硬件直接把数据从内存搬到显存。而 DMA 有个硬性要求：源地址必须是页锁定的，因为只有钉死的物理地址，硬件才敢放心地直接搬。
所以，如果你的源张量在可分页内存里，会发生什么？CUDA 驱动没法直接 DMA，它只能先把数据同步地拷到一块内部的 pinned 暂存缓冲区，再从那儿往显存搬。这个"先同步拷一次"的动作会阻塞住 CPU。结果就是：你的non_blocking=True等于白写了——传输实际上还是同步的，这个标志被悄悄忽略掉。
CPU 卡在拷贝上 → 拷完才去排下一步的计算 → GPU 算完当前 batch 只能干等下一批数据。那段"空闲"就是这么来的。
修复只要一行——在 DataLoader 里打开pin_memory：
dataloader = DataLoader( dataset, batch_size=..., num_workers=8, prefetch_factor=2, pin_memory=True, # ← 关键的一行 )打开之后，DataLoader（通过专门的 pin_memory 线程）会提前把取好的 batch 拷进页锁定内存。这下images.cuda(non_blocking=True)才能走真正的异步 DMA：
- 拷贝本身更快——pinned DMA 不用经过同步暂存，带宽通常能到可分页拷贝的近两倍；
- CPU 不再被拷贝阻塞——
non_blocking调用立刻返回，CPU 得以一路往前跑，把后面的前向、反向 kernel 源源不断地塞进 GPU 的命令队列。
CPU 跑在前面、队列里始终有活，GPU 就不会饿着——那段空闲随之消失。
八、再进一步：prefetch 与双流，把拷贝彻底藏进计算里
pin_memory=True+non_blocking=True是消除空闲的关键修复，对绝大多数情况已经够用。
如果还想把吞吐压到极致，可以再往前一步：用一个手写的 prefetcher，在一条独立的 CUDA Stream 上，提前发起"下一个 batch"的 H2D 拷贝，让它和"当前 batch"的计算真正并行重叠——计算在跑的同时，下一批数据已经在悄悄搬运，拷贝延迟被完全藏进计算里。NVIDIA 的data_prefetcher写法、以及 DALI 这类数据加载库，做的就是这件事。
但顺序别搞反：先用pin_memory=True把地基打好，让non_blocking真正生效；双流 overlap 是锦上添花的进阶项。
总结：一切优化，从定位瓶颈开始
回头看这两个场景，会发现它们是同一个故事的两个版本：
| 现象 | 容易误判的"病因" | 真正的瓶颈 | 正确解法 |
|---|---|---|---|
| LayerNorm 换 FP16 不变快 | 算力没拉满？ | 显存带宽（memory-bound） | 算子融合 / 用 FP16存储减少搬运字节 |
| GPU 算完一个 batch 就空闲 | num_workers不够多？ | CPU→GPU 搬运 + 同步阻塞 | pin_memory=True让non_blocking真正生效 |
两个坑的共同点都是：误把"算力/并行度不够"当成病因，实际上瓶颈在数据搬运。
所以做性能优化，养成一个习惯：动手改之前，先用 Roofline 模型（或者 Nsight 的 timeline）把瓶颈定准——这个算子是被算力卡住，还是被带宽卡住？数据是没喂上来，还是计算本身慢？
先看清楚卡在哪，再决定往哪使劲。不然就像那个换了手更快的厨师——忙活半天，菜还是上得一样慢。