做了这么多年AI芯片相关的软硬件协同设计我越来越觉得真正的难点往往不在某个单一模块而在软硬件咬合的那条边界上。指令集设计、数据流组织、存储层级规划、编译器后端映射这些东西单独拎出来都有成熟的方法论但一旦目标变成“在一个功耗预算内跑满某个模型家族”问题就从“模块能不能work”变成了“整个系统能不能在cycle级连续运转不空转”。这篇我打算把软硬件协同设计里最容易被忽视、又最影响实际性能的环节拆开讲一遍。不是泛泛谈架构而是聚焦在我们实际做一颗AI加速芯片时怎么定数据流怎么给算子分级怎么让编译器知道片上存储到底有多少、什么时候该搬数据以及怎么在RTL冻结之前就把性能误差控制在10%以内。这套内容适合两类人一类是刚入行、正在接触NPU或AI加速器设计的学生和初级工程师另一类是做算法或编译出身、想搞清楚硬件侧到底怎么吞吐数据的同学。如果你是做应用层部署的也可以看看后半部分关于量化、算子映射和性能建模的内容很多“为什么芯片实际跑不快”的答案都在这里面。1. 总体架构软硬件分界线到底画在哪真正开始动手之前最该想清楚的一件事是指令集到底表达什么。1.1 指令集是软硬件之间的契约很多团队一上来就奔着“我要支持所有算子”去设计指令集结果指令种类爆炸硬件译码逻辑复杂编译器后端也痛苦。我个人的经验是指令集的粒度决定了整个系统的复杂度这个粒度必须跟着“哪些操作是性能关键路径”走。举个例子如果目标是跑Transformer类模型核心计算就是大矩阵乘、向量加、LayerNorm、Softmax、GELU、Attention的QK^T和PV。那指令集就可以分三层。第一层是标量指令相当于整个芯片的“总经理”负责循环控制、分支跳转、地址计算、配置各执行单元。第二层是向量指令负责逐元素运算和规约类似“车间主任”管所有按向量处理的活儿。第三层是矩阵指令这才是真正的“生产线”一条指令要在MAC阵列上完成一个完整的分块矩阵乘。这三层指令之间是显式并行的关系。标量引擎在配置DMA搬运下一块数据的同时矩阵引擎可以正在算当前块向量引擎在另一块数据上做激活或归一化。听起来很理想但实际做的时候最难的不是让三个引擎各自跑起来而是让它们在时间上咬合住。1.2 数据流选择是架构的灵魂数据流这个词看着抽象翻译成大白话就是数据从存储器到你手跟前的路径以及数据被复用的顺序。常见的三种流派是输入固定、权重固定和输出固定。我们做卷积加速的时候选的是输出固定原因也很简单可以最大程度减少部分和partial sum的读写次数。想象一下一个卷积层输出通道是512输入特征图是56x56x256如果用输出固定每个输出像素只需要把输入特征图的一个窗口和对应的权重乘累加完结果落在输出寄存器里不需要频繁把中间结果写回DRAM。如果是权重固定一开始把权重全部摊在片上然后让输入图像在MAC阵列里“流过”这种模式很适合批量推理场景因为权重复用率极高。但如果模型更换频繁权重的重载开销会吃掉很大一部分增益。数据流选择的本质是对“能量守恒”的另一种理解。AI加速器里最贵的不是MAC计算而是数据搬移。一次寄存器访问的能量和一次DRAM访问的能量差了三个数量级。所以数据流设计的唯一目标就是让每个比特的数据在被使用之前尽量多被复用几次。1.3 算力与带宽的平衡用Roofline找边界Roofline模型是个老生常谈的工具但真的拿它来做架构决策的人不多。它的核心就是画两条线一条是峰值算力线一条是DRAM带宽线。当模型的算术强度每字节数据承载的MAC操作数低于两条线交点时系统是带宽受限的高于交点才是算力受限。我们曾经做过一个8 TOPS级别的端侧芯片设计峰值算力在INT8下约每秒2万亿次运算DDR带宽是32GB/s那么Roofline的交点大约在62.5 MAC/Byte。跑MobileNet类模型时算术强度一般能到100以上还有机会逼近算力上限但跑一些Bottleneck结构比较多、通道数不规整的模型时算术强度会掉到40甚至更低这时候花大价钱堆算力纯粹是浪费硅面积。这个分析在RTL开发之前就必须做完因为一旦带宽定了后期想靠编译器优化补回来几乎不可能。2. 算子落硬件从抽象到具体的关键一跳2.1 算子拆解与指令化软硬件协同设计里最容易产生分歧的地方就是算子到底怎么落到硬件上。我的习惯是分为三个步骤分析、拆解、映射。分析阶段要做的是把目标模型的算子图完整跑一遍profiling统计每个算子占用的时间比重。拆解阶段决定哪些算子用硬件单元直算哪些用向量指令组合完成哪些干脆在CPU上跑。映射阶段则是把算子和存储布局绑定到具体硬件资源上。举一个具体的例子LayerNorm在Transformer里出现频率很高。如果你让矩阵引擎去算LayerNorm那是大炮打蚊子。LayerNorm本质上是一个减均值、除方差的逐元素操作更适合用向量引擎做。但它的难点在于需要两次遍历一次算均值和方差一次归一化。如果向量引擎的本地寄存器足够大可以把数据先留在寄存器里只让标量引擎做规约计算这样就能省掉一轮DRAM访问。这就是典型的软硬件配合点硬件提供足够大的本地存储编译器负责调度二次遍历的时机。2.2 存储层级与数据搬移的账片上存储怎么规划是AI芯片设计里最考验功力的事情。SRAM太多成本吃不消SRAM太少带宽根本喂不饱MAC阵列。举个例子假设MAC阵列是128行128列也就是一个cycle能算16384次MAC。如果跑INT8输入和权重各占1字节每个cycle光输入就要128字节的新增数据。假设芯片跑800MHz那么每秒需要128 x 800M 102.4GB/s的数据供应。这个数字远远超过DDR带宽所以片上必须有一层大的SRAM做中间缓冲把当前计算层的输入特征图和权重完整hold住。我见过一个还算合理的方案片上总SRAM做成4MB分成三块。一块2MB给权重一块1.5MB给中间特征图剩下512KB做向量引擎的本地寄存器文件。为什么权重需要更大因为卷积的权重总量往往比单层输入特征图大而且权重复用率极高一次性放得越多DRAM访问次数越少。这个配置不是拍脑袋定的是用一个脚本把所有目标模型的逐层内存需求扫了一遍统计出不同容量下的DRAM访问量变化曲线选了一个拐点。2.3 量化方案从PTQ到QAT的精度与部署权衡量化这件事天然是软硬协同的。硬件决定支持哪些位宽组合INT8、INT8xINT4、INT4xINT4软件决定每个张量实际用多少比特。训练后量化PTQ和量化感知训练QAT不是简单的二选一而是要看硬件对量化误差的容忍度。我们的经验是先跑一轮完整的PTQ然后逐层分析每个张量的激活值分布。大部分层用INT8都没问题但有几个位置特别敏感Embedding输出、LayerNorm前后、最后的Logits层。这几个位置的数值范围波动很大或者对精度极其敏感。如果在这些位置强上INT8精度掉点会非常明显。有一个通用做法是先做混合精度分配敏感层保留INT16累加中间层用INT8部分权重稀疏度高的层用INT4。这个分配策略需要量化工具链支持按层指定位宽同时编译器要把不同位宽的算子映射到指令序列。硬件这边对应的能力是MAC阵列的累加器做高精度但输入位宽可以动态切换。这个设计并不复杂但能显著改善PTQ的精度表现。3. 编译器与运行时真正的性能杀手3.1 算子图优化与内存规划编译器这头大家最容易踩的坑是只盯着“能不能生成正确代码”忽略了“生成的代码是否在跟硬件的真实状态对话”。算子图优化里最著名的是算子融合比如ConvBNReLU在推理时可以合并成单个Conv。这个优化能减少一次中间特征图的写回和读入对端侧芯片尤其重要因为存储带宽本身就是瓶颈。但融合不是无脑做的如果你的硬件允许编译器在同一个引擎上连续执行两种算子且中间结果能留在本地寄存器里才有实际收益。如果中间结果必须经过DRAM那融合的意义就少了一半。内存规划这块才是真正的硬仗。因为硬件设计者会把片上SRAM切成很多块编译器要负责决定每个张量在哪个时间窗口放在哪块SRAM里。这个问题的本质是“寄存器分配的多维版本”每个张量有生命周期有多个候选存储位置有对齐约束还有读写端口冲突约束。我们内部用类似图着色的启发式算法来做但现实约束太多仍然需要人工干预。3.2 多核调度数据并行还是流水并行多核架构是提高吞吐量的必经之路但多核调度带来的挑战可能比多核本身还大。两种主流的并行策略是数据并行和流水并行。数据并行就是每个核处理不同的batch优点是实现简单、扩展性好缺点是BN/归一化这些跨样本的操作需要同步而且如果batch只有1数据并行直接失效。流水并行是把一个模型按层切开每个核负责一段计算像流水线一样连续推进。流水并行的最大坑是load imbalance如果某个核负责的算子回数明显长于其他核整个流水线就被拖成这个核的速度。我们实践下来端侧场景更倾向于混合方案batch1时用数据并行batch1时自动切到流水模式。负载均衡需要在编译时做静态分析拿一个profling工具把每个算子的cycle数预估出来然后按预估时长切分。这个方案的精度取决于cycle预估器的准确性所以它跟性能建模那部分强依赖。3.3 性能建模流片前把账算明白性能建模这件事我觉得是整个软硬件协同设计里最值得花时间的环节。它的目标是在RTL开发还在进行时就能回答“这样一个指令序列在目标芯片上要跑多少cycle”。建模分几个层级。最粗糙的是行为级模型直接按每个算子的固定cycle数乘以算子调用次数。这种模型误差通常在40%以上主要用来做前期架构探索。再往下是带数据依赖的行为模型它会计入DMA搬运时间和访存冲突误差能压到15%左右。最精细的是cycle级模型每个流水级、每个bank冲突、每个仲裁器等待都建模误差可以到5%以内但开发和维护成本极高通常只给关键内核用。我的建议是不要一开始追求全覆盖cycle级模型。先做行为级模型然后对最关键的三个内核矩阵乘、卷积、Attention做cycle级细化这样大部分客流场景的误差都能压到10%附近。重要的是定期拿FPGA原型或硅前验证平台的实测数据去校准模型不然模型计算结果会慢慢失真。4. 验证流程与那些年我踩过的坑4.1 从模拟器到FPGA原型的验证层次软硬件协同验证必须分层做每层的目的不一样。指令集模拟器ISS跑起来快专门用来验证编译器生成的指令序列是否正确以及跟性能模型预测的cycle数差多远。RTL仿真跑得慢但好在信号级可观测专门用来抓硬件bug。FPGA原型跑得更接近真实behavior专门用来验证整机性能和真实模型端到端的精度。这里有一个普遍存在的毛病团队在ISS上验证完就以为万事大吉结果FE的RTL仿真一跑发现指令序列里有个地址冲突或者DMA的中断处理和主核的写回顺序不对又回头改编译器。所以我的惯例是任何指令集层面的改动必须同步更新一个RTL模板测试用例确保仿真和ISS的结果逐cycle对齐。4.2 我踩过的几个典型问题第一个坑DMA带宽和主核访存打架。我们早期设计里DMA和主核共享同一组SRAM端口结果DMA正在做整块数据搬运的时候主核访问同一个bank被阻塞了几百个cycle。表面上指令序列没问题但流水线空转严重。后来解决办法是对存储做了bank划分DMA流量优先主核访问落到其他bank同时编译器用双缓冲来隐藏DMA延迟。第二个坑量化后精度掉点查不出来。某个模型量化后分类准确率掉了3%我们一开始怀疑是某个敏感层结果逐层排查发现是Softmax输入分布太集中小端误差被放大。最后是靠调小Softmax量化scale、并在该层保留FP16累加解决的。这件事让我养成了习惯任何时候量化异常先看数值分布而不是急着加正则。第三个坑功耗预期和实测相差很远。性能模型只算了MAC和访存漏掉了数据翻转率的影响。实际跑高熵数据时总线翻转导致的动态功耗比模型预测多了30%以上。现在我们在性能模型里加了一项“数据活跃度系数”不用精确算翻转率按数据类型给不同系数粗略但够用。第四个坑编译器生成的内存地址没有对齐。某个中间特征图的stride设计成了奇数导致后续访问时跨bank开销激增。硬件设计者其实预留了对齐要求编译器没遵守最后靠编译器后端加一个对齐rebase pass解决。4.3 问题排查速查表现象可能原因排查手段解决方案实际吞吐远低于Roofline预测DMA搬运时间暴露在关键路径上抓访存时序图统计DMA活跃比双缓冲、提前搬运、流水线调度精度掉点集中在某一类层量化参数不匹配逐层比较量化和浮点输出分布该层改混合精度或调整量化scale多核利用率严重不均算子切片粒度不合适跑profiling统计每核活跃cycle数重新切割算子或做动态负载均衡编译器生成的指令序列性能波动大存储bank冲突或地址对齐问题开启性能模型里的bank冲突统计对齐rebase、bank均衡分配功耗实测高于预期数据翻转率被忽略统计总线/寄存器翻转时长调整编码、增加数据闲置检测这组排查思路有一次帮我们在流片前定位了一个致命问题某个模型推理会在特定输入尺寸下触发DMA描述符的优先级反转导致长时间卡顿。性能模型报了异常但ISS完全没有问题最后在FPGA上复现长尾Latency才锁定的。这件事之后我把性能模型的输出分成了P50、P99、P95三档避免只看平均值错过偶发性能事件。我个人做软硬件协同设计这几年最核心的体会是越早让软件和硬件的抽象层对齐后续项目风险越低。很多团队把硬件定死了才开始写编译器这是倒过来做的。正确的方式是硬件架构师、编译工程师和验证工程师在指令集定义阶段就坐在同一张桌子前对着性能模型一点点把边界磨出来。这个阶段多花一个月后面能省下半年。最后再分享一个小经验。每次架构或编译器做改动第一件事都是拿同一组基准模型重新跑一遍性能和精度回归。不要只看波形对不对波形只保证行为正确但不保证速度快、功耗低。把回归脚本做成全自动的任何改动只要性能变化超过3%就需要写说明原因。这个习惯虽然烦人但它是防止性能回归最有效的手段。就写到这这套方法算是我在多次流片教训里沉淀下来的希望对你正在做的项目有点参考价值。