手写GEMM内核：矩阵乘法性能优化的完整工程实践

做推理优化这些年，我越来越确认一件事：深度学习的大部分算力消耗，最终都落在矩阵乘法上。无论是全连接层、卷积的隐式派生命令，还是自注意力里的Query乘Key，扒开底层全是一块接一块的GEMM（General Matrix Multiplication）。我自己搞一个名为DeepGEMM的实验项目时，目标很直接：不依赖厂商矩阵库，把矩阵乘法内核重新写一遍，追求接近硬件理论峰值的性能。这篇文章就是这次重写的完整记录，把我碰到的分块策略、存储搬运、软件流水线、精度取舍和排障过程都摊开讲。打算钻研算子优化、推理加速、或者单纯想知道“为什么矩阵库能跑那么快”的朋友，这篇内容应该能给你一套明确的思路，而不是只看到一堆晦涩的汇编指令。

1. 为什么一个矩阵乘法内核值得亲手写一遍

1.1 矩阵乘法在深度学习里的潜伏范围

很多人以为优化GEMM只是在优化“矩阵相乘”这一个操作，真正把网络结构铺开看，它的覆盖面远比想象中大。全连接层天然就是GEMM：输入批次M个样本，每个样本长度为K，权重矩阵是K乘以N，一次前向就是M乘K乘N的矩阵乘。卷积层如果走im2col路线，把输入Patch展开成矩阵，卷积也变成了GEMM。注意力机制更直白，Q乘以K的转置是一个GEMM，softmax之后的结果再乘以V又是一个GEMM，多头注意力就是把多个小GEMM拼在一起。

我测过一个典型的Transformer推理工程，profiler结果里GEMM内核占掉整体执行时间的大头，剩下的算子加起来都不到三分之一。也就是说，哪怕把其他所有算子优化到极致，矩阵乘法不做优化，整个服务的时延瓶颈依然死死卡在同一个位置。这也是为什么我要专门针对GEMM做一个深度优化项目，不是因为它看起来“高级”，而是因为每个算子开发的人迟早都要面对这块硬骨头。

1.2 厂商矩阵库“快”的真相不是玄学

很多人有过这种体验：自己用三循环或者简单分块写出的矩阵乘法，被厂商自带的矩阵库按在地上摩擦，甚至性能差出数量级。于是产生一个误解：矩阵库用了什么黑科技算法。实际上，对方做对的事情完全可以拆解成几条明确原则：第一，小块数据尽可能住在寄存器里，而不是反复从显存搬运；第二，计算和拷贝在时间上重叠，让硬件部件一直处于忙碌状态；第三，针对硬件的特殊矩阵指令做了精细的寄存器排布，而不是让通用编译器自己去猜。

这三点每一条背后都有大量工程细节。比如寄存器排布，在不同指令形态下，参与矩阵乘的每个线程到底持有哪个元素、哪个元素必须交给哪个邻居，都有明确规则。稍微错一位，性能可能掉一半。DeepGEMM这个实验工程所做的，就是把这套规则用自己的代码重新实现、验证、量化。做完之后再看厂商矩阵库的profile输出，你不会觉得它快得神秘，而是能大概看出它做了哪几层优化。

1.3 我给自己定下的项目指标与边界

动工之前先定清楚目标：输入输出全部为FP16数据，计算用混合精度（输入FP16、累加FP32），支持M、N、K三个维度从1到几千的任意形状，并且对常见尺寸能达到硬件理论峰值的75%以上。边界也划清楚：不引入搜索引擎级别的自动调优，不做多个kernel的运行时选择，全部手动定参数，只针对最常见的“大矩阵”场景优化。

这个指标不算激进，但足够逼人把基本功做扎实。因为一旦目标定到75%，你会发现靠编译器自动向量化根本不可能，必须自己上手管寄存器、管共享内存、管异步拷贝、管指令调度。整个项目做下来，我最大的收获不是“我能写出一个更快的GEMM”，而是终于能把计算机体系结构里那些抽象概念，像Cache、并行、流水线、Bank冲突，在实际程序里一一对应起来。

