Edge AI NPU企業69社を比較：チップ、SDK、YOLO対応（2026年）

**単一のNPU市場はありません。このガイドはすべてを網羅するものではありませんが、企業とプラットフォームエコシステムを合わせて69件追跡しています。内訳は、デプロイ可能なチップまたはプラットフォームを持つベンダー51社、NPU IPサプライヤー9社、ウォッチリスト企業9社です。**互換性のない複数の種類のアクセラレーターと、それに近い数のコンパイラースタックにまたがっています。多くのベンダーが約束する手順は共通しています。モデルをエクスポートし、量子化し、コンパイルし、独自形式の成果物をボードにコピーして、ベンダーのランタイムを呼び出します。その手順が午後だけで終わるか、エンジニアリングに四半期かかるかは、細部で決まります。

このガイドでは、2026年に信頼できるコンピュータビジョン向けハードウェアを提供する企業を整理しています。対象チップ、SDKとコンパイラーの名称、デプロイ成果物、公開アクセスの範囲、ベンダーが実際に資料で取り上げているモデルを記録しています。また、新しいADLAスタックが旧A311D NPUエコシステムと実質的に異なるAmlogicを詳しく取り上げます。

**調査範囲：**資料は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は、公開ツールチェーン、モデルズー、シミュレーター、安定したランタイムを備えた小型デバイスより、デプロイ先として劣ることがあります。

このガイドでの「サポート」の意味

ベンダー資料では「サポート」という言葉が非常に曖昧に使われています。この記事では、証拠を4段階に分けます。

この区別は重要です。「ONNXをインポートできる」ことは「YOLO11セグメンテーションに対応する」ことと同じではありません。モデルを解析できても、CPUにフォールバックしたり、出力数値を誤ってコンパイルしたり、アクセラレーターのメモリを超過したり、量子化で精度を落としたりすることがあります。

NPU企業とプラットフォームの概要

以下の表では、SoC、ディスクリートアクセラレーター、スマートセンサー、近接領域のGPU/FPGAを意図的に並べています。NPU、AIPU、BPU、KPU、DLA、HTP、TPU、MLAなど名称は違っても、同じデプロイ先の選択肢になります。

組み込みSoC、スマートセンサー、産業用プロセッサー

ディスクリートのエッジアクセラレーターとモジュール

NPUと比較される近接プラットフォーム

Amlogic：1つではなく2世代のNPU

ウェブ上の情報では互換性のない製品がまとめられていることが多いため、Amlogicには詳しい説明が必要です。同社には、旧VeriSiliconベースの経路と、新しい独自ADLA経路があります。コンパイラー、成果物、ランタイムは共通ではありません。

A311Dのデータシートには、旧5-TOPS INT8 NPUが記載されています。旧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は別製品です。

ハードウェアにはもう1つ注意点があります。Khadas VIM4のリビジョンガイドによると、初期のV12/A311D2リビジョンBボードにはNPUがありません。公称3.2-TOPS NPUが搭載されたのは、A311D2-N0Dリビジョン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環境も対象です。

ツールキットに公開されているプラットフォームIDは次のとおりです。

この対象フィールドは形式的なものではありません。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では、演算子ガイドにあるネイティブINT4、FP16、BF16対応に加えて、W4A8、W4A16、W8A8、W8A16、W16A16を利用できます。Amlogicは代表的なキャリブレーションサンプルを200〜500枚使うことを推奨しています。ランダムデータのオプションは、精度を保つ量子化ではなく性能テスト用だと明記されています。

Amlogicの公開モデル対応

固定版Amlogicモデルプレイグラウンドは、一般的なONNX対応の主張より強い証拠です。公開された対応/サンプル表にはA311D2、S905X5、A311Y3、C305X2、A123Xが記載されています。他の対象IDがコンパイラーで受け付けられることは、このモデル一覧全体の検証を意味しません。

同じリポジトリでは、次のW8A8モデルのランタイム数値も公開しています。数値はNPU上でのニューラルネットワークのベンダー測定値であり、カメラパイプライン全体の性能ではありません。

注意点は特に重要です。Amlogicの演算子ガイドでは、ADLA2とADLA3の両方でNMSをソフトウェアで実行するとしています。READMEでは、前処理と後処理を除外したNPUモデル本体の実行結果と定義しています。メモリ転送をすべて含むかは明らかにされていません。YOLOの精度行はCOCO検証セット全体ではなく、300枚のサブセットを使用しています。分類行ではImageNetのval1000を使用しています。また、表には条件の説明がないまま、A311Y3のYOLOv8nについてFPS表とは異なるレイテンシも記載されています。クロック、電力モード、冷却、定常温度、正確なSDK/BSPバージョン、テスト時間は開示されていません。数値は1つのベンダースタックを理解するために使い、他社とのランキングには使わないでください。

