2026 年 69 家 Edge AI NPU 厂商：芯片、SDK 与 YOLO 部署

NPU 市场并非单一市场。本指南并非穷尽性清单，共跟踪 69 家公司及平台生态：51 家提供可部署芯片或平台的厂商、9 家 NPU IP 供应商，以及 9 家明确标注的候选厂商。 它们横跨多个彼此不兼容的加速器类别，编译器技术栈也几乎各不相同。大多数厂商承诺的流程都类似：导出模型、量化、编译、把专有产物复制到开发板，再调用厂商运行时。具体细节决定这条流程耗时是一个下午还是一个工程季度。

本指南梳理了 2026 年提供可信计算机视觉硬件的公司，记录相关芯片、SDK 和编译器名称、部署产物、公开程度，以及厂商实际记录的模型。本文也特别介绍 Amlogic：其较新的 ADLA 技术栈与较早的 A311D NPU 生态有实质区别。

**研究范围：**资料核查截至 2026 年 8 月 15 日。除非另有标注，具名模型的说法均来自一手产品页面、文档、模型库、仓库或厂商教程。宣传的 TOPS 是厂商数据，不能视作可独立比较的基准测试结果。这是一份开发者指南，不构成投资建议，也不是付费排名。

快速导航：公司表格 | Amlogic 深入介绍 | 厂商简介 | 编译产物表 | 工具获取与生命周期 | LibreYOLO 路线图

最重要的发现

硬件市场高度碎片化，但部署模式却出奇一致：

PyTorch checkpoint
    -> ONNX or TFLite interchange graph
    -> representative calibration data
    -> vendor quantizer and graph compiler
    -> chip-specific binary or model package
    -> vendor runtime on the target
    -> application preprocessing, decode, NMS and rendering

ONNX 明确支持运行时、代码生成器和硬件实现，但 ONNX 文件只是交接格式。这不代表每个 ONNX 算子都能被每种加速器支持并下沉执行。静态输入形状、算子支持限制、量化规则和主机回退共同决定了哪些计算真正运行在 NPU 上。

因此，软件栈也是芯片的一部分。标称速度很快但编译器受限或脆弱的 NPU，可能不如工具链公开、拥有模型库和模拟器、运行时稳定的小型设备适合作为部署目标。

本指南中「支持」的含义

厂商资料对「支持」一词的使用很宽泛。本文区分四种证据等级：

这个区别很重要。「可以导入 ONNX」不等于「支持 YOLO11 分割」。模型可能可以解析，却回退到 CPU；也可能编译后输出数值不正确、超出加速器内存，或在量化过程中损失精度。

NPU 公司与平台一览

下表有意纳入 SoC、独立加速器、智能传感器，以及相邻的 GPU/FPGA 目标。即使厂商使用 NPU、AIPU、BPU、KPU、DLA、HTP、TPU 或 MLA 等不同名称，它们仍会参与同一个部署选型。

嵌入式 SoC、智能传感器和工业处理器

独立边缘加速器和模块

开发者也会拿来与 NPU 比较的相邻平台

Amlogic：两代 NPU，而非同一套技术

Amlogic 值得深入介绍，因为网络资料常将不兼容的产品混为一谈。该公司有较旧的 VeriSilicon 路径和较新的专有 ADLA 路径。两者使用不同编译器、产物和运行时。

A311D 数据手册将原始 NPU 标为 5-TOPS INT8。较早的 Khadas VIM3 应用页面和 NPU 概览记录了 DenseNet CTC、MTCNN、RetinaFace、YOLOFace、YOLOv2、YOLOv3、YOLOv3-tiny、YOLOv4、YOLOv7-tiny 和 YOLOv8n；概览还记录了 YOLOv8n-pose，并标记 FaceNet 已弃用。这些示例确实存在，但它们证明的是旧 Acuity .nb 生态，而非当前 ADLA 芯片。A311D 不等于 A311D2，C305X 不等于 C305X2。

还有第二个硬件陷阱。Khadas VIM4 修订版指南指出，最初的 V12/A311D2 Rev.B 开发板没有 NPU；宣传的 3.2-TOPS NPU 出现在采用 A311D2-N0D Rev.C 芯片的 V13A 及后续开发板上。仅凭产品名称不足以选定测试设备。

当前 AMLNN 和 ADLA 技术栈

当前 AMLNN Toolkit涵盖模型转换、量化、编译、推理和分析。其固定版本的2026 年 5 月用户指南记录了 ONNX、浮点或量化 TFLite、TorchScript .pt，以及 PyTorch 2 ExportedProgram/PT2 导入器。尽管仓库概览用语更宽泛，详细指南仍将 TensorFlow、Paddle 和 Keras 路径标记为计划中。编译器生成 .adla。Python 部署使用 AMLNN 或 amlnn_edge_toolkit_lite；原生 C/C++ 通过 nnsdk2.h 链接 libnnsdk.so。主机端开发可通过 ADB 使用 nnserver；运行时还支持 Android、Buildroot、Yocto 和部分 Debian/Armbian 环境。

工具包当前公布的平台标识如下：

目标字段并非装饰信息。Amlogic 要求 .adla、nnsdk2.h、libnnsdk.so、BSP 以及编译器/运行时代际彼此匹配。固定版本的快速入门要求 ADLA 驱动 2.0.2 或更新版本、NNSDK 3.0.0 或更新版本，以及 NNSDK2 1.0.0 或更新版本；Android 部署指南具体说明了库、头文件、驱动和 BSP 之间的关系。应将 .adla 视为与 ABI 绑定的构建产物，而非可移植模型。

量化也取决于 NPU 代际。ADLA2 目标 001 至 006 的文档记录了 W8A8 和 W8A16 编译。ADLA3 目标 007 和 008 增加了 W4A8、W4A16、W8A8、W8A16 和 W16A16 组合，并在算子指南中记录了原生 INT4、FP16 和 BF16 支持。Amlogic 建议使用 200 至 500 张有代表性的校准样本。其随机数据选项明确用于性能测试，而非保持精度的量化。

Amlogic 有文档记录的模型覆盖

固定版本的 Amlogic model playground比笼统声称支持 ONNX 更有力。其公开支持/示例矩阵列出了 A311D2、S905X5、A311Y3、C305X2 和 A123X。编译器接受其他目标 ID，并不能证明整个模型列表都在这些目标上通过验证。

同一仓库还公布了以下 W8A8 模型运行时数据。这些是神经网络在 NPU 上的厂商测量结果，并非完整摄像头流水线。

需要特别注意其中的限制。Amlogic 的算子指南指出，ADLA2 和 ADLA3 都在软件中执行 NMS。README 将这些数据定义为 NPU 原生模型运行结果，不包含预处理和后处理；是否包含所有内存传输并未披露。YOLO 精度数据使用 300 张 COCO 子集图像，而非完整验证集；分类数据则使用 ImageNet val1000。表中 A311Y3 的 YOLOv8n 延迟与 FPS 表给出的数据不同，仓库未说明测试条件差异。时钟频率、功耗模式、散热、具体 SDK/BSP 版本和测试时长均未披露。应使用这些数据了解单一厂商技术栈，而非与其他厂商横向排名。

Amlogic 为什么值得关注

Amlogic 同时具备四个少见特点：嵌入式 SoC 覆盖面大、编译器技术栈刚刚公开、当前模型矩阵与 LibreYOLO 的任务范围高度重叠，而且主流训练库中原生集成较少。当前仓库也很新，分别于 2025 年底和 2026 年初公开，实质性手册发布于 2026 年 5 月至 7 月。这带来了先发机会，也意味着 API 稳定性存在风险。

