1. 从能跑就行到跑得高效AI芯片软硬件协同设计的核心命题做AI芯片这行的人都有一个共识硬件堆算力不难难的是让软件把硬件真正喂饱。我接触过不少团队芯片流片回来峰值算力标称几百TOPS结果实际跑一个主流检测模型利用率连30%都不到。问题出在哪几乎无一例外都是软硬件设计脱节——硬件按照理想模型设计软件按照通用框架适配中间那层翻译损耗巨大。这一篇要聊的就是AI芯片软硬件设计里最核心的那层协同逻辑。它不是一个具体的工具教程也不是某一款芯片的评测而是把为什么AI芯片必须软硬件一起设计协同设计到底在协同什么实际项目中怎么落地这几个问题讲透。适合正在做AI加速器架构的工程师、准备切入这个方向的软件开发者以及想理解芯片底层逻辑的算法同学。读完你至少能搞清楚一个矩阵乘法从算法描述到硬件执行中间要经过哪些层每一层有哪些设计选择以及这些选择如何反过来影响芯片的能效和面积。先给一个最直观的类比。AI芯片的软硬件设计很像一家餐厅的后厨。硬件是灶台、烤箱、切菜台软件是菜谱和厨师的操作流程。如果灶台只有一个大火口菜谱却要求同时炒三个菜那厨师再厉害也做不快。反过来如果灶台有八个火口但菜谱只教了一道炖菜那大部分火口就是浪费。协同设计的本质就是让菜谱和灶台互相迁就、互相成就——菜谱根据灶台的特点调整步骤灶台根据菜谱的需求增减设备。这个道理听起来简单但落到工程上涉及的东西非常多。下面我按实际项目中的思考顺序一层一层拆开讲。2. 算法层与硬件层的翻译损耗为什么通用处理器跑AI不划算2.1 从卷积到矩阵乘算法描述和硬件执行之间的鸿沟一个卷积神经网络里的卷积操作在算法层面写出来就是几行循环。但在硬件层面这几行循环要变成乘加运算阵列的调度、片上缓存的读写、数据在计算单元之间的搬运。这中间的翻译过程就是损耗的来源。我拿一个具体的例子来说明。假设有一个3x3的卷积层输入特征图是56x56x64输出通道也是64。算法层面这就是一个标准的卷积。但硬件层面你要考虑这64个输出通道是并行算还是串行算3x3的窗口是展开成9个乘加还是用滑窗复用输入特征图能不能全部放在片上缓存里如果放不下怎么分块不同的选择对应的硬件面积、功耗、延迟完全不同。通用处理器之所以跑AI不划算就是因为它的硬件结构是为通用设计的没有针对这些选择做任何优化。它不知道下一个指令是卷积还是分支跳转所以只能保守地设计流水线导致大量晶体管花在了通用性上而不是算力上。2.2 数据复用AI计算真正的瓶颈不在算力很多人以为AI芯片的瓶颈是算力不够其实在实际项目中瓶颈往往是数据搬运。一个乘加运算消耗的能量远小于从DRAM读一个数消耗的能量。有研究数据表明在同等工艺下一次DRAM访问的能耗大约是一次乘加运算的200倍以上。这意味着如果你能让数据在片上多复用一次省下来的能耗比优化计算单元本身更可观。这就是为什么AI芯片设计里数据复用是核心命题。卷积神经网络有一个天然优势权重可以复用输入特征图也可以复用。一个3x3的卷积核在特征图上滑动时同一个权重被用了很多次。硬件设计要做的就是把这个复用机会抓住让数据尽量留在片上减少对DRAM的访问。具体怎么做常见的手段包括把权重固定在片上缓存里反复使用把输入特征图分块加载后让多个输出通道共享以及设计专门的数据流架构让数据在计算阵列中流过而不是存取。这些手段的选择直接决定了芯片的能效比。2.3 软硬件接口的抽象层次从框架到指令集到微架构一个AI模型从训练框架到芯片执行中间要经过好几层抽象。最上面是框架层比如各种深度学习框架往下是图优化层做算子融合、常量折叠、量化再往下是编译层把图变成芯片能执行的指令序列最下面是微架构层指令在硬件上具体怎么调度。协同设计的关键是在这些层次之间找到合适的契约。如果契约定得太高比如直接让框架对接硬件那框架的每次更新都要重新适配硬件不现实。如果契约定得太低比如让编译器直接生成微架构级的控制信号那编译器的复杂度会爆炸。实际项目中比较常见的做法是在指令集层面定契约。芯片提供一套面向AI计算的指令集编译器负责把图变成指令序列硬件负责执行指令。这套指令集的设计就是软硬件协同的核心战场。指令集太复杂硬件解码开销大太简单编译器优化空间小。这个平衡点需要软硬件团队反复迭代才能找到。3. 数据流架构的选择权重 stationary、输出 stationary 还是行 stationary3.1 三种经典数据流的工作机制与适用场景数据流架构是AI芯片设计里最核心的决策之一。它决定了计算阵列里的数据怎么流动、怎么复用。目前主流的有三种权重固定、输出固定、行固定。权重固定的思路是把卷积核的权重加载到计算单元里然后让输入特征图不断流过每个计算单元用固定的权重去乘不同的输入。这种方式的优点是权重复用率极高适合权重数量不大但输入特征图很大的场景。缺点是如果权重太多片上存不下就要频繁换权重反而增加开销。输出固定的思路是每个计算单元负责一个输出像素把对应的输入和权重都送进来算。这种方式适合输出通道多、需要并行累加的场景。缺点是输入和权重的复用率相对低对片上带宽要求高。行固定是前两者的折中把一行输入固定住让权重和输出在行内流动。它在复用率和灵活性之间取了一个平衡点适合卷积核尺寸中等、通道数适中的场景。我实际参与过的一个项目里团队一开始选了权重固定因为理论复用率最高。但实际跑下来发现模型里有些层的权重特别大片上缓存根本放不下导致频繁换权重性能反而下降。后来改成行固定虽然理论复用率低了一点但实际端到端性能提升了将近40%。这就是典型的理论最优不等于实际最优必须结合具体模型的结构来选。3.2 数据流选择如何反向影响编译器设计数据流架构一旦定了编译器的设计就要跟着走。比如选了权重固定编译器就要负责把权重提前加载到片上并且尽量让同一个权重在片上停留更久。这要求编译器对模型的层结构有全局视野不能一层一层独立编译。如果选了输出固定编译器就要重点优化输入和权重的加载顺序尽量让它们在时间上重叠减少计算单元的等待。这要求编译器有精细的调度能力能把加载指令和计算指令交错排布。软硬件协同在这里体现得特别明显硬件的数据流决定了编译器的优化方向而编译器的实际效果又反过来验证硬件设计是否合理。如果编译器怎么优化都达不到预期那很可能是硬件的数据流选错了需要回头改硬件。这种迭代在流片前可能要来回好几轮。3.3 实际项目中的数据流决策清单结合我自己的经验选数据流的时候可以按下面这个清单来评估评估维度权重固定输出固定行固定权重复用率高低中输入复用率中高中高片上缓存需求高中中编译器复杂度中高中适合的模型结构权重少、输入大输出通道多通用型实际能效表现依赖模型依赖带宽较均衡这个表不是绝对的只是一个参考框架。实际决策还要看目标模型的具体结构、片上缓存的容量、以及团队编译器的开发能力。我的建议是如果团队编译器能力一般优先选行固定它的容错空间最大。4. 量化与精度软硬件协同中最容易被低估的环节4.1 从FP32到INT8量化到底省了什么量化是AI芯片绕不开的话题。把浮点运算变成定点运算最直接的好处是计算单元的面积和功耗大幅下降。一个FP32的乘法器面积可能是一个INT8乘法器的十几倍。同时定点数据的位宽更小片上缓存和带宽的压力也相应减小。但量化不是简单地把浮点数截断成整数。它涉及到缩放因子的选择、零点偏移的处理、以及溢出保护。这些细节如果处理不好精度损失会非常明显。我见过一个项目量化后模型精度掉了将近10个百分点排查了半天才发现是某一层的缩放因子选得太大导致大量数值被截断到边界。软硬件协同在量化上的体现是硬件要提供合适的定点运算单元和累加器位宽软件要提供精确的量化算法和校准流程。两边必须对齐否则硬件算出来的结果和软件模拟的结果对不上调试起来非常痛苦。4.2 混合精度不同层用不同位宽的取舍逻辑现在很多AI芯片支持混合精度就是不同层用不同的位宽。比如卷积层用INT8全连接层用INT16某些敏感层甚至保留FP16。这样做的好处是在精度和效率之间取一个更好的平衡。但混合精度对软硬件协同的要求更高。硬件要支持多种位宽的计算单元并且能在它们之间灵活切换。软件要能自动分析每一层的精度敏感度决定用什么位宽。这个分析过程本身就很复杂需要大量的实验数据支撑。我个人的经验是混合精度的收益在模型结构差异大的时候最明显。如果整个模型都是同一种结构比如全是卷积那混合精度的收益有限反而增加了设计和调试的复杂度。但如果模型里既有卷积又有全连接还有注意力机制那混合精度就很有价值。4.3 量化校准中的实操坑与验证方法量化校准是实际项目中最容易出问题的地方。我总结几个常见的坑第一个坑是校准集的选择。校准集要能代表实际推理时的数据分布如果校准集和实际数据偏差太大量化参数就会失准。我一般建议校准集至少覆盖几百个样本并且要包含各种边界情况。第二个坑是逐层校准还是逐通道校准。逐通道校准精度更高但硬件实现更复杂。如果硬件只支持逐层校准那软件就要在量化算法上做补偿比如对权重做更精细的聚类。第三个坑是激活值的动态范围。有些层的激活值分布很集中有些层很分散。如果统一用一个缩放因子集中分布的层精度会很好分散的层就会很差。这时候可以考虑对不同的层用不同的缩放策略。验证量化效果的方法我一般用两步先在软件层面模拟量化后的推理结果和浮点结果对比看精度损失是否在可接受范围内然后在硬件上实际跑看硬件结果和软件模拟结果是否一致。如果两者不一致说明硬件的定点运算单元或者数据通路有问题需要进一步排查。5. 片上存储层次设计为什么缓存比计算单元更难做5.1 寄存器、SRAM、DRAM三级存储的带宽与延迟权衡AI芯片的存储层次一般分三级寄存器、片上SRAM、片外DRAM。寄存器的带宽最高、延迟最低但容量极小SRAM容量中等带宽和延迟也中等DRAM容量大但带宽有限、延迟高、功耗大。设计的难点在于怎么在这三级之间分配数据。计算单元需要的数据最好都在寄存器里但寄存器放不下就要放到SRAMSRAM也放不下就要放到DRAM。每一次往下一级走带宽和延迟都会变差。协同设计在这里的核心问题是编译器和硬件要一起决定哪些数据放在哪一级什么时候搬。如果硬件提供了很大的SRAM但编译器不会用那SRAM就是浪费。如果编译器想用SRAM但硬件没有提供足够的带宽那编译器也巧妇难为无米之炊。5.2 双缓冲与预取让计算单元不饿死的工程手段计算单元最怕的就是饿死——数据没到只能空转。为了避免这种情况常用的手段是双缓冲和预取。双缓冲的思路是把片上缓存分成两块一块给当前计算用另一块提前加载下一批数据。这样计算和加载可以重叠计算单元不用等数据。预取则是更进一步根据计算顺序提前把数据从DRAM搬到SRAM甚至从SRAM搬到寄存器。这些手段听起来简单但实际实现时有很多细节。比如双缓冲的切换时机太早切换会导致当前计算还没完成就换了缓冲太晚切换又起不到重叠的效果。预取的粒度也很讲究粒度太细预取指令的开销太大粒度太粗预取的数据可能用不上浪费带宽。我踩过的一个坑是预取逻辑没有考虑数据依赖结果预取的数据被后面的计算覆盖了导致计算单元读到错误的数据。这种bug在仿真阶段很难发现往往要到实际跑模型时才暴露出来。所以预取逻辑一定要做严格的依赖检查宁可保守一点也不要冒险。5.3 存储带宽的估算方法一个实际项目的计算过程存储带宽的估算是AI芯片设计里必须做的功课。我拿一个实际项目的数据来演示一下估算过程。假设目标模型是一个典型的卷积网络峰值算力需求是10TOPS每秒10万亿次运算。每次运算需要读取两个操作数假设平均复用率是10那就是每10次运算需要读取一次新数据。这样算下来每秒需要读取的数据量是10TOPS除以10再乘以每次读取的数据量。如果每次读取1字节那就是每秒1TB的数据量。这个带宽需求片上SRAM很难单独满足必须靠DRAM补充。但DRAM的带宽是有限的比如LPDDR5的带宽大概在几十GB每秒的量级。这就意味着必须通过提高复用率来降低带宽需求。如果复用率能提高到100那带宽需求就降到每秒100GBDRAM就能勉强满足。这个估算过程告诉我们复用率是决定存储带宽需求的关键变量。硬件设计要提高片上缓存的容量和灵活性软件设计要优化数据流提高复用率。两边一起努力才能把带宽需求压到可实现的范围内。6. 编译器与指令集软硬件协同的合同怎么签6.1 指令集设计的粒度粗粒度算子 vs 细粒度微指令指令集是软硬件之间的合同。合同怎么签直接决定了协同的效率。粗粒度算子指令就是一条指令对应一个完整的算子比如做一次3x3卷积。这种指令的好处是编译器简单硬件解码也简单。缺点是灵活性差如果模型里出现了指令集不支持的算子就没法执行。细粒度微指令就是一条指令对应一个很小的操作比如从SRAM读一个数到寄存器。这种指令的好处是灵活任何算子都可以用微指令拼出来。缺点是编译器要做的优化非常多硬件解码的开销也大。实际项目中比较常见的做法是折中提供一组中等粒度的指令覆盖常见的算子模式同时保留一些微指令用于处理特殊情况。这样既保证了常见情况下的效率又保留了灵活性。6.2 编译器后端优化的三个关键pass编译器后端是软硬件协同最密集的地方。我重点讲三个关键pass。第一个是算子融合。把多个连续的算子合并成一个减少中间数据的搬运。比如卷积后面接一个激活函数如果分开做卷积的输出要写回SRAM激活再读出来。如果融合在一起卷积的输出直接送给激活省了一次读写。第二个是内存分配。决定每个张量放在哪一级存储、什么时候加载、什么时候释放。这个pass做得好不好直接决定了片上缓存的利用率。我见过一个编译器内存分配做得很粗糙导致SRAM利用率只有50%不到大量数据被挤到DRAM性能大打折扣。第三个是指令调度。决定指令的执行顺序让计算和加载尽量重叠。这个pass需要精确的时序模型知道每条指令的延迟和吞吐。如果时序模型不准调度出来的指令序列可能反而更慢。6.3 从图到指令一个卷积层的完整编译流程拆解我拿一个卷积层来演示完整的编译流程。假设输入是一个卷积层参数是3x3卷积核、输入通道64、输出通道128、特征图尺寸56x56。编译器的处理步骤大致如下第一步图优化。检查这个卷积层前后有没有可以融合的算子比如BN层或者激活函数。如果有就融合进来。第二步量化。根据校准数据确定这一层的输入、权重、输出的缩放因子和零点。把浮点参数转成定点。第三步分块。根据片上缓存的容量决定特征图和权重怎么分块。比如把输出通道分成4组每组32个通道分4次计算。第四步生成指令。为每个分块生成加载指令、计算指令、存储指令。计算指令可能是调用硬件提供的卷积指令也可能是用微指令拼出来。第五步调度。把这些指令按时间顺序排好尽量让加载和计算重叠。这个流程走下来一个卷积层可能生成几百条指令。这些指令在硬件上执行的时间就是这一层的实际延迟。如果编译器的分块策略或者调度策略不好延迟可能比理论值大好几倍。7. 流片前的软硬件联合验证怎么在仿真阶段发现问题7.1 功能验证与性能验证的分工流片前的验证分两块功能验证和性能验证。功能验证是确认硬件算出来的结果和软件模拟的结果一致。这个一般用仿真器做把编译出来的指令序列喂给硬件模型看输出对不对。功能验证要覆盖各种边界情况比如数据溢出、缓存冲突、指令异常等。性能验证是确认硬件跑模型的速度和能效达到预期。这个一般用性能模型做统计每条指令的周期数、每次访存的能耗然后累加出总的延迟和能耗。性能验证的关键是模型要准如果性能模型和实际硬件偏差太大验证结果就没有参考价值。7.2 联合仿真的效率问题与加速手段联合仿真的效率是个大问题。一个完整的模型可能有几百万条指令如果每条指令都精确仿真时间会非常长。我见过一个项目跑一次完整模型的仿真要十几个小时严重拖慢了迭代速度。加速的手段有几种。一种是采样仿真只仿真模型的一部分层然后按比例推算整体性能。这种方法的精度取决于采样的代表性如果采样层选得好误差可以控制在10%以内。另一种是抽象仿真把一些不关键的模块用高层模型代替只精确仿真关键路径。比如存储系统可以用统计模型代替只精确仿真计算阵列。还有一种是硬件加速仿真用FPGA或者专用仿真硬件来跑速度比软件仿真快几个数量级。但这种方法的前期投入比较大适合项目后期。7.3 常见软硬件不一致问题的排查思路软硬件不一致是流片前最头疼的问题。我总结几个常见的排查思路。如果功能验证发现输出不对先检查量化参数。量化参数不一致是最常见的原因软件用的缩放因子和硬件实际用的对不上结果就会偏差很大。如果量化参数没问题再检查数据通路的位宽。比如累加器的位宽不够导致中间结果溢出最终结果就会错。这种问题在仿真时可能被忽略因为仿真器可能用了更宽的位宽。如果功能和量化都没问题但性能不达标那就要检查调度和缓存。看看是不是有大量的缓存冲突或者加载和计算没有重叠好。这种问题一般需要看详细的性能剖析数据找到瓶颈在哪里。我的经验是软硬件不一致的问题80%出在量化参数和位宽上15%出在调度和缓存上剩下5%是其他奇怪的问题。所以排查的时候先查量化和位宽能省很多时间。8. 一些实际项目中的经验碎片做AI芯片软硬件协同设计这些年有一些零散的经验不成体系但我觉得挺有价值分享出来。第一个经验是不要过早优化。我见过一些团队芯片还没流片就开始抠编译器的每一个pass想把性能压到极致。结果流片回来发现硬件的某个模块有bug整个数据流都要改之前优化的编译器全部白做。正确的做法是先保证功能正确再逐步优化性能。第二个经验是软硬件团队要坐在一起。这不是说物理上坐在一起而是说两边的设计决策要互相透明。硬件团队要知道编译器在做什么优化软件团队要知道硬件的瓶颈在哪里。如果两边各做各的最后拼在一起大概率出问题。第三个经验是留足够的验证时间。流片前的验证时间永远不够用。我建议至少留出整个项目周期的三分之一来做验证。如果验证时间被压缩流片回来的风险会急剧上升。第四个经验是关注端到端指标不要只看单层。有些设计在单层上表现很好但端到端跑下来反而更差因为层与层之间的切换开销太大。所以评估任何设计决策都要看端到端的效果。第五个经验是保持对模型演进的敏感。AI模型的结构变化很快今天设计的芯片可能明年就过时了。所以在设计的时候要尽量留一些灵活性比如支持可配置的数据流、可扩展的指令集。这样即使模型变了芯片也能通过软件适配继续用。这些经验听起来都是常识但在实际项目中能真正做到的人不多。我自己也是踩了很多坑之后才慢慢把这些常识变成习惯。希望这些分享对正在做或者准备做AI芯片的朋友有一点帮助。