1. 从能跑就行到跑得高效AI芯片软硬件协同设计的核心命题做AI芯片这行的人都有一个共识一颗芯片流片回来真正决定它能不能用的往往不是峰值算力有多高而是软硬件之间的配合有没有做到位。我见过太多团队硬件指标做得很漂亮TOPS数字往PPT上一放确实唬人但实际部署模型的时候利用率连30%都不到。问题出在哪出在软硬件设计的割裂。这个系列写到第10篇我想把之前散落在各个章节里的软硬件协同思路做一次系统性的梳理。不管你是做芯片架构的、做编译器的、还是做算法部署的只要你的工作和AI芯片沾边这些内容应该都能帮你少走一些弯路。核心就一件事怎么让算法在芯片上跑得又快又稳同时让芯片的设计不因为算法的快速迭代而迅速过时。先说一个基本判断。AI芯片和传统通用处理器的最大区别在于它的架构设计必须预判未来两到三年主流算法的计算模式。你不可能像CPU那样靠通用性吃十年AI芯片的架构红利窗口期很短。所以软硬件协同设计不是一个可选项而是生存必需。硬件团队要理解主流模型的算子分布、访存特征、精度需求软件团队要理解硬件的流水线结构、存储层次、并行粒度。两边如果各干各的最后一定是硬件资源浪费、软件性能上不去。这篇文章会从计算模式分析、存储层次设计、数据流调度、编译映射、精度与能效权衡这几个维度展开每个部分都会给出具体的分析方法和实操建议。我会尽量用实际项目中的例子来说明但涉及具体产品信息的地方会做模糊处理。2. 算法计算模式的前置分析硬件架构设计的起点2.1 为什么不能只看TOPS指标很多团队在做AI芯片架构定义的时候第一件事就是定一个TOPS目标然后倒推需要多少个MAC单元、多大的片上缓存。这个思路本身没错但问题在于TOPS这个指标太粗了。同样是100TOPS的芯片跑Transformer和跑卷积神经网络实际性能可能差出好几倍。原因在于不同的算法计算模式对硬件的需求完全不同。卷积神经网络的核心是大规模的乘加运算数据复用率高适合用脉动阵列或者类似的二维计算阵列来处理。而Transformer的核心是矩阵乘法和注意力机制它的访存模式更复杂对片上存储的带宽和容量要求更高。如果你用一套固定的架构去跑所有模型必然有一类模型跑不好。我在实际项目中总结了一个方法在架构定义阶段先做一轮算法计算模式的前置分析。具体来说就是收集目标应用场景下最可能部署的5到10个代表性模型然后做以下几件事统计算子类型分布卷积、矩阵乘、激活函数、归一化、池化各占多少比例分析访存特征每个算子的输入输出数据量、复用次数、访存模式顺序、随机、广播计算算术强度每字节访存对应的计算操作数这个指标直接决定了你是计算瓶颈还是带宽瓶颈评估并行度算子内部和算子之间有多少可并行的维度这些分析做完之后你才能知道你的芯片应该往哪个方向倾斜。如果算术强度普遍很高那就堆计算单元如果算术强度低那就要把重点放在存储带宽和缓存设计上。2.2 算子分布统计的实操方法具体怎么做算子分布统计最直接的办法是用推理框架的profiling工具跑一遍模型导出每个算子的耗时和调用次数。但这里有个坑耗时统计会受到框架实现质量的影响有些算子框架实现得不好耗时就偏高但这不代表它在硬件上一定慢。更可靠的方法是做静态分析。把模型的计算图导出来遍历每个节点统计算子类型和tensor shape。然后根据shape计算出理论计算量和理论访存量。这两个数据结合起来就能得到每个算子的算术强度。我一般会做一个表格把每个算子的以下信息列出来算子类型计算量(MACs)输入数据量输出数据量算术强度占比Conv 3x3计算值计算值计算值计算值百分比MatMul计算值计算值计算值计算值百分比..................这张表做出来之后你一眼就能看出哪些算子是计算密集的哪些是访存密集的。计算密集的算子适合用专用计算单元加速访存密集的算子则需要优化数据搬运和缓存策略。2.3 从算子分布到架构决策有了算子分布数据接下来就是做架构决策。这里我分享一个实际项目中的决策逻辑。假设你的目标场景是边缘端的视觉推理算子分布显示卷积占了80%以上的计算量且主要是3x3和1x1卷积。那么你的架构重点应该是第一设计一个高效的卷积计算阵列。3x3卷积的复用模式很规整适合用行固定或者列固定的数据流。1x1卷积本质上就是矩阵乘可以复用同一套计算阵列。第二片上缓存要能装下足够多的特征图。卷积的输入特征图复用率很高如果缓存不够就会频繁访问外部存储带宽立刻成为瓶颈。第三激活函数和池化这些轻量级算子可以放在后处理单元里做不需要占用主计算阵列的资源。反过来如果你的目标场景是自然语言处理矩阵乘和注意力机制占主导那架构设计的重点就完全不同。矩阵乘的维度通常很大需要计算阵列有足够的灵活性来适应不同的矩阵形状。注意力机制涉及大量的中间结果存储对片上存储的容量和带宽要求极高。这里的关键点是架构决策必须由数据驱动而不是由直觉或者竞品分析驱动。竞品的架构选择是基于他们的目标场景做的你的场景不一样照搬没有意义。3. 存储层次的设计取舍带宽、容量与延迟的三角博弈3.1 AI芯片存储层次的典型结构AI芯片的存储层次一般分为四级寄存器文件、片上缓存、片外缓存、主存。每一级的带宽、容量和延迟都差着数量级。设计的核心挑战在于怎么用有限的片上存储资源支撑起计算单元对数据的需求。寄存器文件离计算单元最近带宽最高但容量极小通常只有几十KB到几百KB。它的作用是暂存当前计算周期需要的数据设计时要考虑读写端口数量和位宽是否匹配计算单元的吞吐。片上缓存是AI芯片设计中最关键的一层。它通常由SRAM构成容量在几MB到几十MB之间。片上缓存的带宽直接决定了计算单元能不能吃饱。我见过一些设计计算阵列的理论算力很高但片上缓存带宽不够导致计算单元经常空转。片外缓存一般是DRAM容量大但带宽有限延迟也高。它的作用是存放模型参数和中间结果中暂时不用的部分。设计时要重点考虑的是怎么通过数据预取和调度把片外访问的延迟隐藏起来。3.2 片上缓存容量的计算方法片上缓存要多大才够这个问题没有标准答案但有一个计算方法可以参考。首先确定你的目标模型的最大单层特征图尺寸。以卷积网络为例假设某一层的输入特征图是H×W×C卷积核是K×K输出通道数是N。那么这一层需要同时驻留在片上的数据包括输入特征图的一个滑动窗口、卷积核权重、输出特征图的部分结果。输入特征图的滑动窗口大小取决于你的数据流设计。如果采用行固定数据流窗口大小大约是K×W×C。卷积核权重是K×K×C×N。输出特征图的部分结果取决于输出通道的并行度。把这些加起来再乘以一个安全系数一般取1.5到2就是片上缓存的最小容量需求。当然实际设计中还要考虑多层的流水线并行缓存容量需要更大。但缓存不是越大越好。SRAM的面积和功耗都很大缓存容量增加一倍面积可能增加80%以上。所以要在性能和成本之间找平衡点。我的经验是对于边缘端芯片片上缓存控制在几MB到十几MB比较合理对于数据中心芯片可以做到几十MB甚至上百MB。3.3 带宽匹配的量化分析方法存储层次设计中最容易出问题的地方是带宽匹配。计算单元的吞吐和存储层次的带宽必须匹配否则要么计算单元饿死要么存储带宽浪费。量化分析的方法很简单计算计算单元在每个周期需要多少字节的数据然后对比存储层次能提供多少字节的带宽。举个例子。假设你的计算阵列有256个MAC单元每个MAC每个周期做一次乘加。如果数据位宽是8位那么每个周期需要读取256×2×1字节512字节的数据每个MAC需要两个操作数。如果片上缓存的带宽只有256字节/周期那计算单元就只能跑到50%的利用率。解决带宽匹配问题有几个思路一是提高数据复用率让每个数据被多个MAC单元共享二是增加片上缓存的带宽比如用多bank并行访问三是调整计算阵列的结构减少每个周期需要的数据量。数据复用是最有效的手段。以卷积为例同一个卷积核权重会被多个输出位置复用同一个输入特征图会被多个卷积核复用。通过合理的数据流设计可以把带宽需求降低一个数量级。4. 数据流调度策略决定实际性能的隐形之手4.1 数据流的本质在正确的时间把正确的数据放到正确的位置数据流调度这个词听起来很玄乎但本质很简单就是在正确的时间把正确的数据放到正确的位置。AI芯片的计算单元就像一条生产线数据流调度就是生产线的物流系统。物流系统设计得好生产线满负荷运转设计得不好生产线经常停工等料。AI芯片中常见的数据流模式有三种权重固定、输出固定、行固定。每种模式适合不同的场景没有绝对的优劣。权重固定数据流是指卷积核权重在计算过程中保持不变输入特征图和输出特征图在计算阵列中流动。这种模式适合卷积核较小的场景因为权重占用的存储空间小可以常驻在寄存器里。输出固定数据流是指输出特征图的部分结果在计算阵列中保持不变输入特征图和权重在流动。这种模式适合输出通道数较多的场景因为输出结果可以累积在寄存器里不需要频繁读写。行固定数据流是指输入特征图的一行在计算阵列中保持不变权重和输出在流动。这种模式适合输入特征图较大的场景因为一行数据可以覆盖多个输出位置。4.2 数据流选择的决策框架怎么选数据流我一般从三个维度来评估数据复用率、存储访问次数、控制复杂度。数据复用率越高越好因为这意味着同样的数据被用了更多次访存需求更低。存储访问次数越少越好因为访存是能耗的主要来源。控制复杂度越低越好因为复杂的控制逻辑会占用芯片面积和功耗预算。具体来说我会做一个简单的模拟给定一个典型的卷积层参数输入通道数、输出通道数、特征图尺寸、卷积核大小分别用三种数据流模式计算总访存次数和总计算周期数。然后选综合表现最好的那个。但实际设计中往往不是选一种数据流就完事了。很多芯片会支持多种数据流模式根据不同的算子类型动态切换。比如卷积用行固定矩阵乘用输出固定。这样做的好处是灵活性高代价是控制逻辑更复杂。4.3 双缓冲与流水线设计数据流调度中有一个关键技术双缓冲。它的作用是在计算当前数据块的同时预取下一个数据块。这样计算单元就不需要等待数据加载可以连续运转。双缓冲的实现需要两倍的缓存空间但带来的性能提升往往很显著。我做过一个测试在同样的硬件配置下加入双缓冲后计算单元利用率从60%提升到了85%以上。流水线设计是另一个关键点。AI芯片的计算通常可以分为多个阶段数据加载、计算、结果写回。如果这些阶段串行执行效率很低。通过流水线设计让不同阶段并行执行可以大幅提升吞吐。但流水线设计要注意一个问题流水线的深度要和计算任务的粒度匹配。如果任务粒度太小流水线填充和排空的开销占比就高反而降低效率。一般来说流水线深度在3到5级比较合适任务粒度要保证每个阶段的工作时间大致相等。5. 编译器与硬件的握手从模型到指令的映射艺术5.1 编译器在AI芯片中的角色定位编译器是连接算法和硬件的桥梁。算法工程师用框架写模型编译器把模型翻译成硬件能执行的指令。这个翻译过程的质量直接决定了硬件的实际性能。很多硬件团队不重视编译器觉得编译器就是个工具硬件做好了性能自然就上去了。这个想法很危险。我见过太多案例硬件理论性能很高但因为编译器映射得不好实际性能只有理论值的零头。编译器要解决的核心问题是如何把计算图切分成硬件能处理的块如何为每个块分配存储资源如何调度指令让计算单元和存储单元并行工作。这些问题解决得好不好取决于编译器对硬件架构的理解深度。5.2 算子融合的收益与代价算子融合是编译器优化中最常用的手段。它的基本思路是把多个连续的算子合并成一个计算核减少中间结果的存储和访存。以卷积网络为例Conv BN ReLU是三个连续的算子。如果不融合需要把Conv的输出写回内存再读出来做BN再写回再读出来做ReLU。三次访存的开销很大。如果融合成一个算子Conv的输出直接在做BN和ReLU中间结果不需要写回内存访存次数减少三分之二。但算子融合不是没有代价的。融合后的算子需要更多的寄存器来暂存中间结果对片上存储的压力更大。而且融合后的算子复杂度高编译器的调度难度也更大。我的经验是优先融合访存密集的算子组合比如ConvBNReLU、MatMulAddSoftmax。对于计算密集的算子融合的收益相对较小可以不做。5.3 内存分配与生命周期分析编译器另一个重要任务是内存分配。模型中的每个tensor都需要存储空间但不同tensor的生命周期不同。有些tensor只在几个算子之间使用用完就可以释放有些tensor需要一直保留到模型结束。通过生命周期分析编译器可以复用存储空间。比如tensor A在第1到第3层使用tensor B在第4到第6层使用那么A和B可以共用同一块内存。这种复用可以大幅降低内存需求。但内存复用有一个约束不能影响计算的正确性。如果两个tensor的生命周期有重叠就不能复用。编译器需要做精确的生命周期分析确保复用的安全性。在实际项目中我一般会要求编译器团队输出一份内存分配报告列出每个tensor的分配地址、大小、生命周期。这份报告可以帮助硬件团队评估片上缓存是否够用也可以帮助算法团队优化模型结构。6. 精度与能效的平衡量化策略的工程实践6.1 量化为什么是AI芯片的必修课量化是把浮点模型转换成定点模型的过程。它的好处很直接定点运算的硬件面积和功耗都远低于浮点运算。同样一颗芯片用定点运算可以做到更高的算力和更低的功耗。但量化会带来精度损失。如何在精度和能效之间找到平衡点是AI芯片软硬件设计中最具挑战性的问题之一。量化的核心是确定每个tensor的缩放因子和零点。缩放因子决定了定点数的表示范围零点决定了定点数的表示偏移。这两个参数选得好精度损失就小选得不好模型可能直接跑崩。6.2 训练后量化与量化感知训练的选择量化方法主要分两类训练后量化和量化感知训练。训练后量化是在模型训练完成后用一批校准数据统计每个tensor的数值分布然后确定量化参数。这种方法的优点是简单快捷不需要重新训练模型。缺点是精度损失可能较大尤其是对于数值分布不均匀的模型。量化感知训练是在训练过程中模拟量化操作让模型适应量化带来的精度损失。这种方法的优点是精度损失小通常可以做到和浮点模型几乎一样的精度。缺点是需要重新训练模型成本较高。怎么选我的建议是如果模型对精度不敏感比如分类任务优先用训练后量化快速验证。如果模型对精度敏感比如检测、分割任务或者训练后量化的精度损失超过可接受范围那就用量化感知训练。6.3 混合精度的硬件支持混合精度是指模型中不同的部分使用不同的精度。比如卷积层用8位定点全连接层用16位定点输出层用浮点。这种策略可以在保证精度的同时最大化能效。但混合精度对硬件的要求更高。计算单元需要支持多种精度的运算存储系统需要支持不同精度的数据读写。这增加了硬件设计的复杂度。从软件角度看混合精度需要编译器能够自动分析每个算子的精度需求并分配合适的精度。这需要编译器对模型的数值特性有深入的理解。我在实际项目中的做法是先做一轮精度敏感性分析找出对精度最敏感的算子这些算子用高精度其余算子用低精度。然后让编译器根据这个分析结果做精度分配。这样既保证了精度又最大化了能效。7. 软硬件协同验证流片前的最后一道防线7.1 协同验证的必要性AI芯片的验证比传统芯片更复杂因为它的行为不仅取决于硬件逻辑还取决于软件调度。同样的硬件不同的软件调度策略性能可能差好几倍。所以验证必须覆盖软硬件协同的场景。协同验证的目标是在流片前尽可能真实地模拟芯片在实际部署中的行为发现性能瓶颈和功能错误。7.2 验证平台的搭建协同验证平台一般包括三个部分硬件模型、软件栈、测试用例。硬件模型可以是RTL仿真也可以是FPGA原型。RTL仿真的精度高但速度慢适合做功能验证。FPGA原型的速度快但精度稍低适合做性能和压力测试。软件栈包括编译器、运行时、驱动程序。这些软件需要在验证平台上真实运行才能发现软硬件接口的问题。测试用例要覆盖目标应用场景中的典型模型和典型输入。我一般会准备三组测试用例一组是功能测试验证模型输出是否正确一组是性能测试测量端到端延迟和吞吐一组是压力测试用极端输入验证系统的稳定性。7.3 常见协同问题与排查方法在协同验证中最常见的问题有三类数据一致性问题、性能不达预期问题、边界条件问题。数据一致性问题通常表现为模型输出和预期不符。排查方法是逐层对比硬件输出和软件参考输出定位到出错的层然后检查该层的数据流和存储访问。性能不达预期问题通常表现为实际延迟远高于理论值。排查方法是做性能剖析找出瓶颈在计算、存储还是调度。如果是计算瓶颈检查计算单元利用率如果是存储瓶颈检查缓存命中率和带宽利用率如果是调度瓶颈检查指令流水线是否有气泡。边界条件问题通常出现在输入尺寸不是2的幂次、通道数不是计算阵列的整数倍等情况下。排查方法是构造边界测试用例覆盖各种非对齐的输入。8. 一些踩过的坑和总结的经验做AI芯片软硬件设计这些年踩过的坑不少这里分享几个印象深刻的。第一个坑是过度追求峰值算力。早期做架构设计的时候总想把TOPS做高结果计算阵列堆得很大但片上缓存带宽跟不上实际利用率很低。后来才明白AI芯片的性能是木桶效应最短的那块板决定实际性能。计算、存储、调度任何一个环节拖后腿整体性能就上不去。第二个坑是忽视编译器的开发周期。硬件团队往往觉得编译器是软件的事可以后做。但实际上编译器的开发周期不比硬件短而且需要和硬件架构深度耦合。如果硬件架构定了才开始做编译器很可能发现架构对编译器不友好但已经来不及改了。所以编译器和硬件必须同步设计。第三个坑是量化策略定得太晚。量化对硬件设计的影响很大比如计算单元的位宽、存储器的位宽、指令集的设计都和量化策略相关。如果硬件设计完了才定量化策略可能发现硬件不支持想要的量化方案。所以量化策略要在架构定义阶段就确定。第四个坑是验证不充分。流片前的验证如果只做功能验证不做性能验证很可能流片回来才发现性能不达标。性能问题在流片后是无法修复的只能重新流片代价极大。所以验证必须覆盖功能和性能两个方面。最后说一点体会。AI芯片的软硬件协同设计本质上是一个不断做取舍的过程。算力、功耗、面积、灵活性、开发周期这些指标相互制约没有完美的方案。关键是要明确目标场景的核心需求然后围绕这个需求做优化。不要试图做一个全能芯片那往往意味着什么都做不好。