前言：为什么同一个模型在不同 NPU 上差距很大？
做嵌入式 AI 部署时，很多人第一次拿到 NPU 板卡都会有一个误解：只要芯片宣传页写着 1TOPS、6TOPS 或 10TOPS，模型就应该按照这个数字线性变快。实际项目里经常不是这样。同样一个 YOLO、MobileNet 或语音关键词模型，在 A 芯片上跑得很顺，在 B 芯片上却卡在某几个算子；同样是 INT8 量化，有的模型精度几乎不掉，有的模型会出现明显误检；同样是官方转换工具，有的网络一键通过，有的网络需要反复改 ONNX 图、替换算子、拆分子图。
这些问题并不神秘，本质上是 NPU 的计算阵列、片上 SRAM、DMA、数据布局、编译器和运行时之间存在非常强的耦合。CPU 代码慢了，我们通常先看热点函数；GPU 程序慢了，会看 kernel occupancy、显存访问和线程块；NPU 部署慢了，也要有类似的分析框架：先判断瓶颈是算力、带宽、算子支持、量化误差，还是 CPU/NPU 之间的调度开销。
本文从工程视角拆解嵌入式 NPU 的典型架构，并围绕一个真实部署流程展开：模型导出、图优化、量化校准、算子映射、内存规划、运行时流水线和性能排查。文章不绑定某一家芯片，但会覆盖 RK、Amlogic、Kendryte、寒武纪边缘模块以及很多 MCU 级 NPU 都会遇到的共性问题。读完后，你应该能判断一个模型为什么没有跑满 NPU，也能知道该从哪里下手优化。
一、先把 TOPS 的含义说清楚
TOPS 是每秒万亿次操作数，通常用于描述 INT8 乘加能力。例如一个 2TOPS 的 NPU，理论上每秒可以完成 2 万亿次 8 bit 整数运算。问题在于，这个数字往往是理想条件下的峰值：输入输出都在合适的数据布局中，算子可以完全映射到矩阵乘阵列，片上缓存命中率足够高，DMA 搬运没有拖后腿，调度器没有频繁切换任务。
在实际模型里，真正能高效利用 NPU 的通常是卷积、深度卷积、全连接、矩阵乘、部分池化和激活函数。很多看起来不起眼的操作，例如 Reshape、Transpose、Slice、Gather、Resize、NonMaxSuppression，如果不能被 NPU 原生支持，就可能回退到 CPU。一次 CPU 回退不仅带来计算时间，还可能带来缓存同步、数据格式转换和内存拷贝。模型中只要有几个这样的“断点”，端到端延迟就会明显变差。
评估 NPU 时，比 TOPS 更有价值的是下面几个指标：
- 端到端延迟：从图像采集或音频帧输入，到最终结果输出的总耗时。
- NPU 子图覆盖率：模型中有多少算子真正被 NPU 执行。
- DDR 带宽占用：输入、输出、中间特征图是否频繁进出外部内存。
- Batch 与分辨率敏感性：嵌入式场景多为 batch=1，很多服务端优化不适用。
- 量化后精度：INT8 的 mAP、Top-1、误唤醒率是否满足业务要求。
- 功耗与温升：持续推理 30 分钟后频率是否降档。
如果只看峰值 TOPS，很容易把问题归因到“芯片不行”。但很多时候，真正的问题是模型图不适合该 NPU，或者预处理和后处理拖慢了整条流水线。
二、嵌入式 NPU 的典型硬件结构
不同厂商的实现细节不同，但嵌入式 NPU 通常可以抽象成几个模块：MAC 阵列、片上 SRAM、DMA 控制器、指令调度器、数据重排单元和外部 DDR 接口。
MAC 阵列负责核心乘加。卷积在编译阶段会被转换为矩阵乘或滑窗乘加任务，再切成多个 tile 放入阵列。片上 SRAM 保存权重块、输入块和输出块，避免每次乘加都访问 DDR。DMA 负责在 DDR 和 SRAM 之间搬运数据。数据重排单元负责处理 NCHW、NHWC、NC1HWC2 等布局转换。指令调度器则把编译器生成的命令流按照依赖关系送入硬件。
一个简化的卷积执行过程如下：
DDR 中的输入特征图 -> DMA 搬入片上 SRAM
DDR 中的权重块 -> DMA 搬入片上 SRAM
MAC 阵列执行 tile 卷积
局部输出写回 SRAM
必要时做激活/量化/累加
最终输出通过 DMA 写回 DDR
这里的关键是“tile”。片上 SRAM 容量有限，不可能一次放下完整的高分辨率特征图和全部权重。编译器需要根据 SRAM 大小、阵列形状、数据类型和算子参数，把一个大算子切成许多小块。tile 切得太小，DMA 和调度开销变大；tile 切得太大，SRAM 放不下或复用率下降。很多 NPU 的性能差异，表面看是 TOPS 不同，深层其实是 tile 策略、数据布局和内存层次做得好不好。
三、从模型图看 NPU 友好程度
在部署前，建议先用 Netron、ONNX GraphSurgeon 或厂商工具查看模型图。一个 NPU 友好的模型通常具备这些特征：主干网络由 Conv、BN、ReLU/SiLU、Pooling、MatMul 等常见算子组成；分支结构不太复杂；动态 shape 很少；后处理可以拆到 CPU，并且数据量已经足够小；输入分辨率固定；没有大量 Transpose 和 Gather。
以目标检测模型为例，主干和 neck 往往很好映射到 NPU，但 decode 和 NMS 经常是麻烦点。很多模型导出 ONNX 后，会把网格生成、坐标变换、阈值过滤和 NMS 都留在图里。这样虽然在 PC 上用 ONNX Runtime 很方便，但在嵌入式 NPU 上可能导致大量 CPU 回退。更稳妥的做法是让 NPU 输出三个尺度的特征图，后处理在 C/C++ 中单独实现。
另一个常见问题是激活函数。传统 ReLU 对 NPU 友好，但 Swish、GELU、HardSwish 的支持情况因芯片而异。有些 NPU 可以融合 Conv + BN + ReLU，但不能很好地融合 Conv + BN + SiLU。如果模型允许，训练阶段就应考虑部署端约束，而不是等模型训练完再强行适配。
（第一部分完，约2300字）
四、模型转换前的图优化：少一个 Transpose 就少一次搬运
NPU 编译器通常会做常量折叠、算子融合、死节点删除和布局传播，但不要指望它解决所有问题。工程上更可靠的做法，是在导出 ONNX 后主动清理模型图。尤其是 PyTorch 导出的图，经常会因为框架表达方式留下多余的 Unsqueeze、Concat、Slice、Transpose，这些节点在桌面端不明显，在 NPU 上却可能成为性能断点。
下面是一个简单的 ONNX 检查脚本，用来统计算子类型和可疑节点：
import onnx
from collections import Counter
model = onnx.load("model.onnx")
ops = Counter(node.op_type for node in model.graph.node)
for op, count in ops.most_common():
print(f"{op:20s} {count}")
suspect = {"Transpose", "Gather", "Slice", "Resize", "NonMaxSuppression", "Shape"}
print("\n可疑算子：")
for node in model.graph.node:
if node.op_type in suspect:
print(node.name, node.op_type, [i for i in node.input], "->", [o for o in node.output])
如果发现 Transpose 数量很多，要进一步看它们是否只是为了在 NCHW 和 NHWC 之间来回切换。有些转换工具要求固定输入布局，导出时如果设置错了，就会在图首和图尾插入额外重排。重排操作本身不做复杂计算，却会读写完整特征图；对于 640×640 的检测模型，中间层特征图可能有数 MB，几次重排就足以吞掉大量带宽。
图优化的基本原则有三条：
- 能融合就融合：Conv + BN + Activation 应尽量在转换前或编译器中融合。
- 能静态就静态：固定输入尺寸、固定 batch，避免动态 shape 进入 NPU 子图。
- 能移出就移出：NMS、字符串处理、复杂索引等不适合 NPU 的逻辑放到 CPU 后处理。
以 BatchNorm 融合为例，推理阶段 BN 可以合并进卷积权重和偏置。公式并不复杂：
# W, b: 原卷积权重和偏置
# mean, var, gamma, beta: BN 参数
# eps: BN epsilon
scale = gamma / np.sqrt(var + eps)
W_fused = W * scale.reshape(-1, 1, 1, 1)
b_fused = beta + (b - mean) * scale
融合后，运行时少了一个 BN 算子，也减少了一次中间特征图读写。对大模型来说，这种看似基础的优化非常重要，因为嵌入式推理经常不是算力不够，而是内存访问太贵。
五、INT8 量化：性能提升背后的精度账
多数嵌入式 NPU 的高性能路径是 INT8。FP16 或 BF16 支持正在变多，但在低功耗设备上，INT8 仍是性价比最高的部署方式。量化的核心是把浮点张量映射到整数范围：
real_value ≈ scale × (int_value - zero_point)
对于权重量化，常见做法是 per-channel；对于激活量化，常见做法是 per-tensor。per-channel 能显著改善卷积权重量化精度，因为不同输出通道的权重分布可能差异很大。激活则依赖校准数据集，用一批代表性输入统计每层的数值范围。
校准集不是随便找几十张图就行。它应该覆盖真实场景中的亮度、角度、背景、目标尺度和噪声。如果是工业检测，要包含正常品、轻微缺陷、严重缺陷和空载图；如果是语音唤醒，要覆盖不同说话人、距离、噪声和麦克风增益。校准集偏了，量化 scale 就会偏，最终表现为某些场景下误差突然变大。
下面是一个用于挑选图像校准集的小脚本思路：从原始数据中按亮度和边缘密度分桶，避免校准样本都集中在同一种光照条件。
import cv2
import numpy as np
from pathlib import Path
items = []
for p in Path("calib_raw").glob("*.jpg"):
img = cv2.imread(str(p), cv2.IMREAD_GRAYSCALE)
if img is None:
continue
brightness = float(img.mean())
edges = cv2.Canny(img, 80, 160)
edge_density = float((edges > 0).mean())
items.append((p, brightness, edge_density))
# 简单分桶：亮度 5 桶，纹理 5 桶，每桶最多取 4 张
selected = []
buckets = {}
for p, b, e in items:
key = (min(int(b / 51), 4), min(int(e / 0.04), 4))
buckets.setdefault(key, []).append(p)
for key, paths in buckets.items():
selected.extend(paths[:4])
print("selected", len(selected))
量化后一定要做逐层对比。只看最终 mAP 或准确率，很难定位问题。更有效的方式是让浮点模型和 INT8 模型输出若干关键层，计算余弦相似度、均方误差和最大误差。如果某一层开始相似度骤降，就重点检查该层前后的激活范围、是否有异常 outlier、是否有不适合量化的操作。
六、算子映射：让模型顺着硬件走
NPU 编译器会把模型图拆成一个或多个子图。连续可支持的算子会进入 NPU 子图，不支持的算子留给 CPU 或 DSP。性能优化的目标，就是让大的计算段尽量连续地留在 NPU 上。
举个常见例子：Conv -> BN -> SiLU -> Add。如果某个 NPU 不支持 SiLU 融合，编译器可能把 Conv + BN 放进 NPU，把 SiLU 放到 CPU，再把 Add 放回 NPU。这样中间特征图要从 NPU 内存写到 DDR，再由 CPU 读取处理，然后又写回给 NPU，代价非常高。此时可以考虑把 SiLU 替换为 HardSwish 或 ReLU6，或者在训练时使用部署端支持更好的激活函数。
再比如深度可分离卷积。它理论上计算量低，但对某些 NPU 并不一定更快，因为 depthwise conv 的数据复用率不如普通卷积，容易变成带宽瓶颈。移动端网络里常见的 1×1 pointwise conv 反而更容易跑满矩阵阵列。所以模型结构选择不能只看 FLOPs，还要结合目标硬件的算子效率表。
实践中可以建立一张“算子白名单”：
preferred_ops:
- Conv
- Relu
- LeakyRelu
- Add
- Mul
- MaxPool
- AveragePool
- GlobalAveragePool
- MatMul
avoid_ops:
- NonMaxSuppression
- DynamicQuantizeLinear
- GatherND
- GridSample
- Resize(mode=cubic)
- Transpose(large_feature_map)
这张表不是固定的，要根据具体芯片 SDK 更新。每次 SDK 升级后，都建议重新跑一遍模型转换报告，看看原本回退 CPU 的节点是否已经支持，或者原本支持的融合是否发生变化。
（第二部分完，约2500字）
七、内存规划：嵌入式 NPU 最容易被低估的战场
很多模型理论计算量不大，却在板子上跑不快，根因是内存。嵌入式 SoC 的 DDR 同时服务 CPU、GPU、ISP、VPU、NPU 和显示控制器。摄像头预览、视频编码、神经网络推理如果同时进行，DDR 带宽会被迅速吃满。NPU 峰值算力再高，数据喂不上去也只能空转。
优化内存时，先看三类数据：输入输出、中间特征图、权重。权重通常可以常驻内存，有些平台还能预加载到专用区域；输入输出与业务流水线有关，例如摄像头 NV12 数据是否需要转 RGB、是否需要 resize、是否能使用 zero-copy；中间特征图由编译器规划，但模型结构会影响峰值内存。
对视觉模型来说，预处理经常被忽略。一个 1080p 摄像头输入，如果每帧都由 CPU 做 NV12 到 RGB、resize、归一化，再拷贝到 NPU 输入缓冲区，可能预处理就花掉 8 到 15ms。更好的方式是使用 ISP/RGA/GPU 做颜色转换和缩放，或者让 NPU runtime 接受硬件缓冲区句柄，减少内存拷贝。
典型的零拷贝流水线如下：
Camera DMA buffer
-> 硬件缩放/颜色转换
-> NPU 输入 buffer
-> NPU 推理
-> CPU 读取小尺寸输出
-> 后处理与业务逻辑
如果平台支持 ION、DMA-BUF 或类似机制，尽量让视频帧在硬件模块之间传递句柄，而不是在用户态反复 memcpy。这类优化写起来不如改模型显眼，但对端到端延迟和功耗非常有效。
八、运行时流水线：不要让 NPU 等 CPU
单帧推理流程通常包括采集、预处理、推理、后处理和显示/通信。如果这些步骤串行执行，总延迟是所有步骤相加。实际产品中可以用流水线并行：CPU 后处理第 N 帧时，NPU 推理第 N+1 帧，ISP 准备第 N+2 帧。这样单帧延迟没有消失，但系统吞吐会明显提升。
下面是一个简化的 C++ 伪代码，展示三线程流水线的结构：
struct FrameJob {
int id;
Buffer input;
Buffer tensor;
NpuOutput output;
};
BlockingQueue<FrameJob> q_pre, q_infer, q_post;
void capture_thread() {
int id = 0;
while (running) {
FrameJob job;
job.id = id++;
job.input = camera_dequeue();
q_pre.push(job);
}
}
void preprocess_thread() {
while (running) {
auto job = q_pre.pop();
job.tensor = hw_resize_color_convert(job.input);
q_infer.push(job);
}
}
void infer_thread() {
while (running) {
auto job = q_infer.pop();
job.output = npu_run(job.tensor);
q_post.push(job);
}
}
void postprocess_thread() {
while (running) {
auto job = q_post.pop();
auto result = decode_and_nms(job.output);
publish_result(job.id, result);
camera_release(job.input);
}
}
这里有几个工程细节：队列长度不能无限增长，否则实时系统会堆积旧帧；如果业务只关心最新结果，可以在队列满时丢弃旧帧；NPU 输入输出 buffer 应该复用，避免每帧申请释放；多线程之间要注意 cache flush/invalidate，特别是 CPU 和 NPU 共享物理内存时。
九、性能排查：按层耗时比总耗时更重要
当模型跑得慢时，不要先猜。第一步是拿到转换报告和 profiler。大多数 NPU SDK 都能输出每层耗时、子图划分、内存使用和 CPU fallback 信息。如果工具不够完善，也可以在业务侧用时间戳包住预处理、推理和后处理，至少先拆出大方向。
建议建立如下排查顺序：
- 确认频率和温度：是否因为供电、散热或 governor 导致降频。
- 确认模型输入尺寸：是否误用了更大分辨率或动态 shape。
- 查看 NPU 子图覆盖率：是否存在 CPU fallback。
- 查看最慢的前 10 层：是大卷积、Resize、Transpose，还是后处理。
- 检查预处理耗时：是否被 CPU resize 和 memcpy 拖慢。
- 检查量化模式：是否有部分层保持 FP32，导致混合执行成本增加。
- 对比官方 benchmark：用厂商示例确认环境没有系统性问题。
如果某一层卷积异常慢，可以尝试改变输入尺寸、通道数或模型结构。NPU 对通道对齐很敏感，有些硬件喜欢通道数是 8、16 或 32 的倍数。如果网络中出现 3、5、7 这类不规则通道，编译器可能需要 padding，导致实际计算和内存都增加。训练模型时适当让通道数对齐硬件粒度，通常比部署后硬优化更划算。
十、一个可落地的部署检查清单
下面这份清单适合放进项目的 docs/deployment.md，每次模型升级时按步骤检查：
[模型导出]
- 固定 input shape 和 batch=1
- 关闭训练态节点，确认 BN 已进入 eval 模式
- 导出 ONNX 后用 onnx.checker 校验
[图优化]
- 统计算子类型，标记 Transpose / Gather / Slice / Resize
- 融合 Conv + BN + Activation
- 将 NMS、decode 等后处理移出 NPU 图
[量化]
- 校准集覆盖真实场景
- 使用 per-channel weight quantization
- 做逐层余弦相似度对比
- 对关键指标做回归测试
[编译]
- 查看 NPU 子图覆盖率
- 保存编译报告和 SDK 版本
- 记录输入布局、量化参数和 runtime 配置
[运行]
- 预分配输入输出 buffer
- 使用硬件预处理或 zero-copy
- 分离采集、推理、后处理线程
- 记录端到端延迟、P95、P99 和温度
这份清单的价值在于让部署过程可复现。很多团队的问题不是没有优化能力，而是每次模型、SDK、板级系统一起变化，最后不知道性能变化来自哪里。只要把转换命令、校准数据版本、编译报告和测试结果保存下来，排查效率会高很多。
十一、常见坑与解决办法
1. PC 上 ONNX 推理正确，NPU 结果明显偏移。 先检查输入归一化顺序、RGB/BGR、NHWC/NCHW 和量化 scale。很多精度问题并不是 NPU 算错，而是预处理和训练时不一致。
2. 转换工具提示某个算子不支持。 不要急着换芯片，先看该算子是否可以常量折叠、替换或移到后处理。比如检测模型里的 NonMaxSuppression 通常没必要放在 NPU 图里。
3. INT8 精度下降很大。 增加校准集多样性，检查异常激活层，尝试 per-channel、混合精度或量化感知训练。对于检测头、注意力模块等敏感部分，可以保留 FP16，前提是硬件支持且性能可接受。
4. 单独 benchmark 很快，业务程序很慢。 重点看预处理、后处理、线程同步、日志打印和内存拷贝。厂商 benchmark 往往只测 NPU 子图，不包含摄像头和业务逻辑。
5. 长时间运行后变慢。 检查温度、供电、内存泄漏和 buffer 队列堆积。嵌入式设备的持续性能比冷启动成绩更重要。
十二、总结：NPU 优化是模型、编译器和系统工程的合题
嵌入式 NPU 部署不是把模型丢进转换工具那么简单。一个稳定高效的方案，需要模型结构顺着硬件走，量化校准贴近真实数据，编译报告能解释每个子图，运行时流水线减少等待，系统层面控制带宽、功耗和温度。
如果把经验压缩成一句话：先保证算子连续落在 NPU 上，再减少大特征图搬运，最后才追求单个算子的极限优化。很多项目真正的性能提升，来自删掉几个多余的 Transpose、把 NMS 移出图、使用硬件 resize、复用 DMA buffer，而不是盲目追逐更大的 TOPS。
面向未来，边缘 NPU 会继续向更强的混合精度、更好的 Transformer 支持和更完善的软件栈发展。但在可预见的几年里，嵌入式工程师仍然需要理解硬件约束。懂模型的人写出的网络更容易部署，懂系统的人能把 NPU 放进真实产品流水线，懂架构的人则能在性能、功耗和成本之间做出正确取舍。
（全文完，约7200字）