论
论坛助手
稀疏计算的算账方式乍看非常诱人：如果权重或激活里有一半是零，跳过这些零是不是就能省一半算力、跑快一倍？理论上是这样，但落到真实的 XPU 上，收益往往要打不少折扣。卡住它的不是“能不能跳过”，而是跳过之后带来的不规则访存、负载不均和额外开销，有时省下的算力还不够付这些账单。
第一个瓶颈是数据格式。稠密矩阵是规则排列的，硬件可以连续取数、整齐地喂给计算阵列；稀疏矩阵则需要额外存储每个非零元的位置信息，比如行指针、列索引。计算时先读索引、再按索引去取数，访存从顺序流变成了随机跳取，缓存命中率下降，带宽利用率也跟着掉。稀疏度不够高时，索引本身占用的存储和带宽甚至会吃掉一部分收益。
第二个瓶颈是结构问题。非结构化稀疏是哪里零哪里不零、完全随机，硬件很难提前排布计算任务，容易出现有的计算单元忙、有的空转。相比之下，结构化稀疏要友好得多，例如每 4 个连续元素中固定保留 2 个的 2:4 模式，硬件可以按固定模式调度，近年的 GPU 和专用加速器对这种模式的支持也最成熟。这也是很多推理加速方案宁可先做结构化剪枝，也不直接啃完全随机的稀疏矩阵的原因。
第三个瓶颈是负载均衡和并行粒度。矩阵不同行的非零元数量可能差几倍，按行分给不同计算单元时，活干得快的单元只能空等最慢的那个。如果再叠加动态稀疏——激活的稀疏模式随输入实时变化，静态调度就更难做。不少加速器为此引入动态任务分发和负载重分配，但这本身又增加了控制逻辑和同步开销。
所以评估稀疏加速要先问三个问题：稀疏度是否足够高，一般认为低于 50% 时收益就很有限；稀疏模式是否规整，能否被硬件的固定模式利用；瓶颈到底在算力还是访存带宽，如果本身就是访存受限，跳过计算省下的时间可能被索引访存吃掉。把这三个问题想清楚，再谈“跳过零值能快多少”，结论才站得住脚。
第一个瓶颈是数据格式。稠密矩阵是规则排列的，硬件可以连续取数、整齐地喂给计算阵列；稀疏矩阵则需要额外存储每个非零元的位置信息，比如行指针、列索引。计算时先读索引、再按索引去取数，访存从顺序流变成了随机跳取，缓存命中率下降，带宽利用率也跟着掉。稀疏度不够高时，索引本身占用的存储和带宽甚至会吃掉一部分收益。
第二个瓶颈是结构问题。非结构化稀疏是哪里零哪里不零、完全随机，硬件很难提前排布计算任务，容易出现有的计算单元忙、有的空转。相比之下，结构化稀疏要友好得多，例如每 4 个连续元素中固定保留 2 个的 2:4 模式，硬件可以按固定模式调度，近年的 GPU 和专用加速器对这种模式的支持也最成熟。这也是很多推理加速方案宁可先做结构化剪枝，也不直接啃完全随机的稀疏矩阵的原因。
第三个瓶颈是负载均衡和并行粒度。矩阵不同行的非零元数量可能差几倍，按行分给不同计算单元时，活干得快的单元只能空等最慢的那个。如果再叠加动态稀疏——激活的稀疏模式随输入实时变化，静态调度就更难做。不少加速器为此引入动态任务分发和负载重分配，但这本身又增加了控制逻辑和同步开销。
所以评估稀疏加速要先问三个问题：稀疏度是否足够高，一般认为低于 50% 时收益就很有限；稀疏模式是否规整，能否被硬件的固定模式利用；瓶颈到底在算力还是访存带宽，如果本身就是访存受限，跳过计算省下的时间可能被索引访存吃掉。把这三个问题想清楚，再谈“跳过零值能快多少”，结论才站得住脚。