一次干净的集成应使用 LibreYOLO 的确定性 ONNX 导出作为编译器输入，低精度构建要求提供有代表性的校准图像，生成 .adla 和元数据清单，再通过 NNSDK2 适配器加载。旧款 A311D 应使用明确区分的 .nb 目标，因为把 .nb 和 .adla 当作同一个后端会造成静默兼容故障。Amlogic 仓库采用 Apache-2.0 顶层许可；在 LibreYOLO 镜像其中的 wheel、共享库、nnserver 和 Android AAR 二进制文件之前，应直接确认再分发权利。

公开部署生态较完善的厂商

以下公司目前较清楚地兼具可获取的硬件、公开技术资料和具名模型证据。这并不代表它们在所有场景下都更快，而是其兼容性声明更容易在购买硬件前评估。

Hailo

Hailo 是专用视觉加速器生态的典型代表。模型先解析为 Hailo Archive，再使用有代表性的图像进行优化和量化，最后编译为 Hailo Executable Format（.hef）文件。应用通过 HailoRT 加载该 HEF。

Hailo Model Zoo包含检测、分割、分类、姿态等任务的配方、预训练模型、后处理配置和性能数据。YOLO 覆盖包括 YOLOv3/v4/v5/v6/v7/v8/v9/v10/11/12 和 YOLO26，以及 YOLOX、DAMO-YOLO、SSD 和 EfficientDet。固定版本的 Hailo-8 目标检测表比笼统的产品页面更适合用作兼容性依据；独立应用则记录了可部署的 YOLO 流水线。

这里有一个重要的版本界线。Hailo-8 和 Hailo-8L 使用较旧的 Model Zoo 2.x、Dataflow Compiler 3.x 和 HailoRT 4.x 系列；Hailo-10 和 Hailo-15 使用当前 5.x 代际。即使设备都带有 Hailo 名称，配方、解析器行为和 HEF 也不能互换。

Hailo-15 还有独立的应用层。它使用 Vision Processor Software Package 和 Hailo Media Library，而不是 Hailo-8/10H 的 TAPPAS 风格主机路径。公开参考仓库 hailo-camera-apps于 2026 年 5 月 3 日归档；hailo-apps-core则是另一个仍公开的应用框架。仓库归档不能证明产品已 EOL，但 Hailo-15 项目应通过 Developer Zone 确认当前的应用包。

LibreYOLO 的 Hailo 部署指南有意只到静态 ONNX 交接为止，因为专有编译器不能作为 Python 依赖打包。这是生成适用计算图与声称已测试 HEF 之间应保持的界线。

Rockchip

Rockchip 的嵌入式 Linux 开发板在爱好者和商业项目中都很常见，尤其是 RK3588、RK3576 和 RK356x。公开的 RKNN-Toolkit2可在 x86 Linux 主机上转换和量化模型，再由开发板上的 RKNN Runtime 或 Toolkit-Lite 执行生成的 .rknn 文件。

RKNN Model Zoo对芯片、模型系列和精度的说明相当具体。当前表格列出 YOLOv5/6/7/8/10/11、YOLOX、PP-YOLOE、YOLO-World 和 YOLOv5/v8 分割变体的 FP16、INT8 路径；YOLOv8 OBB 和 YOLOv8 pose 仅列出 INT8。它还涵盖 OCR、人脸和其他分割网络。

LibreYOLO 已提供保守的直接 RKNN 导出器。它在 RK3588 上验证了四种确切的检测变体，可比较编译器模拟器和 ONNX Runtime，并拒绝未验证的模型系列，不会把成功构建等同于预测正确。这种范围明确的支持声明可作为未来 NPU 后端的参考。

Axelera AI

Axelera AI 常被误拼为「Accelera」，其产品是 Metis AIPU，提供 M.2、PCIe 和多芯片产品。Metis 是目前可公开订购的系列；Europa 和 Titania 是已发布的产品规划，因此不能把它们都描述成相同的供货状态。Voyager SDK 在 GitHub 公开，涵盖模型选择、编译、量化、执行和应用流水线；客户支持仍需账号。

公开的 Voyager Model Zoo是市场上信息最充分的模型库之一。它列出 YOLOv3、YOLOv5、YOLOv7、YOLOv8、YOLOv9、YOLOv10、YOLO11、YOLO26 n/s/m/l/x、YOLOX、YOLO-NAS、OBB、姿态和分割，以及大量分类和稠密预测模型，并提供模型变体、输入尺寸、精度、准确率和实测性能。将量化损失和精度与速度一并公布，比只公布峰值 TOPS 更有用。

产物命名随 API 代际发生过变化。alpha 版 Pipeline Builder 编译流程会生成 .axm 模型，并可将可移植流水线打包为 .axe。经典流水线文档则描述 .axmodel、模型元数据和清单。集成时应检测安装的 Voyager 代际，而不是硬编码一种扩展名。

Qualcomm

高通的设备覆盖范围很广，但「Qualcomm NPU」背后有多种接口。开发者会根据设备和产品类别使用 QAIRT/QNN 下的 Hexagon HTP、较旧的 SNPE 流程、Qualcomm AI Hub 编译服务、LiteRT，或 ONNX Runtime 的 QNN 执行提供程序。

官方 Qualcomm AI Hub Models仓库提供了较强的模型级证据。它发布了 YOLOv3、YOLOv5、YOLOv6、YOLOv7、YOLOv8、YOLOv9、YOLOv10、YOLO11、YOLO26 检测/分割/姿态、YOLOX、YOLO-World、YOLOR、RF-DETR，以及大量分类、深度和姿态模型的优化包。AI Hub 还提供特定设备上的性能分析，这很重要，因为针对一种 HTP 代际编译的模型不会自动适用于另一代。

主要集成成本来自庞大的组合矩阵：Android 与嵌入式 Linux、QCS 订购型号与消费级 Snapdragon、HTP 架构、QNN/QAIRT 版本和量化方案都很重要。高通当前不同页面对 Dragonwing IQ-9075状态的说法不一致：产品页标为 Active，其评估套件可用于评估，而产品生命周期计划仍标为 Sampling，并列出至 2038 年的生命周期。订购 SKU 前缀为 QCS9075；高通宣传 50 和 100-dense-INT8-TOPS 配置，并支持 Ubuntu/Yocto。应针对确切订购 SKU 确认量产状态；LibreYOLO 集成也应记录 SKU，而非生成名为「Qualcomm」的通用目录。

DEEPX

DEEPX 的 DX-M1/DX-M1M 加速器使用 DXNN SDK。DX-COM 负责模型编译和量化，DX-RT 执行模型，部署产物格式为 .dxnn。公司公开了 DX-AllSuite、DX-APP应用示例，以及大型在线 Model Zoo。

截至 2026 年 8 月 15 日，公开目录在 DX-COM 2.4.0 和 DX-RT 3.4.0 下报告 354 个条目。文档覆盖 YOLOv3 至 YOLO11 和 YOLO26、YOLOX、SSD、EfficientDet、NanoDet、DAMO-YOLO、YOLO 分割、姿态和旋转框。DEEPX 是较可行的集成候选，原因是编译器/运行时边界和部署产物名称都很清楚，且公开视觉模型覆盖面广。

工业 SoC 是多个生态，不是一套生态

工业厂商的产品生命周期通常较长，在摄像头、安全和实时集成方面也优于面向创客的开发板 SoC。其 AI 技术栈可能更复杂，因为同一厂商可能同时提供几种互不相关的 NPU 架构。

Texas Instruments

