企业官网建设流程全解析

矩阵乘法，也就是GEMM（General Matrix Multiplication），可能是整个深度学习系统里被提及最多、又最少被普通工程师真正读懂的一个词。它出现在全连接层、卷积的im2col变换、注意力机制里的QKV投影、推荐系统的Embedding查找与交互，几乎每一个上规模的模型推理任务，最终都会落到一堆GEMM调用上。DeepGEMM这个项目，就是我自己从零写的一个面向深度学习推理场景的高性能矩阵乘法库，目标是搞明白一件事：在尽量少的依赖下，仅凭硬件特性、内存层级和指令级并行，能把一个朴素的三重循环优化到什么样的速度。

这篇文章会从GEMM为什么重要、为什么不用通用库、核心优化思路，到分块和微内核的具体写法，再到精度和性能问题的排查，完整梳理一遍做DeepGEMM的思考过程。适合三类人看：正在做推理引擎或者算子融合的工程师，想入门高性能计算但不知道从哪里下手的同学，以及虽然天天调库但想知道底层到底在干什么的人。看懂这篇文章不需要很深的背景，但看完了，你会对“为什么矩阵乘法占了大头”这件事有完全不一样的体感。

1. 为什么需要自研GEMM——矩阵乘法在深度学习里的位置

1.1 从全连接到注意力机制，GEMM无处不在

最直观的例子是全连接层。一个形状为[M, K]的输入矩阵，乘以形状为[K, N]的权重矩阵，得到[M, N]的输出。这里M通常是批量大小乘序列长度，K是输入特征维度，N是输出特征维度。Transformer里，每个Attention头的Q、K、V投影是三个GEMM；计算注意力分数Q @ K^T是一个GEMM；注意力分数与V相乘又是一个GEMM。算下来，一次标准推理里GEMM的耗时占比超过80%非常正常。

卷积层算不算GEMM？严格说卷积是四维运算，但主流的实现方式，比如im2col加GEMM，或者隐式GEMM，核心还是矩阵乘法。甚至现在很多推理引擎会把卷积直接转化成GEMM来处理，因为矩阵乘法的优化思路足够成熟，优化一次，卷积、全连接、Attention都能受益。

从计算量角度看，GEMM的浮点运算次数是2 * M * N * K。哪怕一个很小的模型，一次矩阵乘法的FLOPs也是百万级起步，一个7B模型跑一遍前向要做的矩阵乘法运算量，足够让CPU忙很久。所以GEMM性能直接决定了模型的响应延迟和吞吐量，这不是“值得优化”的问题，而是“不优化就没法用”的问题。

1.2 通用优化库的局限

既然GEMM这么重要，那直接用官方数学库不就行了吗？行，大部分场景下也确实应该这么用。但自己做DeepGEMM的动机在于，通用库有三个很难绕过去的局限。

第一，通用库是为“所有形状”优化的，不是为“你的形状”优化的。通用库要覆盖各种M、N、K的组合，各种对齐条件，各种数据类型和布局需求，策略必须非常保守。比如M很小的时候（M=1、M=4），走大分块的GEMM算法反而不如专门的小矩阵路径；比如K特别大但N很小，访存模式和均衡GEMM完全不同。模型推理时形状往往是固定的，可以针对固定形状做极其激进的优化，收益经常是两位数百分比的。

第二，量化推理正在成为主流，但通用库对INT8、FP8、INT4这些类型的支持往往不够灵活。做量化GEMM不只是把数据类型换成整数那么简单，还要处理scale、zero point的融合时机，以及避免中间反量化造成的额外开销。通用库给了你接口，但不会为你的量化方案定制优化。

第三，算子融合做不到。推理引擎里GEMM之后通常跟着BiasAdd、激活函数、残差连接，如果能把这些融合进GEMM的尾端，就不用把中间结果写回显存再读出来。这一来一回省下的带宽是非常惊人的。通用库的黑盒接口不会帮你做这件事，你只能自己维护一个GEMM内核。

除此之外，学习价值也很高。GEMM是高计算密集度、高数据复用率的代表性问题，把GEMM优化吃透了，做卷积、做带宽优化、做图融合，都会轻松很多。所以从工程和成长两个角度，DeepGEMM都值得做。

1.3 影响范围：为什么一个算子能撬动整个推理链路

GEMM不是孤立存在的，它的性能会沿链路传导。举个我实际遇到的例子：某个模拟项目X的模型，一次推理里有几十次GEMM调用，量化的GEMM只占其中几次，但修改内核后整体延迟下降了接近一半。原因就在于矩阵乘法往往是拖尾算子，只要它变快了，后续算子才能空出资源。

