省算力新利器 DeepGEMM：从 GEMM 原理到 LLM 推理加速实践

做深度学习训练和推理的朋友应该都有这种感觉：模型规模越堆越大，算力账单也越来越吓人。不管是自己搭卡跑实验，还是在云上租集群，最后发现真正卡脖子的往往不是模型设计，而是底层那层“看不见”的矩阵乘法。最近我花了不少时间研究一个叫DeepGEMM的开源项目，它的定位非常直接——把省算力这件事也开源了。简单说，它就是一套面向深度学习场景的高性能矩阵乘法实现，专门在GPU上把GEMM（通用矩阵乘法）做到极致省算力、极致省显存。这篇文章就结合我自己的调研和实测记录，把这套东西的设计思路、核心优化点和部署经验梳理清楚，给正在搞模型压榨、推理加速或者算子开发的朋友作个参考。

GEMM是所有深度学习框架的绝对底层命脉。Linear层、卷积的im2col展开、Attention里的QK^T和PV、MLP里的两个大矩阵相乘，本质都是GEMM。在LLM推理场景里，GEMM和GEMV（矩阵向量乘）加起来往往占据总耗时的一半以上。所以你会发现，不管底层框架怎么换，N卡也好、国产卡也好，大家都在拼命优化GEMM。谁把GEMM做快了，谁就能让模型跑得更快、吃得更少。

DeepGEMM有意思的地方在于，它不只是一个算法demo，而是把一套完整的“如何把GEMM做到极致高效”的方法论直接开源了。它同时照顾了性能和易用性：性能上对标那些闭源算子的调优结果，使用上又不需要你搞复杂的手写kernel和模板元编程。从实际落地的角度看，这种组合非常有吸引力。往下我会从需求拆解、核心机制、部署实测和踩坑经验几个维度展开，把这一整套东西讲透。

1. 为什么大家都盯着GEMM不放

1.1 GEMM在深度学习里的位置

先回到最基础的问题：为什么GEMM这么重要？因为深度学习里几乎所有的密集计算都可以归结为矩阵乘法。拿Transformer来说，Self-Attention要算Q、K、V矩阵和序列特征做矩阵乘，Attention Score的计算是Q乘K的转置，加权求和又是Score乘V，前馈网络里两个Linear层更是两个标准的大型GEMM。甚至卷积操作，在很多高效实现里也会被重排成GEMM来做。换句话说，只要你跑Transformer系列模型，每一个token的生成背后都是数十次GEMM调用。

用个生活化的类比：GEMM就是深度学习世界里的“水电煤”。你写模型架构的时候不会直接碰到它，但每一次训练和推理都离不开它。它在底层发挥的作用，相当于基础设施。基础设施效率低一点，上层再优化也会被拖后腿。所以谷歌、某厂商这些硬件和框架的玩家，都会花巨大代价去维护和优化算子库——因为这就是模型性能的物理底座。

在LLM训练场景里，GEMM（矩阵乘矩阵）是主要形态；在推理场景里，除了传统GEMM，还大量出现GEMV（矩阵乘向量）和GEMM的混合形态。因为推理时batch size通常较小，很多时候一个矩阵维度退化成很小的数值，此时能否利用低精度计算、能否减少显存搬运，就直接决定了推理吞吐和时延。

1.2 省算力的核心逻辑：从FP16到FP8

这里要引入一个概念：算力也是分精度的。很多新架构GPU对FP16/BF16、FP8、INT8都有不同级别的算力支持。FP8的出现让“省算力”有了更具体的含义——你用更低的精度去算，硬件的吞吐可以大幅提升。说得直白一点，同样的时间里，GPU算FP8的矩阵乘法的速度是FP16的两倍甚至更高，而显存占用还能砍一半。

但低精度不是白给的。它带来两个麻烦：一是精度损失，直接全用FP8训大模型或者推大模型，accuracies会有肉眼可见的下降；二是硬件的低精度算力如果利用率上不去，那等于空有马力使不出来。DeepGEMM的一个核心关注点，就是用FP8这类低精度格式做GEMM，同时把硬件的低精度算力榨干。它会把一部分计算保持在高精度上，只在矩阵乘法的主体计算部分用低精度，再通过精细的数值处理把精度损失压到可控范围。

这种方式在业界已经有一些实践，比如训练时先用FP16/BF16做前向，反向时视情况用FP8；推理时把权重和激活都量化到FP8。但真正落到每个GEMM调用上，能把它做得既快又稳，绝非写几行简单代码就能搞定的事情。