TI 当前的边缘 AI 处理器包括 AM62A、AM67A、AM68A、AM69A 和相关 TDA4 设备。软件路径由 Processor SDK Linux、TIDL 编译器/运行时、Edge AI TIDL Tools和 Edge AI Model Zoo组成。TIDL 可与 ONNX Runtime、TensorFlow Lite 等应用运行时集成，同时卸载受支持的子图。

TI 提供的远不止框架导入声明：其模型库包含目标检测、分割、姿态、分类、深度等任务的转换模型和性能元数据。TI 也提醒，模型库产物是开发起点，不会自动成为可用于生产的资产。很多厂商对比资料会漏掉这个有价值的限制说明。

TI 还将 TDA54-Q1列为 Preview，该器件最多有四个 C7 NPU，标称可达 400 TOPS；更广泛的 TDA5 系列宣传值最高为 1,200 TOPS。这些是新一代产品的厂商数据，不代表在 TI 发布针对 TDA54-Q1 的目标矩阵之前，可以把 AM6xA/TDA4 的 TIDL 模型验证结论转移过去。

NXP

NXP 至少需要区分四种后端：

eIQ Model Zoo包含 YOLOv4-tiny、YOLOv8、NanoDet、CenterNet、FastestDet、SSD Lite、YOLACT 等模型的产物或配方；其中 YOLOv5 条目仅为文档。某个后端上的验证条目不能证明其他三个后端也适用。NXP 自己的i.MX 平台 YOLO 导出指南就说明了按目标转换模型的复杂性。NXP 表示，整合式 eIQ Toolkit 在 2025 年第三季度发布 1.17 版后将不再更新；当前工作流使用 eIQ Neutron SDK 等独立软件包。

NXP 于2025 年 10 月完成对 Kinara 的收购。Ara240 规格表标称最高 40 eTOPS，并报告 YOLOv8n 每秒处理 313 张图像。NXP 的产品信息同时列出 Ara SDK 和 eIQ Toolkit，但这不能证明它们与独立的 i.MX 95 Neutron 路径之间的产物可以互换。16 GB M.2 模块处于 Active 状态，USB 选项仍为预生产。NXP 将 eTOPS 中的「e」定义为「equivalent」，即等效，而非「effective」，即有效；这不是其他厂商的 dense-INT8 TOPS 指标，不能直接比较。

STMicroelectronics

STM32N6x7 设备，包括 STM32N657 和 STM32N647，将 600-GOPS Neural-ART 加速器带入 MCU 级产品；通用型 N6x5 产品线不含该加速器。STM32Cube AI Studio和 ST Edge AI Core 会分析并优化导入模型，STM32 AI Model Zoo Services则提供部署、优化、基准测试和示例工作流。

当前目标检测概览记录了 Tiny YOLOv2、YOLOv5u、YOLOv8、YOLO11、YOLO26 和 ST-YOLOX，以及分类、姿态和分割服务。这与 200-TOPS PCIe 卡不属于同一性能级别。它的价值在于摄像头接入、推理和控制都能在严格的嵌入式功耗和内存范围内完成。

Renesas

Renesas RZ/V 处理器集成 DRP-AI 加速器。软件从 DRP-AI Translator 和 DRP-AI TVM 演进到由 EdgeCortix MERA 技术驱动的 RUHMI。开源的 RZ/V DRP-AI TVM 仓库和 RZ/V2H 验证列表列出 YOLOv5、YOLOv8、YOLO11 和 YOLO26 的 n/s/m 变体、YOLOX、姿态和分割网络，以及分类模型。

Renesas 是可信的机器人和工业目标，但为了保证可复现性，仍需记录具体开发板、DRP-AI 代际、转换器版本和 CPU 侧后处理。

智能传感器和摄像头优先的处理器

Sony IMX500

Sony IMX500 不是普通应用处理器。它将图像传感和 AI 处理堆叠起来，让推理可在传感器内完成，从而减少离开摄像头的图像数据量。Raspberry Pi AI Camera 让这种架构更易于使用。

官方 Raspberry Pi IMX500 模型仓库发布了打包好的 YOLOv8n、YOLO11n、EfficientDet Lite0、NanoDet+ 和 SSD MobileNetV2 FPN Lite 模型。AI Camera 文档说明了转换、打包和传感器端后处理。部署单元是 RPK 包，而不是通用 ONNX 文件；传感器内存和算子限制是关键设计边界。Raspberry Pi 的产品页面称该摄像头至少会生产至 2028 年 1 月。

Ambarella

Ambarella 的 CVflow 处理器广泛应用于摄像头、无人机和汽车视觉。当前产品系列包括摄像头用 CV72/CV75、高性能视觉系统用 CV5/CV52，以及汽车用 CV3-AD。Cooper 开发者平台和 CVflow 编译/运行时流程构成公开命名的软件栈。

公开开发者模型库列出 YOLOX、RTMDet、DeepLabV3+、TopFormer、OWL-ViT 和多模态模型。不过，详细编译器文档和下载仍面向合作伙伴。因此，Ambarella 集成应从厂商或 OEM 合作关系开始，不能假设有公开 pip 包可用。

Synaptics Astra

Synaptics 有三个相关目标。SL1600/SL1680 Astra 系统使用 SyNAP toolkit，将源模型和 YAML 描述转换为 model.synap 包。较新的 SL2611/13/15/17/19 设备使用基于 IREE/MLIR 的 Torq 平台，产物为 .vmfb。SR100 系列则是采用 Cortex-M55 和 Ethos-U55、使用独立 SDK 的 MCU 系列。这些产物和 API 不能互换。

官方 YOLO 基准教程提供了相当具体的流程：将 YOLOv8 导出到 TFLite，在 SyNAP 中进行非对称 UINT8 校准，为 SL1680 编译，再运行 synap_cli 和目标检测应用。教程证明 SL1680 支持 YOLOv8n/v8s，并说明 SyNAP 支持至 YOLO11。另一个 SL261x 目标检测指南通过 Torq .vmfb 运行 YOLOv8。这些是特定目标的官方示例，并不表示三个系列的所有 YOLO 计算图都受支持。

MediaTek Genio

MediaTek 值得单独介绍，因为当前 IoT AI Hub现在公开了硬件/软件矩阵、模型包和基准测试表，补上了早期市场调研无法核验的信息。Genio 360/360P/420/520/720 使用 NeuroPilot 8 和 MDLA 5.3；Genio 510/700 使用 NP6 和 MDLA 3.0；Genio 1200 使用 NP6 和 MDLA 2.0。MediaTek 指出，每款 SoC 的 NeuroPilot 和 MDLA 代际、算子集合、编译器和运行时版本在产品生命周期内相互绑定。

分析型 AI 路径以 TFLite 为中心：

PyTorch model
    -> NeuroPilot Converter and representative calibration
    -> quantized .tflite
    -> version-matched ncc-tflite compiler
    -> chip-generation-specific .dla
    -> Neuron Runtime on MDLA

较新的 Genio 产品还支持在线 LiteRT delegate，并可在受支持的操作系统上使用 ONNX Runtime CPU/NPU 路径。这些模式不同于离线 .dla。软件架构指南和资源矩阵明确说明了这种区别。

官方分析型模型表发布了 YOLOv5s 和 YOLOv8s 的基准条目，以及多个 MDLA 代际的转换指南。由于 AGPL-3.0 限制，该页面明确不分发预转换的 YOLO 产物。其 Quant8、640 x 640 离线测量在 Genio 720 上分别为 5.35 ms 和 8.04 ms。YOLOv8s 模型页面发布了输入/输出张量、按后端区分的耗时，以及有关 MediaTek 自定义算子的警告。这些是厂商基准，不代表端到端摄像头结果。

