写这个系列之前我一直在想该怎么把AI 芯片的软硬件设计讲得既专业又不像教科书。市面上聊AI芯片的文章讲硬件架构的多讲软件栈的少讲算法映射的多讲工程取舍的少。而这几年我接触或复盘过的AI芯片项目几乎都会在同一个地方卡壳硬件做出来了软件却跑不通或者跑出了个让人尴尬的性能数字。于是我想用一个系列来系统整理一下这块的经验第一篇先讲清楚软硬件协同设计的整体框架和核心矛盾后续再逐层展开编译器、算子库、数据流、存储架构这些细节。这个系列适合三类人打算做AI芯片/存算一体/NPU的芯片架构师和验证工程师正在给嵌入式平台做AI部署的软件工程师以及想在AI芯片赛道入行但还没找到切入点的学生。看完你至少能回答这三个问题一颗AI芯片的硬件结构究竟由什么决定软件栈为什么比芯片本身更决定生死软硬件协同设计在真实项目中到底是怎么推进的1. 先拨开一个迷思AI芯片的核心难点不在电路在软硬件怎么一起设计1.1 从流片到能用中间隔着一整个软件栈很多刚接触AI芯片的朋友第一反应是盯住算力规格多少TOPS、多少GHz、几个核。这些数字确实吸引人但真实项目里一颗芯片从流片回来到能稳定跑起一个像样的模型往往要再折腾大半年。大半年里最耗时的不是修RTL的BUG而是把算法框架、编译器、算子库、运行时、驱动一层一层对接起来。拿ST的STM32N6举例很多人把它当成带NPU的MCU觉得嵌入式跑AI嘛调个库就好。真上手就会发现ST除了给一颗NPU还配套提供专用的中间表示和编译工具链模型要从PyTorch或者ONNX格式导入经过量化、算子映射、内存规划之后才能生成NPU可执行的指令。芯片只是负责算怎么把模型换算力怎么切分到不同核心怎么分配缓冲区全是软件栈的事。这个认知如果不到位后面所有工作都会跑偏。1.2 软硬件协同设计到底协同什么我把协同拆成三层这三层贯穿项目始终功能划分哪些功能做成硬件单元哪些留给软件。硬件化收益高但灵活性差软件化灵活但性能和功耗拖后腿。性能兑现芯片的峰值算力只是理论极限软件栈负责把它变成真实吞吐和延迟。这里经常出现硬件号称10 TOPS实际跑模型只能到2 TOPS的尴尬。成本控制协同设计不仅指性能和功能还指项目的迭代效率。硬件早冻结、软件跟不上或者算法频繁变导致硬件白做都是成本灾难。这三层几乎每一层都涉及架构师、算法工程师、编译器工程师、驱动工程师之间的反复拉扯。一个典型的教训是架构师喜欢为某个特定模型做极致优化算法工程师却希望架构能适配三个月后就要换的新模型。所以协同设计的第一件事不是画框图而是对齐到底为哪些模型服务。1.3 一个典型AI芯片软硬件全栈长什么样从上到下大致是算法框架PyTorch/TensorFlow等— 模型转换层ONNX/量化/图优化— 编译器图优化、算子融合、指令生成— 算子库/内核 — 运行时与驱动 — 硬件计算单元、存储、互连、控制。每一层之间都有一对接口约束。比如算法层希望数据类型越宽越好硬件层希望数据位宽越窄越好于是编译器中间表示就成了博弈的战场。再比如运行时要知道有多少片上SRAM、多少内存带宽才能决定模型怎么分块执行。可以说没有哪个环节能独立决定性能也没有哪个环节能脱离其他环节独自优化。我个人的体会是刚入行的人往往把AI芯片想象成一块电路板一做项目才发现它更像一套从模型到指令的流水线操作系统。硬件架构决定了流水线的物理边界软件栈决定了流水线能跑多满。2. 算力从哪来算法结构如何决定芯片该长什么样2.1 卷积时代和Transformer时代的需求差异AI芯片设计的起点是算法结构。不同算法的算力需求、数据复用特征、访存模式差别极大这会直接改变硬件设计的方向。以卷积神经网络为例卷积的局部性极好一个卷积核的权重可以在整张特征图上反复复用激活数据也有很强的空间局部性。所以针对CNN设计的芯片会倾向于配置大量乘加单元阵列配合多级片上缓存尽量把数据喂进计算阵列反复用。Transformer时代情况变了。核心是矩阵乘GEMM加注意力机制注意力分数的计算 QK^T 需要把整条序列的特征两两交互是典型的高算力高访存操作。同时还有大量非矩阵类算子比如Softmax、LayerNorm、RMSNorm这些算子计算密度不高但数据依赖强对硬件控制流和片上存储的随机访问能力提出了新要求。这就解释了为什么新一代NPU不再像早期那样只堆卷积加速器而是开始加入更强的通用向量单元、更大的片上存储、更灵活的互连结构。你设计的芯片如果不看清这一点很可能算法一迭代就过时。2.2 计算、搬运、存储AI芯片的三大先天矛盾我记得有句话特别贴切AI芯片的设计本质上是在算力、访存带宽、存储容量三个维度里找平衡点。衡量一个计算任务能不能发挥硬件峰值常用算术强度这个概念算术强度 单位字节数据搬移对应的计算量FLOPs/B)Roofline模型会给出一个现实结论实际性能 min(峰值算力, 内存带宽 × 算术强度)。一个矩阵乘理论上FLOPs很多但如果数据搬移量设计不合理实际性能会被带宽卡死。举一个具体例子。一个 4096×4096×4096 的矩阵乘计算量约 137 GFLOPs如果用FP16精度的朴素算法直接做需要搬运约 200 MB 的数据算术强度大约只有 680 FLOPs/B。如果片上带宽只有 200 GB/s那么性能上限就被死死摁在 136 TOPS 左右。但如果你把矩阵分块成 128×128 的小块让数据在片上反复复用算术强度能提高一个数量级性能天花板随之大幅抬升。可以看到硬件设计里那些看起来复杂的存储分块和调度逻辑本质都在干一件事提高算术强度。2.3 精度选择是工程决策不是技术选型FP32、FP16、BF16、INT8、INT4每个选择背后都牵动硬件面积、功耗、性能和精度四根弦。我见过只强调高精度而把芯片面积做爆的也见过为了性能盲目量化最后模型精度崩了的。实际经验是训练阶段基本用FP32推理阶段首选FP16/BF16与INT8混合方案。BF16的指数位和FP32一致训练时更稳定INT8的吞吐在同等面积下能做FP16的两倍甚至更多是边缘推理芯片的主流选择。INT4则通常是极致性能场景下的妥协需要配合更精细的量化训练和误差校正不是谁都能驾驭。这不是简单的挑一个格式。硬件上混合精度意味着同一个计算阵列要支持多套数据通路、对齐逻辑和累加方案软件上编译器要能自动做精度转换和数据重排。协同设计的早期最该明确的环节之一就是精度方案定了没因为一旦定了后面所有环节都围着它转。3. 硬件架构的三大主战场计算阵列、片上存储与互连3.1 脉动阵列 vs SIMD两条路线的取舍逻辑AI芯片的核心处理单元大致分两大流派维度脉动阵列Systolic ArraySIMD/SIMT类GPU代表Google TPUnVIDIA GPU控制开销极低数据像脉动一样流经各处理单元高每个指令需广播、每个线程需调度峰值能效高逻辑基本全在乘加运算上相对低控制与调度电路占比高灵活性弱稀疏性、不规则形状算子难处理强适应性好典型弱点依赖编译器保证数据不空泡访存瓶颈和缓存一致性复杂实际商用NPU很少走极端路线。RK3588的NPU、Jetson系列里的深度学习加速器大多是向量单元 MAC阵列的混合体。向量单元处理归一化、激活函数、Attention里的杂活MAC阵列专门跑矩阵乘和卷积。这个组合我倾向用一句话概括用灵活性兜底用专用性冲峰值。3.2 存储墙怎么破从HBM到片上SRAM的数据不动计算动AI芯片领域有个老生常谈但不得不谈的问题存储墙。外部DRAM带宽的增长速度远跟不上算力增长速度于是芯片设计者们把大量SRAM搬到了片上尽量让数据在片上流动减少进出片外的次数。这就是所谓的数据不动计算动。具体到数据流策略常见的几种权重固定Weight Stationary权重驻留在处理单元里输入数据流过去适合模型权重大于激活的场景。输入固定Input Stationary输入留在片上权重流动适合大量不同卷积核共享输入的场合。输出固定Output Stationary输出部分和累加器留在片上减少中间结果的写回。选择哪种数据流其实是由模型本身的复用结构决定的。比如卷积操作里权重复用价值高就常见权重固定而全连接层或注意力机制里激活复用也可能成为主导。芯片架构师要做的是让硬件数据流与主流模型的复用模式匹配而不只是拼峰值算力。3.3 NoC与总线多核时代的数据交通规划核一多互连就成了瓶颈。传统的AXI等总线适合低吞吐的控制流和配置流但AI载荷是典型的高吞吐持续数据流多个核同时读写极易发生拥塞。所以现代AI芯片普遍引入NoC片上网络或者更复杂的交叉开关结构。NoC把数据包化按路由规则在网格里传输好处是可扩展性好多核时不需要重写总线协议代价是额外的路由节点延迟和面积开销。我见过一个项目为了解决两个计算集群之间的通信拥塞最后把互连从共享总线改为2D Mesh NoC峰值性能提升将近两倍而面积只增了不到一成。NoC的维度、链路带宽、缓存深度都值得精细调优。比如视频流类任务需要极低的延迟抖动那NoC的仲裁策略就不能用简单的轮询得做优先级调度。这块不做软件栈优化得再好也白搭。4. 软件栈决定芯片生死编译器、算子库与运行时如何兑现性能4.1 编译器从PyTorch到下发给芯片的指令AI编译器的核心目标是把高层模型描述翻译成芯片能高效执行的底层指令。流程大致如下前端解析读取PyTorch/ONNX模型转换成中间表示IR。图优化算子融合、常量折叠、死节点消除。布局转换处理NCHW/NHWC等数据布局匹配硬件存储排布。算子分解大算子拆成芯片支持的小算子组合比如把一个大GEMM切成多个小块。内存规划每个张量分配在哪一级存储、何时分配、何时释放。指令调度按硬件流水线特性排布指令顺序。代码生成生成芯片可执行的二进制。这里最简单的优化例子是算子融合。Conv BN ReLU三个算子如果不融合中间结果要写回DRAM再读出来来回多搬好几轮数据。融合成单个算子后中间张量就留在片上寄存器里性能提升往往非常可观。编译器的抽象层次越高越能在这种看似不起眼的地方赚回大把性能。真正的难点在于编译器几乎不存在通用的最优解。同一个模型在不同芯片上最优图切分和数据布局完全不同。所以编译器架构通常要设计成硬件描述抽象 自动调优的组合硬件相关规则下沉到后端平台无关优化留到前端。4.2 算子库性能的最后一道防线你可能觉得编译器已经做了大部分优化但实际上对很多成熟芯片来说手工调优的算子库仍然是性能基石。比如一些知名移动端推理库大量卷积和矩阵乘内核都是逐行逐指令手写的。算子库的核心工作分两块分块参数调优和指令级优化。分块参数决定数据搬移的粒度指令级优化决定利用向量指令、减少流水线气泡。很多芯片刚流片回来时性能不达标原因往往不是硬件本身不行而是算子库还没跟上一个3×3卷积硬是写成了通用矩阵乘在跑性能自然大打折扣。4.3 运行时和调度多核AI芯片的交通警察当芯片有多个计算核时运行时负责把计算任务切分到不同核上并管理数据依赖和数据搬移。这里容易踩的坑是任务切分不当导致负载不均。比如两个核一个要跑非常重的GEMM一个跑轻量算子如果排程算法不感知算力差异就会出现一个核累死一个核闲死。更复杂的是数据依赖下一个算子的输入依赖上一个算子的输出必须在正确的时间点做同步。运行时的调度粒度、同步机制、中断延迟都会直接影响端到端性能。5. 软硬件协同设计怎么做从工作负载画像到性能模型校准5.1 第一步工作负载画像把算法翻译成硬件需求任何AI芯片设计都应该从工作负载画像开始。所谓画像就是把目标应用里的模型统计一遍形成一个表格模型主要算子计算量权重规模激活规模内存带宽需求ResNet-50卷积约8 GFLOPs约25 MB小但中间特征图多中等BERT-baseGEMMAttention约22 GFLOPs约110 MB序列相关显存占用大高Llama-7B大GEMMAttention每token约15 GFLOPs约14 GBFP16每token约几十KB极高有了画像才能做反推目标帧率/吞吐量是多少反推出来需要多少MACs/s多少内存带宽多少片上存储这些数字构成设计规格而不是拍脑袋定TOPS。5.2 设计空间探索面积、功耗、性能的三角博弈工作负载定了硬件参数还面临大量选择计算阵列多大、片上SRAM多大、主频多高、外部接口多少带宽。这是一场典型的面积-功耗-性能三角博弈通常会建一个性能模型来做设计空间探索。性能模型能在RTL之前给出粗估让团队快速筛选参数。我在实际项目中见过一个很典型的案例架构团队在探索时发现把片上SRAM从4 MB加到6 MB面积增加大约15%但部分模型的性能提升接近40%原因是很多算子的中间结果不再需要搬出片外。这种结论只有靠模型量化才能得到靠拍脑袋很难发现。设计空间探索产出的通常是一个Pareto前沿一组不互相支配的配置最后结合成本和功耗目标做最终选择。5.3 性能模型、RTL仿真与实测的三次校准协同设计最大的坑是性能模型和最终芯片实测对不上。所以必须做三次校准模型校准拿目标模型在性能模型上跑看Roofline估算和实际预估差距在哪。RTL校准RTL级仿真数据回填性能模型修正模型中的假设误差比如实际访存延迟、仲裁排队延迟这些。硅后校准流片回来后用benchmark实测数据回填反过来修正模型和软件栈的调优方向。很多团队的研发节奏是流片回来才开始调软件结果硅后调试周期被拖到半年。我强烈建议在RTL阶段就把软件栈的雏形搭出来哪怕只能跑一个子集模型也要尽早做端到端打通。芯片后端和芯片测试的资源最好也提前介入因为关键路径问题和DFT覆盖率问题都会反过来限制软件能发挥的性能空间。6. 从量产芯片回看协同设计RK3588、Jetson Orin带来的启示6.1 RK3588的NPU终端场景的够用即最优RK3588的NPU是一颗典型为端侧场景设计的加速器不是追求极致算力的大杀器而是用适量的算力加上强大的软件适配能力去满足大量工业视觉、边缘计算、智能终端的需求。它的算力规格在同类里并不夸张但开发者体验相对友好。这种设计思路值得学的一点是按场景定义规格工业视觉任务大多是中低分辨率视频流和中小型检测模型不需要超大上下文窗口的Transformer能力。设计团队把资源花在每路视频稳定处理、硬件编解码协同、多模型流水线切换的能力上比一味堆TOPS更有价值。做硬件最怕的就是什么都想做什么都做不深。6.2 Jetson Orin为什么好用生态比硬件值钱Jetson Orin Nano这类产品的算力在绝对数字上并不是最强的但它在AI开发者里的口碑一直不错核心原因就是软件生态成熟。它可以直接跑PyTorch有相对完整的TensorRT管线社区里踩坑答案多从CUDA到JetPack SDK的路径清晰。对于项目开发来说这种到了就能用的体验价值不亚于把芯片性能再提20%。对比之下很多自研AI芯片最大的短板不是硬件而是工具链断裂模型转换报错、算子缺失、文档过时导致客户花三周都跑不通一个demo。做AI芯片项目一定要把软件工具链和开发者体验纳入核心指标否则芯片做得再强也没人愿意用。6.3 给想入行AI芯片的工程师的实践路径如果你正想进入这个领域我的建议是先别急着写RTL先把算法模型的部署跑通。至少用PyTorch训练或转化一个小模型然后做一次量化、编译、上板全流程。你可以从STM32N6或树莓派加NPU套件入手体会模型到硬件的完整链路。然后再深入编译器的算子融合与循环优化最后才是研究计算阵列与数据流。这个顺序帮你在脑子里建立算法-软件-硬件的闭环思维一下子就通了。最后再说一点我个人的经验AI芯片的软硬件设计与其说是技术问题不如说是个系统工程问题。所有环节都必须从模型出发又回到模型上去验证。这个系列第一篇把框架搭起来了下一篇我打算专门拆编译器里的算子融合和内存规划那才是最考验细节、也是最容易拉开性能差距的地方。