★ FEATURED ARTICLE 1. 从CPU的困境说起为什么需要NPU/TPU这类专用加速器如果你最近两年在关注端侧AI部署或者云端推理集群的搭建大概率会被一堆缩写砸晕NPU、TPU、NPU、VPU、DSA……厂商发布会上一律宣称算力翻倍能效比提升数倍但真到自己动手把模型往这些硬件上搬的时候才发现事情远没有PPT上那么顺滑。这一章我想聊的就是这些专用加速硬件到底解决了什么问题、它们的内部大致长什么样、以及在真实项目里怎么把模型跑上去、跑得稳。先说一个我经常拿来开场的对比。假设你有一台普通的x86服务器跑一个ResNet-50的推理CPU占用率拉满单张图延迟大概在几十毫秒量级。同样的模型放到一块入门级NPU上功耗可能只有CPU方案的几分之一延迟却能压到个位数毫秒。这个差距不是靠优化代码能追回来的它来自架构层面的根本差异。CPU的设计哲学是通用。它要有复杂的乱序执行、分支预测、多级缓存、大容量寄存器堆为的是能高效处理各种不可预测的控制流——操作系统调度、数据库事务、编译过程这些任务里充满了分支跳转和随机内存访问。代价是真正用于乘加运算的ALU面积占比其实很小大部分晶体管都花在了让程序跑得顺这件事上。而神经网络推理这件事恰恰是CPU最不擅长的类型计算模式高度规整几乎全是矩阵乘和卷积数据流可预测分支极少。用CPU跑推理就像开着一辆越野车在高速公路上送快递——能到但浪费。NPUNeural Processing Unit和TPUTensor Processing Unit就是为这类负载量身定制的。它们把绝大部分芯片面积让给了MAC阵列乘累加单元阵列和片上缓存砍掉了复杂的控制逻辑。一个典型的NPU可能包含几千到几万个MAC单元配合专门的数据搬运引擎让数据像流水线一样流过计算阵列算完就走不需要反复进出主存。这里有个关键概念叫数据复用。卷积运算里同一个权重会被反复使用很多次同一块输入特征图也会被多个输出通道共享。CPU靠缓存来复用数据但缓存容量有限、命中率不稳定。NPU则通过显式的片上缓存比如Weight Buffer、Input Buffer、Output Buffer和精心设计的数据流如Weight Stationary、Output Stationary、Row Stationary把复用做到极致从而大幅降低对主存带宽的依赖。这一点在端侧尤其重要因为移动设备的内存带宽和功耗预算都极其紧张。所以当你看到NPU算力XX TOPS这种宣传时别只看TOPS数字。真正决定实际性能的是这个算力在多大程度上能被你的模型用上。一个标称10 TOPS的NPU如果数据搬运跟不上实际有效算力可能只有2 TOPS。这就是为什么后面我们要花大量篇幅讲算子映射和数据布局。2. NPU与TPU的架构分野从脉动阵列到可重构数据流很多人把NPU和TPU混着叫严格来说TPU是某类张量处理器的专有名称NPU是更宽泛的品类。但从架构思路上它们可以分成几个流派理解这些流派对选型和调优非常关键。2.1 脉动阵列TPU的经典打法脉动阵列Systolic Array是最常被拿来讲的一种结构。它的核心思想是让数据像心跳一样有节奏地在PE处理单元阵列中流动每个PE只和相邻的PE通信不需要全局互联。以经典的256x256脉动阵列为例权重从左侧流入激活从上方流入每个周期完成一次乘加并把部分和向下传递。这种结构的优点是互联简单、时钟频率容易做高、能效比极佳。缺点是灵活性差——阵列尺寸固定遇到不规则的算子比如深度可分离卷积、注意力机制里的各种变形利用率会掉得很厉害。一个为3x3标准卷积设计的脉动阵列跑1x1卷积或者转置卷积时PE的闲置率可能超过一半。我在实际项目里遇到过这样的情况某款芯片标称算力很高但跑MobileNet系列时实际吞吐只有理论值的30%左右原因就是深度卷积的通道数太少喂不满阵列。后来通过算子融合把多个层合并才把利用率拉回来一些。2.2 可重构数据流更灵活的中间路线另一类NPU采用可重构的数据流架构典型代表是粗粒度可重构阵列CGRA。它不像脉动阵列那样固定连接而是可以通过配置网络把PE按需连成不同的计算图。这样既能高效跑标准卷积也能处理一些非规则算子。这类架构的编程模型通常更复杂需要编译器做大量的图划分和调度。好处是通用性更好坏处是工具链成熟度参差不齐。我见过一些国产NPU的编译器对某些算子的支持就是能跑但慢需要手动改写模型结构来绕开。2.3 向量矩阵混合兼顾灵活与效率还有一类设计是把向量单元和矩阵单元放在一起。向量单元处理Element-wise操作、激活函数、归一化这些逐元素运算矩阵单元处理卷积和全连接。这种混合架构在端侧SoC里很常见因为端侧模型往往包含大量非矩阵运算。从部署角度看混合架构的好处是算子覆盖率高不容易出现某个算子没有硬件支持只能回退到CPU的情况。坏处是调度复杂向量单元和矩阵单元之间的数据同步如果没做好会出现流水线气泡。下面这张表是我根据实际接触过的几类硬件整理的对比供选型时参考架构类型典型算力密度算子灵活性工具链成熟度适合场景固定脉动阵列极高低中标准卷积为主的视觉模型可重构阵列高中高偏低多模态、非规则算子较多的模型向量矩阵混合中高高高端侧综合负载GPU作为对照中极高极高训练、需要频繁改结构的场景需要说明的是这张表是经验性的粗略划分具体到某一款芯片还要看制程、频率、内存子系统等一堆因素。选型时最靠谱的办法是拿自己的真实模型去实测别信纸面参数。3. 把模型搬上NPU从框架导出到算子映射的完整链路这一节是实操重点。很多人第一次部署NPU时的流程是这样的训练好的模型 → 导出ONNX → 用厂商工具转换 → 报错 → 查文档 → 改模型 → 再转 → 再报错。循环若干次之后要么成功要么放弃。我把这条链路拆开讲尽量让你少走几圈。3.1 导出前的模型体检在导出之前先做几件事能省掉后面大量麻烦。第一固化输入shape。NPU编译器通常需要静态shape动态维度比如batch size可变、序列长度可变会导致编译失败或者生成多个子图。如果你的模型有动态维度尽量在导出时固定下来或者用多个固定shape的版本分别编译。第二清理训练专用节点。Dropout、BatchNorm的训练模式分支、各种debug输出节点这些在推理时都是累赘有些还会导致转换失败。用torch.onnx.export的时候记得设trainingTorchMode.EVAL导出后可以用工具看一下图里还有没有多余的节点。第三检查算子版本。ONNX的算子集版本opset很关键。太老的opset可能缺少某些算子太新的opset厂商工具可能还没支持。我一般会先查厂商文档支持的opset范围然后导出时指定一个居中的版本。# 导出ONNX时的关键参数示例 torch.onnx.export( model, dummy_input, model.onnx, opset_version13, # 根据厂商支持范围选择 input_names[input], output_names[output], dynamic_axesNone, # 固定shape不设动态轴 do_constant_foldingTrue, # 常量折叠减少冗余节点 )导出后强烈建议用onnxsim做一次简化把恒等节点、冗余的transpose、可以合并的常量都清掉。这一步能让后面的转换成功率明显提升。3.2 量化绕不开的一环绝大多数NPU为了能效只支持定点运算常见的是INT8部分支持INT16或混合精度。所以量化几乎是必经之路。量化的核心是确定scale和zero_point。对对称量化scale max(abs(x)) / 127对非对称量化还要算zero_point。听起来简单但实际做的时候有几个坑校准集的选择校准集要能代表真实输入分布。我见过有人用训练集的前100张图做校准结果模型在真实场景下精度掉得厉害因为训练集和线上数据的分布差异很大。校准集最好从验证集或者真实业务数据里采样覆盖各种边界情况。逐层量化 vs 逐通道量化逐通道量化精度更好但不是所有硬件都支持。如果硬件只支持逐层那对权重分布差异大的层比如某些深度卷积要特别小心。敏感层保护第一层和最后一层通常对量化最敏感可以考虑保留FP16或者用更高的位宽。有些工具链支持混合精度把敏感层标出来就行。量化完之后一定要做精度对比。我一般会跑一个完整的验证集看Top-1/Top-5掉了多少。如果掉点超过1%就要回去查是哪一层的问题。可以用逐层敏感度分析工具把每层单独量化看精度变化定位问题层。3.3 算子映射与替换这是最容易卡住的地方。NPU的算子支持列表是有限的你的模型里只要有一个不支持的算子整个图就可能断成两半不支持的部分回退到CPU性能直接崩掉。常见的钉子户算子包括各种非标准激活函数比如GELU的某些变体、Swish的近似实现动态shape相关的操作如NonZero、Where配合动态索引复杂的注意力机制实现尤其是带mask的动态逻辑自定义的归一化层处理思路有三条数学等价替换把不支持的算子用支持的算子组合出来。比如某些激活函数可以用查表LUT近似或者用分段线性拟合。结构调整把动态逻辑改成静态。比如注意力里的mask如果能提前知道最大长度可以padding到固定长度用静态mask。算子融合把多个小算子合并成一个减少映射次数。ConvBNReLU这种经典组合大部分工具链会自动融合但更复杂的组合可能需要手动指定。我个人的经验是在模型设计阶段就要考虑目标硬件的算子支持。如果项目允许尽量用硬件友好的结构——标准卷积、标准激活、固定shape。那些为了刷点而设计的花哨结构在部署时往往要付出成倍的代价。4. 性能调优实战内存布局、流水线与多核调度模型能跑起来只是第一步跑得快才是目标。这一节讲几个我在实际调优中反复用到的抓手。4.1 内存布局NHWC还是NCHW这个看似基础的问题实际影响巨大。很多NPU内部计算用的是NHWC布局通道在最后因为这样连续内存访问更友好便于向量化加载。但训练框架默认往往是NCHW。如果转换工具没有自动处理布局就会在每次卷积前后插入transpose这些transpose在NPU上可能没有硬件加速直接拖垮性能。我的做法是在导出ONNX之前就把模型转成NHWC或者在转换工具里显式指定输入布局。转换完成后用工具看一下生成的图里有没有多余的transpose节点。如果有要么是布局没对齐要么是某个算子强制要求了不同布局。4.2 双缓冲与流水线NPU的计算通常分几个阶段数据加载DMA、计算、结果写回。如果这三个阶段串行执行计算单元会有大量时间在等数据。好的实现会用双缓冲Double Buffering当计算单元在处理当前块数据时DMA已经在预取下一块数据了。作为开发者你能控制的是分块策略。把大的特征图切成小块tile让每块的数据量适配片上缓存大小。块太小DMA启动开销占比高块太大缓存放不下会溢出到主存。这个平衡点需要根据具体硬件的缓存容量和DMA效率来调。有些工具链提供了自动分块但默认参数不一定最优。我一般会手动试几组tile size看哪个吞吐最高。这个过程有点像调数据库的page size理论指导有限实测最靠谱。4.3 多核与任务并行高端NPU往往有多个计算核心。怎么把模型分配到多个核上有两种思路层间并行不同的层分到不同的核形成流水线。适合层数多、每层计算量相对均匀的模型。层内并行同一层的计算切分到多个核。适合单层计算量特别大的情况比如大通道数的卷积。实际工具链通常会做自动切分但切分策略对性能影响很大。我遇到过一个案例工具默认按层间并行切分结果因为某些层计算量太小核间同步开销超过了并行收益反而不如单核。后来改成手动指定切分点把计算量大的几层做层内并行性能提升了40%多。4.4 批处理与延迟的权衡批处理Batching能提高吞吐但会增加延迟。在云端推理场景通常追求高吞吐可以攒一批请求一起跑。在端侧或者实时场景延迟是硬指标往往batch size只能设1。如果必须用batch1那就要在别的地方找性能比如用更激进的量化、更小的输入分辨率、更精简的模型结构。我见过一些团队为了压延迟把模型剪枝到原来的60%参数量精度只掉了0.3%延迟降了三分之一这笔账很划算。5. 踩坑实录那些文档里不会写的报错与排查思路这一节我挑几个印象深刻的坑把排查过程完整写出来。这些问题的共同点是报错信息模糊文档里搜不到只能靠一步步试。5.1 转换成功但推理结果全错有一次模型转换工具显示成功没有报任何warning但推理输出全是乱码一样的数值。排查过程如下第一步检查输入数据。用同样的输入分别跑原始框架和NPU版本确认输入预处理完全一致。这一步排除了输入归一化参数不一致的可能。第二步逐层对比中间输出。把原始模型和转换后的模型都改成逐层输出喂同一组输入看从哪一层开始出现偏差。结果发现第一层卷积的输出就对不上。第三步检查第一层的权重。把转换后模型里第一层的权重dump出来和原始权重对比发现数值被量化后偏差极大。原来这一层的权重分布范围很宽有几个离群值导致量化scale被拉得很大大部分权重被压到了很小的量化级别上。解决办法对这一层单独做逐通道量化或者把离群值clip掉再量化。改完之后第一层输出就对上了整体精度也恢复了。这个坑的教训是转换成功不等于结果正确。一定要做数值对比而且要逐层对比才能快速定位问题层。5.2 性能远低于预期profiling发现DMA瓶颈另一个案例模型跑起来了精度也正常但延迟是预期的5倍。用工具链自带的profiler一看计算单元利用率只有20%大量时间花在DMA等待上。进一步看DMA的传输模式发现每次搬运的数据块很小而且地址不连续。原因是模型里有个reshape操作把原本连续的内存打散了后续的卷积只能按碎片化的方式读数据。解决办法调整模型结构把reshape移到不影响后续卷积的位置或者在转换工具里指定内存对齐参数。改完之后DMA效率上来了延迟降到预期的1.2倍。这个坑说明性能问题往往不在计算本身而在数据搬运。profiling工具是必须用的别靠猜。5.3 多核调度导致的偶发精度问题最诡异的一次单核跑没问题多核跑偶尔会出现精度异常而且不是每次都复现。排查了很久最后发现是两个核同时写同一块输出缓存产生了竞争。工具链的自动切分在这个模型上有个bug把有依赖关系的两个层分到了不同核却没有加同步。解决办法手动指定切分点避开有依赖的层。或者升级工具链版本厂商后来修复了这个问题。这个坑的教训是多核并行不是免费的依赖关系没理清就会出问题。上线前一定要做压力测试跑足够多的次数偶发问题最致命。6. 选型与落地怎么判断一块NPU适不适合你的项目最后聊聊选型。市面上的NPU/TPU方案很多参数表看得人眼花。我一般从这几个维度去评估第一算子覆盖率。拿你的真实模型去跑转换看有多少算子能映射到硬件多少要回退。回退比例超过10%就要慎重了。第二工具链成熟度。看文档是否完整、报错信息是否清晰、社区是否活跃。一个工具链如果报错只会说conversion failed那调试成本会非常高。第三量化支持。是否支持逐通道量化、混合精度、敏感层保护。这些直接决定你能把精度保住多少。第四内存带宽。算力再高带宽跟不上也是白搭。看片上缓存容量、主存带宽、DMA效率。第五实际能效。别只看TOPS要看TOPS/W而且是在你的模型上实测的TOPS/W。我个人的经验是选型阶段一定要做POC概念验证拿真实模型跑通全流程测出真实性能和精度。纸面参数和实际表现之间的差距有时候大得离谱。POC阶段多花两周能省掉后面几个月的返工。还有一点考虑模型的演进。如果你的业务会不断迭代模型结构那就要选算子支持更灵活、工具链更新更勤的方案。如果模型结构基本固定那可以选针对性强、能效更高的专用方案。这个权衡没有标准答案取决于你的业务节奏。从趋势上看端侧NPU的算力还在快速上涨工具链也在逐步统一比如大家都在往ONNX和MLIR生态靠。但短期内跨平台部署的碎片化问题还会存在。作为开发者能做的是把模型设计得尽量硬件友好把部署流程尽量标准化这样换硬件时迁移成本能低一些。
阅读完成 · 觉得有帮助？
