AI芯片算子映射与软硬件协同优化：从Roofline到MAC利用率

做AI芯片这些年，我越来越觉得：真正拉开芯片性能差距的，往往不是晶体管数量，也不是架构图上那些漂亮的框，而是软硬件设计交界处那些不起眼的决策。今天这篇是“AI芯片的软硬件设计”系列的第8篇，想聊的正是这块交界地带：算子怎么落到计算单元上、数据怎么搬才不会堵车、指令怎么排才能让每一排乘法器都不闲着。适合正在做算子库、编译器后端、芯片架构验证的同行参考，也适合刚入行想搞明白“为什么芯片手册上写的算力，实测总是打折扣”的新人。

1. 从架构到算子：软硬件协同中那本“资源账本”

1.1 软件工程师为什么必须读懂硬件账本

我在参与某款AI加速器项目时，最常被问到的一句话是：“硬件明明标了8TOPS，我的算子怎么只能跑到2TOPS？”这个问题我后来想明白了——因为很多人把软件和硬件当成两个独立模块，各做各的。实际上，算子库和编译器后端每天在做的事，本质上就是一次资源分配：把一个算子的计算任务，切碎、排序、安放到有限的硬件资源上。

硬件资源无非三样：MAC阵列规模（每周期能发起多少次乘加）、片上SRAM容量（数据能在片内放多少）、片外访存带宽（主存和片上之间每秒能搬多少字节）。软件侧每个看似“干净”的决策——比如循环怎么分块、缓冲开几份、指令怎么展开——都在同时花这三笔钱。

我常打一个比方：MAC阵列是厨子，手艺好、时薪高；片上SRAM是切菜台，面积就那么大；片外带宽是传菜通道，一次能端的东西有限。如果备菜流程设计不合理，厨子就一直干等着菜上桌。算子实现也是一样，所谓优化，不是让某个单元更快，而是让整个“备菜—炒菜—上菜”流程里最贵的那个环节永远不空转。

所以软件工程师看芯片手册，重点不是看那张性能表，而是看三类要素：MAC阵列每周期能收多少数据、SRAM分几块分别多大、DMA和计算能不能并行。这三个数字，决定了一个算子的所有优化空间。

1.2 算力、带宽、存储的三边约束如何决定性能天花板

这三笔资源不是独立的，它们共同画出一条理论性能上限，业内叫Roofline模型。很多团队一上来就埋头优化代码，其实第一步应该先拿计算器算一算：这个算子在当前芯片上，到底是被算力限制，还是被带宽限制。

我以一颗典型加速器为例：FP16峰值算力4 TFLOPS，片外带宽128 GB/s，片上SRAM约4 MB。Roofline的转折点等于峰值算力除以带宽，也就是4e12 / 128e9 ≈ 31 FLOP/Byte。一个算子的算术强度（每搬运1字节数据能摊到多少次浮点运算）大于31，理论上就是算力受限；小于31，就是带宽受限，再怎么让MAC阵列拼命跑也跑不上去。

这个数字意味着什么？拿一个逐元素Add算子来说，读两个向量、写一个向量，每个元素2次运算对应6字节搬移，算术强度只有0.33 FLOP/Byte，远远低于31。理论上限就是128 GB/s × 0.33 ≈ 42 GFLOPS，只用了峰值算力的1%。而后面要讲的GEMM和卷积，算术强度能到几十甚至几百，才有资格去追求高算力利用率。先算清楚这道题，再决定优化往哪个方向使劲，顺序不能反。

2. 算子映射实操：分块、复用、把搬运藏起来

2.1 Tiling怎么做：以矩阵乘法为例的完整计算

矩阵乘法是AI芯片最基本的算子，也是最好的教学案例。假设C[M,N] = A[M,K] × B[K,N]，M、N、K都是1024，数据类型FP16，累加用FP32。朴素三重循环的问题是：每次算一个C[i][j]，都要从主存读A的一行和B的一列，一遍算下来同一份A数据要被读1024次，带宽直接被拖垮。

Tiling的思路很简单：把矩阵切成小块，让每个小分块的数据从主存只搬一次到片上，然后在片上反复复用。我常用的分块参数是BM=128、BN=128、BK=64，为什么这么选，可以算一笔账：

• A块：128×64，FP16，占128×64×2 = 16 KB
• B块：64×128，FP16，占16 KB
• C块累加结果：128×128，FP32，占64 KB

三个块加起来约96 KB，4 MB的SRAM完全放得下。每个块的计算量是2×128×128×64 ≈ 2.1 MFLOP。数据搬移方面，读入A和B合计32 KB，如果C块累加完写回用FP32就是64 KB。总移动约96 KB，算术强度2.1M/96K ≈ 21 FLOP/Byte。如果写回改为FP16，总移动64 KB，强度变成约33 FLOP/Byte，跨过了31的转折点。这个细节特别说明问题：有时候改一下输出累加结果的下沉格式，就能把一个算子从带宽受限拉回算力受限。