2. GEMM启动前需要认清的硬件资源底账

2.1 GPU到底怎么执行一条矩阵乘指令

在动手写任何代码之前，必须先搞明白GPU底层的基本执行模型。现代GPU的调度单位是线程束（Warp），通常32个线程为一组，它们共享一套程序计数器，意味着同一时刻执行同一条指令。一个GPU芯片被拆分成多个流处理器（SM），每个SM内部有独立的寄存器堆、共享内存和缓存体系，可以同时驻留多个线程束。

过去做通用计算时，矩阵乘法是通过反复执行乘加指令（FFMA）完成的：每个线程取两个数相乘，再加到累加器上。现在硬件提供了专门为矩阵乘法设计的指令，称为Tensor Core类指令，它不再让32个线程各自算各的，而是让整个线程束协同计算一个比较大的子矩阵块。比如一类常见形态，一个线程束执行一次指令，可以完成16乘以8乘以8的块乘累加，也就是说256个乘加运算被一条指令包住，而普通FFMA指令一次只能做一个乘加。

这就解释了为什么现代GEMM性能差距如此悬殊：你的代码如果没有触发Tensor Core，即便循环优化得再好，乘加指令的吞吐也远远落后。而DeepGEMM这类项目，第一步就是把Tensor Core指令的寄存器布局和匹配规则吃透。

2.2 从全局内存到寄存器：一场带宽的降维打击

GPU存储体系像一个多层漏斗。全局内存容量最大，但带宽和延迟都最差；共享内存是SM内部的高速存储，速度比全局内存快一个数量级；寄存器是最快的存储，就在计算单元旁边。数据要参与计算，必须经过“全局内存->共享内存->寄存器->计算单元”这条路径。

我把常见的带宽量级整理了一张表，好让大家心里有数：

从这个表能得出一个最重要的优化方向：绝不能频繁从全局内存捞数去算。一次全局内存访问的延迟，足够寄存器执行上百次运算。所以GEMM优化的第一性原理，就是把数据切成合适大小的块，搬到共享内存里反复使用，再从共享内存搬到寄存器里做真正的计算，每一层搬运都要尽量少、尽量齐整。

2.3 Tensor Core类指令的形态差异

不同代际硬件对矩阵指令的支持宽度不同，常见的有16乘8乘16、16乘8乘8这类参数形态。参数含义类似：指令处理的子矩阵行数、列数和内积维度。同时输入精度的组合也影响性能，比如FP16输入配FP32累加通常是比较高效且稳定的选择，TF32则是牺牲一些尾数位来换取更大的指数范围。

具体到DeepGEMM项目的实现上，我选择寄存器分块再加Tensor Core指令的路线。线程束内每个线程持有C矩阵分块里的一块碎片，多个线程的碎片拼成一个完整子矩阵。为了配合指令的k维宽度，每次累积K维的一小段，K循环不断推进。这里最反直觉的一点是：矩阵乘法的循环最内层早就不再是“乘加”，而是“搬运和排布”。真正把大块乘加交给Tensor Core后，CPU核心里剩下的工作更多是在等数据到位。

2.4 用Roofline模型判断自己缺的是计算还是带宽

写内核之前还要做一个关键判断：当前场景是计算密集还是访存密集。Roofline模型提供了很简单的做法：算出目标矩阵乘法的算术强度（FLOP除以Byte），再看硬件平台上“每秒浮点次数”和“带宽”的比值，这个比值叫做机器的操作强度。如果算法算术强度低于机器操作强度，说明带宽会先到瓶颈，优化重点要放在减少访存上；如果高于，说明计算是瓶颈，优化重点放到触发更高效的指令上。