更关键的是，GEMM内核可以被复用。同一个内核，换不同的分块参数，就能同时服务全连接层、Attention投影和卷积场景。这意味着你在GEMM上做的一点点优化，会被整套推理框架放大无数倍。这是做底层算子最有成就感的地方。

2. 核心设计思路：从访存到计算的对抗游戏

2.1 内存层级与算术强度

要理解GEMM优化，必须建立一张硬件内存的层级图。寄存器最快但容量最小，通常一个核也就几十到几百个寄存器；L1缓存次之，每个核几十KB；L2缓存大一些但延迟已经明显上升；最后是主存，容量大但带宽有限。数据在层级之间搬运的成本，比计算的成本高出好几个数量级。

这里有一个关键概念叫“算术强度”，也就是“每访问一次数据，能做多少次浮点运算”。GEMM的算术强度天然是高的——2*M*N*K次运算只需要读入M*K + K*N个数据。理论上数据只要读进缓存一次，就可以疯狂复用好多次。但前提是，你的循环顺序必须让数据在缓存里待得足够久，否则每次运算都从主存取数，算术强度再高也白搭。

打个比方。你在厨房做菜，冰箱是主存，台面是L2缓存，切菜板是L1缓存，手是寄存器。如果每切一片菜都跑去冰箱拿一次食材，那大部分时间都浪费在路上。正确的做法是一次把所有食材搬到台面上，再到切菜板上小批量处理。GEMM优化的核心，就是安排好这套“搬菜”和“切菜”的节奏。

2.2 分块Tiling：三大核心参数M_BLOCK、N_BLOCK、K_BLOCK

朴素GEMM是一层一层的三重循环：遍历M、N、K，逐个点算。由于内层循环会反复访问A和B的同一片数据，但访问粒度太小，缓存根本来不及“意识到”数据可以被复用。分块，也就是Tiling，就是解决这个问题的手段。

我把它拆成两层分块。第一层，把矩阵切成大块。对于输出的C矩阵，按M_BLOCK x N_BLOCK切成一个一个小块；输入A按M_BLOCK x K切，B按K x N_BLOCK切。这一层的目标是把数据分成适合L2缓存的“托盘”。第二层，在每一个M块和N块内部，再把K维切成K_BLOCK的小段。这样一次只算“一块”数据，让A和B的片段分别待在L1缓存里。两层分块配合起来，数据复用率能提高一个数量级。

三个分块参数怎么选？关键看三件事：缓存容量、寄存器数量、并行度。M_BLOCK和N_BLOCK越大，片上数据复用率越高，但每个线程块占用的寄存器和缓存资源就越多，同时能并行的线程块数就越少。K_BLOCK太大，L1缓存装不下，会频繁驱逐，太小则无法有效摊平访存延迟。我常用的一组起步值是M_BLOCK=64、N_BLOCK=64、K_BLOCK=16，这组参数在形状适中的矩阵上表现非常稳，之后再针对具体形状调。

注意：分块不是越大越好。块太大导致一个核同时处理的线程数变少，利用率反而下降。正确的姿势是固定整体占用率（比如每个核的占用率控制在百分之几十），再在这个前提下尽量加大分块。

2.3 数据复用与向量化：让每一条加载指令“物超所值”

分块解决的是“数据重用”，但还有一个维度是“单次加载的利用率”。现代处理器的向量寄存器可以一次装载多个浮点数，比如支持128位SIMD的CPU可以一次加载4个FP32，支持张量核心单元的GPU硬件则可以在单指令中完成大矩阵的乘加操作。

为了让向量化收益最大化，GEMM里有一个经典技巧：把A矩阵的一行分给多个线程去同时复用，让同一份数据被广播到多个处理单元。以CPU上的SIMD为例，内层循环里，向量寄存器一次性装载B矩阵的4个连续元素，然后与A矩阵的1个标量相乘，结果累加到4个独立的累加器上。这样一次内存访问，完成了4次乘法累加，带宽成本被摊薄了。

这里还要提到“累加器数组”的概念，这也是微内核的设计基础。C矩阵的每个碎片，不是每算一个点就写回内存，而是先放在寄存器数组里，反复累加K个维度之后再一次性写回。比如一个4x4的C碎片，需要16个寄存器来维护累加结果。寄存器是GEMM优化里最金贵的资源，设计微内核时一定要确保累加器全部放在寄存器里，不要让编译器把它们“溢出”到栈上。

