NPU
神经网络处理单元 (Neural Processing Unit, NPU) 泛指面向神经网络工作负载设计的专用处理器。NPU 既包括数据中心训练与推理加速器，也包括手机、PC 和边缘设备中的低功耗单元；不同产品的能力与软件接口差异很大。
快速开始¶
评估 NPU 前先回答四个问题：
- 目标框架能否识别设备；
- 模型中的全部算子、动态形状和数据类型是否受支持；
- 编译或转换后输出是否与基线一致；
- 目标 Batch 和功耗下是否真正优于 CPU / GPU。
不要从厂商峰值 TOPS 直接推导大模型速度。先用一个小模型完成“导出 -> 编译 -> 加载 -> 推理 -> 质量对比”的闭环。
设计目标¶
NPU 通常通过以下方式提高能效：
- 使用矩阵或张量计算阵列；
- 支持 INT8、INT4、FP16、BF16 等低精度；
- 配置片上 SRAM，减少外部内存访问；
- 融合常见神经网络算子；
- 对数据流和内存布局做专用优化；
- 通过编译器静态安排计算与传输。
专用化提高了目标工作负载的性能功耗比，也缩小了可灵活执行的算子范围。
数据中心与端侧 NPU¶
| 类型 | 主要目标 | 典型约束 |
|---|---|---|
| 数据中心 NPU | 大模型训练、高吞吐推理 | 集群互联、HBM、分布式框架 |
| PC NPU | 本地助手、音视频与轻量模型 | 共享内存、系统 API、功耗 |
| 移动 NPU | 相机、语音与端侧生成 | 电池、散热、模型大小 |
| 嵌入式 NPU | 实时感知与控制 | 固定算子、确定性、资源极少 |
同为 NPU，数据中心卡可能支持多机训练，而移动芯片可能只允许通过系统推理 API 运行转换后的模型。
软件栈¶
典型 NPU 软件栈包括模型前端、图编译器、算子库、设备 Runtime 和 Driver。模型通常先从 PyTorch、TensorFlow 或 ONNX 导出，再经过图优化、量化、布局转换和设备编译。
转换时常见问题包括：
- 算子不受支持，回退到 CPU；
- 动态维度需要固定或限制范围；
- Layout 不同导致额外 Transpose；
- 量化校准不足造成精度下降；
- 自定义算子缺少编译与调试工具。
成功加载模型不等于全部算子都在 NPU 上执行。必须检查编译报告和运行时 Profiling。
大模型推理¶
大语言模型对 NPU 提出几类特殊要求：
- 权重和 KV Cache 容量大；
- Prefill 与 Decode 的形状和瓶颈不同；
- 动态序列长度与连续批处理复杂；
- RoPE、GQA、量化和采样需要完整算子支持；
- 多卡推理需要高效集合通信。
端侧 NPU 通常运行小型或高度量化模型。若权重放在共享系统内存中，实际速度还受内存带宽和操作系统调度影响。
转换案例¶
以文本分类模型为例，先在原框架保存固定输入输出样本，再导出 ONNX 或厂商中间表示。使用有代表性的校准集执行 INT8 量化，编译后逐层或逐输出比较误差。
验收至少包括：
- 正常、空输入和最大长度输入；
- 任务准确率而非仅张量余弦相似度；
- 首次加载、单请求和稳态吞吐；
- CPU 回退比例；
- 功耗、温度与长时间降频。
选型指标¶
| 指标 | 需要验证的内容 |
|---|---|
| 算力 | 对应何种精度、是否要求稀疏 |
| 内存 | 容量、带宽、是否与 CPU 共享 |
| 算子覆盖 | 目标模型是否全部支持 |
| 动态形状 | 序列长度和 Batch 能否变化 |
| 量化 | 支持的粒度、校准和 Kernel |
| 工具链 | 编译、Profiling、调试和错误信息 |
| 生态 | 框架、模型仓库和部署运行时 |
| 能效 | 目标负载下的吞吐每瓦 |
安全与可移植性¶
模型转换器和厂商插件属于软件供应链，应固定版本并核验来源。专有编译产物可能只能运行在特定芯片和 Runtime 上，发布前要记录原始模型、转换参数、校准数据与工具链版本。
涉及端侧隐私时，还要确认输入是否离开设备、系统服务是否记录数据、模型文件能否被其他应用读取。
常见问题¶
- TOPS 通常是特定整数精度的理论值，不能直接换算 Token/s；
- 宣称支持某框架不代表支持该框架中的所有算子；
- CPU 回退可能让功能正常但性能和功耗恶化；
- 量化模型文件更小不保证 NPU 有对应高速 Kernel；
- NPU 不是统一架构，跨厂商迁移通常需要重新转换和评测。