获取权限是限制因素。公开的 Yocto 文档很详细，但当前 NP8 一体化转换器/编译器包和大量 Android 资料标为 NDA 或直客资源。普通开发者账号与 MediaTek Online 客户账号的权限不同。因此，LibreYOLO 应将 Genio 视为技术证据充分、但可复现的自带模型编译集成依赖合作关系的平台。

面向中国市场的边缘 AI 生态

一些性能突出、价格低廉且易获取的视觉平台，在英文市场清单中并不常见。

D-Robotics 和源自 Horizon 的 BPU 平台

D-Robotics 围绕 RDK 开发板生态维护 BPU 加速器，应用于 RDK X3、X5、Ultra 和较新的 S100 系列产品。其 RDK Model Zoo当前 rdk_x5 分支记录了 RDK X5 上 YOLOv5/v5u、YOLOv8/9/10/11/12/13/26、YOLOE、YOLO-World，以及检测、分割、姿态、分类、OCR 和 CLIP 路径。X3 使用独立分支；当前 S 系列交付位于主模型库的 rdk_s 分支；旧版 rdk_model_zoo_s 仓库则保留历史演示。因此，现代 X5 列表不能证明所有模型都在 X3、Ultra 或 S100 上通过验证。

OpenExplorer/Algorithm Toolchain 可导入 ONNX 或 Caffe 进行 PTQ，也支持面向 PyTorch 的 QAT 流程。部署因平台而异：当前 RDK X5 通过 libdnn 下的 hbm_runtime 使用 .bin；当前主线 rdk_s 流程通过 libhbucp 下同名的 hbm_runtime API 使用 .hbm；X3 仍保留较旧的分支和推理接口。旧 rdk_model_zoo_s 资料也描述过历史 .bin 和 .hbm 路径，因此这些产物必须与对应分支和工具链配套。不支持的算子可能回退至 CPU。公开示例值得参考，但 RDK OS、开发板固件、工具链和模型二进制文件之间的版本配对仍是兼容性契约的一部分。

AXERA

AXERA AX650/AX630/AX620 系列常见于 Sipeed MaixCAM 等紧凑型 AI 摄像头和开发板。Pulsar2 导入 ONNX，执行校准和精度分析并生成 .axmodel；AXEngine 负责运行该产物。

AXERA 官方示例覆盖 YOLOv5/6/7/8/9/10/11/13/26、YOLOX 和 YOLO-World，任务和芯片支持因平台而异。在受支持的目标上，当前 YOLO26 示例包括检测、姿态、分割和 OBB。Pulsar2 转换示例展现了实际工作：精确的张量名称、输出切分、布局转换、校准归档和目标硬件配置。

SOPHGO

SOPHGO 的 TPU-MLIR 是较适合独立集成的编译器技术栈之一，因为编译器本身为开源软件。它可导入 ONNX、PyTorch、TFLite 和 Caffe，降低并量化计算图，为 BM 目标生成 .bmodel，为 CV18xx 硬件生成 .cvimodel。

TPU-MLIR 项目按目标支持 FP32、BF16、FP16 和 INT8 流程。SOPHON 演示集合列出 YOLOv3/4/5/7/8/9/10/11/12/26、YOLOX、PP-YOLOE、YOLO-World、OBB/分割变体、SSD、CenterNet、RetinaFace、SAM/SAM2 和 OCR。与往常一样，在 BM1684X 上运行的演示不能证明相同产物也适用于 BM1688 或 CV18xx。

Huawei Ascend

Huawei 的边缘推理产品包括 Atlas 200I 和 300I 产品中的 Ascend 310/310P/310B 芯片。CANN 提供 ATC 编译器、AscendCL 运行时和芯片专用算子内核；ATC 将 ONNX 等源表示转换为离线 .om 模型。

当前 Atlas 200I DK A2 文档和 CANN 示例提供适用于 Ascend 310B 的 YOLOv5 .om 路径。较早且范围更广的 Ascend ModelZoo包含 YOLOv2/3/4/5、YOLOX、YOLOR、SSD、RetinaNet、Mask R-CNN、姿态和分割模型，但不应将其描述成每个条目都已在 310B 上重新验证。CANN、内核、固件和 SoC 必须匹配。面向 Ascend310P 的 .om 不是通用 Ascend 产物。

Cambricon

Cambricon MLU 加速器使用 Neuware 和 MagicMind 推理引擎。公开的 MagicMind Cloud 仓库固定于 MagicMind 1.7 和 MLU370-X4/S4 矩阵；它提供的是历史兼容性证据，不代表当前 SDK 或 MLU270 的验证情况。仓库记录了 PyTorch、ONNX、Caffe 和 Paddle 路径；1.7 版移除了 TensorFlow 框架支持，尽管仍有历史 TensorFlow 示例。Cambricon 当前的第 3 系列开发者门户列出后续整体 SDK 版本，因此不能把公开示例仓库和当前商业技术栈说成同一版本。

官方 MagicMind Cloud 模型仓库发布了相当直接的 MLU370-X4/S4 矩阵，列有 YOLOv3、Tiny-YOLOv3、YOLOv4、YOLOv5、YOLOv7、YOLOv8、PP-YOLOE、SSD、RetinaFace、RetinaNet、Mask R-CNN、DeepLab 和 UNet 示例，也说明是否提供 C++ 或 Python 示例。证据充分；主要障碍是通过 Cambricon 渠道获取 SDK 和容器。

Canaan/Kendryte

Kendryte 当前的 K230/K230D 和旧款 K210/K510 KPU 芯片在低成本开发板和智能摄像头领域很重要。nncase 编译器可导入 ONNX 或 TFLite，使用校准数据进行定点转换，在主机上模拟结果，并生成 .kmodel。

官方 K230 nncase 开发指南介绍 YOLOv5s 的编译、模拟和运行流程。独立的 AI 演示目录包含 YOLOv8n 检测、分割和姿态产物；当前 CanMV 更新日志增加了优化后的 YOLOv8/11/26 分类、检测、分割、OBB 和姿态示例。数据手册的 YOLOv5s 结果是实际公布的基准；编译器与二进制 KPU 插件版本必须和开发板 SDK 匹配。

Allwinner

Allwinner V853 将面向摄像头的媒体硬件与 1-TOPS Vivante NPU 集成在一起。官方英文 NPU 指南说明如何通过 viplite 导入 Acuity/Pegasus、量化、验证和部署。Allwinner 自己的模型页面及 YOLOv5 指南列出 YOLOv2/3/4/4-tiny/5/5s、RetinaNet、MobileNet、ResNet 和人脸/人员网络。

这是真实的计算机视觉支持，但仍绑定较旧的 Tina Linux/Vivante 工具链，SDK 下载需要账号。市场图谱应纳入该平台，同时明确这些限制。

常被忽略的韩国、台湾和中国平台

英文资料经常从 Rockchip 直接跳到 NVIDIA，遗漏另一批真实且有文档支持的芯片。其中一些生态当前 YOLO 矩阵的覆盖范围甚至超过知名度更高的西方初创公司。

Mobilint

韩国加速器厂商 Mobilint 销售低功耗 REGULUS 和高吞吐量 ARIES MLA100。其 qb SDK 接受 PyTorch、TensorFlow、TFLite、ONNX 和 Keras 相关输入，量化至 INT8 并生成编译产物 .mxq。公开的视觉矩阵列出 YOLOv3/v5/v7/v8/v9/v10/11/12/26 检测，以及 YOLO 分割、姿态和 OBB 变体。ARIES 产品页甚至发布了 YOLO11s 和 YOLO26m 的具体结果。这是有力的集成证据，但 SDK/硬件仍需商业渠道获取。

