端侧AI这个词这两年出现的频率越来越高，但很多人对它的理解还停留在"把模型塞进手机里跑"这个层面。真正做过端侧部署的人会告诉你，事情远没有这么简单。一个模型从训练框架里导出，到最终在设备上以可接受的延迟和功耗跑起来，中间要经过图优化、算子融合、量化、内存布局调整、硬件指令映射等一长串环节。而这条链路的最底层，就是张量如何在NPU上被真正执行的问题。
我自己是从移动端推理优化开始接触这个领域的，先后在几个不同架构的NPU上做过模型移植和性能调优。踩过的坑包括但不限于：量化后精度崩了、算子不支持导致大量回退到CPU、内存带宽成为瓶颈导致算力利用率不到30%、不同厂商的NPU对同一张图的理解完全不同。这些问题追到根上，都指向同一个东西——你得理解张量在NPU上的执行逻辑，而不是把它当成一个黑盒。
这篇文章适合谁看？如果你正在做端侧AI的模型部署，或者准备从纯算法转向推理优化，又或者你只是好奇"NPU到底是怎么算一个卷积的"，那接下来的内容应该能给你一些实在的参考。我会从张量的内存表示讲起，一路拆到NPU的指令调度和常见性能陷阱，尽量把这条链路讲透。
1. 张量在端侧的真实形态：不只是多维数组
1.1 从框架张量到硬件张量的三次转换
在PyTorch里，一个张量就是一个多维数组加上一些元信息。但到了端侧，这个"数组"要经历至少三次形态转换，每一次都可能引入性能损耗。
第一次转换发生在模型导出阶段。以ONNX为例，PyTorch的NCHW布局会被保留，但某些算子会被拆解或重组。比如一个普通的卷积，在ONNX图里可能变成Conv加BN加ReLU三个节点，也可能被融合成一个节点，取决于导出时的配置。这一步的关键是：你看到的图结构，和硬件实际执行的图结构，往往不是一回事。
第二次转换发生在推理引擎的图优化阶段。以TensorRT、NCNN、MNN这类引擎为例，它们会做算子融合、常量折叠、死代码消除等优化。这时候张量的形状可能会被改写，比如把NCHW转成NHWC，因为很多NPU的卷积加速器对NHWC更友好。这个转换不是免费的，它涉及一次完整的内存重排。
第三次转换发生在硬件层面。NPU通常有自己的张量描述格式，比如某些架构要求张量按特定的tile大小对齐，或者要求通道数补齐到某个倍数。如果你的张量形状不满足这些约束，运行时就会插入额外的padding或slice操作。
注意：很多性能问题不是出在算力不够，而是出在这三次转换中的某一次引入了额外的内存搬运。搬运一次张量的能耗，可能比算一次卷积还高。
1.2 内存布局为什么比算力更影响性能
我做过一个实测：同一个MobileNetV2模型，在同一个NPU上，只改变张量的内存布局，推理延迟差了将近一倍。这不是个例，而是端侧推理的常态。
原因在于NPU的算力单元通常很快，但内存带宽是有限的。如果张量的布局导致算力单元需要频繁地从DRAM里取数据，那算力单元大部分时间都在等数据，利用率自然上不去。这就是所谓的"内存墙"问题。
具体来说，NCHW布局下，卷积核在通道维度上是连续的，这对某些NPU的向量化指令很友好。但NHWC布局下，空间维度连续，对另一些NPU的DMA搬运更高效。选哪种布局，取决于你的NPU架构。没有一个放之四海而皆准的答案。
更麻烦的是，一个模型里不同算子可能偏好不同的布局。卷积喜欢NHWC，全连接喜欢NCHW，矩阵乘又可能有自己的要求。推理引擎会在图优化阶段插入transpose节点来满足不同算子的需求，但每一次transpose都是一次完整的内存读写。如果transpose太多，性能就被吃掉了。
我的经验是：在模型设计阶段就尽量保持布局一致性，避免频繁的维度变换。如果必须变换，尽量让变换发生在通道数较小的张量上，因为搬运成本和张量大小成正比。
1.3 量化对张量表示的颠覆性改变
量化是端侧部署绕不开的话题。从FP32到INT8，张量的数值表示变了，但更重要的是，张量的内存组织和计算方式也变了。
INT8量化后，一个张量的每个元素只占1个字节，理论上内存占用降到FP32的四分之一。但实际收益往往没有这么大，因为量化会引入scale和zero_point这两个参数，它们需要额外的存储和计算。而且，很多NPU的INT8计算要求张量按通道或按组进行量化，这意味着scale和zero_point的数量可能和通道数一样多。
更关键的是，量化改变了算子的执行方式。以卷积为例，FP32卷积是乘加运算，INT8卷积是整数乘加再乘scale。某些NPU有专门的INT8乘加指令，能在一个周期内完成更多运算。但如果你的量化方案和NPU的指令不匹配，比如用了per-channel量化但NPU只支持per-tensor，那运行时就得插入额外的反量化操作，性能反而下降。
我踩过的一个坑是：在一个NPU上做per-channel量化，精度很好，但推理速度比per-tensor量化慢了40%。后来查下来，是因为这个NPU的INT8卷积指令只支持per-tensor的scale，per-channel的scale需要在软件层面处理，引入了大量额外计算。所以量化方案的选择，不能只看精度，还要看硬件支持。
2. NPU的算力从哪来：架构差异决定执行逻辑
2.1 三种主流NPU架构的算力组织方式
市面上的NPU架构差异很大，但大致可以归为三类： systolic array（脉动阵列）、SIMD向量机、以及混合架构。
脉动阵列的代表是Google的TPU系列，它的核心思想是让数据在计算单元之间流动，每个计算单元只做简单的乘加，但数据复用率极高。这种架构对矩阵乘和卷积非常友好，因为这两类算子的数据复用模式很规整。但它的缺点是灵活性差，遇到非规则算子（比如某些注意力机制里的gather操作）就无能为力。
SIMD向量机的代表是高通的Hexagon DSP和很多移动端NPU。它的核心是一组向量寄存器和一个向量ALU，能同时对多个数据做相同的操作。这种架构的灵活性比脉动阵列好，能处理更多类型的算子，但数据复用率不如脉动阵列，对内存带宽更敏感。
混合架构则是把两者结合起来，比如用脉动阵列处理卷积和矩阵乘，用向量机处理element-wise操作和激活函数。这种架构的编程模型更复杂，但能覆盖更多场景。
理解你的NPU属于哪一类，直接决定了你应该怎么优化模型。脉动阵列上，你要尽量把算子转成矩阵乘；SIMD上，你要尽量让数据在向量寄存器里复用；混合架构上，你要注意算子在不同计算单元之间的调度开销。
2.2 数据流：NPU执行一个卷积的完整链路
让我用一个具体的例子来说明NPU执行一个卷积时发生了什么。假设有一个3x3的卷积，输入是1x3x224x224，输出是1x64x224x224，INT8量化。
第一步，DMA把输入张量从DRAM搬到NPU的片上内存。这一步的耗时取决于张量大小和内存带宽。224x224x3大约是150KB，如果内存带宽是10GB/s，搬运时间大约是15微秒。
第二步，权重张量从DRAM搬到权重缓存。3x3x3x64大约是1.7KB，搬运时间可以忽略。但如果是大模型，权重搬运可能是主要开销。
第三步，计算单元开始执行乘加。脉动阵列会按行和列加载输入和权重，每个周期完成一批乘加。3x3x3x64x224x224大约是2.7亿次乘加，如果NPU有1024个乘加单元，每个周期完成1024次，那需要大约26万个周期。按1GHz主频算，大约是260微秒。
第四步，结果写回DRAM。输出是1x64x224x224，大约是3.2MB，写回时间大约是320微秒。
注意，写回时间比计算时间还长。这就是为什么我说内存带宽往往是瓶颈。在这个例子里，计算只占了不到一半的时间，剩下的都是数据搬运。
提示：优化端侧推理时，先看内存搬运时间，再看计算时间。如果搬运时间占比超过50%，那优化计算单元是没用的，得先优化数据流。
2.3 算子融合如何减少数据搬运
算子融合是端侧推理优化最有效的手段之一，它的核心目的就是减少数据搬运。
以Conv+BN+ReLU为例，如果不融合，执行流程是：卷积输出写到DRAM，BN从DRAM读卷积输出，计算后写到DRAM，ReLU再从DRAM读BN输出，计算后写到DRAM。三次读写，每次都是完整的张量大小。
如果融合成一个算子，卷积的输出直接留在片上内存，BN和ReLU在片上完成，最后只写一次DRAM。数据搬运量降到原来的三分之一。
但算子融合不是没有代价的。融合后的算子需要更多的片上内存来保存中间结果，如果片上内存不够，融合就会失败，或者需要分块处理。分块处理又会引入额外的边界处理开销。
我在一个NPU上做过测试：把ResNet50的所有Conv+BN+ReLU都融合，推理延迟降低了35%。但把融合后的模型放到另一个片上内存较小的NPU上，延迟反而增加了10%，因为分块处理的开销超过了融合的收益。所以融合策略要针对具体硬件来定。
3. 从张量到指令：NPU的调度逻辑
3.1 图编译：NPU如何理解你的模型
当你把一个模型交给NPU运行时，第一件事是图编译。这个过程把框架层面的计算图转换成NPU能执行的指令序列。
图编译的第一步是算子映射。NPU通常只支持有限的一组算子，比如卷积、全连接、池化、激活等。如果你的模型里有NPU不支持的算子，比如某些自定义的注意力机制，编译器会把它标记为"不支持"，然后回退到CPU执行。回退到CPU的算子会成为整个推理链路的瓶颈，因为CPU和NPU之间的数据同步开销很大。
第二步是内存分配。编译器会为每个张量分配片上内存或DRAM地址。片上内存有限，通常只有几百KB到几MB，所以编译器需要决定哪些张量放在片上，哪些放在DRAM。这个决策直接影响性能。
第三步是指令生成。编译器把每个算子转换成NPU的指令序列，包括DMA指令、计算指令、同步指令等。指令的调度顺序会影响数据依赖和流水线效率。
我遇到过一个典型问题：模型里有一个reshape操作，在框架层面是零成本的（只是改变元信息），但在NPU上，reshape可能触发一次完整的内存重排。如果这个reshape恰好发生在两个大张量之间，性能就会明显下降。解决办法是调整模型结构，让reshape发生在通道数较小的张量上，或者用view操作替代reshape。
3.2 算子不支持的代价：回退与重写
算子不支持是端侧部署最常见的坑之一。不同NPU的支持列表差异很大，同一个算子在这个NPU上支持，在另一个上可能就不支持。
回退到CPU的代价有多大？我做过一个实测：一个模型有20个算子，其中19个在NPU上执行，1个回退到CPU。NPU部分的执行时间是10毫秒，CPU部分的执行时间是2毫秒，但总推理时间是18毫秒。多出来的6毫秒是数据在NPU和CPU之间同步的开销。
所以，一个算子回退，可能让整个推理链路的性能下降30%以上。解决办法有两个：一是重写算子，用NPU支持的算子组合来等价实现；二是调整模型结构，避免使用不支持的算子。
重写算子的例子：某些NPU不支持GELU激活函数，但支持tanh和乘法。GELU可以近似为x * sigmoid(1.702 * x)，而sigmoid可以用tanh表示。这样就能用NPU支持的算子组合出GELU的近似实现。精度损失通常在可接受范围内。
调整模型结构的例子：某些NPU不支持动态shape的算子，但你的模型里有动态reshape。可以把动态reshape改成固定shape的reshape，或者在模型设计阶段就避免动态shape。
3.3 多核NPU的任务划分策略
高端NPU通常有多个计算核心，比如4核或8核。如何把模型划分到多个核心上，是一个直接影响性能的问题。
最简单的策略是按层划分：前几层在一个核心上，后几层在另一个核心上。但这种策略的问题是，核心之间的数据同步开销很大，而且负载可能不均衡。
更好的策略是按通道或按空间划分：把同一个算子的不同通道或不同空间区域分配到不同核心上。这样每个核心处理的数据量更均衡，同步开销也更小。但这对算子的实现有要求，不是所有NPU都支持。
还有一种策略是流水线划分：把模型分成多个阶段，每个阶段在一个核心上执行，阶段之间用流水线方式重叠。这种策略能提高核心利用率，但需要编译器有较强的调度能力。
我在一个4核NPU上做过测试：按层划分的推理延迟是15毫秒，按通道划分是11毫秒，流水线划分是9毫秒。但流水线划分的编程复杂度最高，而且对模型结构有要求。所以选择哪种策略，要看你的模型和硬件特性。
4. 端侧部署的实战陷阱与调优经验
4.1 量化精度崩塌的排查链路
量化精度崩塌是端侧部署最常见的问题。模型在FP32下精度正常，量化后精度大幅下降。排查这个问题需要一套系统的方法。
第一步，定位是哪一层导致的精度下降。方法是逐层量化，观察每一层输出的误差。如果某一层的误差突然变大，那问题就出在这一层。
第二步，分析这一层为什么对量化敏感。常见原因有：这一层的权重分布不均匀，存在极端值；这一层的输入动态范围很大；这一层使用了对量化敏感的算子，比如softmax或layer norm。
第三步，针对性处理。如果是权重分布问题，可以用KL散度或最小化量化误差的方法来选择scale；如果是输入动态范围问题，可以用per-channel量化；如果是对量化敏感的算子，可以保留FP16精度，或者用查表法替代。
我遇到过一个案例：一个模型的最后一层全连接对量化特别敏感，量化后精度掉了5个百分点。后来发现是因为这一层的权重有一个很大的偏置项，导致量化后的zero_point偏移。解决办法是把偏置项单独用FP16处理，精度就恢复了。
4.2 内存带宽瓶颈的识别与缓解
内存带宽瓶颈的典型表现是：NPU的算力利用率很低，但推理延迟很高。用性能分析工具看，会发现DMA的占用率很高，而计算单元的占用率很低。
识别内存带宽瓶颈的方法是：计算模型的算术强度（arithmetic intensity），即每字节内存访问对应的计算量。如果算术强度低于NPU的算力带宽比，那就是内存瓶颈。
缓解内存带宽瓶颈的方法有几种。一是算子融合，减少中间张量的读写。二是分块处理，把大张量切成小块，让小块能放在片上内存里，减少DRAM访问。三是改变数据布局，让连续访问更高效。四是降低精度，比如从FP16降到INT8，直接减少一半的内存流量。
我在一个模型上做过对比：不做任何优化时，算力利用率是25%；算子融合后提升到40%；再加上分块处理，提升到60%；最后用INT8量化，提升到75%。每一步的收益都很明显，但每一步都需要针对具体硬件来调。
4.3 不同NPU平台的移植经验对比
我在几个不同平台上做过模型移植，每个平台都有自己的特点。
平台A的NPU对卷积支持很好，但对全连接支持一般。移植时要把全连接尽量转成卷积，比如用1x1卷积替代全连接。这个转换在数学上是等价的，但需要调整权重布局。
平台B的NPU对INT8支持很好，但对FP16支持一般。移植时要尽量用量化感知训练，让模型在量化后精度损失最小。这个平台上的调优重点是量化方案的选择。
平台C的NPU对动态shape支持很好，但对静态shape的优化不够。移植时要尽量保持动态shape，让编译器有更多优化空间。但这个平台的编程模型比较复杂，需要更多的手动调优。
跨平台移植的通用经验是：不要假设一个平台上的优化策略在另一个平台上有效。每个平台都要重新做性能分析，重新找瓶颈，重新调优。移植的成本往往比预期的高。
4.4 端侧AI硬件的选型考量
选端侧AI硬件时，不能只看算力参数。算力只是理论峰值，实际能用到多少，取决于内存带宽、算子支持、编译器质量等多个因素。
我的选型框架是：先看算子支持列表，确保模型的主要算子都被支持；再看内存带宽和片上内存大小，评估是否能避免内存瓶颈；然后看编译器的优化能力，比如是否支持算子融合、是否支持自动分块；最后看工具链的成熟度，比如是否有性能分析工具、是否有量化工具。
算力参数可以作为参考，但不能作为唯一依据。我见过算力很高但实际性能很差的NPU，也见过算力一般但实际性能很好的NPU。差距就在软件栈上。
还有一个容易被忽略的因素是功耗。端侧设备的功耗预算通常很紧，NPU的峰值功耗可能很高，但持续功耗才是关键。有些NPU在短时间爆发时性能很好，但持续运行时会因为散热问题降频。选型时要看持续性能，而不是峰值性能。
5. 端侧AI执行逻辑的演进方向
5.1 从固定算子到可编程数据流
当前的NPU大多采用固定算子架构，编译器把模型映射到一组预定义的算子上。这种架构的优点是效率高，缺点是灵活性差，遇到不支持的算子就得回退。
未来的趋势是可编程数据流架构，NPU不再有固定的算子概念，而是由编译器生成数据流图，硬件按数据流执行。这种架构能支持任意算子，但编译器的复杂度会大幅增加。
已经有公司在做这方面的探索，比如用CGRA（粗粒度可重构阵列）来实现可编程数据流。这种架构在灵活性和效率之间找到了一个平衡点，但编程模型和工具链还需要完善。
5.2 动态shape与自适应推理
端侧AI的一个趋势是动态shape和自适应推理。比如在视频处理中，每一帧的感兴趣区域可能不同，需要动态调整计算量。又比如在语音处理中，不同长度的音频需要不同的计算图。
当前的NPU对动态shape的支持普遍不好，很多编译器要求静态shape。未来的NPU需要更好地支持动态shape，包括动态内存分配、动态指令调度等。
自适应推理是另一个方向，模型根据输入难度动态调整计算量。比如简单样本走浅层网络，复杂样本走深层网络。这需要NPU支持条件执行和动态控制流。
5.3 端侧训练与推理的融合
当前端侧AI主要是推理，训练还是在云端。但有些场景需要在端侧做微调，比如个性化推荐、隐私保护等。这要求NPU不仅支持推理，还支持训练。
端侧训练的挑战更大，因为训练需要反向传播、梯度更新等操作，计算量和内存需求都更高。当前的NPU大多不支持训练，或者只支持很有限的训练。未来的NPU需要更好地支持训练，包括混合精度训练、梯度压缩等。
我在实际项目中的体会是：端侧AI的底层执行逻辑，本质上是一个软硬件协同设计的问题。你不能只关注算法，也不能只关注硬件，必须两边都懂，才能做出真正高效的方案。这个领域还在快速演进，新的架构、新的编译器、新的优化技术不断出现，保持学习是必须的。
