企业官网建设流程全解析

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，输入通道IC=64，输出通道OC=64，卷积核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的小模型。

选择哪种数据流，本质上是在“访存带宽”和“计算并行度”之间找平衡。还拿上面那个卷积层举例：输入特征图161664，INT8下约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 + ReLU
• Conv + 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次数太多，要压缩调用次数。

下面是我常用的速查表：

5.2 实测中遇到的怪问题与排查思路

做AI芯片工具链，总会遇到一些想破头都想不到的问题。这里分享几个我在实验中遇到的典型问题，以及对应的排查思路。

第一个是量化后精度崩掉。模型在FP32下跑得很好，INT8后却出现明显掉点。后来逐层对比INT8和FP32的输出范围，发现某一层卷积在ReLU之前就溢出了INT8范围。解决办法是在融合时加入重定标节点，重新计算该层的量化scale，让中间结果落在合理范围内。

第二个是片上内存bank冲突导致性能抖动。同一个模型有时候跑得快，有时候跑得慢，最初以为是调度问题。后来用profiler看DMA等待周期，发现多个tile的地址分布落到了同一个bank，导致并行访问冲突。调整地址偏移或者加padding之后，性能稳定了很多。

第三个是多核计算结果不稳定。单核跑永远正确，多核跑偶尔出错。先怀疑数据依赖没处理好，检查算子间的barrier是否齐全，再检查总线并发写冲突。最终定位到两个核心同时写同一个输出地址的边界区域，通过任务划分时重叠区域做冗余计算解决。

这里我想给个实用建议：先写性能模型，再动代码。拿到硬件参数后，先在大脑里把关键层的计算量和访存量估算一遍，再写个简单的计算脚本来验证。很多时候，性能瓶颈是可以推算出来的，不需要盲目跑实验。

我自己做了几年AI芯片相关工具链，最大的体会是：芯片架构和编译器一定要同时设计，不要等硬件定稿了才开始想软件。哪怕只做一个简单的性能模拟器，把每个算子的预计算力和访存时间都标出来，也能在早期把最差的设计决策拦在门外。这个系列后面我还会挑几个更具体的点来写，比如多核间数据同步、低精度推理的数值稳定性、还有编译器的自动调优。如果你也在做类似项目，建议至少让团队里有个既懂硬件、又懂编译器的同学做端到端的owner，很多时候项目不是死在算力上，而是死在软硬件之间的那层“翻译”上。