Amlogicが戦略的に興味深い理由

Amlogicには、大きな組み込みSoCの展開規模、新たに公開されたコンパイラースタック、LibreYOLOのタスク領域と大きく重なる現行モデル表、主要な学習ライブラリでのファーストクラス統合の少なさという、珍しい特徴が4つあります。現行リポジトリは2025年末から2026年初めに公開されたばかりで、実質的なマニュアルも2026年5〜7月のものです。そのため、先行者利益を得る機会がある一方、APIの安定性にはリスクもあります。

堅牢な統合では、LibreYOLOの決定論的ONNXエクスポートをコンパイラー入力にし、低精度ビルドでは代表的なキャリブレーション画像を必須にします。.adlaとメタデータマニフェストを生成し、NNSDK2アダプター経由で読み込みます。旧A311Dは明確に異なる.nb対象として扱ってください。.nbと.adlaを1つのバックエンドとして見せると、互換性の問題を気付かずに引き起こします。AmlogicのリポジトリはトップレベルのライセンスがApache-2.0ですが、同梱wheel、共有ライブラリ、nnserver、Android AARバイナリーの再配布権は、LibreYOLOでミラーする前に直接確認する必要があります。

公開デプロイ環境が特に充実した企業

次に挙げる企業は、現在、入手可能なハードウェア、公開技術資料、モデル名を示す証拠の組み合わせが特に明確です。どこでも最速という意味ではありません。ハードウェアを購入する前に互換性の主張を評価しやすいという意味です。

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には別のアプリケーション層もあります。Hailo-8/10HのTAPPAS形式のホスト経路ではなく、Vision Processor Software PackageとHailo Media Libraryを使います。公開リファレンスリポジトリhailo-camera-appsは2026年5月3日にアーカイブされましたが、hailo-apps-coreは別の公開アプリケーションフレームワークとして継続しています。リポジトリのアーカイブは製品EOLの証明ではありません。Hailo-15のプロジェクトではDeveloper Zoneで現行のアプリケーションパッケージを確認してください。

LibreYOLOのHailoデプロイガイドは、プロプライエタリなコンパイラーをPython依存関係として同梱できないため、静的ONNXを受け渡すところまでを扱います。適切なグラフを作ることと、HEFの動作検証済みを主張することの境界を正直に示しています。

Rockchip

Rockchipは、特にRK3588、RK3576、RK356xのボードを通じて、趣味用途と商用組み込みLinuxで最大級の展開規模を持ちます。公開されている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上の検出バリアントを厳密に4種類検証し、コンパイラーシミュレーターと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世代の変更に伴い、成果物の名称も変わりました。アルファ版Pipeline Builderのコンパイル手順では.axmモデルを出力し、移植可能なパイプラインを.axeとしてパッケージ化できます。従来版のパイプラインドキュメントでは、.axmodelとモデルメタデータ、マニフェストを説明しています。統合側では拡張子を固定せず、インストールされたVoyagerの世代を検出する必要があります。

Qualcomm

Qualcommのデプロイ対象は非常に幅広い一方、「Qualcomm NPU」という名称の裏には複数のインターフェースがあります。デバイスや製品クラスによって、QAIRT/QNN経由のHexagon HTP、旧SNPE経路、Qualcomm AI Hubコンパイルサービス、LiteRT、ONNX RuntimeのQNN Execution Providerを使います。

公式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バージョン、量子化方式をすべて考慮する必要があります。Qualcommの現行ページ間でもDragonwing IQ-9075の状況に食い違いがあります。製品ページではActive、EVKでは評価可能とされていますが、Product Longevity Programでは引き続きSamplingと表示され、2038年までの長期供給が記載されています。発注/SKUの接頭辞はQCS9075です。Qualcommは高密度INT8で50および100 TOPSの構成、Ubuntu/Yocto対応を公称しています。正確な発注SKUの量産状況を確認し、LibreYOLO統合では「Qualcomm」という一般的なフォルダー名ではなく、そのSKUを記録してください。

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より製品ライフサイクルが長く、カメラ、安全性、リアルタイム処理との統合に優れることがよくあります。一方、1社が複数の無関係なNPUアーキテクチャを出荷するため、AIスタックは複雑になりがちです。

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として掲載しています。この部品は最大4基のC7 NPUを搭載し、最大400 TOPSです。より広いTDA5ファミリーでは最大1,200 TOPSと公称されています。これは新世代に関するベンダー製品の主張であり、TIが対象別対応表を公開する前に、AM6xA/TDA4のTIDLモデル検証をTDA54-Q1へ引き継げることを意味しません。

