GEMM

对 $A\in\mathbb{R}^{M\times K}$ 和 $B\in\mathbb{R}^{N\times K}$，计算 $C=AB^{\top}$ 得到 $M\times N$ 的输出。这里的转置描述数学运算。

实际 kernel 根据 stride、描述符和指令要求读取数据。支持现有布局时，可以直接计算；需要重新打包、对齐或改布局时，才产生额外的数据搬运。

忽略缩放与偏置，乘加按两次浮点操作计数，工作量约为 $2MNK$。若 A、B 各从显存读一次、输出写一次，元素字节数分别为 $b_A,b_B,b_C$，下面给出理想化的显存算术强度。实际重复读取和附加操作会改变它。

当 $M$ 很小时，读取 B 的成本可能主导。增大 M 让同一份权重参与更多计算，通常提高复用，但最终还要看缓存、调度和计算吞吐。

增大输出 tile 可以提高输入复用，也会增加累加器和缓冲区占用。资源压力可能降低常驻 block 数，甚至造成寄存器溢出。

大 tile 还会减少可分配的任务数量。矩阵边缘的无效工作与最后一波没有填满的 SM，可能抵消复用带来的收益。

K tile 决定每轮沿归约维处理多少数据。stage 数决定同时在流水线中保留多少组输入缓冲区。两者都影响 shared memory 用量，但解决的问题不同。

增加 stage 可以让搬运更早开始；增大 K tile 会改变每轮的搬运和计算工作量。调优时需要一起检查资源占用和等待时间。

拷贝完成表示输入可以交给消费者。消费者发出的异步矩阵指令，还可能继续从这块 shared memory 读取数据。

复用缓冲区前，要等待相关读取结束，再把空闲阶段交还给生产者。否则下一轮拷贝可能覆盖正在计算的输入。

Triton 教程把 program ID 映射到分组后的输出 tile，以改善相邻工作之间的数据复用。这个映射改变谁处理哪块数据。

普通 grid 中的 block 调度顺序没有因此获得保证。需要显式控制工作分配时，可以研究 persistent kernel 的 tile scheduler；它也需要正确处理跨 CTA 的依赖。

当 M/N 较小而 K 较大时，可以把一个输出 tile 的归约工作分给多个 CTA。这样增加并行工作，但每个 CTA 只得到部分和。

Split-K 按设定的份数切分 K。Stream-K 从整体的内循环工作量出发分配任务，缓解尾波负载不均。切开的输出仍需要归约，收益要覆盖额外的同步和数据搬运。

输入存储、scale、乘法与累加结果可以使用不同格式。低精度 GEMM 的接口还需要说明缩放粒度、scale 布局以及输出类型。

同样叫 FP4，也可能采用不同的 block scaling 格式。比较性能前，先对齐数值路径与误差要求，再把量化、打包和 scale 处理的成本算进实际调用。

路由后，各专家收到的 token 数可能不同，也就产生不同 M 的矩阵乘法。Grouped GEMM 把这些问题交给同一个调度体系，减少逐个启动小 kernel 的成本。

它仍要面对不均匀的工作量。连续布局与 masked 布局适合不同的输入组织方式，不能只按总 FLOPs 判断哪一个更快。

先对齐 shape、布局、输入和累加精度、输出操作与误差检查。把编译、初始化和预热放在稳态计时之外，用 GPU 计时记录多次运行。

明确测试热缓存还是冷缓存，并保持相同设置。记录 GPU、软件版本、功耗和频率条件。若比较应用收益，再把量化、转置、分配与后处理等实际开销计入。