1. 端侧 AI 到底在“跑”什么从张量说起很多人第一次接触端侧 AI脑子里冒出来的问题是“模型怎么塞进手机里”“NPU 到底比 CPU 快在哪”。但真要往下挖绕不开一个最底层的东西——张量。你可以把它理解成 AI 世界的“通用货币”不管你是做图像分类、语音唤醒还是跑一个几亿参数的大模型数据在芯片内部流转时几乎都是以张量的形式存在。我刚开始做端侧部署的时候总觉得“张量”是个玄乎的数学概念后来拆开看才发现它本质上就是一个多维数组。标量是 0 维张量向量是 1 维矩阵是 2 维再往上就是 3 维、4 维甚至更高。比如一张 RGB 图片在模型里通常表示成[1, 3, 224, 224]这样的四维张量分别对应批大小、通道数、高度和宽度。卷积层的权重也是一个四维张量形状大概是[输出通道, 输入通道, 卷积核高, 卷积核宽]。为什么端侧 AI 要反复强调张量因为芯片的算力调度、内存搬运、算子融合全都是围绕张量的形状和布局来做的。同样一个卷积张量是 NCHW 布局还是 NHWC 布局在 NPU 上的执行效率可能差出一大截。这不是理论问题是我在实际项目里踩过的坑有一次模型在 CPU 上跑得好好的转到 NPU 后精度直接崩了查了半天才发现是某个算子对张量的内存对齐有要求布局没转过来。所以这一章我们先不急着聊 NPU先把张量这件事讲透。你只有理解了张量在端侧是怎么被“搬运”和“计算”的后面看 NPU 的架构才不会觉得是在看天书。1.1 张量的形状、布局与内存排布张量的形状shape决定了它有多少个维度、每个维度多长而布局layout决定了这些元素在内存里是怎么排列的。这两件事听起来简单但在端侧部署里经常是“事故现场”。举个最常见的例子。PyTorch 默认的卷积输入布局是 NCHW也就是先存所有通道的同一行像素再存下一行。而很多移动端 NPU 和 GPU 更偏好 NHWC也就是每个像素的多个通道连续存放。为什么因为 NHWC 在做逐通道卷积或者点卷积时内存访问更连续缓存命中率更高。你要是直接把 NCHW 的张量丢给只认 NHWC 的 NPU轻则性能打折重则直接报错。我在实际转换模型时通常会做这么几步检查确认原始框架的默认布局PyTorch 是 NCHWTensorFlow 通常是 NHWC查看目标 NPU 的文档确认它支持的布局和是否需要显式转换在模型转换工具里加上布局转换节点或者直接在导出 ONNX 时指定input_names和动态轴用一个小输入跑一遍对比 CPU 和 NPU 的输出差异误差超过 1e-3 就要警惕。内存排布还有一个容易被忽略的点对齐。很多 NPU 要求张量的起始地址按 16 字节甚至 64 字节对齐通道数也最好是对齐到 4 或 8 的倍数。如果你自己写算子或者做内存复用不对齐会导致性能骤降甚至触发硬件异常。我一般会在分配张量内存时统一用aligned_alloc把对齐值设成 64虽然会浪费一点空间但省心。1.2 张量在端侧流转的完整链路一个张量从输入到输出在端侧设备上大概会经历这么几个阶段预处理阶段图像从摄像头出来是 YUV 或 RGB 的连续内存需要转成模型需要的张量形状和数据类型。这一步通常在 CPU 上做因为 NPU 不擅长处理这种非规则的数据搬运。量化与反量化如果模型是量化模型浮点张量会被转换成 int8 或 uint8。量化公式一般是q round(x / scale) zero_point反量化就是逆运算。这里 scale 和 zero_point 的选择直接影响精度后面会细说。算子计算阶段张量进入 NPU 的运算单元经过卷积、矩阵乘、激活等操作。这个阶段张量可能一直在 NPU 的片上内存里流转不回到主存这就是所谓的“算子融合”。后处理阶段输出张量回到 CPU做 NMS、解码、阈值过滤等操作。这条链路里张量在不同内存空间之间的搬运往往是瓶颈。我实测过一个 1x3x224x224 的输入在某个中端 NPU 上纯计算只花了 3ms但前后处理和数据搬运花了 12ms。所以后来我做优化时第一件事就是看张量在哪儿搬来搬去能融合的融合能常驻片上的就常驻。提示如果你在用 ComfyUI 这类工具调用 Intel NPU 做推理注意它底层也是把张量转成 OpenVINO 的 blob 再交给 NPU。张量的布局和精度在转换时就已经定死了后期很难改所以导出模型时就要想清楚。2. NPU 凭什么比 CPU 快架构与执行逻辑拆解聊完张量我们终于可以进入正题NPU。很多人把 NPU 当成“更快的 CPU”这是个误解。CPU 是通用处理器擅长逻辑控制和标量运算NPU 是专用处理器它的设计目标只有一个——高效地做张量运算。你可以把 CPU 想象成一个什么都会做的老教授NPU 则是一个只练举重的运动员比写代码肯定不行但比举重老教授连上场的机会都没有。NPU 快在哪核心就三点脉动阵列、片上缓存、算子固化。下面我一个个拆。2.1 脉动阵列矩阵乘法的硬件加速器矩阵乘法是深度学习里最常见的运算卷积也可以展开成矩阵乘im2col GEMM。NPU 里做矩阵乘的核心结构叫脉动阵列Systolic Array。这个名字听起来很玄其实原理不复杂一堆乘加单元MAC排成二维网格数据像心跳一样从左边和上边“脉动”进来每个周期完成一次乘加结果从下边和右边流出。假设有一个 4x4 的脉动阵列做两个 4x4 矩阵相乘理论上 4 个周期就能算完第一轮而 CPU 用循环一个个算可能要几十个周期。这就是为什么 NPU 的 TOPS每秒万亿次操作能轻松做到几十甚至上百而 CPU 通常只有几 TOPS。但脉动阵列有个特点它只擅长规则的大矩阵运算。如果你的张量形状很奇怪比如通道数是 3 或者 7阵列的利用率就会很低。我见过一个模型因为第一层卷积输入通道是 3NPU 利用率只有 30% 不到。后来把输入通道 padding 到 4利用率直接上去了。所以做端侧部署时尽量让张量的维度对齐到 4 或 8 的倍数这不是玄学是硬件特性决定的。2.2 片上缓存为什么 NPU 不爱访问主存NPU 的第二个杀手锏是片上缓存on-chip memory。CPU 也有缓存但 NPU 的缓存通常更大、带宽更高而且设计上就是为了让张量在计算过程中尽量不回到主存。为什么这件事重要因为访问主存的功耗和延迟远高于片上访问。有数据表明一次主存访问的能耗可能是一次片上访问的 100 倍以上。端侧设备电池就那么大能省一点是一点。所以 NPU 的典型工作流是把输入张量和权重从主存搬到片上然后在片上完成所有计算最后把输出搬回主存。中间过程不打扰主存。这也解释了为什么算子融合在 NPU 上特别重要。比如 Conv BN ReLU如果分开做中间结果要写回主存再读出来融合成一个算子中间张量一直在片上省了两次主存访问。我在做模型优化时会优先看哪些算子可以融合通常能带来 20% 到 40% 的性能提升。2.3 算子固化NPU 的“舒适区”与“禁区”NPU 的算子是固化在硬件里的也就是说它只支持特定的一些操作。常见的比如卷积、深度卷积、全连接、池化、ReLU、Sigmoid 等这些在 NPU 上跑得飞快。但如果你模型里有个自定义的算子比如某种特殊的注意力机制或者动态形状的操作NPU 可能根本不支持只能回退到 CPU 执行。回退到 CPU 的代价很大。我实测过一个模型里面有一个不支持的Gather算子导致整个网络被切成两段中间张量要来回搬运整体性能直接掉了 60%。所以做端侧部署时第一件事就是查目标 NPU 支持哪些算子然后尽量用支持的算子重写模型。如果实在避不开就考虑用 CPU 做那部分但要做好性能预算。下面这张表是我整理的一些常见算子在 NPU 和 CPU 上的支持情况不同厂商会有差异但大方向差不多算子类型NPU 支持情况备注标准卷积原生支持性能极高建议通道对齐到 4/8深度可分离卷积原生支持移动端模型常用全连接原生支持大模型里就是矩阵乘ReLU / Sigmoid原生支持通常融合进前一个算子自定义激活多数不支持需回退 CPU动态形状操作多数不支持端侧尽量用静态形状非极大值抑制部分支持后处理阶段常用注意如果你在用 AMD NPU 跑大模型注意它的算子库和移动端 NPU 不太一样对 Transformer 结构的支持更好但对一些传统 CNN 算子可能反而没那么优化。选型时要看你的模型结构。3. 端侧 AI 硬件部署的完整实操流程理论讲了不少这一章我们直接上实操。我以一个典型的端侧部署项目为例从模型导出到 NPU 上跑通把每一步都拆开讲。你跟着做基本能复现一个可用的端侧推理流程。3.1 模型导出与格式转换第一步是把训练好的模型导出成中间格式。现在最通用的是ONNX它相当于模型界的“普通话”各大框架都能说。导出时要注意几个点固定输入形状端侧 NPU 通常不支持动态形状导出时把 batch、height、width 都固定死。比如torch.onnx.export(model, dummy_input, model.onnx, input_names[input], output_names[output], dynamic_axesNone)。算子版本ONNX 的 opset 版本不要太高很多 NPU 工具链只支持到 opset 11 或 13。我一般用 11兼容性最好。去掉训练专用节点比如 Dropout、BatchNorm 的训练模式分支导出前要model.eval()。导出后用onnxsim做一次简化把多余的 Identity、Constant 节点去掉。这一步能减小模型体积也能避免一些工具链的解析问题。python -m onnxsim model.onnx model_sim.onnx接下来是转换成 NPU 能吃的格式。不同厂商工具不同Intel 用 OpenVINOAMD 用 Ryzen AI 工具链移动端高通用 SNPE联发科用 NeuroPilot。以 OpenVINO 为例mo --input_model model_sim.onnx --output_dir ir_model --data_type FP16这里--data_type FP16表示转成半精度。如果你的 NPU 支持 int8还可以做量化后面细说。3.2 量化精度与速度的平衡术量化是端侧部署绕不开的一步。简单说就是把 FP32 的权重和激活值用 int8 表示模型体积缩小 4 倍推理速度提升 2 到 4 倍。但量化会带来精度损失怎么平衡是个技术活。我常用的量化流程是训练后量化PTQ不需要重新训练只需要一小批校准数据。以 OpenVINO 的 POT 工具为例from openvino.tools.pot import DataLoader, IEEngine, load_model, save_model, compress_model_weights from openvino.tools.pot.graph import load_model # 准备校准数据 class CalibDataLoader(DataLoader): def __init__(self, data): self.data data def __len__(self): return len(self.data) def __getitem__(self, index): return self.data[index], None # 加载模型并量化 model load_model(ir_model/model.xml) engine IEEngine(config{device: CPU}, data_loaderCalibDataLoader(calib_data)) compressed_model compress_model_weights(model) save_model(compressed_model, int8_model)校准数据一般取 100 到 500 张有代表性的图片或文本覆盖各种场景。我踩过的坑是校准数据如果太单一量化后的模型在边缘场景下精度会崩。比如做人脸识别校准集里全是正脸侧脸就废了。所以校准集要尽量贴近真实分布。量化还有一个细节逐通道量化 vs 逐张量量化。逐通道量化对每个输出通道单独算 scale精度更好但硬件实现更复杂。很多 NPU 只支持逐张量量化这时候就要在精度和兼容性之间做取舍。我的经验是如果 NPU 支持逐通道优先用如果不支持就在量化感知训练里补偿。3.3 在 NPU 上跑通第一个推理模型转换和量化做完就可以在 NPU 上跑推理了。以 OpenVINO 调用 Intel NPU 为例import openvino as ov import numpy as np core ov.Core() model core.read_model(int8_model/model.xml) compiled_model core.compile_model(model, NPU) input_layer compiled_model.input(0) output_layer compiled_model.output(0) # 准备输入张量 input_data np.random.randn(1, 3, 224, 224).astype(np.float32) result compiled_model([input_data])[output_layer] print(result.shape)如果一切顺利你会看到输出张量的形状和数值。但实际项目中第一次跑通往往不会这么顺。常见的问题包括输入张量的布局不对、量化后的 scale 没对齐、NPU 驱动版本不匹配等。我一般会先用 CPU 跑一遍同样的模型对比输出差异如果误差在可接受范围内再切到 NPU。跑通之后用benchmark_app测一下性能benchmark_app -m int8_model/model.xml -d NPU -api sync -niter 100这个命令会输出平均推理时间、吞吐量等指标。我通常会对比 CPU、GPU、NPU 三个设备的性能看看 NPU 到底快了多少。如果 NPU 没有明显优势可能是模型结构不适合 NPU或者数据搬运成了瓶颈。3.4 ComfyUI 调用 Intel NPU 的实操记录最近有不少人在问怎么在 ComfyUI 里调用 Intel NPU 跑图。我实际试了一遍流程大概是这样的安装 OpenVINO 的 ComfyUI 插件或者用 OpenVINO 的optimum-intel把 Stable Diffusion 模型转成 OpenVINO IR。在 ComfyUI 的节点里选择 OpenVINO 执行设备指定为 NPU。注意模型要转成 FP16 或 int8FP32 在 NPU 上跑不动或者很慢。第一次加载模型会比较慢因为要编译到 NPU后面就快了。我实测下来Intel NPU 跑 SD 1.5 的 512x512 图片单张大概 8 到 12 秒比纯 CPU 快 3 倍左右但比独立显卡还是慢不少。所以如果你追求极致速度NPU 不是最优解但如果你是在笔记本上做轻量推理NPU 的功耗优势很明显。提示ComfyUI 调用 NPU 时如果遇到“设备不支持”的报错先检查 OpenVINO 版本和 NPU 驱动是否匹配。我遇到过驱动版本太旧导致 NPU 识别不到的情况更新驱动后就好了。4. NPU 算子开发从零写一个自定义算子如果你不满足于用现成算子想自己写一个 NPU 算子这一章就是给你的。NPU 算子开发和 CUDA 编程不太一样它更接近硬件描述你需要考虑数据怎么在脉动阵列里流动、片上缓存怎么分配、指令怎么调度。4.1 算子开发的基本流程以某款 NPU 的算子开发为例流程大致是定义算子接口输入张量形状、数据类型、输出张量形状。编写计算逻辑用厂商提供的 DSL 或者 C 模板描述计算过程。映射到硬件把计算逻辑映射到脉动阵列和片上缓存决定数据分块策略。编译与验证用厂商工具链编译成 NPU 指令然后在模拟器或真机上验证数值正确性。性能调优调整分块大小、数据复用策略提升阵列利用率。这里面最难的是数据分块。因为片上缓存有限大张量必须切成小块一块一块地算。切得不好要么缓存不够用要么阵列利用率低。我一般会先用厂商提供的自动分块工具跑一版然后根据性能报告手动调。4.2 一个简单的 ReLU 算子示例假设我们要写一个 ReLU 算子输入是[1, 64, 56, 56]的 int8 张量。计算逻辑很简单max(0, x)。但在 NPU 上你要考虑数据怎么从主存搬到片上怎么用向量指令一次处理多个元素怎么把结果写回主存。伪代码大概长这样// 假设 NPU 提供向量加载和存储指令 void relu_kernel(int8_t* input, int8_t* output, int size) { for (int i 0; i size; i VECTOR_SIZE) { vectorint8_t v load_vector(input i); vectorint8_t result max(v, 0); store_vector(output i, result); } }实际开发中你还要处理边界情况、对齐问题、多核并行等。我建议先从简单的逐元素算子入手熟悉工具链后再挑战卷积这种复杂算子。4.3 算子性能调优的实战经验算子写出来能跑只是第一步跑得快才是目标。我总结了几条调优经验提高阵列利用率尽量让张量的维度对齐到阵列大小。比如阵列是 16x16那通道数最好是 16 的倍数。减少主存访问能融合的算子就融合中间结果不要写回主存。利用双缓冲在计算当前块的同时预取下一块数据隐藏搬运延迟。选择合适的数据类型int8 比 FP16 快但精度低。如果精度允许优先用 int8。我做过一个对比实验同一个卷积算子优化前阵列利用率 45%优化后到 82%性能直接翻倍。所以算子开发不是写完就完事调优才是重头戏。5. 常见问题与排查技巧实录端侧 AI 部署的坑很多这一章我把常见问题和排查方法整理出来你遇到问题时可以对照着查。5.1 模型转换失败怎么办模型转换失败是最常见的问题原因通常有几类问题现象可能原因解决方法不支持的算子模型里有 NPU 不支持的算子用支持的算子重写或回退 CPU形状不匹配动态形状或维度不对固定输入形状检查各层维度数据类型错误FP32 输入但 NPU 只支持 FP16转换时指定 FP16版本不兼容ONNX opset 太高降低 opset 版本重新导出我一般会先用 Netron 打开 ONNX 模型看看有没有奇怪的节点。然后查 NPU 的算子支持列表逐个核对。如果实在找不到原因就把模型切成几段逐段转换定位问题出在哪一层。5.2 推理结果不对怎么排查推理结果不对比转换失败更头疼因为它不报错只是数值不对。排查思路是对比 CPU 和 NPU 的输出用同一个输入分别跑 CPU 和 NPU看差异有多大。如果差异很小可能是正常的量化误差如果差异很大说明有问题。逐层对比把模型中间层的输出也导出来逐层对比。哪一层开始出现大差异问题就在那一层。检查量化参数量化模型的 scale 和 zero_point 如果算错了输出会完全乱掉。重新校准一遍。检查布局NCHW 和 NHWC 搞混了输出也会不对。确认输入输出布局和模型定义一致。我遇到过一次NPU 输出全是 0查了半天发现是输入张量的 scale 设成了 0导致所有值量化后都是 0。这种问题只能靠仔细检查参数。5.3 性能不达预期怎么优化性能不达预期通常有几个原因数据搬运成瓶颈用性能分析工具看时间花在哪如果是搬运就考虑算子融合或片上缓存。阵列利用率低检查张量维度是否对齐不对齐就 padding。回退 CPU 太多查哪些算子回退了尽量用 NPU 支持的算子替代。功耗限制端侧设备可能因为发热降频导致性能波动。加散热或者降低负载。我一般会用厂商提供的性能分析工具比如 OpenVINO 的benchmark_app加上-pc参数看每一层的耗时。找到最耗时的层重点优化。注意端侧设备的性能测试一定要在真实设备上做模拟器和开发板的性能可能差很多。我吃过亏在开发板上跑得好好的到手机上直接卡死因为手机散热和功耗限制更严格。6. 端侧 AI 的未来扩展与个人体会端侧 AI 这个方向变化太快了。去年还在讨论怎么把 MobileNet 塞进手机今年已经在聊怎么在端侧跑 7B 大模型了。NPU 的算力也在涨从几 TOPS 到几十 TOPS未来还会更高。我个人在实际操作中的体会是端侧部署的核心不是模型有多先进而是对硬件特性的理解有多深。同样一个模型懂 NPU 架构的人能优化出 3 倍性能不懂的人可能连跑都跑不起来。张量布局、量化参数、算子融合这些细节看起来琐碎但每一个都直接影响最终效果。如果你刚开始做端侧 AI我的建议是先从一个小模型入手比如 MobileNet 或者 YOLO-nano完整走一遍导出、转换、量化、部署的流程。跑通之后再逐步挑战更大的模型和更复杂的算子。不要一上来就搞大模型容易受挫。最后分享一个小技巧做端侧部署时永远保留一个 CPU 回退路径。NPU 再快也有不支持的情况。有一个能跑的 CPU 版本兜底至少保证功能可用然后再慢慢优化 NPU 路径。这是我踩过几次坑之后总结出来的希望对你有用。