NXP

NXPでは、少なくとも4つのバックエンドを説明する必要があります。

eIQ Model ZooにはYOLOv4-tiny、YOLOv8、NanoDet、CenterNet、FastestDet、SSD Lite、YOLACTなどの成果物やレシピがあります。YOLOv5の項目はドキュメントのみです。1つのバックエンド向けに検証された項目が、4つすべてに対応する証拠ではありません。NXP自身のi.MXプラットフォーム向けYOLOエクスポートガイダンスも、対象ごとの変換が必要であることを示しています。NXPによると、モノリシックなeIQ Toolkitはバージョン1.17以降、2025 Q3に更新を終了しました。現在は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モジュールは販売中ですが、USBオプションは量産前です。NXPはeTOPSの「e」を「equivalent（相当）」と定義しており、「effective（実効）」ではありません。他社の高密度INT8 TOPS指標と直接比較すべきではありません。

STMicroelectronics

STM32N6x7デバイスにはSTM32N657、STM32N647などが含まれ、MCUクラス製品に600-GOPS Neural-ARTアクセラレーターを搭載しています。汎用の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世代、Translatorのバージョン、CPU側後処理を記録する必要があります。

スマートセンサーとカメラ向けプロセッサー

Sony IMX500

SonyのIMX500は通常のアプリケーションプロセッサーではありません。画像センシングとAI処理を積層しており、センサー内で推論することで、カメラから外へ送る画像データを減らせます。Raspberry Pi AI Cameraによって、この構成を特に利用しやすくなっています。

公式のRaspberry Pi IMX500モデルリポジトリでは、YOLOv8n、YOLO11n、EfficientDet Lite0、NanoDet+、SSD MobileNetV2 FPN Liteのパッケージ済みモデルを公開しています。AI Cameraドキュメントでは、変換、パッケージ化、センサー内後処理を説明しています。デプロイ単位は汎用ONNXファイルではなくRPKパッケージで、センサーのメモリと演算子の制約が設計上の重要な制限になります。Raspberry Piの製品ページによると、このカメラは少なくとも2028年1月まで生産されます。

Ambarella

AmbarellaのCVflowプロセッサーはカメラ、ドローン、車載ビジョンで広く使われています。現行ファミリーにはカメラ向けCV72/CV75、高性能ビジョンシステム向けCV5/CV52、車載向けCV3-ADデバイスがあります。Cooper開発者プラットフォームとCVflowコンパイル/ランタイム経路が、公開資料に記載されたソフトウェアスタックです。

公開の開発者向けモデルガーデンにはYOLOX、RTMDet、DeepLabV3+、TopFormer、OWL-ViT、マルチモーダルモデルが掲載されています。ただし、コンパイラーの詳しいドキュメントとダウンロードはパートナー向けです。Ambarellaを統合する場合、公開pipパッケージがあると想定せず、ベンダーやOEMとの連携から始めるべきです。

Synaptics Astra

Synapticsには関連する対象が3種類あります。SL1600/SL1680 Astraシステムは、ソースモデルとYAML記述からmodel.synapパッケージを生成するSyNAP toolkitを使います。新しいSL2611/13/15/17/19デバイスは、.vmfbを生成するIREE/MLIRベースのTorqプラットフォームを使います。SR100シリーズはCortex-M55とEthos-U55を中心とする別のMCUファミリーで、専用SDKを持ちます。これらの成果物とAPIは相互利用できません。

公式YOLOベンチマークチュートリアルは、具体的な手順を示しています。YOLOv8をTFLiteにエクスポートし、SyNAPで非対称UINT8キャリブレーションを行い、SL1680向けにコンパイルした後、synap_cliと物体検出アプリケーションを実行します。SL1680上のYOLOv8n/v8sを実証し、SyNAPではYOLO11まで対応すると説明しています。別のSL261x物体検出ガイドでは、Torqの.vmfbからYOLOv8を実行します。いずれも対象を限定した公式例であり、3ファミリーすべてのYOLOグラフに対応するという主張ではありません。

MediaTek Genio