1.3 为什么还需要一个新的GEMM实现

看到这里你可能会有个疑问：现有框架不是已经有CUTLASS、CUBLAS、TensorRT这些方案了吗？为什么还要一个新的GEMM实现？我的理解是：场景不同，痛点不同。

CUBLAS是某硬件厂商闭源的，通用性很好，但很多情况下它不是最快的，而且你没办法为特定shape和特定硬件魔改。CUTLASS虽然开源，但学习曲线极其陡峭，模板套模板，编译期逻辑非常重，对普通算法工程师来说维护成本很高，而且它对新硬件的适配往往有滞后。TensorRT是推理引擎层面的方案，封装程度高，你想把它拆出来单独做某个算子很难。

DeepGEMM的差异化在于它采用了一条务实路线：针对主流GPU架构做手写精细优化，同时把代码量控制在很小的范围内，让你不仅能看懂、能改，还能快速集成。这种“小而精”的风格，反而是算子库领域里稀缺的气质。它不追求覆盖所有硬件所有场景，而是让你看到GEMM这一件事在特定硬件上如何被做到极致。

2. DeepGEMM的省算力思路拆解

2.1 计算侧：高利用率是怎么来的

讨论省算力，第一个绕不开的指标就是硬件利用率。一个GEMM kernel跑得慢，很多时候不是因为卡不行，而是因为数据没喂饱、计算单元在空等。DeepGEMM花大力气做的第一件事，就是让GPU的Tensor Core（专门做矩阵乘法的硬件单元）尽可能满载。

要做到满载，核心是分块（tiling）策略。GPU执行GEMM时，不是一次性把整个大矩阵都塞进计算单元，而是拆成很多个小块（block），每个块对应一组计算任务。分块大小直接决定了两件事：数据能不能复用、计算单元忙不忙。如果块太小，访存次数就多，带宽被浪费；块太大又会超出片上存储（shared memory）的容量，导致频繁读写显存。

DeepGEMM在分块上做得比较聪明的地方，是按照硬件的存储层次去匹配分块尺寸。它不会把块设得特别大，而是刚好让A和B的两个小块能同时放进shared memory，并且能够覆盖足够多的计算量，让计算和访存形成流水线。这样每个数据从显存搬到片上之后，能被重复用很多次，计算密度上去了，整体的有效算力也就上去了。

再配合上多级流水线调度，整个kernel在执行时就像一条顺畅的工厂流水线：这一批数据在计算单元里跑的同时，下一批数据已经在路上搬运了，上一批结果则在写回显存。三个动作重叠起来，GPU的各个硬件单元就没有闲着的。这个原理说起来不难，但真正让它在各种shape下都能稳定跑出高利用率，是需要大量调试和实验的。

2.2 读写侧：怎么减少显存搬运

除了计算单元要忙，另一个省算力的关键是把数据搬运量压到最低。这个道理和CPU缓存优化完全一致——最慢的操作永远是内存访问。GPU的场景里，显存带宽虽然比CPU内存高很多，但相对计算速度依然是瓶颈。很多kernel性能差的根源就是把大量时间花在了搬数据上，而不是算数据上。

DeepGEMM减少数据搬运的主要手段，是充分利用GPU的异步拷贝能力和shared memory的复用机制。它会在kernel启动前，把需要计算的矩阵分块的数据准备好，通过异步方式预取到片上。片上shared memory的读写速度远快于显存，所以只要数据进了片上，剩下的计算就非常快。这套机制在DeepGEMM里是通过硬件提供的一些特殊指令实现的，代码写起来会比老式的手动同步方案简洁得多，而且不容易出现数据竞争。

另一个思路是kernel融合。传统的做法是，算完一个矩阵乘法，把中间结果写回显存，下一个算子再从显存里读出来。这一写一读，就是两次显存流量。DeepGEMM的做法是尽量把GEMM和它后面的操作（比如激活函数、残差连接、量化）合并在一个kernel里，结果还在片上寄存器的时候就直接处理掉，不再来回倒腾。这个手段在推理场景效果尤其明显，因为推理时显存带宽往往是真正的瓶颈。

2.3 简化部署：轻量级设计的价值

DeepGEMM在工程上的一个明显特点是轻。相比CUTLASS动辄几十万行的模板代码，DeepGEMM的代码量少得惊人。对于一个只想把模型跑快一点的团队来说，这意味着不用专门养一个算子开发团队去维护。你可以拿过来，编译，跑通，然后针对自己的模型shape微调几个参数，直接就集成到项目里。

