解码场景GEMM优化实战：从访存瓶颈到硬件环境排查

搞了半年多decoding相关的GEMM优化经验，我最大的感受是：真正的瓶颈往往不在数学本身，而在你如何认识这个算子的真实形态、如何伺候好底层硬件与运行环境。把一条自回归解码链路里反复执行的矩阵乘法拆开看，它的形状、访存模式、硬件映射和编译环境，每一环都可能让人头疼。这篇文章不打算复述教科书上的GEMM推导，而是把我实际踩过的坑、验证过的方案、以及几次看起来跟GEMM毫无关系的硬件/环境问题，一次性整理出来。

1. 解码场景的GEMM长什么样？先把问题定性

1.1 解码阶段的GEMM与训练阶段有本质区别

训练时的GEMM通常是大批量、方方正正的矩阵相乘，batch size动辄几十上百，所有token一次性喂进去，整个运算的算术强度高，可以尽情压榨GPU的浮点计算单元。但decoding阶段完全不一样，它是自回归的，一个token一个token地往外吐，每一步只处理当前生成的序列状态，实际参与计算的batch size往往只有1到8。

以常见的7B规模模型为例，hidden size通常在4096左右，feed-forward层的两个线性变换会把特征从4096维升到11008维再降回来，attention部分还有QKV投影和输出投影。每一步推理实际发生的GEMM，形状大致是M = batch_size, K = hidden_size, N = 权重输出维度，也就是M很小，K和N很大。这种瘦长形状的矩阵乘法和训练时那种“大方块”完全是两类问题，如果用训练时的思路去优化解码GEMM，很容易白忙一场。

1.2 解码GEMM的瓶颈是访存带宽，不是算力

有一句话特别适合形容解码阶段的GEMM优化：仓库很大，但门口的传送带太窄。GPU的FP16算力动辄上百TFLOPS，但HBM带宽通常只有几百GB/s到几TB/s，当每次GEMM只消费一批很小的输入时，计算单元根本吃不饱，真正拖后腿的是权重矩阵要从显存搬到计算核心的速度。

这就意味着，优化解码GEMM的核心目标不是“怎么算得更快”，而是“怎么让权重少搬几次、搬得更顺”。我在优化时一直提醒自己：先看内存访问模式，再看计算密度。算术强度越高，越值得花精力做计算优化；算术强度低，就得想方设法减少访存量，比如做权重缓存、算子融合、低精度量化。先把这个定性搞清楚，后续所有优化手段才有方向。

2. 优化思路与核心手段拆解

2.1 分块到底怎么分？先看数据能不能进Cache

GEMM优化里最核心的动作是分块，也就是把大矩阵切成能塞进Cache和寄存器的小块，提高数据复用率。但解码场景的GEMM形状特殊，分块策略也要跟着变。

我在实际调参中常用的tile尺寸组合是tile_m = 16 或 32、tile_n = 64 或 128、tile_k = 8 或 16。这个选择不是拍脑袋定的，背后有几个硬约束：

• tile_m要小于等于实际batch size。解码时batch经常只有1或4，设成32会导致大量计算资源闲置。所以更推荐batch小的时候让一个线程块处理整个M维度，减少跨block的通信开销。
• tile_n要同时考虑寄存器容量和L2 Cache。N方向切太大会拖慢数据加载，太小又没法隐藏访存延迟。以FP16数据为例，一个128×16的A矩阵分块，如果直接用float4向量加载，大约需要512次128bit访存，这个数量和寄存器文件的容量需要匹配好。
• tile_k决定内层循环的重用距离。K方向是数据复用率最高的维度，但解码场景下K往往就是hidden size，取值4096左右，所以内层循环体要尽量轻，把从全局内存搬数据的开销压到最低。

我自己的经验是：先用tile_m=16, tile_n=64, tile_k=16作为baseline，然后根据实测的访存吞吐率微调。遇到M特别小的情形，甚至可以把tile_m直接设为M本身，让一个block把整个batch的GEMM扛下来。

2.2 向量化加载与内存对齐的坑

GEMM优化的另一个关键点是向量化。GPU和现代CPU都支持128bit甚至更宽的向量访存指令，一次能搬4个FP16。如果数据地址没有对齐，编译器只能退化成逐元素访问，性能会大幅跳水。

我在写优化代码时，会确保权重矩阵的行首地址按16字节对齐。CUDA里具体操作是给张量分配内存时用cudaMalloc，它天然对齐256字节；但在自己写kernel或者做TensorCore对齐时，要特别注意矩阵leading dimension是不是16的整数倍。曾经遇到一个情况：权重矩阵的列数不是对齐值，导致每行开头都错位，向量化加载根本没法生效，性能直接掉了30%。

对于ARM NEON或者x86 AVX2指令集，同样的逻辑也适用。AVX2一次可以加载32字节，AVX512能加载64字节，如果数据没对齐，性能差异会非常明显。所以无论跑在什么硬件上，我拿到权重第一件事就是检查alignment，这一步做了，后面才能谈进一步优化。

