前阵子帮朋友调一台带 NPU 的轻薄本任务是让一个视觉模型在本地跑起来。设备管理器里明明能看到 NPU 设备驱动也装好了可程序一启动任务管理器里的 NPU 占用率纹丝不动CPU 倒是烧到 90 度。这种情况我见过太多次端侧 AI 真正卡人的地方从来不是芯片上有没有 NPU而是张量从框架那一端走到 NPU 那一端这条链路里任何一个环节断裂整个加速就变成摆设。这篇不打算堆硬件参数我想从一张张量的视角把端侧 AI 的执行链路完整走一遍。你会看到数据是怎么摆放的、NPU 硬件为什么能比 CPU 快、模型是怎么一步步变成 NPU 认识的指令以及我在真实部署里踩过的几个大坑。内容主要面向正在做端侧 AI 硬件部署、被 NPU 驱动和算子问题折磨又或者单纯想了解 NPU 算子开发到底在做什么的人。整条链路走完之后你会发现所谓 AI 加速首先是一场数据工程和系统工程其次才是那排乘累加阵列。1. 一张张量从框架到硬件最先要过的是数据姿势关1.1 张量是什么以及为什么 AI 只有这一张通行证张量这个词在 AI 语境下没那么玄本质就是一个 N 维数组。模型里任何数据——图片、音频、文本、特征——最终都会被组织成张量一张 640×640 的 RGB 图是1×3×640×640的 FP32 张量一句话 token 化之后的 embedding 是1×128×4096的 FP16 张量。深度学习模型本身就是一个由算子Operator连接起来的有向无环图而每个算子的输入输出都是张量。所以 NPU 这个硬件的设计目标也极其单纯高速地吃张量。一个 NPU 不认识 PyTorch 的nn.Conv2d也不认识 ONNX 的Conv节点它认识的是自己那套底层指令。从上层模型到 NPU 指令中间靠的仍然是张量这个通行证——框架和运行时之间传输的是张量编译器和 NPU 驱动约定数据格式的也是张量。这里有一个关键点经常被新手忽略运行时里的张量不是一个裸的内存指针它带着一堆元数据——形状shape、数据类型dtype、内存布局layout、步长stride、设备类型、内存地址。NPU 驱动拿到一个张量第一件事就是检查这些元数据是否符合硬件要求。不符合的要么报错要么走一条偷偷帮你拷贝的低效路径。所以张量的姿势对不对往往决定了后续所有性能。1.2 布局与对齐NCHW、NHWC 和 32 字节这道坎框架默认的数据布局跟 NPU 喜欢的布局经常不一致。PyTorch 习惯用 NCHW也就是通道维排在第二维先存完整个 channel 0 再存 channel 1而很多移动端运行时和部分 NPU SDK 更喜欢 NHWC也就是通道维在最后一维每个像素的 RGB 紧挨着排。为什么 NPU 偏爱 NHWC因为图像处理里的裁剪、缩放、格式转换以及 NPU 的 DMA 搬运都希望单次连续访问能拿到尽量多的有效计算数据。通道最后的布局天然适配向量化的数据搬运也让 elementwise 类算子比如加 bias、ReLU 激活能沿着连续内存一次性处理完。反过来NCHW 在 CNN 的权重复用上有它的优点所以 GPU 上很常见。端侧 NPU 上到底用哪种得看具体 SDK 的约定但普遍规律是先问硬件要什么再决定框架层怎么导。比布局更隐蔽的是内存对齐。NPU 的 DMA 引擎通常要求源地址和目的地址按 16、32 甚至 128 字节对齐不满足时驱动会拒绝下发或者做一次 bounce buffer 拷贝。我在实际项目里见过同样的模型、同样的量化方案只是把预处理输出从非对齐改成 32 字节对齐端到端延迟就差了 20%~30%。这个优化不花一分钱但需要你在写预处理代码时就把缓冲区对齐做对。再补一个常见坑张量切片。PyTorch 里tensor[:, :, :100, :]产生的是非连续的 view步长不再是标准值。NPU 不认这种带洞的布局驱动强制要求连续内存最后你不得不做一次contiguous()拷贝。所以设计数据管线时尽量让输入尺寸从一开始就是固定的、对齐的、连续的省得后面反复搬家。1.3 搬运比计算贵NPU 前端的存储模型NPU 芯片内部不是只有一块大内存。典型结构是外部 DDR几个 GB和片上 SRAM通常只有 2~8MB两者之间靠 DMA 引擎搬运。一次推理的过程本质上就是把权重和输入从 DDR 搬到 SRAM在 SRAM 里完成计算再把结果搬回 DDR的循环。看起来计算很忙其实真正耗时的往往不是 MAC 阵列而是数据在 DDR 和 SRAM 之间的来回搬。算笔账一个 3×3 卷积64 输入通道、128 输出通道、输入特征图 56×56总的乘累加次数大约是 3×3×64×56×56×128 ≈ 2.3 亿次。单论计算量任何一个有点规模的 NPU 都能在毫秒级内跑完。但它的输入是 64×56×56约 196KB权重是 3×3×64×128约 72KB输出是 128×56×56约 392KB。这些东西如果都能塞进 SRAM一次 DMA 搬运就够一旦塞不下编译器就必须做 tiling把大张量切成小块分多次搬运每切一次就多一次搬运开销。理解了这个存储模型你就能看懂为什么有些 NPU 标称 TOPS 很高实际跑大模型却乏力的原因——大模型的特征图、KV Cache、中间激活都很大瓶颈早就从计算转移到了搬运。端侧 AI 部署里真正值钱的优化大部分都是围绕怎么少搬展开的这一点后面讲算子融合时还会再碰到。2. NPU 为什么能又快又省硬件层面的取舍2.1 通用处理器的天花板先回答那个经典问题CPU 为什么跑神经网络不够快CPU 是为通用计算设计的。它要应对分支跳转、乱序执行、各种不可预知的任务所以大量晶体管和能耗花在取指、译码、分支预测、缓存一致性上。即便是支持 AVX-512 VNNI 这类向量指令的桌面 CPU单个核心一周期能完成的 int8 乘累加也就是几十次这个量级。想提高吞吐就得靠多核并行但多核并行又受限于内存带宽和缓存。GPU 把并行度做到了另一个量级动辄几千个 CUDA core内存带宽也是 G 字节每秒甚至 T 字节每秒级别。但 GPU 的代价是功耗和体积一块独立显卡动辄两三百瓦集成 GPU 也要分走笔记本大量的功耗预算和内存带宽。对手机、轻薄本、智能摄像头这类端侧设备来说GPU 要么没有要么不能长时间满载跑。于是 NPU 找到了自己的生态位在极低的功耗预算内提供足够高的、面向神经网络算子的计算吞吐。它的做法很粗暴但极有效——放弃通用性把计算资源集中到乘累加这一件事上。2.2 乘累加阵列与数据流核心加速原理一个 MACMultiply-Accumulate运算就是一条公式acc acc a × b。卷积和矩阵乘法虽然表达形式复杂但底层 90% 的工作就是反复执行这种乘累加。NPU 的硬件核心就是一块由成百上千个 MAC 单元组成的阵列。要让这块阵列高效运转关键在于数据怎么流动。常见的设计是脉动阵列Systolic Array思想数据像流水线上传递的工件每个 MAC 单元从邻居那里拿到数据算完后再递给下一个单元。这样做的好处是每个单元不需要频繁从寄存器文件里取数数据搬运开销被大幅摊薄。数据流策略有讲究。权重固定Weight-Stationary适合 CNN——权重在 SRAM 里躺好输入特征图流过整个阵列因为同一个权重会被大量输入复用输出固定Output-Stationary则让部分和待在原地累加适合输出特征图复用较多的场景。编译器做的事情之一就是判断某个算子的数据复用模式选最合适的排布方案。这也是为什么同一个 NPU不同 SDK 版本跑同一个模型性能可能差很多——排布和调度方案的优劣经常比硬件本身的差异更关键。用生活类比就是CPU 像一个全能型自由职业者什么活都能接但每接一单都要重新读资料、找工具NPU 则像一条专线流水线只会做一件事但每个工位只干一个动作吞吐量就是能吊打全能选手。2.3 看懂 TOPS标称性能与真实吞吐的差距TOPSTera Operations Per Second是 NPU 营销最爱用的数字但理解它的计算方式会让你冷静很多。一块 NPU 的标称 TOPS 大约等于主频 × MAC 单元数 × 2一个 MAC 算两次操作乘和加÷ 1e12。比如某款 NPU 主频 1.4GHz、集成 2048 个 MAC 单元那么它的理论峰值就是 1.4G × 2048 × 2 ≈ 5.7 TOPS如果有多个计算引擎再乘个数。但理论峰值和真实吞吐之间有一条巨大的鸿沟——内存带宽。前面说过int8 卷积每做一次 MAC 至少需要读取 1 字节输入和 1 字节权重也就是 2 字节的数据供给。一块标称 40 TOPS 的 NPU理论上每秒需要至少 80GB 的数据供给才能让 MAC 阵列吃饱。而笔记本上常见的双通道 DDR5 内存带宽也就 50~60GB/s 上下还得跟 CPU、GPU 共享。所以实际跑起来MAC 阵列的利用率能到 50% 已经算优秀大量时间都花在等数据上。不同硬件的对比用这张表能看得很清楚维度CPUGPUNPU可编程性极高较高低算子受限计算密度低高很高每瓦性能低中高内存带宽依赖中高极高典型时延灵活较高低算子固定后典型场景通用计算图形/大规模并行固定模型推理结论很简单选型的时候别只看 TOPS要看 SRAM 大小、内存带宽、SDK 成熟度以及你要跑的模型跟这套工具链的契合度。3. 从 ONNX 到 NPU 可执行程序的一次完整编译3.1 全链路模型、运行时、离线编译器假设你已经有一个训练好的 PyTorch 模型要在某款 NPU 设备上跑完整的链路大致长这样模型导出为中间表示最通用的是 ONNX也可以是 TFLite 的 FlatBuffer或者各家 SDK 自己的格式。运行时加载中间表示比如 ONNX Runtime、TFLite、MNN、ncnn它们负责解析模型图并把图切分成若干子图。每个子图交给对应的 NPU 后端NNAPI Delegate、OpenVINO NPU Plugin、QNN、SNPE 等后端编译器把算子映射成 NPU 指令。NPU 驱动把编译好的指令和权重加载到设备运行时负责把输入张量 DMA 到片上、启动内核、再把结果搬运回来。这里有两种编译模式。一种是离线编译AOT在 PC 上用厂商 SDK 把模型预先编译成.bin之类的一体化文件手机端只是加载执行优点是启动快、优化充分缺点是模型一旦改动就得重新编译。另一种是在运行时动态编译JIT设备端拿到模型后边解析边生成计划灵活但不适合对启动延迟敏感的场景。多数端侧 SDK 偏爱 AOT尤其是手机 NPU因为手机端的 CPU 资源太宝贵经不起运行时做复杂图优化。一个常被误解的点是NPU 不会执行你的 PyTorch 代码它只认自家的一族指令。你写的model.forward()最终能不能落到 NPU 上取决于中间那套 SDK 工具链认不认识模型里的每一个算子。这就引出了 3.2 和 3.3 两个主题。3.2 量化没有想象中那么可怕但也没那么简单绝大多数端侧 NPU 的 MAC 阵列都是为 INT8 设计的FP16 只是部分支持或者性能减半。原因很实在INT8 的数据量只有 FP32 的四分之一搬运压力小MAC 单元硬件也更好堆。所以从 FP32 到 INT8 的量化是能不能把模型塞进 NPU 的关键一步。量化的本质是给浮点数值找一组整数映射q round(x / scale) zero_point。scale 是缩放系数zero_point 是零点偏移。怎么定 scale 有两派做法对称量化直接映射到 [-127, 127]和非对称量化利用 [0, 255] 整个范围。权重的分布相对稳定可以用 per-channel 的 scale每个输出通道一组系数激活值分布由输入决定通常整张特征图共用一个 scale也就是 per-tensor。校准Calibration是最容易被做坏的一环。你需要准备一批有代表性的输入数据前向跑一遍收集每个激活张量的数值分布然后用 min/max 或 KL 散度等策略确定 scale。我见过很多团队随便拿几十张网图做校准结果部署到真实场景精度崩了。正确做法是拿目标场景的数据分布去校准比如你的人脸模型部署在闸机上就用闸机现场的抓拍图集。从实际数据看YOLOv5s 这类检测模型做 PTQ 后mAP 损失通常能控制在 1 个百分点以内问题不大但碰到车牌识别、光学字符识别这类对细粒度数值敏感的模型最后几层回归头的 INT8 误差会被成倍放大经常出现看起来指标还行跑起来数字全歪的情况。解决办法是混合精度把敏感的层留在 FP16其余走 INT8。大语言模型那边则是另一套思路最常见的是权重量化到 4bitGPTQ/AWQ 这类方案激活保持 FP16因为主要瓶颈在于 KV Cache 和模型权重的内存占用而不是算子本身。3.3 图优化与算子融合真正决定性能的一步模型原始结构图和实际 NPU 上执行的算子序列往往相差悬殊因为中间有一层图优化。图优化做的事情包括常量折叠、死分支消除以及最重要的算子融合。最经典的融合是 Conv BatchNorm ReLU。BatchNorm 本质上是每个通道做一次线性变换y (x - mean) / sqrt(var eps) * gamma beta这个线性变换可以直接折叠进卷积的权重和 bias权重乘上gamma / sqrt(var eps)bias 做相应修正。融合之后NPU 只需要执行一个卷积内核中间特征图完全不用写回内存。别小看这一步每一个被融合掉的中间张量都意味着少一次整块数据的写入和读取。ResNet 里有几十个这样的组合每一个都是几百 KB 到几 MB 的读写量累积起来就是成倍的性能差距。我在项目里实测过同样的模型在同一个 NPU 上推理时间可以因为融合优化差出 1.5~2 倍。很多时候新模型跑不快不是硬件不行、不是算子写得烂而是图优化没生效大量算子被拆成了一个一个的小颗粒中间数据来回搬运。所以拿到一个 ONNX 模型后第一件事应该是用可视化工具看一遍计算图数数不同名字的节点数。一个健康的、优化充分的计算图节点数应该远小于原始模型的操作数尤其是不要出现一堆孤零零的 BatchNorm 和 ReLU。3.4 实例一个检测模型走完整条链路用一个具体的 YOLOv5s 部署流程把这套链路串起来。我在某高通平台的手机上走的是 QNN/NNAPI 路线流程大致是导出 ONNX设定固定 batch1输入尺寸固定 640×640。这一步最关键的是把动态维度全钉死NPU 讨厌动态 shape。准备 1000 张目标场景图片做校准集把 FP32 ONNX 量化成 INT8 模型。用厂商的转换工具把量化后的模型编译成 NPU 可执行文件同时会输出一个算子支持情况的报告。在目标手机上用厂商 sample 程序验证确认 NPU 真正接管了模型子图而不是静默回退到 CPU。集成自己的预处理和后处理把 resize、归一化、NMS 这些环节放到 CPU 上和 NPU 推理用双缓冲流水串起来。这样的效果224×224 输入的 YOLOv5s 在 15 TOPS 级别的 NPU 上大概能跑到 8~12ms而同一台设备的 CPU 侧要 40ms 往上。差距核心当然有硬件原因但更关键的是链路完整——预处理、量化、算子映射、图融合、后处理流水每一步都做好了才有这个数。3.5 再聊下 ComfyUI 与 Intel NPU 的落地现状端侧 AI 的热度这两年从手机漫延到了 PC最典型的场景是 Stable Diffusion 类工作流。很多人发现自己的 Intel Core Ultra 笔记本带 NPU想知道怎么让 ComfyUI 调用这块硬件搜索里出现comfyui调用因特尔npu一点都不意外。原理上不复杂。OpenVINO 把 PyTorch 的 UNet 模型转成 OpenVINO IR 格式运行时里的 NPU Plugin 会做子图切分把卷积密集的部分放给 NPU一部分 Attention 和动态算子留在 CPU/GPU。ComfyUI 侧通过 OpenVINO 执行后端接入理论上就能让 NPU 参与推理。但现实总是比新闻稿复杂。我在实际折腾中遇到的主要有三道坎第一是驱动版本和 OpenVINO 版本必须精确匹配Intel NPU 驱动和 OpenVINO 运行时是一起发布的版本对不上就会报device not found这类错误第二是模型导出路径要顺ControlNet、IPAdapter 这类附加组件要跟 UNet 一起转 IR版本兼容问题能折腾半天第三是性能预期管理Core Ultra 上的 iGPU 有很高的共享带宽跑大模型常常比 NPU 还快NPU 的真正优势在低功耗——笔记本不插电、长时稳定出图时才有明显收益。这个案例其实是整条链路的缩影硬件在、SDK 在、模型也能转但要把张量高效送进 NPU、把算子映射做对、把版本对齐每一环都踩得动。4. 端侧部署真实踩坑记录按出现频率排序4.1 量化翻车现场敏感层必须单独处理有一次做车牌识别模型的端侧移植FP32 在测试集上准确率 98%PTQ 量化后直接掉到 82%。一开始我怀疑是校准集选得不对换了三组更贴近现场抓拍的数据仍然无效。后来用调试工具逐个算子排查输出误差发现最后那个字符分类的全连接层输出分布极其集中相邻类别的 logit 相差很小INT8 的量化步长根本分辨不出来。修复方案是混合精度只把分类头留在 FP16整个网络其余部分照常 INT8准确率恢复到 96% 以上而推理时间只增加了不到 5%。这个案例教会我的经验是量化损失从来不是均匀分布的少数几个敏感层吃掉了绝大部分误差。排查时别一上来就怀疑全局先做逐层误差对比把误差大的层挑出来单独处理。如果混合精度还不够再考虑 QAT量化感知训练训练阶段模拟量化误差通常能再追回一到两个点但代价是要改动训练管线团队要评估值不值。4.2 算子覆盖不足静默回退是最大的伤害端侧部署最阴险的问题不是直接报错而是静默回退Fallback。当模型图里有 NPU 不支持的算子时运行时不会告诉你这个我不想跑而是默默把包含那个算子的子图切出来丢给 CPU 执行。表面上看程序运行正常但如果每次子图切换都要把张量从 NPU 的内存拷回 CPU 内存、再拷回去你会发现实际延迟比全程跑 CPU 还慢。我有一次部署分割模型输入只有 512×512NPU 上的卷积很快但模型里两个unfold操作把整张图切回了 CPU来回搬运四五次端到端比 CPU-only 还慢 30%。查问题的时候看到运行时日志里出现了fallback to CPU的警告才意识到原凶。排查这类问题的通用手段是把运行时的日志级别调到 verbose查看子图切分结果。QNN、OpenVINO、NNAPI 都有类似的图分割报告会列出每个子图分配到哪个设备。另一个实用技巧是尽量在模型设计阶段就约束算子集合优先使用卷积、全连接、池化、常见激活、普通矩阵乘避开unfold、cumsum、动态gather这类容易落地的高级操作。动态 shape 也是重灾区NPU 的编译器普遍要求静态维度动态 batch 或动态分辨率会造成大量算子被迫回退。把输入固定成定值、或者用 padding 补齐到固定尺寸能避免一大半问题。4.3 驱动、SDK 与运行时版本兼容泥潭端侧 NPU 的软件栈成熟度远不如 CUDA。以 AMD 的 NPURyzen AIXDNA 架构为例官方宣传是大模型原生支持实际部署却要同时满足Windows 驱动版本匹配、ONNX Runtime 的 Execution Provider 版本匹配、Python 环境匹配甚至有些机器要在 BIOS 里确保 NPU 是开启状态。只要其中一环不一致程序要么找不到设备要么静默走 CPU。Intel 那边情况类似。OpenVINO 的 NPU Plugin 跟驱动是强绑定的升级了驱动没升级 OpenVINO或者反过来最常见的结果就是 npu 设备枚举失败。用 ComfyUI 走 OpenVINO 后端的同学在他们的交流帖里百分之七八十的问题都是这类版本冲突。我现在养成的排查顺序是固定的先用厂商 SDK 自带的 sample 程序在目标机器上跑通确定SDK 链没问题确认运行时版本和驱动版本精确匹配记录到项目的环境清单里再跑自己的模型如果 sample 正常但自己的模型异常问题在模型/算子不在环境部署到生产环境的依赖版本全部锁死不轻易升级。这套顺序帮我省了无数瞎折腾。记住一个原则端侧 NPU 不是拿来就用的通用平台它是硬件驱动SDK运行时四位一体的产物任何一位变了都得重新验证。4.4 热设计与功耗NPU 不是每时每刻都划算性能评测里有一句大实话NPU 在每瓦性能上赢但在极致性能上经常输。同一台轻薄本上iGPU 跑 Stable Diffusion 的 UNet 出图可能比 NPU 快一截因为 iGPU 有更灵活的可编程性和更充裕的内存带宽。但如果把功耗墙按住——不插电、限制功耗 15W 时——NPU 反而可能反超。什么时候用 NPU我的判断标准是这么几条模型是已知支持的算子集合且以卷积/矩阵乘为主推理是持续进行的比如摄像头预览流、语音助手唤醒而不是单次突发功耗预算紧张设备依赖电池运行时延要求不算变态100~200ms 级别的任务 NPU 完全够用模型较小特征图能塞进 NPU 的片上 SRAM搬运压力可控。反过来什么时候别迷信 NPU模型非常小CPU 上 1~2ms 就能结束、要求 FP32/FP16 完整精度、模型里动态控制流复杂或者你有充足的 GPU 功耗预算。这些场景下强上 NPU打磨算子映射的投入产出比极低。5. 写算子与异构调度把 NPU 用明白的两件硬功夫5.1 什么样的场景需要动 NPU 算子讲到npu算子开发这个搜索词很多人的第一反应是这不是厂商的事吗其实恰恰相反一线团队碰自研算子的频率远比想象中高。原因是模型迭代速度远快于芯片 SDK 的算子支持速度。典型例子是 Mamba、RWKV 这类新架构自注意力换成了线性扫描厂商 SDK 通常要滞后好几个大版本才补上对应的原生算子。再比如 NMS、top-k 这类带控制流的后处理算子多数 NPU 不原生支持但又不想把它们放在 CPU 上来回搬运。还有一类是融合需求——模型里某个结构厂商没有现成融合内核需要自己写一个自定义算子把两三个标准算子捏在一起。如果你只是调接口部署成熟模型确实不需要写算子但只要你做的是新模型抢占先机的落地算子开发基本是绕不开的。这也是为什么这一块在招聘市场越来越高价值——门槛不在写代码而在你得同时懂张量语义、硬件数据流和编译器行为。5.2 从张量描述符到自写算子一次开发记录我写一个自研算子时工作流大致是固定的。首先是张量描述符。NPU SDK 喂给你的不是普通的数组指针而是一个 TensorDescriptor 结构里面包含维度、dtype、layout、stride、内存池、偏移量等字段。写算子前必须先把描述符里的每个字段搞清楚80% 的调试时间都花在这里。我看过新手一上来就写指令跑出来数值全错最后发现是 layout 字段指定的是 NHWC而参考实现按 NCHW 循环了。然后是端到端的数值验证。我的习惯是写一个 CPU 参考实现用固定随机种子生成多组输入一套数据同时喂给参考实现和 NPU 算子比较输出张量的最大绝对误差。容忍度视类型而定INT8 中间层允许 1~2 个量化步长FP16 一般要求相对误差在 1e-3 量级最后一层尽量收紧到接近参考结果。这个验证要自动化模型迭代一次就要回归一次。接着是性能分析。厂商通常都有 profiler能查看 MAC 利用率、DMA 事务数、内核活动周期数。我见过最典型的性能问题不是算子算得慢而是内存访问模式糟糕导致 MAC 阵列大面积空闲等待。调优优先看数据排布怎么改能让搬运更连续然后才考虑指令级优化。这个流程走完你才会真正理解为什么我说NPU 算子开发首先是数据工程。5.3 融合算子少搬一次数据比优化十个循环更有用自研算子里性价比最高的就是融合算子。举一个我调过的例子模型里有Conv Bias ReLU三段。常规做法是三个算子依次执行卷积结果先写回 DDR下一个算子再读回来加 bias、再过 ReLU写成第三个结果。中途那个中间特征图假设是 64×56×56 的 INT8 张量约 196KB写一次读一次就是 400KB 的搬移。融合后bias 和 ReLU 直接在卷积内核的 epilogue 阶段完成中间结果只在寄存器或 SRAM 里短暂停留读写次数归零。不只是简单激活残差连接加激活也能融入卷积的收尾阶段比如Conv Add ReLU。这类操作在 ResNet 里遍布全图每融合一个省的都是一次整张特征图的往返搬移。我在一个中端 NPU 上做过统计单靠融合推理速度能提升 1.6~2.2 倍而 MAC 阵列的计算量压根没变。想设计好融合算子核心是计算数据重用找出哪些中间数据只被消费一次把它们留在片上设计 tiling 时让 elementwise 和主算子的 tile 边界对齐。做到这两点性能基本不会差。5.4 CPUNPU 分工一张决策清单最后聊聊异构调度。理想状态不是把整个模型都塞给 NPU而是合适的算子去合适的执行单元。我在项目里的切分经验可以总结成一张清单算子类型推荐设备原因卷积INT8NPU计算密集MAC 阵列主场矩阵乘/注意力INT8NPU同样计算密集但注意带宽LayerNorm/SoftmaxNPU 或 CPU看是否支持动态范围敏感NMS、top-k、gatherCPU控制流强NPU 不擅长动态 shape 相关算子CPUNPU 编译器要求静态字符串/文件/IOCPU无争议调度上有个非常实用的技巧CPU 预处理和 NPU 推理用双缓冲流水重叠。比如人脸检测CPU 做仿射变换和 resize 的同时NPU 正在推理上一帧NPU 输出的同时CPU 开始做 NMS。我在一个 512×512 的检测项目上CPU 预处理约 2msNPU 推理约 8msCPU 后处理约 1ms流水化之后端到端 11ms 左右几乎没有浪费。再配合异步 DMA搬运和计算可以进一步重叠。还有一个设计上的建议生产环境永远保留 CPU 回退路径。NPU 驱动在某些设备上一旦拉胯程序要能自动降级到 CPU 而不是直接崩溃。这是我在产品上线前吃过亏才学到的。最后说点我自己的习惯。每次接手一个新的端侧部署任务我第一步永远是把厂商 SDK 的 sample 在目标机器上跑通再把自己模型的 ONNX 导出用同样的后端跑一遍确认工具链没问题后才谈优化。第二步是打开模型图先把所有看起来不像标准卷积/全连接的算子列出来优先处理它们。第三步做量化校准和融合。这个顺序反了后面每一步都是在补窟窿。这几年端侧 AI 的硬件越来越强TOPS 数字翻着跟头涨但真正能落地的项目拼的还是对这条链路本体的理解张量怎么摆、往哪儿搬、算子怎么映射、哪些环节会掉链子。把这些想明白了NPU 才是真正属于你的加速器而不是任务管理器里那个永远 0% 的陌生设备。