这种轻量级设计是有意识的选择。它不试图成为万能算子库，而是做“最常用场景下的极致性能”。所以代码里很多地方做了硬编码假设，比如默认某种布局、默认某种数据类型组合。这些假设平时看不出来，遇到不匹配的场景才需要你研究怎么改。但从工程角度讲，这种“针对性强”反而更适合被集成，因为行为和性能都可预测，不会因为配置复杂而出现莫名其妙的分支。

我自己的体会是，阅读DeepGEMM的源码比阅读大型算子库要愉快得多。它能让人在一两个小时内理解核心思路，甚至在关键地方看到可读性很好的注释。这种可维护性，是它在“省时间”层面的价值——不省你的算力，但省你的开发时间。

3. 核心优化机制剖析

3.1 异步流水线与数据并行

DeepGEMM的设计里，最核心的机制是用异步流水线把访存和计算重叠起来。这里不用太纠结厂商指令集的细节，把思路理解清楚即可。

假设你要算一个很大的GEMM：A矩阵乘B矩阵得到C矩阵。朴素的做法是：把A的一块和B的一块加载进shared memory，同步等待加载完成，然后让Tensor Core计算，等计算完成，写回C，然后再加载下一块。这个流程最大的问题是：加载数据的时候计算单元在等，计算的时候加载单元在等。整个硬件利用率可能连一半都不到。

DeepGEMM的做法是把加载变成异步的：先启动加载第一批数据的操作，不等它完成，CPU侧的逻辑就继续往下走；等真正要计算时，数据已经在片上了。在计算第一批的同时，后台已经把第二批数据加载到shared memory的另一块区域。这种“双缓冲”甚至“多缓冲”机制，让加载和计算像两条并行的流水线一样各跑各的。从结果来看，kernel的总执行时间约等于“计算时间 + 最后一小段加载时间”，而不是“加载时间 + 计算时间”。

这套思路其实在CPU的高性能计算里也有对应版本，叫软件流水线。但在GPU上实现起来，难度在于同步和异步的边界要分得非常清楚。DeepGEMM做得好的地方在于它把数据依赖关系梳理清楚了：哪些加载必须等，哪些加载可以提前，哪些计算必须等加载完成。只有这些依赖摆对了，流水线才跑得起来。

3.2 算子和激活函数的融合

GEMM的融合优化是推理加速里的一大杀器。在LLM推理里，一个Transformer层通常包含：QKV投影矩阵乘、Attention Score计算、Softmax、Attention输出矩阵乘、残差连接、LayerNorm、MLP的两个矩阵乘、激活函数GELU/SiLU等。如果每一小步都生成一个独立的kernel，中间结果来回写显存，那访问流量会爆炸。

DeepGEMM支持把矩阵乘法与一些逐元素算子融合。比如计算完MLP的第一个GEMM之后，直接在寄存器里做ReLU或者GELU，再作为下一个GEMM的输入，省掉一次完整的写出和读入。这听起来简单，但实现上有不少细节要处理：边界条件、数据类型转换、融合算子的数值稳定性等。

融合还有一个额外的好处：减少kernel启动开销。GPU上启动一个kernel是有固定开销的，虽然单个kernel启动只要微秒级，但一个大的Transformer模型可能有几百个kernel，这些开销累加起来就很可观。融合之后kernel数量减少，单次推理的总延迟也会下降。这个优化方向在端侧和小batch推理场景里尤其受益明显。

3.3 低精度格式的处理细节

DeepGEMM另一个值得深挖的机制，是它对低精度格式（尤其是FP8）的处理。要用好FP8，不只是把数据从FP16切到FP8那么简单。FP8本身也有不同表示方式，有的范围大精度低，有的范围小精度高。矩阵乘法的输入可能需要不同的缩放因子，这些缩放因子还要在kernel内部动态计算或者预先校准。

精度处理上一个常见手段是“分块缩放”（block-wise scaling）。也就是不把整个矩阵统一用一个缩放因子，而是按小块分别计算缩放。这样做的好处是，每个局部的数值范围都被适配到最适合的表示范围，精度损失明显减小。代价是需要在kernel内部多做几次统计计算和缩放操作，但相比FP8带来的算力倍增，这点开销非常划算。

