端侧AI这个词这两年出现的频率越来越高但很多人对它的理解还停留在把模型塞进手机里跑这个层面。真正做过端侧部署的人都知道模型能不能跑起来只是第一步跑得快不快、功耗低不低、内存够不够才是决定产品能不能落地的关键。而这些问题最终都会收敛到一个核心命题上张量这种数据结构是怎么在NPU这种专用硬件上被高效执行的。我自己是从移动端推理框架一路做过来的早期用CPU跑卷积网络后来转到GPU再到现在主力做NPU算子适配和端侧部署。这个过程中踩过的坑、绕过的弯路远比看几篇论文要多得多。这篇文章不打算讲太多理论推导而是想从一个实际做端侧部署的工程师视角把张量在NPU上的执行链路拆开来看——从数据排布、算子映射、内存调度到量化策略每一层都有它存在的理由也有它容易出问题的地方。如果你正在做端侧AI硬件部署或者想搞清楚CPU、GPU、NPU在跑大模型时到底有什么区别又或者你只是好奇张量这个东西在硬件层面到底长什么样那这篇内容应该能给你一些实在的参考。我会尽量用生活化的类比来解释底层机制同时给出可以直接对照的实操思路和参数配置建议。1. 张量在端侧硬件上到底长什么样1.1 从数学概念到内存布局的转换在数学课本里张量就是一个多维数组听起来很抽象。但在端侧硬件上张量首先是一块连续的内存区域然后才是一个多维数组。这个区别非常关键因为硬件不关心你的数学定义它只关心数据在内存里怎么排、怎么取。举个具体的例子。一个形状为[1, 3, 224, 224]的输入张量在PyTorch里是NCHW格式意思是批次、通道、高度、宽度。但在很多NPU上这个张量会被转换成NHWC格式也就是批次、高度、宽度、通道。为什么要换因为NPU的卷积计算单元通常按照通道维度做向量化NHWC格式下通道维度的数据在内存里是连续的取数效率更高。这个转换过程叫布局变换Layout Transform听起来只是换个顺序但实际部署中它可能是性能杀手。我遇到过不少情况模型在CPU上跑得好好的转到NPU上反而慢了排查到最后就是布局变换引入了额外的内存拷贝。所以你在做端侧部署时第一件事就是确认目标硬件偏好的张量布局然后在模型转换阶段就把布局固定下来避免运行时反复转换。1.2 端侧硬件的内存层级与张量驻留策略端侧设备和服务器最大的区别在于内存层级极其复杂。服务器上你基本只需要关心DDR和显存但端侧SoC里通常有寄存器文件最快但容量极小通常只有几十KB片上SRAM速度接近寄存器容量在几百KB到几MB之间L2/L3缓存共享缓存容量稍大但延迟增加DDR/LPDDR主存容量大但带宽有限、功耗高张量在NPU上执行时理想情况是数据从DDR加载到SRAM计算单元从SRAM取数算完再写回DDR。但现实是SRAM容量有限大张量必须分块Tiling处理。分块策略直接决定了你的算子性能。我实测过一个典型的卷积层输入特征图是[1, 64, 56, 56]权重是[128, 64, 3, 3]。如果不做分块整个特征图需要约800KB的SRAM很多端侧NPU根本放不下。分成4块之后每块只需要200KB左右但代价是边界数据需要重复加载。这个权衡就是端侧部署的核心艺术——用计算换内存或者用内存换计算没有免费午餐。提示在做NPU算子开发时一定要先查清楚目标硬件的SRAM容量和DMA带宽。这两个参数决定了你的分块策略上限也决定了你能跑多大的模型。1.3 张量形状对NPU执行效率的隐性影响很多人以为张量形状只影响计算量其实它还深刻影响NPU的流水线效率。NPU的计算单元通常是脉动阵列Systolic Array或者类似的矩阵乘加结构这种结构对张量的维度有对齐要求。比如某个NPU的矩阵乘法单元是16x16的那么你的张量维度最好是16的倍数。如果通道数是17硬件会把它padding到32多出来的计算全是浪费。我见过一个模型因为把通道数从64改成了65端侧推理速度直接掉了30%。这不是理论推导是实测数据。所以在端侧模型设计阶段就要有意识地把通道数、特征图尺寸对齐到硬件的友好数值。常见的友好数值是8、16、32、64。如果你用的是现成的模型那在转换阶段也要检查是否有维度不对齐导致的padding浪费。2. NPU执行张量运算的底层流水线2.1 指令下发与数据搬运的并行机制NPU和CPU最大的区别在于CPU是通用计算一条指令做一件事NPU是专用计算一条指令可能触发一整套数据搬运和计算流程。理解这一点是理解NPU执行逻辑的关键。典型的NPU执行一条卷积指令背后会发生这些事DMA引擎从DDR读取输入张量和权重到SRAM计算单元从SRAM读取数据执行矩阵乘加累加器暂存中间结果激活函数单元对结果做非线性变换DMA引擎把输出写回DDR这些步骤在硬件上是流水线并行的。也就是说当计算单元在处理第N块数据时DMA引擎已经在搬运第N1块数据了。这种并行机制决定了NPU的性能上限但也带来了一个麻烦如果数据搬运和计算不匹配流水线就会停顿。我遇到过最典型的情况是权重数据太大DMA搬运时间超过了计算时间导致计算单元经常空转。解决办法是把权重量化到INT8甚至INT4减少搬运量。这也是为什么端侧部署几乎必然要做量化——不只是为了省内存更是为了让流水线跑满。2.2 算子融合如何减少张量的往返搬运在CPU上每个算子独立执行中间结果写回内存下一个算子再读出来。这在端侧是灾难性的因为每次往返DDR都意味着带宽消耗和功耗增加。NPU通常支持算子融合Operator Fusion把多个算子合并成一个执行单元。最常见的融合模式是ConvBNReLU这三个算子融合后中间结果不需要写回DDR直接在SRAM里传递。但融合不是无条件的。我踩过的一个坑是某些NPU对融合算子的输入输出张量形状有要求如果形状不匹配融合会失败退化成独立执行。更隐蔽的是有些框架在转换时会假装融合成功但实际运行时还是分开执行的。所以你在部署后一定要用性能分析工具确认融合是否真的生效不能只看转换日志。下面是一个典型的融合前后对比以某端侧NPU为例配置执行时间DDR访问次数功耗独立执行ConvBNReLU4.2ms6次基准融合执行ConvBNReLU2.8ms2次降低约35%这个数据是我在实际项目中测出来的不同硬件会有差异但趋势是一致的融合能显著减少内存往返从而提升性能和能效。2.3 多核NPU的任务划分与张量切分现在很多端侧NPU是多核架构比如4核NPU或者大小核NPU。多核意味着张量可以被切分到不同核心上并行计算但切分方式很有讲究。最简单的切分是按批次切分比如批次为4每个核心处理一个样本。但端侧推理通常批次为1这时候就要按通道或者空间维度切分。按通道切分的问题是每个核心都需要完整的输入特征图输入数据被重复读取。按空间切分的问题是边界区域需要halo区域增加了计算量。我实际用下来按通道切分在大多数端侧NPU上表现更好因为通道维度的数据局部性更好DMA搬运效率更高。但这也取决于具体硬件的DMA设计有些NPU的DMA对空间连续访问更友好那就适合按空间切分。注意多核切分不是越多越好。核心之间的同步开销、DMA通道竞争都会抵消并行收益。我一般会从2核开始试逐步增加找到性能拐点。3. 量化让张量在NPU上跑得更快的关键手段3.1 从FP32到INT8量化到底损失了什么量化是端侧部署绕不开的话题。FP32的权重和激活值占4字节INT8只占1字节内存占用直接降到四分之一DMA搬运时间也大幅缩短。但量化不是免费的它引入了精度损失。量化的本质是把浮点数映射到整数区间。以INT8为例把[-127, 127]映射到浮点范围[min, max]。这个映射需要一个缩放因子Scale和一个零点Zero Point。缩放因子决定了量化精度零点决定了量化区间的偏移。问题在于神经网络中不同层的激活值分布差异很大。有些层输出范围是[-1, 1]有些是[-100, 100]。如果统一用一套量化参数小范围的层精度损失会很大。所以实际部署中通常采用逐层量化Per-Layer Quantization甚至逐通道量化Per-Channel Quantization。我做过一个对比实验同一个MobileNetV2模型在端侧NPU上量化策略Top-1精度推理延迟模型大小FP3271.8%12.5ms14MB逐层INT870.2%4.1ms3.6MB逐通道INT871.1%4.3ms3.6MB逐通道量化精度更高但推理稍慢因为每个通道需要独立的缩放因子增加了计算开销。实际选型时如果精度敏感就选逐通道如果速度敏感就选逐层。3.2 量化感知训练与训练后量化的选择逻辑量化有两种主要方式训练后量化PTQ和量化感知训练QAT。PTQ直接对训练好的FP32模型做量化简单快捷但精度损失可能较大。QAT在训练过程中模拟量化误差让模型适应量化精度更好但需要重新训练。我的经验是对于分类、检测这类对精度要求不是极端苛刻的任务PTQ通常够用。但对于分割、超分辨率这类像素级任务PTQ的精度损失可能无法接受这时候就需要QAT。QAT的实现也有讲究。不是所有层都适合量化第一层和最后一层通常保持FP32因为输入输出对精度更敏感。另外某些激活函数如Sigmoid、Tanh的量化误差较大可以考虑用ReLU替代或者做特殊处理。3.3 混合精度在NPU上平衡速度与精度混合精度是量化的进阶玩法。不是所有层都用INT8而是根据敏感度分析对精度敏感的层保持FP16其他层用INT8。这样可以在精度和速度之间找到更好的平衡点。实现混合精度的关键是敏感度分析。具体做法是逐层量化观察每一层量化后对最终精度的影响然后选择影响最大的几层保持高精度。这个过程可以用工具自动化但需要人工确认结果是否合理。我在一个端侧人脸识别项目里用了混合精度最终方案是主干网络用INT8最后的特征嵌入层用FP16。结果是模型大小只增加了8%但识别准确率提升了2.3个百分点推理延迟只增加了0.4ms。这个投入产出比是非常划算的。4. 端侧部署中张量相关的典型问题与排查思路4.1 张量形状不匹配导致的推理失败这是端侧部署最常见的问题没有之一。模型在训练框架里跑得好好的转成端侧格式就报错十有八九是张量形状问题。常见原因包括动态形状不支持很多NPU只支持静态形状如果你的模型有动态维度比如NLP模型中的序列长度转换时就会失败。解决办法是固定形状或者用多个静态形状的模型覆盖不同输入长度。布局不一致训练框架用NCHWNPU期望NHWC转换工具没有正确处理导致形状对不上。算子版本差异不同版本的转换工具对同一算子的形状推导规则可能不同升级工具后模型跑不了的情况我也遇到过。排查这类问题的思路是先确认输入张量的形状和布局再逐层检查中间张量的形状找到第一个不匹配的层。大多数转换工具都支持导出中间层的形状信息善用这个功能能省很多时间。4.2 内存溢出与张量分块策略调整端侧设备内存有限大模型或者高分辨率输入很容易导致内存溢出。表现可能是推理直接失败也可能是推理过程中被系统杀掉。解决内存问题的核心是张量分块。但分块策略需要根据具体硬件调整。我的一般流程是先确认NPU的SRAM容量和DDR可用内存计算最大张量的内存占用如果超过SRAM容量设计分块方案在分块基础上考虑是否可以把部分权重常驻SRAM有一个容易被忽略的点是内存对齐。很多NPU要求张量地址按特定字节对齐比如16字节或64字节如果不对齐要么报错要么性能下降。在手动分配内存时一定要检查对齐要求。4.3 性能不达预期的逐层分析方法模型跑起来了但速度不达预期这时候需要逐层分析。我常用的方法是逐层计时用NPU的性能分析工具导出每一层的执行时间找瓶颈层通常瓶颈集中在卷积层和全连接层但某些激活函数层也可能成为瓶颈分析瓶颈原因是计算量大还是内存访问多还是流水线停顿我遇到过一个案例某个深度可分离卷积层耗时异常。排查后发现是因为通道数太少只有8NPU的向量化单元利用率极低。解决办法是把相邻的深度可分离卷积合并或者调整通道数到16的倍数。另一个常见问题是首层和末层的开销。首层通常要做布局变换和量化末层要做反量化和后处理这两层的开销在整体延迟中占比可能很高。优化方法是把部分预处理和后处理移到CPU上或者用NPU的专用指令加速。5. 从CPU到NPU端侧AI硬件部署的选型逻辑5.1 CPU、GPU、NPU在端侧的分工与边界端侧AI硬件部署不是非此即彼的选择而是要根据任务特点做分工。我的经验是CPU适合小模型、低频率任务、控制逻辑、后处理。优势是灵活劣势是能效低。GPU适合中等规模模型、图形相关任务、需要浮点精度的场景。优势是通用性强劣势是功耗高。NPU适合大规模卷积、矩阵运算、量化模型。优势是能效高劣势是灵活性差。实际产品中通常是CPUNPU或者CPUGPUNPU的组合。比如手机上的拍照场景预处理用CPU主体检测用NPU后处理用GPU。这种异构计算的关键是任务划分和数据同步划分不好反而会拖慢整体速度。5.2 模型转换工具链的坑与应对从训练框架到端侧NPU中间要经过模型转换。这个环节的坑非常多我列几个最常见的算子不支持训练框架里的某些算子NPU没有对应实现。解决办法是用NPU支持的算子重新表达或者把该层放到CPU上执行。转换工具版本不匹配训练框架版本、转换工具版本、NPU驱动版本三者之间可能有兼容性问题。我的建议是锁定版本不要轻易升级。量化校准数据问题PTQ需要校准数据如果校准数据分布和实际数据差异大量化精度会很差。校准数据一定要有代表性。提示模型转换后一定要用测试集验证精度。我见过太多转换后精度掉点但没被发现的情况上线后问题才暴露出来。5.3 端侧大模型部署的现实挑战现在端侧大模型很热但实际部署挑战很大。大模型的参数量动辄几十亿即使量化到INT4也要几GB内存很多端侧设备根本放不下。目前的现实方案是模型裁剪去掉冗余层或者用蒸馏得到小模型参数共享不同层共享权重减少参数量条件计算根据输入动态选择激活的层减少计算量内存映射把权重放在闪存里按需加载但延迟会增加我实测过一个70亿参数的模型INT4量化后约3.5GB在高端手机上可以跑但延迟在秒级离实时还有距离。所以端侧大模型目前更适合对延迟不敏感的场景比如离线翻译、文档摘要。6. 实操建议与个人经验总结6.1 端侧NPU算子开发的入门路径如果你想做NPU算子开发我的建议是从这几个方向入手先跑通官方Demo每个NPU厂商都会提供算子开发示例先把这些示例跑通理解工具链的基本流程。从简单算子开始不要一上来就写卷积先从Element-wise算子如Add、Mul开始理解数据搬运和计算的基本模式。学会看性能分析报告NPU厂商通常提供性能分析工具能告诉你每个算子的执行时间、内存访问量、流水线利用率。这是优化的基础。理解硬件架构不需要懂电路设计但要理解计算单元的组织方式、内存层级、DMA通道数量这些关键参数。6.2 性能调优的优先级排序端侧性能调优我的优先级排序是量化收益最大风险也最大需要仔细验证精度算子融合收益中等实现难度中等内存布局优化收益中等但需要深入理解硬件多核并行收益取决于任务实现难度较高指令级优化收益较小但需要深厚的硬件知识这个排序不是绝对的具体项目要根据瓶颈所在调整。但一般来说先做量化再做融合最后考虑并行和指令优化是投入产出比最高的路径。6.3 常见问题的快速排查清单最后分享一个我常用的排查清单遇到端侧部署问题可以按这个顺序检查模型转换是否成功有没有警告信息输入张量的形状和布局是否正确量化校准数据是否有代表性内存是否足够有没有溢出算子融合是否生效多核切分是否合理首层和末层的开销是否过大是否有算子回退到CPU执行这个清单能覆盖80%以上的常见问题。剩下的20%通常需要具体分析但有了这个基础排查方向不会跑偏。我在实际项目中最大的体会是端侧AI部署没有银弹每个硬件平台都有自己的脾气。同样的模型在A平台上跑得好在B平台上可能完全不行。所以不要迷信任何通用方案一定要针对目标硬件做实测和调优。另外精度和速度的权衡贯穿始终没有既快又准的完美方案只有适合当前场景的最优解。