// 伪代码：矩阵乘分块主循环 for (int m0 = 0; m0 < M; m0 += BM) { for (int n0 = 0; n0 < N; n0 += BN) { for (int k0 = 0; k0 < K; k0 += BK) { load_to_sram(A_blk, A[m0][k0], BM * BK * sizeof(fp16)); load_to_sram(B_blk, B[k0][n0], BK * BN * sizeof(fp16)); mac_compute(C_blk, A_blk, B_blk); // 在片上完成128x128x64累加 } store_to_dram(C[m0][n0], C_blk, BM * BN * sizeof(fp16)); } }

真写代码时还会把数组指针改成带步长的形式，DMA引擎通常要求地址按64字节对齐，否则一个burst传输会被拆成好几个小传输，带宽利用率直接掉一截。我建议拿到一个新芯片，先把分块大小、地址对齐、DMA描述符开销这些底层参数测清楚，形成一张速查表，再开始写算子。

2.2 双缓冲与软件流水：把搬运时间藏起来

分块解决了复用问题，但还有一个更隐蔽的性能杀手：同步等待。如果按“先搬运块，再计算块，再搬运下一块”的顺序执行，整个流程是串行的，计算单元在每次DMA搬运期间都是空闲的。

双缓冲是解决这个问题的标准做法：准备两份buffer，计算模块算第t块数据的时候，DMA同时在往另一份buffer里搬第t+1块数据。理想情况下，总时间从“搬运时间+计算时间”变成“max(搬运时间, 计算时间)”，流水线一建立，搬运开销就被藏起来了。

// 伪代码：双缓冲主循环 dma_prefetch(buf[1]); // 先预取第1块 for (int t = 1; t < num_blocks; t++) { dma_wait(buf[t % 2]); // 等第t块搬运完成 mac_compute(buf[t % 2]); // 算当前块 dma_prefetch(buf[(t + 1) % 2]); // 预取下一块 } dma_wait(buf[num_blocks % 2]); mac_compute(buf[num_blocks % 2]);

这里有两个坑必须提醒。第一，当分块很小时，两块buffer之间的同步开销可能超过搬运本身节省的时间，这时候试试三缓冲，让DMA和计算之间多一级弹性。第二，DMAbuffer的起始地址最好错开，避免多路DMA同时访问同一个bank导致访存冲突；我实测过，两个buffer地址恰好落在同一bank组时，带宽可能掉15%以上。

3. 指令形态与流水线：编译器压力最大的那一段

3.1 VLIW风格的优势与静态调度的代价

算子跑得快不快，除了数据搬移，还取决于指令怎么发给MAC阵列。AI芯片的指令形态，我接触过的多数走VLIW（超长指令字）风格：一条指令字里同时编码多个操作，比如“这一周期MAC阵列做矩阵乘、DMA同时搬下一块、标量单元更新地址”。好处是硬件不需要做动态调度，控制逻辑简单、功耗低、面积小，这对追求能效比的AI芯片来说非常关键。

更重要的是时序确定性。VLIW是静态调度，每条指令在哪一个周期执行、读写哪个寄存器，在编译期就定死了。反过来说，这也把巨大的压力推给了编译器后端：它必须在编译阶段就把访存延迟、算力吞吐、同步点全部安排好。一旦判断失误，硬件不会帮你纠正，只会默默空转一个周期。

我在实际项目中体会很深的一点是：指令集设计必须和编译器后端同步做，不能等硬件设计冻结了再单独搞一套指令规范。某团队曾经设计了一个看起来很有表现力的指令，支持任意寄存器间同步，结果编译器后端根本没法静态分析依赖关系，最终只能退化成几乎所有指令前都加barrier，白白损失20%的算力。指令编码设计早期多问编译器工程师一句“这个字段你能生成得出来吗”，比后期打补丁省事一百倍。

3.2 循环展开、软件流水与同步机制

在VLIW机器上，循环展开几乎是必须的。原因是每个运算都有固定延迟，比如MAC的写回可能要等5个周期，如果循环体太小，下一个周期没有独立指令可以发射，流水线就停一拍。展开的本质是把多个相邻迭代的独立指令排到同一条指令字里，让MAC阵列每周期都有活干。

展开因子怎么选？至少覆盖访存往返延迟。假设片上到主存的延迟约80周期，每个迭代体里有4个独立的MAC包，那展开因子至少需要80/4=20，才能让DMA搬运的等待不被计算打断。我实际做卷积算子时，展开因子经常取到16或32，但不会无限展开，因为指令体积会指数级膨胀，最终指令缓存装不下，又会引入新的cache miss。