MediaTekを詳しく取り上げる理由は、現行のIoT AI Hubに、以前の市場調査では監査できなかったハードウェア/ソフトウェア対応表、モデルパッケージ、ベンチマーク表が公開されたためです。Genio 360/360P/420/520/720はMDLA 5.3搭載NeuroPilot 8を使います。Genio 510/700はMDLA 3.0搭載NP6、Genio 1200はMDLA 2.0搭載NP6を使います。MediaTekによると、NeuroPilotとMDLAの世代、演算子セット、コンパイラー、ランタイムは、各SoCの製品寿命を通じてバージョンに依存します。

分析系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 delegationと、対応OS上のONNX Runtime CPU/NPU経路も利用できます。これらはオフライン.dlaとは異なる実行モードです。ソフトウェアアーキテクチャガイドとリソース一覧では、その違いを明示しています。

公式の分析系モデル表には、複数MDLA世代向けのYOLOv5sとYOLOv8sのベンチマーク項目、変換ガイドが掲載されています。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エコシステム

英語の市場一覧では、RockchipからNVIDIAへ話が飛び、その間にあるエコシステムが抜け落ちることがよくあります。

D-RoboticsとHorizon由来のBPUプラットフォーム

D-Roboticsは、RDK X3、X5、Ultra、新しいS100シリーズの製品で使われるBPUアクセラレーターを中心に、RDK開発ボードのエコシステムを維持しています。RDK Model Zooの現行rdk_x5ブランチには、RDK X5向けのYOLOv5/v5u、YOLOv8/9/10/11/12/13/26、YOLOE、YOLO-World、検出、セグメンテーション、姿勢推定、分類、OCR、CLIPの手順が記載されています。X3は別ブランチを使用し、現行Sシリーズ向け資産はメインzooのrdk_sブランチにあります。旧rdk_model_zoo_sリポジトリには過去のデモがあります。したがって、現行X5一覧は、すべてのモデルがX3、Ultra、S100でも検証済みである証拠ではありません。

OpenExplorer/Algorithm ToolchainはONNXまたはCaffeをインポートしてPTQを行い、PyTorchを用いるQAT手順にも対応しています。デプロイはプラットフォームごとに異なります。現行RDK X5は.binを使い、libdnn経由でhbm_runtimeから実行します。現行の主要rdk_s経路は.hbmを使い、libhbucp上の同名hbm_runtime APIから実行します。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は、独立した統合にとって魅力のあるコンパイラースタックの1つです。コンパイラー自体がオープンソースだからです。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の経路が記載されています。TensorFlowフレームワーク対応は1.7で削除されましたが、過去のTensorFlow例は残っています。Cambriconの現行3-series開発者ポータルには、より新しい全体SDKリリースが掲載されています。公開サンプルリポジトリと現行商用スタックを同じバージョンとして扱うべきではありません。

公式のMagicMindクラウドモデルリポジトリは、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ガイドでは、Acuity/Pegasusによるインポート、量子化、検証、viplite経由のデプロイを説明しています。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入力を説明しているため、ほかのフレームワークには対応IRへのエクスポートまたは変換が必要です。Milk-V提供のENNP概要とYOLOv3チュートリアルで、公開されたエンドツーエンドの手順を確認できます。ただし、現在の幅広いモデル/精度一覧までは確認できません。

Nuvoton M55M1

NuvotonのM55M1は、Linuxアプリケーションプロセッサーではなく、Cortex-M55とEthos-U55-256を組み合わせたMCUクラスの設計です。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は主にLLM/VLM向けの別.fxbスタックを使います。Furiosaの現行ロードマップでは、ビジョン向けYOLOv8m対応が2024 Q4に完了したと記録されています。しかし、現在公開されている対応モデルや性能情報はLLM/VLM中心で、詳細なYOLOv8m精度/性能表はありません。これはリリース済み世代についての証拠であり、Warboyの対応を示すものではありません。

Realtek、Telechips、T-Head、SigmaStar

これら4つのプラットフォームは実在しますが、独自モデルの公開手段は限られているか、旧式であるか、アクセス制限付きです。

HiSiliconのスマートビジョンはHuawei Ascendではない

