AI芯片的软硬件设计这个系列写到第6篇我打算聊一个特别容易被项目进度逼到角落的话题模型在框架里跑得好好的为什么一落到自研AI芯片上就各种拉胯你以为是硬件算力不够结果一查往往是软件工具链根本没把算子映射到硬件该有的形态上。这篇我就把从AI模型到芯片指令这条链路上最关键的几个环节拆开讲包括算子映射、数据流设计、编译器优化、运行时调度以及我在调试过程中踩过的坑。适合正在做AI芯片验证、编译器开发和系统软件的工程师也适合准备入门AI芯片方向的在校学生。1. 从AI模型到芯片指令这条链路到底长什么样1.1 模型、算子、指令三个层次的基本关系AI芯片软硬件设计的第一件事是把“模型”和“硬件”这两个看似不相关的世界打通。AI模型本质上是一个巨大的计算图节点是各种算子边是张量。芯片本质上是一堆可以执行乘加、访存、控制的硬件资源。中间需要一个“翻译官”把算子变成能在硬件上跑的指令序列。这个翻译通常不是一次到位的而是分成多层框架层把模型解析成计算图这时候还是高层语义。图优化层做算子的融合、重排、精度转换把计算图变成更高效的形式。算子调度层把逻辑算子切分成适合硬件计算阵列的tile并决定循环顺序。指令生成层把tile映射成具体的搬运指令、计算指令和写回指令。这就像一道菜谱本来写着“把食材切段、热锅、翻炒”但后厨的设备可能只有一把菜刀和一个电磁炉你需要把每个动作翻译成“用这把刀切土豆、按哪个按钮、开多大火候”。菜谱对应模型后厨设备对应芯片翻译过程就是软硬件协同设计要解决的问题。这里我想强调一个观点AI芯片软硬件设计的核心不是分别把硬件做快、把软件做优而是让软件知道硬件的每一块资源怎么用让硬件为软件提供更高效的抽象接口。否则就会出现“峰值算力很高实测利用率很低”的尴尬局面。1.2 为什么一定要做软硬件协同设计硬件一旦流片就很难改软件是唯一可以调整的空间。这个道理大家都知道但实际项目里经常是硬件架构先定编译器团队再被动适配结果就是工具链开发周期被拉得很长而且做出来性能也达不到预期。我身边有个真实例子。某团队做过一颗边缘AI芯片峰值算力标称很高但跑一个小型分类模型实际利用率只有20%左右。一开始大家以为是MAC阵列不够后来一测发现每一层卷积都在反复搬运同一份特征图到片外内存软件侧的循环顺序跟硬件的数据重用方式不匹配。改完编译器调度之后利用率直接翻了三倍。这个例子足以说明做AI芯片不只是数字电路设计的问题“软硬件协同设计”才是决定项目成败的关键交叉点。具体到工程上协同设计不只意味着“软件适配硬件”还包括硬件做出合理的抽象和编程模型。硬件设计时要考虑编译器能否有效生成代码、中断和同步机制是否够用、内存寻址方式会不会给数据搬运造成麻烦。如果硬件架构师只盯着RTL设计不跟编译器团队对齐后期工具链会非常难写。2. 算子映射与数据流分析硬件架构决定软件写法2.1 卷积/矩阵乘算子的映射策略卷积是AI芯片里最常见的算子也是编译器要重点关照的对象。卷积在数学上可以转化成矩阵乘但直接做大矩阵乘法会浪费大量内存所以行业里普遍的做法是“切块”把卷积输出按空间位置和通道切成小块逐个映射到硬件计算阵列上。举个具体参数来算一下。假设某层卷积的输入特征图是16x16输入通道IC64输出通道OC64卷积核3x3输出尺寸14x14。总乘加次数就是14146433*64大约1.13亿次乘加。如果主频1GHz、MAC阵列为8x8、每周期完成64次乘加理想情况下这个卷积只要1.76毫秒。但这只是理想值实际做不到原因在于数据怎么喂给MAC阵列。最简单的映射方式是让8x8阵列处理一个空间位置的输出每个PE对应一个输出通道。这样输入通道要循环64次每次加载一个3x3核数据的重用性很差。更优的映射方式是把8x8阵列的行方向映射到输出通道OC列方向映射到输入通道IC每个周期可以同时算8个输出通道和8个输入通道的局部矩阵乘。这时循环嵌套会变成这样for oh in range(14): for ow in range(14): for oc_block in range(OC // 8): # 每次处理8个输出通道 for ic_block in range(IC // 8): # 每次处理8个输入通道 # 从片上buffer取数据计算8x8的MAC操作 mac_array(data_buf, weight_buf, out_buf)实际工程里还有更复杂的空间切分比如把OH、OW也分块以适配有限的片上存储。映射策略直接决定编译器生成什么循环结构也决定DMA要搬运哪些数据。我在带编译器项目时有一个习惯拿到一个新算子先手画一张数据复用图把输入、权重、输出三个张量在MAC阵列上的流动方向标出来再决定主循环顺序。这个步骤看似原始但比直接看代码更不容易出错。2.2 数据流、片上存储与带宽匹配卷积映射的循环顺序背后其实对应三种经典数据流输出固定、输入固定、权重固定。输出固定Output Stationary的思路是把部分和一直留在片上寄存器或累加器里减少中间结果的写回适合输出通道多但每个输出点计算量大的情况。输入固定Input Stationary的思路是让输入激活尽量驻留在片上反复被多个输出通道复用适合输入通道少但输出通道多的层。权重固定Weight Stationary则是让权重在片上待着不动反复读取不同输入适合权重规模不大、能整体放进SRAM的小模型。选择哪种数据流本质上是在“访存带宽”和“计算并行度”之间找平衡。还拿上面那个卷积层举例输入特征图161664INT8下约16KB权重336464约36KB输出1414*64约12KB。单看一层都不算大但网络动辄几十上百层如果每层都把中间特征图写回DDR累计的搬运量会非常可观。编译器要做的就是尽量让中间特征图留在片上避免每一层都跟DDR打交道。工程上通常用tile调度和片上内存复用来实现。比如可以把一整层卷积的输入特征图分块让每个tile在片上完成所有输入通道的累加再一次性写出结果。这就像后厨上菜不是每炒一道菜就去仓库取一次食材而是按一批菜的需求提前把食材都堆到厨房里。我在实际项目里见过一种常见的性能杀手数据流的切换导致编译器生成的代码频繁flush累加器。比如前一层用输入固定后一层用输出固定硬件状态要切换中间有很多空泡周期。所以设计编译器时最好让数据流策略在模型的层与层之间尽量保持一致减少硬件状态切换的开销。3. 编译器设计与调度策略工具链里的几个核心关卡3.1 图优化与算子融合做AI芯片编译器说白了就是要在一个受限的硬件资源下把计算图优化到极致。图优化里收益最明显、也最容易出问题的一步就是算子融合。最经典的是卷积批归一化激活函数的融合。推理阶段批归一化可以折叠到卷积权重里激活函数可以融合到MAC输出后这样中间结果不需要落回内存。以INT8特征图为例某层输出特征图大小如果是64x32x32那就是64KB写回再读一次会增加128KB的搬运。一个几百层的模型累积起来访存开销会非常吓人。编译器侧通常有多级IR。最上层是框架给的原始计算图中间是经过图优化的IR底层才是面向硬件的IR。算子融合一般发生在中间层常见的融合组合有Conv BatchNorm ReLUConv Add ReLU残差结构里的融合MatMul Add 量化scale融合不是把节点简单合并就完事还要注意数值范围。尤其是量化网络BN折叠后卷积权重可能整体偏大或偏小如果直接套原来的量化scale输出很可能会溢出INT8范围。解决方式是在折叠后重新统计权重分布更新scale。3.2 内存分配与指令调度片上存储永远是AI芯片最紧张的资源。编译器要做内存分配通常基于张量的生命周期分析。如果两个张量在时间上完全不重叠就可以共用同一块SRAM这种静态内存复用策略能省下不少空间。实际操作时我会先用一个简单的liveness分析脚本把每个算子的输入输出张量生命周期都画出来再检查哪些可以复用。不要小看这一步很多芯片的片上内存不大一个稍大的特征图放不下就必须通过切tile来分时复用这时候内存分配的顺序直接影响每个tile能不能靠双缓冲把DMA和计算重叠起来。双缓冲是调度里最重要的手段。原理很简单用两块buffer交替工作DMA正在搬运下一块数据到buffer B时MAC阵列在计算buffer A里的数据。伪代码大概是for (int tile 0; tile tile_count; tile) { dma_load(tile 1, buffer[1 - cur]); // 提前加载下一次数据 wait_event(load_done); mac_compute(buffer[cur], out_buf); // 计算当前数据 signal(compute_done); dma_store(out_buf); // 写回结果 cur 1 - cur; }指令调度的目标是让搬运指令和计算指令尽量重叠。编译器要做依赖分析哪些指令必须先执行、哪些可以并发再按依赖关系重排指令序。有些编译器会采用类似软件流水software pipelining的方法把循环体的几条指令交错排开让硬件流水线每个阶段都保持忙碌。这块最容易出问题的是同步原语。如果硬件不支持细粒度的事件同步编译器就只能用比较粗糙的barrier两段流水之间必须停下来等性能会明显变差。所以我在参与芯片架构讨论时强烈建议硬件设计者至少提供独立的DMA完成事件和计算完成事件让编译器有得玩。3.3 量化与稀疏化在编译器侧的配合低精度推理是AI芯片的常态INT8基本是标配。量化的核心是把浮点权重和激活映射到整数域乘加结果通常是INT32输出之前需要再做一次scale还原和饱和截断。编译器要插入这些量化节点不只是离线把权重转成INT8那么简单。具体来说编译器要处理三种东西zero-point数据偏移量影响加减法。scale数据缩放比例影响乘法结果还原。饱和边界INT8输出范围是[-128,127]超出要截断。如果不处理zero-point和scale的传播融合后的计算也许“看起来能跑”但数值上会悄悄偏掉。我见过一个项目逐层对比FP32和INT8输出时前几层误差还好到第20层就开始明显放大最后定位时发现是BN折叠后的scale没有重新分配导致误差逐层累积。稀疏化是另一个热门方向。权重稀疏化或者激活稀疏化可以减少乘加次数但硬件要真正跳零需要软件侧提供稀疏格式。常见做法是用bitmask标记哪些数据有效硬件读取后只对有效数据做乘加。但这里有个陷阱如果硬件的bitmask解码逻辑很慢或者压缩格式选择不对那么节省的乘加周期会被解码周期抵消。我在调试中遇到过编译器把稀疏权重压缩得很小看起来搬运量降低了但实际运行时因为硬件要逐字节解码掩码周期反而变长。所以稀疏支持一定要硬件配合好比如在DMA层面直接支持稀疏块读取否则软件费半天劲最终效果是负优化。4. 硬件抽象层与运行时让算子“跑得稳”的关键4.1 HAL设计与算子注册编译器和硬件之间硬件抽象层HAL是必不可少的一层。HAL的作用是给上层提供统一、稳定的算子接口把底层到底是模拟器、FPGA原型还是真片这部分差异全部藏起来。我在做AI芯片工具链时HAL里通常定义一组标准的算子执行接口比如struct Kernel { const char* name; int (*execute)(const void* args); }; static Kernel kernel_table[] { {conv2d, conv2d_execute}, {matmul, matmul_execute}, {resize, resize_execute}, }; int invoke_op(const char* op_name, const void* args) { for (int i 0; i sizeof(kernel_table) / sizeof(Kernel); i) { if (strcmp(kernel_table[i].name, op_name) 0) { return kernel_table[i].execute(args); } } return -1; }这段代码虽然简单但它带来的工程收益很大。上层推理引擎或者框架只需要按算子名从注册表里查到实现不需要关心底层驱动怎么调度、芯片怎么配寄存器。同一个模型可以很方便地在“指令级模拟器”和“真片”之间切换这对验证流程特别重要。HAL设计时要注意接口粒度不要太小。如果每个底层操作都暴露给上层上层代码会非常啰嗦而且难以优化调用开销。我比较推荐“粗粒度算子接口参数结构体”的方式把卷积参数、矩阵乘参数、内存缓冲区全部装进一个struct减少函数调用次数和参数解析开销。4.2 运行时调度与流水有了HAL下一步是运行时runtime。运行时要做的事很多维护任务队列、管理内存池、处理算子间的依赖关系、同步多个计算核心。运行时调度器的基本逻辑是这样的根据计算图的拓扑顺序为每个算子维护一个依赖计数。一个算子的所有输入都就绪后它的依赖计数归零就可以被投递到任务队列。多核情况下多个互不依赖的算子可以分配到不同核心执行。这里要特别小心同步问题。硬件计算完成可能通过中断或者状态寄存器通知软件要用异步事件来等待避免CPU轮询导致总线压力过大。我见过一个诡异bug一个端侧推理任务偶尔结果不对排查了很久最后定位到缺少同步barrier总线延迟导致一个算子的输出还没完全写回片外下一个算子就开始读取。解决方式是在运行时里加入事件等待机制每个算子的完成事件对应一个标志位后续算子启动前检查。为了不增加多大开销事件标志可以用原子操作不要用锁。还有一个容易被忽略的点小算子的调度开销。模型里除了卷积、矩阵乘还有很多reshape、transpose、拼接算子。如果在CPU侧逐个执行每多一次kernel launch就多几十微秒的开销。真正的端到端优化要把这些“小算子”也尽量融合或者转移到硬件上执行否则性能会浪费在调用开销上。5. 性能调优与常见问题速查5.1 性能上不去先查哪几个点我在项目里总结了一套性能调优的基本路径遇到性能瓶颈时按顺序查基本能定位大部分问题。第一步看MAC利用率。方法是用profiler统计有效计算周期和总周期如果利用率低于50%先别急着加计算单元大概率是数据搬运卡住了。第二步看访存热点。检查DMA搬运量看是否有不必要的写回、有没有碎片化搬运。很多一次写回又读出的问题通过算子融合就能解决。第三步看融合是否真的生效。编译器在IR层面做了融合但能不能落到硬件上要看后端是否真的生成了对应指令。我习惯把中间IR dump出来直接对比融合前后的算子序列。第四步看小算子开销。如果端到端延迟比单算子累加时间长很多那多半是kernel launch次数太多要压缩调用次数。下面是我常用的速查表指标合理范围异常时的排查方向MAC利用率70%以上DMA是否等待、是否有数据冲突DMA搬运量与理论访存量接近有无重复搬运、有无碎片融合生效比例关键层全覆盖检查IR dump、检查后端匹配Kernel调用开销占比小于5%减少小算子调用、批量提交5.2 实测中遇到的怪问题与排查思路做AI芯片工具链总会遇到一些想破头都想不到的问题。这里分享几个我在实验中遇到的典型问题以及对应的排查思路。第一个是量化后精度崩掉。模型在FP32下跑得很好INT8后却出现明显掉点。后来逐层对比INT8和FP32的输出范围发现某一层卷积在ReLU之前就溢出了INT8范围。解决办法是在融合时加入重定标节点重新计算该层的量化scale让中间结果落在合理范围内。第二个是片上内存bank冲突导致性能抖动。同一个模型有时候跑得快有时候跑得慢最初以为是调度问题。后来用profiler看DMA等待周期发现多个tile的地址分布落到了同一个bank导致并行访问冲突。调整地址偏移或者加padding之后性能稳定了很多。第三个是多核计算结果不稳定。单核跑永远正确多核跑偶尔出错。先怀疑数据依赖没处理好检查算子间的barrier是否齐全再检查总线并发写冲突。最终定位到两个核心同时写同一个输出地址的边界区域通过任务划分时重叠区域做冗余计算解决。这里我想给个实用建议先写性能模型再动代码。拿到硬件参数后先在大脑里把关键层的计算量和访存量估算一遍再写个简单的计算脚本来验证。很多时候性能瓶颈是可以推算出来的不需要盲目跑实验。我自己做了几年AI芯片相关工具链最大的体会是芯片架构和编译器一定要同时设计不要等硬件定稿了才开始想软件。哪怕只做一个简单的性能模拟器把每个算子的预计算力和访存时间都标出来也能在早期把最差的设计决策拦在门外。这个系列后面我还会挑几个更具体的点来写比如多核间数据同步、低精度推理的数值稳定性、还有编译器的自动调优。如果你也在做类似项目建议至少让团队里有个既懂硬件、又懂编译器的同学做端到端的owner很多时候项目不是死在算力上而是死在软硬件之间的那层“翻译”上。
