摘要很多人优化 AI 推理时第一反应是“换更强的 GPU”。但在不少场景里模型慢并不是因为计算单元不够而是因为数据搬来搬去太频繁。算子融合就是为了解决这个问题把多个连续的小操作合并成一个更大的执行单元减少中间结果读写让数据尽量停留在更近、更快的地方。本文用一个简单例子讲清楚为什么算子融合能提升推理性能以及它并不是所有场景都适合。一、模型推理慢可能慢在“搬数据”假设有这样一段计算y relu(x * w b)从数学上看它只是三步乘法加法ReLU 激活。如果按普通方式执行可能会变成三个独立算子x 和 w 读入内存 - 计算乘法 - 写出中间结果 tmp1 tmp1 和 b 读入内存 - 计算加法 - 写出中间结果 tmp2 tmp2 读入内存 - 计算 ReLU - 写出最终结果 y问题来了每一步都要读写内存。当张量很大时真正耗时的不一定是乘法和加法而是中间结果在显存和缓存之间不断搬运。计算单元可能还没吃饱内存通道已经堵住了。这就是所谓的内存带宽瓶颈。二、算子融合到底融合了什么算子融合的核心思想很朴素既然这几个操作总是连续执行为什么不放在一起算融合后执行过程可能变成读入 x、w、b 在一个 kernel 内完成乘法、加法、ReLU 直接写出 y中间的 tmp1、tmp2 不再频繁写回全局内存而是在寄存器或更近的缓存里完成处理。这样做带来的收益主要有三个减少中间张量写入减少 kernel 启动次数提高数据局部性。对于很多小算子密集的网络这种优化非常明显。三、一个直观类比厨房流水线可以把推理过程想象成做饭。没有融合时切菜的人切完把菜端到仓库 炒菜的人再去仓库取菜 调味的人调完又送回仓库 装盘的人再去仓库取。每一步本身都不复杂但来回搬运太多。算子融合后同一个工作台上完成切菜、翻炒、调味、装盘。不是厨师变成超人了而是少走了很多路。AI 推理也是这样。融合优化的本质不是让每个计算更神奇而是让数据少旅行。四、哪些算子适合融合并不是所有操作都适合融合。通常比较适合的有element-wise 操作比如 add、mul、relu、sigmoid形状不变的连续计算前后依赖明确的小算子计算量不大但内存访问频繁的操作常见模式比如 Conv Bias Activation。例如MatMul Add Conv BatchNorm ReLU LayerNorm 中的部分连续步骤 Attention 里的某些投影和后处理这些模式如果拆开执行会生成大量中间张量。融合后可以减少数据落地。五、哪些情况融合反而不划算算子融合不是万能药。下面几类场景要谨慎第一融合后 kernel 太复杂。如果把太多操作硬塞进一个 kernel寄存器压力可能变大反而降低并行度。第二不同算子的访存模式差异太大。有些操作适合顺序访问有些操作访问很跳跃强行融合可能让缓存命中率更差。第三动态 shape 太多。输入尺寸变化频繁时编译器很难提前生成稳定高效的融合策略。第四调试成本上升。多个操作合成一个执行单元后定位数值误差会更麻烦。尤其在混合精度场景里一个小小的融合顺序变化可能影响最终结果。所以工程上不是“能融合就融合”而是“收益大于代价才融合”。六、编译器在这里做了什么现代 AI 推理引擎和编译器通常会做几件事分析计算图找到连续可合并的算子模式判断 shape、数据类型和设备约束生成融合后的执行计划在运行时选择合适 kernel。从开发者角度看你可能只是写了普通模型代码。但在底层编译器会尝试把碎片化计算改写成更适合硬件执行的形式。这也是为什么同一个模型在不同推理引擎上的速度可能差很多。差别不一定只在硬件而在图优化、kernel 选择和内存调度。七、如何判断是不是内存带宽瓶颈如果你遇到推理慢可以观察几个现象GPU 利用率不高但显存带宽占用很高kernel 数量很多每个 kernel 执行时间很短profiler 里大量时间花在数据移动和小算子上batch 增大后吞吐提升不明显删除一些 element-wise 操作后速度明显变化。这时可以重点检查是否有大量中间张量 是否存在连续小算子 是否启用了图优化 是否使用了合适的数据格式 是否存在动态 shape 阻碍优化优化方向不一定是买更强的卡而可能是减少访存、打开编译优化、调整模型结构或切换推理引擎。八、开发者能做什么如果你不是编译器开发者也可以做一些事尽量使用推理框架推荐的模型导出方式避免在推理路径里插入大量零散 Python 逻辑固定输入 shape减少动态分支打开图优化或编译模式用 profiler 看 kernel 数量和显存读写对性能敏感模块做单独 benchmark谨慎使用会打断计算图的自定义操作。很多性能问题不是模型结构本身造成的而是模型落到工程代码后计算图被拆碎了。总结算子融合解决的是一个很现实的问题AI 推理不只需要“会算”还要“少搬”。当多个小算子连续执行时中间张量的读写会浪费大量内存带宽。通过融合推理引擎可以减少数据搬运、降低 kernel 启动开销并提升硬件利用率。但融合不是越多越好。真正成熟的优化需要在计算复杂度、寄存器压力、访存模式、动态 shape 和调试成本之间做平衡。一句话记住推理慢不一定是算力不够很多时候是数据在路上堵车了。
AI 推理慢不一定是算力不够：从算子融合看内存带宽瓶颈
发布时间：2026/6/25 12:30:20
摘要很多人优化 AI 推理时第一反应是“换更强的 GPU”。但在不少场景里模型慢并不是因为计算单元不够而是因为数据搬来搬去太频繁。算子融合就是为了解决这个问题把多个连续的小操作合并成一个更大的执行单元减少中间结果读写让数据尽量停留在更近、更快的地方。本文用一个简单例子讲清楚为什么算子融合能提升推理性能以及它并不是所有场景都适合。一、模型推理慢可能慢在“搬数据”假设有这样一段计算y relu(x * w b)从数学上看它只是三步乘法加法ReLU 激活。如果按普通方式执行可能会变成三个独立算子x 和 w 读入内存 - 计算乘法 - 写出中间结果 tmp1 tmp1 和 b 读入内存 - 计算加法 - 写出中间结果 tmp2 tmp2 读入内存 - 计算 ReLU - 写出最终结果 y问题来了每一步都要读写内存。当张量很大时真正耗时的不一定是乘法和加法而是中间结果在显存和缓存之间不断搬运。计算单元可能还没吃饱内存通道已经堵住了。这就是所谓的内存带宽瓶颈。二、算子融合到底融合了什么算子融合的核心思想很朴素既然这几个操作总是连续执行为什么不放在一起算融合后执行过程可能变成读入 x、w、b 在一个 kernel 内完成乘法、加法、ReLU 直接写出 y中间的 tmp1、tmp2 不再频繁写回全局内存而是在寄存器或更近的缓存里完成处理。这样做带来的收益主要有三个减少中间张量写入减少 kernel 启动次数提高数据局部性。对于很多小算子密集的网络这种优化非常明显。三、一个直观类比厨房流水线可以把推理过程想象成做饭。没有融合时切菜的人切完把菜端到仓库 炒菜的人再去仓库取菜 调味的人调完又送回仓库 装盘的人再去仓库取。每一步本身都不复杂但来回搬运太多。算子融合后同一个工作台上完成切菜、翻炒、调味、装盘。不是厨师变成超人了而是少走了很多路。AI 推理也是这样。融合优化的本质不是让每个计算更神奇而是让数据少旅行。四、哪些算子适合融合并不是所有操作都适合融合。通常比较适合的有element-wise 操作比如 add、mul、relu、sigmoid形状不变的连续计算前后依赖明确的小算子计算量不大但内存访问频繁的操作常见模式比如 Conv Bias Activation。例如MatMul Add Conv BatchNorm ReLU LayerNorm 中的部分连续步骤 Attention 里的某些投影和后处理这些模式如果拆开执行会生成大量中间张量。融合后可以减少数据落地。五、哪些情况融合反而不划算算子融合不是万能药。下面几类场景要谨慎第一融合后 kernel 太复杂。如果把太多操作硬塞进一个 kernel寄存器压力可能变大反而降低并行度。第二不同算子的访存模式差异太大。有些操作适合顺序访问有些操作访问很跳跃强行融合可能让缓存命中率更差。第三动态 shape 太多。输入尺寸变化频繁时编译器很难提前生成稳定高效的融合策略。第四调试成本上升。多个操作合成一个执行单元后定位数值误差会更麻烦。尤其在混合精度场景里一个小小的融合顺序变化可能影响最终结果。所以工程上不是“能融合就融合”而是“收益大于代价才融合”。六、编译器在这里做了什么现代 AI 推理引擎和编译器通常会做几件事分析计算图找到连续可合并的算子模式判断 shape、数据类型和设备约束生成融合后的执行计划在运行时选择合适 kernel。从开发者角度看你可能只是写了普通模型代码。但在底层编译器会尝试把碎片化计算改写成更适合硬件执行的形式。这也是为什么同一个模型在不同推理引擎上的速度可能差很多。差别不一定只在硬件而在图优化、kernel 选择和内存调度。七、如何判断是不是内存带宽瓶颈如果你遇到推理慢可以观察几个现象GPU 利用率不高但显存带宽占用很高kernel 数量很多每个 kernel 执行时间很短profiler 里大量时间花在数据移动和小算子上batch 增大后吞吐提升不明显删除一些 element-wise 操作后速度明显变化。这时可以重点检查是否有大量中间张量 是否存在连续小算子 是否启用了图优化 是否使用了合适的数据格式 是否存在动态 shape 阻碍优化优化方向不一定是买更强的卡而可能是减少访存、打开编译优化、调整模型结构或切换推理引擎。八、开发者能做什么如果你不是编译器开发者也可以做一些事尽量使用推理框架推荐的模型导出方式避免在推理路径里插入大量零散 Python 逻辑固定输入 shape减少动态分支打开图优化或编译模式用 profiler 看 kernel 数量和显存读写对性能敏感模块做单独 benchmark谨慎使用会打断计算图的自定义操作。很多性能问题不是模型结构本身造成的而是模型落到工程代码后计算图被拆碎了。总结算子融合解决的是一个很现实的问题AI 推理不只需要“会算”还要“少搬”。当多个小算子连续执行时中间张量的读写会浪费大量内存带宽。通过融合推理引擎可以减少数据搬运、降低 kernel 启动开销并提升硬件利用率。但融合不是越多越好。真正成熟的优化需要在计算复杂度、寄存器压力、访存模式、动态 shape 和调试成本之间做平衡。一句话记住推理慢不一定是算力不够很多时候是数据在路上堵车了。