HiSiliconのHi3516CV610/DV500、Hi3519DV500、Hi3403V100カメラSoCは、NNN/SVP-NNNランタイムを通じてATCから.omを生成する手順を公開しています。公式のHiSpark model zooには、特にHi3403とHi3591Pを対象とした表に、YOLOv3/4/5/6/7/8/9/10/11、YOLO11セグメンテーション/姿勢推定、YOLOv8 OBB/World/セグメンテーション、OCR、深度、TinySAMが掲載されています。上記のスマートビジョンSoCすべてで全項目が実行できることを示すものではありません。一部はロードマップ項目です。公開済み例と計画中の対応は分けて扱う必要があり、リポジトリには提供モデルを非商用利用に限定する記述があります。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と量産中の50-TOPS Modalixプラットフォームは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は旧AKD1000ハードウェアやAkida 2 IPとともに、出荷中のAKD1500コプロセッサーをM.2形式で販売しています。

現行の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では、2基のMLアクセラレーターと、E7のTFLiteからVelaへの経路を実演しています。Ensemble E8にはEthos-U85が1基、Ethos-U55 NPUが2基搭載されています。AlifはCortex-M55とEthos-U55で動作する、192 x 192のファミリーレベルINT8 YOLO-Fastest顔検出器ベンチマークも公開していますが、現代的なYOLOの幅広い対象別対応表はありません。これらのメモリ制約のあるシステムは、小型の分類・検出ネットワークに適しています。TFLiteで表現できるというだけで、任意の640ピクセル検出器に適しているわけではありません。

Infineon PSOC Edge、Himax WiseEye2、Analog Devices MAX7800x

InfineonのPSOC Edge E83とE84ファミリーは、Cortex-M55とEthos-U55を組み合わせ、低消費電力のM33側には別のNNLiteブロックを追加しています。E84アーキテクチャマニュアルでは、8-bit重み、8または16-bitアクティベーション、対応演算子を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ツールは学習済みネットワークを量子化し、移植可能なONNXランタイムパッケージではなく、対象固有のCコード、重み、アクセラレーター設定を生成します。ファーストパーティの資料には、顔識別、ADIモデルズーにあるTinierSSD QR検出、画像分類器があります。エンドポイントビジョンに関係するデバイスですが、現代的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 sensAIは、固定NPUに代わるFPGAベースの選択肢です。sensAI StudioとNeural Network Compilerは、対応グラフをECP5、iCE40 UltraPlus、CrossLink-NX、CertusPro-NX、Avant-E、Avant-Xデバイス向けの構成可能なアクセラレーターIPに割り当てます。出力は選択したFPGA、アクセラレーターモード、メモリ配置、ビットストリームに結び付いており、移植可能なランタイムモデルではありません。

現行のNeural Network Compilerマニュアルには、特に直接的なトポロジー表があります。ECP5向けYOLOv1、最適化/AdvancedモードのCrossLink-NXおよびCertusPro-NX向けYOLOv5/YOLOv8、AdvancedモードIPのみのYOLO11が記載されています。さらにSSD、MobileNetV2-SSD、ResNet、ENet、SqueezeDetなどのビジョンネットワークも、FPGAファミリーごとに未対応欄を明示して掲載されています。Advanced CNN AcceleratorはAvant-E/Avant-X/CertusPro-NXを対象とする商用IPです。これはコンパイラー表の証拠であり、1つのビットストリームで列挙したすべてのトポロジーを同時に使えるという保証ではありません。

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はMicrochip独自ライセンスのもとで公開され、ソフトウェアと派生物の利用はMicrochip製品に限定されています。Microchipは無料ですが申請が必要なLibero SilverとCoreVectorBloxライセンスを提供します。デプロイには引き続きFPGAシステム全体の整合が必要です。アクセラレーター設定、ビットストリーム、ファームウェア、SDK生成ネットワークデータ、メモリ配置を一致させる必要があります。VectorBloxでコンパイルできても、任意のPolarFire設計へコピーできるバイナリーになるわけではありません。

Syntiant

SyntiantのNDP200は、通常のLinux SoCより低い電力範囲で常時稼働するビジョン、音声、センサー推論を対象にしています。現行ハードウェア表ではNDP200が量産中、NDP250がサンプリング中です。NDP200製品概要では、CNN、RNN、全結合ネットワークを1 mW未満でサポートするとしています。一方、NDP250発表では、常時稼働の画像認識を30 mW未満としています。「サブミリワット」を両方の部品に一般化すべきではありません。

公開資料から幅広いYOLO互換性は確認できません。そのため、汎用ONNXエクスポートを想定するのではなく、ベンダー支援のモデル評価を通じて、小規模な常時稼働分類器や検出器に適するか検討してください。

Google Coral：無関係な2世代

