4、动态形状对算子性能的影响：访存模式变化、计算效率下降、算子融合失效
好，咱们接着聊动态形状。前面几章我们讲了动态形状的定义、来源，还有它带来的那些麻烦。这一章，我想深入聊聊一个更实际的问题——动态形状到底是怎么拖累算子性能的。
说白了，动态形状不是“偶尔变一下”那么简单。它会让你的GPU计算变得很不规律。我见过不少团队，模型精度调得挺好，一上动态形状推理，延迟直接翻倍。为什么？
原因主要集中在三个方面：访存模式变化、计算效率下降、算子融合失效。咱们一个一个拆开看。
4.1 访存模式变化：从连续到随机
先说说访存。GPU的显存带宽虽然高，但它最怕什么？最怕非连续访问。
静态形状下，数据在显存里是规规矩矩排好的。比如一个[B, 128, 128]的矩阵，每个batch的数据紧挨着。GPU读取的时候，可以一次读一大块，这叫合并访问（coalesced access）。效率很高。
但动态形状一来，情况就变了。假设batch size从1变到8，或者序列长度从64变到512。数据布局可能就不再连续了。你想想看，每次推理时，数据在显存里的“脚印”都不一样。GPU的缓存（L1/L2 cache）根本来不及适应。
我在项目中遇到过这样一个场景：一个Transformer模型，输入序列长度动态变化。静态形状时，显存带宽利用率能到80%以上。动态形状一开，直接掉到40%。
核心问题：动态形状导致数据访问模式从“连续大块”变成“离散小块”。GPU的缓存命中率下降，访存延迟显著增加。
为什么会这样？因为GPU的warp调度器是按固定大小（比如32个线程）来读取数据的。如果数据不连续，有些线程读到的数据是无效的，或者需要多次访存才能凑齐。这就是所谓的访存发散（memory divergence）。
嗯，这里要注意：访存发散是动态形状下最隐蔽的性能杀手。它不像计算瓶颈那么明显，但往往贡献了30%-50%的额外延迟。
4.2 计算效率下降：小形状下的“空转”
访存问题说完，咱们看看计算效率。
GPU的计算单元（CUDA core / Tensor Core）喜欢什么？喜欢大块、规整的数据。比如矩阵乘法，[1024, 1024] x [1024, 1024]，计算效率接近理论峰值。
但动态形状下，经常出现小矩阵。比如batch size=1，或者序列长度很短。这时候，计算单元就“吃不饱”了。
我举个例子。一个[1, 128, 128]的矩阵乘，和[128, 128, 128]的矩阵乘，计算量差了128倍。但启动kernel的开销（launch overhead）几乎一样。你想想看，小矩阵的计算时间可能只有几微秒，但kernel启动就要花几十微秒。这就是典型的计算效率下降。
我的经验：当矩阵维度小于256时，计算效率通常不到理论峰值的20%。这时候，瓶颈往往不在计算，而在kernel启动和访存。
还有一个更隐蔽的问题：Tensor Core的利用率。Tensor Core要求输入数据满足特定的对齐条件（比如16x16的tile）。动态形状下，如果维度不是16的倍数，Tensor Core就用不了，只能退回到普通的CUDA core。这一退，性能直接腰斩。
我记得有一次调试一个动态形状的BERT模型，发现某个矩阵乘的维度是[1, 77, 768]。77不是16的倍数，Tensor Core罢工了。后来我做了padding到80，性能提升了40%。
避坑指南：我曾经因为没检查Tensor Core的对齐条件，浪费了整整两天。建议你在动态形状推理时，显式检查每个算子的输入维度是否满足硬件对齐要求。不满足的话，要么padding，要么换算子实现。
4.3 算子融合失效：优化链条断裂
最后，也是最让人头疼的——算子融合失效。
算子融合是推理优化的核心手段之一。比如把“卷积+BN+ReLU”融合成一个算子，减少访存和kernel启动开销。静态形状下，融合后的算子可以提前编译好，直接调用。
但动态形状下，融合就变得很棘手。为什么？因为融合后的算子需要知道输入的形状。如果形状是动态的，编译器就无法生成最优的融合代码。
举个例子。一个融合了“矩阵乘+加偏置+ReLU”的算子，在静态形状下，编译器可以把所有循环展开，寄存器分配也做到最优。但动态形状下，编译器只能生成通用的、带循环和条件判断的代码。这性能差距，可能达到2-3倍。
更糟糕的是，有些融合策略在动态形状下根本不能做。比如，某些融合需要知道中间张量的具体大小，才能决定是否在寄存器中传递数据。形状一变，中间张量可能太大，寄存器放不下，只能写回显存。这一写一回，融合的优势全没了。
关键点：动态形状下，算子融合的收益会显著下降。你辛辛苦苦做的融合优化，可能因为形状一变就失效了。
我建议的做法是：对动态形状做“分桶”处理。把可能的形状分成几个区间（比如小、中、大），每个区间内用静态形状的融合策略。这样虽然不能覆盖所有情况，但至少能保证大部分场景的性能。
4.4 总结：一张表看清影响
好，咱们把这三个方面的影响总结一下。我习惯用一张表来对比，这样更直观。
| 影响维度 | 静态形状 | 动态形状 | 性能损失 |
|---|---|---|---|
| 访存模式 | 连续、合并访问 | 离散、非合并访问 | 30%-50% 带宽浪费 |
| 计算效率 | 高利用率（>80%） | 低利用率（<20%） | 2-5倍计算延迟 |
| 算子融合 | 可提前编译，最优代码 | 需运行时编译，通用代码 | 2-3倍融合收益下降 |
你看，这三个方面不是孤立的。访存模式变化会导致计算单元等待数据，计算效率下降又会让融合失效的影响更明显。它们互相叠加，最终让动态形状推理的性能变得很难预测。
我个人习惯是，在项目初期就明确动态形状的范围。比如，batch size是1-8，还是1-32？序列长度是64-512，还是128-1024？范围越窄，优化空间越大。如果范围太宽，那就要考虑用动态编译或者形状自适应算子了。这些我们后面章节会详细讲。
嗯，这一章就到这里。下一章，我会聊聊如何通过形状对齐和padding来缓解这些问题。到时候见。