对于深度学习中常见的大GEMM，算术强度通常很高，比如两个1024方阵相乘，算完需要大约20亿次浮点运算，而数据量只有几MB，典型的计算密集场景。问题就转化为：怎么让计算单元别闲着。标准答案是分块：让数据块在共享内存和寄存器里循环复用，把每个数据的平均搬运成本压到极低。DeepGEMM的主循环设计，就是围绕这个答案展开的。

3. 分块与线程映射：一个内核的骨架如何设计

3.1 为什么BM、BN、BK取这些经典数值

GEMM分块的核心参数是BM、BN、BK，分别对应M方向每个CTA（协作线程块）负责的行数、N方向每个CTA负责的列数、K方向每次循环推进的大小。常见的组合是BM=128、BN=128、BK=32，这个选择不是拍脑袋，背后有三个约束：共享内存容量、寄存器数量、指令块尺寸。

先用共享内存算一笔账：A矩阵的一个Tile是BM乘BK，B矩阵的一个Tile是BK乘BN，FP16类型每个元素占2字节。以128乘32和32乘128为例，两个Tile各自占用8KB，合计16KB。如果再做双缓冲，就需要32KB。这个容量在现代SM的共享内存预算内，能保证足够多的CTA驻留，用并发隐藏延迟。再来算寄存器：BM=128、BN=128的C矩阵分块包含16384个FP32累加元素，如果全放寄存器，需要每个线程平均持有512个寄存器，这显然超标。于是C矩阵也得分块到指令粒度，让每个线程只负责其中一小片。

我最终选了128乘128乘32这个组合，并配合CTA内256个线程的布局。这样每个线程管理C矩阵中的一小块，寄存器压力在可控范围内，同时共享内存占用还有余量做流水线缓冲。读者如果做不同形状优化，可以按同样的思路反推参数，而不是照抄数值。

3.2 主循环结构与K维累积

GEMM的K维是内积累积的维度。物理含义很清楚：C矩阵的每一个输出点，都需要把A的一整行和B的一整列做内积。如果不分块，K维全长都会串行依赖；分块之后，K循环变成一小段一小段推进，每次从全局内存取一小片A和B，更新一次C的累积结果。

DeepGEMM主循环的伪代码逻辑大致如下：

// 伪代码：CTA级别的主循环结构 for (int k = 0; k < K; k += BK) { // 第一步：异步搬运当前K段所需的A块、B块到共享内存 cp_async(A_smem, A_global + offset_a, bytes_a); cp_async(B_smem, B_global + offset_b, bytes_b); commit_group(); // 第二步：等待这一批搬运完成 wait_group(0); // 第三步：从共享内存加载A块、B块到寄存器，并进行重排 load_and_permute(A_reg, A_smem); load_and_permute(B_reg, B_smem); // 第四步：用Tensor Core指令执行A_reg x B_reg，累积到C_reg mma(C_reg, A_reg, B_reg, C_reg); }

循环的每一步都只负责BK大小切面，C矩阵的累积值一直住在寄存器里。这个设计的好处是：一个输出数据块从首次读取到最终写回，在寄存器里被反复更新很多次，访存次数被压缩到理论最低。

3.3 线程协作布局：谁手里到底握着哪片C

这一节是整个内核设计里最容易绕晕的地方，值得多花点篇幅讲清楚。Tensor Core指令对线程布局有硬性要求。假设指令处理16乘8的输出块，32个线程会被组织成一个4乘8的二维逻辑网格。每个线程持有该输出块中特定位置的两个元素，具体怎么分配由指令语义决定。

DeepGEMM的CTA里，我把M维度拆分给线程组的横向排列，N维度拆分给纵向排列，然后让每个线程重复拥有多个小碎片。举个例子，一个128乘128的C分块，由256个线程协作，每个线程最终平均持有64个FP32累加值。这64个值不是连续存储的，而是按照指令的布局规则分散在寄存器编号的不同位置。