3. 从朴素实现到高性能实现——实操路径拆解

3.1 第一步：朴素的三重循环，先建立正确性基线

任何高性能实现的前提都是：有一个完全正确的朴素版本。它不仅能用来验证后续优化版本的正确性，还能作为性能对比的基准。

void gemm_naive(const float* A, const float* B, float* C, int M, int N, int K, float alpha, float beta) { for (int m = 0; m < M; m++) { for (int n = 0; n < N; n++) { float sum = 0.0f; for (int k = 0; k < K; k++) { sum += A[m * K + k] * B[k * N + n]; } C[m * N + n] = alpha * sum + beta * C[m * N + n]; } } }

这个版本没什么好说的，唯一要建立的习惯是：从一开始就支持alpha和beta。很多GEMM调用场景都需要把结果累加到已有的C矩阵上，比如残差连接、某些特殊融合场景。后期再把alpha、beta加进去会非常痛苦。

内层循环里，A的一行和B的一列被反复访问，且每次只算一次乘法。当K比较大的时候，每次读入的B列元素从上一次开始就被缓存淘汰掉了。所以这个版本的性能基本等于内存带宽上限，没有任何复用。

验证这个版本时，我会用M、N、K都在32到256之间的几个随机形状，用统一的随机种子和一组固定数值，逐一和后续版本对比。注意初始时C矩阵要填入非零随机值，这样才能验证beta分支没有被写坏。

3.2 第二步：分块与缓存优化，让数据在缓存里“多活一会”

下一步是把三重循环改成分块循环。外层按块遍历M、N，内层按块遍历K，每次计算一个C小块。

