前两篇我们聊了AI芯片的整体架构选型和指令集设计的思路这一篇我打算把视角往下压一层着重聊聊软硬件到底是怎么“咬合”在一起的。很多人对AI芯片有个误解觉得硬件做出来、编译器一接、算子库一填就能跑模型。实际做过一个完整芯片项目之后会发现真正让芯片发挥出理论算力的恰恰是那些不起眼的、软硬件交界处的细节地址怎么排、数据怎么搬、算子怎么切、调度怎么控、量化怎么保住精度。这一篇适合正在做AI芯片、AI加速卡或者端侧NPU相关工作的开发者也适合想从系统层面理解“为什么芯片需要配套软件栈”的算法工程师。1. 从系统视角拆解AI芯片的软硬件设计1.1 软硬件一起设计的本质AI芯片和其他芯片最大的区别在于它的“应用意图”非常明确加速深度学习模型的计算。这带来一个连带结果——硬件必须为特定的计算模式优化而软件栈必须以硬件的数据通路为核心重新组织计算。软硬件协同不是“先出芯片再补编译器”而是在芯片架构定义阶段就要把算子、调度、数据流、内存带宽这些软件层面的约束放进硬件规格里。以矩阵计算单元为例。硬件上决定做一个16x16的脉动阵列还是一个8x8的可重构乘加阵列不只是面积和功耗的取舍更是编译器视野的取舍。16x16阵列意味着每次可以将一个16x16的输出子块一次性计算完编译器需要把大矩阵切成16x16的tile如果硬件还支持2x1、4x4等子模式编译器就要多处理一层模式选择的逻辑。这就是很典型的“给硬件一个自由度软件栈就要接住它”。我在一个模拟项目X里做过类似的事情。当时要设计一个端侧AI加速核硬件团队一开始的想法是做一个很“通用”的SIMD单元配合指令集灵活应对各种算子。结果软件侧用起来极其痛苦——每个算子都要手动把计算映射成SIMD指令序列卷积的im2col转换又浪费大量带宽。后来推翻重来改成固定结构的数据流加速单元算子库从几十个算子缩减到十几个但每个算子都映射得很干净编译器要做的决策反而少了。这个案例让我深刻体会到AI芯片的软硬件设计第一步不是算力有多高而是计算模式有多“配合”。1.2 以最终业务目标倒推设计决策软硬件协同设计的正确起点是最终业务目标。跑什么模型、什么精度、多少路并发、多少毫秒延迟、多少瓦功耗——这些指标直接决定了架构的取舍。不同的目标组合会得出截然不同的设计方案。如果你的目标是云端推理模型的Batch通常比较大芯片设计会倾向于大的矩阵单元、大的片上存储、偏吞吐优化的数据通路支持多Batch并行编译器可以奢侈一点用离线调优把调度方案算得很好。如果你的目标是端侧低功耗场景Batch一般很小甚至只有1此时扫描窗口类的算子占了主流芯片就更适合走小矩阵单元、高带宽的片上存储、低功耗的数据流设计编译器必须处理动态形状和稀疏控制流。这里有一个非常容易被忽略的点模型在部署阶段的“形状动态性”会直接反作用于硬件设计。如果硬件只支持固定形状输入编译器就只能通过padding和循环裁剪来处理动态输入内存会被浪费很多边缘场景的延迟抖动就是这么来的。在设计硬件接口时就要明确允许哪些维度可变、哪些维度必须固定。这不是软件能补回来的必须在芯片定义时定清楚。我在实际项目里吃过这个亏。某一次做视频结构化芯片的软硬件方案硬件定的是固定3x3卷积加速单元当时觉得靠补丁算子能兜住1x1、5x5这些情况。结果到了适配阶段1x1卷积全被拆成矩阵乘来跑还好矩阵单元够大5x5则拆分到几乎翻倍。硬件团队后来在下一版里加了可配置的卷积窗口寄存器编译器适配工作量直接降了一半还多。所以软硬件设计的本质是——软件能扛多少硬件才能省多少硬件省多少软件就要补多少。不能让某一方单方面“优雅”。2. 硬件侧微架构与算力传递的关键取舍2.1 算力单元的选择与量化AI芯片的算力单元最常见的就是两大类SIMD风格的并行乘加阵列 vs 脉动阵列systolic array。它们的本质差异在于数据复用方式。传统SIMD是把数据从寄存器堆搬到计算单元每条指令可以并行执行多次乘加脉动阵列则是让数据在阵列中流动每个计算单元把结果顺带传给相邻单元从而减少重复读取。这两类方案对软件栈的影响完全不同。SIMD风格在指令集层面暴露了大量的寄存器操作编译器要管好变量分配、指令调度、向量化。脉动阵列则把重心放在数据编排上——编译器几乎成了一个“数据搬运调度器”计算单元本身的操作顺序是高度规律的反而是权重和激活怎么喂进去、怎么轮转决定了绝大部分性能的优劣。算力单元的量化决策是另一个关键点。INT8、FP16、BF16、FP32这些精度选项不是单纯数值精度问题而是整个数据通路宽度的定义。每减少一半位宽片上存储带宽的有效利用率就能双倍提升功耗也是近似线性下降。但要保住精度往往需要混合精度设计部分层用FP16、部分层用INT8甚至同一层的权重和激活用不同精度。这时候硬件必须提供精细的精度切换粒度同时编译器也要有对应的量化感知调度能力。我在一个语音识别芯片的设计评审里看到过一种做法硬件支持per-channel的量化缩放因子每个通道在乘法之前都能独立乘一个标量。这种东西看起来只是一个小细节但直接决定了后训练量化的精度能不能保住。没有这个能力部署时就会被迫退回FP16功耗性能全打折扣。这就是典型的“硬件的一点小设计能替软件解决一整个部署场景”。2.2 存储墙与数据搬运AI芯片设计的核心约束大部分时候不是计算单元有多大而是存储带宽够不够喂饱计算单元。也就是所谓的“存储墙”问题。理论上一个16x16的MAC阵列在1GHz下每周期要吃掉16162*1字节512字节的数据如果从DDR里搬数据DDR带宽根本接不住。所以AI芯片一定要有片上的多级存储体系寄存器堆、核内SRAM、共享SRAM、L2缓存甚至还有软件管理的一级本地存储。如何组织这级存储就是硬件设计里特别考究的地方。很多AI芯片选择“软件管理的SRAM”也叫显式管理的片上内存来做一级存储因为编译器能精确知道数据和计算的时间关系可以把生命周期安排得明明白白。比起靠缓存一致性来自动搬运软件管理虽然编程难一些但性能和能耗都要好一个量级。我在某一次调研里对比过硬件管理缓存和软件管理SRAM的两款AI加速器设计方案。硬件管理那款的适配成本低一些任何模型拿来就能跑但片上是共享Cache经常出现矩阵搬运和激活搬运互踩带宽利用率只能到60%左右软件管理那款两个核之间就要认真划分SRAM分区一旦错了性能很糟糕但调通后带宽利用率可以到85%以上。对于追求极致性能和能效比的场景软件管理几乎是不可避免的选择。2.3 硬件接口如何服务编译器硬件给编译器提供的接口决定了软件栈的开发复杂度。这里讲的接口不是简单的寄存器访问而是硬件架构对编译器暴露的“编程模型”计算单元怎么组合、数据地址空间怎么组织、同步怎么处理、交错执行怎么表达。我见过一个很典型的接口设计陷阱把计算单元做成“黑盒”硬件内部自动处理数据重用和搬运编译器只需要发一条指令。听起来很美好但实际上软件栈完全不知道内部数据通路占用情况无法做精细的调度只能等硬件排队。更糟的是一旦模型比较复杂这种黑盒硬件的利用率就很不稳定。反过来接口暴露得太细也有问题编译器需要处理几百个微操作的依赖关系开发调度器的时间就会爆炸。好的硬件接口设计应该是一种“中间抽象”定义好计算子图coarse-grained micro-op让编译器可以把多个算子打包成一个大算子发射同时暴露有限的关键资源信息比如当前缓冲占用、阵列忙闲状态、带宽余量让运行时可以做出调度决策。这种设计才是真正的软硬件协同而不是硬件和软件各做各的。3. 软件侧编译器、运行时与算子库3.1 算子适配与指令集的抽象芯片的指令集或者说硬件原语确定后软件侧的第一项工作就是把深度学习算子映射到这些原语上。这里面最难的不是单算子映射而是算子之间的连接。编译器把多个算子翻译成指令序列时需要决定中间结果放在哪里、何时写回这直接决定数据搬运的总量。以常见的融合优化为例。Conv BN ReLU三个算子如果能融合成一个算子就不需要把Conv中间结果写回DDR再读回来跑BN再写回再读回来跑ReLU。这个融合看起来简单但需要硬件支持“在同一个计算过程中穿插多种操作”——比如Conv的输出直接留在片上SRAMBN的缩放因子在对应的计算单元权重寄存器里加载好ReLU的激活截断在输出路径上打开。算子库的设计也很考验功力。同一个卷积输入特征图尺寸不同、分支数不同、硬件通道数不同最优的实现方式往往完全不同。算子库不能只放一个通用版本而是要针对不同shape生成一个分档编译时再根据实际shape选优或者运行时在候选实现间做benchmark选优。我以前做某个图像超分模型部署时同一份UNet结构在输入尺寸是256x256和512x512时底层算子的最优实现截然不同。256时通道少数据直接放SRAM里用大tile跑最划算512时SRAM放不下必须拆成行卷积分块推进。这些决策如果全塞在运行时里做适配成本很高最好的做法是发版阶段就针对目标shape枚举一遍组合离线把kernel缓存好。这就是“离线调优运行时查表”的混合策略。3.2 调度和内存规划调度是软件栈里最像“操作系统”的部分。它要回答几个问题哪些算子可以并行、哪些算子必须串行、计算和搬运如何重叠、不同核之间如何分配任务。这些问题在AI芯片上尤其复杂因为通常有多个计算核、多个DMA通道、多层存储。一个成熟的调度策略需要考虑“计算与搬运重叠”compute/overlap transfer。比如某个算子上游的搬运和下游的计算可以并行调度器要能把一次迭代里的DMA搬运和MAC计算放在同一条流水线上。如果调度器做不到芯片的宏观利用率最多只能到50%。内存规划则是另一个大坑。AI模型的中间张量多到爆炸每层之间都要缓存。如果毫无章法地分配地址就会产生大量碎片和搬运。业内通用做法是“内存池 生命周期分析”编译器静态分析每个张量的生存期尽量把生存期不重叠的张量分配到同一块地址极大减少峰值内存占用。我印象很深的是一个语音唤醒项目模型很小参数量只有几十万但推理过程中间的特征图很多。一开始直接按顺序分配内存峰值内存飙到几MB根本塞不进只有512KB SRAM的芯片。后来用生命周期分析做内存复用峰值直接压到300KB以下模型就部署进去了。这件事让我意识到内存规划不是凑合着给Tensor分个地址那么简单它几乎是决定芯片任务能不能跑通的生死线。3.3 软硬件接口规范的落地实践很多团队做AI芯片软硬件设计最后一个环节才考虑“接口规范”文档这是不对的。接口规范要跟芯片架构定义同步做。因为硬件实现一旦成型改接口的代价极大软件栈如果等到流片后再开始适配又会拖半年。接口规范至少要包含指令/微操作编码、数据地址空间划分、寄存器定义、中断/事件机制、调试与性能计数器的访问方法、对不同算子的支持矩阵。最关键的是“支持矩阵”它写明哪些算子、哪些shape、哪些精度组合是官方保证的未列出的组合属于“尽力而为”甚至“不支持”。有了这个矩阵硬件团队可以集中精力把核心路径做稳软件团队也有明确的交付边界。接口规范里还有一个容易被忽略的内容错误码与诊断机制。AI芯片部署现场最怕的就是“芯片不干活但也不报错”。硬件设计时就要考虑把所有关键路径上的超时、溢出、带宽拥塞等异常情况抓出来通过可读的错误码反馈给运行时。这一条做好后续的工程排查会节省大量时间。4. 实操一个卷积算子的软硬件协同调优全流程4.1 从参考模型到芯片映射下面用一个真实的场景来梳理整个软硬件协同调优的流程。假设我们要在一颗带有2个MAC阵列核、每核16x16阵列、片上SRAM一共1MB的AI芯片上部署一个ResNet-18模型的第一个卷积层输入特征图224x224x3卷积核3x3输出通道64。第一步把卷积算子的计算方式按芯片硬件特点改写。16x16的MAC阵列一次可以算16个输出通道对应的16个像素位置。最直观的映射是把输入按滑窗展开成矩阵然后做矩阵乘。但im2col展开会浪费大量内存所以实践里更多是“隐式im2col”——在DMA搬运时就按滑窗格式把数据排好计算单元直接消费搬来的数据块展开不落内存。这一步的关键在于让硬件的数据搬运模块支持滑窗搬运模式。如果硬件不支持那im2col展开就不可避免带宽浪费会吃掉几乎所有性能优化空间。这也是为什么说软硬件设计必须一起做——im2col是否隐式不是编译器能单独决定的。4.2 参数、缓冲、循环切分第二步确定tiling策略。把224x224x3的输入和64个3x3x3的卷积核切成多个tile。首先看SRAM容量1MB要同时容纳输入tile、权重tile、输出tile。以32x32输出通道块为例输出tile是32x32x4字节假设FP32 4KB权重tile是3x3x3x32x4字节 3.4KB输入tile在滑窗下需要多一行多一列的halo区域大约是34x34x3x4 13.8KB。单看这一轮完全够放。但这只是静态容量。真正的问题是要把“读取输入→搬运进SRAM→MAC计算→搬运输出”这一连串动作做成流水。理想情况下用双缓冲double buffering让DMA搬运下一块数据的同时MAC在算当前块。这样计算单元不被饿着带宽也能持续被消费。这一步的参数选择会直接影响性能tile设太大SRAM吃不消tile设太小DMA启动开销占比变大流水容易断流。我建议的做法是先按“SRAM容量的一半作为最大tile容量”起手再逐步加大tile观察DMA搬运占比的变化直到性能出现拐点。4.3 性能测试与迭代第三步跑性能测试对比预期收益。AI芯片常说的“理论算力”和“实际利用率”差距可以非常大。如果理论算力是2 TOPS实际跑到1 TOPS利用率50%这在很多真实部署里已经算不错了但要是只跑到0.4 TOPS那肯定有问题。通常的第一个瓶颈是DMA带宽。计算需要的数据量是固定的如果DMA不能按时把数据送到MAC阵列MAC就只能空转。排查方法很简单看芯片提供的性能计数器比如total_mac_cycles和total_dma_cycles如果MAC的空闲周期占比很高说明搬运没跟上如果DMA的空闲很高说明计算密度不够。其次是数据复用率。卷积核和输入图上有很多数据是可以重用的。如果复用率只有1意味着每次乘加都从DDR取数这种设计几乎不可能跑出高性能。合理的复用率至少要做到几十倍也就是算一次输出块需要读取的数据量只有输出数据量的几十分之一。我调上面那个ResNet-18场景时第一版利用率只有34%。后来发现是输入的行halo反复被加载重复搬了3次。通过调整tile顺序让同一行的halo数据在一个tile内被多次消费利用率提高到了67%。再往后把DMA和计算做成真正重叠提升了82%。余下部分主要是BN融合和算子边界的数据搬运动作涉及的范围会更广需要软件栈整体的融合优化才能突破。5. 常见问题与排查技巧实录5.1 性能不符合预期的排查路径性能不达预期是AI芯片部署最多的问题。它跟软件Bug不一样往往是多个因素叠加的结果。建议按固定的排查顺序来先看带宽再看计算利用率再看调度流水。如果DMA带宽利用率很高但MAC利用率不高说明有数据依赖或同步等待问题如果两者都不高说明可能是输入数据量太大比如tile切太小、DMA启动开销占满或是算子实现本身选错。我的经验速查表如下现象优先排查项方向MAC利用率低但带宽跑满调度中计算与搬运未重叠引入双缓冲/多级流水带宽和MAC利用率双低tile过小DMA启动开销占比高加大tile增加数据复用特定shape性能骤降硬件不支持对应access模式检查是否触发了算子回退路径多核并行效率低核间任务分配不均或同步开销采用静态负载均衡或异步push调度内存占用超SRAM容量张量生命周期未复用引入内存池和生命周期分析5.2 算子和模型兼容性问题模型部署时最常见的兼容性问题有三个算子缺失、精度下降、动态shape不支持。算子缺失最直接的解决方法是所谓“算子分解”把一个不支持的算子拆成多个支持的算子组合。比如硬件不支持softmax可以先在硬件上算最大值做减法再用多项式近似算exp最后通过规约操作做除法。这样性能略差但至少能跑通。精度下降则要重点检查量化方式。后训练量化里最怕的是激活值分布不均匀。建议对每层做激活值统计看哪个层跨太大单独给那层设置较大的缩放因子如果还是损失过大干脆把那层切成FP16跑。动态shape是部署里最头疼的因为它的影响是全局的分配器要按最大规模预留内存调度器不能做太多离线决策。建议在硬件设计阶段就把shape动态性约束住比如只允许输入宽度维度可变其他维度固定。这样编译器可以把大多数调度做离线运行时只剩最简分支。5.3 架构成熟度带来的连锁问题做AI芯片项目时间长了会看到一种现象第一版芯片软件栈还没成熟就量产各种问题集中爆发。硬件bug可以通过芯片号errata规避但编译器问题很难绕。我建议AI芯片团队在一开始就要立一个习惯软件栈和硬件验证并行开发流片前用模拟器完整跑通目标模型的前向推理而不是等芯片回来才开始联调。最容易被忽略的是“性能回退测试”。模型适配时每一次算子实现改动都要做全量性能回归。我见过一个团队为了修一个sum算子的边界Bug往里面加了一条分支判断结果这个sum算子被很多模型频繁调用整体性能直接下降15%。如果不做回归测试这种问题能在线上潜伏很久。最后还想提一件事AI芯片的软硬件设计里最值钱的不是某个黑科技加速器而是“脏活累活”的工程积累——算子库的覆盖逃逸、内存分配的合理约束、调试工具的丰富程度。这些看起来不性感但恰恰是决定一个芯片产品能不能在客户那里跑起来的关键。希望这篇能把软硬件协同这一点讲清楚大家少踩些坑。