这样做的好处是：计算完一个Tile后，寄存器里已经天然是按指令要求的排列，直接喂给下一条Tensor Core指令即可，不需要额外重排。很多第一次写GEMM的人把性能写崩，就是因为在寄存器布局上没对齐指令的胃口，导致每次计算前都要从共享内存重新读、重新摆，白白增加大量搬运。

3.4 非整除形状与边界处理

现实中的矩阵很少恰好是128的整数倍，所以边界策略不可回避。主流的做法有两种：Pad补齐与谓词截断。

Pad补齐的思路是在分配共享内存时按对齐后的尺寸开空间，从全局内存拷贝时，不足的部分补零。补零的好处是主循环完全不用分支，所有线程走同一套代码，不产生线程束分化。代价是边界Tile有一点无效计算，但通常占比很小。

谓词截断则是每次搬运或者计算前判断当前坐标是否越界，越界就跳过。这样做更省算力，但会在边界处引入分支，而GPU对分支发散相当敏感。我的实测结论是：对偶发的边界Tile，Predicate的收益远不如它带来的分支开销，所以DeepGEMM统一采用Pad补齐，K维不整除时也把共享内存多留出一块，用零填充。这样既简洁又稳定，性能差异在1%以内。

4. 数据搬运的实战关卡：共享内存、Bank与异步拷贝

4.1 让拷贝先飞一会儿：异步拷贝的节奏

数据从全局内存到共享内存的搬运，是GEMM内核里最容易被忽视的隐形瓶颈。同步搬运的意思是拷贝没完成前，计算必须等待，计算单元被迫空转。异步拷贝则是把搬运动作提交给硬件后台，提交完立刻返回，计算继续跑自己的，等到真正需要这批数据时再去“收取”。

DeepGEMM里我对异步拷贝的控制很简单：每次循环开始时，先提交下一轮需要的A块和B块拷贝，然后才处理当前轮的计算。当前轮算完时，下一轮的数据往往已经到了，再提交下下一轮。这个“先提交、后使用、再提交”的节奏，就是软件流水线的雏形。关键方法论是：不要一次性把整个K维数据全搬进来，那会占满共享内存；也不要搬一段算一段，那会浪费等待延迟。最好的是切到正好让搬运和计算重叠的长度。

4.2 共享内存Bank冲突：性能悄悄腰斩的真凶

共享内存虽然比全局内存快很多，但它有一个特殊限制：物理上被划分为若干个Bank，同一周期内不同线程访问不同Bank时并行，访问同一个Bank时就会发生冲突，硬件只能串行处理。如果32个线程同时落在一个Bank上，理论带宽直接降到三十二分之一。

我的第一个正确版本在实测时性能只有预期的60%，怎么调指令都不能提升。后来用性能分析工具一查，发现共享内存访问阶段出现了严重的Bank冲突。问题出在B矩阵的Tile布局上：当线程按照某个步长读取数据时，因为Bank的地址映射是按固定间隔均匀分布的，而我的数据排列方式恰好让每两个线程访问同一Bank，冲突倍数高达8，效率白白丢掉了一大截。

4.3 Padding：给矩阵“加个垫片”化解冲突

破解Bank冲突的标准办法是给共享内存数组加Padding，也就是每行多出几个元素不存数据。原理很简单：如果每行长度为32的倍数，那么不同行相同列的数据会映射到同一个Bank，线程很容易撞车；每行长33后，行与行之间错开一格，相同列的地址在Bank层面错开了，冲突自然被拆散。

DeepGEMM的做法是：给A矩阵的共享内存每行补4个元素，B矩阵的共享内存每行补4个元素。实测下来，冲突倍数从8降到了接近1，共享内存访问的整体耗时几乎缩短了一个数量级。代价只是共享内存多了不到10%的浪费，非常划算。如果你自己实验也遇到诡异的速度瓶颈，先查Bank冲突，这种问题不看硬件事件计数器的话，光靠读代码很难发现。

4.4 跨线程的数据重排：从共享内存到寄存器不能硬搬