Sunplus

Sunplus SP7350/C3V 使用源自 Vivante 的 NPU 技术栈，但其打包方式与 Allwinner 或旧版 Amlogic 不同。公开流程包括 Acuity 转换、NPU Docker 环境、SNNF 运行时和 .nb 输出。官方自定义 YOLOv8 指南讲解了转换和部署，而不只是宣称支持某个框架。采用相关 IP 不代表其 .nb 能移植到其他 Vivante SoC。

ESWIN Computing

ESWIN 的 RISC-V 系列包括 EIC7700/EIC7700X 和双晶粒 EIC7702/EIC7702X；采用 EIC7700 的 Milk-V Megrez 等开发板已出货。ENNP 包括 EsQuant、当前的 EsAAC 编译器、黄金数据生成、模拟和 ESSDK 运行时，编译产物为 .model；较旧 ENNP 资料使用 ennc-compile 名称。当前 EsAAC 页面记录了 ONNX 输入，因此其他框架需先导出或转换为受支持的中间表示。Milk-V 托管的 ENNP 概览和 YOLOv3 教程证明存在公开端到端路径，但没有广泛的当前模型/精度矩阵。

Nuvoton M55M1

Nuvoton M55M1 属于 MCU 级设计，采用 Cortex-M55 加 Ethos-U55-256，而非 Linux 应用处理器。NuEdgeWise/NuML 和 Arm Vela 负责准备量化 TFLite Micro 模型。公开的 NuEdgeWise 仓库列出 YOLOv8-nano、YOLOX-nano、YOLO Fastest v1.1、SSD-MobileNet FPNLite 和多个分类器。这些小型网络示例体现了设备的内存/功耗等级，并不证明其支持标准 640 像素 YOLO 变体。

Rebellions 和 FuriosaAI

Rebellions 的 ATOM 系列使用 RBLN SDK 和编译产物 .rbln。其官方支持版本说明列出 YOLOv3 tiny/full/SPP、YOLOv5 n 至 x、YOLOv6 n 至 l、YOLOv7 变体和 YOLOv8 n 至 x。当前加速卡支持矩阵将 ATOM CA02 和 ATOM+ CA12 标为 EoL，ATOM+ CA22 和 ATOM-Max CA25 标为 Active。ATOM-Lite CA21 虽有产品页面，却未出现在该 SDK 矩阵中，其当前工具链状态不明确。文档公开，但编译器 wheel 需要 Rebellions Portal 凭据。

FuriosaAI 必须按代际区分。Warboy 是较旧的计算机视觉加速器，使用 INT8 .enf 产物，官方模型库包含 SSD、YOLOv5M/L 和 YOLOv7-w6-pose。RNGD 使用完全不同的 .fxb 技术栈，主要面向 LLM/VLM 工作负载。Furiosa 当前路线图记录了 YOLOv8m 视觉支持于 2024 年第四季度完成，但当前公开支持模型和性能资料仍以 LLM/VLM 为主，未提供详细的 YOLOv8m 精度/性能矩阵。这是已发布代际的证据，不能据此声称 Warboy 兼容。

Realtek、Telechips、T-Head 和 SigmaStar

以下四个平台真实存在，但其自带模型部署路径范围较窄、版本较旧或获取受限：

HiSilicon 智能视觉不等于 Huawei Ascend

HiSilicon Hi3516CV610/DV500、Hi3519DV500 和 Hi3403V100 摄像头 SoC 通过 NNN/SVP-NNN 运行时提供 ATC 到 .om 的工作流。官方 HiSpark 模型库针对特定目标的矩阵列出 YOLOv3/4/5/6/7/8/9/10/11、YOLO11 分割/姿态、YOLOv8 OBB/World/分割、OCR、深度和 TinySAM，尤其涉及 Hi3403 和 Hi3591P。它并未证明以上所有智能视觉 SoC 都能运行每一个条目。部分条目属于路线图，因此必须区分已发布示例和计划支持；仓库也声明其提供的 ModelZoo 模型仅限非商业用途。ATC/.om 名称相同，并不能证明它与基于 CANN 的 Ascend 产品线在产物或运行时方面兼容。

新兴和专业加速器公司

MemryX

MemryX MX3 模块采用数据流架构，可组合多颗芯片。Neural Compiler接受 ONNX、TensorFlow Lite、Keras 和 TensorFlow 模型，生成由加速器运行时使用的 DFP 包。运行时 API支持多模型和流式处理流水线。

MemryX 文档和示例包含检测、分割和姿态任务的优化 YOLO 预处理/后处理。SDK 发行说明明确列出 YOLOv10、YOLO11 和 YOLO26 支持。公开资料在技术上很有用，但缺少类似 Axelera 那种简单的模型/精度/设备表。

Kneron

Kneron KL520/KL530/KL630/KL720/KL730 产品涵盖小型 USB 和嵌入式加速器。Kneron PLUS 面向应用运行时；当前 Model Toolchain 0.33.1 记录了适用于这些目标的转换、量化、评估、模拟和 .nef 编译。KL830 出现在部分 PLUS 运行时 API中，但不在当前编译器目标列表中；未经厂商确认，不能把通用 .nef 编译声明应用于 KL830。

官方 YOLO 示例以 Tiny-YOLOv3 演示流程，其他 Kneron 资料涉及 YOLOv5 训练和部署。证据可信，但覆盖范围不如 Hailo、Axelera、Rockchip 或 DEEPX 的现代 YOLO 矩阵广。

SiMa.ai

SiMa.ai 的 MLSoC 和量产 Modalix 50-TOPS 平台使用 Palette 软件环境。ModelSDK、MLA 编译器和 ModelExecutor 覆盖导入、量化、编译、性能分析和执行。根据工作负载与产品不同，工具支持 INT8、INT16 和 BF16 流程。

公司发行说明列出了已验证的 YOLOv7、YOLOv8 检测/姿态/分割、YOLOX 和 YOLOX 分割、DETR、Mask R-CNN 和 EfficientDet 流水线。当前有一个限制不应隐瞒：Palette SDK 2.1 说明指出，由于 Python/PT2E 量化回归问题，QAT 不可用。文档中的绕行办法是在 SDK 2.0 中生成带标注的 ONNX，再使用 2.1 编译。获取和采购仍以企业客户为主。

部署边界也有文档说明：ModelSDK 编译流程生成编译后的 .tar.gz，还可生成可执行 ELF；MPK Tool会打包可部署的 .mpk。这些输出与 MLSoC/Modalix 目标及 Palette 版本绑定。

EdgeCortix

SAKURA-II 是面向视觉和生成式 AI 的 60-TOPS 宣传型加速器，通过 MERA 软件框架编译。EdgeCortix 也向 Renesas 较新的 RUHMI 流程提供 MERA 技术。

SAKURA-II 产品资料说明了硬件和编译器，M.2/PCIe 硬件通过试用或订购咨询提供。没有找到足够具体且当前有效的公开 YOLO 兼容矩阵。这对采购很有参考价值：确定硬件前，应要求厂商验证目标模型。

BrainChip

BrainChip 的 Akida 是神经形态事件域处理器，不是传统的稠密张量 NPU。MetaTF 环境由可安装 Python 包构成，可用于模型创建、低比特量化、转换、模拟和硬件执行。BrainChip 目前销售已出货的 AKD1500 M.2 协处理器，也有旧款 AKD1000 硬件和 Akida 2 IP。