旧Edge TPU製品は、完全INT8 TFLiteモデルとEdge TPU Compiler、libedgetpu、PyCoralを使います。中核の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項目はYOLOv8s INT8です。NVIDIAのDLA制約に演算子の制限が記載されています。Thorはさらに別です。NVIDIAのDriveOS移行ガイドによると、ThorではGPUスケジューリングの柔軟性を優先してDLAコアを削除しました。つまり「Jetson上で動く」だけでは、使われたアクセラレーターは特定できません。

**AMD Vitis AI：**旧Kria/DPU世代は.xmodelグラフをコンパイルし、VARTで実行していました。現行Vitis AI 6.2は、Versal AI Edge向けの別々の2経路でGAとなっています。Gen1はVEK280/VE2802上でONNX、AMD Quark、対象固定のsnapshot/サブグラフ経路を使います。Gen2はVEK385上で別のコンパイル/ランタイム契約を持ちます。Gen1の例ではYOLOv5、YOLOv7、YOLOv8、YOLOXを扱います。Ryzen AIは4つ目の別系統クライアントNPUスタックです。すべてVitisまたはAMDの名を持つというだけで、旧DPU、Versal Gen1、Versal Gen2、Ryzen AI間で成果物や検証結果を移してはなりません。

**Intel OpenVINO：**OpenVINOは1つのAPIからCPU、GPU、Core Ultra NPUを対象にできます。Intel NPUプラグインのドキュメントには対応NPU世代が記載され、検証済みモデル表ではデバイスごとの列を確認できます。YOLOノートブックはアプリケーション手順を示す資料です。表で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企業

ボードやパッケージ済みアクセラレーターを直接販売せず、SoCベンダーにNPU設計をライセンスする企業もあります。同じ基礎アーキテクチャが複数のチップブランドに搭載されることがあるため重要ですが、最終SDKと成果物はライセンシーによって独自化される場合があります。

Imaginationを見ると、アーキテクチャ名の横にアクセスとライフサイクルを示す理由がわかります。Open Accessプログラムでは、実シリコンで検証済みのSeries3NX構成を3種類、IPの初期ライセンス料なしで提供します。ただし、企業審査に加え、有償サポート/保守と製品ロイヤリティが必要です。Neural Compute SDKは、コンパイル、最適化、量子化、ランタイムの各ツールを提供します。公式のBaidu PaddlePaddleとの連携では、PP-YOLOE検出、EfficientNet分類、HRNetセグメンテーションを取り上げています。これらの例はすべてのSeries3NXまたはSeries4構成を検証するものではありません。また、現行の個別Series4製品ページでは入手不可と表示されているため、販売部門が確認するまではSeries4を過去の製品として扱ってください。

このIP層が、ファミリー間に一見似ている点が生まれる理由です。成果物の移植性が生まれるわけではありません。VivanteやEthos IPに関連性のあるSoC同士でも、メモリマップ、ドライバー、コンパイラーバージョン、演算子セット、ベンダーランタイムは異なる場合があります。

実際にデプロイするもの：成果物ロックインの表

コンパイラーパイプラインの最後にあるファイルを見れば、見かけ上のONNX移植性がどこで終わるかがわかります。名称や拡張子は変わりますが、実務上の原則は変わりません。ネイティブ成果物は通常、別のNPU世代へ移せず、別のSDKリリースで確実に再生成できるとも限りません。そのため、元モデルとキャリブレーションデータを保持してください。

この表は拡張子の一覧だけではありません。コンパイラーバージョン、対象ID、ドライバー、ファームウェア、BSPは、モデルの再現可能な識別情報の一部です。今後LibreYOLOにエクスポーターを追加する場合は、成果物ごとに機械可読なマニフェストへこれらを記録してください。

ツールへのアクセスとライフサイクルの兆候

ハードウェアの入手性とコンパイラーへのアクセスは別問題です。ボードを簡単に購入できても現行コンパイラーには顧客契約が必要な場合があり、SDKが公開されていても対象シリコンの入手が難しい場合があります。以下は一次資料で確認できる具体的な兆候であり、普遍的な製品寿命ランキングではありません。

TOPSが購入ガイドにならない理由

ピークTOPSは1社内、同じアーキテクチャ内なら参考になりますが、次のすべてが一致しない限り、メーカー間の比較は通常成り立ちません。

• INT8、INT4、FP16、混合モードなど、数値精度
• 1回の積和演算を1演算または2演算のどちらと数えるか
• 密演算か構造化スパース演算か
• 入力解像度、バッチサイズ、モデルグラフ
• 量子化後の精度
• NPU単体のレイテンシか、アプリケーションパイプライン全体か
• メモリ転送とホスト側フォールバック
• 温度状態、バースト時ではなく持続時の動作