共享内存里的数据布局，和Tensor Core指令期望的寄存器布局通常是两套体系，中间必须有一层重排。Copy某个指令是专门为这个场景设计的，它能把共享内存里按特定规律排列的矩阵数据，一次加载到线程束内多个线程的寄存器中，并且自动完成跨线程的转置与分布。

这是我的内核里最容易写错的部分，因为没有直观的类比。你可以想象成：仓库里货物按“箱子编号、层号”摆放，但生产线的机器要求“层号、箱子编号”的顺序，仓库到生产线中间有个自动分拣台，这个分拣台就是重排指令。刚开始我对它的参数理解不到位，加载出来的寄存器里元素位置和指令期望对不上，计算结果完全错乱。后来我把一个小矩阵的期望元素布局打印出来，和实际寄存器值做逐一对照，才彻底调通。建议任何写GEMM内核的人，第一步都先用4乘4的小块做单元验证，而不是上来就挑战大矩阵。

5. 软件流水线与计算重叠：让SM真正忙起来

5.1 三段式结构：序曲、主循环、尾声

一个高性能GEMM内核的时间线可以分为三个阶段：序曲（Prologue）、主循环（Steady State）、尾声（Epilogue）。序曲阶段先提交前面若干轮的数据搬运，让流水线“注满”；主循环阶段搬运与计算稳定重叠；尾声阶段处理最后一轮的数据并完成结果写回。

用流水线的视角看，整个内核就像一个工厂流水线：序曲就是让传送带上先有半成品，主循环就是稳定的加工节奏，尾声是把最后一批工件加工完。如果没有序曲直接进入主循环，第一轮计算必须干等数据到达，流水线起点就空了。DeepGEMM里我设置了2到4个阶段的预取缓冲，保证任何时候共享内存里都存着接下来几轮要用到的数据，计算单元几乎永远不必等待访存。

5.2 阶段数选择：双缓冲、三缓冲还是更多

阶段数（Stage）决定共享内存里同时存几组A/B分块。双缓冲是最常见的起点：一组数据在算，一组数据在搬。三缓冲则让搬运的延迟容忍度更高，因为即使某一轮的搬运稍有延迟，计算单元还可以切到更早备好的另一组数据。

我在DeepGEMM里实际对比了双缓冲和三缓冲。关键约束在于共享内存总容量：BM=128、BN=128、BK=32时，每组A+B块占16KB，双缓冲占32KB，三缓冲48KB。对常见的硬件配置来说，三缓冲依然能保证2个CTA同时驻留，而四缓冲就会把并行驻留数量压低到1，反而可能因为无法用另一个CTA隐藏延迟而得不偿失。实测中三缓冲比双缓冲有5%左右的稳定收益，四缓冲则出现倒车。

5.3 寄存器压力与Occupancy的平衡

Occupancy指的是SM上同时驻留的线程束数量，它直接决定了隐藏各种延迟的能力。寄存器数量是限制Occupancy的最常见因素。GEMM内核天生想多占寄存器：C矩阵的累加值、A/B矩阵的临时片段、各种循环变量，动辄上百个寄存器。

我在调DeepGEMM时遇到一个两难：每个线程持有的C分块越大，复用率越高，但寄存器占用越猛，驻留线程束越少。这一步我做了完整的参数扫描：把BM、BN在64到256之间变换，记录每种组合下的寄存器用量、Occupancy和实测GFLOPS。结果发现，过高的Occupancy并不总是好事，因为一旦每个线程分到的计算量太少，调度开销相对增加，性能反而下降。最终我选了让Occupancy大约50%到75%之间的配置，此时每个线程持有足够多的累加数据，重复计算效率最高。

5.4 异步拷贝的提交与等待：一个容易被忽略的细节

异步拷贝并不是完全“异步”，它需要你在合适的时机执行等待操作，确认提交的数据已经到达。等待时机选晚了，计算会读取未就绪的数据产生错误；选早了，本该隐藏的延迟又暴露出来。