当前 Akida 2 模型卡列出 AkidaNet0.5 YOLOv2 检测器、CenterNet、AkidaUNet 和人脸识别网络。其他支持资料包括 FOMO 和事件型工作负载。Akida 支持特别低比特的权重和激活值，但成功部署可能需要结合架构特点进行转换，不能将它当作另一个通用 INT8 ONNX 目标。除非映射/适配报告明确验证，否则不能把 AKD1000 或 Akida 2 模型库的结果归到 AKD1500 上。

Blaize

Blaize 销售基于 P1600 的 Pathfinder 和 Xplorer 产品，通过 Picasso SDK、NetDeploy 和 AI Studio 提供软件路径。产品页面明确面向视觉和边缘 AI，但没有当前公开的逐模型兼容矩阵。

因此，本指南将 Blaize 标为商业/受限获取，而不采用社区说法来填补空白。开始前应要求厂商提供针对目标模型的编译和精度报告。

TinyML 和端侧视觉

Arm Ethos-U 和 Alif

Arm 将 Ethos-U55、U65 和 U85 NPU IP 授权给芯片公司。Vela 编译器接收量化 LiteRT/TFLite 计算图，并将受支持的子图改写为 Ethos-U 自定义算子。不受支持的算子可能留在 CPU 上运行，因此「应用可以运行」和「整个网络都运行在 NPU 上」是两种不同的声明。

实际产品包括 Alif Ensemble E7 中的 Ethos-U55、NXP i.MX 93 中的 Ethos-U65，以及较新系统中的 Ethos-U85。Alif 的 E7 AI/ML AppKit记录了两个 ML 加速器，并演示 E7 的 TFLite 到 Vela 路径；Ensemble E8结合一个 Ethos-U85 和两个 Ethos-U55 NPU。Alif 还发布了系列级 INT8 YOLO-Fastest 人脸检测基准，在 Cortex-M55 加 Ethos-U55 上以 192 x 192 运行，但没有广泛的现代 YOLO 目标级矩阵。这类内存受限系统适合小型分类和检测网络，不能仅因为模型可以表示为 TFLite，就推断任意 640 像素检测器都适用。

Infineon PSOC Edge、Himax WiseEye2 和 Analog Devices MAX7800x

Infineon PSOC Edge E83和 E84 系列采用 Cortex-M55 加 Ethos-U55，并在低功耗 M33 侧增加独立 NNLite 模块。E84 架构手册记录了 8 位权重、8 或 16 位激活值，以及 Vela 流程：受支持算子转成 NPU 命令流，不受支持的工作留在 CPU 上。DEEPCRAFT Model Converter接受 TFLite、Keras 和 PyTorch 路径；架构资料将 MobileNetV1/V2 列为代表性内核，而非目标基准。E84 AI Kit带有摄像头并使用 ModusToolbox，但目前公开资料尚未提供具名 YOLO 兼容矩阵。

Himax 的 HX6538 WiseEye2也将 Cortex-M55 和 Ethos-U55 结合起来，用于常开视觉。对于这一功耗级别，其公开软件资料相当具体：官方 Grove Vision AI Module V2 示例包含 YOLOv8n 目标检测、姿态和性别分类、YOLO11n 检测、人脸网格和 PeopleNet。统一流程使用 TFLite Micro 和 Vela，必要时再回退到 CMSIS-NN 和参考内核。这些都是有意设计的小型模型和分辨率，并不证明常规服务器规模的 YOLO 计算图也能运行。

Analog Devices 通过 MAX78000/MAX78002 CNN 加速器采用另一种方案。公开的 ai8x-synthesis工具会量化已训练网络并生成目标专用 C 代码、权重和加速器配置，而不是可移植的 ONNX 运行时包。一手证据包括人脸识别、ADI 模型库中的 TinierSSD 二维码检测（见模型库），以及图像分类器。这些设备适用于端侧视觉，但未找到当前官方现代 YOLO 矩阵。

GreenWaves GAP9

GAP9 将 RISC-V 计算与 NE16 神经引擎结合起来。NNTool 导入并量化网络，AutoTiler 和 GAP SDK 则生成可部署代码。公开的 GAP9 神经网络目录包含 MobileNet、EfficientNet、ResNet、MobileNet SSD、人脸和识别应用。GreenWaves 还发布了一个 YOLOX 行人检测项目，并提供精度和模拟结果。

这是透明度较高的 TinyML 证据，但完整 SDK 只提供给合格客户，且这些模型远小于主流的 640 x 640 YOLO 变体。

Lattice sensAI

Lattice FPGA 的 sensAI 工具链将神经网络编译为 FPGA 配置、权重和运行时资源。目标硬件可能是 ECP5、CrossLink-NX、CertusPro-NX、Avant-E 或 Avant-X，具体取决于编译器/IP 模式和开发板。输出与所选 FPGA、加速器模式、内存布局和 bitstream 绑定，不是可移植的运行时模型。

当前 Neural Network Compiler 手册包含很直接的拓扑表：ECP5 支持 YOLOv1；优化/高级 CrossLink-NX 和 CertusPro-NX 模式列有 YOLOv5 和 YOLOv8；YOLO11 仅支持 Advanced 模式 IP。表中也列有 SSD、MobileNetV2-SSD、ResNet、ENet、SqueezeDet 等视觉网络，并按 FPGA 系列显示不支持的单元格。Advanced CNN Accelerator面向 Avant-E/Avant-X/CertusPro-NX，是商业 IP。这是编译器表中的证据，不代表同一 bitstream 能同时支持所有列出的网络拓扑。

Microchip VectorBlox

Microchip 公开的 VectorBlox SDK 3.1可为 PolarFire SoC FPGA 中可配置的 CoreVectorBlox IP 预处理并编译完全量化的 INT8 TFLite 网络。tflite_preprocess 和 vnnx_compile 会生成 .vnnx、.hex 和 .ucomp 部署产物；仓库还提供模拟器和目标端 C 驱动。上游 TensorFlow、ONNX 和 OpenVINO 计算图仍需走文档化的 TFLite/INT8 准备流程。

当前教程矩阵涵盖 YOLOv5n、YOLOv8n 检测、分类、OBB、姿态和分割，YOLOv9t、稀疏/压缩 YOLO 变体、MobileNet、EfficientNet-Lite0、ResNet18、MiDaS、FFNet 和 QuickSRNet。C 后处理指南另外列出 YOLOv2/3/4/5 及 Ultralytics 检测、姿态和 OBB 解码器。SDK 3.1 当前支持 PolarFire SoC Video Kit，明确不支持非 SoC PolarFire Video Kit，因此不能把旧开发板演示误当成当前目标契约。

SDK 可在 GitHub 公开下载，但采用针对 Microchip 的许可，限制软件及衍生品只能用于 Microchip 产品。Microchip 提供免费但需申请的 Libero Silver 和 CoreVectorBlox 许可。部署仍受 FPGA 系统契约约束：加速器配置、bitstream、固件、SDK 生成的网络数据和内存布局必须一致。VectorBlox 编译成功不会让模型变成可复制到任意 PolarFire 设计中的二进制文件。

Syntiant

Syntiant NDP200 面向常开视觉、音频和传感器推理，功耗范围低于常规 Linux SoC。当前硬件表将 NDP200 列为量产，NDP250 列为送样。NDP200 产品简报记录了低于 1 mW 的 CNN、RNN 和全连接网络支持；NDP250 公告则称其常开图像识别低于 30 mW。不能将「亚毫瓦」概括用于这两款芯片。

