1. AI芯片软硬件协同设计的整体思路拆解1.1 为什么软硬件必须一起设计很多人第一次接触AI芯片会下意识把它当成一个“更快的GPU”或者“专门跑矩阵乘法的加速器”。这个理解不算错但只停留在表面。真正决定一颗AI芯片能不能用、好不好用的不是峰值算力而是软硬件之间的配合程度。我打个比方硬件像是高速公路软件像是交通规则和车辆调度系统。如果只修了八车道的高速却没有配套的导航、限速、匝道管理那车照样堵死。AI芯片也一样算力再高如果编译器映射不好、算子库覆盖不全、内存调度跟不上实际跑出来的有效算力可能连峰值的30%都不到。所以“AI芯片的软硬件设计”这个命题核心不是分别讲硬件怎么设计、软件怎么写而是讲两者如何在架构定义阶段就互相约束、互相成就。这也是为什么现在主流AI芯片团队里架构师、编译器工程师、算子库工程师往往是坐在一起开会的而不是各做各的。1.2 从应用场景反推设计约束做AI芯片设计第一步不是画架构图而是明确目标场景。不同场景对软硬件的诉求差异极大我列一个常见的对照场景类型典型负载硬件侧重软件侧重云端训练大模型预训练、微调高带宽内存、大规模互联、高精度支持分布式通信库、自动并行、图优化云端推理推荐、搜索、生成式推理低延迟、批处理效率、量化支持运行时调度、动态shape、算子融合边缘推理视觉检测、语音唤醒低功耗、小面积、定点运算轻量运行时、模型压缩工具链终端SoC拍照增强、实时翻译异构集成、内存共享NPU调度、多核协同这张表不是让你背而是让你理解一个逻辑场景决定约束约束决定架构架构决定软件栈的形态。比如边缘场景功耗卡得死那硬件可能只支持INT8甚至INT4软件就必须配套量化训练和量化部署工具云端训练要求高精度硬件支持FP16/BF16甚至FP32软件就要做混合精度和梯度累积。我见过一些团队硬件先做完了再找软件团队“适配一下”结果发现硬件不支持某个关键算子或者内存布局对编译器极不友好最后只能改硬件或者绕路实现代价非常大。所以我的经验是架构定义阶段软件团队必须有一票否决权。1.3 软硬件协同的分层模型为了把问题讲清楚我把AI芯片的软硬件栈分成四层来看硬件层计算阵列、片上存储、互联总线、外设接口驱动与运行时层设备管理、内存分配、任务调度、同步机制编译与图优化层计算图解析、算子融合、内存规划、指令生成框架与算子层训练框架对接、推理引擎、算子库实现这四层里编译与图优化层是软硬件协同的“咽喉”。它往上要理解框架的计算图语义往下要生成硬件能执行的指令序列。很多性能问题根源不在硬件算力不够而在这一层没有做好。举个例子一个Transformer模型里有大量的矩阵乘、LayerNorm、Softmax、残差连接。如果编译器能把LayerNorm和前面的矩阵乘融合成一个kernel就能省掉一次中间结果的写回和读取带宽消耗直接降下来。但如果硬件不支持这种融合后的指令模式或者片上存储不够放中间结果融合就做不了。这就是典型的软硬件协同问题。2. 核心细节解析与实操要点2.1 计算阵列的设计取舍AI芯片的计算阵列主流方案有几种脉动阵列、SIMD/SIMT阵列、可重构数据流架构。每种方案背后都有软硬件协同的考量。脉动阵列的优点是数据复用率高适合规则的大矩阵运算。但它的缺点是灵活性差遇到非规则计算或者稀疏计算效率会掉得很厉害。所以用脉动阵列的芯片软件层通常要配套做大量的图重写和算子融合把计算尽量规整化。SIMT阵列更灵活编程模型接近GPU软件栈相对成熟。但它的能效比通常不如脉动阵列因为指令调度和寄存器访问的开销更大。用这种架构软件层要重点做的是线程块划分、共享内存优化、指令级并行挖掘。可重构数据流架构介于两者之间硬件可以根据计算图动态配置数据通路。这种架构对编译器的要求最高因为编译器不仅要生成指令还要生成配置信息。但它的潜力也最大理论上可以逼近脉动阵列的能效同时保持较好的灵活性。我在实际项目中接触过脉动阵列和SIMT两种方案一个深刻的体会是硬件阵列的维度、数据位宽、片上存储大小这三个参数一旦定下来软件优化的天花板就基本确定了。比如阵列是128x128那单次矩阵乘的最大规整维度就是128超过这个尺寸就要做分块分块就会带来额外的数据搬运。所以架构师在定这些参数时必须让软件团队拿真实模型来跑模拟看分块带来的开销占比多少。2.2 片上存储的层次与分配策略AI芯片的片上存储通常分几级寄存器文件、片上SRAM也叫共享内存或本地内存、全局缓存。层级越多软件管理的复杂度越高但能效和带宽的优化空间也越大。这里有一个关键的设计决策片上SRAM是做统一编址还是独立编址。统一编址的好处是编程简单编译器不用关心数据在哪块存储坏处是容易产生bank冲突而且容量扩展性差。独立编址的好处是可以针对不同数据做精细化管理坏处是编译器要负责数据搬运增加了编译复杂度。我个人的经验是对于训练芯片统一编址更友好因为训练的计算图复杂多变编译器很难提前知道每块数据的最佳存放位置。对于推理芯片独立编址更常见因为推理的计算图相对固定可以离线做好内存规划。内存分配策略上有一个常见的坑中间结果的复用。很多计算图里某些张量用完一次就不再用了如果编译器能识别出来把这块内存回收给后面的张量用就能显著降低内存占用。但这件事做起来不容易因为要分析张量的生命周期还要考虑并行执行时的依赖关系。我见过一些编译器为了保险起见不做内存复用结果片上存储不够只能把中间结果写到片外带宽直接爆炸。实操心得在架构模拟阶段一定要让编译器团队提供“内存复用率”这个指标。如果复用率低于50%说明要么计算图本身有问题要么编译器的生命周期分析不够强需要回头优化。2.3 算子库的覆盖与性能平衡算子库是软件栈里最“接地气”的部分因为框架和用户直接调用它。算子库的设计有两个核心问题覆盖多少算子和每个算子优化到什么程度。覆盖度方面训练场景通常需要支持几百个算子推理场景可能只需要几十个核心算子。但这不是绝对的因为模型结构在快速演进今天不常用的算子明天可能就变成核心算子。所以算子库的架构要可扩展新增一个算子的成本要低。性能方面不是所有算子都值得花大力气优化。按照二八原则20%的算子占据了80%的运行时间。通常来说矩阵乘、卷积、注意力机制、LayerNorm、Softmax这几个是重点。但具体哪些是重点要看目标场景的模型分布。我参与过一个推理芯片的算子库建设一开始团队想每个算子都做到极致结果进度严重滞后。后来调整策略先保证核心算子的性能达到硬件峰值的70%以上非核心算子先保证功能正确性能后续迭代。这个策略让项目按时交付而且用户反馈也不错因为用户真正在意的就是那几个核心算子的性能。算子类别优化优先级常见优化手段目标性能矩阵乘/卷积最高分块、双缓冲、指令重排峰值70%以上注意力机制高算子融合、FlashAttention思路峰值60%以上LayerNorm/Softmax中向量化、减少同步带宽瓶颈的80%元素级运算低融合进前后算子功能正确即可2.4 编译器的图优化与指令生成编译器是软硬件协同的“翻译官”它要把框架的计算图翻译成硬件能执行的指令。这个过程中图优化和指令生成是两个核心环节。图优化包括常量折叠、死代码消除、算子融合、内存规划、并行调度。其中算子融合对性能影响最大也最难做好。融合的难点在于融合后的算子要能高效地在硬件上执行不能因为融合导致寄存器溢出或者片上存储不够。指令生成包括指令选择、寄存器分配、指令调度。这部分和传统编译器后端类似但AI芯片的指令集通常有大量定制指令比如矩阵乘指令、向量化指令、数据搬运指令。编译器要能识别出计算图中的模式映射到这些定制指令上。我踩过的一个坑是编译器的指令调度没有考虑硬件的流水线深度导致指令之间产生了不必要的停顿。后来在编译器里加了一个流水线模型让调度器知道每条指令的延迟和吞吐性能直接提升了15%。这件事让我意识到编译器团队必须对硬件微架构有深入理解不能只把它当成一个黑盒。3. 实操过程与核心环节实现3.1 从模型到硬件的完整链路搭建假设我们要为一颗新的AI推理芯片搭建软硬件链路目标场景是视觉检测模型。整个链路可以分成以下几个步骤第一步模型接入与图解析。选择一个主流推理框架作为前端把模型转换成框架的中间表示。这一步的关键是保证算子语义的正确映射特别是那些有特殊行为的算子比如带padding的卷积、带mask的注意力。第二步图优化与算子融合。在中间表示上做常量折叠、算子融合、布局转换。布局转换很重要因为框架通常用NCHW或NHWC而硬件可能对某种布局更友好。这一步要结合硬件的内存访问特性来做决策。第三步内存规划与指令生成。根据融合后的计算图做张量生命周期分析分配片上存储和片外存储。然后生成硬件指令序列包括计算指令和数据搬运指令。第四步运行时调度与执行。运行时负责加载指令、管理设备内存、调度任务到硬件队列。对于多核芯片还要做核间同步和负载均衡。第五步性能分析与迭代。用性能分析工具采集每个算子的执行时间、带宽利用率、计算利用率找出瓶颈回到第二步或第三步做优化。这个链路听起来线性实际是迭代的。我通常会在第二步和第三步之间来回好几轮因为融合策略变了内存规划也要跟着变。3.2 关键参数的计算与选择在实操中有几个关键参数需要计算和选择我拿一个具体的例子来说明。假设硬件有128x128的脉动阵列片上SRAM有4MB片外带宽是256GB/s目标模型是一个ResNet-50的变体。分块大小的选择矩阵乘的分块大小要同时考虑阵列维度、SRAM容量和带宽。如果分块太大SRAM放不下分块太小数据复用率低带宽压力大。计算方法是假设分块为MxNxK需要存储A块MxK和B块KxN总存储需求是(MxK KxN) x 数据位宽。对于FP164MB SRAM最多能放约200万个元素。如果MN128K64那么A块和B块各需要128x648192个元素总共16384个元素远小于200万所以SRAM不是瓶颈。但实际中还要考虑双缓冲和多级流水所以通常会留出2-3倍的余量。带宽需求的计算如果分块是128x128x64每次计算需要加载A块和B块共16384个元素FP16下是32KB。计算量是128x128x64x22M FLOPs。如果硬件算力是10 TFLOPS那么这次计算需要0.2微秒。在这0.2微秒内要传输32KB数据带宽需求是32KB/0.2us160GB/s。如果片外带宽只有256GB/s那带宽利用率就是62.5%还算合理。但如果分块变小比如64x64x64数据量不变但计算量降到0.5M FLOPs时间变成0.05微秒带宽需求就变成640GB/s超过片外带宽了。所以分块不能太小否则带宽会成为瓶颈。量化位宽的选择视觉检测模型通常对精度不是极度敏感INT8量化一般能保持99%以上的精度。但如果模型里有大量小数值的激活INT8可能会溢出或者精度损失严重。这时候可以考虑混合量化对敏感层用INT16其他层用INT8。选择的方法是先做INT8全量化跑验证集看精度掉多少如果掉超过1%就逐层分析找出敏感层对它们用更高位宽。3.3 一个算子融合的实操案例我拿“卷积BNReLU”这个经典组合来演示算子融合的实操过程。在框架的计算图里这三个是独立的算子。如果不融合执行流程是卷积写结果到内存BN读结果、计算、写回内存ReLU再读、计算、写回。三次内存读写带宽消耗大。融合后的算子在卷积计算完一个输出块后直接在寄存器或片上SRAM里做BN和ReLU然后只写一次最终结果到内存。这样内存读写从三次变成一次带宽消耗降到三分之一。但融合不是免费的。BN需要计算均值和方差这些统计量在训练时是动态的推理时是固定的。所以推理阶段的融合相对简单把BN的参数提前算好融合进卷积的权重和偏置里。训练阶段的融合就复杂了因为BN的统计量在每次迭代后都会变不能提前融合。实操中我通常这样做在推理编译器的图优化阶段识别“ConvBNReLU”模式。把BN的缩放和平移参数合并到卷积的权重和偏置中。具体公式是如果卷积输出是y Wx bBN是y gamma(y - mean)/sqrt(var eps) beta那么合并后的权重是W W * gamma/sqrt(vareps)偏置是b (b - mean)*gamma/sqrt(vareps) beta。把ReLU作为激活函数附加在卷积算子后面在写回结果前做max(0, x)操作。生成融合后的指令序列确保中间结果不写回片外内存。这个融合在大多数硬件上都能带来1.5到2倍的性能提升是性价比最高的优化之一。注意事项融合后的算子要保证数值稳定性。BN的eps不能太小否则除零风险ReLU的阈值要处理负数零的情况。这些细节在单独算子时可能不明显融合后容易出问题。4. 常见问题与排查技巧实录4.1 性能不达预期的排查思路性能问题是AI芯片软硬件协同中最常见的。我总结了一个排查顺序从顶层到底层逐级排查第一级模型层面。检查模型是否有异常大的算子或者异常小的算子导致调度开销占比过高。有时候一个模型里混了太多小算子每个算子执行时间只有几微秒但调度开销就有几十微秒整体性能就被拖垮了。解决办法是做算子融合或者批处理。第二级图优化层面。检查算子融合是否生效内存复用率是否达标布局转换是否引入了额外开销。我见过一个案例编译器为了对齐硬件要求把NHWC转成NCHW结果转换本身消耗了20%的时间。后来发现硬件其实支持NHWC只是编译器默认配置没开。第三级指令生成层面。检查是否有寄存器溢出、指令流水线停顿、数据搬运指令过多。用性能分析工具看指令级的执行情况找出停顿最多的位置。第四级硬件层面。检查计算阵列利用率、内存带宽利用率、功耗和频率是否正常。如果计算阵列利用率低但带宽利用率高说明是内存瓶颈反之则是计算瓶颈。这个排查顺序的好处是从软件到硬件逐级深入避免一上来就怀疑硬件有问题。实际上我遇到过的性能问题里70%以上都能在软件层面解决。4.2 精度问题的定位与修复精度问题比性能问题更难排查因为它往往不是“全对”或“全错”而是“差一点”。常见的精度问题来源有量化误差INT8量化的舍入误差累积导致最终输出偏差。算子实现差异不同框架对同一个算子的数值行为定义不同比如除零处理、溢出处理。融合引入的误差算子融合后中间结果的精度可能降低。并行计算的重排误差浮点加法不满足结合律并行归约的顺序不同会导致结果不同。定位精度问题我通常用“逐层对比法”把硬件上的每一层输出和参考实现通常是CPU上的高精度实现做对比找出误差最大的层。然后针对这一层分析是量化问题、实现问题还是融合问题。修复手段包括对敏感层提高量化位宽、调整融合策略、修改算子实现以匹配参考语义、使用确定性归约算法。其中确定性归约在训练场景特别重要因为训练对数值的微小差异很敏感不确定的归约顺序可能导致训练不收敛。4.3 常见问题速查表问题现象可能原因排查方法解决手段性能只有峰值30%内存带宽瓶颈看带宽利用率增大分块、提高数据复用某些算子特别慢算子未优化或未融合逐算子计时优化算子或做融合精度掉超过1%量化误差或实现差异逐层对比混合量化、修正实现多核利用率不均负载划分不合理看各核执行时间重新划分任务或动态调度运行时报内存不足内存规划不合理看内存占用峰值优化生命周期分析、增加复用训练不收敛归约不确定性或梯度误差对比CPU训练确定性归约、提高精度4.4 几个容易忽视的避坑技巧第一个坑编译器的默认配置不一定最优。很多编译器有一套默认的优化策略但默认策略通常是保守的为了保证正确性牺牲了性能。我建议在项目初期就花时间调编译器的配置参数比如融合级别、分块大小、并行度。这些参数调好了性能提升可能比改硬件还明显。第二个坑算子库的边界情况。算子库在标准输入上表现很好但遇到边界情况比如空张量、超大张量、非对齐尺寸可能就崩了或者性能骤降。我建议在算子库开发阶段就建立边界测试集覆盖各种极端情况。第三个坑硬件模拟器和真实硬件的差异。很多团队在模拟器上做性能评估但模拟器通常简化了内存延迟、流水线冲突、功耗限制等因素。模拟器上跑出来80%的利用率真实硬件上可能只有50%。所以尽早流片或者用FPGA原型验证不要等到最后才发现性能不达标。第四个坑软件栈的版本管理。AI芯片的软件栈通常包含驱动、运行时、编译器、算子库、框架插件等多个组件版本之间的兼容性很容易出问题。我建议用统一的版本管理工具把整个软件栈作为一个整体来发布和测试而不是各组件独立发版。第五个坑忽视端到端的用户体验。芯片设计团队往往关注单个算子的性能但用户关心的是整个模型跑起来要多久、精度够不够、好不好用。所以除了算子级优化还要做端到端的模型级优化比如图级别的并行、流水线编排、动态shape支持。5. 软硬件协同的迭代方法论5.1 建立性能模型驱动设计在项目早期还没有真实硬件的时候建立一个性能模型是非常有价值的。这个模型不需要很精确但要能反映关键参数对性能的影响趋势。性能模型通常包括计算时间模型、内存访问时间模型、通信时间模型。计算时间模型根据阵列维度和指令吞吐来估算内存访问时间模型根据数据量和带宽来估算通信时间模型根据互联拓扑和消息大小来估算。有了这个模型架构师可以在参数空间里快速搜索找到帕累托最优的配置。软件团队也可以用这个模型来评估不同优化策略的潜在收益决定优先级。我参与过的一个项目在架构定义阶段用性能模型跑了上千种配置组合最终选定的配置比初始方案在目标模型上快了2.3倍。这个模型后来也一直用在整个开发过程中作为性能回归的基准。5.2 软硬件联合调试的流程当硬件原型比如FPGA可用后软硬件联合调试就开始了。这个阶段的流程通常是单算子验证逐个算子跑测试确保功能正确、性能符合预期。小模型验证用一个小型模型比如MobileNet跑端到端检查整体链路是否通畅。目标模型验证用真实的目标模型跑做性能和精度的全面评估。压力测试用多种模型、多种输入尺寸、多种批大小做压力测试找出边界问题。回归测试每次软件栈更新后重新跑一遍测试集确保没有引入回归。这个流程里自动化测试框架是关键。手工测试效率太低而且容易漏。我建议从第一天就搭建自动化测试流水线把模型编译、执行、性能采集、精度对比都自动化。5.3 从项目经验中提炼的设计原则做了几个AI芯片项目后我提炼出几条设计原则供参考原则一软件团队早期介入。架构定义阶段就要有软件团队参与对硬件参数提出约束。不要等硬件定型了再让软件适配。原则二以真实模型为基准。不要用合成负载或者玩具模型做评估要用目标场景的真实模型。真实模型的算子分布、内存访问模式、并行度都和玩具模型差别很大。原则三保留可编程性。硬件再专用也要保留一定的可编程能力以应对模型演进。完全固定的数据流架构遇到新模型可能就无能为力了。原则四工具链先行。在硬件流片之前编译器、模拟器、性能分析工具就要基本可用。否则硬件回来之后软件团队没有工具调试效率极低。原则五迭代优化不要追求一次完美。AI芯片的软硬件协同是一个长期迭代的过程。第一版可能只达到峰值性能的40%但通过持续优化可以逐步提升到70%甚至更高。关键是建立好迭代的机制和工具。我个人在实际操作中的体会是AI芯片项目失败的原因很少是硬件算力不够更多是软硬件协同没做好。硬件团队觉得软件团队优化不力软件团队觉得硬件团队设计不合理最后互相扯皮。解决这个问题的唯一办法就是让两个团队从一开始就坐在一起用共同的目标和语言来工作。
1. AI芯片软硬件协同设计的整体思路拆解1.1 为什么软硬件必须一起设计很多人第一次接触AI芯片会下意识把它当成一个“更快的GPU”或者“专门跑矩阵乘法的加速器”。这个理解不算错但只停留在表面。真正决定一颗AI芯片能不能用、好不好用的不是峰值算力而是软硬件之间的配合程度。我打个比方硬件像是高速公路软件像是交通规则和车辆调度系统。如果只修了八车道的高速却没有配套的导航、限速、匝道管理那车照样堵死。AI芯片也一样算力再高如果编译器映射不好、算子库覆盖不全、内存调度跟不上实际跑出来的有效算力可能连峰值的30%都不到。所以“AI芯片的软硬件设计”这个命题核心不是分别讲硬件怎么设计、软件怎么写而是讲两者如何在架构定义阶段就互相约束、互相成就。这也是为什么现在主流AI芯片团队里架构师、编译器工程师、算子库工程师往往是坐在一起开会的而不是各做各的。1.2 从应用场景反推设计约束做AI芯片设计第一步不是画架构图而是明确目标场景。不同场景对软硬件的诉求差异极大我列一个常见的对照场景类型典型负载硬件侧重软件侧重云端训练大模型预训练、微调高带宽内存、大规模互联、高精度支持分布式通信库、自动并行、图优化云端推理推荐、搜索、生成式推理低延迟、批处理效率、量化支持运行时调度、动态shape、算子融合边缘推理视觉检测、语音唤醒低功耗、小面积、定点运算轻量运行时、模型压缩工具链终端SoC拍照增强、实时翻译异构集成、内存共享NPU调度、多核协同这张表不是让你背而是让你理解一个逻辑场景决定约束约束决定架构架构决定软件栈的形态。比如边缘场景功耗卡得死那硬件可能只支持INT8甚至INT4软件就必须配套量化训练和量化部署工具云端训练要求高精度硬件支持FP16/BF16甚至FP32软件就要做混合精度和梯度累积。我见过一些团队硬件先做完了再找软件团队“适配一下”结果发现硬件不支持某个关键算子或者内存布局对编译器极不友好最后只能改硬件或者绕路实现代价非常大。所以我的经验是架构定义阶段软件团队必须有一票否决权。1.3 软硬件协同的分层模型为了把问题讲清楚我把AI芯片的软硬件栈分成四层来看硬件层计算阵列、片上存储、互联总线、外设接口驱动与运行时层设备管理、内存分配、任务调度、同步机制编译与图优化层计算图解析、算子融合、内存规划、指令生成框架与算子层训练框架对接、推理引擎、算子库实现这四层里编译与图优化层是软硬件协同的“咽喉”。它往上要理解框架的计算图语义往下要生成硬件能执行的指令序列。很多性能问题根源不在硬件算力不够而在这一层没有做好。举个例子一个Transformer模型里有大量的矩阵乘、LayerNorm、Softmax、残差连接。如果编译器能把LayerNorm和前面的矩阵乘融合成一个kernel就能省掉一次中间结果的写回和读取带宽消耗直接降下来。但如果硬件不支持这种融合后的指令模式或者片上存储不够放中间结果融合就做不了。这就是典型的软硬件协同问题。2. 核心细节解析与实操要点2.1 计算阵列的设计取舍AI芯片的计算阵列主流方案有几种脉动阵列、SIMD/SIMT阵列、可重构数据流架构。每种方案背后都有软硬件协同的考量。脉动阵列的优点是数据复用率高适合规则的大矩阵运算。但它的缺点是灵活性差遇到非规则计算或者稀疏计算效率会掉得很厉害。所以用脉动阵列的芯片软件层通常要配套做大量的图重写和算子融合把计算尽量规整化。SIMT阵列更灵活编程模型接近GPU软件栈相对成熟。但它的能效比通常不如脉动阵列因为指令调度和寄存器访问的开销更大。用这种架构软件层要重点做的是线程块划分、共享内存优化、指令级并行挖掘。可重构数据流架构介于两者之间硬件可以根据计算图动态配置数据通路。这种架构对编译器的要求最高因为编译器不仅要生成指令还要生成配置信息。但它的潜力也最大理论上可以逼近脉动阵列的能效同时保持较好的灵活性。我在实际项目中接触过脉动阵列和SIMT两种方案一个深刻的体会是硬件阵列的维度、数据位宽、片上存储大小这三个参数一旦定下来软件优化的天花板就基本确定了。比如阵列是128x128那单次矩阵乘的最大规整维度就是128超过这个尺寸就要做分块分块就会带来额外的数据搬运。所以架构师在定这些参数时必须让软件团队拿真实模型来跑模拟看分块带来的开销占比多少。2.2 片上存储的层次与分配策略AI芯片的片上存储通常分几级寄存器文件、片上SRAM也叫共享内存或本地内存、全局缓存。层级越多软件管理的复杂度越高但能效和带宽的优化空间也越大。这里有一个关键的设计决策片上SRAM是做统一编址还是独立编址。统一编址的好处是编程简单编译器不用关心数据在哪块存储坏处是容易产生bank冲突而且容量扩展性差。独立编址的好处是可以针对不同数据做精细化管理坏处是编译器要负责数据搬运增加了编译复杂度。我个人的经验是对于训练芯片统一编址更友好因为训练的计算图复杂多变编译器很难提前知道每块数据的最佳存放位置。对于推理芯片独立编址更常见因为推理的计算图相对固定可以离线做好内存规划。内存分配策略上有一个常见的坑中间结果的复用。很多计算图里某些张量用完一次就不再用了如果编译器能识别出来把这块内存回收给后面的张量用就能显著降低内存占用。但这件事做起来不容易因为要分析张量的生命周期还要考虑并行执行时的依赖关系。我见过一些编译器为了保险起见不做内存复用结果片上存储不够只能把中间结果写到片外带宽直接爆炸。实操心得在架构模拟阶段一定要让编译器团队提供“内存复用率”这个指标。如果复用率低于50%说明要么计算图本身有问题要么编译器的生命周期分析不够强需要回头优化。2.3 算子库的覆盖与性能平衡算子库是软件栈里最“接地气”的部分因为框架和用户直接调用它。算子库的设计有两个核心问题覆盖多少算子和每个算子优化到什么程度。覆盖度方面训练场景通常需要支持几百个算子推理场景可能只需要几十个核心算子。但这不是绝对的因为模型结构在快速演进今天不常用的算子明天可能就变成核心算子。所以算子库的架构要可扩展新增一个算子的成本要低。性能方面不是所有算子都值得花大力气优化。按照二八原则20%的算子占据了80%的运行时间。通常来说矩阵乘、卷积、注意力机制、LayerNorm、Softmax这几个是重点。但具体哪些是重点要看目标场景的模型分布。我参与过一个推理芯片的算子库建设一开始团队想每个算子都做到极致结果进度严重滞后。后来调整策略先保证核心算子的性能达到硬件峰值的70%以上非核心算子先保证功能正确性能后续迭代。这个策略让项目按时交付而且用户反馈也不错因为用户真正在意的就是那几个核心算子的性能。算子类别优化优先级常见优化手段目标性能矩阵乘/卷积最高分块、双缓冲、指令重排峰值70%以上注意力机制高算子融合、FlashAttention思路峰值60%以上LayerNorm/Softmax中向量化、减少同步带宽瓶颈的80%元素级运算低融合进前后算子功能正确即可2.4 编译器的图优化与指令生成编译器是软硬件协同的“翻译官”它要把框架的计算图翻译成硬件能执行的指令。这个过程中图优化和指令生成是两个核心环节。图优化包括常量折叠、死代码消除、算子融合、内存规划、并行调度。其中算子融合对性能影响最大也最难做好。融合的难点在于融合后的算子要能高效地在硬件上执行不能因为融合导致寄存器溢出或者片上存储不够。指令生成包括指令选择、寄存器分配、指令调度。这部分和传统编译器后端类似但AI芯片的指令集通常有大量定制指令比如矩阵乘指令、向量化指令、数据搬运指令。编译器要能识别出计算图中的模式映射到这些定制指令上。我踩过的一个坑是编译器的指令调度没有考虑硬件的流水线深度导致指令之间产生了不必要的停顿。后来在编译器里加了一个流水线模型让调度器知道每条指令的延迟和吞吐性能直接提升了15%。这件事让我意识到编译器团队必须对硬件微架构有深入理解不能只把它当成一个黑盒。3. 实操过程与核心环节实现3.1 从模型到硬件的完整链路搭建假设我们要为一颗新的AI推理芯片搭建软硬件链路目标场景是视觉检测模型。整个链路可以分成以下几个步骤第一步模型接入与图解析。选择一个主流推理框架作为前端把模型转换成框架的中间表示。这一步的关键是保证算子语义的正确映射特别是那些有特殊行为的算子比如带padding的卷积、带mask的注意力。第二步图优化与算子融合。在中间表示上做常量折叠、算子融合、布局转换。布局转换很重要因为框架通常用NCHW或NHWC而硬件可能对某种布局更友好。这一步要结合硬件的内存访问特性来做决策。第三步内存规划与指令生成。根据融合后的计算图做张量生命周期分析分配片上存储和片外存储。然后生成硬件指令序列包括计算指令和数据搬运指令。第四步运行时调度与执行。运行时负责加载指令、管理设备内存、调度任务到硬件队列。对于多核芯片还要做核间同步和负载均衡。第五步性能分析与迭代。用性能分析工具采集每个算子的执行时间、带宽利用率、计算利用率找出瓶颈回到第二步或第三步做优化。这个链路听起来线性实际是迭代的。我通常会在第二步和第三步之间来回好几轮因为融合策略变了内存规划也要跟着变。3.2 关键参数的计算与选择在实操中有几个关键参数需要计算和选择我拿一个具体的例子来说明。假设硬件有128x128的脉动阵列片上SRAM有4MB片外带宽是256GB/s目标模型是一个ResNet-50的变体。分块大小的选择矩阵乘的分块大小要同时考虑阵列维度、SRAM容量和带宽。如果分块太大SRAM放不下分块太小数据复用率低带宽压力大。计算方法是假设分块为MxNxK需要存储A块MxK和B块KxN总存储需求是(MxK KxN) x 数据位宽。对于FP164MB SRAM最多能放约200万个元素。如果MN128K64那么A块和B块各需要128x648192个元素总共16384个元素远小于200万所以SRAM不是瓶颈。但实际中还要考虑双缓冲和多级流水所以通常会留出2-3倍的余量。带宽需求的计算如果分块是128x128x64每次计算需要加载A块和B块共16384个元素FP16下是32KB。计算量是128x128x64x22M FLOPs。如果硬件算力是10 TFLOPS那么这次计算需要0.2微秒。在这0.2微秒内要传输32KB数据带宽需求是32KB/0.2us160GB/s。如果片外带宽只有256GB/s那带宽利用率就是62.5%还算合理。但如果分块变小比如64x64x64数据量不变但计算量降到0.5M FLOPs时间变成0.05微秒带宽需求就变成640GB/s超过片外带宽了。所以分块不能太小否则带宽会成为瓶颈。量化位宽的选择视觉检测模型通常对精度不是极度敏感INT8量化一般能保持99%以上的精度。但如果模型里有大量小数值的激活INT8可能会溢出或者精度损失严重。这时候可以考虑混合量化对敏感层用INT16其他层用INT8。选择的方法是先做INT8全量化跑验证集看精度掉多少如果掉超过1%就逐层分析找出敏感层对它们用更高位宽。3.3 一个算子融合的实操案例我拿“卷积BNReLU”这个经典组合来演示算子融合的实操过程。在框架的计算图里这三个是独立的算子。如果不融合执行流程是卷积写结果到内存BN读结果、计算、写回内存ReLU再读、计算、写回。三次内存读写带宽消耗大。融合后的算子在卷积计算完一个输出块后直接在寄存器或片上SRAM里做BN和ReLU然后只写一次最终结果到内存。这样内存读写从三次变成一次带宽消耗降到三分之一。但融合不是免费的。BN需要计算均值和方差这些统计量在训练时是动态的推理时是固定的。所以推理阶段的融合相对简单把BN的参数提前算好融合进卷积的权重和偏置里。训练阶段的融合就复杂了因为BN的统计量在每次迭代后都会变不能提前融合。实操中我通常这样做在推理编译器的图优化阶段识别“ConvBNReLU”模式。把BN的缩放和平移参数合并到卷积的权重和偏置中。具体公式是如果卷积输出是y Wx bBN是y gamma(y - mean)/sqrt(var eps) beta那么合并后的权重是W W * gamma/sqrt(vareps)偏置是b (b - mean)*gamma/sqrt(vareps) beta。把ReLU作为激活函数附加在卷积算子后面在写回结果前做max(0, x)操作。生成融合后的指令序列确保中间结果不写回片外内存。这个融合在大多数硬件上都能带来1.5到2倍的性能提升是性价比最高的优化之一。注意事项融合后的算子要保证数值稳定性。BN的eps不能太小否则除零风险ReLU的阈值要处理负数零的情况。这些细节在单独算子时可能不明显融合后容易出问题。4. 常见问题与排查技巧实录4.1 性能不达预期的排查思路性能问题是AI芯片软硬件协同中最常见的。我总结了一个排查顺序从顶层到底层逐级排查第一级模型层面。检查模型是否有异常大的算子或者异常小的算子导致调度开销占比过高。有时候一个模型里混了太多小算子每个算子执行时间只有几微秒但调度开销就有几十微秒整体性能就被拖垮了。解决办法是做算子融合或者批处理。第二级图优化层面。检查算子融合是否生效内存复用率是否达标布局转换是否引入了额外开销。我见过一个案例编译器为了对齐硬件要求把NHWC转成NCHW结果转换本身消耗了20%的时间。后来发现硬件其实支持NHWC只是编译器默认配置没开。第三级指令生成层面。检查是否有寄存器溢出、指令流水线停顿、数据搬运指令过多。用性能分析工具看指令级的执行情况找出停顿最多的位置。第四级硬件层面。检查计算阵列利用率、内存带宽利用率、功耗和频率是否正常。如果计算阵列利用率低但带宽利用率高说明是内存瓶颈反之则是计算瓶颈。这个排查顺序的好处是从软件到硬件逐级深入避免一上来就怀疑硬件有问题。实际上我遇到过的性能问题里70%以上都能在软件层面解决。4.2 精度问题的定位与修复精度问题比性能问题更难排查因为它往往不是“全对”或“全错”而是“差一点”。常见的精度问题来源有量化误差INT8量化的舍入误差累积导致最终输出偏差。算子实现差异不同框架对同一个算子的数值行为定义不同比如除零处理、溢出处理。融合引入的误差算子融合后中间结果的精度可能降低。并行计算的重排误差浮点加法不满足结合律并行归约的顺序不同会导致结果不同。定位精度问题我通常用“逐层对比法”把硬件上的每一层输出和参考实现通常是CPU上的高精度实现做对比找出误差最大的层。然后针对这一层分析是量化问题、实现问题还是融合问题。修复手段包括对敏感层提高量化位宽、调整融合策略、修改算子实现以匹配参考语义、使用确定性归约算法。其中确定性归约在训练场景特别重要因为训练对数值的微小差异很敏感不确定的归约顺序可能导致训练不收敛。4.3 常见问题速查表问题现象可能原因排查方法解决手段性能只有峰值30%内存带宽瓶颈看带宽利用率增大分块、提高数据复用某些算子特别慢算子未优化或未融合逐算子计时优化算子或做融合精度掉超过1%量化误差或实现差异逐层对比混合量化、修正实现多核利用率不均负载划分不合理看各核执行时间重新划分任务或动态调度运行时报内存不足内存规划不合理看内存占用峰值优化生命周期分析、增加复用训练不收敛归约不确定性或梯度误差对比CPU训练确定性归约、提高精度4.4 几个容易忽视的避坑技巧第一个坑编译器的默认配置不一定最优。很多编译器有一套默认的优化策略但默认策略通常是保守的为了保证正确性牺牲了性能。我建议在项目初期就花时间调编译器的配置参数比如融合级别、分块大小、并行度。这些参数调好了性能提升可能比改硬件还明显。第二个坑算子库的边界情况。算子库在标准输入上表现很好但遇到边界情况比如空张量、超大张量、非对齐尺寸可能就崩了或者性能骤降。我建议在算子库开发阶段就建立边界测试集覆盖各种极端情况。第三个坑硬件模拟器和真实硬件的差异。很多团队在模拟器上做性能评估但模拟器通常简化了内存延迟、流水线冲突、功耗限制等因素。模拟器上跑出来80%的利用率真实硬件上可能只有50%。所以尽早流片或者用FPGA原型验证不要等到最后才发现性能不达标。第四个坑软件栈的版本管理。AI芯片的软件栈通常包含驱动、运行时、编译器、算子库、框架插件等多个组件版本之间的兼容性很容易出问题。我建议用统一的版本管理工具把整个软件栈作为一个整体来发布和测试而不是各组件独立发版。第五个坑忽视端到端的用户体验。芯片设计团队往往关注单个算子的性能但用户关心的是整个模型跑起来要多久、精度够不够、好不好用。所以除了算子级优化还要做端到端的模型级优化比如图级别的并行、流水线编排、动态shape支持。5. 软硬件协同的迭代方法论5.1 建立性能模型驱动设计在项目早期还没有真实硬件的时候建立一个性能模型是非常有价值的。这个模型不需要很精确但要能反映关键参数对性能的影响趋势。性能模型通常包括计算时间模型、内存访问时间模型、通信时间模型。计算时间模型根据阵列维度和指令吞吐来估算内存访问时间模型根据数据量和带宽来估算通信时间模型根据互联拓扑和消息大小来估算。有了这个模型架构师可以在参数空间里快速搜索找到帕累托最优的配置。软件团队也可以用这个模型来评估不同优化策略的潜在收益决定优先级。我参与过的一个项目在架构定义阶段用性能模型跑了上千种配置组合最终选定的配置比初始方案在目标模型上快了2.3倍。这个模型后来也一直用在整个开发过程中作为性能回归的基准。5.2 软硬件联合调试的流程当硬件原型比如FPGA可用后软硬件联合调试就开始了。这个阶段的流程通常是单算子验证逐个算子跑测试确保功能正确、性能符合预期。小模型验证用一个小型模型比如MobileNet跑端到端检查整体链路是否通畅。目标模型验证用真实的目标模型跑做性能和精度的全面评估。压力测试用多种模型、多种输入尺寸、多种批大小做压力测试找出边界问题。回归测试每次软件栈更新后重新跑一遍测试集确保没有引入回归。这个流程里自动化测试框架是关键。手工测试效率太低而且容易漏。我建议从第一天就搭建自动化测试流水线把模型编译、执行、性能采集、精度对比都自动化。5.3 从项目经验中提炼的设计原则做了几个AI芯片项目后我提炼出几条设计原则供参考原则一软件团队早期介入。架构定义阶段就要有软件团队参与对硬件参数提出约束。不要等硬件定型了再让软件适配。原则二以真实模型为基准。不要用合成负载或者玩具模型做评估要用目标场景的真实模型。真实模型的算子分布、内存访问模式、并行度都和玩具模型差别很大。原则三保留可编程性。硬件再专用也要保留一定的可编程能力以应对模型演进。完全固定的数据流架构遇到新模型可能就无能为力了。原则四工具链先行。在硬件流片之前编译器、模拟器、性能分析工具就要基本可用。否则硬件回来之后软件团队没有工具调试效率极低。原则五迭代优化不要追求一次完美。AI芯片的软硬件协同是一个长期迭代的过程。第一版可能只达到峰值性能的40%但通过持续优化可以逐步提升到70%甚至更高。关键是建立好迭代的机制和工具。我个人在实际操作中的体会是AI芯片项目失败的原因很少是硬件算力不够更多是软硬件协同没做好。硬件团队觉得软件团队优化不力软件团队觉得硬件团队设计不合理最后互相扯皮。解决这个问题的唯一办法就是让两个团队从一开始就坐在一起用共同的目标和语言来工作。
：Aquilon系统介绍)
实现原理)
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