软件流水则是比简单展开更高阶的编排方式，典型结构是prologue（准备前几轮）、steady state（稳态时同时执行不同迭代的访存和计算）、epilogue（排空尾部）。稳态阶段就是双缓冲思想在指令层面的体现。实现时要注意同步：芯片上通常有依赖计数机制，DMA完成一个事件，计算单元才能开始消费对应buffer；计数没到位就发射计算指令，结果是未定义行为。我建议在指令集里保留显式的wait事件，不要在每条指令里隐式等待，否则有人会图省事全加wait，性能归零。

4. 一个卷积算子的四轮调优实录：从22%到85%

4.1 先做Roofline健康检查

纸上谈兵结束，看一个真实调优过程。假设某个3×3卷积，输入224×224×64，输出224×224×64，FP16，芯片还是那颗4 TFLOPS、128GB/s的加速器。

先算Roofline。运算量约2×224×224×3×3×64×64 ≈ 3.7 GFLOP。输入数据一次性读入约6.4 MB，输出写回约6.4 MB，总数据量按12.8 MB算，算术强度约289 FLOP/Byte，远大于转折点31。结论很明确：理论上是算力受限算子，优化的核心目标应该是提高MAC阵列利用率，而不是跟带宽死磕。

这个健康检查能避免很多弯路。有一个负责模型部署的同事，拿到算子直接猛优化DMA通道，折腾两周，带宽利用率从40%拉到70%，算力利用率却纹丝不动，因为本来就是算力受限，搬运怎么省都省不出多少时间。先花10分钟算Roofline，后面省下来的时间是以天计的。

4.2 从22%到85%的四轮优化路径

我用表格记录实际优化过程，每一步都有明确改动和对应数据：

V0到V1是最容易的一步：把输出通道分块，让输入行在片上被多个输出通道复用，输入的重复读少了一个数量级。V2把双缓冲加上后，系统从“搬运完再算”变成“边搬边算”，性能直接上一个台阶。V3处理的是一个很容易被忽略的问题：原数据布局是NHWC，DMA搬一行要带几个不连续段，改为内部NCHW连续布局并做地址对齐后，总线效率明显改善。

V4阶段最有意思。3×3卷积有大量padding弃算，我针对输入尺寸做shape特化，把边缘通道单独处理，主计算路径去掉所有分支判断；同时把循环体内的指令包从塞满通用寄存器改为用累加器直通方式，减少指令字里的冗余比特。这一步把利用率从66%推到85%。再往上调不动了，因为剩余15%包括DMA换轨、同步等待、以及编译器排不满指令槽等真实开销。

5. 性能瓶颈速查：先看五个典型现场

5.1 五个“看起来正常但很慢”的状况与对策

第五种现场最容易误判。表面上看MAC阵列没跑满，带宽计数器也没到上限，很多人会以为是硬件坏了。实际上往往是指令之间的数据依赖没被编译器安排好，每个周期都在等结果。VLIW里单个依赖链上的关键路径如果能从20周期压到10周期，整体性能翻倍不是夸张。排查办法是看性能计数器的stall事件，而不是靠肉眼看波形。

5.2 两个值得长期投入的Profiling习惯

第一个习惯是三层时间分解。第一层看整个算子从调用到返回花了多少时间；第二层看其中计算时间、搬运时间、同步等待时间各占多少；第三层再看计算时间里MAC阵列真正在跑的比例、流水线stall了多少周期。这个分解做完，大部分瓶颈其实已经定位了。

第二个习惯我可能说过很多次，但值得再说：做置换实验。比如怀疑某个算子是搬运瓶颈，就写一个“只搬不算”的版本，把计算结果伪造一下；再写一个“只算不搬”的版本，数据常驻片上。两个版本一比，瓶颈在哪一目了然。这个方法不需要复杂的工具，一个计时器就够，但我在多个项目里靠它省下了几周的排查时间。

我在团队里一直推行一个做法：每次调优都留一份“利用率报告”，跑完自动打印MAC利用率、带宽利用率、stall事件数三项核心指标。新人接手任何算子，第一件事就是跑一遍报告，而不是直接看代码。坚持一年下来，这个脚本就成了团队最强的新人培训材料。

6. 从调优到“调优习惯”：几点个人体会

做了这么多年软硬件协同优化，我越来越觉得，一个优秀的算子工程师跟普通工程师的区别，往往不是谁更会写循环，而是谁更早建立了“资源账本”的思维模式。拿到任何算子，先算Roofline，再定优化方向，然后围绕分块、复用、流水线三个动作反复打磨。这套流程比任何奇技淫巧都管用。

最后再分享一个小技巧：把常用的分块参数和延迟数据做成一张卡片，贴在工位上。DMA对齐要求多少字节、片上单块最大能放多少、MAC等待周期多长、写回用什么类型成本最低——这些数字不需要背，但每次写代码前扫一眼，能避免大量低级失误。这块内容往后还值得再展开一点，比如自动化调优框架怎么把这一整套流程变成脚本，又或者图级优化如何在多个算子之间进一步复用片上数据。这个系列后面有机会继续聊。