公开资料不能证明广泛兼容 YOLO，因此应通过厂商支持的模型评估来测试小型常开分类器和检测器，而不是假设任意 ONNX 导出都能使用。

Google Coral：两种互不相关的代际

旧款 Edge TPU 产品使用 Edge TPU Compiler、libedgetpu 和 PyCoral，配合完全 INT8 量化的 TFLite 模型。其主要 Edge TPU和 PyCoral仓库已归档。这确实带来维护风险，但不等于正式的硬件 EOL 通知。

Google 还在维护一个独立且活跃的开源 Coral NPU：一种可集成到低功耗 SoC 的 RISC-V 加速器 IP。公开项目目前提供 RTL、硬件模拟、工具链和 ELF 示例。它不是 Edge TPU 的 USB/M.2 直接替代品，也没有公布当前 YOLO 部署矩阵。

相邻 GPU、客户端 NPU 和可重构计算的陷阱

NVIDIA、AMD、Intel 和 Apple 经常出现在 NPU 搜索结果中，但它们并未提供同一种可互换的加速器。

**NVIDIA Jetson：**Jetson Orin 结合 CUDA GPU 和专用 DLA 核心。TensorRT 可为 DLA 构建序列化引擎，但只有显式启用 GPU 回退时，不受支持的层才会转到 GPU。当前 DeepStream YOLO 表涵盖 YOLOv4/v7/v8/v9/11，但大多数条目针对 GPU；其明确记录的 ONNX DLA 条目是 INT8 YOLOv8s。NVIDIA DLA 限制说明了算子限制。Thor 又是另一种情况：NVIDIA 的 DriveOS 迁移指南称 Thor 移除了 DLA 核心，改用 GPU 调度灵活性。因此，「在 Jetson 上运行」并不能说明使用了哪种加速器。

**AMD Vitis AI：**较早的 Kria/DPU 代际将 .xmodel 计算图编译后通过 VART 执行。当前 Vitis AI 6.2已面向两种独立的 Versal AI Edge 路径 GA：Gen1在 VEK280/VE2802 上使用 ONNX、AMD Quark 和绑定目标的 snapshot/子图流程；Gen2在 VEK385 上有独立的编译和运行时契约。Gen1 发布了 YOLOv5、YOLOv7、YOLOv8 和 YOLOX 示例。Ryzen AI 是第四套独立的客户端 NPU 技术栈。不能仅因它们都带有 Vitis 或 AMD 名称，就在旧 DPU、Versal Gen1、Versal Gen2 和 Ryzen AI 之间迁移产物或验证结果。

**Intel OpenVINO：**OpenVINO 可通过同一 API 面向 CPU、GPU 和 Core Ultra NPU。Intel NPU 插件文档说明受支持的 NPU 代际，已验证模型矩阵则按设备列出结果。除非矩阵明确说明 NPU 验证，否则 YOLO notebook 只能证明应用流程，不能证明 NPU 验证。算子、形状、精度和已安装 NPU 驱动仍决定完整计算图能否运行于 NPU。OpenVINO IR（.xml 加 .bin）是可复用的源级 IR；编译模型缓存则取决于设备和软件。

Apple Core ML：coremltools 可将模型转换为 .mlpackage，再由 Xcode 编译成 .mlmodelc。Core ML 可在 CPU、GPU 和 Apple Neural Engine 之间调度，但有意抽象了具体分配情况。Apple 因而是优秀的部署平台；除非性能分析证据能确认，否则不宜声称「整个 YOLO 计算图都运行在 NPU 上」。

NPU 芯片厂商背后的 IP 公司

有些公司不直接销售开发板或封装加速器，而是将 NPU 设计授权给 SoC 厂商。同一架构可能出现在不同芯片品牌下，但最终 SDK 和产物仍可能由被授权方定制。

Imagination 说明了为什么架构名称旁边还应列出获取方式和生命周期。其 Open Access 计划提供三种经硅片验证的 Series3NX 配置，无需预付 IP 许可费，但需经过公司评估，并支付支持/维护费用及量产版税。Neural Compute SDK提供编译、优化、量化和运行时工具；官方 Baidu PaddlePaddle 合作列出了 PP-YOLOE 检测、EfficientNet 分类和 HRNet 分割示例。这些示例不能验证每种 Series3NX 或 Series4 配置；目前各个 Series4 产品页面都标为不可获取，因此除非销售渠道确认，否则应将 Series4 视为历史产品。

这一层解释了架构之间为何相似，却不会带来产物可移植性。采用相关 Vivante 或 Ethos IP 的两款 SoC，仍可能有不同内存映射、驱动、编译器版本、算子集合和厂商运行时。

实际部署的产物：格式绑定表

编译流程中的最后一个文件，是 ONNX 表面可移植性终结的地方。名称和扩展名会变化，但实践规则稳定：保留原始模型和校准数据，因为原生产物通常无法迁移到其他 NPU 代际，也不一定能用另一个 SDK 版本可靠重建。

这张表不只是扩展名速查表。编译器版本、目标标识、驱动、固件和 BSP 都属于模型可复现身份的一部分。未来 LibreYOLO 导出器应将这些信息写入每个产物旁的机器可读清单。

工具获取和生命周期信号

硬件是否容易购买，与编译器是否能获取，是两回事。开发板可能容易买到，但当前编译器需要客户协议；SDK 也可能公开，却面向难以采购的芯片。以下是一手资料中的具体信号，不是统一的生命周期排名。

为什么 TOPS 不是购买指南

在同一厂商和架构内，峰值 TOPS 可能有参考价值；跨厂商比较通常无效，除非以下各项都相同：

• 数值精度，包括 INT8、INT4、FP16 或混合模式
• 一次乘加按一次还是两次运算计数
• 稠密计算还是结构化稀疏计算
• 输入分辨率、批大小和模型计算图
• 量化后的精度
• 仅 NPU 延迟还是完整应用流水线延迟
• 内存传输和主机回退
• 温度状态，以及持续运行而非瞬时突发的性能

检测器是一条流水线：图像采集、缩放/letterbox、归一化、设备传输、神经网络推理、解码、NMS、坐标缩放和应用逻辑。厂商经常只公布中间的神经网络推理部分。MLPerf Inference Edge很有价值，因为它定义了场景、质量目标和系统级测量规则，而不是孤立比较宣传数据。

YOLO 部署至少应记录以下基准信息：

exact checkpoint + checksum
source and compiled model format
compiler, runtime, driver and firmware versions
target board and clock/power mode
input resolution and batch
precision and calibration dataset
accuracy before and after compilation
warmup and sample count
preprocess, inference and postprocess latency
power measurement boundary

缺少这些字段时，两组 FPS 往往衡量的不是同一件事。

如何为计算机视觉选择 NPU

按以下顺序选择，不要只看产品页上最大的数字。

1. 验证计算图兼容性。 编译准确导出的模型，而不是名字相似的模型库检查点。
2. 测量精度。 在校准和量化后，用真实任务数据集验证编译产物。
3. 端到端测量。 纳入输入转换、数据传输、解码和 NMS。
4. 检查软件获取方式。 确认编译器是公开、需要注册，还是只在商业协议后提供。
5. 固定版本矩阵。 记录编译器、运行时、驱动、固件和目标标识。
6. 核实操作系统支持。 Android、Debian、Yocto、Buildroot、RTOS 和 Windows 支持并不等价。
7. 检查供货和生命周期。 如果模块、驱动或长期支持情况不确定，技术上很出色的芯片也可能不适合生产。
8. 最后比较成本、功耗和性能。 只有两个目标上的同一模型都能正确运行后，这些测量才有意义。

