1. 先搞明白 ops-nn 要解决的问题统一调度接口背后的硬件现实1.1 同样是做算子为什么神经网络算子要单独建库如果你把一个深度学习网络翻译成计算图里面的节点类型其实非常有限卷积、矩阵乘、池化、归一化、激活、Softmax、残差加以及各种逐元素操作。这些节点从数学描述上看都很简单难的是让它们在 AI 芯片上跑得足够快。一个经常被低估的事实是在算子粒度上AI 芯片的执行效率从来不是按浮点运算次数定的。公式写对了、输出结果对了性能可能只有优化版本的十分之一甚至更低。差异主要来自硬件本身。AI 芯片的存储层次、计算单元分工、数据排布要求都与传统通用处理器不一样通用编译器很难为每个算子都生成贴近硬件的指令序列。CANN 把神经网络算子独立整理成 ops-nn 这样的专用算子库本质就是把这层硬件适配集中起来做深做透替上层框架和开发者挡住大部分性能问题。ops-nn 看起来像是一个现成算子函数的集合但它实际承担的是“语义到硬件”的翻译工作。拿到一个算子调用它需要根据张量形状、数据类型、目标 AI 核心的计算单元特点选择合适的实现路径在网络编译阶段它还会参与算子组合与图级优化。一个算子能不能用、快不快往往在选库里的哪个 kernel 时就已经决定了。1.2 算子库的边界它替开发者挡住了什么先厘清 ops-nn 在整个体系里的位置。上层框架把网络解析成计算图做完算子级调度后最终落到一个具体算子的 kernel 调用。kernel 内部怎么读数据、怎么切分、怎么计算、怎么写回就是算子库要管的范围。我接触过的很多调优案例里真正拉开性能差距的往往不是网络结构的差异而是同一批算子在目标硬件上的落地质量。比如同样的卷积在某个版本硬件上适合把通道切成小块送进矩阵单元在另一版硬件上则适合保留大通道减少切分次数。算子库的一大职责就是把这些硬件差异封装起来对外只暴露稳定的接口。这也解释了为什么单独拆出一个 NN 算子库而不是把所有算子都交给通用编译层处理。神经网络算子的张量维度规整、中间数据量极大、算子之间高度连续三个特征叠加在一起使得它值得专门做访存和流水优化。图像处理类算子、数值计算类算子虽然也有自己的规律但访存模式和并行特征完全不同混在一套机制里只会互相妥协。1.3 从算子描述到可执行指令的落地路径一次算子调用并不仅仅是函数调用它要经历几个阶段参数解析与校验确认形状、数据类型、布局、format 等信息。算子选择从算子库中选出匹配的 kernel必要时做参数推导。Tiling 切分把大张量切成符合片上缓冲容量的分块同时决定多核分配方式。编译与执行生成或调度指令序列启动 AI Core 流水。输出处理将结果从片上缓冲写回全局内存处理边界和掩码。这五个环节里最核心的是 Tiling。它决定每个 AI Core 拿到多大的分块也直接决定搬运次数、缓存命中率和计算重叠程度。固定形状的网络可以把 Tiling 方案提前算好动态 shape 的网络则要求在运行期快速计算。ops-nn 里大量性能差异最终都可以追溯到不同 Tiling 策略的取舍上分块大了搬运少但片上空间紧张分块小了流水灵活但启动开销跟着涨。真正成熟的算子实现往往不是“找一种最优切法”而是针对常见 shape 区间准备了几种可切换的切法。2. 硬件级优化的前提AI Core 的存储、计算与数据排布2.1 三级存储结构如何决定每一步都花钱要做硬件级优化首先得知道硬件是怎么组织的。AI Core 的典型存储层级是全局内存GM、二级缓存或共享缓存L2以及 AI Core 内部的统一缓冲UB。数据只有搬到 UB 才能被计算单元直接读取而 GM 到 UB 的搬运成本远高于 UB 内部的读写。理解这套层级我习惯用仓库和工作台来类比。GM 就是大仓库容量大但离工作台远每搬一次货都要花时间和能耗UB 是操作台离得近、速度快但台面很小一次只能摆下几个分块。中间的 L2 相当于中转货架能在一定程度上减少重复去仓库的麻烦但不可能做到零成本。这个存储结构直接决定了写算子时的第一原则减少 GM 和 UB 之间的往返次数。能一次读完的分块就不要反复回仓库取能在 UB 内完成的操作就不要写回仓库再读回来。后面要讲的算子融合、内存复用、流水线调度最终都是在为“少搬一趟”这个目标服务。2.2 三种计算单元的分工决定了算子的写法AI Core 内部通常有三种计算角色矩阵计算单元Cube、向量计算单元Vector、标量控制单元Scalar。它们的分工和性能关键点差异很大。计算单元擅长任务性能关键矩阵单元Cube矩阵乘法、卷积中的乘累加数据是否按矩阵分块对齐是否长时间无空转向量单元Vector逐元素、规约、激活数据连续性、向量化程度、对齐标量单元Scalar地址计算、循环控制控制流是否成为瓶颈是否掩盖了计算调算子时最先要做的一件事就是判断它属于 Cube 型还是 Vector 型因为两类算子的优化目标完全不同。卷积、矩阵乘这类算子核心是让 Cube 尽量满负荷归一化、激活、Softmax 这类算子则要围绕 Vector 指令规划数据流。如果一个算子既要 Cube 又要 Vector比如卷积后面紧跟激活那么两个计算单元之间如何交接数据、如何避免互相等待就变成了整个调优中最关键的问题。2.3 数据布局是隐性开关默认情况下网络张量以 NCHW、NHWC 这类维度顺序表达。但 AI 芯片为了让矩阵单元连续取数、让向量指令对齐读写经常要求数据以特殊格式存储。一个典型的例子是 NC1HWC0 这种把通道维度拆成主通道和微通道的五维布局矩阵乘还常常用分形格式Fractal把大矩阵切成一堆适合矩阵单元直接消费的小块。数据布局选对了一次搬运的数据全部用上矩阵单元也能连续取数选错了搬运效率减半甚至需要先做一次格式转换。麻烦的是格式转换本身也是一次完整的访存操作代价并不低。所以 ops-nn 在考虑算子融合时会把相邻算子的数据格式放在一起规划让中间数据始终保持同一种特殊布局避免反复转换。实际网络优化中这种“格式意识”带来的收益有时候比减少浮点计算量还明显。3. 硬件级优化策略全景拆解3.1 算子融合为访存“压缩行程”假设一个网络片段连续出现卷积、归一化、激活三步。如果不做融合每一步都会把结果写回 GM下一步再从 GM 读出来中间结果被反复搬运。对比一下无融合和融合后的数据流环节无融合的数据流融合后的数据流卷积输出写回 GM1 次写留在 UB不写 GM归一化读取/写入读 GM 写 GM1 读 1 写在 UB 内完成激活读取/写入读 GM 写 GM1 读 1 写在 UB 内完成最终输出写 GM1 次写只写 1 次最终结果融合之后中间结果根本不出 UBGM 访问次数从六七次缩减到两次左右。对带宽敏感的网络来说这笔收益非常可观。归一化算子的参数还能进一步折叠进卷积权重推理阶段完全不出现单独的归一化算子访存省得更加彻底。但融合不是越多越好。融合后单个 AI Core 的处理粒度变大可能导致多核并行度下降计算单元要连续处理混合任务流水线也可能更难排。我见过不少“融合后变慢”的案例根源基本都是这三类并行度下降、引入额外的格式转换、流水等待反而更长。所以在决定融合哪些算子之前一定要先确认瓶颈是访存还是计算而不是把所有能融的都融一遍。3.2 内存复用与双缓冲把有限的片上空间用出花UB 容量有限大张量必须分块处理。每个分块在 UB 里都有输入区、中间计算区和输出区这些区域并不是所有时刻都同时活跃。通过生命周期分析可以让多个临时数据分时复用同一块空间这就是内存复用。它不改变计算量却能明显降低中间缓存需求让更大的分块塞进有限空间。比复用更进一步的常见优化是双缓冲。把同一个阶段的数据缓冲分成两块搬运数据时另一块正在被计算单元使用这样搬运与计算就能重叠。乒乓操作的本质就是给流水线持续供应原料。同步要靠硬件的状态位或依赖链来保证不能靠人工猜时机否则很容易读到没写好的数据出现脏读。选择单缓冲、双缓冲还是多缓冲本质是空间换时间的权衡。单缓冲实现简单但等待时间长双缓冲能让计算和搬运重叠是目前算子实现的主流选择多缓冲进一步隐藏不规则访存但对 Tiling 精细度要求更高一般只在访存抖动明显的场景里使用。很多算子实现之间的性能差距就来自缓冲级数和切换时机的把握。3.3 向量化与数据对齐避免一次搬运只搬一半向量指令一次处理的字节数是固定的往往能一次读取并操作几十甚至上百个连续元素。如果代码里每个元素单独处理或者数据地址没有对齐到向量边界向量单元就只能低效执行甚至退化成标量循环。向量化的要点不只是“用更宽的数据类型”还包括循环展开、减少分支以及让同一批计算访问连续内存。对齐是另一个容易踩的坑起始地址没有按硬件要求对齐时一次高效的宽访问会被拆成多次低效访问尾部不足一个单位时要用掩码处理而不是让整个循环退化。我一贯的做法是把循环拆成“对齐主体 尾部处理”两段。// 主体连续且对齐走向量指令 for (int i 0; i aligned_len; i VEC_WIDTH) { vec_op(input i, output i); } // 尾部剩余少量元素用掩码或标量处理 for (int i aligned_len; i total_len; i) { scalar_op(input[i], output[i]); }这种写法能稳定拿到大部分向量化收益。如果主体部分还能配合多缓冲流水整体性能通常不会差。很多“明明计算量不大却跑不快”的算子问题就出在搬运不连续、尾部处理拖垮了整个循环。3.4 流水线调度让搬运、计算、写回各干各的一个算子一次分块的执行可以抽象成三个阶段Load从 GM 或 L2 搬到 UB、Compute计算单元处理、Store结果写回 GM。如果三个阶段串行AI Core 会在搬运期间大量空转。流水线调度想解决的问题就是让 Load 下一块数据时Compute 正在算当前块同时上一块的结果在 Store。只要三个阶段里最慢的一个不拖后腿整体吞吐就能逼近它的极限速度。这里有个重要的预估动作大致算出计算时间与搬运时间的比例。计算时间远大于搬运时间说明优化重点在计算单元利用率比如让 Cube 更满、减少指令依赖搬运时间远大于计算时间就要压缩数据量、提升缓存命中率、减少重复搬运。流水重叠的实现依赖指令级依赖链管理并不是靠并行线程自然发生的。算子代码里通常会显式表达“我在等上一块写完才能复用这个缓冲”的依赖关系。调度时还有一个常见误区为了让计算更早开始把 Load 和 Compute 的依赖关系设置得太松结果拿到错误数据功能测试直接失败。流水调度的每一步改动都应该同时做数值对比而不能只看 profiling 指标。4. 典型算子硬件级优化的实战推演4.1 卷积的“一条龙”处理让输出不落 GM卷积在硬件上的身份是 Cube 算子。单纯把卷积做快核心是合理切分通道和特征图让矩阵单元保持高利用率。但网络真正跑得快还要看卷积后面的附加操作怎么处理。以 Conv Bias ReLU 为例最差的实现是三次读写 GM较好的实现是卷积输出留在 UB 内紧跟着完成 Bias 加法和 ReLU最后只写一次结果。这个融合听起来简单实际会遇到几个细节问题。第一是数据类型混合卷积输出可能是高精度中间值Bias 和 ReLU 要按相应精度处理第二是边界 padding卷积的边缘填充会让特征图的排布不规整向量单元处理时要注意掩码第三是布局衔接Cube 输出的数据布局未必是 Vector 期望的连续布局有些转换可以在片上直接完成有些转换代价较大需要重新评估融合是否划算。另一种值得单独分析的是 1x1 卷积。它本质上就是矩阵乘切分方式和大卷积不一样。通道数大时走 Cube 的收益非常明显通道数小时切换到 Vector 做通道线性组合反而可能更快。好的算子库会在内部对这类“伪卷积”做识别和分流而不是一律当成普通卷积处理。4.2 BatchNorm 推理折叠把乘法变加法、融合进卷积推理阶段的 BatchNorm 本质上是一个线性变换先减均值再除以标准差然后乘缩放系数、加平移量。这些参数在训练完成后都是固定的所以整体可以变成一个 scale 加一个 shiftfold_scale scale / sqrt(var eps)fold_shift shift - mean * fold_scale这个线性变换还能进一步折叠进前一层的卷积或全连接权重权重乘以 fold_scale偏置变为 (原偏置 - mean) * fold_scale shift。折叠之后网络里少了一个完整算子中间结果的访存也彻底消失。实现时要注意两点一是浮点精度的累积误差scale 与权重相乘后数值范围可能变化极端情况下需要重新评估二是量化场景折叠后的权重范围变化会影响后续量化参数必须重新校准不能直接沿用原始量化表。很多推理引擎的性能差异一部分就来自折叠时机的选择和数值鲁棒性的处理。4.3 Softmax 的在线标定把三段式压在一个 pass 里Softmax 的标准实现为了保证数值稳定要先减最大值再算指数和总和最后做除法。这个流程通常被拆成两个 pass第一个 pass 求最大值与总和第二个 pass 计算输出。这意味着输入要被读两遍中间结果也可能落 GM。在线 Softmax 的思路是把整个过程压缩到一个 pass。顺序扫描每个分块时同时维护当前最大值和带标定的指数和如果后续遇到更大的最大值就把已经积累的指数和乘以一个重标定因子再继续累加。最终只需要一次完整读入输出流式写回中间结果完全不必落 GM。这类“单 pass 化”优化非常契合访存受限的算子。实现时要关注三个点重标定因子的数值精度分块大小与误差的关系以及向量指令是否支持在累加过程中动态调整。只要这三个点处理到位Softmax 的访存量能直接下降近一半在网络里高频出现时累计收益很可观。4.4 逐元素算子的大张量分片别把连续访问切成碎片ReLU、Add、残差加这类逐元素算子没有复杂的依赖关系优化核心几乎全在数据搬运上。最简单有效的做法是每个 AI Core 处理连续的一段数据按 L2 容量切块让数据尽量命中缓存。分片有两个常见错误。一是单核分块过小多核启动和同步的开销反而盖过计算收益二是分块跨度过大把本来连续的搬运切成碎片。正确做法是让每个核处理“连在一起的区间”而不是“等间隔采样”这样才能发挥向量指令连续访存的优势。如果逐元素算子的结果要被后面的规约算子或下一个算子使用还要考虑结果的输出布局尽量让数据留在适合下游直接消费的格式避免一次无谓的格式转换。单独看逐元素算子的单次耗时都不高但这类算子在网络里出现频率最高。积少成多的访问量比一个大算子带来的影响还大。所以成熟的算子库会专门对这类算子做“轻量化”设计启动开销尽量低分片尽量少同步能融合就融合到邻近算子中。5. 性能验证与调优心得数据说了算但别被数据骗5.1 打开 profiling 先看哪几个指标做任何优化之前先跑一轮 baseline记录这些指标算子耗时、AI Core 利用率、向量单元利用率、矩阵单元利用率、读写带宽利用率以及指令流水是否频繁中断。只看耗时容易被单次测量误差带偏只看利用率容易忽略数据量差异。一个非常典型的误读是AI Core 利用率高就认为计算已经饱和。实际上忙等待也会拉高利用率——向量单元在等数据搬运时利用率统计上依然可能显示很高但吞吐并没有变快。因此要把“计算时间”和“搬运时间”尽量分开统计再看它们各自占总耗时的比例。5.2 瓶颈定位的先后顺序拿到 profiling 数据后我一般按这个顺序判断先看算子在整图中的耗时占比。占比不足 5% 的算子不值得投入大量精力去优化优先处理大头。再看计算时间与搬运时间的比例区分计算密集型和访存密集型。计算密集型检查矩阵/向量单元利用率查看指令流水是否被打断。访存密集型对比实际搬运量与理论带宽检查是否存在重复搬运、格式转换、缓存未命中。这个顺序能避开最常见的弯路在访存瓶颈的算子上反复调整计算指令或者在计算瓶颈的算子上反复改缓冲大小结果两边的收益都很有限。我自己就走过几次这样的弯路最后发现一开始方向就错了真正花时间的不是调参而是定位。5.3 几种“优化反而变慢”的典型情况只要调优周期足够长一定会碰到一些反直觉的结果。融合算子后整体变慢。主要原因往往是并行度下降或者融合引入的格式转换开销比省下的访存还大。双缓冲没有提速。这说明搬运和计算的依赖链没有真正打破调度仍然在互相等待所谓“重叠”只是假象。向量化后结果不收敛。可能只是改了数据类型没有同步调整归一化因子或者累加顺序。这类问题在功能验证阶段就应该用数值对比抓住。这些反直觉现象背后的规律很简单任何一次改动都会同时影响访存、并行度和流水三个维度中的一个或多个。收益和代价必须放在一起看。我养成了一个习惯——任何优化只改一个变量跑完 profiling 后留下记录。宁可慢一点也不做无法归因的“混合优化”否则出了问题根本不知道是哪一步引起的。5.4 我常用的几条调优规则最后分享几条整理过多次的规则不算高深但非常有用。先正确后性能。功能测试和数值对比不过关就不进入优化阶段。用真实 shape 做基准。小 shape 下得出的优化结论在大 shape 下经常失效多核分块和缓冲大小的最优解会随 shape 变化。对比时固定 batch 和精度。这两个因素一变结论就得重新验证。保留每次改动的 profiling 记录。优化过程最重要的是可复现而不是一次性的性能数字。做算子调优本质是在一堆取舍里找到一个平衡点遍历更多还是复用更多看得更宽还是切得更细尽早开始计算还是等待完整数据。ops-nn 这类算子库把很多经验固化成了默认策略但真正的高性能实现永远离不开对具体硬件行为的理解和对 profiling 数据的耐心解读。带着这条主线去阅读算子实现你会发现那些看起来复杂的优化策略其实都是在回答同一个问题数据是怎么搬的计算有没有在等。 
长河君 · 2026/10/20 15:47:00 · 阅读 1.2k AI芯片算子库硬件级优化：数据搬移、算子融合与流水调度的实战指南
1. 先搞明白 ops-nn 要解决的问题统一调度接口背后的硬件现实1.1 同样是做算子为什么神经网络算子要单独建库如果你把一个深度学习网络翻译成计算图里面的节点类型其实非常有限卷积、矩阵乘、池化、归一化、激活、Softmax、残差加以及各种逐元素操作。这些节点从数学描述上看都很简单难的是让它们在 AI 芯片上跑得足够快。一个经常被低估的事实是在算子粒度上AI 芯片的执行效率从来不是按浮点运算次数定的。公式写对了、输出结果对了性能可能只有优化版本的十分之一甚至更低。差异主要来自硬件本身。AI 芯片的存储层次、计算单元分工、数据排布要求都与传统通用处理器不一样通用编译器很难为每个算子都生成贴近硬件的指令序列。CANN 把神经网络算子独立整理成 ops-nn 这样的专用算子库本质就是把这层硬件适配集中起来做深做透替上层框架和开发者挡住大部分性能问题。ops-nn 看起来像是一个现成算子函数的集合但它实际承担的是“语义到硬件”的翻译工作。拿到一个算子调用它需要根据张量形状、数据类型、目标 AI 核心的计算单元特点选择合适的实现路径在网络编译阶段它还会参与算子组合与图级优化。一个算子能不能用、快不快往往在选库里的哪个 kernel 时就已经决定了。1.2 算子库的边界它替开发者挡住了什么先厘清 ops-nn 在整个体系里的位置。上层框架把网络解析成计算图做完算子级调度后最终落到一个具体算子的 kernel 调用。kernel 内部怎么读数据、怎么切分、怎么计算、怎么写回就是算子库要管的范围。我接触过的很多调优案例里真正拉开性能差距的往往不是网络结构的差异而是同一批算子在目标硬件上的落地质量。比如同样的卷积在某个版本硬件上适合把通道切成小块送进矩阵单元在另一版硬件上则适合保留大通道减少切分次数。算子库的一大职责就是把这些硬件差异封装起来对外只暴露稳定的接口。这也解释了为什么单独拆出一个 NN 算子库而不是把所有算子都交给通用编译层处理。神经网络算子的张量维度规整、中间数据量极大、算子之间高度连续三个特征叠加在一起使得它值得专门做访存和流水优化。图像处理类算子、数值计算类算子虽然也有自己的规律但访存模式和并行特征完全不同混在一套机制里只会互相妥协。1.3 从算子描述到可执行指令的落地路径一次算子调用并不仅仅是函数调用它要经历几个阶段参数解析与校验确认形状、数据类型、布局、format 等信息。算子选择从算子库中选出匹配的 kernel必要时做参数推导。Tiling 切分把大张量切成符合片上缓冲容量的分块同时决定多核分配方式。编译与执行生成或调度指令序列启动 AI Core 流水。输出处理将结果从片上缓冲写回全局内存处理边界和掩码。这五个环节里最核心的是 Tiling。它决定每个 AI Core 拿到多大的分块也直接决定搬运次数、缓存命中率和计算重叠程度。固定形状的网络可以把 Tiling 方案提前算好动态 shape 的网络则要求在运行期快速计算。ops-nn 里大量性能差异最终都可以追溯到不同 Tiling 策略的取舍上分块大了搬运少但片上空间紧张分块小了流水灵活但启动开销跟着涨。真正成熟的算子实现往往不是“找一种最优切法”而是针对常见 shape 区间准备了几种可切换的切法。2. 硬件级优化的前提AI Core 的存储、计算与数据排布2.1 三级存储结构如何决定每一步都花钱要做硬件级优化首先得知道硬件是怎么组织的。AI Core 的典型存储层级是全局内存GM、二级缓存或共享缓存L2以及 AI Core 内部的统一缓冲UB。数据只有搬到 UB 才能被计算单元直接读取而 GM 到 UB 的搬运成本远高于 UB 内部的读写。理解这套层级我习惯用仓库和工作台来类比。GM 就是大仓库容量大但离工作台远每搬一次货都要花时间和能耗UB 是操作台离得近、速度快但台面很小一次只能摆下几个分块。中间的 L2 相当于中转货架能在一定程度上减少重复去仓库的麻烦但不可能做到零成本。这个存储结构直接决定了写算子时的第一原则减少 GM 和 UB 之间的往返次数。能一次读完的分块就不要反复回仓库取能在 UB 内完成的操作就不要写回仓库再读回来。后面要讲的算子融合、内存复用、流水线调度最终都是在为“少搬一趟”这个目标服务。2.2 三种计算单元的分工决定了算子的写法AI Core 内部通常有三种计算角色矩阵计算单元Cube、向量计算单元Vector、标量控制单元Scalar。它们的分工和性能关键点差异很大。计算单元擅长任务性能关键矩阵单元Cube矩阵乘法、卷积中的乘累加数据是否按矩阵分块对齐是否长时间无空转向量单元Vector逐元素、规约、激活数据连续性、向量化程度、对齐标量单元Scalar地址计算、循环控制控制流是否成为瓶颈是否掩盖了计算调算子时最先要做的一件事就是判断它属于 Cube 型还是 Vector 型因为两类算子的优化目标完全不同。卷积、矩阵乘这类算子核心是让 Cube 尽量满负荷归一化、激活、Softmax 这类算子则要围绕 Vector 指令规划数据流。如果一个算子既要 Cube 又要 Vector比如卷积后面紧跟激活那么两个计算单元之间如何交接数据、如何避免互相等待就变成了整个调优中最关键的问题。2.3 数据布局是隐性开关默认情况下网络张量以 NCHW、NHWC 这类维度顺序表达。但 AI 芯片为了让矩阵单元连续取数、让向量指令对齐读写经常要求数据以特殊格式存储。一个典型的例子是 NC1HWC0 这种把通道维度拆成主通道和微通道的五维布局矩阵乘还常常用分形格式Fractal把大矩阵切成一堆适合矩阵单元直接消费的小块。数据布局选对了一次搬运的数据全部用上矩阵单元也能连续取数选错了搬运效率减半甚至需要先做一次格式转换。麻烦的是格式转换本身也是一次完整的访存操作代价并不低。所以 ops-nn 在考虑算子融合时会把相邻算子的数据格式放在一起规划让中间数据始终保持同一种特殊布局避免反复转换。实际网络优化中这种“格式意识”带来的收益有时候比减少浮点计算量还明显。3. 硬件级优化策略全景拆解3.1 算子融合为访存“压缩行程”假设一个网络片段连续出现卷积、归一化、激活三步。如果不做融合每一步都会把结果写回 GM下一步再从 GM 读出来中间结果被反复搬运。对比一下无融合和融合后的数据流环节无融合的数据流融合后的数据流卷积输出写回 GM1 次写留在 UB不写 GM归一化读取/写入读 GM 写 GM1 读 1 写在 UB 内完成激活读取/写入读 GM 写 GM1 读 1 写在 UB 内完成最终输出写 GM1 次写只写 1 次最终结果融合之后中间结果根本不出 UBGM 访问次数从六七次缩减到两次左右。对带宽敏感的网络来说这笔收益非常可观。归一化算子的参数还能进一步折叠进卷积权重推理阶段完全不出现单独的归一化算子访存省得更加彻底。但融合不是越多越好。融合后单个 AI Core 的处理粒度变大可能导致多核并行度下降计算单元要连续处理混合任务流水线也可能更难排。我见过不少“融合后变慢”的案例根源基本都是这三类并行度下降、引入额外的格式转换、流水等待反而更长。所以在决定融合哪些算子之前一定要先确认瓶颈是访存还是计算而不是把所有能融的都融一遍。3.2 内存复用与双缓冲把有限的片上空间用出花UB 容量有限大张量必须分块处理。每个分块在 UB 里都有输入区、中间计算区和输出区这些区域并不是所有时刻都同时活跃。通过生命周期分析可以让多个临时数据分时复用同一块空间这就是内存复用。它不改变计算量却能明显降低中间缓存需求让更大的分块塞进有限空间。比复用更进一步的常见优化是双缓冲。把同一个阶段的数据缓冲分成两块搬运数据时另一块正在被计算单元使用这样搬运与计算就能重叠。乒乓操作的本质就是给流水线持续供应原料。同步要靠硬件的状态位或依赖链来保证不能靠人工猜时机否则很容易读到没写好的数据出现脏读。选择单缓冲、双缓冲还是多缓冲本质是空间换时间的权衡。单缓冲实现简单但等待时间长双缓冲能让计算和搬运重叠是目前算子实现的主流选择多缓冲进一步隐藏不规则访存但对 Tiling 精细度要求更高一般只在访存抖动明显的场景里使用。很多算子实现之间的性能差距就来自缓冲级数和切换时机的把握。3.3 向量化与数据对齐避免一次搬运只搬一半向量指令一次处理的字节数是固定的往往能一次读取并操作几十甚至上百个连续元素。如果代码里每个元素单独处理或者数据地址没有对齐到向量边界向量单元就只能低效执行甚至退化成标量循环。向量化的要点不只是“用更宽的数据类型”还包括循环展开、减少分支以及让同一批计算访问连续内存。对齐是另一个容易踩的坑起始地址没有按硬件要求对齐时一次高效的宽访问会被拆成多次低效访问尾部不足一个单位时要用掩码处理而不是让整个循环退化。我一贯的做法是把循环拆成“对齐主体 尾部处理”两段。// 主体连续且对齐走向量指令 for (int i 0; i aligned_len; i VEC_WIDTH) { vec_op(input i, output i); } // 尾部剩余少量元素用掩码或标量处理 for (int i aligned_len; i total_len; i) { scalar_op(input[i], output[i]); }这种写法能稳定拿到大部分向量化收益。如果主体部分还能配合多缓冲流水整体性能通常不会差。很多“明明计算量不大却跑不快”的算子问题就出在搬运不连续、尾部处理拖垮了整个循环。3.4 流水线调度让搬运、计算、写回各干各的一个算子一次分块的执行可以抽象成三个阶段Load从 GM 或 L2 搬到 UB、Compute计算单元处理、Store结果写回 GM。如果三个阶段串行AI Core 会在搬运期间大量空转。流水线调度想解决的问题就是让 Load 下一块数据时Compute 正在算当前块同时上一块的结果在 Store。只要三个阶段里最慢的一个不拖后腿整体吞吐就能逼近它的极限速度。这里有个重要的预估动作大致算出计算时间与搬运时间的比例。计算时间远大于搬运时间说明优化重点在计算单元利用率比如让 Cube 更满、减少指令依赖搬运时间远大于计算时间就要压缩数据量、提升缓存命中率、减少重复搬运。流水重叠的实现依赖指令级依赖链管理并不是靠并行线程自然发生的。算子代码里通常会显式表达“我在等上一块写完才能复用这个缓冲”的依赖关系。调度时还有一个常见误区为了让计算更早开始把 Load 和 Compute 的依赖关系设置得太松结果拿到错误数据功能测试直接失败。流水调度的每一步改动都应该同时做数值对比而不能只看 profiling 指标。4. 典型算子硬件级优化的实战推演4.1 卷积的“一条龙”处理让输出不落 GM卷积在硬件上的身份是 Cube 算子。单纯把卷积做快核心是合理切分通道和特征图让矩阵单元保持高利用率。但网络真正跑得快还要看卷积后面的附加操作怎么处理。以 Conv Bias ReLU 为例最差的实现是三次读写 GM较好的实现是卷积输出留在 UB 内紧跟着完成 Bias 加法和 ReLU最后只写一次结果。这个融合听起来简单实际会遇到几个细节问题。第一是数据类型混合卷积输出可能是高精度中间值Bias 和 ReLU 要按相应精度处理第二是边界 padding卷积的边缘填充会让特征图的排布不规整向量单元处理时要注意掩码第三是布局衔接Cube 输出的数据布局未必是 Vector 期望的连续布局有些转换可以在片上直接完成有些转换代价较大需要重新评估融合是否划算。另一种值得单独分析的是 1x1 卷积。它本质上就是矩阵乘切分方式和大卷积不一样。通道数大时走 Cube 的收益非常明显通道数小时切换到 Vector 做通道线性组合反而可能更快。好的算子库会在内部对这类“伪卷积”做识别和分流而不是一律当成普通卷积处理。4.2 BatchNorm 推理折叠把乘法变加法、融合进卷积推理阶段的 BatchNorm 本质上是一个线性变换先减均值再除以标准差然后乘缩放系数、加平移量。这些参数在训练完成后都是固定的所以整体可以变成一个 scale 加一个 shiftfold_scale scale / sqrt(var eps)fold_shift shift - mean * fold_scale这个线性变换还能进一步折叠进前一层的卷积或全连接权重权重乘以 fold_scale偏置变为 (原偏置 - mean) * fold_scale shift。折叠之后网络里少了一个完整算子中间结果的访存也彻底消失。实现时要注意两点一是浮点精度的累积误差scale 与权重相乘后数值范围可能变化极端情况下需要重新评估二是量化场景折叠后的权重范围变化会影响后续量化参数必须重新校准不能直接沿用原始量化表。很多推理引擎的性能差异一部分就来自折叠时机的选择和数值鲁棒性的处理。4.3 Softmax 的在线标定把三段式压在一个 pass 里Softmax 的标准实现为了保证数值稳定要先减最大值再算指数和总和最后做除法。这个流程通常被拆成两个 pass第一个 pass 求最大值与总和第二个 pass 计算输出。这意味着输入要被读两遍中间结果也可能落 GM。在线 Softmax 的思路是把整个过程压缩到一个 pass。顺序扫描每个分块时同时维护当前最大值和带标定的指数和如果后续遇到更大的最大值就把已经积累的指数和乘以一个重标定因子再继续累加。最终只需要一次完整读入输出流式写回中间结果完全不必落 GM。这类“单 pass 化”优化非常契合访存受限的算子。实现时要关注三个点重标定因子的数值精度分块大小与误差的关系以及向量指令是否支持在累加过程中动态调整。只要这三个点处理到位Softmax 的访存量能直接下降近一半在网络里高频出现时累计收益很可观。4.4 逐元素算子的大张量分片别把连续访问切成碎片ReLU、Add、残差加这类逐元素算子没有复杂的依赖关系优化核心几乎全在数据搬运上。最简单有效的做法是每个 AI Core 处理连续的一段数据按 L2 容量切块让数据尽量命中缓存。分片有两个常见错误。一是单核分块过小多核启动和同步的开销反而盖过计算收益二是分块跨度过大把本来连续的搬运切成碎片。正确做法是让每个核处理“连在一起的区间”而不是“等间隔采样”这样才能发挥向量指令连续访存的优势。如果逐元素算子的结果要被后面的规约算子或下一个算子使用还要考虑结果的输出布局尽量让数据留在适合下游直接消费的格式避免一次无谓的格式转换。单独看逐元素算子的单次耗时都不高但这类算子在网络里出现频率最高。积少成多的访问量比一个大算子带来的影响还大。所以成熟的算子库会专门对这类算子做“轻量化”设计启动开销尽量低分片尽量少同步能融合就融合到邻近算子中。5. 性能验证与调优心得数据说了算但别被数据骗5.1 打开 profiling 先看哪几个指标做任何优化之前先跑一轮 baseline记录这些指标算子耗时、AI Core 利用率、向量单元利用率、矩阵单元利用率、读写带宽利用率以及指令流水是否频繁中断。只看耗时容易被单次测量误差带偏只看利用率容易忽略数据量差异。一个非常典型的误读是AI Core 利用率高就认为计算已经饱和。实际上忙等待也会拉高利用率——向量单元在等数据搬运时利用率统计上依然可能显示很高但吞吐并没有变快。因此要把“计算时间”和“搬运时间”尽量分开统计再看它们各自占总耗时的比例。5.2 瓶颈定位的先后顺序拿到 profiling 数据后我一般按这个顺序判断先看算子在整图中的耗时占比。占比不足 5% 的算子不值得投入大量精力去优化优先处理大头。再看计算时间与搬运时间的比例区分计算密集型和访存密集型。计算密集型检查矩阵/向量单元利用率查看指令流水是否被打断。访存密集型对比实际搬运量与理论带宽检查是否存在重复搬运、格式转换、缓存未命中。这个顺序能避开最常见的弯路在访存瓶颈的算子上反复调整计算指令或者在计算瓶颈的算子上反复改缓冲大小结果两边的收益都很有限。我自己就走过几次这样的弯路最后发现一开始方向就错了真正花时间的不是调参而是定位。5.3 几种“优化反而变慢”的典型情况只要调优周期足够长一定会碰到一些反直觉的结果。融合算子后整体变慢。主要原因往往是并行度下降或者融合引入的格式转换开销比省下的访存还大。双缓冲没有提速。这说明搬运和计算的依赖链没有真正打破调度仍然在互相等待所谓“重叠”只是假象。向量化后结果不收敛。可能只是改了数据类型没有同步调整归一化因子或者累加顺序。这类问题在功能验证阶段就应该用数值对比抓住。这些反直觉现象背后的规律很简单任何一次改动都会同时影响访存、并行度和流水三个维度中的一个或多个。收益和代价必须放在一起看。我养成了一个习惯——任何优化只改一个变量跑完 profiling 后留下记录。宁可慢一点也不做无法归因的“混合优化”否则出了问题根本不知道是哪一步引起的。5.4 我常用的几条调优规则最后分享几条整理过多次的规则不算高深但非常有用。先正确后性能。功能测试和数值对比不过关就不进入优化阶段。用真实 shape 做基准。小 shape 下得出的优化结论在大 shape 下经常失效多核分块和缓冲大小的最优解会随 shape 变化。对比时固定 batch 和精度。这两个因素一变结论就得重新验证。保留每次改动的 profiling 记录。优化过程最重要的是可复现而不是一次性的性能数字。做算子调优本质是在一堆取舍里找到一个平衡点遍历更多还是复用更多看得更宽还是切得更细尽早开始计算还是等待完整数据。ops-nn 这类算子库把很多经验固化成了默认策略但真正的高性能实现永远离不开对具体硬件行为的理解和对 profiling 数据的耐心解读。带着这条主线去阅读算子实现你会发现那些看起来复杂的优化策略其实都是在回答同一个问题数据是怎么搬的计算有没有在等。