void gemm_blocked(const float* A, const float* B, float* C, int M, int N, int K, int MB, int NB, int KB) { for (int m0 = 0; m0 < M; m0 += MB) { for (int n0 = 0; n0 < N; n0 += NB) { int mEnd = min(m0 + MB, M); int nEnd = min(n0 + NB, N); // 初始化 C 小块 for (int m = m0; m < mEnd; m++) for (int n = n0; n < nEnd; n++) C[m * N + n] = beta * C[m * N + n]; for (int k0 = 0; k0 < K; k0 += KB) { int kEnd = min(k0 + KB, K); for (int m = m0; m < mEnd; m++) { for (int n = n0; n < nEnd; n++) { float sum = 0.0f; for (int k = k0; k < kEnd; k++) { sum += A[m * K + k] * B[k * N + n]; } // 注意：这里不能直接写回 C，需要把临时结果累积起来 C[m * N + n] += alpha * sum; } } } } } }

分块之后，K的内循环被限制在KB以内。A的一个MB x KB块和B的一个KB x NB块会被加载到L1缓存，然后在计算中反复命中。相比朴素版本，这里的命中率已经有质的飞跃。不过这个版本有个明显问题：C的累计是每次K块结束后做的，这意味着C数据会被反复写回再读取。真正的高性能实现会把C小块保留在寄存器里，最后一次性写回。这引出了微内核。

这一阶段性能提升的典型幅度，在形状为512x512的情况下，是朴素版本的几倍到十几倍不等。关键观察点是：分块变大时性能会先升后降，这就是前面说的资源和复用之间的博弈。

3.3 第三步：引入微内核，把C碎片钉在寄存器里

微内核，也就是microkernel，是整个GEMM优化的核心。它的思想很简单：取消每次K块结束时的C写回，让一个“小块”的乘累加操作完全在寄存器里完成。

// 计算一个 C 的 MB x NB 碎片，寄存器内累加 void microkernel(const float* A_ptr, const float* B_ptr, float* C_ptr, int K, int ldC, int MB, int NB) { // 假设 MB=4, NB=4 float c[4][4] = {0.0f}; for (int k = 0; k < K; k++) { for (int i = 0; i < 4; i++) { float a = A_ptr[i * K + k]; for (int j = 0; j < 4; j++) { c[i][j] += a * B_ptr[j * K + k]; } } } for (int i = 0; i < 4; i++) for (int j = 0; j < 4; j++) C_ptr[i * ldC + j] += alpha * c[i][j]; }

这段伪代码表达的核心思想是：内层循环中，A的一个元素被用于更新C一整行的4个寄存器累加器，B的一个元素被用于更新一整列的4个累加器。数据从内存读到寄存器后，被反复使用了4次。这就是数据复用从“缓存级”下沉到“寄存器级”。寄存器级复用的收益远大于缓存级，因为寄存器的读写零延迟、零带宽消耗。

微内核大小的选择，也就是MB和NB具体取多少，取决于寄存器数量。一个4x4的C碎片占16个寄存器，加上A、B的向量寄存器，以及地址计算、循环计数器，总共可能占30到40个寄存器。一个CPU核通常有32个倍数关系的寄存器组，4x4在大多数平台上都算安全。如果是支持更宽向量寄存器的平台，6x8、8x8这类碎片也常见。核心原则是：在编译器不溢出寄存器的前提下，C碎片尽可能大。怎么判断溢出？把性能测试时的汇编或者栈访问情况看一遍，如果出现很多内存load/store，说明寄存器不够用了。

注意：内循环里计算地址时，尽量不要用数组索引里带乘法的形式，比如A_ptr[i * K + k]每次都会多一次乘法指令。在真正的内核里，我会提前把指针步长算好，用增量指针的方式把这些乘法消掉。这是编译期优化的基础，也是很多伪代码移植到实际代码时性能低一截的原因。

3.4 第四步：多线程与硬件指令，把多核和宽寄存器用满

微内核本身是单核的优化，要发挥多核优势，还需要把分块循环拆到多个线程上。做法是按M或N方向做工作划分。我的习惯是按N方向划分，因为这样不同线程访问的B列互不相交，写C时不需要加锁；而A会被多个线程共享读取，这正好在缓存共享上有利，因为同一块A数据不需要每个核都去主存读一次。

每个线程分到一个或多个M_BLOCK x N_BLOCK的C块，然后以自己的节奏跑完整套分块循环。注意控制线程之间的同步点：最好只在每个工作块结束时同步一次，不要在K块内部频繁插入屏障，否则同步开销会吃掉所有性能收益。

硬件指令的使用则因平台而异。支持SIMD的CPU上，内层循环会把4个B的值装入一个向量寄存器，跟广播后的A值做向量乘加；支持张量核心单元的硬件上，一次硬件乘加能完成一个矩阵碎片的运算。无论哪种，微内核的基本结构都不变，只是“最内层的乘加”由编译器或者硬件指令来加速。

到这一步，一个能打的GEMM内核已经成型了。我实测下来，从朴素版到多线程微内核版，在512x512形状上性能提升通常能到20倍以上，已经非常接近硬件峰值的一个可观比例。剩下的工作，就是针对目标形状调参数。

3.5 关键参数实测选择：一组肉眼调优的经验值

分块参数最怕“看起来合理”，实际性能拉胯。以下是我的起步参数和实测观察，你可以在此基础上做tuning，但不要上来就追求极致：

实践里有个重要的调试技巧：控制变量法。每次只改一个参数，看性能数据，别同时乱调。我见过太多人一上来把四个参数全部换掉，性能变差了都不知道是哪个参数的问题。画一条“块大小-性能”曲线，能很快找到你的平台性能拐点。

4. 工程落地：数据布局、融合算子和量化支持

4.1 数据布局优化：先转置还是当场转置

朴素GEMM里，C的计算需要A的每行和B的每列。内存布局如果按行优先存放，B的列访问就是不连续的，每一次取B[k * N + n]都会引发缓存行浪费。高性能GEMM通常通过“打包”解决：在进入微内核前，把B的对应小块拷贝到一个连续的内存缓冲区里，让内层循环访问B时完全是顺序的。A也可以做同样的处理，甚至在拷贝过程中完成数据类型转换和转置，减少内层的复杂分支。

打包的开销是一次额外的拷贝，但因为拷贝之后是连续访问，缓存命中率高，整体开销远小于它在内层循环里节省的访存损失。打包缓冲区要按块大小对齐，最好一次性分配好，避免反复申请释放。这一步看似简单，实际对性能影响极大。我测试过，不加打包的微内核版本，性能会掉20%到30%。

经验：打包方向也有讲究。通常先打包B再打包A收益更高，因为B的列访问模式是“完全随机”，而A的行访问在行优先布局下本来就有不错的空间局部性。如果你只愿意先优化一个，打包B优先。

4.2 算子融合：省掉中间张量的几个技巧

推理引擎里，GEMM后面几乎总是跟着一系列简单算子。与其让每个算子独立读写一遍全局内存，不如把后置操作直接塞进GEMM的尾端。比如：

• BiasAdd：在微内核写回C之前的标量加法。
• ReLU / GELU：在写回C寄存器时直接应用激活函数。
• 残差连接：把残差输入的加法和激活函数一起融合。
• 量化：如果GEMM输出后面紧跟一个量化节点，那么反量化、应用scale、取整这些操作也可以在寄存器里做掉，省掉中间FP32张量的存储和读取。

注意融合要分层次。有些融合适合在微内核尾端做，比如C碎片写回前；有些融合更适合在分块外层做，比如需要跨行处理的LayerNorm。不要把一切融合都塞进微内核，否则寄存器压力过大，反而得不偿失。判据很简单：尾端融合只做“逐元素”操作，任何依赖一整个向量或一行的操作，都放到内核外面。

4.3 量化GEMM：整数算术的溢出与控制

量化GEMM的核心公式是：

real_C = scale_a * scale_b * (A_int @ B_int) + ...

通常会用A_int乘以B_int然后累加到INT32累加器里，步进为scale_a * scale_b和zero point的修正。实现时最大的坑是溢出。两个INT8相乘最大是16256，累加K次后，K超过约131倍就可能冲破INT16的范围，所以累加器至少要用INT32。更严格来说，如果K很大，还要评估是否需要用INT64累加，或者把K维度拆成多段再合并。

另一个坑发生在alpha和beta上。量化GEMM里，alpha是浮点目标尺度，beta是对旧C的尺度。不要每一步都做浮点乘法和反量化，正确做法是：先在整数域算完整个A @ B，最后一次性应用scale和zero point。这样既减少了误差，也减少了指令。

如果你做的是FP16/FP8混合精度GEMM，核心结构相同，只是累加精度和异常处理（对INF/NaN的屏蔽策略）不同。我的建议是：把量化参数包装成一个小结构体，在微内核外部传进去，内核里只用基础类型，便于编译器做指令选择。

4.4 与推理框架的集成：shape推断与kernel选择

GEMM内核做好之后，要考虑怎么接入整个推理链路。一个独立的GEMM函数是一次性解决所有形状，这在框架里并不好用。更合理的是做一个按形状分发的前端逻辑：根据M、N、K、数据类型、对齐条件，选择对应的内核实例。

关键细节是充分性判断。比如M小于某个阈值时走专门的“小M”内核，K特别大但N很小时可能应该走转置路径，M和N能够被块大小整除时走“无边界检查”的快速路径，不能整除时走“带边界检查”版本。这个分发层虽然不产生浮点运算，但能省掉大量不必要的分支判断。有了它，后续做自动调优就方便了。

5. 常见性能问题与调试技巧

5.1 一个指标表：FLOPs、有效带宽、延迟、占用率怎么测

先约定怎么衡量GEMM内核的好坏，否则谈优化就是空谈。我每次调内核一定会记录下面几个指标：

性能分析工具不是玄学，一定要用起来。它会告诉你内核到底卡在访存延迟、计算吞吐还是同步等待上。这三者的优化方向完全不一样：访存瓶颈就去调分块和打包；计算瓶颈就去查指令选择和循环展开；同步瓶颈就去改任务划分粒度。

5.2 性能低于预期的几个根源

第一个根源是缓存未命中。表现为实测FLOPs远低于纸面预期，但有效带宽已经接近硬件上限。这时候要检查分块大小，特别是K_BLOCK是否已经超过L1缓存容量。把K_BLOCK从64降到16，往往立即见效。

第二个是bank冲突或通道冲突。在并行访问内存时，多个线程访问同一bank会导致排队。表现在性能曲线上是某个块大小突然掉坑。解决办法通常是给B的打包缓冲区填充一点padding，比如在每一行末尾多留4字节，打破对齐。

第三个是同步过频。有些实现喜欢在每个K块之后加线程屏障，导致所有线程在每轮K循环互相等待，快的那部分被慢的拖住。正确做法是尽量让线程独立工作更长的时间，只在计算完整个C块后同步一次，或者干脆按任务队列动态分配。

第四个是任务粒度不均衡。M和N无法整除块大小时，边缘块的计算量不满，分配到这些块的线程会提前结束，拖慢整体耗时。解决方法是把剩余边缘块合并成“单线程顺序执行”的特殊内核，不与主内核复用。

5.3 数值精度异常排查

性能搞定后，最烦人的就是数值错误。常见的坑有三个。第一，累加顺序问题：分块之后每个C块累加K的顺序和朴素版本不同，浮点结果会有微小差异。解决方案不是消除差异，而是设置合理的容差阈值。我在测试里用spectral norm或者随机向量的相对误差判定，阈值设在1e-5（FP32）和1e-2（FP16）左右。

第二，alpha和beta的应用时机。在分块版本里，如果你在K循环内部就先乘了alpha，再在最后写回，那么alpha会被应用很多次，数值偏差会随K增大而累积。正确做法是：alpha只在最后一次写回时应用。

第三，INT8的zero point没对齐。量化GEMM里，zero point的修正项经常会被忘掉。特别是当A和B的zero point都不为零时，需要额外减去A_zero * B_zero这一项。这是个极易出错的部分。建议单独写一个“零矩阵”测试：把输入全部设为zero point对应的整数，输出应该正好等于0附近的残差。

5.4 六个实用调试口诀

这六个口诀是我做了这么多年算子的总结，对新手尤其有用：

• 先正确，后优化。所有优化都基于一个验证过的朴素基线。
• 要想快，看访存。性能瓶颈十有八九先查数据搬运。
• 向量化，要写清。不要指望编译器自动把标量循环变成向量指令。
• 寄存器，别溢出。看见栈操作，先检查分块大小。
• 循环展开要适度。展开能提升指令级并行，但也增加指令缓存压力。
• 抓大头，别抠小点。先把分块、打包、融合做了，再想milestone级别的优化。

6. 深度扩展：DeepGEMM还能做什么

6.1 稀疏GEMM与结构化剪枝

模型剪枝之后，权重矩阵会变成稀疏矩阵。传统GEMM会把大量零值也参与计算，浪费算力。结构化稀疏GEMM的思路是把矩阵按块稀疏化，比如2:4稀疏，也就是每四个元素里保留两个。这类GEMM的核心是在普通GEMM的微内核上增加稀疏掩码处理，硬件支持时可以直接跳过零值块。自己做的时候，一个比较务实的起点是先做CSR或BSR格式的稀疏GEMM，用分块的方式避免索引查找的开销。稀疏GEMM的加速比和稀疏度强相关，越稀疏收益越大，但实现复杂度也越高。

6.2 自动调优：autotuning空间

手工调参是有上限的，更系统的做法是引入自动调优。具体做法是把分块大小、微内核大小、循环展开因子、线程数这些参数枚举成一块“配置空间”，针对目标硬件跑一遍，记录每个配置的耗时，选出最优配置。配置空间通常有几百到几千个组合，用全枚举比较耗时，但推理引擎本来就是针对固定模型做编译，一次性成本可以接受。

做自动调优要注意两点：一是基准测试本身要足够稳定，最好多次运行取最小值，避免频率波动和后台进程干扰；二是不要只调GEMM，要联动后续融合算子一起调，否则局部最优不是全局最优。我见过几次因为只调GEMM本身，结果融合后的整体延迟反而变差的情况。

6.3 多项式融合与图优化

更高级的扩展是把多个GEMM和它们周围的算子整体融合。比如Attention里Q @ K^T和后面的softmax、@ V，能否在同一个内核里完成？理论上可以，但实现难度非常大，因为softmax的softmax分母依赖整个行的最大值和求和，这要求跨线程归约。一个折中的方案是融合QK^T和softmax的一部分，或者把LayerNorm融合到前一个GEMM的尾端。

这是推理引擎最能出成果的地方。同样的模型结构，一个好的图优化管线可以把延迟砍掉两到三成，而GEMM本身可能只能贡献其中两三成。DeepGEMM的核心内核做好了，后续融合就等于在已有的“高速计算单元”上附加几乎零开销的周边操作，这比重新写一整个新算子要省力得多。

我自己在这套项目上踩过最深的坑，其实是过度优化。有一阵子为了追求单内核的极致效率，先是把汇编调得非常复杂，然后又加了各种特殊分支，结果边缘情况下性能不稳定，代码也难维护。后来我把大部分特殊分支移出去，留下一个相对简洁但稳定的内核，再靠自动调优找参数，整体反而更快。高性能计算里，代码的简洁性和运行效率往往是一体两面——复杂的分支会让指令缓冲失效，也会让编译器更难优化。这个教训，做任何算子库都适用。

如果你也想从零开始做一个类似的GEMM，我的建议是先别碰复杂硬件指令，把一个分块微内核调明白，再加上多线程和打包，这一套已经能让你对高性能计算有非常完整的理解。等你真的需要冲峰值时，再到汇编层面去打磨，你会发现之前打下的基础让一切都顺理成章。