每个做AI加速器的团队，几乎都遇到过这种场景：硬件团队说MAC阵列利用率跑到了98%，软件团队盯着执行时间说这绝对没到预期，两边各拿出一套数据，结果谁都没错。问题就出在软硬件协同设计上，而且多半不是单点失误，是整个栈的交互细节出了岔子。这篇是“AI芯片的软硬件设计”系列的第6篇，我想跳出性能对比表，聊聊项目落地过程中最消耗精力的那些交互点：算子怎么映射到硬件、指令集边界划在哪儿、存储结构如何反推编译策略、联调时软硬件两边到底该按什么顺序排错。内容适合正在做AI芯片编译器、加速器架构或算子库的工程师，也适合想弄明白“AI芯片为什么算法设计不难、难在系统协同”的人。接下来要讲的思路，很多来自实际项目里的反复试错，不一定每一条都对，但大概率能让你少踩几个坑。1. 算子在硬件上落地：数据通路和循环嵌套怎么互相妥协1.1 编译器看到的循环，和硬件看到的数据通路一个普通卷积算子，软件端写出来就是几层for循环：for (int oc = 0; oc < OC; oc++) { for (int oh = 0; oh < OH; oh++) { for (int ow = 0; ow < OW; ow++) { for (int ic = 0; ic < IC; ic++) { for (int kh = 0; kh < KH; kh++) { for (int kw = 0; kw < KW; kw++) { acc[oc][oh][ow] += input[ic][oh+kh][ow+kw] * weight[oc][ic][kh][kw]; } } } } } }但在硬件工程师眼里，这段代码完全不是这个形态。硬件只能看到一个数据通路：数据从哪块SRAM读出来、经过多少个乘加单元、暂存在哪个accumulator、最后以什么地址写回。所谓“硬件加速”，本质上是把软件里的循环计数器，换成了一套物理上并行流动的数据。这个差异是几乎所有软硬件分歧的源头。编译器把循环当成一个可重排的数学问题，硬件把循环当成一条精确到拍数的时空轨迹。互相之间谁都不知道对方约束了什么，后面就必然吵架。我见过最多的一种局面，是算法团队先跑通了一个浮点模型，硬件团队照着峰值算力把MAC阵列定了，编译器团队最后才介入，结果发现硬件的数据流格式只支持某一种循环顺序，编译器得为每个算子生成非常复杂的地址跳变逻辑。更糟的是，这种跳变会让片上存储bank冲突严重，最终利用率比paper上的理论值低一大截。1.2 三种硬件映射风格，对应的软件约束具体到卷积或者GEMM这类算子，业内现在的主流映射风格基本可以归成三类，它们对软件栈的约束完全不同：脉动阵列风格：数据像流水线一样在阵列里流动，每个PE从邻居拿数据，乘完继续传。优点是数据复用率高，功耗和面积都漂亮；缺点是约束很死，一旦卷积stride不是1、或者padding不对称，阵列边界会出现严重空泡，编译器得把pad逻辑揉进地址计算里。二维FMA阵列风格：每个周期每个MAC单元都从本地Register或SRAM里取独立的数据，乘加后写回本地累加器。这种结构非常灵活，几乎任何数据排布都能跑，但代价是地址译码和控制逻辑更复杂，编译器输出的地址模式一旦没照顾到bank划分，带宽会掉得很难看。向量单元加标量核风格：底下的执行单元本质是一个长向量流水线，再配一个标量处理器做控制流。这种方式最灵活，也最容易编程，但需要软件把很多“踩满流水线”的活揽下来，否则利用率上不去。这三种风格没有绝对的好坏，关键看编译器团队能投入多少精力。脉动阵列对编译器要求高，但映射成功之后性能非常稳；二维FMA阵列看似好写，实际上软件要对每个bank的访问模式做精细管理。在架构探索阶段，我建议把“某个算子在所有映射风格下的指令条数、访存字节数、占用周期数”算出来，做成一张对照表。这张表会直接决定编译器调度策略怎么写，也会帮硬件团队发现他们引以为傲的数据通路在真实软件栈面前有多脆弱。有一点特别值得注意：很多算子在算法层面会做Im2Col变换，把卷积拍成GEMM。这种变换从数学上完全等价，但从硬件访存角度看，它会显著放大中间数据规模。如果你的硬件不能提供“Im2Col免拷贝”的物理寻址能力，软件就得真的腾出一块缓存重新摆数据，那个代价往往比多算几次乘法还大。这种“数学等价但硬件不等价”的问题，是软硬件协同里最常见的隐形冲突。2. 指令集的边界：该把哪些调度决策交给硬件2.1 指令粒度：从通用指令到固定流水很多人以为AI芯片的指令集就是SIMD加一点矩阵扩展，实际上，AI加速器的指令设计更像是在“通用性”和“控制开销”之间做折中。你不可能让每条指令都描述一个完整的GEMM，也不能每一个乘加周期都发一条指令，那样指令带宽和取指电路就会吃光所有面积。现在比较普遍的做法，是做一个三层指令结构。最外面是标量指令，负责循环控制和地址计算；中间是向量/张量指令，负责某个大块张量数据的搬运或者一次批量计算；最里面是微码流水，由硬件自己管理。编译器要做的，就是把算法代码翻译成一条条标量指令加较大粒度的张量指令，并确保张量指令之间尽量流水起来。在实际项目里，我见过一个常见的误设计：把指令粒度做得过大，比如一条指令可以控制整个“Conv + BN + ReLU”融合算子。听起来很高级，但遇到新的算子组合时，硬件微码根本不会匹配，只能退化成好几条低效小指令。反过来，也有团队把指令拆得太碎，结果算子里每做一个很小的切片都要同步一次，性能直接被同步开销拖垮。我的经验是，指令粒度以“一次能搬完的SRAM数据块”为单位去划分。一个张量关键路径上的操作，最好控制在3到5条指令内描述清楚，而不是让一条巨型指令包治百病。这样编译器既不用频繁发指令，也不会因为算子变形而束手无策。2.2 Kernel间握手的同步成本软硬件协同设计里，最容易被低估的是kernel之间的同步成本。一个网络模型通常被拆成十几个、几十个小kernel，每个kernel执行完，下一个kernel要等它的结果。如果硬件只在“整个芯片级别”提供事件同步，那么软件在开下一个kernel之前，必须去读状态寄存器、等待事件置位，这个等待过程看上去很短，但在动辄几百MHz到1GHz的芯片上，几十拍的空泡就是实际性能损失。更隐蔽的问题是kernel之间如果共用同一块SRAM，软件要确保上一个kernel把写缓冲清空。很多加速器会提供“写完buffer后自动发一个事件”的机制，但如果编译器没有把事件依赖关系建模清楚，硬件只能额外插入一个全空泡屏障，性能直接腰斩。我建议在指令集设计阶段，就明确规定哪些同步可以由硬件“接力”完成，哪些必须软件显式等待。例如，kernel A写到SRAM后，可以直接通过数据依赖寄存器把控制权交给kernel B，而不是让B的主控核先去轮询状态。后者虽然简单，但编译器的调度空间会被压缩得非常小。3. 存储系统：片上SRAM布局如何反推算子拆分策略3.1 Buffer分级与双缓冲的工程考量AI芯片的存储层次，通常从容量和延迟上分成外部DDR、全局SRAM、若干分布式SRAM，再到每个MAC阵列本地的Register文件。软件栈最核心的任务，就是在这几层里合理安排数据的位置和流动，让数据尽可能留在“离计算最近”的地方。双缓冲经常被当成解决存储瓶颈的万能药，其实它也是有代价的。双缓冲意味着你要把一个tile的数据准备两份空间，一份在算，一份在搬。如果片上SRAM本来就紧张，分配两份buffer后能放的tile更小，计算覆盖反而变差。真正要做的，是让编译器根据硬件的多级Buffer结构，提前计算“预取窗口”。比如当前kernel正在用buffer0计算时，DMA可以提前把下一个kernel需要的输入搬到buffer1。这个预取窗口的长度取决于计算时间和搬运时间的比值。如果计算快、搬运慢，窗口就得往前拉得很长，否则就算做了双缓冲，计算单元还是会空等。我记得有一次调一个4K分辨率输入的检测模型，硬件利用率只有40%，排查下来是DMA只搬运了当前kernel需要的输入像素，没有把卷积核覆盖区域之外的下一批数据提前搬进来。改了一版预取深度之后，利用率直接跳到了70%以上。这个收益不是硬件改动带来的，纯粹是存储调度策略的改善。3.2 一个tiling决策的伪代码推演片上SRAM容量有限，总装不下整个特征图，所以算子必须按tile拆分。tiling参数的选择，本质上就是解一个“片上存储容量约束下的面积覆盖最大化”问题。下面我用一段简化伪代码，演示如何根据SRAM容量，决定卷积输出tile的高度、宽度和输出通道数：def compute_tile(available_sram_bytes, dtype_bytes, IC, KH, KW, OH, OW, OC): # 初始tile：一个简单的输出点，一条输出通道 oh_tile = 1 ow_tile = 1 oc_tile = 1 while True: # 计算当前tile需要的片上空间： # 输入块 + 权重块 + 输出累加块 input_bytes = (IC * (oh_tile + KH - 1) * (ow_tile + KW - 1)) * dtype_bytes weight_bytes = (oc_tile * IC * KH * KW) * dtype_bytes output_bytes = (oh_tile * ow_tile * oc_tile) * dtype_bytes total_bytes = input_bytes + weight_bytes + output_bytes # 实际可用的SRAM一般要打八折， # 因为还要留出DMA描述符和地址对齐开销 if total_bytes > available_sram_bytes * 0.8: break # 优先扩大ow，减少输入块边界的额外面积 if ow_tile < OW: ow_tile *= 2 elif oh_tile < OH: oh_tile += 1 elif oc_tile < OC: oc_tile *= 2 else: break return oh_tile, ow_tile, oc_tile这段代码很粗糙，但它体现了tiling的核心逻辑：扩大ow方向时，输入块增加的是KW-1列边界，相对效率最高；扩大oc方向时，输入块不增加，但权重块线性增加；扩大oh方向时，输入块和输出块同时增加。编译器的tiling策略，就要在这个边界开销里找平衡。实际工程比这复杂得多，因为还要考虑SRAM内部bank划分、地址对齐到128字节、DMA搬移的burst长度。但思路是一样的：tiling从来不是算子自己拍脑袋定的，它直接由硬件的SRAM容量和带宽约束反推出来。换句话说，硬件存储结构设计得好不好，最终就看编译器能不能轻松切出高覆盖率的tile。4. 编译器和工具链：芯片Freeze前就要回答的问题4.1 算子库抽象层是第一份软硬件契约不少AI芯片项目会犯同一个时间顺序错误：先做硬件RTL，流片前半年才开始找编译器工程师。结果编译器一边写一边发现硬件少了一条状态位、多了一个bank冲突，只能通过寄存器配置去绕，最后绕出一堆屎山补丁。正确的节奏，应该是硬件还在架构探索阶段时，编译器团队就已经和架构师一起，把算子库的抽象层定义好。这个抽象层，是软硬件之间的第一份契约。它不直接暴露寄存器，而是暴露一批高层次算子接口，上层框架通过接口调用，底层再映射到具体硬件指令。一个算子库抽象层大概长这样：class ConvOp { public: struct Config { int inC, outC; int H, W, KH, KW; int strideH, strideW; int padH, padW; }; virtual void config(const Config& cfg) = 0; virtual void record(CommandStream* stream, Tensor& input, Tensor& weight, Tensor& bias, Tensor& output) = 0; virtual void synchronize(CommandStream* stream) = 0; };这层接口的价值在于，硬件团队初期改数据通路时，只要保证这些接口行为不变，编译器就不用大改；编译器团队也能在硬件RTL还没有出来的时候，先对着行为模型写代码。如果这层契约缺失，最典型的问题就是：上层框架直接拼算子汇编，每个算子的实现都凝结着某个硬件版本的历史包袱，后面一换架构，全部重写。这个教训我见过不止一次，项目延期往往不是硬件本身难，而是软件栈的“积累价值”没有被尊重。4.2 性能模型、模拟器和RTL怎么对齐工具链先行的另一个关键任务，是在RTL冻结之前建立一个可量化的性能模型。它不一定要求cycle accurate，但至少得做到cycle approximate，让编译器在调度策略上能看到趋势变化。性能模型和最终RTL之间的误差控制，是软硬件协同里的老难题。误差太大，编译器做的tiling、双缓冲预取、指令重排全部是白费；误差太小，开发性能模型的成本又几乎赶上一个简单模拟器。我的做法是，分阶段对齐。第一阶段只对齐几个典型算子的总周期数和SRAM访问次数，误差允许15%到20%。第二阶段对齐主要stall事件的比例，比如DMA等待、bank冲突、同步等待，误差控制在10%以内。第三阶段才对齐每个指令的cycle分布，这部分精度要求最高，但通常只有问题算子才需要较真。这里有一个非常重要的经验：性能模型的“周期数精确”远没有“stall分布精确”重要。因为编译器排错时，最怕的是不知道瓶颈在哪。如果模型告诉你80%的周期是DMA等待，即使总周期数差一些，你也知道下一步要去调预取；反过来，如果总周期数很准但完全看不出stall在哪儿，那这个模型对编译器调度几乎没有帮助。5. 联合调试：看到性能回退时我按什么顺序查5.1 先区分“访存受限”还是“计算受限”软硬件联调阶段，最常见的诉求是“性能回退”。算子明明在模拟器上性能不错，一上验证平台就往下掉。这时候我建议先不要急着翻波形，先用两个数字判断瓶颈方向：峰值算力F和可用带宽B。算力的单位是TOPS，带宽的单位是GB/s，两者相除得到“临界算术强度”。临界算术强度 = F / B (ops/Byte)如果实际算子的算术强度低于这个临界值，说明算子理论上是访存受限，那么即使MAC阵列全部空转，你也别太意外。如果算术强度远高于临界值，但MAC利用率还是差，那才是真正的计算侧问题。举例来说，一个峰值100TOPS的int8加速器，DDR带宽400GB/s，临界算术强度就是250 ops/Byte。而一个常见的3x3卷积，输入输出通道数都是128时，算术强度通常只有50到150 ops/Byte，明显访存受限。这时候你要做的第一件事，不是调整指令顺序，而是检查数据复用和片上数据驻留够不够。只有把数据的重复使用次数拉高，让算术强度跨过临界线，MAC阵列才有机会跑满。这个“算术强度”的判断方法非常朴素，但极其好用。很多性能问题推到根上，都是“喂数据的速度”和“算数据的速度”不匹配，而不是计算单元本身出了问题。5.2 精度异常与调度异常的交叉排查性能问题之外，联调时最让人头疼的是精度问题。这里说的不一定是数值溢出，更多是“软硬件两边算出来的结果在小数点后几位对不上”。我排查精度问题时，会先在软件参考实现里，把浮点累加顺序改成和硬件完全一致，再看结果差异。因为浮点加法不满足结合律，两个等价算法换一个累加顺序，结果就可能差几个ulp。如果硬件用的是FMA，软件参考用的是单独的乘加指令，差异更明显。还有一个容易踩的坑是混合精度的scale处理。很多模型会走int8量化，量化scale值本身也是浮点。如果硬件在计算某一层时自动把scale合进后续层的偏置里，而软件参考实现是按两步算的，那中间的张量就可能出现微小漂移。这种问题不是“谁错了”，而是“谁和谁约定一致”的问题。所以我建议软硬件两边，从一开始就约定一份“逐算子中间张量dump”机制。每个关键算子执行完，硬件侧能把指定buffer里的值导出成文件，软件侧也把标准参考结果导出成同一格式，逐元素对比。第一次跑通这种对比流程很麻烦，但后面每次修改架构或者编译策略，都能靠这个流程快速回归，省下大量联调时间。6. 设计节奏里的经验账：软硬件协同最常见几个坑6.1 架构还没定型就写寄存器手册？反过来的错更常见AI芯片项目里，有一种错误的顺序几乎每个团队都会踩一次：硬件架构师先画好了数据通路，后补寄存器手册，然后编译器团队拿着寄存器手册反推调度能力。这个方式的致命点在于，数据通路本身不一定“方便软件调度”，往往是先被面积、功耗、物理实现限制死了，软件能做的只是绕弯子。我建议在架构探索的早期，就让编译器工程师参与进“数据通路备选方案”的讨论。具体操作上，可以让编译器团队对每个备选方案，写一份“软硬件接口状态表”，里面明确列出：该方案能支持哪些算子形态、指令粒度、同步机制、地址对齐要求、可预测性有多强。打分不是凭感觉，而是基于一个可运行的简化性能模型。这听起来像管理流程，但本质上是在物理实现之前，把“软硬件能否配合”这个风险先降下来。芯片项目的延期，很多时候并不是某个模块做不出来，而是两个团队到了联调阶段才发现彼此理解的东西根本不一样。6.2 可用的性能基线比paper里的峰值重要得多最后想聊一个项目层面的问题。很多团队会把“峰值算力”当成芯片的核心KPI，开会、汇报、对外宣传全是TOPS。但真正做到软硬件协同的团队，心知肚明：真正决定用户体验的，是“真实模型里一组典型算子的平均利用率”和“编译一套网络的总时间”。我们自己做性能管理时，会维护一份“算子性能基线表”，覆盖卷积、矩阵乘、各种激活、归一化、池化、以及一些常见融合算子。每次硬件RTL改版本或者编译器调度器升级，都会自动跑一遍这份基线，任何算子利用率下降超过2个百分点，就要给出原因。这份基线跑起来非常枯燥，但它是团队长期迭代的锚点。没有它，硬件团队可以说自己改了某个设计，性能提升了，但没人知道它在别的模型里是不是反而退步了。没有它，编译器团队的各种优化也无从对比——优化了半天，数字还说不清楚。这个系列前几篇聊过很多架构选型层面的东西，但我实际工作里收益最大的一件事，反而是定好这份基线和“软硬件接口状态表”。每次改动，两边同时看，大量返工就消失了。如果你正在做AI芯片的软硬件协同，建议也尽早把这类“共同文档”立起来，它未必会写进任何新闻稿，却很可能决定你的项目到底能按时跑到什么程度。
每个做AI加速器的团队，几乎都遇到过这种场景：硬件团队说MAC阵列利用率跑到了98%，软件团队盯着执行时间说这绝对没到预期，两边各拿出一套数据，结果谁都没错。问题就出在软硬件协同设计上，而且多半不是单点失误，是整个栈的交互细节出了岔子。这篇是“AI芯片的软硬件设计”系列的第6篇，我想跳出性能对比表，聊聊项目落地过程中最消耗精力的那些交互点：算子怎么映射到硬件、指令集边界划在哪儿、存储结构如何反推编译策略、联调时软硬件两边到底该按什么顺序排错。内容适合正在做AI芯片编译器、加速器架构或算子库的工程师，也适合想弄明白“AI芯片为什么算法设计不难、难在系统协同”的人。接下来要讲的思路，很多来自实际项目里的反复试错，不一定每一条都对，但大概率能让你少踩几个坑。1. 算子在硬件上落地：数据通路和循环嵌套怎么互相妥协1.1 编译器看到的循环，和硬件看到的数据通路一个普通卷积算子，软件端写出来就是几层for循环：for (int oc = 0; oc < OC; oc++) { for (int oh = 0; oh < OH; oh++) { for (int ow = 0; ow < OW; ow++) { for (int ic = 0; ic < IC; ic++) { for (int kh = 0; kh < KH; kh++) { for (int kw = 0; kw < KW; kw++) { acc[oc][oh][ow] += input[ic][oh+kh][ow+kw] * weight[oc][ic][kh][kw]; } } } } } }但在硬件工程师眼里，这段代码完全不是这个形态。硬件只能看到一个数据通路：数据从哪块SRAM读出来、经过多少个乘加单元、暂存在哪个accumulator、最后以什么地址写回。所谓“硬件加速”，本质上是把软件里的循环计数器，换成了一套物理上并行流动的数据。这个差异是几乎所有软硬件分歧的源头。编译器把循环当成一个可重排的数学问题，硬件把循环当成一条精确到拍数的时空轨迹。互相之间谁都不知道对方约束了什么，后面就必然吵架。我见过最多的一种局面，是算法团队先跑通了一个浮点模型，硬件团队照着峰值算力把MAC阵列定了，编译器团队最后才介入，结果发现硬件的数据流格式只支持某一种循环顺序，编译器得为每个算子生成非常复杂的地址跳变逻辑。更糟的是，这种跳变会让片上存储bank冲突严重，最终利用率比paper上的理论值低一大截。1.2 三种硬件映射风格，对应的软件约束具体到卷积或者GEMM这类算子，业内现在的主流映射风格基本可以归成三类，它们对软件栈的约束完全不同：脉动阵列风格：数据像流水线一样在阵列里流动，每个PE从邻居拿数据，乘完继续传。优点是数据复用率高，功耗和面积都漂亮；缺点是约束很死，一旦卷积stride不是1、或者padding不对称，阵列边界会出现严重空泡，编译器得把pad逻辑揉进地址计算里。二维FMA阵列风格：每个周期每个MAC单元都从本地Register或SRAM里取独立的数据，乘加后写回本地累加器。这种结构非常灵活，几乎任何数据排布都能跑，但代价是地址译码和控制逻辑更复杂，编译器输出的地址模式一旦没照顾到bank划分，带宽会掉得很难看。向量单元加标量核风格：底下的执行单元本质是一个长向量流水线，再配一个标量处理器做控制流。这种方式最灵活，也最容易编程，但需要软件把很多“踩满流水线”的活揽下来，否则利用率上不去。这三种风格没有绝对的好坏，关键看编译器团队能投入多少精力。脉动阵列对编译器要求高，但映射成功之后性能非常稳；二维FMA阵列看似好写，实际上软件要对每个bank的访问模式做精细管理。在架构探索阶段，我建议把“某个算子在所有映射风格下的指令条数、访存字节数、占用周期数”算出来，做成一张对照表。这张表会直接决定编译器调度策略怎么写，也会帮硬件团队发现他们引以为傲的数据通路在真实软件栈面前有多脆弱。有一点特别值得注意：很多算子在算法层面会做Im2Col变换，把卷积拍成GEMM。这种变换从数学上完全等价，但从硬件访存角度看，它会显著放大中间数据规模。如果你的硬件不能提供“Im2Col免拷贝”的物理寻址能力，软件就得真的腾出一块缓存重新摆数据，那个代价往往比多算几次乘法还大。这种“数学等价但硬件不等价”的问题，是软硬件协同里最常见的隐形冲突。2. 指令集的边界：该把哪些调度决策交给硬件2.1 指令粒度：从通用指令到固定流水很多人以为AI芯片的指令集就是SIMD加一点矩阵扩展，实际上，AI加速器的指令设计更像是在“通用性”和“控制开销”之间做折中。你不可能让每条指令都描述一个完整的GEMM，也不能每一个乘加周期都发一条指令，那样指令带宽和取指电路就会吃光所有面积。现在比较普遍的做法，是做一个三层指令结构。最外面是标量指令，负责循环控制和地址计算；中间是向量/张量指令，负责某个大块张量数据的搬运或者一次批量计算；最里面是微码流水，由硬件自己管理。编译器要做的，就是把算法代码翻译成一条条标量指令加较大粒度的张量指令，并确保张量指令之间尽量流水起来。在实际项目里，我见过一个常见的误设计：把指令粒度做得过大，比如一条指令可以控制整个“Conv + BN + ReLU”融合算子。听起来很高级，但遇到新的算子组合时，硬件微码根本不会匹配，只能退化成好几条低效小指令。反过来，也有团队把指令拆得太碎，结果算子里每做一个很小的切片都要同步一次，性能直接被同步开销拖垮。我的经验是，指令粒度以“一次能搬完的SRAM数据块”为单位去划分。一个张量关键路径上的操作，最好控制在3到5条指令内描述清楚，而不是让一条巨型指令包治百病。这样编译器既不用频繁发指令，也不会因为算子变形而束手无策。2.2 Kernel间握手的同步成本软硬件协同设计里，最容易被低估的是kernel之间的同步成本。一个网络模型通常被拆成十几个、几十个小kernel，每个kernel执行完，下一个kernel要等它的结果。如果硬件只在“整个芯片级别”提供事件同步，那么软件在开下一个kernel之前，必须去读状态寄存器、等待事件置位，这个等待过程看上去很短，但在动辄几百MHz到1GHz的芯片上，几十拍的空泡就是实际性能损失。更隐蔽的问题是kernel之间如果共用同一块SRAM，软件要确保上一个kernel把写缓冲清空。很多加速器会提供“写完buffer后自动发一个事件”的机制，但如果编译器没有把事件依赖关系建模清楚，硬件只能额外插入一个全空泡屏障，性能直接腰斩。我建议在指令集设计阶段，就明确规定哪些同步可以由硬件“接力”完成，哪些必须软件显式等待。例如，kernel A写到SRAM后，可以直接通过数据依赖寄存器把控制权交给kernel B，而不是让B的主控核先去轮询状态。后者虽然简单，但编译器的调度空间会被压缩得非常小。3. 存储系统：片上SRAM布局如何反推算子拆分策略3.1 Buffer分级与双缓冲的工程考量AI芯片的存储层次，通常从容量和延迟上分成外部DDR、全局SRAM、若干分布式SRAM，再到每个MAC阵列本地的Register文件。软件栈最核心的任务，就是在这几层里合理安排数据的位置和流动，让数据尽可能留在“离计算最近”的地方。双缓冲经常被当成解决存储瓶颈的万能药，其实它也是有代价的。双缓冲意味着你要把一个tile的数据准备两份空间，一份在算，一份在搬。如果片上SRAM本来就紧张，分配两份buffer后能放的tile更小，计算覆盖反而变差。真正要做的，是让编译器根据硬件的多级Buffer结构，提前计算“预取窗口”。比如当前kernel正在用buffer0计算时，DMA可以提前把下一个kernel需要的输入搬到buffer1。这个预取窗口的长度取决于计算时间和搬运时间的比值。如果计算快、搬运慢，窗口就得往前拉得很长，否则就算做了双缓冲，计算单元还是会空等。我记得有一次调一个4K分辨率输入的检测模型，硬件利用率只有40%，排查下来是DMA只搬运了当前kernel需要的输入像素，没有把卷积核覆盖区域之外的下一批数据提前搬进来。改了一版预取深度之后，利用率直接跳到了70%以上。这个收益不是硬件改动带来的，纯粹是存储调度策略的改善。3.2 一个tiling决策的伪代码推演片上SRAM容量有限，总装不下整个特征图，所以算子必须按tile拆分。tiling参数的选择，本质上就是解一个“片上存储容量约束下的面积覆盖最大化”问题。下面我用一段简化伪代码，演示如何根据SRAM容量，决定卷积输出tile的高度、宽度和输出通道数：def compute_tile(available_sram_bytes, dtype_bytes, IC, KH, KW, OH, OW, OC): # 初始tile：一个简单的输出点，一条输出通道 oh_tile = 1 ow_tile = 1 oc_tile = 1 while True: # 计算当前tile需要的片上空间： # 输入块 + 权重块 + 输出累加块 input_bytes = (IC * (oh_tile + KH - 1) * (ow_tile + KW - 1)) * dtype_bytes weight_bytes = (oc_tile * IC * KH * KW) * dtype_bytes output_bytes = (oh_tile * ow_tile * oc_tile) * dtype_bytes total_bytes = input_bytes + weight_bytes + output_bytes # 实际可用的SRAM一般要打八折， # 因为还要留出DMA描述符和地址对齐开销 if total_bytes > available_sram_bytes * 0.8: break # 优先扩大ow，减少输入块边界的额外面积 if ow_tile < OW: ow_tile *= 2 elif oh_tile < OH: oh_tile += 1 elif oc_tile < OC: oc_tile *= 2 else: break return oh_tile, ow_tile, oc_tile这段代码很粗糙，但它体现了tiling的核心逻辑：扩大ow方向时，输入块增加的是KW-1列边界，相对效率最高；扩大oc方向时，输入块不增加，但权重块线性增加；扩大oh方向时，输入块和输出块同时增加。编译器的tiling策略，就要在这个边界开销里找平衡。实际工程比这复杂得多，因为还要考虑SRAM内部bank划分、地址对齐到128字节、DMA搬移的burst长度。但思路是一样的：tiling从来不是算子自己拍脑袋定的，它直接由硬件的SRAM容量和带宽约束反推出来。换句话说，硬件存储结构设计得好不好，最终就看编译器能不能轻松切出高覆盖率的tile。4. 编译器和工具链：芯片Freeze前就要回答的问题4.1 算子库抽象层是第一份软硬件契约不少AI芯片项目会犯同一个时间顺序错误：先做硬件RTL，流片前半年才开始找编译器工程师。结果编译器一边写一边发现硬件少了一条状态位、多了一个bank冲突，只能通过寄存器配置去绕，最后绕出一堆屎山补丁。正确的节奏，应该是硬件还在架构探索阶段时，编译器团队就已经和架构师一起，把算子库的抽象层定义好。这个抽象层，是软硬件之间的第一份契约。它不直接暴露寄存器，而是暴露一批高层次算子接口，上层框架通过接口调用，底层再映射到具体硬件指令。一个算子库抽象层大概长这样：class ConvOp { public: struct Config { int inC, outC; int H, W, KH, KW; int strideH, strideW; int padH, padW; }; virtual void config(const Config& cfg) = 0; virtual void record(CommandStream* stream, Tensor& input, Tensor& weight, Tensor& bias, Tensor& output) = 0; virtual void synchronize(CommandStream* stream) = 0; };这层接口的价值在于，硬件团队初期改数据通路时，只要保证这些接口行为不变，编译器就不用大改；编译器团队也能在硬件RTL还没有出来的时候，先对着行为模型写代码。如果这层契约缺失，最典型的问题就是：上层框架直接拼算子汇编，每个算子的实现都凝结着某个硬件版本的历史包袱，后面一换架构，全部重写。这个教训我见过不止一次，项目延期往往不是硬件本身难，而是软件栈的“积累价值”没有被尊重。4.2 性能模型、模拟器和RTL怎么对齐工具链先行的另一个关键任务，是在RTL冻结之前建立一个可量化的性能模型。它不一定要求cycle accurate，但至少得做到cycle approximate，让编译器在调度策略上能看到趋势变化。性能模型和最终RTL之间的误差控制，是软硬件协同里的老难题。误差太大，编译器做的tiling、双缓冲预取、指令重排全部是白费；误差太小，开发性能模型的成本又几乎赶上一个简单模拟器。我的做法是，分阶段对齐。第一阶段只对齐几个典型算子的总周期数和SRAM访问次数，误差允许15%到20%。第二阶段对齐主要stall事件的比例，比如DMA等待、bank冲突、同步等待，误差控制在10%以内。第三阶段才对齐每个指令的cycle分布，这部分精度要求最高，但通常只有问题算子才需要较真。这里有一个非常重要的经验：性能模型的“周期数精确”远没有“stall分布精确”重要。因为编译器排错时，最怕的是不知道瓶颈在哪。如果模型告诉你80%的周期是DMA等待，即使总周期数差一些，你也知道下一步要去调预取；反过来，如果总周期数很准但完全看不出stall在哪儿，那这个模型对编译器调度几乎没有帮助。5. 联合调试：看到性能回退时我按什么顺序查5.1 先区分“访存受限”还是“计算受限”软硬件联调阶段，最常见的诉求是“性能回退”。算子明明在模拟器上性能不错，一上验证平台就往下掉。这时候我建议先不要急着翻波形，先用两个数字判断瓶颈方向：峰值算力F和可用带宽B。算力的单位是TOPS，带宽的单位是GB/s，两者相除得到“临界算术强度”。临界算术强度 = F / B (ops/Byte)如果实际算子的算术强度低于这个临界值，说明算子理论上是访存受限，那么即使MAC阵列全部空转，你也别太意外。如果算术强度远高于临界值，但MAC利用率还是差，那才是真正的计算侧问题。举例来说，一个峰值100TOPS的int8加速器，DDR带宽400GB/s，临界算术强度就是250 ops/Byte。而一个常见的3x3卷积，输入输出通道数都是128时，算术强度通常只有50到150 ops/Byte，明显访存受限。这时候你要做的第一件事，不是调整指令顺序，而是检查数据复用和片上数据驻留够不够。只有把数据的重复使用次数拉高，让算术强度跨过临界线，MAC阵列才有机会跑满。这个“算术强度”的判断方法非常朴素，但极其好用。很多性能问题推到根上，都是“喂数据的速度”和“算数据的速度”不匹配，而不是计算单元本身出了问题。5.2 精度异常与调度异常的交叉排查性能问题之外，联调时最让人头疼的是精度问题。这里说的不一定是数值溢出，更多是“软硬件两边算出来的结果在小数点后几位对不上”。我排查精度问题时，会先在软件参考实现里，把浮点累加顺序改成和硬件完全一致，再看结果差异。因为浮点加法不满足结合律，两个等价算法换一个累加顺序，结果就可能差几个ulp。如果硬件用的是FMA，软件参考用的是单独的乘加指令，差异更明显。还有一个容易踩的坑是混合精度的scale处理。很多模型会走int8量化，量化scale值本身也是浮点。如果硬件在计算某一层时自动把scale合进后续层的偏置里，而软件参考实现是按两步算的，那中间的张量就可能出现微小漂移。这种问题不是“谁错了”，而是“谁和谁约定一致”的问题。所以我建议软硬件两边，从一开始就约定一份“逐算子中间张量dump”机制。每个关键算子执行完，硬件侧能把指定buffer里的值导出成文件，软件侧也把标准参考结果导出成同一格式，逐元素对比。第一次跑通这种对比流程很麻烦，但后面每次修改架构或者编译策略，都能靠这个流程快速回归，省下大量联调时间。6. 设计节奏里的经验账：软硬件协同最常见几个坑6.1 架构还没定型就写寄存器手册？反过来的错更常见AI芯片项目里，有一种错误的顺序几乎每个团队都会踩一次：硬件架构师先画好了数据通路，后补寄存器手册，然后编译器团队拿着寄存器手册反推调度能力。这个方式的致命点在于，数据通路本身不一定“方便软件调度”，往往是先被面积、功耗、物理实现限制死了，软件能做的只是绕弯子。我建议在架构探索的早期，就让编译器工程师参与进“数据通路备选方案”的讨论。具体操作上，可以让编译器团队对每个备选方案，写一份“软硬件接口状态表”，里面明确列出：该方案能支持哪些算子形态、指令粒度、同步机制、地址对齐要求、可预测性有多强。打分不是凭感觉，而是基于一个可运行的简化性能模型。这听起来像管理流程，但本质上是在物理实现之前，把“软硬件能否配合”这个风险先降下来。芯片项目的延期，很多时候并不是某个模块做不出来，而是两个团队到了联调阶段才发现彼此理解的东西根本不一样。6.2 可用的性能基线比paper里的峰值重要得多最后想聊一个项目层面的问题。很多团队会把“峰值算力”当成芯片的核心KPI，开会、汇报、对外宣传全是TOPS。但真正做到软硬件协同的团队，心知肚明：真正决定用户体验的，是“真实模型里一组典型算子的平均利用率”和“编译一套网络的总时间”。我们自己做性能管理时，会维护一份“算子性能基线表”，覆盖卷积、矩阵乘、各种激活、归一化、池化、以及一些常见融合算子。每次硬件RTL改版本或者编译器调度器升级，都会自动跑一遍这份基线，任何算子利用率下降超过2个百分点，就要给出原因。这份基线跑起来非常枯燥，但它是团队长期迭代的锚点。没有它，硬件团队可以说自己改了某个设计，性能提升了，但没人知道它在别的模型里是不是反而退步了。没有它，编译器团队的各种优化也无从对比——优化了半天，数字还说不清楚。这个系列前几篇聊过很多架构选型层面的东西，但我实际工作里收益最大的一件事，反而是定好这份基线和“软硬件接口状态表”。每次改动，两边同时看，大量返工就消失了。如果你正在做AI芯片的软硬件协同，建议也尽早把这类“共同文档”立起来，它未必会写进任何新闻稿，却很可能决定你的项目到底能按时跑到什么程度。