做了好几年AI芯片的软硬件设计我最深的体会是真正难的不是把算力堆上去而是让软件真的把硬件吃满。很多团队芯片流片回来跑几个经典模型性能只能到标称值的百分之三四十问题往往不在RTL而在软硬件之间那层没人愿意说清楚的边界上。这是系列的第二篇上一篇我们梳理了AI芯片的整体形态和基本流程包括什么是NPU、主流的芯片形态、以及一个芯片项目大概要经历哪些阶段。这篇想换个更硬核的视角把硬件侧的架构决策、软件侧的编译栈、以及两者怎么协同设计这条线完整串一遍再把我实际项目里踩过的坑和排查方法整理出来。适合正在做或打算做AI芯片的工程师、做AI框架底层优化的同学也适合想搞清楚芯片和软件到底怎么配合的产品和技术管理者。1. 重新理解软硬件设计AI芯片的两条腿1.1 芯片不是堆料游戏软件才是翻译官刚接触AI芯片的人最容易陷入一个误区看算力。某某芯片标称20 TOPS某某芯片标称100 TOPS就觉得后者一定更强。但真实项目里标称算力只是硬件在最理想条件下、以某个固定数据格式跑某个特定算子时的峰值和用户实际能拿到的吞吐量之间隔着十万八千里。可以把芯片想象成一座高度自动化的工厂。硬件决定的是工厂里有哪些机器、流水线怎么布置、物料传输通道有多宽软件决定的是今天要生产什么、每个工序怎么排期、物料怎么流转才能不堵车。工厂再先进排产计划一团糟照样产能低下排产计划再聪明机器本身只能干某一种活遇到新产品也白搭。AI芯片的软件栈本质上就是这个排产计划和翻译官的组合。它要做的是把PyTorch、ONNX这些高层框架里的模型一层层翻译成芯片能执行的底层指令同时把计算任务排到合适的硬件单元上让数据搬运和计算尽量重叠让每个时钟周期都不浪费。硬件负责定义能做哪些事软件负责决定怎么把事做好两者缺一不可。我在项目里见过太多重硬轻软的团队架构师花一年时间打磨微架构编译器团队只有两三个人等芯片回来才发现软件跑不动模型延迟惨不忍睹整个项目延期。反过来也见过硬件设计平庸但软件调优极好的芯片在特定场景里反而跑出更优的效果。软硬件设计从来不是两个阶段而是一件事。1.2 从大模型到指令流一条完整的翻译链路理解AI芯片绕不开那条从模型到指令的完整链路。我习惯把它分成五层第一层是模型层也就是PyTorch、TensorFlow或者ONNX表达的计算图这层描述的是要算什么和芯片无关。第二层是图优化层常见的如算子融合、常量折叠、算子改写这层开始对计算图做第一次瘦身。第三层是算子层把融合后的图拆解成一个个可在硬件上执行的算子实现比如GEMM、Convolution、Softmax的某种切分版本。第四层是内核层也就是每个算子如何在硬件的计算阵列、存储、流水线上落地包括循环切分、数据排布、向量化。第五层才是真正打到芯片的指令流。这条链路每往下一层约束条件就多一层。硬件规定了计算阵列的尺寸、片上SRAM的大小、可用的向量宽度、存储的bank数量、甚至访存的burst长度软件每下降一层都必须在这些约束里做选择。举例来说一个3x3的卷积在模型层只是一个节点到了算子层可能要拆成im2col GEMM也可能走winograd变换到了内核层又要决定是沿着H维度切块还是沿着C维度切块切多大才能把输入输出完整塞进片上SRAM最后到指令层还可能因为硬件指令集不支持某些寻址模式再多搬几次数据。任何一个项目如果团队成员心里没有这条链路的完整图景就会在某个环节脱节。硬件工程师觉得指令集我已经定好了编译器工程师觉得算子库已经够用了框架集成工程师觉得推理引擎已经接好了但没人对着整条链路看数据格式、内存分配、同步机制对不对得上最后出问题就是必然的。2. 硬件侧的核心架构决策算力、存储与数据流2.1 算力单元的三条主流技术路线先聊硬件侧最核心的决策算力单元选型。业界主流路线基本可以分三类脉动阵列、SIMD/SIMT向量阵列、以及近年来不少NPU采用的向量单元矩阵单元混合架构。脉动阵列的代表是Google的TPU核心思路是把大量乘加单元排成一个二维阵列数据像水在管道里流动一样一个周期往阵列里塞一遍输入所有单元同时做乘加结果接力传递。优点是单位面积能效比极高数据复用好非常适合矩阵乘法和卷积这类规则计算缺点是灵活性差遇到非规则算子、动态形状、稀疏计算阵列利用率会大幅下降。编译器要把算子映射得漂亮需要做大量循环变换难度不小。SIMD/SIMT路线是GPU的老本行大量并行线程共享一套控制逻辑每个线程在同一时刻执行同一指令适合通用并行计算。灵活性强编程模型成熟CUDA生态就是它的护城河但代价是控制开销和缓存开销大能效比不如脉动阵列。第三条路线典型的比如华为昇腾、寒武纪这些AI芯片走的路子矩阵单元负责GEMM和卷积这类密集计算向量单元负责激活、归一化、逐元素运算标量单元负责控制流和地址计算。这种分工思路更贴近真实模型的计算需求因为Transformer里除了大矩阵乘还有大量LayerNorm、Softmax、逐元素乘加这类又碎又小的算子。三种路线各有优劣我做过一个简单的对照供选型时参考维度脉动阵列SIMD/SIMT向量阵列矩阵向量混合架构能效比高中中高灵活性低高中编译器难度高中高典型代表TPUGPU昇腾、寒武纪系列擅长场景规则密集矩阵运算通用并行计算大模型混合负载我的建议是先把目标工作负载算清楚再选型。如果产品只做推理、模型相对固定、矩阵乘占比极高脉动阵列的性价比最好如果要做训练、要兼容各种框架和动态模型混合架构更稳。最怕的是拍脑袋定了一个架构后面编译器团队跪着也填不满算力。2.2 存储层级与数据复用算得再快也怕搬数据芯片设计里有个铁律数据的搬运成本远高于计算成本。单位能量的算术运算要比单位数据的片外搬运便宜一到两个数量级所以AI芯片性能上不去很多时候不是算力不够而是数据喂不进来。这就是所谓的访存墙问题。为了解决这个墙硬件设计要搭一个金字塔形的存储层级寄存器堆在最顶层容量最小但带宽最大中间是片上SRAM一般几百KB到几MB带宽可以达到每周期几十到几百字节再往下是片外DDR或HBM容量大但带宽和延迟都差几个量级。关键的设计变量是片上SRAM的大小和它的数据通路。SRAM越大能缓存的数据越多片外访存次数越少但面积和功耗也上去缓存命中率还有边际递减效应。工程上有一个经典的目标对目标模型里占比最高的算子能把一个完整的计算Tile所需的输入、权重、输出全部装进SRAM里让计算在片上循环只把最终结果写回片外。数据复用是另一个重点。卷积运算天然有数据复用同一个输入像素会被多个输出通道的卷积核用到同一个权重会被多个空间位置的输入用到。好的数据流设计会把这种复用显式地表达在硬件上比如让权重在阵列里横向广播、让输入在纵向流动最大程度减少从SRAM重复取数。之前做设计空间探索时我见过同一份卷积代码因为数据流方向不同SRAM访问带宽消耗能差3倍以上。这个环节的优化需要硬件架构师和编译器工程师坐在一起反复对着数据流图核对而不是各写各的文档。2.3 片外带宽、片上互联与SoC集成算力单元和存储层级定了之后还要面对片外带宽和片上互联。片外带宽的选择基本决定了芯片的天花板。以HBM为例一颗HBM2E能提供约460GB/s的带宽而一颗LPDDR4X只有30-50GB/s差距一个数量级。但HBM贵、封装复杂、功耗也高不是所有产品都适合。做边缘侧芯片比如瑞芯微RK3588、地平线征程系列这类SoC一般选LPDDR带宽有限所以架构设计更强调片上缓存和数据复用编译器也要把访存调度优化放到首位。做云端训练芯片比如寒武纪思元、壁仞这样的HBM几乎是标配因为模型规模摆在那没有足够带宽计算阵列只能空转。片上互联负责把计算单元、SRAM、DMA、外部接口连接起来。复杂SoC一般用NoC或者层次化AXI总线设计时要注意带宽的对称性和路径的一致性。我踩过一个坑一套总线协议在各模块的地址映射上有一处重叠导致DMA搬运到错误地址数据静默损坏跑模型时精度忽高忽低查了两周才定位到。这种问题在验证阶段如果没做全地址空间的交叉检查大概率会漏到芯片回来之后。SoC集成层面还有启动、电源、时钟这些不性感但致命的环节。启动流程一般是BootROM读片外存储上的引导代码逐步加载固件和驱动这里涉及QSPI Flash、eMMC、看门狗芯片、升压电源芯片这些外围器件。很多工程师盯着NPU架构忽略了这些细节结果芯片回来点不亮或者经常死机复位。Jetson Orin Nano这类开发板如果QSPI Flash损坏系统只能通过专用工具重新烧写可见这个环节的可靠性设计非常重要。3. 软件侧的编译器设计与运行时机制3.1 图优化与算子融合先把计算图瘦身硬件架构定了软件侧的重头戏开始。编译器第一道工序是图优化宗旨只有一个减少不必要的数据搬运和计算。最经典的优化是算子融合典型如ConvBatchNormReLU融合成一个算子。不融合时卷积的输出要写回片外内存BatchNorm再读出来算一遍ReLU再读出来又写一遍一个算子三次访存数据量大了之后片外带宽直接被浪费掉。融合之后中间数据留在片上SRAM里一次流水线走完访存开销大幅下降。我实测过一个MobileNetV3的优化单纯做算子融合这一项端到端推理延迟能降低20%到35%具体取决于芯片的SRAM大小和片外带宽。图优化还包括布局转换比如把NCHW布局转成NHWC或者NC1HWCO。不同硬件对数据排布的要求差异很大向量单元喜欢通道在连续维度矩阵单元可能要求特定的分块排布编译器如果只做一次全局布局决策性能往往不好。真正让图优化变得复杂的原因是精度和动态性。比如推理引擎里常见的动态形状——输入图片分辨率不固定、batch size变化——很多优化在静态形状下很有效形状一动态就失效。所以现代AI编译器普遍采用静态形状优先动态形状兜底的策略对热门模型做静态特化对冷门输入走通用路径。3.2 算子映射与指令生成编译器最难啃的骨头图优化之后编译器要把每个算子变成能在硬件上高效执行的指令序列。这里最核心的工作是两层循环切分和指令调度。循环切分解决的是数据放不下的问题。一个矩阵乘假设输出是4096x4096片上SRAM只有2MB不可能一次性算完必须把计算切成一个个Tile保证每个Tile的输入、权重、输出都能装进SRAM并且Tile之间的数据用DMA预取来重叠。切分粒度太大SRAM溢出频繁访存切分粒度太小DMA启动开销占比上升计算单元饿肚子。这个平衡没有常数解要看硬件参数基本要靠编译器里的代价模型自动搜索。指令调度解决的是硬件怎么动起来的问题。矩阵单元、向量单元、DMA、标量单元哪个先动、哪个后动、怎么用同步信号保证数据依赖正确都体现在这一层。好的调度能让DMA搬运和矩阵计算重叠让矩阵计算和向量激活流水起来做到算着算着数据就位了。以GEMM映射到脉动阵列为例子业界有个经典优化思路分解成六个维度M、N、K方向的切分以及阵列映射、数据复用的方向选择等逐步求解。第一步确定K方向的切分保证权重分块能放进阵列第二步确定M、N方向的Tile兼顾SRAM容量和写回效率第三步决定数据在阵列里的流动方向比如输入从上方流入、权重在阵列中广播还是反过来最后再做指令级流水排布。这一套操作纸上写起来简单真正实现起来要考虑边界条件、对齐约束、位宽差异工作量相当可观。3.3 运行时、驱动与推理引擎让模型真正跑起来编译器和内核只是把能算的东西准备好了模型真正要跑起来还差运行时和驱动。运行时负责三件事内存管理、任务调度、生命周期管理。内存管理要解决的是频繁的分配释放带来的碎片化问题所以推理引擎一般用内存池一次性向驱动申请大块连续内存内部自己管理。任务调度要把编译好的多个算子按依赖关系排队分配给不同的硬件单元同时处理多线程、多进程的并发访问。大模型场景下还要考虑KV Cache的预分配和动态扩缩容。驱动层是软硬件最后的接缝。寄存器读写、消息邮箱、中断处理、DMA描述符的填充和回收都在这层完成。我最担心的是这一层的代码质量和文档维护。芯片的寄存器定义经常在验证阶段变动同一个功能地址改来改去驱动如果没同步更新非常容易出现硬件明明改了软件还按旧地址写的静默错误。这种问题用仿真很难复现因为行为仿真里地址错位往往直接挂死但真实芯片上可能只是行为异常很难定位。推理引擎层把上面所有能力封装成上层框架能调用的接口比如兼容ONNX Runtime或者自定义一套C API。对开发者友好度的评估要看你从PyTorch导出一个模型之后几步能跑起来。这个过程涉及算子支持清单、量化格式对齐、输入输出的内存布局约定哪一环不透明用户都会在集成时踩坑。4. 软硬件协同设计与全流程落地4.1 先定工作负载再谈架构软硬件协同设计的第一步也是最容易被跳过的定义清楚目标工作负载。不是一个宽泛的我们要支持主流模型而是具体到模型的集合、各算子的时间占比、输入形状的分布、batch size的范围、精度要求FP16还是INT8、延迟还是吞吐优先。我习惯先从公开模型库里选一个代表性子集跑一遍算子级的profiling把时间占比拉出来看。比如一个典型的BERT类模型矩阵乘可能占60%以上但LayerNorm、Softmax、GELU这些逐元素算子加在一起也有20%-30%。如果硬件只优化GEMM不关心向量单元那再好的矩阵阵列也会被这些碎算子拖住。而一个基于MobileNet的视觉模型卷积的形态又完全不同深度可分离卷积在硬件上利用率天然偏低需要专门的映射策略。工作负载分析的产出是一张算子时间分布表和一个访存强度分布图这两样东西直接决定硬件参数的初值。算力要多大、SRAM要多大、片外带宽要多高都应该从这张表倒推而不是先定一个看起来好看的TOPS数字。4.2 性能建模与架构探索不是拍脑袋定参数工作负载定了之后架构探索要用模型而不是感觉。业界最常用的工具是Roofline模型画一条机器天花板曲线横轴是运算强度每字节数据承载多少次运算纵轴是可达性能。任何计算内核在这张图上的位置要么被计算上限限制要么被带宽上限限制一眼就能看出瓶颈在哪。举个例子一个10 TOPS的芯片假设片外带宽只有30GB/s那它的Roofline转折点在运算强度约333 FLOPs/Byte。一个计算强度只有50的算子理论上限就是1.5 TOPS无论计算阵列多强都跑不满。这类分析的价值是在花几百万美元流片前把最致命的性能问题暴露出来。更精细的架构探索需要周期级仿真器或者性能原型。高精度仿真的精度好但速度慢跑一个大模型要几天分析模型快但误差大。工程实践里一般两级配合初期用分析模型快速扫设计空间锁定几个候选配置再用周期级仿真对热点算子精仿修正关键参数。需要注意的是SRAM容量、MAC阵列规模、频率、带宽这四个变量是强耦合的改一个往往要连带看其他三个的连锁效应不能只看单一变量。4.3 从RTL验证到芯片后端再到片上调试的完整流程架构探索收口之后硬件进入实现阶段。RTL设计、验证、逻辑综合、后端物理设计、DFT、流片这是硬件团队的主战场。但软硬件协同在这个阶段就已经开始了最常见的做法是FPGA原型验证和硬件仿真加速器emulator双轨并行。FPGA原型提前把RTL跑起来软件团队可以在流片前完成驱动开发、系统启动验证、基础算子调试。一个典型的AI芯片设计FPGA原型通常比真实芯片慢几十倍但对于验证功能正确性足够用。另一个路径是用仿真加速器比如Cadence的Palladium或Synopsys的Zebu速度快、可调试性好但成本高主要用来跑操作系统的启动流程和复杂并发场景。芯片后端流程和芯片测试也是协同设计的一部分。后端要做时序收敛芯片测试要做ATE测试和硬件功能测试软件团队需要提供一套自检测试程序通常叫D0测试在拿到首批芯片时快速验证基本功能。经验是这套测试程序最好在流片前就跑过仿真和FPGA不然芯片回来你都不知道是芯片坏了还是测试程序写错了。5. 实测踩坑与典型案例复盘5.1 软硬件接口不一致导致的静默错误先分享一个我印象深刻的案例。某款NPU的硬件团队在实现时把DMA描述符里的地址字段从32位扩展到了36位但寄存器地址偏移没变。驱动这边一直按旧文档用32位读写功能仿真没发现异常因为验证平台里所有地址都落在低32位。流片回来后跑大模型时偶尔出现计算错误而且错误位置完全不固定。排查了两周最后是用printk把DMA描述符逐个字节打出来才看到高4位地址丢失。这种问题本质是软硬件接口的版本管理失控。解决思路是三条第一把寄存器描述文件通常叫RDL或者IP-XACT作为唯一事实源驱动代码和验证环境都用它自动生成不允许手写第二每次寄存器改动都强制触发全量回归包括FPGA上的驱动测试第三在硬件里加校验机制比如关键描述符的CRC校验软件写错能立刻被发现而不是静默算错。5.2 性能不达标的排查路径先分清楚瓶颈再动手芯片性能跑不到预期排查路径要按部就班先看是不是计算瓶颈再看是不是访存瓶颈最后看是不是调度开销。用Roofline做第一层判断最简单把一个算子的运算强度算出来够不够转折点一测便知。有个实际例子一个卷积在阵列利用率只有40%但整算子性能还是低的。一开始大家以为是矩阵映射有问题各种优化做了半天没效果。后来用性能计数器一看发现DMA的排队等待时间占了整个算子耗时的50%根因是输入Tensor的对齐导致DMA传输分成了大量碎片请求带宽利用率极低。解决方案是改编译器里的对齐策略让DMA每次搬运都是完整的burst长度。一个很小的代码改动算子性能直接翻倍。类似的还有启动开销问题。推理引擎如果拆出大量细粒度算子每个算子的启动延迟就会叠加。之前优化一个小型检测模型端到端延迟总是压不下去原因是图优化没做到位400多个算子提交到硬件每个算子的任务调度和同步开销占了大量时间。合并掉一部分碎片算子并让多个独立算子形成流水线后延迟降了将近一半。性能问题永远要带着计数器找证据不要凭感觉猜。5.3 启动流程与固件设计最容易翻车的地方芯片上电后能不能板利跑起来启动流程是关键。常见启动链路是BootROM → 片外启动设备QSPI Flash或eMMC → 引导加载程序 → 固件 → 操作系统 → 驱动。链路里任何一环出问题表现都是上电没反应或者反复复位。看门狗芯片在这里的作用很容易被忽视。如果固件启动时间超出看门狗超时周期芯片会被强制复位形成启动循环。之前调一块板子系统总是启动到一半就重启排查到最后是看门狗芯片的超时配置太短而新固件因为初始化了很多外设启动时间刚好卡在临界点。把看门狗超时调大并且在固件里增加了心跳喂狗逻辑后才稳定。电源时序是另一个高频问题。AI芯片一般有多路电源域核心电压、IO电压、内存接口电压上电顺序有严格要求。很多外围的升压电源芯片配置不对会导致某些模块上电不完整芯片在进入某个深度计算时突然掉电重启。排查这种问题最实用的工具是示波器抓各路电源的上电时序和芯片手册上的要求逐一核对。别小看这些不智能的环节它们恰恰是芯片项目延期的主要原因之一。6. 几个个人实践中的习惯分享给你做了几个项目之后我逐渐养成了一些未必写在教科书里的习惯分享出来供参考。第一个习惯是软件团队从第一天就进场。硬件团队做架构探索时编译器团队的负责人就应该坐在旁边一起看工作负载分析一起定指令集和寄存器接口而不是等RTL freeze了再介入。成本最低的修改时机永远是架构探索阶段而不是流片之后。第二个习惯是永远有一个可跑通的最小系统。不管进展到哪一步都保持一个最小的软件栈可以从模型编译到片上执行哪怕是只支持一个算子、跑一个最简单的网络。这个最小系统是团队的基准线任何改动导致它坏了都能第一时间发现避免问题越积越多最后无从查起。第三个习惯是性能计数器从设计第一版就定义好。很多团队芯片快流片了才开始想性能分析怎么做导致计数器布局不合理调试时发现关键信号根本没引出来。性能计数器是软件调优的眼睛应该在架构定义阶段就列出需要监测的事件清单包括计算单元利用率、SRAM读写带宽、DMA等待周期、指令发射停顿周期这些。没有这些数据优化就是盲人摸象。最后再强调一句我在多个项目里反复验证过的判断AI芯片的软硬件设计本质上是在算力、带宽、存储、编译器复杂度这个四维空间里找平衡点。每一项单独做到极致都不难难的是让四项在同一个产品里同时成立。培养这种感觉没有捷径就是多跑数据、多拆模型、多对着性能计数器看真实行为。希望这篇文章能帮你少踩几个我已经踩过的坑。