做端侧AI芯片那几年我听到最多的一句话是模型在服务器上跑得飞快为什么上了我们自己的芯片就慢得离谱这种问题十有八九不是微架构不行而是软硬件设计没有对齐。AI芯片从来不是纯硬件工程它是把算法、编译器和硅片绑在一起协同设计的系统。一个只有硬件没有软件栈的芯片顶多算一块漂亮的砖头一套不考虑硬件特性的编译器也救不了一个数据流设计有硬伤的架构。这篇内容我想结合自己参与过的端侧AI芯片项目把软硬件协同设计这件事从架构拆解、编译器落地、性能模型到踩坑排查完整过一遍。适合正在做AI芯片架构、编译器、算子库的工程师也适合算法同学想搞清楚我的模型为什么在自研芯片上跑不快。1. AI芯片的软硬件设计本质是一枚硬币的两面1.1 通用计算的契约与AI芯片的尚在起草的合同做CPU和GPU的老工程师常说一句话指令集是硬件和软件之间的契约。这个契约一旦定下来编译器、操作系统、应用软件全都按它来写硬件迭代只要保证向后兼容旧软件就能在新芯片上继续跑。这套机制让通用计算生态稳固了几十年代价是硬件要为未知的未来负载留足通用性因此在面对AI模型这种极其规律的矩阵运算时通用架构的效率并不理想。AI芯片走的是另一条路。它属于领域专用架构DSA设计之初就假设自己只需要高效处理有限几类算子比如卷积、矩阵乘、激活函数、归一化。这个假设给了架构师极大自由度可以把大量晶体管堆成MAC阵列可以做很窄的片上存储层次甚至可以去掉分支预测、乱序执行这些通用处理器必须保留的复杂逻辑。但自由度是有代价的。通用CPU的契约是稳定的AI芯片的契约往往还在起草中。我在项目里见过一种状态RTL已经冻结编译器还没定义清楚指令调度策略算法团队还在改模型结构。三个团队各动一下最后对接出来的性能惨不忍睹。这就是软硬件没有协同设计最典型的症状——硬件设计了一个很好的特性软件栈却不知道怎么用软件栈做了一个优化硬件又没有对应的数据通路来支撑。1.2 为什么编译器即架构这句话永远不过时在AI芯片项目里用户真正接触到的不是指令集手册而是编译器、算子库和部署工具链。你硬件设计了再好的张量指令如果编译器不生成对应的指令序列或者算子库根本不调用这个特性那这个硬件功能就等于不存在。反过来硬件设计得好不好最终也是靠编译器测出来的。我有个很深的体会给AI芯片做编译器和给CPU做编译器是两种完全不同的工作。CPU编译器面对的是几十年沉淀下来的稳定指令集主要工作是寄存器分配、指令调度这些通用优化AI芯片编译器面对的是一个仍在快速演进的计算图它要做的第一件事是理解模型的结构然后决定哪些算子融合、哪些算子落哪个核、数据在片内片外怎么搬运、哪一层用FP16哪一层用INT8。这些决策直接决定了芯片能不能吃饱。所以我在团队里经常强调一个观点架构评审的时候不能只看MAC阵列有多大、主频有多高一定要把编译器团队的核心成员拉进来让编译器的人提前回答一个问题——这个数据通路设计我们现有的编译器能不能有效喂饱如果喂不饱算力数字再好看也只是PPT上的数字。2. 硬件骨架算力从哪里来数据又在哪里卡住2.1 MAC阵列与数据位宽算力账要算清晰AI芯片算力的核心单位是MAC也就是乘累加操作。一个MAC单元在一个周期内完成一次乘法和一次加法通常表现为a a w * x。一个由M行N列MAC单元组成的阵列理论上每个周期能完成M×N次乘累加再乘以时钟频率就得到峰值算力。这里有三个账要算清楚。第一峰值算力不等于有效算力。阵列里的每个MAC单元只有在数据到位时才能干活。如果片内SRAM太小、带宽不够数据搬运的速度跟不上计算速度阵列就只能空转。这个现象在芯片领域有个形象的叫法算力饥渴。第二位宽决定能效。INT8 MAC单元的面积和功耗大约是FP16的三分之一到二分之一更不要提FP32。所以几乎所有端侧AI芯片都选择INT8作为主力精度FP16做增强FP32基本只出现在少数需要高精度的兜底场景。硬件支持混合精度不难难的是编译器要能根据每层算子自动选择合适精度不然INT8单元和FP16单元之间来回倒腾数据反而浪费周期。第三MAC阵列的排布方式影响数据复用。同样128个MAC单元可以排成16×8的阵列也可以排成32×4的阵列两种排布对输入特征图、权重、输出特征图的搬运次数完全不同。这一步选择基本确定了芯片的数据流风格。2.2 片内存储层次与Dataflow决定芯片真实吞吐量的隐藏变量很多第一次接触AI芯片的人会盯着MAC阵列看觉得算力是唯一指标但实际项目里最常卡脖子的恰恰是存储和搬运。一个典型AI芯片的存储层次大致是寄存器文件、片内SRAM、片外DRAM。MC阵列直接消费的数据必须来自最近的存储层次但SRAM容量有限DRAM延迟又高所以关键在于让数据尽量在片内循环使用。打个不那么精确但很直观的比方MAC阵列是工厂里的工人SRAM是工位旁的工具台DRAM是远在几公里外的仓库。工人干活快不重要重要的是工具台上要一直有料。每次去仓库取料都消耗大量时间所以最聪明的做法是一趟把一批料拉到工具台让工人反复使用后再回去取下一批。这个一趟拉多少料、在工位上复用多少次的策略就是芯片设计里的dataflow。以二维卷积为例。一个3×3卷积核滑过一张特征图对每个输出像素都要做9次乘累加。如果权重数据能留在MAC阵列旁边的寄存器里输入像素持续流入输出结果持续流出那DRAM的访问次数就很少。但如果每次计算都重新从DRAM取权重带宽立刻爆炸。所以数据流设计的核心只有一个问题哪份数据可以留在片内复用多少次。2.3 一张表格看懂三种主流数据流策略数据流策略让谁待在片内核心优势典型代价适合场景权重固定卷积核权重权重复用率高适合卷积核参数复用多的模型输入特征图需反复搬运片内空间占用大大规模卷积计算输出固定输出累加结果减少部分和写回DRAM适合累加次数多的层权重需反复加载通道并行受限深度可分离卷积、小模型行流式按行滑动窗口数据适合流式处理片上存储压力小调度复杂度高分支场景多视频流、多帧连续处理选哪种数据流不是拍脑袋决定的要看目标模型的计算特征。我在某次项目里发现用权重固定策略跑一个通道数很大的骨干网络效果很好但切到一个小而深的分支网络时性能掉了三成原因就是输出特征图只有几路每个权重只被复用几次权重的搬运成本反而压过了复用收益。最后我们在编译器里做了一层自动切分逻辑根据卷积的输入输出维度动态选择数据流策略才把这个差距补回来。3. 软件落地从模型计算图到芯片指令的完整链路3.1 计算图优化在几何层面做减法软件栈接手一个模型时硬件看到的只是一张由算子节点组成的数据流图。这张图往往来自PyTorch或TensorFlow的导出结果包含了大量冗余常量折叠没有做、连续可融合的算子没有合并、shape转换插了一堆没必要的拷贝。直接把这张图交给硬件执行等于在给芯片喂垃圾。计算图优化的第一个动作是淘汰冗余节点。比如某个常量在模型编译期就能算完那就不该在运行时再算一遍某个节点的输出没有任何消费者那就直接剪掉。第二个动作是改写等价结构比如把若干个连续的小卷积合并成一个等效的卷积减少调度开销。第三个动作是算子融合这一步对硬件最友好也最考验编译器功底。拿最常见的ConvBNReLU融合举例。如果不融合卷积输出整张特征图要写到DRAMBN算子再把整张图读出来算一遍ReLU再读再写一次。三级流水下来同一个中间张量在DRAM里被写读了好几次。假设中间特征图是512×512×64的FP16数据这一张图就是32MB。对端侧芯片常见的几十GB/s带宽而言光这一次多余的回写和重读就要多花几毫秒。而整张图融合后BN和ReLU可以在数据还留在MAC阵列输出寄存器时顺势算完整个中间张量根本不用落地。3.2 算子映射与指令生成编译器在给硬件编舞计算图优化做完编译器拿到的还是一张逻辑层面的图接下来要做的是把每个算子映射到硬件能执行的指令序列上。我经常把这一步类比成给舞蹈演员编舞硬件提供了哪些动作——MAC指令、搬运指令、激活指令、存储指令——编译器要决定每个动作什么时候做、用哪个执行单元做、数据从哪里来。这一步有三个核心子问题。第一个是算子切分。一个卷积可能远大于片内SRAM容量编译器必须把特征图和权重切成若干个tile逐个送入MAC阵列计算。tile切多大、切几维、切完按什么顺序送直接决定了数据复用的比例。第二个是数据搬运调度。数据从DRAM搬到SRAM、从SRAM搬到MAC阵列可以重叠在计算周期里进行这是隐藏访存延迟最关键的手段。如果编译器把搬运和计算排成串行芯片利用率至少减半。第三个是指令发射顺序。硬件可能有多个执行单元可以并行工作比如MAC阵列算卷积的同时标量单元做激活、DMA单元预取下一块数据编译器要尽量让它们互不阻塞。静态shape模型在这种场景下最容易优化。因为所有张量尺寸在编译期确定编译器可以把整张图的片内内存规划、指令调度全部预先算好运行时几乎不需要决策。动态shape模型则是噩梦——每次shape一变内存规划和tile切分都要重算很多芯片干脆用保守策略兜底性能下降非常明显。3.3 量化不只是精度问题更是硬件能力边界的对齐说到量化很多算法同学的第一反应是精度掉点怎么办。但站在软硬件协同设计的角度量化本质上是在回答一个问题模型要妥协到什么程度才能完全跑在硬件最舒服的精度范围内。端侧AI芯片通常把INT8作为主力精度因为INT8 MAC单元又小又快。但硬件支持INT8不意味着所有算子都适合INT8。LayerNorm、Softmax这类算子做完归一化后数值分布极其集中量化误差会直接积累到后续层的输入上某些检测头的回归分支对绝对值精度也很敏感。如果编译器一刀切地把所有层都压到INT8调试起来会非常痛苦。我见过一个很典型的翻车现场某检测模型精度掉得特别厉害算法团队调了一周量化参数都没救回来。最后我们用逐层对比的方法把每一层FP32和INT8的输出特征图拉出来算误差发现误差集中在第二个检测头附近的某个小卷积上数值范围极宽量化步长一设就饱和或欠分辨。把那几层切成FP16混合精度跑精度立刻回到正常水平。所以编译器在设计阶段就必须预留混合精度调度的能力而且要能支持按层、按算子粒度的精度切换。否则一旦模型里出现顽固层只能整网跑FP16算力直接打对折。4. 软硬件协同设计中的数据瓶颈分析用Roofline说话4.1 从一道矩阵乘说起算力再高也怕带宽饿死判断一个kernel在芯片上是被算力限制还是被带宽限制业内有一套非常成熟的分析框架叫做Roofline模型。它的核心思想很简单每个算子的实际性能不会超过两个天花板一个是芯片的峰值算力一个是带宽乘以算子的算术密度也就是每读取一个字节数据能完成多少次计算。举个例子。假设芯片的INT8算力是4TOPS带宽是20GB/s那么算术密度的分界点是200 ops/byte。一个卷积层如果算术密度只有10 ops/byte那它无论如何都跑不到4TOPS真实上限被带宽锁死在200 GOPS左右利用率只有5%。出现这种情况的原因通常就是数据复用没做好每个输入数据只被用了一两次就被丢掉MAC阵列饿着肚子干活。我一直建议芯片架构团队在定硬件规格前先把手上的目标模型逐层跑一遍算术密度分析。有些层天然是计算密集的比如大通道数卷积有些层天然是访存密集的比如逐元素运算、激活层。两者混在一个模型里硬件必须在MAC阵列和带宽资源之间找到一个平衡点。只堆算力不做带宽访存密集层就会变成无底洞只堆带宽不做算力计算密集层又会浪费片上资源。4.2 协同设计的决策流程先定瓶颈再定方案协同设计的完整决策流程我的习惯是先做一个性能预分析再决定在哪个维度做改动切忌上来就改硬件。第一步收集目标模型每层的FLOPs和特征图尺寸算出每层的算术密度。第二步在预估的芯片算力和带宽参数下逐层画出Roofline上限找到哪些层落在带宽限制区哪些层落在算力限制区。第三步针对带宽限制层看软件手段是否足够能不能优化tile切分增加复用能不能算子融合减少DRAM往返如果软件手段已经用足还是不够才考虑在硬件侧增加带宽或者调整存储层次。这套流程看起来很基础但实际项目里很多团队跳过了前两步直接凭感觉加buffer、加MAC结果钱花了不少端到端性能提升却很有限。原因就是他们没有先定位瓶颈在非瓶颈的地方砸资源收益当然有限。4.3 一张表梳理三端优化方向层面常见瓶颈征象优先优化动作协同设计含义算法侧模型结构碎片化大量小算子改算子结构、合并卷积、降精度算法有权影响芯片数据流设计需求软件侧tile切分粗糙算子融合少优化计算图、加融合、调调度编译器负责榨干现有硬件能力硬件侧实测带宽利用率长期低于六成加DMA通道、调SRAM容量、改数据流硬件改动成本高必须是最后手段我见过一个很有意思的案例某团队原本计划在下一版芯片里把MAC阵列规模翻倍理由是算力不够。但性能预分析显示卷积部分其实只用了不到四成算力真正拖后腿的是模型里大量逐元素操作把带宽打满了。他们后来只调整了三处一个访存指令的burst长度、一个数据搬运引擎的通道优先级、编译器里的算子融合开关就获得了接近翻倍的端到端提升。这比流片改架构便宜、快得多。5. 一次端侧AI芯片的项目复盘需求、架构、编译器与实测闭环5.1 需求定义与硬件基线先让性能模型跑起来这里拿我参与过的模拟项目X做一次完整复盘。项目目标很明确在5W功耗约束下跑一个中等规模的视觉检测模型端到端时延不超过50msINT8精度损失不超过1%。算法团队给出来的模型是一个以卷积骨干为主、带两个检测头的结构卷积占比大约七成剩下三成是逐元素操作、上采样、后处理和少量标量逻辑。我们最初的硬件基线是一个64bit的小核CPU负责控制流和少量兜底算子一个128MAC lanes的专用计算阵列负责卷积和矩阵乘片内SRAM总共2MBDRAM带宽对标同级竞品。编译器方面我们有一套基于计算图的优化器加一个半手写的算子库量化工具支持per-channel的INT8。硬件还没完全回来之前我们就用性能模型把整个网络逐层跑了一遍预估。按当时的带宽和SRAM容量模型里至少有两层卷积和四个逐元素操作会落在带宽限制区端到端预估时延在30ms左右。这个数字说明目标有戏但余量不算大。我们当时就知道真正的考验在实测阶段。5.2 实测发现三个不是芯片bug的性能杀手芯片回来后第一次跑端到端结果让我们大跌眼镜——时延不仅没有贴近预估的30ms甚至跑到了90ms以上。我们一度怀疑芯片有硬件bug结果排查下来发现三个问题全出在软硬件对接的灰色地带。第一个杀手是算子覆盖率不足。模型里有一个非常规的上采样算子我们的算子库不支持编译器只能把它降级到CPU小核上跑。问题不在CPU算得慢而在于NPU到CPU之间需要同步等待一组数据来回切换的同步开销比算子本身还贵。那一次统计发现仅仅这样一个算子就贡献了端到端时延的15%。第二个杀手是layout不匹配。我们的计算阵列内部偏好NHWC的数据排列但模型导出时默认是NCHW编译器为了兼容在每一层之间悄悄插入了大量的permute操作。这些permute本身不算复杂但会把数据从SRAM搬出去再搬回来等效于每层多了一次全量DRAM往返。我们后来统计光这些看不见的permute就吃掉了近三成带宽。第三个杀手是DMA传输效率。我们的数据搬运引擎每次只能做固定burst长度的搬运但编译器给出的tile切分粒度跟这个长度不匹配导致很多小碎块的搬运请求不能合并带宽利用率长期徘徊在四成左右。这个问题在性能模型里完全没体现因为模型假设理想连续搬运。5.3 复盘后的设计流程修正软硬件共同演进这三个问题都不是芯片坏了而是软硬件各自为政的结果。修复过程也很说明问题。我们做了三件事第一编译器侧补齐layout转换传播。在计算图优化阶段建立一个layout推导机制让整个网络尽量统一在NHWC下执行把permute压到最少。第二算子库侧补齐了那个上采样算子并专门设计了一个避免sync等待的异步调度路径NPU和CPU尽量并行工作而不是串行等待。第三硬件侧做了一个最小改动给DMA控制器增加了按tile尺寸自动合并burst的逻辑这个改动不动主架构只是状态机层面的小调整。三件事做完之后端到端时延从90ms降到了38ms已经贴近最初的性能模型预估。这个项目给我留下的最重要经验是性能模型不是一次性工具它必须在芯片回来之后继续校准并且把实测数据反哺回模型让下一版预估越来越准。软硬件协同设计说白了就是一个共同演进的闭环硬件给软件划预算软件用足预算并反馈需求硬件再根据反馈去修订设计。6. 我自己踩过的坑四条高频问题的定位链路6.1 算子支持了但很慢的真相layout不匹配这个算子明明支持为什么跑这么慢是AI芯片项目里出现频率最高的一句话。大部分情况下问题不是算子本身慢而是它周围的layout转换在拖后腿。编译器在遇到数据排列偏好不同的算子时会默默插入transpose、permute这类搬运算子。搬运本身计算量不大但访存开销极高。排查链路我建议这样做第一步拿per-layer profiling数据把每个op的实际耗时列出来排序第二步看耗时最高的op前后是否有大量copy类操作第三步把copy操作去掉后重新计算同样的算子耗时差距立刻现形。大多数情况下你不需要改硬件只需要在计算图优化里把layout传播做彻底。6.2 量化掉点不要急着调模型先做逐层误差体检端侧芯片上模型精度掉点算法团队的第一反应通常是把量化参数调一圈或者把整网改成FP16。但这样做的成本很高算力优势也没了。我建议先做一次逐层误差体检把FP32模型每一层输出的特征图存档再把它跑INT8版本拿到同样位置的输出逐层计算PSNR或余弦相似度。误差最突出的那一层就是量化敏感层通常指向数值动态范围极宽的层或者结构里直接暴露softmax/exp这类非线性输出的层。定位之后用混合精度把这些敏感层切回FP16往往几行配置就能救回精度。6.3 同步开销与DMA效率两个容易被忽略的窝案NPU和CPU之间的同步等待是我见过最隐蔽的性能杀手。某个算子被降级到CPU执行本身可能只要0.2ms但NPU必须等CPU算完才能继续下一层这段等待时间可能长达0.5ms到1ms。几次同步叠加时延立刻膨胀。排查方式是看profiling里的idle占比如果NPU的空闲时间成块出现基本就是同步等待。解决思路通常是异步调度让CPU跑的小算子跟NPU主计算流并发执行而不是硬切。DMA效率问题则要靠带宽探测。在芯片上跑一个纯搬运的测试把burst长度从64字节一路加到2KB记录实际带宽变化。如果有效带宽随burst长度显著上升说明硬件搬运粒度需要和软件tile切分对齐。很多编译器默认按逻辑块搬运完全没有意识到底层DMA的burst约束。6.4 通用排查方法论建立自己的性能回归基线踩过这么多坑之后我建立了一套属于自己的排查方法论。第一件事永远是跑完整的per-layer profiling没有数据不猜原因。第二件事是把问题归类算力瓶颈、带宽瓶颈、同步瓶颈还是精度问题每类问题对应完全不同的解决工具。第三件事是修改时一次只改一个变量改完重测避免多变量互相污染结论。第四件事是保留一份性能回归基线数据集每次芯片版本或者编译器版本更新都重新跑一遍防止性能悄悄回退。我现在拿到一个新芯片或者新工具链的第一件事不是跑模型的准确率而是先把带宽回归、算力回归、算子延迟回归三张表跑出来。这三张表再加上Roofline分析几乎能解释所有端到端性能问题的七八成。剩下的两成靠的就是逐层profiling一帧一帧抠。这套流程看上去不酷但在实际项目里它的价值远超任何炫技式的优化。做AI芯片软硬件协同设计从来不是某一次灵光一现而是把每一层数据流都算清楚、每一步调度都调明白的笨功夫。
