1. 从能跑模型到跑得高效AI芯片软硬件协同设计的核心命题很多人第一次接触AI芯片注意力都放在算力数字上——多少TOPS、多少TFLOPS、功耗多少瓦。但真正做过芯片落地的人都知道纸面算力只是入场券能不能把算力喂饱才是决定实际性能的关键。我见过太多项目芯片峰值算力标得很漂亮实际跑起模型来利用率连30%都不到问题几乎都出在软硬件没有协同设计上。所谓AI芯片的软硬件设计本质上是解决一个匹配问题硬件提供什么样的计算资源和存储层次软件编译器、运行时、算子库就要围绕这些资源去调度和映射。两者如果各做各的硬件按通用思路堆MAC阵列软件按通用框架做图优化最后的结果就是数据在片上来回搬运计算单元大量空转。这个系列的第二篇我想把重点放在协同这两个字上聊聊硬件架构怎么为软件留接口软件又怎么反过来约束硬件设计。这篇文章适合几类人看正在做AI加速器架构设计的工程师、做推理框架或编译器的开发者、以及想理解为什么同样算力的芯片实际表现差这么多的技术管理者。我会尽量把原理讲透同时给出可操作的思路和参数参考而不是停留在概念层面。全文围绕数据流、存储层次、量化支持、编译器协同、验证方法这几个核心维度展开每一块都会说明为什么这么设计以及实际做的时候要注意什么。2. 数据流决定成败三种主流架构的取舍逻辑2.1 为什么数据搬运比计算更值得关注先建立一个基本认知在典型的AI计算中一次乘加运算MAC消耗的能量远小于从片外内存读取一个操作数消耗的能量。有研究给出的量级是32位浮点乘法大约几个皮焦而从DRAM读一个数可能是几百皮焦差距在两个数量级以上。这意味着如果数据复用做得不好芯片的功耗和延迟会被内存访问彻底主导计算单元再强也没用。所以AI芯片设计的第一性问题不是怎么算得快而是怎么让数据少搬。这就引出了数据流Dataflow的概念。数据流描述的是在计算阵列中权重、激活值、部分和这三类数据各自沿着什么路径流动、在哪里被复用、复用多少次。不同的数据流方案直接决定了片上缓存的需求量、带宽压力和能效比。2.2 权重 stationary、输出 stationary 与行 stationary 的对比业界最常讨论的三类数据流是权重固定Weight Stationary, WS、输出固定Output Stationary, OS和行固定Row Stationary, RS。我用一个通俗的类比来解释想象一个厨房厨师是计算单元食材是数据。WS相当于把常用调料固定在灶台边做很多道菜都不用重新取OS相当于把出锅的盘子固定住每道菜做好直接装盘RS则是折中让某一行的操作共享食材。数据流类型复用重点优势场景主要代价权重固定 WS权重在PE内复用权重矩阵大、batch小的推理激活值复用低部分和搬运多输出固定 OS部分和留在PE卷积核小、通道多的场景权重和激活都需要频繁加载行固定 RS三者折中复用通用卷积加速控制逻辑复杂PE利用率波动实际做架构时很少纯粹用某一种更多是混合策略。比如在卷积层用RS思路在全连接层切换到WS。我个人的经验是先根据目标模型的主力算子分布来定主数据流再针对少数算子做特化。如果目标模型以Transformer为主注意力机制里的矩阵乘和softmax对数据流的要求完全不同这时候一刀切的数据流设计会吃亏。2.3 片上存储层次怎么配合数据流数据流定了存储层次就要跟着设计。典型的AI芯片片上存储分三级寄存器文件RF、片上缓存SRAM常分全局缓冲和本地缓冲、以及片外DRAM。设计时要回答几个问题权重放哪一级、激活放哪一级、部分和放哪一级、每一级的容量和带宽配多少。一个实用的估算方法是先算出目标算子在最优数据流下的理论复用次数反推每一级需要的带宽。比如一个PE阵列有256个MAC如果权重复用次数是64那么权重加载带宽只需要满足每64个周期加载一次新权重即可对带宽要求就低很多。反过来如果激活复用差激活带宽需求就会飙升这时候要么加大本地SRAM要么改数据流。注意片上SRAM面积和功耗都不小盲目加大容量会推高成本。更聪明的做法是通过数据流优化降低对容量的需求而不是用容量去弥补数据流的缺陷。3. 量化不是降精度那么简单数值格式与硬件支持的配合3.1 从FP32到INT8再到FP8的演进逻辑训练阶段普遍用FP32或BF16推理阶段则大量转向INT8甚至INT4。这个演进背后的逻辑很直接推理对数值精度的容忍度比训练高而低位宽能带来成倍的能效和面积收益。一个INT8乘法器的面积大约是同架构FP16乘法器的四分之一到三分之一功耗也低得多。但量化不是简单地把浮点数截断成整数。它涉及一个映射过程把浮点范围线性映射到整数范围需要确定缩放因子scale和零点zero point。如果映射参数选得不好精度损失会集中在某些层导致整体准确率崩塌。硬件设计上要支持量化就必须在计算单元里内置相应的处理逻辑比如INT8的乘累加、以及反量化时的缩放操作。3.2 硬件需要为量化提供哪些原生支持很多团队做量化时踩的坑是算法团队在软件层面把模型量化好了结果发现硬件不支持对应的数据格式或者支持得很别扭导致要么回退到高精度要么性能大打折扣。所以硬件在设计初期就要明确支持哪些数值格式。我的建议是至少原生支持INT8和INT4并预留对FP8或BF16的支持接口。具体来说硬件需要具备混合精度的乘累加单元能处理不同位宽输入、可配置的累加器位宽避免低位宽累加溢出、以及反量化的硬件通路把INT32累加结果缩放回目标精度。累加器位宽这点特别容易被忽略INT8乘INT8的结果是INT16但累加很多次后需要更宽的位宽通常用INT32比较稳妥。3.3 量化感知训练与硬件仿真的闭环软件侧要做的是让量化过程感知硬件的实际行为。纯后训练量化PTQ速度快但对敏感层不友好量化感知训练QAT在训练时就模拟量化误差精度更稳但成本高。无论哪种都需要一个硬件仿真环节在软件里模拟硬件的量化、累加、溢出行为验证量化后的模型在目标硬件上的实际精度。这个闭环很关键。我见过项目因为跳过了硬件仿真软件量化精度看着没问题一上板就掉点排查了很久才发现是累加器溢出导致的。所以流程应该是量化算法设计 → 硬件行为仿真 → 精度验证 → 上板实测每一步都要对齐。4. 编译器与硬件的握手指令集和调度接口的设计4.1 为什么通用指令集在AI芯片上不好用如果AI芯片直接用类似通用CPU的指令集编译器就很难发挥硬件的并行能力。原因是AI计算的模式高度规整大量矩阵乘、卷积而通用指令集是为通用性设计的指令粒度和数据并行度都不匹配。结果就是编译器要么生成大量低效指令要么需要极其复杂的调度。所以AI芯片通常设计专用指令或者采用粗粒度可重构的思路。指令的粒度可以是一条向量乘加、一次DMA搬运、或者一个完整的算子调用。粒度越粗编译器负担越轻但灵活性越低粒度越细灵活但调度复杂。这个平衡点要根据目标模型的可预测性来定。4.2 编译器需要从硬件拿到哪些信息编译器要生成高效代码必须知道硬件的脾气。具体包括计算阵列的维度比如16x16的MAC阵列、各级存储的容量和延迟、DMA的通道数和带宽、支持的数值格式、以及指令的流水线特性比如乘加需要几个周期出结果。这些信息通常通过一个硬件描述文件类似target description传给编译器。设计这个描述文件时要尽量完整且准确因为编译器会基于它做调度决策。如果描述不准编译器可能生成看似合理但实际低效的代码。我建议在硬件流片前就用FPGA或仿真器把这份描述验证一遍确保编译器能正确理解硬件。4.3 算子融合与内存分配的协同编译器优化的两个重头戏是算子融合和内存分配。算子融合把多个连续算子合并成一个计算核减少中间结果的搬运内存分配则决定张量在片上存储的布局和复用。这两件事必须和硬件的数据流、存储层次配合。举个例子如果硬件支持在PE内保留部分和编译器就应该尽量把需要累加的算子融合在一起让部分和不用写回。如果硬件有专门的激活函数单元编译器就应该把激活算子调度到那个单元上而不是用通用计算单元算。这些协同点需要在编译器和硬件团队之间反复对齐最好在架构定义阶段就拉上编译器的人一起讨论。5. 验证与实测怎么确认软硬件真的协同好了5.1 从RTL仿真到FPGA原型的分阶段验证AI芯片的验证不能等到流片后。常规做法是分阶段先用RTL仿真验证功能正确性再用FPGA原型验证性能和软件栈最后流片后做硅后验证。每个阶段的侧重点不同。RTL仿真主要看功能跑几个小算子确认数据通路没问题。FPGA原型则能跑真实模型这时候就能测出实际的吞吐、延迟、能效也能暴露编译器和硬件的配合问题。我强烈建议在FPGA阶段就把目标模型完整跑一遍包括量化后的版本因为很多问题只有真实负载才能触发。5.2 性能剖析找到真正的瓶颈跑起来之后下一步是剖析性能。常用的指标包括计算单元利用率、各级存储的带宽占用、DMA的忙碌程度、以及端到端的延迟分解。通过这些数据能定位瓶颈到底在计算、存储还是调度。一个常见的误区是只看平均利用率。平均值会掩盖局部的空转。更好的做法是看时间线上的利用率曲线找出利用率骤降的时段再对应到具体的算子或数据搬运上。我遇到过整体利用率70%但某些层只有20%的情况优化那几个层之后整体提升很明显。5.3 软硬件协同的迭代节奏最后说迭代节奏。软硬件协同不是一次性的而是持续迭代的过程。硬件流片后基本定型但软件编译器、算子库、调度策略可以持续优化。所以合理的节奏是硬件设计时预留足够的灵活性比如可配置的存储划分、可调的调度参数软件侧则建立快速的迭代和回归测试流程。提示在硬件里预留一些软件可调的参数比如缓存划分比例、DMA优先级能让后期优化省很多事。这些参数在流片前定死后期就只能靠软件绕成本高得多。6. 一些实际项目中的经验与取舍做AI芯片软硬件设计这些年有几个体会比较深。第一不要追求全能。一款芯片很难同时把训练和推理、云端和边缘都做到最优明确目标场景比堆参数重要。第二软硬件团队要尽早坐在一起。架构定义阶段如果只有硬件的人拍板软件后期会很痛苦。第三量化支持和编译器友好度往往比峰值算力更能决定实际体验。还有一个容易被低估的点是工具链的成熟度。硬件再好如果编译器难用、调试工具缺失落地速度会大打折扣。所以在资源分配上工具链的投入不能省。我见过算力中规中矩但工具链顺手的芯片实际项目落地反而比算力更强但工具链难用的芯片快。关于数据流和存储层次的具体参数没有放之四海皆准的答案必须结合目标模型和工艺节点去算。但方法论是通用的先定目标负载再推数据流再配存储最后用编译器和实测去验证和微调。这个顺序如果乱了后面会反复返工。