2.3 底层库选型：用对工具比手写Kernel更划算

做GEMM优化很容易陷入“我要手写一个完美Kernel”的执念，但现实是，成熟的底层库往往已经针对各种shape做过大量调优。我的经验是：首先评估cuBLASLt和CUTLASS，看它们能不能直接满足需求；确实有特殊融合需求，再考虑手写或改Triton。

cuBLASLt有一个很好用的功能：cublasLtMatmulPreference配合cublasLtMatmulHeuristicSearch，可以自动搜索当前形状下的最优算法配置。我在解码链路上固定M=1或4、K=4096、N=11008这类形状时，用启发式搜索比默认配置快了不少。需要注意一点：启发式搜索本身有耗时，不能每次推理都跑，而是提前离线搜好，把选中的配置缓存起来，线上直接复用。

CUTLASS的价值在灵活性，它允许你自定义epilogue，比如把GEMM和残差连接、激活函数融为一体。但代价是需要花时间理解它的C++模板体系。Triton则更适合快速验证想法，Python画风，迭代很快，但精细化控制不如CUTLASS到位。工具选型没有绝对标准，我的建议是先跑cuBLASLt看上限在哪，再决定要不要上CUTLASS。

3. 硬件层面：一桩被“Above 4G Decoding”卡住的怪事

3.1 症状：解码验证跑到一半突然崩溃

有一阵子我在一台老平台上做解码性能验证，主板是H81，配了一块支持大容量显存的显卡。每次跑到某些GEMM形状时，程序就会突然崩溃，日志最后一行类似：

configuration: crash decoding : disabled - no sandbox or build area path cra...

当时第一反应是算子库安装有问题，或者显存不足，但排查来排查去，显存占用才40%。后来无意中发现，显卡在系统里被识别成只有不到4GB的地址空间，明明卡上显存更大，驱动能看到的BAR区域却非常小。我就顺着这个线索去翻BIOS，果然找到了问题根源。

3.2 Above 4G Decoding到底是什么？为什么它会影响GEMM任务

ABove 4G Decoding，直译就是“允许4G以上地址空间的解码”，在PCIE语境下是让显卡的BAR可以把MMIO地址映射到整个64位地址空间，而不仅仅限制在4GB以下。

传统32位系统里，硬件设备的寄存器、显存映射都要占用4GB以下的地址空间，如果多张显卡、多块NVMe设备同时占地方，地址很容易冲突。H81这种老主板BIOS默认把Above 4G Decoding关掉，显卡只能把自己的一部分显存映射到低地址空间。对游戏来说影响可能不明显，但对深度学习这类需要大量显存映射和解码访存的任务来说，BAR空间受限会导致驱动没法正确映射整个显存，进而引发随机崩溃或性能骤降。

开启方式很简单：开机进BIOS，找到“高级”或“PCI子系统设置”菜单，把“Above 4G Decoding”设为Enabled，保存重启。如果主板支持Resizable BAR相关的选项，一般也建议一并打开，它允许CPU一次访问更大的显存映射区域，对于GEMM链路里频繁读写权重有实际帮助。开启后，显卡在系统里的地址映射会变大，显存分配也更完整，原先偶发的崩溃基本消失，性能也更稳定。

3.3 开启这个选项的副作用与注意点

这个选项虽然好用，但也不是毫无代价。首先是部分老主板开启后，开机自检画面可能会变慢，甚至影响传统Option ROM的加载顺序。如果机器还插着老式非UEFI显卡，可能出现启动黑屏的情况，需要把CSM模块打开兼容。其次是有些主板上的Above 4G Decoding会默认关闭，不是因为主板不支持，而是为了避免兼容性问题，需要手动打开。

如果你手里的机器还有其他PCIe设备，比如采集卡、声卡、网卡，开启后留意一下这些设备的驱动是否还正常。我自己的经验是，测试深度学习机器时优先开启，但如果发现其他设备异常，可以先只保留GPU做最小化验证，逐一排除冲突源。优化GEMM时，很多性能指标和稳定性问题最后都要回到硬件配置上找原因，BIOS这一个选项往往是被忽略的重灾区。

4. 编译与运行环境里那个“no sandbox or build area path”的崩溃

4.1 这个报错到底在说什么

排除了BIOS问题后，日志里的no sandbox or build area path又单独出现过几次，尤其是我在自动化脚本里跑GEMM自动调优、内核编译和基准测试的时候。这行日志看起来吓人，翻译成人话就是：系统没有配置沙箱或构建工作目录，编译器内核无法把临时文件写到可用位置。