DeepGEMM里面还处理了一个容易被忽视的问题：累加精度。FP8输入乘出来之后，累加器往往还是用FP32甚至更高精度来累加，避免累加过程中的误差被放大。因为浮点数的加法存在舍入误差，如果累加器也用FP8，误差会快速累积。把累加精度保持在高位，虽然会稍微增加寄存器开销，但能显著提升最终结果的准确性。这是所有严肃的低精度GEMM实现都必须处理的问题。

3.4 手工调优：劳动密集型但高效

说到Optimization，很多团队的常规路径是依赖自动调优工具（autotuning），让程序在运行时搜索最佳的分块参数和调度策略。这种方法通用性强，但搜索空间巨大，耗时也长。DeepGEMM在这一点上走的是另一个极端：它用人工经验把关键参数先钉死，然后针对特定硬件做手工打磨。

这样做的好处是代码运行路径非常确定，没有运行时搜索的开销，性能是“可解释的”而不是“神秘地很快”。缺点是遇到新的硬件架构或者非常特殊的shape，你需要自己下场去调参数。好在其核心代码的可读性比较好，调整参数也不是什么恐怖工程。

我自己的习惯是：先用DeepGEMM的默认参数跑一遍，然后用profiling工具看是访存瓶颈还是计算瓶颈。如果访存瓶颈明显，就考虑增大分块来增加数据复用；如果计算瓶颈明显，再检查是不是某些融合操作没生效或边界处理引入了额外开销。几轮下来，大部分场景都能收敛到不错的性能表现。

4. 部署接入实战记录

4.1 编译与基本接入流程

DeepGEMM的编译过程非常轻量。它依赖的组件很少，在主流Linux环境下基本不需要额外装重型依赖。整个编译耗时大概在几十秒到一两分钟级别，这点对需要反复修改和测试的场景特别友好，不会像CUTLASS那样改个参数编译时长赶上一杯咖啡的时间。

接入流程大致是：把DeepGEMM的源码作为子模块放进项目里，在构建脚本里加上对应的编译目标，然后在你的推理引擎或训练脚本里调用它的接口。它的接口设计也比较克制，核心就是传矩阵的指针、行数、列数、布局信息、数据类型和缩放因子。你不需要关心kernel内部怎么切分、怎么调度，框架已经替你安排好了。

不过有一点要提前规划：因为它的目标是极致性能，所以接口设计是面向“你已经知道自己要算什么”的场景，而不是一个自动调度器。换句话说，它不会帮你分析模型结构然后决定用哪个kernel，而是把kernel提供给你，由你在上层做选择。这对绝大多数场景来说是合理的，毕竟GEMM的shape和布局通常是确定的。

4.2 性能对比怎么测才靠谱

性能对比这个环节最容易翻车。很多人拿DeepGEMM和一个库比一下端到端时间就下结论，这是不科学的。正常的对比流程，应该是先确定你的测试矩阵的shape范围，再保证输入数据一致、精度一致、GPU频率一致，然后分别跑同样次数取中位数或者最小值，最好再用profiling工具确认是不是被正确调用。

我在实测中大概测了三组不同规模的矩阵乘：小矩阵（模拟推理场景的GEMV）、中矩阵（常见模型hidden size级别）、大矩阵（训练场景的典型规模）。DeepGEMM整体上在小矩阵和中矩阵的优势最明显，因为它的kernel启动开销更低、数据搬运优化更彻底。大矩阵也有提升，但幅度受限于整体访存带宽上限。

另外要注意的一点是，性能和精度要一起看。如果只看性能不看误差，就有可能出现输出和参考值差别很大的情况。正常情况下DeepGEMM输出的误差应该在低精度格式的理论误差范围之内，如果你发现误差明显偏大，优先检查缩放因子的计算和累加器的数据类型设置，这两个地方是低精度GEMM误差的主要来源。

4.3 哪些场景最适合用DeepGEMM

根据我这段时间的体验，最适合用DeepGEMM的场景主要有三类。

第一类是LLM推理引擎的自研算子层。如果你的推理服务使用在线batch或动态shape，对延迟要求很高，那么替换掉通用矩阵乘算子，直接调用DeepGEMM，往往能拿到立竿见影的提速。

第二类是训练框架的特定模块优化。尤其是混合精度训练中用FP8做前向和部分反向计算的环节。虽然训练场景的shape通常更大更规整，但DeepGEMM对核心矩阵乘的优化依然能带来额外收益。

第三类是算子开发的学习和研究场景。它的代码规模小、注释清晰、优化思路完整，非常适合用于教学和二次开发。你想写自己的优化算子，拿它当底子改比从零开始要快得多。

