上周我把一个生成模型的前向流程用 profiler 撸了一遍发现单是矩阵乘相关算子就占了接近 68% 的执行时间。这个数字不算意外但凡跑过 Transformer 系列模型的人都清楚自注意力、MLP、Embedding 这几大模块骨子里全是矩阵运算。但真到要优化的时候很多人的第一反应是去调 batch size、搞并行策略很少有人会往下钻一层去看看底层那个神经网络算子库ops-nn到底是怎么把一次矩阵乘变成硬件指令的。这周我在某个代码托管平台上花了几个晚上把一个面向 AI 处理器的算子库源码从头到尾翻了翻重点关注矩阵类算子的实现与调度逻辑。看完之后收获很大不仅搞懂了为什么同一套模型在不同架构上跑起来差距能到好几倍还顺手把手头的一个生成模型推理速度提了接近 30%。这篇文章就把我解码过程中整理出来的东西写清楚包括 AIGC 与矩阵运算的关系、算子库的内部实现逻辑、如何高效读源码以及我实际调优时踩过的一些坑。不管你是做算法还是做推理部署应该都能从中找到点有用的东西。1. 先说清楚AIGC 的“线性基石”到底是什么为什么卡在矩阵乘1.1 自注意力机制里的矩阵运算很多人聊 AIGC 喜欢谈大模型、扩散模型、多模态但模型的骨架翻来覆去就那么几件事线性映射、注意力计算、归一化、激活函数。其中注意力计算的本质就是把 Query、Key、Value 三个矩阵分别跟权重矩阵相乘再做 softmax。Transformer 结构里有一句经典描述Attention(Q, K, V) softmax(QK^T / sqrt(d_k)) V。这里的 QK^T 和最后的 V 相乘全都是矩阵乘。矩阵乘在数学上写起来只是 Σ a_ik * b_kj但落到真实模型里就不是一个简单公式能带过的事了。拿一个 7B 规模的生成模型来举例单次前向传播要完成的矩阵乘操作数量是百万量级的每个矩阵乘的尺寸也从几百到几千不等。你可以把一次矩阵乘想象成搬砖算力决定你一秒钟能搬多少块带宽决定砖从仓库到工地能运多快而算法决定你搬砖的顺序是否合理。AI 处理器要同时管好这三件事才可能把矩阵算得快。1.2 大量矩阵乘的叠加带来性能挑战矩阵运算本身并不难理解难的是规模上去了之后性能不再是每秒钟能做多少次乘加这么简单。现在的 AI 处理器普遍有专门的计算单元比如矩阵乘单元理论算力听起来很吓人但实际能跑到理论值的三四成已经算不错了。问题通常出在数据搬运和计算单元的空等上。我做性能分析时经常看到一类现象某个矩阵算子的计算时间只占 20%剩下 80% 都在等数据从内存搬到片上。这就是典型的访存密集型瓶颈。而有些算子计算量很大但因为没有做切分数据局部性很差导致缓存命中率低同样跑不快。AIGC 模型动辄几十亿参数权重本身就有几个 GB根本不可能全塞进片上缓存因此如何把大矩阵切成小块、分步搬运、循环计算就成了算子库最核心的功课。这也是为什么说想真正把 AIGC 模型跑快绕不开底层这些线性基石的实现细节。2. ops-nn 算子库在 AI 计算架构里的位置从数学公式到硬件指令2.1 算子库的角色把数学公式翻译成硬件指令我们平时写模型用的是 PyTorch 或者 MindSpore 这类框架框架层会调用一个个算子比如torch.matmul、torch.bmm。这些算子最终要落到具体的 AI 芯片上执行而芯片厂商不会把硬件细节直接暴露给框架中间夹着一层算子库。ops-nn 就是这样的角色它专门负责把神经网络里常用的算子卷积、矩阵乘、归一化、激活等实现成可以在特定 AI 处理器上高效运行的指令序列。如果你把整个软件栈从顶往下看大致是模型代码 - 深度学习框架 - 图编译与算子调度 - 算子库ops-nn - 运行时与驱动 - AI 芯片硬件。绝大多数做模型的人平时只接触最上面两层根本不会去看算子库。但只要一碰到性能问题或者想把一个自定义算子塞进计算图就不得不往下潜。早点搞清楚这一层的东西能省下不少瞎调参的时间。2.2 裸算子 vs 融合算子性能差异巨大在算子库里面矩阵乘并不是孤零零一个实现。至少可以分成两类一类是裸算子就是只做一次纯粹的矩阵乘另一类是融合算子把矩阵乘前后紧挨着的若干个操作比如转置、加偏置、GELU 激活合并到同一个计算流程里。为什么融合很重要因为 AI 处理器的数据搬运代价非常高。如果每做一步操作就把中间结果写回内存下一步再读出来大量的时间就浪费在往返搬运上了。融合算子的本质就是减少中间结果的落地次数让数据在片上多待一会儿能算的都算了再出去。我在实测中对比过一个 4096 维的线性层裸算子加偏置再加 GELU 分开执行跟融合成一个算子执行端到端时间差了接近 1.8 倍。对于生成模型这种动辄几十层串联的结构每个算子都省一点累积起来就是很可观的收益。所以看算子库源码时看到一个融合算子不要觉得它复杂它恰恰是性能优化的主力军。3. 在代码托管平台上逐行解码一个矩阵算子tiling、layout 与流水线3.1 shape 推导与数据布局先把输入输出形状理清楚我在代码托管平台上搜到 ops-nn 仓库的矩阵乘算子实现时第一反应是去翻它的头文件和 shape 推导逻辑。很多只看 Python 层的同学可能不知道底层算子在真正执行前需要做非常严格的维度与布局检查。矩阵乘本身要求 A 的最后一维等于 B 的倒数第二维但实际工程里输入往往带着 batch 维、序列长度维还可能要求你支持广播。这些逻辑全在 shape 推导阶段完成。shape 推导之后紧接着是数据布局layout的选择。同样是二维矩阵在内存里可以按行优先存也可以按列优先存到了更高维还涉及是 NCHW 还是 NHWC 这类通道排布。AI 芯片的矩阵乘单元对数据排布非常敏感排对了可以连续搬运排错了就到处随机访问性能直接崩掉。我建议阅读源码时养成一个习惯拿到一个算子先画一张数据流图标出输入张量的维度、输出张量的维度、内存布局是连续还是不连续。很多时候性能问题不是计算慢而是布局不对导致拷贝太多。3.2 tiling 切分策略大矩阵是怎么被吃掉的矩阵乘的核心挑战之一是数据放不下。假设我们要算一个 8192 x 8192 的矩阵乘以另一个 8192 x 8192 的矩阵中间结果和输入数据加起来远超片上缓存容量。硬算是不现实的必须把大矩阵切成很多个小块一块一块地搬进片上算完一块再算下一块。这个切分过程在算子实现里叫 tiling。tiling 维度非常有讲究。常见做法是把 M、N、K 三个维度分别切块每个计算单元处理一个 (block_m, block_n, block_k) 的小矩阵乘。block_k 的选择直接影响数据复用K 维切得越大A 矩阵的分块加载到片上后能被更多次的 B 分块计算复用但片上缓存占用也会变大切得太小数据复用率低带宽压力变大。实际算子库里通常会提供多个 tiling 策略或者根据 shape 动态计算最优分块。我在源码里看到过针对不同数据类型FP16、BF16和不同矩阵尺寸生成不同 tiling 参数的逻辑。这个细节很有意思因为很多性能问题就藏在 tiling 参数匹配不佳上。如果你要在自己的算子库里写矩阵乘tiling 这块值得花最多时间调。3.3 向量化与流水线调度让计算单元不闲着切分好矩阵块之后真正执行乘加运算时还要考虑指令流水线。现代 AI 处理器的计算单元通常是向量化的一次指令可以同时处理多组数据。矩阵乘的实现会把小块矩阵按特定方式展开让乘加操作尽量对齐到硬件向量宽度上。如果数据规模不是向量宽度的整数倍就面临尾部处理问题通常要补零或者用掩码指令。流水线调度则是隐藏访存延迟的关键手段。我在看源码时注意到设计比较好的算子循环体里会先 prefetch 下一块数据再计算当前块。也就是说数据搬运和计算是重叠进行的。这样计算单元不会因为等数据而空转整体吞吐率能大幅提升。这个思路跟 CPU 上的软件流水线是一回事但在 AI 芯片上表现得更加极致。看完 tiling 和流水线这两个机制你会明白一个道理把矩阵乘写对很容易写快很难。快的前提是数据局部性好、搬运重叠、向量化充分以及切分参数跟硬件匹配。这些恰恰是通用框架做不到的必须要算子库针对具体芯片去打磨。4. 看完源码之后手头模型推理提速 30% 的完整调优过程4.1 定位瓶颈不要凭感觉优化先上 profiler光看源码不动手是不行的。我读完核心逻辑之后立刻拿手头那个生成模型做了性能剖析。这里建议大家第一步永远是用 profiler 看一下算子级耗时排行。我那次的结果非常典型耗时前五的算子全是矩阵乘相关其中三个是融合了偏置和激活的线性层算子还有两个是注意力里的 QK^T 和 AV 运算。定位到瓶颈之后再去比对我读源码时注意到的几个关键点数据布局是否正确、tiling 参数是否合理、是否走了最合适的融合算子路径。结果发现了一个问题模型 input 的 tensor 是从另一个预处理模块过来的内存布局不是算子库中最优的那种排布导致执行时多了一次额外的数据转换。这种转换在算子耗时里看不出来但会拖慢整体访存效率。4.2 调整策略改布局、换融合算子、修正 tiling针对定位出的问题我做了三处改动。第一处是把预处理模块的输出布局直接改成算子库推荐的排布省掉运行时转换。第二处是把我自己写的一个自定义算子一个带 mask 的矩阵乘替换成算子库原生支持的融合版本通过传入 mask 参数来达到同样效果避免自定义算子没有经过充分优化的问题。第三处是把部分矩阵乘的 tiling 参数手动指定成跟模型 shape 更匹配的档位而不是让它每次走默认的启发式选择。这三处改动单独看都不大合在一起效果就出来了。用同一份输入数据、同一个 batch 大小部署环境完全一致的情况下端到端推理耗时从原来的 408ms 降到了 287ms提升约 29.7%。其中融合算子替换的贡献最大接近六成布局调整贡献了两成多tiling 参数微调贡献了不到两成。4.3 验收与回归提速之后更要测稳定性性能优化最怕的是只看到 benchmark 变快一上真实业务就出问题。所以我做了一套简单的回归测试准备几组不同长度的输入序列分别跑优化前和优化后的版本除了看耗时还对比了输出的数值误差。因为矩阵乘本身的精度受到 tiling 分块和累加顺序影响不同实现算出来的结果在小数点后几位可能有差异这个需要确认在你的业务可接受范围内。我还特意测了 batch size 从 1 到 16 的扩展情况。结果发现固定 tiling 参数在小 batch 下表现很好但 batch 变大之后反而是默认参数更优。这说明没有一套参数能通吃所有场景优化必须针对你真实的上线配置来做而不是拿一个 benchmark 场景的结论到处套。这也是我做完这次调优之后最大的感受。5. 踩过的三个隐蔽的坑与最后的实操心得5.1 坑一只盯着计算时间忘了数据转换开销第一次做算子级剖析时我只看每个算子自己的耗时没有关心算子之间的数据流动。后来才发现输入张量从 NHWC 转成 NCHW 的转换算子本身耗时不高但它涉及的整块数据搬移会污染缓存导致后续矩阵算子的访存速度变慢。这种隐形污染不做端到端对比根本发现不了。后来我把数据流也纳入分析范围看每个 tensor 的诞生位置、使用位置、消亡位置一下子就抓住了真凶。5.2 坑二盲目替换成官方融合算子反而变慢融合算子并非所有情况下都更快。有一次我把一个矩阵乘加残差加 LayerNorm 的自定义流程替换成算子库的融合版本结果耗时反而涨了 15%。后来排查发现那个融合算子为了兼顾多种 Shape内部有很复杂的分支处理而我当前的输入 shape 恰好落入了一条低效路径。所以说融合算子的性能优势是有前提的shape 合适、走对分支。遇到这种情况建议把候选实现都写成一个几十行的 profile 脚本实际跑一遍再决定用哪个别只看文档宣传。5.3 坑三tiling 参数照搬别人的成功案例网上能搜到不少性能调优经验比如某模型把 block_k 设为 128 效果最好。但这类结论跟硬件架构强相关跟矩阵尺寸强相关跟甚至数据类型强相关。我试过把一个在 A 芯片上表现很好的 tiling 配置搬到 B 芯片上结果性能下降 40%。原因是两代芯片的缓存大小和矩阵乘单元宽度完全不同。比较靠谱的做法是自己写一个小的参数扫描脚本把可能的分块组合各跑一遍再做决策。5.4 最后的实操心得这次深入解码算子库源码我最想分享的体会是优化 AIGC 模型性能不能只停留在调并行策略和改 batch size 的层面。往下走一层把矩阵乘这类线性基石算子的实现逻辑搞清楚你会发现可做的事情其实很多而且一旦做对效果非常确定。哪怕你只是需要一个现成的解决方案也要懂得怎么去代码平台里找对仓库、看对文件、跑通验证。建议每个想深入推理优化的人都花点时间读一读自己常用 AI 计算架构对应的算子库源码先从最简单的矩阵乘开始把 tiling、layout、融合算子这三件事彻底弄明白后面再遇到性能问题就不会两眼一抹黑了。 
长河君 · 2026/10/19 3:27:57 · 阅读 1.2k 深入算子库：矩阵乘如何决定AIGC模型性能与推理速度
上周我把一个生成模型的前向流程用 profiler 撸了一遍发现单是矩阵乘相关算子就占了接近 68% 的执行时间。这个数字不算意外但凡跑过 Transformer 系列模型的人都清楚自注意力、MLP、Embedding 这几大模块骨子里全是矩阵运算。但真到要优化的时候很多人的第一反应是去调 batch size、搞并行策略很少有人会往下钻一层去看看底层那个神经网络算子库ops-nn到底是怎么把一次矩阵乘变成硬件指令的。这周我在某个代码托管平台上花了几个晚上把一个面向 AI 处理器的算子库源码从头到尾翻了翻重点关注矩阵类算子的实现与调度逻辑。看完之后收获很大不仅搞懂了为什么同一套模型在不同架构上跑起来差距能到好几倍还顺手把手头的一个生成模型推理速度提了接近 30%。这篇文章就把我解码过程中整理出来的东西写清楚包括 AIGC 与矩阵运算的关系、算子库的内部实现逻辑、如何高效读源码以及我实际调优时踩过的一些坑。不管你是做算法还是做推理部署应该都能从中找到点有用的东西。1. 先说清楚AIGC 的“线性基石”到底是什么为什么卡在矩阵乘1.1 自注意力机制里的矩阵运算很多人聊 AIGC 喜欢谈大模型、扩散模型、多模态但模型的骨架翻来覆去就那么几件事线性映射、注意力计算、归一化、激活函数。其中注意力计算的本质就是把 Query、Key、Value 三个矩阵分别跟权重矩阵相乘再做 softmax。Transformer 结构里有一句经典描述Attention(Q, K, V) softmax(QK^T / sqrt(d_k)) V。这里的 QK^T 和最后的 V 相乘全都是矩阵乘。矩阵乘在数学上写起来只是 Σ a_ik * b_kj但落到真实模型里就不是一个简单公式能带过的事了。拿一个 7B 规模的生成模型来举例单次前向传播要完成的矩阵乘操作数量是百万量级的每个矩阵乘的尺寸也从几百到几千不等。你可以把一次矩阵乘想象成搬砖算力决定你一秒钟能搬多少块带宽决定砖从仓库到工地能运多快而算法决定你搬砖的顺序是否合理。AI 处理器要同时管好这三件事才可能把矩阵算得快。1.2 大量矩阵乘的叠加带来性能挑战矩阵运算本身并不难理解难的是规模上去了之后性能不再是每秒钟能做多少次乘加这么简单。现在的 AI 处理器普遍有专门的计算单元比如矩阵乘单元理论算力听起来很吓人但实际能跑到理论值的三四成已经算不错了。问题通常出在数据搬运和计算单元的空等上。我做性能分析时经常看到一类现象某个矩阵算子的计算时间只占 20%剩下 80% 都在等数据从内存搬到片上。这就是典型的访存密集型瓶颈。而有些算子计算量很大但因为没有做切分数据局部性很差导致缓存命中率低同样跑不快。AIGC 模型动辄几十亿参数权重本身就有几个 GB根本不可能全塞进片上缓存因此如何把大矩阵切成小块、分步搬运、循环计算就成了算子库最核心的功课。这也是为什么说想真正把 AIGC 模型跑快绕不开底层这些线性基石的实现细节。2. ops-nn 算子库在 AI 计算架构里的位置从数学公式到硬件指令2.1 算子库的角色把数学公式翻译成硬件指令我们平时写模型用的是 PyTorch 或者 MindSpore 这类框架框架层会调用一个个算子比如torch.matmul、torch.bmm。这些算子最终要落到具体的 AI 芯片上执行而芯片厂商不会把硬件细节直接暴露给框架中间夹着一层算子库。ops-nn 就是这样的角色它专门负责把神经网络里常用的算子卷积、矩阵乘、归一化、激活等实现成可以在特定 AI 处理器上高效运行的指令序列。如果你把整个软件栈从顶往下看大致是模型代码 - 深度学习框架 - 图编译与算子调度 - 算子库ops-nn - 运行时与驱动 - AI 芯片硬件。绝大多数做模型的人平时只接触最上面两层根本不会去看算子库。但只要一碰到性能问题或者想把一个自定义算子塞进计算图就不得不往下潜。早点搞清楚这一层的东西能省下不少瞎调参的时间。2.2 裸算子 vs 融合算子性能差异巨大在算子库里面矩阵乘并不是孤零零一个实现。至少可以分成两类一类是裸算子就是只做一次纯粹的矩阵乘另一类是融合算子把矩阵乘前后紧挨着的若干个操作比如转置、加偏置、GELU 激活合并到同一个计算流程里。为什么融合很重要因为 AI 处理器的数据搬运代价非常高。如果每做一步操作就把中间结果写回内存下一步再读出来大量的时间就浪费在往返搬运上了。融合算子的本质就是减少中间结果的落地次数让数据在片上多待一会儿能算的都算了再出去。我在实测中对比过一个 4096 维的线性层裸算子加偏置再加 GELU 分开执行跟融合成一个算子执行端到端时间差了接近 1.8 倍。对于生成模型这种动辄几十层串联的结构每个算子都省一点累积起来就是很可观的收益。所以看算子库源码时看到一个融合算子不要觉得它复杂它恰恰是性能优化的主力军。3. 在代码托管平台上逐行解码一个矩阵算子tiling、layout 与流水线3.1 shape 推导与数据布局先把输入输出形状理清楚我在代码托管平台上搜到 ops-nn 仓库的矩阵乘算子实现时第一反应是去翻它的头文件和 shape 推导逻辑。很多只看 Python 层的同学可能不知道底层算子在真正执行前需要做非常严格的维度与布局检查。矩阵乘本身要求 A 的最后一维等于 B 的倒数第二维但实际工程里输入往往带着 batch 维、序列长度维还可能要求你支持广播。这些逻辑全在 shape 推导阶段完成。shape 推导之后紧接着是数据布局layout的选择。同样是二维矩阵在内存里可以按行优先存也可以按列优先存到了更高维还涉及是 NCHW 还是 NHWC 这类通道排布。AI 芯片的矩阵乘单元对数据排布非常敏感排对了可以连续搬运排错了就到处随机访问性能直接崩掉。我建议阅读源码时养成一个习惯拿到一个算子先画一张数据流图标出输入张量的维度、输出张量的维度、内存布局是连续还是不连续。很多时候性能问题不是计算慢而是布局不对导致拷贝太多。3.2 tiling 切分策略大矩阵是怎么被吃掉的矩阵乘的核心挑战之一是数据放不下。假设我们要算一个 8192 x 8192 的矩阵乘以另一个 8192 x 8192 的矩阵中间结果和输入数据加起来远超片上缓存容量。硬算是不现实的必须把大矩阵切成很多个小块一块一块地搬进片上算完一块再算下一块。这个切分过程在算子实现里叫 tiling。tiling 维度非常有讲究。常见做法是把 M、N、K 三个维度分别切块每个计算单元处理一个 (block_m, block_n, block_k) 的小矩阵乘。block_k 的选择直接影响数据复用K 维切得越大A 矩阵的分块加载到片上后能被更多次的 B 分块计算复用但片上缓存占用也会变大切得太小数据复用率低带宽压力变大。实际算子库里通常会提供多个 tiling 策略或者根据 shape 动态计算最优分块。我在源码里看到过针对不同数据类型FP16、BF16和不同矩阵尺寸生成不同 tiling 参数的逻辑。这个细节很有意思因为很多性能问题就藏在 tiling 参数匹配不佳上。如果你要在自己的算子库里写矩阵乘tiling 这块值得花最多时间调。3.3 向量化与流水线调度让计算单元不闲着切分好矩阵块之后真正执行乘加运算时还要考虑指令流水线。现代 AI 处理器的计算单元通常是向量化的一次指令可以同时处理多组数据。矩阵乘的实现会把小块矩阵按特定方式展开让乘加操作尽量对齐到硬件向量宽度上。如果数据规模不是向量宽度的整数倍就面临尾部处理问题通常要补零或者用掩码指令。流水线调度则是隐藏访存延迟的关键手段。我在看源码时注意到设计比较好的算子循环体里会先 prefetch 下一块数据再计算当前块。也就是说数据搬运和计算是重叠进行的。这样计算单元不会因为等数据而空转整体吞吐率能大幅提升。这个思路跟 CPU 上的软件流水线是一回事但在 AI 芯片上表现得更加极致。看完 tiling 和流水线这两个机制你会明白一个道理把矩阵乘写对很容易写快很难。快的前提是数据局部性好、搬运重叠、向量化充分以及切分参数跟硬件匹配。这些恰恰是通用框架做不到的必须要算子库针对具体芯片去打磨。4. 看完源码之后手头模型推理提速 30% 的完整调优过程4.1 定位瓶颈不要凭感觉优化先上 profiler光看源码不动手是不行的。我读完核心逻辑之后立刻拿手头那个生成模型做了性能剖析。这里建议大家第一步永远是用 profiler 看一下算子级耗时排行。我那次的结果非常典型耗时前五的算子全是矩阵乘相关其中三个是融合了偏置和激活的线性层算子还有两个是注意力里的 QK^T 和 AV 运算。定位到瓶颈之后再去比对我读源码时注意到的几个关键点数据布局是否正确、tiling 参数是否合理、是否走了最合适的融合算子路径。结果发现了一个问题模型 input 的 tensor 是从另一个预处理模块过来的内存布局不是算子库中最优的那种排布导致执行时多了一次额外的数据转换。这种转换在算子耗时里看不出来但会拖慢整体访存效率。4.2 调整策略改布局、换融合算子、修正 tiling针对定位出的问题我做了三处改动。第一处是把预处理模块的输出布局直接改成算子库推荐的排布省掉运行时转换。第二处是把我自己写的一个自定义算子一个带 mask 的矩阵乘替换成算子库原生支持的融合版本通过传入 mask 参数来达到同样效果避免自定义算子没有经过充分优化的问题。第三处是把部分矩阵乘的 tiling 参数手动指定成跟模型 shape 更匹配的档位而不是让它每次走默认的启发式选择。这三处改动单独看都不大合在一起效果就出来了。用同一份输入数据、同一个 batch 大小部署环境完全一致的情况下端到端推理耗时从原来的 408ms 降到了 287ms提升约 29.7%。其中融合算子替换的贡献最大接近六成布局调整贡献了两成多tiling 参数微调贡献了不到两成。4.3 验收与回归提速之后更要测稳定性性能优化最怕的是只看到 benchmark 变快一上真实业务就出问题。所以我做了一套简单的回归测试准备几组不同长度的输入序列分别跑优化前和优化后的版本除了看耗时还对比了输出的数值误差。因为矩阵乘本身的精度受到 tiling 分块和累加顺序影响不同实现算出来的结果在小数点后几位可能有差异这个需要确认在你的业务可接受范围内。我还特意测了 batch size 从 1 到 16 的扩展情况。结果发现固定 tiling 参数在小 batch 下表现很好但 batch 变大之后反而是默认参数更优。这说明没有一套参数能通吃所有场景优化必须针对你真实的上线配置来做而不是拿一个 benchmark 场景的结论到处套。这也是我做完这次调优之后最大的感受。5. 踩过的三个隐蔽的坑与最后的实操心得5.1 坑一只盯着计算时间忘了数据转换开销第一次做算子级剖析时我只看每个算子自己的耗时没有关心算子之间的数据流动。后来才发现输入张量从 NHWC 转成 NCHW 的转换算子本身耗时不高但它涉及的整块数据搬移会污染缓存导致后续矩阵算子的访存速度变慢。这种隐形污染不做端到端对比根本发现不了。后来我把数据流也纳入分析范围看每个 tensor 的诞生位置、使用位置、消亡位置一下子就抓住了真凶。5.2 坑二盲目替换成官方融合算子反而变慢融合算子并非所有情况下都更快。有一次我把一个矩阵乘加残差加 LayerNorm 的自定义流程替换成算子库的融合版本结果耗时反而涨了 15%。后来排查发现那个融合算子为了兼顾多种 Shape内部有很复杂的分支处理而我当前的输入 shape 恰好落入了一条低效路径。所以说融合算子的性能优势是有前提的shape 合适、走对分支。遇到这种情况建议把候选实现都写成一个几十行的 profile 脚本实际跑一遍再决定用哪个别只看文档宣传。5.3 坑三tiling 参数照搬别人的成功案例网上能搜到不少性能调优经验比如某模型把 block_k 设为 128 效果最好。但这类结论跟硬件架构强相关跟矩阵尺寸强相关跟甚至数据类型强相关。我试过把一个在 A 芯片上表现很好的 tiling 配置搬到 B 芯片上结果性能下降 40%。原因是两代芯片的缓存大小和矩阵乘单元宽度完全不同。比较靠谱的做法是自己写一个小的参数扫描脚本把可能的分块组合各跑一遍再做决策。5.4 最后的实操心得这次深入解码算子库源码我最想分享的体会是优化 AIGC 模型性能不能只停留在调并行策略和改 batch size 的层面。往下走一层把矩阵乘这类线性基石算子的实现逻辑搞清楚你会发现可做的事情其实很多而且一旦做对效果非常确定。哪怕你只是需要一个现成的解决方案也要懂得怎么去代码平台里找对仓库、看对文件、跑通验证。建议每个想深入推理优化的人都花点时间读一读自己常用 AI 计算架构对应的算子库源码先从最简单的矩阵乘开始把 tiling、layout、融合算子这三件事彻底弄明白后面再遇到性能问题就不会两眼一抹黑了。