検出器はパイプラインです。画像取得、リサイズ/レターボックス、正規化、デバイス転送、ニューラル推論、デコード、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

これらの情報がなければ、2つのFPS値は通常、異なる内容を測定しています。

コンピュータビジョン用NPUの選び方

製品ページに最大の数字があるものではなく、次の順番で選んでください。

1. **グラフ互換性を証明します。**似た名前のモデルズーチェックポイントではなく、エクスポートした正確なモデルをコンパイルします。
2. **精度を測定します。**キャリブレーションと量子化の後、実際のタスクデータセットでコンパイル済み成果物を検証します。
3. **エンドツーエンドで測定します。**入力変換、転送、デコード、NMSを含めます。
4. **ソフトウェアへのアクセスを確認します。**コンパイラーが公開、登録制、商用契約のみのいずれかを調べます。
5. **バージョン対応を固定します。**コンパイラー、ランタイム、ドライバー、ファームウェア、対象IDを記録します。
6. **OSの実情を確認します。**Android、Debian、Yocto、Buildroot、RTOS、Windowsへの対応は相互に代替できません。
7. **供給とライフサイクルを確認します。**モジュール、ドライバー、長期サポートが不確かなチップは、技術的に優れていても本番採用に適しません。
8. **その後で価格、電力、性能を比較します。**両方の対象で同じモデルが正しく動いた後に、これらの数値が意味を持ちます。

用途別の実践的な出発点

この表は調査候補の一覧であり、性能ランキングではありません。調達、地域での入手性、正確なモデルによって順序が変わる場合があります。

LibreYOLOにとっての意味

拡張しやすい設計は、互いに無関係なエクスポーターを何十個も用意することではありません。厳密な交換契約1つと、小規模なベンダー用コンパイラー/ランタイムアダプターで構成します。

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のチェックサム
• 入力名、形状、レイアウト、色空間、正規化、dtype
• 量子化精度、公開されている場合はスケール、キャリブレーションデータのハッシュ
• 出力テンソル名、形状、意味
• 検出タスク、クラス名、デコード/NMSがチップ上かホスト側か
• 記録した数値パリティとタスク精度の結果

LibreYOLOは、移植可能なONNXエクスポート、量子化ツール、対象を意図的に絞った直接RKNNエクスポート、外部コンパイラーを使うHailo手順をすでに提供しています。このガイドの基準では、Amlogic ADLAは次の有力な統合候補です。ツールキットは公開され、モデル対応はLibreYOLOと大きく重なり、旧A311D経路を明確に分けられます。

Amlogic以降の優先順位は、コンパイラーの入手性だけでなく、ユーザーが使うハードウェアと精度検証の実施可能性に基づいて決めるべきです。DEEPX、Sony IMX500、D-Robotics、AXERA、SOPHGO、Qualcommは技術的に魅力があります。TI、NXP、ST、Renesasは、産業分野のパートナーからボードと長期CIアクセスを得られる場合に特に有用です。

ウォッチリスト：公開統合契約がない実在シリコン

企業を完全に除外すると市場一覧が誤解を招く場合があります。「対応済み」として含めると、さらに問題になることがあります。次のベンダーは関連シリコンを販売、サンプリング、または発表していますが、公開資料だけでは、LibreYOLOバックエンドに適した再現可能な現行コンパイラー、成果物、モデル名付きのデプロイ手順を確認できません。

このウォッチリストは証拠に基づいています。現行ツールチェーンまたは評価手順、対象固有の成果物仕様、エンドツーエンド手順を伴うモデル名付き例を公開すれば、ベンダーはデプロイ可能な一覧へ移せます。

意図的に主張していないこと

この記事は、列挙したすべてのモデルが上流リポジトリのまま動くとは主張していません。ベンダーのzooモデルは、変更を加えられていたり、異なる出力ノードで分割されていたり、カスタム後処理と組み合わされていたりすることがよくあります。

また、以下を対応済みの主張にはしていません。

• コンパイラーが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ライセンス、モデルライセンスをそれぞれ確認する必要があります。

調査方法と訂正

各企業について、次の4つの一次資料を調べました。