DeepGEMM的典型做法是：在发出下一轮拷贝后，只等待前一轮提交组完成，而不是无脑等待所有组都完成。代码上表现为类似“提交一组拷贝，然后等待上一组完成”。这个“提交未来、等待过去”的错峰方式，能精确保证每一轮计算开始时，它需要的数据已到达。类似的方法论是分而治之：把拷贝分组管理，每次只关心当前依赖的那一组，而不是整体同步。

6. 数值精度与FP16/BF16/TF32的选择

6.1 三种低精度格式的差别远比想象大

深度学习GEMM输入数据的格式直接影响结果正确性与训练收敛。FP16是典型的16位浮点数，它有若干位的指数和若干位的尾数，精度较高但取值范围有限，太大或太小的数都容易溢出。BF16则采用与FP32相同的指数位，但尾数位被大幅压缩，它更擅长表示大范围数字，代价是精度粗糙。TF32介于两者之间，用与FP32相近的指数范围配合减少的尾数位，适合不需要很深精度的场景。

我把三者做了直观对比：

6.2 中间累加必须用FP32，别图省事

几乎所有Tensor Core指令都支持“低精度输入、高精度累加”。也就是说，输入的A和B可以是FP16，但乘法结果会以FP32精度累加。这是GEMM精度设计的生命线：矩阵乘法的内积本质是一个K维求和，如果每一次加法都在低精度下执行，舍入误差会随矩阵规模增长而积累，最后结果可能越来越离谱。

我做过一个简单的实验：分别用FP16累加和FP32累加计算同一个4096维内积，前者最终结果的相对误差是后者的几十倍。DeepGEMM从一开始就坚持FP32累加寄存器，而且这个选择几乎不消耗额外性能，因为Tensor Core指令本身就支持。这是少数几个“零成本提升精度”的优化点，不做才是真的亏。

6.3 防止溢出的Chunked GEMM策略

当输入数据方差较大时，即使累加用FP32，输入本身在FP16范围内的溢出风险依然存在。最典型的例子是注意力分数的计算，中途数值可能超过FP16的表示上限。DeepGEMM项目中我预留了一个参数来控制内积的分段长度：把K维分成多段，每段内累积结果后先用FP32做一次缩放，再继续下一段。

这个做法在深度学习里很常见：不是改变计算精度，而是调整数值的缩放尺度。应用上，可以选择每个输入Tile额外建立一个最大值统计，然后对数据统一做归一化缩放。这多出一点额外计算，但在稳定性要求高的场景下完全值得。如果你的模型在线推理时偶尔出现NaN，先查的往往不是内核逻辑，而是数值范围。

7. 性能调优踩坑实录

7.1 现象：分块全部正确，性能卡在理论峰值的30%

DeepGEMM第一个“正确”版本跑通后，我测了一下大矩阵性能，数字相当难看：只有硬件理论峰值的30%。更令人困惑的是，算法逻辑看起来完全合理：分块大小合适，指令也用上了，共享内存也没超限。这让我意识到，性能和正确性是两个维度的问题，正确只保证你启动了所有必要的运算，没保证运算在正确的节奏上执行。

于是我开始一步步排查。先看内核整体耗时占比，再看存储层级的访问事件，最后定位到共享内存的Bank冲突以及寄存器分配不合理两个主要问题。这个过程给我最重要的启示：性能分析工具的计数器数据，比直觉可靠得多，你不应该只盯着代码“觉得”哪里慢。

7.2 排障链路1：共享内存Band冲突的完整定位

使用性能分析工具读取共享内存相关事件时，代表Bank冲突的计数器数值高得吓人。我拿计算Tile的线程访问模式反推，发现B矩阵Tile读取时，线程按固定步长跨行取数，而行长恰好是Bank数量的整数倍，导致几乎每两个线程都访问同一个Bank。

