过去两年我经手过的AI SoC项目从边缘端的几十TOPS小芯片到面向数据中心的大算力方案都有。有一个认知是反复被验证的一颗AI SoC设计得好不好不能只看NPU那颗“心脏”有多强更要看数据到底能不能在正确的时间被搬到正确的位置。算力是账面数据存储带宽和片上互联才是决定实际帧率、实际时延、实际能效的真正变量。这篇文章就以我实际做架构评估和流片反馈的经历把NPU、存储子系统、片上互联这三块拆开讲清楚。1. 先泼一盆冷水TOPS这个数字最容易骗人1.1 一个只堆MAC阵列的失败案例三年前有个项目定义规格时市场那边给的输入很明确INT8算力要超过50TOPSDDR带宽不低于32GB/s成本控制在某个区间里。于是架构组花了很大力气去堆MAC阵列128行乘128列的乘累加单元频率拉到1.5GHz理论算力刚好做到49.1TOPS。整个NPU的datapath、DMA、乃至指令发射逻辑都是围绕“如何把MAC阵列喂饱”设计的。流片回来之后跑ResNet-50预期的500帧每秒没看到实测只有不到200。定位了很久问题根本不在MAC阵列本身而在数据供给片内SRAM总共只有2MB权重和激活值根本放不下每一层卷积都要从DDR反复搬运中间结果。那个项目让我非常确定一件事MAC阵列是成本最低也最容易做的部分真正难的是让MAC周围的数据通路配得上它。1.2 TOPS的换算逻辑和几个反直觉的地方不少刚开始接触AI芯片的同学会把TOPS当成一个单一维度的性能标尺其实这里面的坑挺多。先看一个基本换算一个MAC乘累加运算包含一次乘法和一次加法所以每周期执行N个MAC意味着每周期贡献2N次操作Ops。比如一个128*128的MAC阵列频率1.5GHzINT8算力就是128 * 128 * 2 * 1.5GHz 49152 GOPS 49.1 TOPS这只是峰值。实际能跑出多少取决于数据能不能喂进去因此业界更关注MAC利用率MAC utilization。我见过不少芯片标称50TOPS实测卷积层利用率85%但到了Transformer的自注意力层利用率直接掉到40%以下。掉利用率的原因通常不在计算而在存储和互联。还有一个反直觉的点主流AI芯片标称的TOPS往往是指INT8稠密算力而FP16、BF16算力一般只有INT8的一半或四分之一INT4则可能是INT8的两倍。训练芯片更在意浮点精度推理芯片则普遍会用低精度整数来堆算力。这个选择直接影响MAC阵列的晶体管布局和供电设计后面细说。1.3 从SIMD到脉动阵列MAC阵列的几种性格同样是做MAC阵列设计哲学差别很大。最早的GPU类方案走的是SIMD路线一组ALU在同一指令下处理多组数据灵活但控制开销大TPU这种脉动阵列走的是另一种极端——数据在阵列里像水一样流过每个MAC每个MAC不需要反复从寄存器读操作数功耗和面积都更划算但灵活性差遇到不同形状的算子容易有空泡近几年的可重构数据流架构如Systolic Array的变体和CGRF风格方案则同时保留阵列吞吐和操作灵活性代价是复杂的路由逻辑。这里建议团队在做架构选型前先把目标模型集的算子形状做个统计。如果主要跑卷积脉动阵列通常最划算如果模型里全是动态shape、稀疏计算、各种自定义算子那可能得牺牲一点峰值效率去换灵活性。我踩过最深的坑就是照搬了某论文里漂亮的脉动阵列设计结果在跑短序列Transformer时阵列利用率低到没法看——脉动阵列有固定的流水填充时间序列太短填充和排空的时间占比反而变高。2. NPU核心MAC阵列怎么定、片上SRAM怎么配2.1 MAC阵列的尺寸选择不是拍脑袋MAC阵列的尺寸选择本质上是在算力目标、面积预算、时钟频率、数据供给能力四个维度之间找平衡。工艺给定后可用的时钟频率基本有个上限比如7nm工艺下做128*128阵列跑到1.5GHz已经比较紧张要继续加算力就得扩阵列尺寸而不是拉频率。阵列尺寸扩大一倍面积大概跟着翻倍供电网络、时钟树的压力也同步上升。一个实用的设计方法是先定“目标模型集目标帧率/时延”反推实际所需的持续算力再留出50%到100%的利用率补偿算出标称TOPS。接下来用标称TOPS和MAC阵列频率反推阵列行列数。比如目标是持续30TOPS预留利用率70%那么标称TOPS要超过42.8TOPS若频率定在1.2GHz需要的MAC数量就是42.8 * 10^12 / (2 * 1.2 * 10^9) 17833个MAC考虑到阵列通常是正方形或接近正方形的排布取128144或者128160同时要给偏置加法、激活函数、池化留出独立的处理单元。这样算下来最终阵列尺寸往往比拍脑袋定的更接近真实需求。2.2 片上SRAM容量和分块策略片上SRAM是AI SoC里比MAC阵列更值钱的资源。SRAM的读写带宽远高于DDR功耗低好几个数量级但面积贵、漏电不可忽视。设计存储层级时我习惯先用一个简单的公式估算所需SRAM容量必需SRAM容量 ≈ 单层最大的权重尺寸 单层最大的输入激活尺寸 输出累加器尺寸 双缓冲余量以BERT-base为例一个Transformer层的权重约在30MB左右4096*1024的矩阵乘以四个绝大多数中低端AI SoC都不可能把它全放片上所以需要tiling策略把权重按行或按列切成块逐块搬运到片上计算。这时SRAM容量反而可以小一点但带宽必须够大否则每次切块都会卡在搬运上。我遇到过的问题恰好相反某款芯片把SRAM做到了16MB看着很大但由于把存储物理上分成了8个独立bank每个bank只有独立的读写端口当某个算子集中访问其中一个bank时其他bank闲置有效带宽只有理论峰值的一半。所以存储分块不只是考虑总容量还要看访问模式。正确做法是先跑一遍目标模型的内存访问trace找出热点bank再做bank数量、端口、交叉开关的联合设计。2.3 精度和量化如何反向影响硬件结构推理SoC普遍采用INT8原因是8bit乘法器面积只有FP32的约四分之一功耗低得多对精度影响在大多数CV模型里可以接受。但这里有个容易被忽视的细节MAC阵列里累加器的位宽通常不是8bit而是16bit或32bit。INT8乘INT8得到一个16bit结果若干乘积累加后可能溢出16bit所以累加器要做32bit否则用户做量化时会出现莫名其妙的精度损失最后还要软件层背锅。如果目标场景是LLM这类对精度更敏感的模型可能需要支持INT4和INT8混合精度、或BF16对齐训练推理。支持FP16/BF16意味着MAC阵列里要有16bit乘法通路面积功耗显著上升。这里要特别注意权衡。我们团队做过对比同样的128*128阵列INT8-only的面积比INT8FP16双模式小大概三分之一功耗优势更明显。如果产品定义里确定不需要训练、也不需要跑高精度浮点就不要为了“看起来全功能”去堆FP16通路省下的面积和功耗留做SRAM或者互联带宽会更划算。3. 存储层级AI推理SoC真正的带宽命门3.1 一次Transformer推理的访存账单怎么算很多团队在定义存储子系统时容易只盯着带宽峰值忽视实际数据重用度。以自注意力层为例虽然计算密集度不低但在推理阶段每个token的Query、Key、Value向量都需要和全部历史Key/Value做矩阵乘历史缓存的访存量会随序列长度线性增长。若序列长度较长访存开销完全可能超过计算开销也就是所谓“memory-bound”状态。这里给一个估算方法。假设当前模型权重矩阵为W尺寸为MN每个元素内存字节数为B字节。完成这一层的矩阵乘法需要读取权重一次约MNB字节计算量约2M*N次操作MAC的两倍。于是“计算访存比”算术强度是算术强度 2MN / (MNB) 2 / B如果B1INT8算术强度就是2 Ops/Byte如果B2FP16/BF16算术强度就是1 Ops/Byte。而MAC阵列每周期能做128128232768次操作要让阵列不空等存储系统每秒得提供至少32768 / 2 16384字节/周期对应INT8的情况。1.2GHz频率下即约19.6GB/s。这还只是单个MAC阵列的权重读取需求如果再加上激活值、中间结果的读写实际要求会更高。因此一台理论算力50TOPS的INT8设备DDR带宽至少要超过30GB/s才勉强喂得饱低于这个值的时候多高的TOPS都是摆设。3.2 LPDDR5还是HBM成本、带宽、功耗三线评估这是一个经常在架构评审会上被反复讨论的问题。直接说结论边缘设备用LPDDR数据中心或高性能计算板卡用HBM。这句话听起来是废话但中间的决策过程有着明确的测算依据。指标LPDDR5HBM2EHBM3单颗容量范围8~64GB8~24GB8~48GB(单栈)单颗典型带宽51.2GB/s(64bit)460GB/s819GB/s单位带宽成本低高更高功耗/Byte约3~5pJ更低但封装/TSV开销大类似HBM2E封装复杂度简单可直接贴装系统板2.5D/CoWoS封装转接板成本高同HBM2E但设计更严选择时核心问题只有一个系统需要多少内存带宽。如果目标场景是端侧多模态模型权重总量大概在2~8GB量级帧率要求不高LPDDR5在成本上优势明显。如果目标是数据中心高并发推理单卡需要吞吐几百GB甚至1TB以上带宽那只有HBM类方案满足得了。有一种折中方案是LPDDR5X接多通道并把数据通路加宽实测能到100GB/s以上但芯片引脚数和系统布线复杂度会显著上升成本未必比低配HBM方案便宜太多。需要按具体项目把两个方向的系统BOM成本、PCB层数、功耗预算都算一遍再拍板。3.3 多核缓存一致性CPU和NPU到底怎么共享数据AI SoC上通常既有通用CPU核也有NPU还可能有DSP、GPU。CPU上跑应用和调度NPU跑模型推理它们之间需要交换输入输出数据。最简单的做法是软件通过DMA显式搬运但这对软件工程师并不友好所以很多SoC选择做硬件缓存一致性。硬件一致性带来明显好处CPU和NPU可以像操作普通内存一样访问同一块地址空间省掉大量驱动层的拷贝操作。但代价也很大需要一致性协议引擎如AMBA ACE或CHI需要为所有一致性的master维护目录Directory还需要保证跨时钟域、跨电源域的同步面积和验证工作量都显著增加。以经验来看是否做硬件一致性取决于CPU和NPU交互频率。如果NPU输入输出数据量大、但交互次数少比如一次AI识别只提交一次任务、拿一次结果用显式DMA缓存维护就完全够了如果要跑交互密集的实时控制类推理比如SLAMCPU和NPU每一帧都要做大量小数据同步硬件一致性才有价值。还有一个折中方案是只做IO一致性IO Coherency让NPU作为外设通过一致性端口读CPU侧缓存数据但CPU不能反读NPU内部buffer。如果NPU的运行时内存要求可控这个方案性价比很高是我们现在比较倾向的选择。4. 片上互联与片间互联把一千个核心捏成一个系统4.1 总线、NoC和网络片不同互联形态的取舍AI SoC的片上互联架构通常被低估。许多中等规模SoC仍然以AXI总线作为主要互联手段简单成熟但带宽和并行度有限。真正的AI SoC动不动就是几十个上百个主设备总线方案走到带宽极限后会迅速恶化时延和功耗。这时候就需要NoC片上网络Network-on-Chip。NoC把数据包化后在二维网格或环形拓扑里路由。网格拓扑可扩展性好但平均跳数多时延大环形拓扑平均跳数少但单跳带宽压力大还有树形、交叉开关等。选择没有绝对答案我通常建议根据数据流模式来确定如果数据流主要是一对多如DDR数据分发到多个NPU集群用树形或者集中交叉开关更直接如果是多对多多个NPU集群互相交换中间数据2D Mesh或环形更合适。这里有个实操经验不要只在IDE里做理论分析要拿真实模型的通信trace去验证。我遇到过一款芯片仿真阶段Mesh网络平均时延很好但上板后发现特定报文模式下的死锁问题最后只能靠软件绕路性能和设计预期差了很多。如果当时在架构阶段就做更贴近真实流量的NoC吞吐压测这个问题完全可以提前暴露。4.2 带宽、时延、QoS互联设计的三条铁律AI SoC互联设计要同时满足三个目标足够的聚合带宽、可预测时延、以及关键业务的QoS保证。聚合带宽取决于总线的数据位宽和时钟频率公式很简单聚合带宽 总线位宽 / 8 * 时钟频率例如256bit位宽、1GHz时钟聚合带宽为32GB/s。但同一条NoC如果被多个主设备同时访问要考虑仲裁策略。标准AXI的仲裁是轮询或优先级在AI负载下容易出现某个低优先级但在实时链路上的数据等了太久导致整体性能抖动。QoS设计最常见的做法是按请求类型分虚拟通道Virtual Channel把对时延敏感的请求比如NPU的关键权重读取和对带宽敏感但时延不敏感的请求比如批量日志写入DDR隔离开。我们之前的芯片里还做过按主设备ID限速的机制避免某个np桶把自己跑满把系统拖死。这个细节听上去很小但在多路并发推理场景下的表现差异非常大。4.3 Chiplet和UCIe把一颗巨大SoC拆开重组进入后摩尔时代单die面积过大导致良率低、成本高chiplet芯粒化成为高性能SoC的主流选择。AI SoC天然适合拆成几个die计算dieNPUCPU、IO dieDDR/LPDDR控制器、PCIe控制器、以及可能的HBM堆叠。die与die之间必须靠高速SerDes链路互联目前主流协议是UCIe也有不少自研BoWBunch of Wires方案。UCIe的物理层是一条条低摆幅高速差分线数据率可以从16GT/s做到32GT/s以上。一个die上数百条UCIe线聚合带宽能到几TB/s量级比传统PCIe结构灵活得多。但UCIe功耗也不低长距传输时每条lane都要消耗几十毫瓦。所以设计时依然遵循“能片上访问就不走die间”的原则把交互最频繁的模块放在同一个die里。如果芯片太大不得不拆优先让每个die内部的访问保持局部化die间只做低频控制和高层数据同步这样系统性能和功耗都会健康很多。有些团队担心chiplet会带来额外的封装和测试成本。我的观点是如果芯片面积超过大概600平方毫米或者某些IP比如HBM控制器单独做die能显著提升良率那么chiplet的收益大概率覆盖成本。前提是提前做好信号完整性和热仿真别等到样片回来才发现某条die间链路在高温点不稳定。5. 设计流程里的性能建模和验证方法5.1 算力带宽比开机前先算性能上界芯片还没影的时候架构师就得能用表格算出系统的性能上限。工具不复杂一张Excel往往比花几个月做仿真平台更快。核心思路是罗列出系统的关键资源MAC阵列总吞吐、SRAM访问带宽、DDR带宽、NoC各节点带宽然后对目标模型的每一类算子计算各自的计算量和访存量二者取小就是理论极限。以卷积层为例某层计算量为C访存量权重输入输出为M如果MAC阵列理论每秒能做P Ops那么“计算时间”是C/P如果存储带宽是B那么“访存时间”是M/B。这一层的执行时间下限是max(C/P, M/B)。把整个网络逐层加起来加上流水线重叠因子就能估算芯片跑该模型的最小可能时延。如果这个估算值比产品需求差很多那就不用先进仿真平台先将DDR带宽或者SRAM容量调整一轮再算。这个习惯能帮团队省下大量改架构的时间。5.2 从SystemC/TLM仿真到FPGA原型验证架构定下来之后需要验证微架构是否跟设计意图一致。各家主流做法是搭TLMTransaction-Level Modeling模型用SystemC描述NoC、缓存、DDR控制器、NPU内部流水线的事件级行为。TLM跑起来比RTL仿真快几个数量级适合做多任务并发和带宽压力测试。但TLM始终是抽象模型某些底层行为它模拟不了比如DRAM的bank冲突、page miss、NoC报文路由死锁。这些坑只有到了RTL仿真甚至FPGA原型阶段才会暴露。我建议团队在RTL冻结前就做一轮“FPGA跑真实模型”的门禁测试把NPU逻辑装进FPGA开发板接上真实的LPDDR颗粒跑几个代表性模型收集实际带宽和利用率数据。FPGA频率远低于目标芯片但数据流的正确性和卡点位置依然有很高的参考价值。我们最近一个项目就是靠FPGA测试发现某条NoC的低优先级报文在重负载下几乎完全抢不到通道导致CPU侧控制路径超时。这个bug如果拖到流片后才发现问题就不是改两行代码能解决的了。5.3 实测阶段如何定位“NPU空转”芯片回来之后第一件事不是跑benchmark而是跑自带的微基准测试。把MAC阵列、DMA、DDR控制器各自隔离出来测试确认单项能力达标。然后逐步增加负载观察性能计数器。这里强烈建议在做RTL时就把性能计数器设计进去我自己吃过没做性能计数器的亏。最早一块芯片上板实际帧率只有理论设计的六成但没有任何硬件计数器能告诉我们NPU到底在等什么——是等DDR数据还是在等NoC通道还是在等SRAM仲裁最后只能靠在代码里插桩软件插桩来猜浪费了整整三周。后来的项目里我们会在NPU的每个关键流水级放一组计数器统计stall周期和stall原因等于给芯片装了仪表盘。定位NPU空转的时候一读计数器就能知道瓶颈在哪个模块。还有一类问题属于电源和热。高性能推理SoC在满负载下功耗波动很大MAC阵列全速运转时die温度快速上升这会直接导致DRAM刷新周期和时序参数变化进一步增加内存时延。实测阶段一定要把热负载和性能测试一起做否则在恒温环境下测出的数据到用户真实场景里会明显出入。6. 与硬件强绑定的软件栈没有编译器NN加速器只是废铁6.1 算子映射不到硬件上再强的NPU也是白做我在做AI SoC架构时最常对硬件工程师说的一句话是如果一个算子无法被编译器高效映射到MAC阵列上它就不该出现在目标模型的精度或速度承诺里。很多AI芯片团队堆了强大的硬件资源但软件工具链跟不上导致用户无法跑通或无法发挥硬件性能。这个现象在行业里太常见了。软件栈的第一个关键环节是算子库/编译器。主要有两条路线一条是为每个算子手工写汇编级kernel性能可控但工程量大另一条是基于编译器如TVM、MLIR做自动调度灵活但调优难度大。实际项目中两条路线通常是混合的成熟算子的kernel手工优化新出现的算子走自动编译兜底。但自动编译的生成代码性能往往只有手写的七八成如果产品对性能要求苛刻就需要在硬件设计时就把编译器能力考虑进去比如给编译器提供连续性更好的存储布局、明确的异步DMA指令、可配置的数据流模式。6.2 从PyTorch模型到SoC上的部署链路现在主流部署链路大概是这样的PyTorch/TensorFlow训练好模型后导出ONNX再做图优化和量化映射到硬件指令。每步都有坑。量化就是个重灾区直接用PTQ训练后量化在敏感模型上经常掉点严重需要用QAT量化感知训练才能保证精度。硬件对量化方式的支持程度直接决定部署效果所以架构定义时就要确定是否支持per-channel量化、是否支持非对称量化、激活值用动态范围还是静态范围。这些看起来都是软件问题但最终是硬件寄存器提供的能力决定的。还有图优化层面的细节比如算子融合。ConvBNReLU融合成单算子可以把中间结果的读写省掉访存量能降一半以上。前提是NPU硬件支持注入式activation和bias更新并且编译器能识别这种融合模式。由此可见SoC的指令集设计也不只是给硬件用的而是给编译器准备一套舒适、可预测的抽象接口。6.3 为模型结构演进预留硬件灵活性最后谈一点面向未来的问题。AI模型演进非常快两三年前的神经网络结构和现在的Transformer等新结构差异巨大。硬件一旦流片就很难改变但软件还可以迭代所以架构师必须在硬件设计时就预判未来两三年模型结构的变化。具体来说我会关注几个点一是算子复杂度是否会出现更多动态shape、动态长度对应硬件是否需要支持更灵活的tiling二是精度需求是否会普遍转向INT4或者混合精度MAC阵列能否支持类似INT4乘INT8的特殊指令三是注意力类算子的存储访问模式是否值得在硬件里设计专用的KV cache管理单元这个对未来LLM推理的能效影响极大。每次做架构决策时我都会让团队先列出“三年后用户可能会跑什么模型”再对照当前方案做差距分析。这个习惯帮我们在一款边缘芯片上提前预埋了KV cache支持逻辑后来客户要跑端侧大语言模型时我们的方案在能效和时延上都明显优于同期竞品。回看整个设计流程AI SoC的本质不是一个单独的大核而是一套围绕数据搬移构建的系统工程。NPU、存储、互联三者从来都不是独立模块而是互相制约的一体化设计。如果你也在做类似的项目建议在架构定义早期就把三者的物理量和数据流模型放到同一张表里做联调分析而不是各团队各自为战——这是我做了这么多代AI芯片之后最想分享的一件事。