1. 为什么AI芯片的软硬件设计值得每一个做系统的人认真对待这两年跟同行聊天话题绕来绕去最后总会落到同一个地方模型越跑越大算力需求像坐了火箭可通用处理器那条路已经明显感觉到天花板了。于是大家不约而同地把目光投向专用芯片——也就是我们常说的AI加速器。但真正上手做过一轮之后你会发现AI芯片从来不是把矩阵乘法做快这么简单它是一个软硬件深度咬合的系统工程硬件决定了性能的上限软件决定了你能逼近这个上限到什么程度。我写这篇东西的出发点很直接。市面上讲AI芯片的文章要么停留在架构名词的罗列要么一头扎进某个具体电路细节里出不来中间那层到底怎么把软硬件捏合成一个能跑起来、跑得好的系统反而很少有人讲透。而这一层恰恰是绝大多数工程师真正会踩坑的地方。无论你是做数字前端、做编译器、做算子优化还是做系统集成的只要你的工作和让模型在专用硬件上高效跑起来沾边这篇内容都值得你花时间看完。我会从整体设计思路讲起把软硬件协同的核心逻辑拆开再落到具体的实操环节——包括数据流怎么设计、算子怎么映射、编译器怎么配合、性能怎么调优最后把我自己踩过的坑和排查思路整理成速查表。全程尽量说人话复杂的地方用类比能抄作业的地方直接给方案。核心关键词AI芯片、软硬件协同设计、数据流架构、算子映射、编译器后端、性能调优这些会贯穿全文。需要先说明一点下面涉及的具体参数、位宽、带宽数字都是基于行业常见实践给出的参考量级不是某个特定产品的规格。你拿去做方案设计时要结合自己的工艺节点、目标模型和成本约束重新算一遍但推导逻辑是通用的。2. 整体设计思路软硬件到底该怎么协同2.1 先想清楚一个根本问题这颗芯片为谁而造做AI芯片设计最容易犯的第一个错误就是一上来就讨论MAC阵列摆多大、SRAM放多少。这些问题当然重要但它们都是果不是因。真正的因是这颗芯片要服务哪一类模型、哪一类负载、哪一类部署场景。我习惯把AI芯片粗略分成三个象限来思考。第一个象限是训练芯片特点是需要高精度FP16/BF16甚至FP32、大容量片上存储、极高的互联带宽因为它要处理梯度同步、要支持大batch。第二个象限是云端推理芯片精度可以降到INT8甚至INT4吞吐优先batch可以做得比较大对延迟相对宽容。第三个象限是边缘推理芯片功耗和面积是硬约束batch通常就是1延迟敏感精度往往要压到INT8以下。这三个象限对硬件的要求几乎是互相矛盾的。训练芯片追求极致的算力和带宽功耗可以放到几百瓦边缘芯片可能整个芯片预算就几瓦你不可能给它堆一个几百乘几百的MAC阵列。所以软硬件协同设计的第一步是把目标场景钉死而不是做一个什么都能干的通用加速器——那种东西最后往往什么都干不好。提示如果你在项目早期就听到我们这个芯片训练推理通吃、云端边缘通吃基本可以判断这个项目还没想清楚定位。通吃的代价通常是每一项都不够极致而AI芯片这个赛道不够极致就等于没有竞争力。2.2 软硬件协同的本质把数据搬运这件事管好很多人以为AI芯片的性能瓶颈在计算其实在绝大多数实际负载里瓶颈在数据搬运。我做过一个粗略的统计在一个典型的卷积或矩阵乘负载里如果片上存储和计算单元之间的数据供给跟不上MAC阵列的利用率能低到20%以下。也就是说你花大价钱堆的算力八成时间在等数据。这就是为什么数据流架构Dataflow Architecture成了AI芯片设计的核心议题。所谓数据流说白了就是决定数据在片上怎么流动、在哪里复用、什么时候被消耗。经典的几种模式——权重固定Weight Stationary、输出固定Output Stationary、行固定Row Stationary——本质上都是在回答同一个问题哪一份数据值得被留在原地反复用哪一份数据必须不停地搬。举个生活化的类比。你开一家餐厅厨房是计算单元食材是数据。如果每做一道菜都要从仓库重新取一次所有食材那厨师大部分时间都在跑仓库炒菜的时间少得可怜。聪明的做法是把常用的调料权重放在灶台边片上缓存把当餐要用的主料输入特征一次性备好做出来的菜输出及时端走腾出操作台。数据流设计就是在规划这个灶台怎么摆、仓库多远、备菜节奏怎么定。2.3 一个可落地的设计流程框架基于上面的认知我把AI芯片软硬件协同设计整理成一条相对通用的流程后面几个章节会逐一展开负载分析确定目标模型集合统计算子类型分布、张量形状分布、访存特征。架构选型根据负载特征决定计算阵列规模、存储层次、数据流模式、精度支持范围。指令集与编程模型设计定义硬件对外暴露的抽象决定软件怎么写。编译器与算子库开发把高层模型映射到硬件指令做算子融合、内存分配、调度。性能建模与调优建立性能模型找到瓶颈迭代优化。软硬件联合验证用真实模型端到端跑通验证功能与性能。这条流程的关键在于它不是线性的。你在第5步发现的瓶颈很可能要回到第2步改架构你在第4步写编译器时遇到的表达困难可能说明第3步的指令集设计有问题。软硬件协同的精髓就在于让这些反馈回路尽可能短、尽可能早地暴露问题。3. 核心细节解析从计算阵列到存储层次的关键决策3.1 计算阵列MAC规模不是越大越好计算阵列是AI芯片的肌肉。最常见的做法是二维的脉动阵列Systolic Array每个周期数据在阵列里像波浪一样推进相邻的PE处理单元之间直接传递数据省去了大量的寄存器读写。这个设计的优雅之处在于它把数据复用这件事做到了硬件层面——一个权重进入阵列后可以被多个输入特征共享。但阵列规模怎么定这里有个容易被忽略的约束阵列越大对数据供给带宽的要求越高同时阵列边缘的利用率越低。假设你做一个128×128的阵列理论上每周期能算16384次乘加。但要喂饱它你每周期得送进来128个输入和128个权重。如果片上带宽不够阵列就会饿着。而且当矩阵维度不是128的整数倍时边缘那些PE就闲置了实际利用率会打折。我的经验是阵列规模要和目标模型的典型张量维度匹配。如果你主要跑的是BERT类模型隐藏层维度常见是768、1024这种那阵列维度选64或128比较自然如果你跑的是轻量级视觉模型通道数可能只有几十那大阵列就是浪费。先统计目标负载的维度分布再定阵列规模这个顺序不能反。3.2 存储层次片上存储是AI芯片的第二算力如果说计算阵列是肌肉那存储层次就是血管系统。AI芯片的存储通常分几层寄存器文件最快最小、片上SRAM较快较大、片外DRAM最慢最大。设计的核心矛盾是片上SRAM越大能复用的数据越多访存越少但面积和功耗也越高。这里有个很实用的估算方法。假设你的目标负载里某个算子的权重是W字节输入是I字节输出是O字节。如果片上SRAM能装下W那权重只需要从DRAM读一次之后反复复用如果装不下就要分块tiling每块权重都要重新读。分块带来的额外访存直接决定了你的能效比。我一般会这样算一笔账假设DRAM访问能耗是片上SRAM访问能耗的100倍这个量级在先进工艺下是合理的那么每减少一次DRAM访问就相当于省下了99次SRAM访问的能耗。所以在面积允许的前提下尽量把片上SRAM做大把能复用的数据留在片上这是AI芯片能效比的关键杠杆。注意片上SRAM不是越大越好它有个临界点。当SRAM大到一定程度面积开销会挤占计算阵列的空间而且大SRAM的访问延迟也会上升。通常的做法是做一个多级SRAM结构把最热的数据放在最小最快的那一级。3.3 精度与位宽省下来的每一位都是性能AI芯片相比通用处理器的一大优势就是可以针对AI负载的特点降低精度。训练用FP16/BF16推理用INT8甚至INT4、INT2。每降低一半位宽理论上计算吞吐翻倍、存储需求减半、带宽压力减半这是非常可观的收益。但降精度不是无脑降。INT8量化会带来精度损失需要通过量化感知训练QAT或者训练后量化PTQ来补偿。而且不同层对精度的敏感度不一样——第一层和最后一层通常比较敏感中间层可以压得更狠。所以混合精度是更实际的做法敏感层用高精度其余层用低精度。硬件上要支持这种灵活性就需要计算单元能处理多种位宽。一种常见做法是设计可重构的MAC比如一个支持INT8的MAC可以拆成两个INT4的MAC或者组合成INT16。这样同一套硬件能适应不同精度的需求灵活性大大提升。3.4 指令集与编程模型硬件对软件的承诺指令集是软硬件之间的契约。AI芯片的指令集通常比通用CPU简单得多因为它不需要处理复杂的控制流主要就是搬数据、算矩阵、做激活。但简单不代表好设计指令集的抽象层次直接决定了软件开发的难度和优化的空间。我见过两种极端。一种是抽象层次太低指令细到从SRAM地址A搬32字节到寄存器B程序员要手写大量搬运指令开发效率极低而且很容易写出低效代码。另一种是抽象层次太高一条指令就是一个完整的卷积硬件内部全自动程序员完全无法干预遇到特殊负载就抓瞎。比较合理的做法是分层暴露底层提供细粒度的搬运和计算指令供算子库开发者做极致优化上层提供粗粒度的算子指令供普通开发者快速上手。这样既保证了优化的天花板又降低了使用门槛。3.5 一个具体的参数估算示例为了让你对上面的讨论有个量化的感觉我拿一个假设的边缘推理场景算一笔账。目标模型是一个轻量级视觉网络主要算子是3×3卷积输入特征图通道数64输出通道数128特征图尺寸56×56。先算计算量每个输出像素需要64×3×3576次乘加输出有128×56×56401408个像素总乘加数约2.3亿次。如果芯片跑在200MHz要在一个合理时间内完成假设给这个算子分配1毫秒那需要2.3亿/1毫秒230G MAC/s的算力。如果每个周期一个MAC那需要230G/200M1150个MAC。考虑到利用率打个对折阵列规模大概要2000个MAC左右也就是45×45的阵列取整到48×48比较合适。再看存储权重是128×64×3×373728个参数INT8的话约72KB。输入特征图64×56×56200704字节约196KB。如果片上SRAM只有128KB那权重和输入都装不下必须分块。这就是为什么边缘芯片的SRAM容量往往要精心权衡——它直接决定了你能不能用最简单的数据流还是要引入复杂的分块调度。这笔账算下来你会发现每一个参数都不是孤立的阵列规模影响算力算力影响延迟延迟影响你对batch和分块的选择分块又反过来影响存储需求。软硬件协同设计就是在这些相互纠缠的约束里找平衡点。4. 实操过程从模型到芯片的完整落地路径4.1 第一步负载分析怎么做才不流于形式负载分析听起来很虚但它是整个设计的基石。我的做法是拿目标模型集合跑一遍profiling统计三样东西算子类型分布、张量形状分布、访存特征。算子类型分布告诉你哪些算子是热点。通常卷积、矩阵乘、注意力机制会占掉80%以上的计算量这些就是硬件要重点优化的对象。张量形状分布告诉你维度特征比如卷积的通道数集中在什么范围、矩阵乘的K维度有多大这直接指导阵列规模和分块策略。访存特征告诉你数据复用的机会在哪里比如权重是否可以被多个batch共享、输入是否可以被多个输出通道共享。我一般会把这些统计做成直方图然后找出覆盖80%计算量的形状区间硬件设计就围绕这个区间做优化。剩下20%的长尾负载用相对通用的方式兜底就行不值得为它们牺牲主路径的效率。4.2 第二步数据流设计的具体决策数据流设计是硬件架构的核心。我拿一个具体的卷积场景来说明决策过程。假设我们要实现一个3×3卷积输入通道C输出通道K特征图H×W。如果采用权重固定Weight Stationary数据流每个PE固定持有一个权重输入特征在阵列里流动。这种模式适合权重复用度高的场景比如大batch推理因为同一组权重可以被多个输入共享。但如果batch1权重复用度就低了效率会下降。如果采用输出固定Output Stationary数据流每个PE负责一个输出像素累加结果留在PE里输入和权重都流动进来。这种模式适合输出复用度高的场景但要求输入和权重的供给带宽足够。实际设计中**行固定Row Stationary**往往是更平衡的选择它同时在行方向和列方向做复用能适应更多样的负载。但它的控制逻辑也更复杂对编译器的调度能力要求更高。我的建议是先用一个简单的数据流把功能跑通再根据profiling结果逐步优化。不要一上来就追求最复杂的数据流那样调试成本会高到让你怀疑人生。4.3 第三步算子映射与编译器后端算子映射是把高层算子比如一个卷积翻译成硬件指令的过程。这一步的核心工作是循环分块Loop Tiling和循环重排Loop Reordering。以一个卷积为例它的计算可以表示成多层嵌套循环batch、输出通道、输出高度、输出宽度、输入通道、卷积核高度、卷积核宽度。这七层循环怎么切分、怎么排序直接决定了数据复用的效率。编译器要做的就是找到一种切分和排序方式让片上存储的复用最大化、DRAM访问最小化。这里有个很实用的技巧把最内层循环留给能留在寄存器里的数据。比如让卷积核的某个维度在最内层这样权重可以被反复使用而不需要重新加载。同时把输出通道放在较外层让累加结果能在片上多待一会儿。编译器后端还要处理内存分配。片上SRAM是有限的多个张量要共享这块空间就需要做生命周期分析——哪些张量同时活跃、哪些可以复用同一块内存。这个分析和通用编译器的寄存器分配本质上是同一类问题只是粒度更大。4.4 第四步性能建模与瓶颈定位性能建模的目的是在硬件流片之前就能预测软件跑在上面的性能。我常用的方法是建立一个roofline模型横轴是计算强度每字节访存对应的计算量纵轴是性能。每个算子在这个图上是一个点如果它落在计算瓶颈区说明算力是限制如果落在访存瓶颈区说明带宽是限制。有了这个模型你就能快速判断一个算子该怎么优化。如果它在访存瓶颈区那就想办法提高数据复用、减少访存如果它在计算瓶颈区那就考虑降精度、增加算力。这个判断比盲目调参高效得多。我还会做一个逐层profiling把每个算子的实际耗时和理论耗时对比。如果某个算子实际耗时远高于理论值那要么是数据供给有问题要么是调度有冲突。顺着这个线索往下查通常能很快定位到瓶颈。4.5 第五步软硬件联合验证的实操要点联合验证是最后一道关也是最容易出问题的地方。我的经验是先做单元验证再做集成验证。单元验证是把每个算子单独跑通对比硬件输出和软件参考实现的数值差异。这里要注意定点计算的舍入误差是累积的单个算子误差小不代表整个网络误差小所以单元验证的容差要留够。集成验证是把整个模型跑通重点看端到端的精度和性能。精度方面如果发现掉点严重要逐层排查是哪个算子引入的误差。性能方面要对比实测和建模的差距差距大的地方就是优化机会。提示联合验证阶段一定要准备一套完整的回归测试集每次硬件或软件改动后都跑一遍。AI芯片的软硬件耦合度高一个看似无关的改动很可能引发连锁反应没有回归测试你会疲于奔命。4.6 一个完整的算子优化实例我拿矩阵乘GEMM这个最基础的算子走一遍完整的优化流程。假设我们要在某个AI芯片上实现C A × B其中A是M×KB是K×NC是M×N。第一步确定分块策略。片上SRAM能装下多大的A块和B块假设SRAM有256KBINT8数据那能装256K个元素。如果取M块64、K块256、N块64那A块是64×25616KB块是256×6416K加起来32K远小于256K说明可以加大分块。取M块128、K块512、N块128A块64K、B块64K共128K留一半给输出和其他数据比较合理。第二步设计数据流。让B块固定在片上A块流动进来每个A元素和B块的所有列做乘加。这样B的复用度是M块大小A的复用度是N块大小。第三步安排指令序列。先加载B块到SRAM然后循环加载A块每次加载后触发计算计算结果累加到输出缓冲。这里要注意指令的流水线安排让数据加载和计算重叠起来避免串行等待。第四步实测调优。跑一遍发现利用率只有60%profiling显示是加载A块的时候计算单元在空转。于是改成双缓冲加载A块的同时计算上一块利用率提升到85%。再进一步发现输出写回DRAM的时候也有停顿于是把输出也做双缓冲利用率到92%。这个流程里每一步的优化都是数据驱动的不是拍脑袋。这也是我一直强调性能建模的原因——没有度量就没有优化。5. 常见问题与排查技巧实录5.1 精度掉点从哪一层开始查精度掉点是AI芯片落地最常见的问题。我的排查顺序是这样的先确认参考实现通常是浮点的精度是否正常排除模型本身的问题然后逐层对比定点实现和浮点实现的输出找出误差最大的那一层最后分析这一层的量化策略是否合理。常见的精度问题来源有三个。一是量化参数选择不当比如激活值的动态范围估计不准导致截断误差大。二是累加器位宽不够矩阵乘的累加结果溢出。三是激活函数近似太粗糙比如用分段线性近似sigmoid时段数太少。针对第一个问题可以用KL散度或者最小化均方误差的方法来选量化参数比简单的最大最小值法效果好很多。针对第二个问题累加器位宽一般要留够INT8输入的累加器至少32位。针对第三个问题查表法LUT往往比多项式近似更实用精度和速度都能兼顾。5.2 性能不达标一张速查表帮你定位性能问题排查我整理了一张表按现象分类基本能覆盖大部分场景现象可能原因排查方法解决方向计算单元利用率低数据供给不足看SRAM带宽和计算吞吐的比值加大片上缓存、优化数据流某算子耗时异常分块策略不合理对比理论访存量和实际访存量重新设计tiling参数端到端延迟高算子间切换开销大统计算子间的同步和搬运时间算子融合、流水线优化带宽跑不满访问模式不连续看DRAM访问的突发长度调整数据布局、对齐访问功耗超标数据搬运过多统计各级存储的访问次数提高复用、降低精度这张表是我踩了无数坑之后总结的基本上遇到性能问题先对着表过一遍能省下大量瞎猜的时间。5.3 编译器报错与算子不支持编译器报错通常分两类一类是语法或类型问题这类比较好查看报错信息就行另一类是调度失败比如找不到合法的分块方案这类比较麻烦。调度失败最常见的原因是片上存储不够。编译器尝试了所有分块组合发现没有一种能把数据装进SRAM。这时候要么减小分块粒度要么增加片上存储要么换一种数据流。我的经验是在编译器里加一个分块可行性检查提前把不可能的方案排除掉能大幅减少编译时间。算子不支持的问题通常出现在新模型刚出来的时候。解决办法有两种一是用现有算子组合出等价功能比如某些注意力变体可以用基础矩阵乘加激活拼出来二是扩展编译器后端增加新算子的映射规则。前者快但可能效率低后者慢但一劳永逸。我的建议是先用前者快速支持再根据实际使用频率决定要不要做后者。5.4 几个容易被忽略的实操心得第一个心得尽早做端到端跑通哪怕性能很差。我见过太多项目硬件做完了、编译器做完了最后集成的时候发现某个环节的假设完全错了返工成本巨大。哪怕用一个最笨的实现先把整条链路打通也能提前暴露接口不匹配、数据格式不一致这类问题。第二个心得性能优化要抓大放小。一个模型里80%的时间花在20%的算子上把这20%优化好整体收益就很大。不要平均用力那是最低效的做法。第三个心得留足验证时间。AI芯片的验证复杂度远高于通用芯片因为软件的行为空间太大了。我一般会把项目时间的三分之一留给验证这个比例看起来高但实际做下来往往还不够。第四个心得和软件团队保持高频沟通。硬件设计者容易陷入我提供了这个能力软件应该会用的思维但实际软件团队可能根本不知道怎么用或者用错了。定期的软硬件对齐会能避免大量返工。6. 写在最后的一点个人体会做AI芯片这几年我最大的感受是这个领域的门槛不在某一个单点技术上而在把软硬件捏在一起的系统能力上。你可能电路设计很强可能编译器写得很好但如果不能理解对方的约束和诉求做出来的东西就是拧巴的。我见过太多硬件很强但软件难用的芯片也见过软件很优雅但硬件跑不动的方案。真正成功的AI芯片一定是软硬件团队从第一天就坐在一起共同定义问题、共同设计方案、共同承担结果。这种协同不是流程上的形式而是认知上的对齐——硬件工程师要懂模型和编译软件工程师要懂架构和电路中间那层翻译的工作恰恰是最有价值的。如果你正在做AI芯片相关的项目我的建议是先把一个最小的端到端链路跑通哪怕它很慢很丑。跑通之后你对该优化什么、该怎么优化会有完全不同的理解。纸上谈兵一万遍不如亲手跑一遍。这个领域变化很快但把数据搬运管好、把复用做到极致、让软硬件说同一种语言这几条底层逻辑短期内不会变。抓住这些不变的东西你就能在变化里站稳脚跟。