修复方法是前文提到的Padding。我在B矩阵共享内存数组的每行末尾多分配4个元素，数据拷贝时也按这个扩容后的行宽搬运。修改后Bank冲突事件数量直接降到接近零，整体性能立刻从30%提升到50%左右。这个坑最大的迷惑性在于：共享内存数组看起来只是“多开了一点点空间”，不读计数器根本不会想到这个改动会带来质变。

7.3 排障链路2：寄存器溢出与Occupancy崩盘

性能到50%后又遇到第二个瓶颈：编译器报告每个线程的寄存器用量已经超过安全线，开始把变量“溢出”到本地内存。本地内存在物理上落在全局内存上，它的访问延迟和全局内存一样，这对高性能内核是灾难性的。线程束的Occupancy也从预期的75%掉到了30%，因为寄存器池已经装不下需要的线程束数量。

解决办法不是盲目限制寄存器数量，而是重新规划每个线程持有的C分块大小。我把BM与BN的配置调小一档，让每个线程的累加器数量减半，并把A/B矩阵的临时片段复用，减少同时存活的大数组。调整后寄存器用量回落到安全范围，Occupancy恢复，性能从50%推到了70%以上。这里的核心教训是：寄存器和共享内存一样是稀缺资源，你在设计分块时就要把它当成硬约束来计算，而不是等编译器报错再补救。

7.4 与厂商自带矩阵库的实测对比

性能优化到一定程度后，我做了一次公允的对照测试：相同矩阵形状、相同精度配置，DeepGEMM内核和厂商自带矩阵库分别跑。在1024到4096的大矩阵段，DeepGEMM能达到厂商库性能的90%以上，某些规整尺寸甚至基本持平。在小矩阵段，厂商库因为高度特化的小矩阵内核仍然领先，毕竟我没有为那个场景专门优化。

需要说明的是，厂商库不是永远最优的。它在某些自定义形状、自定义精度组合、或需要融合其他算子的场景下，并不一定比一个专门定制的内核更合适。DeepGEMM能做到这个成绩，已经证明思路没错。通过这个项目，我真正明白了所谓“矩阵库性能”并不是借助不可言说的魔法，而是把访存、线程布局、指令调度每一项细节都较真到底。

7.5 调优时要刻意遵守的纪律

回看整个性能调优过程，我最想强调的纪律是：每次只改变一个变量。我吃过亏，有一次同时改动了线程块尺寸和异步拷贝阶段数，性能掉了20%，我根本说不清是哪个改动导致退化，只能一步步回退再单项测试。后来我给自己定下规矩：每个实验只动一个参数，记录测试数据后再进入下一个。

这种方法的另一个好处是能积累可信的调参表。现在如果让我对一个新尺寸做快速配置，我能根据历史测试直接锁定起始点，而不是从头猜。做算子优化和做实验研究一样，控制变量不是刻板，而是效率最高的工作方式。

最后再分享一点体会

DeepGEMM项目做下来，我心里最大的变化是对“性能”两个字的理解。过去我认为性能优化就是堆各种技巧、写复杂的汇编指令，现在我更愿意把它理解为：让你的代码结构和硬件的物理结构达成共识。硬件已经把计算、搬运、并行的规则写在物理设计里了，内核开发者的工作不是发明规则，而是读懂规则并顺着它设计，那些看似神奇的矩阵库快，也只是因为和硬件配合得更紧密而已。

如果你也想尝试类似的优化工作，我的建议很朴素：先从小矩阵开始验证正确性，拿出profiler一点点看存储事件，永远记录实验数据，别过度崇拜某一种参数组合。这条路上一定会有性能卡在半山腰的时候，但每一次定位问题、拆解原因、换成更合理的资源布局，都会让下一版代码的骨架更扎实。DeepGEMM本身只是一个起点，同样的方法论，还可以延伸到卷积算子、注意力融合、以及更多自定义计算单元里。希望你也能在自己项目的profiler数据里，找到那个“原来如此”的时刻。