如果你的场景是CPU推理、非主流架构GPU、或者极稀疏的矩阵运算，那DeepGEMM可能不是最佳选择，它的路线是为密集GEMM和特定硬件架构设计的，用错场景反而会事倍功半。

5. 常见问题排查与避坑实录

5.1 布局和Shape检查：先说老生常谈

集成DeepGEMM时最常见的报错就是矩阵布局不匹配。GPU上的矩阵布局分为行主序（row-major）和列主序（col-major），以及不同的转置标志。很多框架默认的内存布局和DeepGEMM的默认假设不一定一致。如果接口文档没写清楚，传进去之后轻则结果错误，重则直接报显存访问越界。

我建议在接入前先把你的矩阵在内存中的实际排布打印出来，确认行、列、stride等信息，再对照DeepGEMM的接口要求做转换。转置操作本身也有开销，如果能在上层提前把布局调整好，性能会更好。

另外一个容易忽视的点就是矩阵维度对齐。很多面向Tensor Core的GEMM实现要求维度是8、16或32的倍数，非对齐维度会有额外的tail处理逻辑，这部分逻辑如果用不好，性能会急剧退化。DeepGEMM虽然会内部处理，但不代表所有非规整shape都能跑出理想性能。遇到这种场景，我一般会在上层做padding，把维度补到对齐要求，实测效果比复杂tail逻辑好得多。

5.2 融合操作边界条件的坑

融合算子看起来是高收益率优化，但边界条件处理不好就会在特殊shape下产生错误。最典型的是归一化层（比如LayerNorm）被融合进GEMM时，如果矩阵的某一行长度特别短，归一化统计量的计算可能不稳定或者需要走单独的代码路径。

如果你在集成融合功能时发现某些shape下误差突然变大，优先怀疑的不是GEMM主体，而是融合进来的归一化和激活函数的边界逻辑。这些逐元素算子通常假设每个元素独立处理，但融合进GEMM后，会被安排在不同的线程上并行执行，线程间的边界和共享变量处理需要格外留意。

还有一个隐藏点：融合后的kernel不容易调试。分段跑每个算子都能跑对，合在一起错了，你很难确定是哪一步引入的错误。我的习惯是先用工具定位到出错的数据范围，然后对照未融合版本做逐block的比对，把问题范围缩小到具体的那一个融合操作。

5.3 精度和性能的权衡：没有免费的午餐

使用DeepGEMM时还有一个方向性的提醒：低精度优化本质上是拿精度换速度，只是好的实现可以把精度损失控制到很小。当你发现模型端到端精度掉得比较多时，可以先检查是不是某些敏感层也被强行用了低精度。LLM里不同类型的层对精度敏感度不同，比如attention score的计算就比MLP里的矩阵乘更敏感，前者如果被量化到FP8，对输出质量的影响可能远大于预期。

我自己在实践时的策略是：先跑一遍全链路低精度，验证整体性能收益，然后逐层替换回高精度，对比每个替换点的精度损失和性能回退，找到一个性价比最高的组合。这个过程中DeepGEMM灵活的接入粒度帮了大忙——它可以按单层调用，而不是强迫你全局切换。

还有一个小技巧：如果某个开关参数默认值在你的数据分布下效果不理想，不要急着改代码逻辑，先看看是不是数据的数值范围分布比较极端。FP8这种低精度格式对数值范围比较敏感，你可以尝试在数据预处理阶段做一次缩放或裁剪，把数值范围压到low精度最友好的区间，往往比修改kernel内部逻辑更省事。

5.4 常见问题速查表

写在最后的一些体会

前面讲了不少技术细节，最后聊点更贴近实际的东西。我最初接触DeepGEMM是抱着“看看它到底能快多少”的心态，深入下来才发现，它最有价值的倒不是某一个具体数值，而是它提供了一条很清晰的思考路径：从硬件特性出发，理解算力瓶颈在哪里、访存瓶颈在哪里，然后针对性地设计kernel。这种分析问题的方式，迁移到其他算子优化上同样有效。

另外一个体会是，DeepGEMM这类轻量级高性能算子的出现，对小团队特别友好。大公司的算法团队可以靠规模维护重型算子库，但大量中小团队没有这个资源。一个能看懂、能改、能快速集成的开源方案，把前沿优化手段的门槛拉低了一大截。如果你正在做模型部署或者推理加速，我建议花一个下午的时间把它的源码读一遍，再跑几个测试对比一下，大概率会有一些意外收获。