1. シリコンを特定する現行製品ページまたはデータシート
2. 実際のデプロイ経路を説明するコンパイラー/ランタイムドキュメント
3. ビジョンモデル名が記載されたモデルズー、互換性表、エンドツーエンドチュートリアル
4. 開発者が実際にツールを入手できるかを示すライフサイクルまたはアクセス情報

ファーストパーティのGitHub組織もベンダー資料に含めています。チップ企業自身が同じ内容を公開していない場合は、ボードベンダーの資料をエコシステム資料として示しています。サードパーティの性能主張は比較表から除外しました。

完成した草稿を、企業群別の再調査と表を横断した確認で再監査しました。対象範囲、成果物名、精度、モデルと後処理の証拠、発表済み/出荷中の区別、ライフサイクル表示、ベンチマークの分母、企業数を再確認しました。一次資料2つの内容が食い違う場合は、都合のよい方を黙って選ばず、食い違いを明記しています。

この市場は急速に変化します。対象企業の担当者で、チップ、SDK、モデル一覧、アクセス状況に誤りを見つけた場合は、正確な公開ドキュメントのURLとバージョンをLibreYOLOへお知らせください。一次資料で裏付けられる訂正で本文を更新します。ドキュメントにないマーケティング上の主張は追加しません。

FAQ

Edge AIのNPU企業は何社ありますか？

製品ベンダー、IPライセンサー、スマートセンサー、GPU、非公開の車載ASICが重なり合うため、普遍的な企業数はありません。このガイドはすべてを網羅するものではありませんが、2026年8月時点で、関連するEdge AIチップ、アクセラレータープラットフォーム、ライセンス提供されるNPU IP、または有望なウォッチリスト対象シリコンを持つ企業とプラットフォームエコシステムを69件追跡しています。

NPUとは何ですか？

NPU（ニューラル処理ユニット）は、畳み込みや行列乗算など、ニューラルネットワークの演算に特化したハードウェアです。ベンダーによってNPU、AIPU、BPU、KPU、DLA、HTP、TPU、MLAなどの名称が使われ、コンパイル済みモデルは一般に企業間で移植できません。

YOLOモデルを公式にサポートするNPU企業はどこですか？

Amlogic、Hailo、Axelera AI、Rockchip、Qualcomm、MediaTek、DEEPX、D-Robotics、AXERA、SOPHGO、Huawei、Cambricon、Raspberry Piの公式AI Cameraリポジトリ経由のSony IMX500、STMicroelectronics、Renesas、Lattice、Himax、Microchipなどは、少なくとも1世代のYOLOについて、ファーストパーティのモデルズー項目、チュートリアル、または検証済み結果を公開しています。対応する世代、タスク、チップの対象、SDKバージョンを個別に確認する必要があります。

どのONNXモデルでも、どのNPUでも実行できますか？

いいえ。ONNXは交換形式であり、ハードウェア互換性を保証するものではありません。NPUコンパイラーは、グラフ内のすべての演算子、テンソル形状、データ型をサポートする必要があります。静的形状、グラフ分割、カスタム演算、CPUフォールバックはよくあります。

YOLOに最適なNPUはどれですか？

万能な勝者はいません。Hailo、Rockchip、Axelera AI、DEEPX、Amlogicは、公開資料で確認できるYOLO対応が充実しており、Qualcommは特に幅広いデバイスに展開されています。量子化後の精度、パイプライン全体のレイテンシ、持続消費電力、価格、入手性、SDKへのアクセス、OS対応で選んでください。

NPUのTOPS値を直接比較できないのはなぜですか？

ベンダーによって、数値精度、スパース演算、積和演算、ピーク稼働率の前提が異なります。TOPSにはメモリ転送、未対応演算子、前処理、後処理、ホスト側のオーバーヘッドが含まれません。同じモデル、数値精度、解像度、タスク精度、パイプライン全体で比較してください。

NPUのキャリブレーションとは何ですか？

キャリブレーションでは、代表的なデプロイ画像（通常はラベルなし）をモデルに通し、コンパイラーがINT8などの低精度形式向けにアクティベーション範囲を推定します。ランダムな画像や代表性のない画像でもコンパイル成果物が生成されることはありますが、タスク精度を損なう可能性があります。

LibreYOLOはエッジNPUをサポートしていますか？

LibreYOLOはONNXや複数のランタイム形式にエクスポートでき、一部のRockchipモデル向けに直接RKNNコンパイラーパスを備え、外部Hailoコンパイル手順も説明しています。それ以外のベンダー固有成果物にはベンダーSDKが必要です。ハードウェア上でコンパイル、検証、実行するまでは、統合候補として説明してください。