按使用场景选择起点

这张表是调研候选清单，不是性能排名。采购渠道、地区供货情况和具体模型都可能改变选型顺序。

这对 LibreYOLO 意味着什么

可扩展的设计不是构建数十个互不相关的导出器，而是建立统一、严格的交换契约，以及小型厂商编译器和运行时适配器：

LibreYOLO model
    -> deterministic static ONNX
    -> VendorCompiler.compile(model, target, calibration, precision)
    -> native artifact + manifest
    -> VendorRuntime.load() / infer()
    -> shared task-specific decode and Results objects

每个原生产物旁都应有清单，记录：

• 厂商、芯片目标和开发板目标
• 编译器、运行时、驱动和固件版本
• 源检查点和 ONNX 校验和
• 输入名称、形状、布局、色彩空间、归一化和数据类型
• 量化精度、可获取时的 scale，以及校准数据哈希
• 输出张量名称、形状和语义
• 检测任务、类别名称，以及解码/NMS 在芯片上还是主机上执行
• 数值一致性和任务精度结果

LibreYOLO 已提供可移植的 ONNX 导出、量化工具、直接但有意限制范围的 RKNN 导出，以及如实说明外部编译器要求的 Hailo 流程。按本指南采用的标准，Amlogic ADLA 是很适合下一步集成的候选：工具包公开，模型覆盖与 LibreYOLO 高度重叠，而且可明确区分旧版 A311D 路径。

Amlogic 之后的优先级应取决于用户硬件和运行精度验证的能力，而不应只看编译器是否可用。DEEPX、Sony IMX500、D-Robotics、AXERA、SOPHGO 和 Qualcomm 在技术上很有吸引力；如果工业合作伙伴能提供开发板和长期 CI 访问权限，TI、NXP、ST 和 Renesas 也会尤其有价值。

候选清单：芯片真实存在，但没有公开的集成契约

完全排除一家公司会让市场图谱产生误导；把它纳入「已支持」则可能更糟。这些厂商已经销售、送样或宣布了相关芯片，但公开证据还不能证明它们提供可复现的当前编译器、产物和具名模型路径，因而不适合作为 LibreYOLO 后端。

这份候选清单有意以证据为依据。厂商若发布当前工具链或评估路径、目标专用产物契约，以及至少一个具名模型的端到端配方，就可以进入可部署平台表格。

本文有意未作的声明

本文没有说每个具名模型都能从任意上游仓库直接运行。厂商模型库中的模型经常经过修改、在不同输出节点切分，或搭配自定义后处理。

以下说法也不能单独构成支持声明：

• 编译器可以导入 ONNX。
• 芯片宣传带有 Android NNAPI 驱动。
• 经销商说开发板「兼容 YOLO」。
• 某社区仓库可以运行某个模型的一个分支。
• 模型编译没有报错。
• 厂商报告了 NPU 单独运行的 FPS，却没有精度结果。

Google Tensor 手机加速器和许多仅面向 OEM 的定制 ASIC 也真实存在，但 Google 并未开放 Tensor，无法像上文平台那样作为通用自助编译目标。公司存在、NPU 框图或 Android 加速功能，都不足以凭空作出 LibreYOLO 集成声明。

同样，Google TPU、AWS Inferentia/Trainium、Microsoft Maia 和仅用于数据中心的 AI 卡等云端加速器不在本文范围内。本指南关注计算机视觉开发者实际可能在边缘设备上部署的硬件。

模型许可是另一层问题。芯片厂商发布 YOLO 转换配方，并不会授予使用或再分发上游权重、训练代码或编译衍生物的权利。硬件支持、SDK 许可和模型许可都必须针对预期产品分别核查。

研究方法和更正

针对每家公司，研究都查找了四类一手资料：

1. 说明芯片的当前产品页面或数据手册。
2. 解释实际部署路径的编译器和运行时文档。
3. 列出视觉模型名称的模型库、兼容性表或端到端教程。
4. 说明开发者能否实际获取工具的生命周期或访问信号。

厂商的一手 GitHub 组织视为厂商来源。如果芯片公司自己没有发布相同资料，则会将开发板厂商文档标为生态证据。对比表排除了第三方性能声明。

随后，草稿经过了独立的厂商分组和跨表复核。这些检查重新验证了目标范围、产物名称、精度、模型与后处理证据、已发布与出货状态、生命周期标签、基准测试分母和所有实体数量。如果两个一手页面互相矛盾，本文会展示冲突，而不是暗中选取更方便的数据。

这个市场变化很快。如果你在其中一家厂商工作，发现芯片、SDK、模型清单或访问状态有误，请向 LibreYOLO 提供准确的公开文档 URL 和版本。应以一手证据支持的更正替换本文；没有文档的营销说法不应加入。

常见问题

有多少家 Edge AI NPU 公司？

没有统一的公司总数，因为产品厂商、IP 授权商、智能传感器、GPU 和私有汽车 ASIC 之间存在重叠。本指南并非穷尽性清单，截至 2026 年 8 月，共跟踪了 69 家拥有相关边缘 AI 芯片、加速平台、可授权 NPU IP，或具有可信候选芯片的公司及平台生态。

什么是 NPU？

神经网络处理器（NPU）是用于卷积、矩阵乘法等神经网络运算的专用硬件。厂商使用的名称包括 NPU、AIPU、BPU、KPU、DLA、HTP、TPU 和 MLA；编译后的模型通常无法在不同厂商之间移植。

哪些 NPU 公司官方支持 YOLO 模型？

Amlogic、Hailo、Axelera AI、Rockchip、高通、MediaTek、DEEPX、D-Robotics、AXERA、SOPHGO、Huawei、Cambricon、通过树莓派官方 AI Camera 仓库提供支持的 Sony IMX500、STMicroelectronics、Renesas、Lattice、Himax、Microchip 等厂商，都有至少一个 YOLO 代际的一手模型库条目、教程或验证结果。具体代际、任务、芯片目标和 SDK 版本仍然很重要。

任何 ONNX 模型都能在任何 NPU 上运行吗？

不能。ONNX 是模型交换格式，不是硬件兼容性保证。NPU 编译器必须支持计算图中的每个算子、张量形状和数据类型。静态形状、计算图切分、自定义算子和 CPU 回退都很常见。

哪款 NPU 最适合 YOLO？

没有适用于所有场景的赢家。Hailo、Rockchip、Axelera AI、DEEPX 和 Amlogic 的 YOLO 文档覆盖较充分，而高通的设备覆盖面很广。选择时应考虑量化后的精度、完整流水线延迟、持续功耗、价格、供货情况、SDK 获取方式和操作系统支持。

为什么 NPU 的 TOPS 数字不能直接比较？

厂商统计时可能采用不同精度、稀疏运算、乘加计数方式和峰值利用率假设。TOPS 不包含内存流量、不支持的算子、预处理、后处理和主机开销。应在相同模型、精度、分辨率、精度指标和完整流水线上进行比较。

什么是 NPU 校准？

校准是将有代表性、通常没有标签的部署图像输入模型，让编译器估算 INT8 或其他低精度格式的激活值范围。随机或缺乏代表性的图像仍可能生成编译产物，却会损害任务精度。

LibreYOLO 支持边缘 NPU 吗？

LibreYOLO 可导出 ONNX 和多种运行时格式；部分 Rockchip 模型可直接通过 RKNN 编译器路径处理，并提供外部 Hailo 编译流程的文档。其他厂商原生格式仍需其厂商 SDK；在完成编译、验证并在硬件上运行之前，应将它们描述为集成候选方案。