1. 为什么AI芯片的性能七成由软硬件协同决定做AI芯片这几年我越来越笃定一个观点单看算力榜单没有意义真正决定一颗芯片好用不好用的是硬件和软件贴不贴合。每次跟同行聊到“AI芯片的软硬件设计”大家第一反应都是架构选型、算力峰值、能效比但实际从流片到量产软硬件协同设计才是那个最磨人、最能拉开差距的环节。先拆一下这个标题里最容易被低估的两个字——“协同”。硬件工程师喜欢把资源堆得满满当当认为算子跑得越快越好软件工程师则希望在写代码时感觉不到硬件的存在最好像用通用处理器那样跑完就完事。这两种心态放到AI芯片上都会出问题。我见过不少团队硬件峰值做得非常漂亮结果编译器只能映射出三成利用率也见过软件能力很强、算子优化得很精细但芯片存储带宽分配不合理频繁打回重做的项目。软硬件协同设计解决的正是这种割裂它要求两边的人在芯片定义阶段就坐在同一张桌上把指令集、算子库、编译器、数据流、存储层级当成一个统一的系统来设计。一个比较形象的类比是盖房子。硬件是毛坯房的结构承重墙怎么砌、水电管线往哪走、房间开间多大这是芯片的架构微架构软件是装修方案家具怎么摆、动线顺不顺、甚至哪些墙要敲掉重砌。如果装修师傅到了现场才发现某个插座位置根本插不进冰箱工程量就大了。AI芯片的软硬件协同设计本质上就是在结构施工图还没定稿之前装修师傅已经介入把家具尺寸、电器位置全部锁死。等房子交付拎包入住。这类设计的难点不完全在技术深度而在于两边知识体系差异太大。做硬件的不太关心编译器中间表示长什么样写编译器的不在乎RTL里那个寄存器的物理位置但协同设计的核心恰恰是这些边界的知识。比如指令编码的选择决定了编译器要出多少条微码存储缓冲的深度决定了软件要不要做双缓冲MAC阵列的行列数量直接决定卷积算子在硬件上的切分方式。任何一个环节拍板太早、沟通缺位后面都是连环返工。还有一点要强调所谓“AI芯片”不是单指一颗芯片本身它是一个系统级工程从指令集架构ISA设计到片上互联网络NoC再到编译工具链、算子库、运行时调度器以及模型量化和部署工具全部要捏合起来。每一层都有自己需要坚守的语义但层与层之间绝不能隔着黑箱。第六期这个标题带着“6”说明这系列已经聊过很多架构层面的内容这一篇我重点讲讲真正落地时软硬件之间那些衔接细节。适合正在做AI加速器、端侧NPU或者专用推理芯片的团队参考也适合准备从软件转行做异构计算、或者从硬件转到编译器方向的开发者提前建立整机视角。2. 硬件侧容易踩坑的三个关键设计点2.1 算力单元设计你的MAC阵列适合哪种算子形状算力单元几乎是所有AI芯片设计的起点也是最容易让软硬件协同失控的地方。大多数端侧AI芯片采用的是脉动阵列Systolic Array或者经典的乘累加阵列MAC Array但这两者有一个本质差异脉动阵列靠数据在阵列中“流动”来复用对卷积这种规整的算子是理想的而普通MAC阵列则是把输入数据广播到各计算单元更灵活但对片上带宽的要求更高。这块我非常建议硬件工程师在定阵列尺寸之前先拉一份目标模型清单。“你打算跑什么样的网络”这句话应该出现在架构定义的第一页。比如很多端侧设备重点跑的是轻量化模型核心算子是1x1或3x3卷积如果阵列被设计成过大的矩形小算子会在边缘产生大量无效计算实测利用率会非常惨。我见过一个项目阵列做成了比主流模型期望尺寸大一倍的方阵结果编译器只能把算子拆成两次映射用到一半的MAC单元造成的浪费相当于白烧了一大块硅片面积。另外不要忽略矩阵乘中的维度匹配问题。不少NPU为了支持Transformer类模型会额外设计支持高维度矩阵乘的模式这时候阵列的数据位宽、累加器精度、甚至输出行缓冲的数量都要重新考虑。如果照搬上一代卷积专用设计跑注意力模型时要么在数据搬运上损失效率要么在累加精度上出问题。设计阶段最好把卷积、全连接、矩阵乘三种计算形态的映射效率全部仿真一遍确定折中点。2.2 存储层级与带宽规划那是芯片性能的真正瓶颈回到现实世界很多AI芯片的瓶颈不在计算而在访存。这句话老生常谈但真正设计时还是会反复栽跟头。AI推理过程里激活值、权值、中间结果三者都要频繁在DRAM和片上SRAM之间搬运。片上存储每提升一点容量面积和功耗代价都很大。所以合理的做法不是尽可能堆SRAM而是算清楚你目标模型的“数据复用因子”——每次从DRAM读出来的数据能在片上被用多少次。这里有两个数值要重点把握访存带宽和算术强度Arithmetic Intensity即每字节数据对应的计算量。一个常用的粗算公式是假设芯片主频为F GHz、每周期可完成C次MAC运算则所需的访存带宽至少要达到 FC/算术强度 字节每秒。比如某场景下算术强度为10 MAC/Byte芯片主频1GHz每秒要完成2T次MAC那么访存带宽不能低于200GB/s。听着不算吓人但数据一旦不能缓存在片上实际带宽利用率会断崖式下跌。在协同设计上存储这块最重要的理念是“让数据待在离计算最近的地方”。硬件上要规划好几级存储的层次L1缓冲区贴近MAC阵列L2是中间共享内存尽量把模型权重预先铺到片上。软件编译器则需要知道每一级存储的容量和端口带宽才能决定哪层做数据复用、哪层做乒乓缓冲。最怕的是硬件把存储当成简单的“大水池”软件端也不清楚访问延迟是多少最后跑模型时性能计数器一开全是等待事件。2.3 片上互连和同步机制并行越多协调成本越高多核AI芯片基本都会遇到“核多了性能反而上不去”的情况。核心问题出在互连和同步机制上。片上网络NoC的设计直接决定了多个计算核心之间、计算核与存储之间的通信延迟和带宽分配。这里有个普遍误区以为把NoC带宽做大就能解决问题。真实情况往往是带宽有富余但仲裁策略不公平一个核发起大量突发访问会把其他核的流量堵死导致长尾延迟飙升。硬件设计上要支持区分“延迟敏感”和“带宽敏感”两类请求比如同步用的通知消息走低延迟通道大块数据搬运走高吞吐通道。同步机制也是软硬件协同的深水区。AI推理流水线里经常要做算子间的同步比如一个卷积算子结束后下一个Pooling算子才能开始。如果硬件只提供简单的全局barrier那一核拖慢往往导致整个管线停下来。合理的做法是硬件支持细粒度的依赖管理软件端尽量把大算子切分成小块让多个核在块级粒度上做流水而不是等整个算子全部完成再切换到下一个。这块调度策略写不到芯片规格书里但对最终性能影响极大属于典型的软硬件要坐到一起解决的问题。3. 软件侧真正决定落地效果的核心环节3.1 编译器别拿通用编译器的思路套专用芯片AI芯片的软件栈里编译器是承上启下的枢纽。它接收来自上层框架如PyTorch、MindSpore这类推理框架的模型图然后通过图优化、算子映射、存储分配、指令调度等一系列pass最终生成目标芯片能执行的指令流或配置。难点在于AI芯片不是通用的CPU它的指令集高度特化一个算子在硬件上可能对应一套复杂的微代码序列编译器必须把“语义正确”和“性能可用”两件事同时做好。我特别想提醒做基础软件的工程师不要一上来就套LLVM那套通用编译器思维。LLVM的中间表示IR假定的是寄存器机模型但你面对的NPU可能是显式的片上存储层次没有“通用寄存器”这种概念数据只能搬来搬去。你必须设计一套符合硬件数据流模型的IR至少要让硬件里每个存储块在IR里都有对应的虚拟表示编译器才知道该如何搬数、何时搬运。编译器另一个大头是算子映射。硬件里如果有专门加速某个形状算子的单元编译器就要试图把模型图中匹配的算子尽可能“融合”进去。融合之外内存分配也极其考验策略不同算子之间哪些可以复用缓冲区哪些必须重新分配分配错了会让片外访问暴增。所以编译器团队的KPI不能只看着“能跑”要看“利用率”——我们可以用汇编、反汇编、仿真器统计每个算子在芯片上占用了多少周期、流水线停顿了多少周期这些都是优化方向。3.2 算子库与手动Kernel编译器不是万能的很多新手团队会有一个幻想只要编译器写得好所有算子都能自动优化到位。实际经验是对于高度特化的硬件手写关键算子往往比通用编译器生成的代码高效得多。原因很简单编译器要面对任意可能的计算图它的优化策略是启发式的而一个经验丰富的内核工程师面对一个固定算子时可以把每一周期该发生的事情都排得明明白白。所以成熟的软件栈都是“编译器算子库”双轨并行。算子库针对芯片最常用的算子做深度手工优化比如3x3卷积、1x1卷积、矩阵乘、LayerNorm、Softmax等把数据复用方式、片上缓冲区调度、流水线安排全部按最优方案写好。编译器在匹配到这些算子时直接调用库里的最优实现其他算子退化为通用映射逻辑。做算子库时需要特别注意边界条件和算法分支优化。一个卷积算子要支持不同的步长、膨胀率、分组数每种模式都是独立的优化空间。如果贪图省事把参数全转成通用分支性能会大打折扣。我也见过为提高覆盖率把所有参数用循环展开的方式全铺开结果编译后的指令尺寸巨大指令缓存装不下性能反而下降。所以算子库的优化需要量化到具体模式针对高频路径做深度优化低频路径做正确性兜底这才是工程上务实的选择。3.3 运行时与调度器静态排指令还是动态抢资源芯片读到了指令流谁来保证计算核和搬运引擎步调一致这就到了运行时调度器的职责范围。AI芯片上通常会有专门的DMA引擎负责数据搬运计算核负责计算两者天然并行。调度器要决定某个算子的数据提前多少拍搬到片上、计算核什么时候开始计算、下一块数据什么时候开始搬运才能做到永不停歇。常见两种调度思路静态调度和动态调度。静态调度是编译期就把所有指令的发射时间推算好运行时只按顺序执行好处是开销低、时序可预期动态调度则是在运行时根据各引擎的忙闲状态动态分配任务灵活但对硬件同步机制和软件的锁管理要求更高。端侧实时性要求高的系统更倾向于静态调度服务器端算力冗余多的场景则更适合动态减少空心期。这里有一个实操细节值得说说指令下发方式。有些芯片选择用CPU核执行“指令流”的方式做调度相当于把NPU当成协处理器CPU逐条下发指令另一些芯片则给NPU配备内部的微控制器或指令队列一次性下发整条算子链硬件自行依次执行。前者灵活性好但同步开销大后者有利于低延迟执行但要求编译器把依赖分析做扎实。软硬件协同设计在这块就要提前判断你的目标系统中CPU是否足够空闲来承担调度如果不能就得给硬件多留一些自主调度能力。3.4 量化工具链掉点永远是软件来扛谈到落地量化是绕不开的词。AI芯片为了能效几乎都会采用INT8、INT16甚至更低比特的定点计算推理框架产出的通常是FP32模型如何把它转成硬件能高效执行的定点模型这是量化工具链的职责。我记得一个被反复议论的经典场景FP32模型在GPU上精度达标一转到自研NPU上就掉点严重。排查时十有八九不是硬件计算错了而是量化算法不过关。问题可能出在激活值分布的非均匀性、个别离群值拉大了量化范围导致有效精度不足、或者某个敏感层没有做混合精度保护。好的量化工具链要提供逐层精度分析能力能对每一层对比在线量化前后的输出差标出敏感层提示开发者在哪里保留高比特。之前有个项目调推理精度连续调了两周最后发现问题根本不在量化本身而是一个卷积层在硬件上的数据排布顺序和参考框架不同导致批归一化融合时用错了均值方差。这种问题如果不做量化工具链层面的自动校准靠手工排查几乎是大海捞针。所以给做AI芯片的同学一个建议量化工具链不是“写完就完”的边缘工具它在整个软件栈里面跟编译器同等重要上线前一定要做充分测试至少用几十个真实模型跑一遍端到端的精度对比。4. 从一张需求表到流片前完整协同设计流程走一遍4.1 先做“模型到硬件”的映射仿真再动手写RTL我一直觉得AI芯片项目里最不该省的一步是早期做“模型到硬件”的映射仿真。很多团队直接从算法团队要一份运算量统计表就据此拍板算力、存储、带宽这些关键参数然后闷头设计等到软件开发时才发现硬件资源卡的难受。正确做法是先建立一套软硬件协同的仿真环境把目标模型系列拆成算子序列逐个映射到拟定的硬件配置上统计每个算子的计算周期、访存总量、片上存储占用、以及流水线有没有气泡。比如某个项目想覆盖一系列检测模型输入分辨率不同、算子的张量形状差异很大。仿真下来发现主要的瓶颈不在MAC总量不够而在每次算子切换时片上缓存的残留数据占用导致下一层能分配到的内存变少。于是设计团队把存储策略从“整块均分”改成了“按算子动态分配”并且硬件上增加了虚拟化存储映射的机制。这个改动如果放到流片后再发现几乎是推翻重来。仿真的精度不必追求百分之百周期精确初期可以粗一些重点看在各类模型组合下硬件资源的使用率分布。等微架构逐渐收敛再导入更精确的性能模型甚至RTL仿真逐步逼近真实数据。所有关键架构决策都要用仿真数据确认后才锁定这是协同设计流程中“不可跳过的第一站”。4.2 指令集与编译器接口的契约定好双端视图指令集架构ISA是软硬件协同最核心的一个契约面。它既让硬件知道要支持哪些操作也让编译器知道能生成哪些指令。AI芯片的ISA设计很考验功力太细的指令会让编译器压力巨大每条都要精确调度太粗的指令则把大量决策丢给硬件硬件逻辑变得复杂且灵活度下降。合理的设计是分成几个层级粗粒度的算子级指令如Conv2D、MatMul、Activation、细粒度的数据搬运指令如Load、Store、Copy、以及同步控制指令如WaitEvent、SignalEvent。定了ISA之后编译器就按这个契约工作。但这里有一个很多新人会低估的细节ISA的版本兼容。芯片设计周期长编译器开发并行进行指令集格式如果中途频繁变双端都会崩溃。所以项目启动时要定好“指令集冻结时间点”之后的修改必须走严格的变更评审。我在实际项目中见过ISA临时加了一个“立即数变体”用于加速某个特殊算子结果编译器端已经按固定宽度编码上量导致两边对接花掉了将近一个月。早期把契约锁死后面会省出无数精力来做真正有价值的优化。4.3 存储分配和算子切分到底怎么配合存储分配是编译器与硬件之间最频繁的“谈判区”。硬件定义好几块大小不同的SRAM编译器则要决定每一层网络的中间结果放在哪块、权重怎么排、哪个数据提前预取。这里需要遵循几条原则高频访问的数据放离计算阵列最近的存储低频数据可以放在较大但稍远的内存。算子的输出要尽量覆盖到下一个算子的输入否则每次都要写回DRAM再读出来效率折半不止。权重加载尽量在算子启动之前完成流水线上要给权重搬运预留时间窗口。算子切分则是面对超大张量时的必要手段。比如一个视频超分模型会产生巨大的中间特征图超出了片上存储容量就不能整算子进行计算必须按高、宽或通道方向切块。切块尺寸的选择直接影响数据复用程度切得越小存储占用越低但边缘重叠计算和数据搬运开销越大切得越大复用越好但可能装不进片内。这个优化本质是个背包问题我见过团队用动态规划自动搜索最优切块参数效果比手工调快得多。芯片的存储容量、带宽参数被当成约束条件计算软件自动适配这正是协同设计高效的体现。4.4 一个实战推演8MB片上存储、4TOPS算力的小芯片怎么跑Transformer用一个已经收敛的模拟配置给大家走一遍推演过程。假设我们要设计一款端侧推理芯片INT8算力4TOPS主频800MHz片上SRAM总共8MB支持4个计算核并行峰值访存带宽64GB/s片内。目标是跑一个轻量Transformer模型大约有12个编码层每层主要算子是QKV投影矩阵乘、Attention、FFN。第一步先估算单层结构的访存需求。假设序列长度128、隐藏维度256、中间维度1024。QKV投影三个矩阵乘的权重合计约 3×256×256 196K参数FP32换算成INT8只有196K字节FFN两层权重大约 256×1024×2 约512K字节。都远小于8MB说明权重可以全部预加载到片上。但真正麻烦的是Attention部分。QK^T得到128×128的分数矩阵然后在序列维度做Softmax接着跟V做矩阵乘。如果不做优化QK^T输出要写回存储再读出来做Softmax再写一次再做PV乘法。这就是典型的多写多读浪费。协同优化的解法是在硬件上增加一个“融合运算单元”让Softmax的结果直接在片上行缓冲里流转不落回大存储。软件编译器要识别Attention的完整数据流图生成融合指令序列。这个过程做下来Attention部分的有效算术强度会从约2 MAC/Byte提升到接近10 MAC/Byte。接着看算力匹配。4TOPS在800MHz下相当于每周期5000次MAC四个核心每个约1250次MAC/周期。以256维的矩阵乘为例一个周期理论上可以完成一行256维点积配合流水需要多个周期凑满阵列效率。FFN中间维度1024切分得当的话算力利用率可以到80%以上。再检查带宽如果所有数据都在片上片内带宽64GB/s远远够用片外DRAM只在模型切换时加载权重可以不作为常态瓶颈。这套推演方式就是软硬件协同的日常先算清理论峰值再算数据流损失最后通过软硬件配合把损失一点点抠回来。最终项目实测这个配置跑12层Transformer单Token延迟能做到5毫秒以内端侧场景完全够用。5. 项目实战里常见问题的排查经验手记5.1 利用率为啥只有三成先校准你的“算力定义”在多个项目里被反复问到同一个问题“我的芯片理论4TOPS跑模型实测只有1TOPS出头是不是硬件有bug”每次遇到这种问题我都会先反问一句你是怎么定义TOPS的很多芯片标称的算力是按MAC阵列满载、完全不考虑数据搬运的理想值。而真实模型跑起来卷积的输出通道数、输入分辨率、存储带宽三个因素任何一个不匹配都会让实际利用率腰斩再腰斩。排查利用率的第一步是拆时间线。用芯片内置的性能计数器分别记录计算时间、访存等待时间、同步等待时间三类数据。如果计算时间占比本身就低怀疑是算子切分不够好或阵列尺寸与算子形状不匹配如果访存等待时间高怀疑是数据复用策略失效权重被反复从DRAM读取如果同步等待时间高怀疑是多核调度负载不均。曾经有个项目利用率卡在45%很久查到最后发现是编译器的调度器对所有核的任务分配采用了贪心策略同一层的大算子被切成等块后分给4个核但因为输出并行度的差异两个核1微秒跑完两个核要50微秒后来改成动态窃取任务量不均时自动迁移才把利用率拉到75%。这类问题单看硬件是看不出来的必须软硬件一起抓。5.2 精度掉点之后按“层-张量-通道”三层逐级排查量化模型的精度问题像个幽灵时有时无特别折磨人。掉点排查的流程我一般建议按三层递进来定位第一层逐层比对。把量化模型在芯片上的每层输出和FP32参考模型的逐层输出做对比算出每层余弦相似度或绝对误差。误差大的层就是重点怀疑对象。第二层看张量分布。对误差大的层打印该层输入张量的数值分布特别关注是不是有少数离群值。在95%的分位点上数值都在[-10, 10]之内偏偏有极少数值到几百这种分布直接做均匀量化必然翻车需要做离群值截断或者对该层改用更高比特表达。第三层查通道维度误差。有的层整体误差不大但某个具体通道的误差异常高可能是权重本身就分布不均。这时候要做通道粒度的量化尺度校准不要贪图省事整层统一scale。我遇到过一个特别隐蔽的精度问题批归一化BatchNorm的实现在不同框架里语义不同。推理时需要把BN融合进卷积的权重和偏置但融合过程中因为对均值方差张量做了在线更新导致多线程并发时竞态条件破坏了参数一致性。表现出来就是模型前几次推理掉点多跑几次又恢复正常非常难定位。最后是软件团队用固定随机种子反复复现再同时抓取权重参数和中间融合结果比对才锁定问题不在量化算法而在融合过程的并发控制。这种问题提醒我们精度问题的排查要覆盖整个计算图变换过程包括那些看起来“只是优化”的pass。5.3 实测吞吐上不去检查你的流水线“气泡”明明算力充足、量化无误为什么端到端的帧率还是达不到预期这就要看流水线里有没有“气泡”。AI推理的端到端流程往往涉及多个阶段图像预处理、模型前处理、NPU计算、后处理。如果这些阶段串行执行大量时间浪费在等待上。很多团队在初期会把NPU计算当成一个不可分割的大黑盒CPU等待NPU全部跑完才开始做后处理。软硬件协同的优化则要求把NPU的执行过程拆成算子级或块级的流水摄像头上来的图像在做预处理时NPU并行跑前一帧的推理CPU同步处理后处理。这需要硬件提供清晰的算子完成事件通知软件设计好事件驱动的状态机。别小看这个改动在很多端侧方案里流水改造带来的收益往往比继续刷算力高得多。实操上有一个建议开发早期就要把端到端的性能数据流图画出来标注每个阶段的执行时间、依赖关系、可并行的部分。很多人习惯等到芯片回来才开始看端到端流程太晚了。在仿真环境里就应该把流水方案验证一遍确认事件同步机制在硬件上能否支撑。等到流片后再发现硬件缺少某个异步通知寄存器就只能靠软件空转轮询来弥补白白浪费算力。5.4 疑难杂症速查表按现象索引处理路径现象推理结果在固定层开始全变为零。优先检查该层上游是否发生溢出INT8乘法累加结果没有饱和截断直接截位丢数据。硬件需要做饱和处理编译器需要排查指令的累加位宽设置。现象吞吐量随batch size增大先涨后跌。大概率是片内存不下多个batch中间结果导致频繁写回DRAM建议降低batch或优化内存复用或者对batch内多个样本走算子融合。现象多核运行反而比单核慢。查负载均衡、数据竞争、NoC拥塞三块。曾有项目是因为两个核同时访问同一块SRAM的同一bank触发bank冲突引入交错地址映射后问题立即解决。现象同一算子反复执行时性能波动大。优先查DRAM刷新与cache策略是否干扰以及运行时调度器是否被其他任务抢占。现象编译时间过长大型模型编译要数小时。通常是优化pass的复杂度失控对大型计算图做全局内存规划时会反复搜索可以先设置分层编译策略把不常变化的子图缓存起来。表格化更直观一点现象可能根因排查入手点利用率低阵列与算子形状不匹配统计各算子映射效率精度波动量化分布异常或并行竞争逐层比对输出分布吞吐不达标流水线串行等待画端到端时间线固定层输出为0累加溢出无饱和处理检查INT8乘法位宽多核掉速bank冲突或负载不均查访存地址交错、任务分配编译耗时极高全局优化pass爆炸开启子图缓存分级编译6. 最后分享一点跨了六期实战的心得做完这么多期AI芯片软硬件设计的复盘我个人的体会是芯片项目的成功不在于硬件多先进或者软件多聪明而在于两个团队有没有形成真正的“共同语言”。这不是一句空话——从指令集契约的锁定到量化精度问题的联合排查再到流水线方案的协同验证每一次顺利推进都建立在两边理解了对方的约束。今天特意把几个最容易踩坑的软硬件衔接点串起来讲了一遍算力单元怎么贴合模型形状、存储带宽如何算清数据复用、编译器与算子库怎么搭配、量化掉点如何逐层定位、流水线气泡怎么消除。如果你正在做类似的项目建议从第一个环节“模型到硬件的映射仿真”开始把目标模型拉到你的架构草案里跑一遍把每类算子的周期和访存量都摸清楚再决定硬件资源怎么配。这一步花的时间会在后面十倍的返工中省回来。至于那些参数到底怎么权衡还是要拿自己手上的真实场景去验证。工程没有银弹每个团队的模型、成本、功耗、时延约束都不一样上面的方法给你的是排查路径和设计框架不是万能模板。最后再提醒一个容易忽略的点软硬件协同的文档要跟代码和RTL同步维护。我见过太多接口文档过期之后硬件和软件按各自的“过期版本”实现联调时互相指责对方没对齐。养成随时更新契约文档的习惯比什么都重要。