很多算子库在首次运行时需要把kernel代码编译成可执行模块，它们依赖环境变量指定的构建目录，比如HOME,TMPDIR,BUILD_DIR。如果这些环境变量指向的路径不存在、不可写，或目录超出当前用户权限，工具会直接崩溃，并打出类似“crash decoding: disabled”的日志。这里的“decoding”指的是把二进制/字节码解码成可执行指令的过程，不是自然语言解码，所以跟模型推理本身没有直接关系。

4.2 排查步骤：先看环境再看权限

遇到这个报错，我的排查顺序其实非常固定：

1. 先确认日志里提到的构建目录是哪一个，通常能从完整堆栈中看到路径关键词。
2. 检查这个目录是否存在，以及当前运行用户是否有写入权限。可以用一条命令直接测试：

   mkdir -p /tmp/gemm_build && touch /tmp/gemm_build/.write_test

3. 检查HOME、TMPDIR、BUILD_DIR这些环境变量是否被错误设置。比如容器里HOME指向一个只读目录，或者CI工具把TMPDIR设为不存在的位置。
4. 排除磁盘空间不足的问题。构建缓存如果特别大，临时目录满了后，工具链不会友好地提示“磁盘满”，而是直接以莫名其妙的方式崩溃。

4.3 修复与预防方案

修复方案不复杂，关键是统一约定构建路径。我现在的做法是在所有部署和测试脚本开头，显式设置：

export HOME=/root export TMPDIR=/tmp export BUILD_DIR=/tmp/gemm_build mkdir -p "$BUILD_DIR"

有些带命令行参数的工具，还可以更明确地传构建目录，比如：

python run_benchmark.py --build_dir /tmp/gemm_build

还有一点特别容易踩坑：构建目录路径里不要有中文、空格或特殊符号。我曾在某个云主机上把BUILD_DIR设成带空格的目录，结果工具链在解析路径时把参数切成两半，报了完全无关的错误。后来统一用短横线命名，问题再没出现过。

5. 实操评估：性能数据、参数选择与反复调整记录

5.1 一次真实的优化前后对比

下面这组数据来自我在某张消费级显卡上做的解码GEMM测试，形状固定为M=1、K=4096、N=11008，即单batch、单token时feed-forward网络第一个线性层的典型形状，数据类型是FP16。耗时是我多次跑完取的中位数。

这组数据说明几个问题：一是朴素实现确实很慢，二是基础优化就能带来明显收益，三是当算法侧优化到一定程度后，硬件环境的影响就会浮出水面。开启Above 4G Decoding之后，单次GEMM的耗时并没有剧烈下降，但耗时波动从±20%缩小到±5%以内，这对解码链路来说意义很大，因为解码是串行的，任何一步抖动都会直接影响端到端延迟。

5.2 tile尺寸的调参记录

我还系统记录过tile尺寸对耗时的影响。同样是上述形状，固定tile_k=16，变化tile_m和tile_n：

这里有个经验：当M为1时，盲目加大tile_m没有意义，因为数据根本没那么多。反而是tile_n要尽量大，让每次向量化加载能覆盖更长的连续数据，让访存和计算尽量重叠。但如果tile_n太大导致寄存器溢出，性能会断崖式下跌，所以调参时一定要盯着编译信息里的寄存器占用和local memory spill警告。

5.3 正确性与数值精度验证

优化做完了，最怕的是“跑得快但是算错了”。我在每次改动后都会做一次回归验证，方法很简单：用CPU双精度计算同一组输入作为参考，然后把GPU输出转回FP32，计算最大绝对误差和相对误差。一般FP16 GEMM的误差在1e-2量级是可以接受的，但如果优化过程里擅自改了累加顺序、用了TensorCore的低精度累加，误差可能会到1e-1甚至更大，这种就不能用了。

TensorCore的FP16 GEMM默认会产生与普通FMA不同的舍入误差，如果业务对精度敏感，建议保留FP32累加器，或者对某些关键层退回FP32计算。我还有个习惯是固定随机种子、固定输入数据，把优化前后的输出dump下来做逐位比较，这样能及时抓住异常变化。

6. 实战中容易误判的几个问题

排查GEMM优化问题，很多时候真正花时间的不是改代码，而是定位方向。我把最近半年遇到的高频问题整理成一个速查表，方便下次照着查：

我现在排查问题的顺序基本是：先确认环境变量和构建目录，再查BIOS层面的地址映射，然后再回到算法本身的tile和访存配置。很多人一上来就扎进kernel代码里调参，结果发现问题根本不在那。我个人的习惯是，拿到一台新机器，先花半小时把驱动、BIOS选项、临时目录权限全部确认一遍，这半小时看起来是浪费，实际能省下后面一整天的“定位时间”。

另外一个小技巧：所有GEMM基准测试都建议固定GPU频率再进行对比，否则调度器自动boost会导致同一次测试不同轮次的结果差距很大，你以为是代码问题，实际是频率波动。用锁频工具把显卡的core clock锁定到某个固定值，跑出来的数据才真正有对比意义。