干AI芯片这行最怕听到的一句话是“我们芯片标称200TOPS算力怎么跑个BERT比显卡还慢”这句话我听了不下十次。问题几乎都不在硬件本身而在于软硬件设计从来没有真正协同起来。今天这篇我不打算从头到尾念某个芯片的databook而是把AI芯片这条主线的软硬件配合逻辑讲清楚——硬件端为什么要做专用架构软件端编译器、运行时、算子库又在扮演什么角色两边是怎么互相咬着往前走的。这是系列文章的第一篇适合三类人刚入行的芯片工程师、想了解AI芯片内部逻辑的算法工程师以及要给AI项目做硬件选型或者架构预研的负责人。1. 先搞清楚AI芯片为什么要做软硬件协同设计1.1 AI芯片到底是什么它和CPU、GPU的关键区别在哪AI芯片行业里更准确的叫法是AI加速器或者NPU神经网络处理单元。它和CPU、GPU最大的区别不在于“能不能跑AI”而在于“为跑AI做了多少专用化设计”。CPU追求的是通用性什么指令都能执行分支预测、乱序执行、各种缓存策略全是为了让通用程序跑得快GPU最初为图形渲染设计后来被改造成大规模并行计算引擎核心数量多但它的调度模型还是面向SIMT/SIMD的“宽执行、多线程”。而AI芯片从一开始就是冲着张量运算、卷积、矩阵乘法这类特定计算模式去的指令集、数据通路、片上存储结构全都围绕这些模式来优化。打个比方CPU像一把通用厨刀什么菜都能切GPU像一台绞肉机走量很猛但你要处理精细的雕花它就力不从心AI芯片则更像一条带专用模具的生产线压某个特定形状的东西极快换产品就得重新调模。这个“专用化”正是软硬件之间的第一个矛盾点越专用硬件效率越高可编程性越差越通用软件好写了性能又上不去。所以AI芯片的架构设计从来不是单纯画RTL而是在专用化程度和可编程性之间找平衡点。这个平衡点没有绝对公式只能靠具体的工作负载workload来定。我见过一个很典型的案例某团队做端侧AI芯片硬件规格非常激进堆了很多自定义指令来处理Transformer的Attention计算但编译器迟迟不支持这些指令导致线上模型只能用通用指令去模拟性能比预期低了四倍。硬件流片都回来了软件还在赶这就是典型的没有从一开始就做协同设计。1.2 软硬件协同设计到底在协同什么软硬件协同设计英文叫Hardware/Software Co-design这个词听起来高级核心思想其实很朴素芯片的架构规格、指令集、存储结构要和编译器、运行时、算子库、调试工具一起定义、一起评审、一起迭代而不是硬件先订一套方案流片回来再说“软件去适配吧”。为什么必须这样因为AI芯片的算力不是摆在那好看的它需要软件一层一层把计算搬进去才能变成真实的性能。举个具体例子硬件设计了脉动阵列Systolic Array这个阵列擅长大规模矩阵乘但它的数据复用依赖PEProcessing Element之间的一层一层流动。如果编译器不支持把卷积运算映射成脉动执行整个阵列就只能空转如果映射得不巧妙数据流动方向不对访存次数就会暴增性能同样拉胯。再比如硬件做了稀疏加速可以在weights有大量零值时跳过无效计算但如果上层框架没有稀疏化的算子和数据布局这个加速模块在真实模型里就根本不会被触发。所以软硬件协同设计的本质是要让硬件团队和软件团队在统一的目标函数下工作。目标函数一般有三项跑目标模型的端到端延迟或吞吐、单位算力能效、以及软件栈的开发和维护成本。很多人只盯着第一项忽略了后两项等产品化的时候才发现编译器三个月没编译出一个新模型或者工具链没人愿意维护这个芯片就算性能数据再漂亮也很难在市场上站稳脚跟。这一节想传达的核心就一句话AI芯片是系统工程算力规格只是起点软件栈能不能把这个算力“接住”才算落地。2. 硬件架构设计要点算力、带宽与数据流的三角取舍2.1 计算核心怎么选脉动阵列、SIMD还是混合架构AI芯片的计算核心业界主流基本就是三条路线。第一条是GPU式的大规模SIMT/SIMD核每个核都能灵活执行各种向量和标量操作分支处理能力强但能效比相对偏低因为指令调度的开销和存储访问的开销都很大。第二条是Google TPU带火的脉动阵列路线大量PE按二维网格排布权重和激活值像流水线一样在PE之间传递每个PE只做简单的乘加操作。它的优势是数据复用好读取一次数据能多次计算访存压力大幅下降所以能效比很高劣势是数据流模式固定对不同形状的张量适配性差编译器要做很强的静态规划。第三条是粗粒度可重构阵列CGRA硬件上有大量可配置的计算单元和互连软件在运行时把数据流图映射到阵列上灵活性和能效都在脉动阵列和SIMD之间但工具链复杂度最高。实际商用NPU很少走单一极端的都是混合结构。比如主计算单元做类脉动阵列来处理Conv和MatMul旁边再配一组向量单元来处理归一化、激活、池化、LayerNorm这类逐元素或规约类操作再加一个标量CPU核做控制流。选择混合结构背后的逻辑不复杂真实模型里的算子类型五花八门用一个单一架构去通吃所有算子必然在某类算子上效率极差。做架构设计的第一件事是拿目标模型集去统计算子占比是Conv为主还是Transformer类为主数据是NCHW布局还是NHWC更多这些统计结果直接决定计算核心的排布方式。这里给个经验值如果目标负载里卷积类算子占比超过六成脉动阵列带来的收益很可观值得投入如果负载是各种动态shape的小模型比如推荐系统、语音识别这种脉动阵列的静态调度就可能僵化SIMD风格反而更稳。我曾经参与过一个项目最初规划是全脉动阵列后来分析真实负载发现大量小而碎的自定义算子几轮模拟下来果断改成“小脉动阵列宽向量单元”的混合结构最终性能反而比全脉动方案提升了约30%原因是碎片算子在向量单元上跑得更顺畅。2.2 存储系统设计真正决定性能上限的是数据搬运AI计算最容易被忽视的矛盾不是算力不够而是“数据搬不动”。你看一个芯片的TOPS规格很高但如果片上缓存太小、外部带宽太窄就算计算单元都在满负荷工作流水线也会不断被数据饥饿打断。举个直观的数字一个ResNet-50的第一层卷积输入是224x224x3的int8图像大约150KB输出是112x112x64约800KB加上权重单层需要搬运接近1MB的数据。假设芯片在1GHz主频下有128个MAC单元跑满完成整层计算只需要极短时间但如果外部带宽只有几十GB/s搬运这1MB数据可能比计算多花十倍时间。所以在AI芯片里存储系统设计的重要性不低于计算核本身。存储系统设计有几个关键决策要做。第一片上SRAM总量多大这决定了哪些数据能固定在片上复用尽量不与外部DRAM频繁交换。第二多级存储的带宽如何分配L0、L1、L2每一级的读写带宽要匹配计算单元的需求瓶颈必须出现在计算而不是数据缺失。第三数据布局转换要不要硬件支持比如NCHW转NHWC、图像预处理、通道重排这些操作如果在CPU上做会消耗大量时间现在很多NPU干脆在DMA前面加一个data layout转换引擎一次搬动完成重排。第四多核之间是否支持直接数据交换比如把上一个P;E的输出直接喂给下一个PE的输入省去绕道共享内存那一圈。我在实际项目中踩过一个很深的坑当时架构评审时大家都盯着算力缓存容量给了个够用但不算宽裕的值等RTL验证才发现跑Transformer时中间激活值加上KV Cache片上空间严重不够导致每个token都要从外部DRAM重新读一遍历史激活值性能损失巨大。后来不得不加缓存、改数据流策略重新布线整个进度拖了两三个月。从那以后我养成一个习惯任何架构评审先算一遍目标模型的内存需求曲线特别要关注KV Cache这类随序列长度线性增长的部分。2.3 多核互联与同步从单核到集群的扩展陷阱单核AI芯片能处理的模型规模总归有限尤其是现在大模型动辄几十亿上百亿参数单核放不下也不划算多核扩展几乎是必然方向。但多核不是把几个计算核复制粘贴就行核与核之间的互联拓扑、缓存一致性策略、同步机制反而决定了扩展效率能到多少。常见的互联方案有三类共享总线、环状互连和片上网络NoC。共享总线最直观所有核挂在同一条总线上读写共享缓存但一个周期只能有一个master在占用总线核一多就撞车适合核心数少于八个的小芯片。环形互连把各核串成一个环数据在环上传递实现简单但最远的两个核通信要绕大半个环延迟高适合强调局部性的设计。NoC是大型AI芯片的主流选择各个计算核、缓存簇、DMA控制器、外部接口都作为网络节点通过路由报文交换数据扩展性好带宽可以随节点数提升但需要处理路由死锁、服务质量保障、延迟抖动等问题设计和验证成本都不低。多核同步往往比互联更难搞。跑一个大模型不同层可能被分配到不同核上层与层之间有严格的数据依赖比如Transformer的LayerNorm需要在一个序列长度维度上做跨核对偶归约硬件如果没有高效的同步原语软件只能用轮询等待会引入巨大延迟。我的建议是在硬件层面至少提供三样东西细粒度的事件通知机制而不是只有全局同步屏障、跨核中断或者mailbox通道、以及可直接在片上寄存器读写的同步计数器。软件同步粒度尽量和算法边界对齐别让同步粒度太粗否则几个核经常出现一个干活、一堆等着的尴尬画面。3. 软件工具链编译器、运行时与调优工具的实战拆解3.1 编译流程从PyTorch模型到芯片指令的完整旅程AI芯片的软件栈里编译器是核心中的核心。一个用PyTorch训练出来的模型要真正跑在NPU上至少要经过四步图优化、算子分解、算子映射、指令生成。图优化阶段拿到的是计算图任务是把冗余计算消掉把可以合并的算子融合在一起。最经典的是ConvBNReLU融合训练时BN是一个独立算子推理时它的参数可以折算进卷积的权重和偏置里三个算子变成一个省掉了一次完整的数据读写和一次中间张量的分配。还有常量折叠、死代码消除、公共子表达式提取这些优化和传统编译器里的优化类似但图优化更关心的是“张量的生命周期”和“访存次数”因为每一份中间张量的产生和消亡都对应一次或多次数据搬运。算子分解和算子映射是最挑人的一步。一个Conv算子要决定切成多少个tile才能塞进片上缓存每个tile用什么数据布局权重要不要做重排让哪个计算核心去执行指令缓存里能放多少条指令。这里的分块参数直接决定片上数据复用率分块太小反复搬数据分块太大缓存溢出性能断崖。我倾向于让编译器以“硬件指令能直接支持的计算模式”为粒度去设计IR而不是把框架语义一层层无损搬进来因为芯片能高效执行的模式就那么几种设计IR时先穷举硬件支持的指令模板再让图优化器尽量把计算图往这些模板上靠这个思路在工程上好落地得多。市面上已经有很多开源帮助做这件事MLIR把编译过程拆成多级IR硬件厂商只需要把图优化后的计算图lower到自己的方言层级即可。我见过有的团队用TVM做自动调度搜索让编译器在数千种分块策略里尝试找最优解思路对但要注意搜索空间爆炸的问题。经验是先把形状信息做静态分析排除明显不可行方案再在有限的候选空间里做轮廓比较绝大多数项目根本不需要跑到完整的强化学习搜索。3.2 运行时与通用IR框架兼容性的关键设计硬件厂商给用户提供的东西除了编译器还有一套运行时库。模型经编译器生成的可执行文件最终要由运行时加载到NPU上执行。运行时要做的事很多申请内存、管理指令缓冲、处理多核调度、同步、和DMA协作、提供调试接口等。但一个很关键的设计决策是中间表示层要不要统一、怎么统一。很多团队一开始只支持PyTorch后来MMDeploy、ONNX、TensorFlow Lite一拥而上每个框架做一套转换维护成本指数上升。比较成熟的做法是定义一套自己的图IR或直接用行业标准IR比如ONNX作为中间表示让前端框架的模型先统一转到这层后端再针对自己的硬件做lower。这样一来新框架接入时只需要写一个前端转换器后端优化则全部复用。但IR层的粒度选择很有讲究——粒度太粗算子无法映射到硬件指令还得二次分解粒度太细转换复杂优化器也不好写。我的做法是设计IR时列出硬件支持的指令模板和访存模式把IR节点定义为“与指令模板直接对应的一组张量操作”再让图优化器去组合这些节点不要一开始就做一层无数小算子的原子IR那样调试起来会让你怀疑人生。运行时还需要注意内存池设计。AI模型执行时的内存申请和释放非常频繁如果每次直接调用物理内存接口耗时会很夸张。正确的做法是运行时维护一个内存池按大小和生命周期分类复用。这里有一个容易被忽视的点推理引擎为了保证低延迟通常会为同一个模型保有多个执行实例一个实例里算完的DPU内存块能不能及时转给另一个实例用直接决定并发吞吐量有多高。3.3 profiler不是可选项是必选项没有性能分析工具调AI芯片的性能等于闭眼摸象。一个模型在芯片上跑得慢你到底该调计算核心的调度、调整存储布局、换算子实现方案还是上游图就有冗余没有profiler你只能靠猜而猜错的概率非常高。一个合格的profiler至少要有三块能力第一能给出算子在硬件上的实际执行耗时细分到计算时间、访存时间、等待时间三个部分第二能绘制带宽和缓存命中率等硬件计数器的曲线让你一眼看出数据通路是否有瓶颈第三能把软件程序计数器映射回模型的操作符信息也就是哪一行模型代码导致了哪个底层操作慢。这三块缺一不可。我在调一个端侧NPU模型时靠profiler发现某层卷积的计算时间本身不到总耗时的20%其余全耗在了一个看起来很不起眼的转置操作上——模型里一个把NCHW转成NHWC的操作被编译器映射成了逐元素搬运没走硬件的data layout引擎。改掉这个映射之后这层耗时直接降了四成整个模型的延迟减了近三成。这个案例说明profiler的价值不只是“看出哪慢”而是“看出到底为什么慢”它把模糊的性能问题转换为明确的可归因信息再结合硬件架构知识才能给出正确调整方案。4. 一次完整的软硬件协同设计流程实录4.1 需求分析阶段别急着定算力先跑负载很多项目一启动就定了目标“我要做一个100TOPS的AI芯片”。这个数字听起来很有气势但如果不结合目标负载做分析它就是一堆空话。正确的第一件事是工作负载分析把目标应用领域里要跑的代表性模型全部跑起来统计每个算子的占比、张量形状分布、数据精度分布、访存总量和时延要求。大模型、推荐系统、自动驾驶、端侧图像这些领域的负载特征完全不同架构方案自然也不同。负载分析之后还要定义几个关键的边界指标端到端时延要求比如实时推理要小于10ms、能效目标多少TOPS/W、模型规模上限最大能跑多少参数量。这些指标才是后续所有架构决策的标尺。没有这些标尺你会被硬件团队“我们能做更大”和算法团队“新模型要支持”两头拉扯最后做出一个看似什么都行、实际什么都跑不顺的芯片。4.2 架构探索阶段参数化配置与全系统仿真需求定义清楚后进入架构探索。这个阶段不需要把所有细节都定死而是用参数化配置去跑马可纳斯运动。参数包括计算核数量、每核MAC数、片上存储容量与层级、互联拓扑、DMA通道数、外部带宽等。每次调整参数就跑一遍全系统仿真对比性能、面积、功耗的权衡。我特别强调全系统仿真这个环节。在一个片上系统还没有RTL的时候最佳做法是搭建一个功能模拟器里面包含CPU核的指令模拟、数据流引擎的调度模拟、存储系统的带宽与时延建模以及计算单元的周期估计。用这个模拟器跑真实模型和真实调度策略才能在造硬件之前预判瓶颈。但模拟器的精度要拿捏得很准精度太高构建周期太长参数搜索跑不动精度太低结论没有参考价值。我的经验是捕到周期级关键瓶颈即可比如计算单元利用率在80%以上还是50%以下这种量级不必过度精确。4.3 并行开发阶段RTL与工具链如何对齐架构探索收敛后进入实现阶段硬件团队开始写RTL软件团队开始写工具链。很多人以为软硬件协同只是架构设计阶段协同其实实现阶段的协同才最考验执行力。两侧必须以同一份架构规格文档为准规格里要写明指令编码、寄存器接口、数据布局约定、异常处理流程、地址映射表任何一处修改都需要走变更评审否则RTL改了一版编辑器还在按旧指令生成联调起来是个灾难。我建议在实现阶段就建立一个“最小可运行系统”的目标哪怕它只能跑通一个卷积算子也要从上到下打通模型转换、图优化、算子映射、指令生成、运行时加载、硬件执行、结果回传。这个垂直切片比水平分层开发早几周做出来能暴露大量接口层面的坑硬件和软件团队的协作节奏很快就会进入正轨。我当时负责的工具链团队就靠这个方法在RTL冻结前就把所有关键算子的精度比对跑完省掉了流片回来再排查接口bug的噩梦。4.4 流片验证阶段Bring-up的坑与调优方法拿到样片后第一个任务是bring-up上电、加载代码、跑最小的程序、确认时钟和复位没问题。这个阶段会碰到各种稀奇古怪的问题比如某模块时钟门控没开导致死锁、DMA地址对齐不合要求、中断信号竞争每一条都要快速定位。我的补救方式是提前准备一份诊断工具集一组小的裸机测试程序覆盖每个硬件模块的基本读写和中断功能。这样bring-up时可以通过排除法快速缩小问题范围而不是在一轮又一轮神秘的挂死中浪费时间。流片后的性能调优也很有讲究。模拟器和真实芯片之间总是有差距跑完真实模型后对比模拟器的预测找出差异点再回溯到底是存储时延建模不准还是指令调度顺序被编译器的某些优化改变了。这一步做完你还得再跑一遍精度一致性检查内存踩踏、浮点到定点的误差累积都在这个阶段暴露。整个流片验证阶段我的建议是不要同时调很多变量——一次只改一个参数并在基准集上记录前后性能否则你无法得知哪个变动起了作用。5. 常见问题排查与经验速查5.1 性能不达预期的五个排查方向当你说“这个芯片怎么跑不出纸面性能”时先别急着怪硬件按照下面顺序排查百分之六七十的情况能直接定位第一算力利用率。跑一个计算密集算子看看计算单元的忙闲占比。如果不到50%说明调度或者数据供给有问题。第二带宽利用率。用profiler看外部存储端口是否经常处于满负荷等待状态如果是优先优化数据复用和tile切分。第三算子实现本身的问题比如某个算子用了低效率的通用路径而不是专用硬件路径这种情况直接改算子映射策略最有效。第四内存分配逻辑频繁的申请释放会造成碎片化和额外拷贝。第五模型结构层面的问题有些计算在模型设计时就可以融合或剪枝别都指望底层编译器去兜底再智能的编译器也救不了冗余的图结构。5.2 数据精度与纸面算力的落差AI芯片标称的TOPS数通常跟数据精度强相关。int8的算力经常是fp16的两倍fp16又是fp32的一倍多。你拿一个标称int8算力的芯片去跑fp16模型自然达不到宣传数字。这里有两个要点一是做需求分析时就要明确目标推理精度并在规格文档里写清楚该精度对应的真实算力二是部署时尽量做量化感知训练让模型能真正工作在int8上否则你等于买了一把好刀却一直用背面切菜。另一个精度相关的问题是数值溢出和精度损失混合精度推理越来越常见硬件要支持不同精度混跑时的格式转换开销要控制好。5.3 工具链联调避坑清单我把这几年联调时遇到的典型问题整理成一个表按经验整理的。遇到问题时可以先对照表格定位很多坑我已经替你们踩过了一个个排查就能省掉大量调试时间。问题现象排查方法解决思路指令生成错误执行结果与参考值不一致对照工具链打印的指令序列和规格文档逐条比对检查寄存器分配和地址偏移是否写错为每条指令增加无符号调试标识数据布局不匹配算子执行时间异常高profiler看访存类型是否为连续模式在算子映射阶段统一数据布局尽早插入layout转换节点多核同步死锁多核程序随机挂起抓trace看互等依赖检查同步原语使用顺序增加超时机制DMA中断丢失队列卡死无响应查看DMA状态寄存器和中断向量确认中断触发源和中断控制器掩码配置正确内存踩踏数据莫名被篡改在芯片上启用MPU内存保护缩小权限范围排查越界访问加强编译器的地址越界检查缓存一致性问题多核间数据不一致加读屏障对比行为差异使用硬件提供的一致性协议不要直接用原子操作代替缓存刷写提示工具链联调阶段最忌的是多个问题一起出现时慌作一团。先重置到最小环境逐个跑通单元测试再逐步叠加新功能定位速度会快得多。最后分享一个我坚持的习惯每版架构评审之前我都会请软件团队准备一个最小可运行的软件栈Demo哪怕它只跑通一个卷积算子、一张模糊的图片推理结果。这个Demo不需要有多漂亮但它会把两个团队真正拉到同一张桌子前把接口、指令、时序的细节掰开揉碎。这个习惯帮我避掉了至少三次大返工——有一次甚至是在评审现场直接发现某个自定义指令的编码方式会让编译器多出三条无用搬移指令当场改了规格省掉日后无尽的联调烦恼。做AI芯片这行光会设计硬件和光会写软件都走不远把这两拨人拧成一股绳才是真正值钱的能力。