# STM32N6とNeural-ART NPU｜マイコン単体で動くエッジAI実践ガイド｜株式会社テクノスフィア

> ST初のNPU搭載マイコンSTM32N6を実務目線で解説。Neural-ART Accelerator（1GHz・最大600 GOPS・約3 TOPS/W）のアーキテクチャ、Jetson/ラズパイとの使い分け判断基準、評価ボードの選び方、ONNXモデルのデプロイ手順、4.2MB SRAMとフラッシュレス構成のメモリ制約、量産採用の判断ポイントまで。組込み受託開発20年超のテクノスフィアが解説。

URL: https://technosphere.co.jp/blog/stm32n6-neural-art-edge-ai

** 目次
1. はじめに：「マイコンでAI」の何が変わったのか
2. STM32N6とNeural-ART NPUのアーキテクチャ
3. Jetson・Raspberry Piとの使い分け判断基準
4. 開発に必要なもの：評価ボードとST Edge AI Suite
5. ONNX/TFLiteモデルのデプロイフロー
6. メモリ制約の現実：4.2MB SRAMとフラッシュレス構成
7. 量産採用の判断ポイント
8. よくある落とし穴と対策
9. まとめ

## はじめに：「マイコンでAI」の何が変わったのか

 これまでSTM32でAI推論といえば、[STM32Cube.AIで学習済みモデルをCコードに変換し、CPUで実行するTinyML](https://technosphere.co.jp/blog/stm32-cube-ai-tinyml)が定番でした。この方式は消費電力とコストの面では優秀ですが、実行主体はあくまでCortex-MコアのCPUです。数十〜数百KBの小さなモデルなら実用になる一方、カメラ画像に対する物体検出のようなワークロードでは推論に数百ミリ秒〜数秒かかり、「リアルタイムの画像AIはJetsonかラズパイ＋アクセラレータで」というのが実務上の相場でした。

 この前提を変えたのが、STマイクロエレクトロニクスが投入した**STM32N6シリーズ**です。STM32として初めてNPU（Neural Processing Unit）である**Neural-ART Accelerator**を内蔵し、**マイコン単体で最大600 GOPS**のニューラルネットワーク推論を実行できます。CPU推論の従来型TinyMLと、Linuxボードによるエッジ推論のあいだにあった性能の空白地帯を、1チップのMCUで埋める存在です。

 本記事では、カタログスペックの紹介にとどまらず、「N6で何ができて何ができないのか」「Jetson/ラズパイとどう使い分けるか」「ONNXモデルをどうやって実機に載せるか」「量産採用で何を確認すべきか」を、受託開発の実務目線で整理します。   ** 弊社での取り組み

弊社はSTM32ファミリでの[組込み受託開発20年超の実績](https://technosphere.co.jp/embedded-achievements)に加え、エッジAIプラットフォーム「GENBA IQ」でカメラ×AIの現場実装を手がけています。本記事はST公式ドキュメント・公開リポジトリの一次情報と、STM32/エッジAI双方の開発経験に基づいて構成しています。

## STM32N6とNeural-ART NPUのアーキテクチャ

まず主要スペックを整理します。数値はいずれもST公式の製品ページ・製品プレゼンテーションに基づきます。
| 項目 | 内容 |
| CPUコア | Arm Cortex-M55 @ **800MHz**（Heliumベクトル拡張搭載） |
| NPU | ST Neural-ART Accelerator @ **1GHz**、最大**600 GOPS**、電力効率 約**3 TOPS/W** |
| NPU内部構成 | 約300個の構成可能なMAC（積和演算）ユニット＋64ビットAXIバス×2本 |
| 内蔵RAM | **4.2MB**の連続SRAM（複数バンク構成）＋8KBバックアップSRAM |
| 内蔵フラッシュ | **非搭載（フラッシュレス）**。外部シリアルフラッシュ（XSPI: Octo-SPI/Hexadeca-SPI等）から起動 |
| ビジョン系 | MIPI CSI-2カメラインターフェース＋ISP（画像信号処理）内蔵 |
| マルチメディア | H.264ハードウェアエンコーダ、NeoChrom GPU（2.5Dグラフィックス）、JPEGコーデック |
| 代表型番 | STM32N657X0（HW暗号あり）、STM32N647x0 など |

### アーキテクチャ上のポイント3つ

**(1) NPUはCPUから独立した推論エンジン。**Neural-ARTは約300個のMACユニットを持つ専用ハードウェアで、コンパイル時にモデルをNPU用マイクロコードに変換して実行します。CPU（Cortex-M55）は推論中も空くため、前処理・後処理・通信・制御を並行できます。RTOSタスクとして推論と制御を同居させる設計は、[STM32 + FreeRTOS入門](https://technosphere.co.jp/blog/stm32-freertos-intro)で解説したタスク設計の延長線上で考えられます。

**(2) NPU非対応の層はCortex-M55にフォールバック。**ST Edge AI Coreのコンパイラは、モデルの各レイヤをNPU実行とCPU実行に自動で振り分けます。Cortex-M55はHelium（MVE）ベクトル拡張を持つため、フォールバック時もCortex-M4/M7比では高速ですが、CPUフォールバックが多いモデルはNPUの意味が薄れます。NPUの対応オペレータ一覧はST Edge AI Coreの公式ドキュメントに公開されているので、**モデル設計の段階で対応表と突き合わせる**のが実務の鉄則です。

**(3) カメラパイプラインが1チップで完結。**MIPI CSI-2＋ISP＋NPU＋H.264エンコーダを内蔵するため、「カメラ入力→AI推論→結果のみ送信（または録画）」という典型的なスマートカメラ構成が外付けプロセッサなしで成立します。従来この構成には一般にLinux SoCクラスのプロセッサが必要でした。  ** 600 GOPSの読み方

600 GOPS = 0.6 TOPSです。Jetson Orin Nano（最大67 TOPS）の約1/100であり、「Jetsonの代わり」ではありません。一方、電力効率は約3 TOPS/Wと高く、**ワット級の電源枠でCNN推論を実用速度で回せる**ことがN6の本質的な価値です。この規模感を正しく掴むことが、次章の使い分け判断につながります。

## Jetson・Raspberry Piとの使い分け判断基準

エッジAIの実装先を相談される際、弊社では「演算量」「電力・熱」「起動時間と制御性」「コストと運用」の4軸で判断しています。代表的なプラットフォームと比較します。
|  | STM32N6 | Raspberry Pi 5 + AI Kit
(Hailo-8L) | Jetson Orin Nano Super |
| AI演算性能 | 0.6 TOPS（600 GOPS） | 13 TOPS | 最大67 TOPS |
| OS | ベアメタル / RTOS | Linux | Linux (JetPack) |
| 消費電力の目安 | MCUクラス（NPU効率 約3 TOPS/W） | 数W〜10W級 | 7〜25Wの電力モード |
| 冷却 | ファンレス前提 | ヒートシンク/ファン推奨 | ファン付き |
| 起動時間 | ミリ秒〜秒オーダー | 数十秒（Linuxブート） | 数十秒（Linuxブート） |
| 開発キット価格帯 | 約76〜224ドル（Nucleo/DK） | Pi 5＋AI Kit 約130〜180ドル | 開発キット249ドル |
| 量産形態 | 自社基板にMCU実装 | CM5等のモジュール実装 | Jetsonモジュール実装 |

### STM32N6が向くケース
- **単機能のビジョンAI：**1カメラでの人検知・物体検出・分類・姿勢推定・異常検知など、int8量子化したCNN 1〜2本で完結するタスク
- **電池・PoE・限られた電源枠：**ファンレス密閉筐体、ソーラー＋バッテリー運用、常時給電が難しい屋外設置
- **リアルタイム制御との同居：**モーター制御や安全系のマイクロ秒応答とAI判定を1チップで両立したい装置組込み（LinuxのソフトリアルタイムではNGな案件）
- **瞬時起動・高信頼：**電源断→復帰が頻繁な環境。ファイルシステム破損リスクのあるLinuxブートを避けたい場合
- **BOMコストと部品点数の圧縮：**SoC＋DRAM＋eMMC＋PMICの構成をMCU＋外部フラッシュ1個に集約したい量産品

### STM32N6では無理をしないほうがよいケース
- **LLM・VLM（視覚言語モデル）：**数百MB〜GB級のモデルはメモリ的に対象外。VLM級の推論は[Raspberry Piで動かすvLM完全ガイド](https://technosphere.co.jp/blog/raspberry-pi-vlm-edge-ai)で扱ったようなLinuxボード以上が前提
- **複数カメラの同時解析・高解像度リアルタイム処理：**演算量が0.6 TOPSを恒常的に超える構成
- **モデルを頻繁に差し替える運用：**コンテナやPythonランタイムでモデルを入れ替えるスタイルの開発・運用にはLinux機が向く（N6は再コンパイル＋ファーム更新が基本）
- **学習・ファインチューニングをデバイス上で行う用途**
  ** 実務での判断手順

迷ったら「①目標モデルをint8量子化して演算量（MACs）とメモリを見積もる → ②ST Edge AI Developer Cloudで実機ベンチマーク → ③目標フレームレートに届けばN6、届かなければ上位機」の順で1〜2日あれば見極められます。先にハードを決めてからモデルを削る進め方は手戻りが大きく、お勧めしません。

## 開発に必要なもの：評価ボードとST Edge AI Suite

### 評価ボードは2種類
| 型番 | 実売価格の目安 | 特徴 |
|  **STM32N6570-DK**
（Discoveryキット） |  約224ドル
（米DigiKey実売） |  STM32N657X0H3Q搭載。**MIPI CSI-2カメラモジュール（Sony IMX335搭載のMB1854）と5インチ800×480 LCDが付属**。Octo-SPI NORフラッシュ（Macronix MX66UW1G45G）、Hexadeca-SPI PSRAM、Ethernet、USB Type-C、microSD、オーディオコーデック搭載。ビジョンAIの評価はこれ一択 |
|  **NUCLEO-N657X0-Q** |  約76ドル
（米DigiKey実売） |  Nucleo-144フォームファクタ。カメラ・LCDなし。外部フラッシュはMX25UM51245G。センサー系AIや自社基板設計前のペリフェラル検証、コストを抑えた複数人開発に |

カメラAIの評価が目的なら、カメラ・LCD・サンプルアプリがそのまま動く**STM32N6570-DKから始めるのが最短**です。ST公式のGitHubに画像分類・物体検出・姿勢推定などのGetting Startedリポジトリ（STM32N6-GettingStarted-ImageClassificationなど）が公開されており、ビルド済みバイナリを書き込めば当日中にデモが動きます。

### ソフトウェア側：ST Edge AI Suiteの構成

N6のAI開発ツール群は「ST Edge AI Suite」という傘の下に整理されています。実務で触るのは主に次の4つです。
- **ST Edge AI Core（stedgeai CLI）：**無償のコマンドラインツール。TensorFlow Lite / ONNX / Kerasのモデルを評価・最適化し、Neural-ART用マイクロコードとCコードに変換する中核。本記事執筆時点の対応バージョンはv4系（後述のGetting StartedはSTEdgeAI v4.0.0を要求）
- **GUIツール（STM32N6-AI / STM32Cube AI Studio）：**CubeMX連携のN6用AIパッケージがSTM32N6-AI、従来のX-CUBE-AIの後継となるデスクトップGUIがSTM32Cube AI Studio（STEDGEAI-CUBEAI）。いずれも中身はST Edge AI Coreベースで、GUI派はこちら
- **ST Edge AI Developer Cloud：**ブラウザからモデルをアップロードし、**リモートの実機ボードでレイテンシとメモリをベンチマーク**できる無償サービス。ボード購入前の見積もりに有効
- **STM32モデルZoo（GitHub: STMicroelectronics/stm32ai-modelzoo）：**量子化済みの学習済みモデル＋学習/評価スクリプト集。まず自分のタスクに近いモデルをここから選ぶのが定石

このほか、ビルドと書き込みに**STM32CubeIDE**と**STM32CubeProgrammer**（Getting Startedの要求はそれぞれv1.17.0 / v2.18.0以降）を使います。

## ONNX/TFLiteモデルのデプロイフロー

N6へのモデル搭載は「①int8量子化 → ②stedgeaiでNPU用にコンパイル → ③アプリに組み込みビルド → ④署名して外部フラッシュへ書き込み」の4段階です。順に見ていきます。

### Step 1：int8量子化（必須）

Neural-ARTで実行するモデルは、**重み・アクティベーションともにint8（scale/offset形式、per-channel）で量子化されていることが前提**です。float32のONNXをそのまま渡してもNPUには載りません。ONNXの場合はQDQ形式の量子化モデルを用意します。

```
# ONNXモデルを int8 (QDQ) に静的量子化する例（onnxruntime）
from onnxruntime.quantization import quantize_static, QuantType

quantize_static(
    "model_fp32.onnx",
    "model_int8.onnx",
    calibration_data_reader=reader,   # 実運用に近い画像数百枚で校正
    activation_type=QuantType.QInt8,
    weight_type=QuantType.QInt8,
    per_channel=True,                 # Neural-ARTはper-channel int8が前提
)
```

量子化の校正データは学習データからのランダム抽出ではなく、**実運用環境で撮影した画像**を混ぜるのが精度劣化を抑えるコツです。TensorFlow系ならTFLiteのfull-integer quantizationで同様にint8化します。量子化とメモリ最適化の考え方自体は[STM32Cube.AIでTinyMLを量産品質にする記事](https://technosphere.co.jp/blog/stm32-cube-ai-tinyml)で解説した内容がそのまま土台になります。

### Step 2：stedgeaiでNeural-ART向けにコンパイル

```
# TFLite(int8)モデルをNeural-ARTターゲットでコンパイル（公式ドキュメントの例）
stedgeai generate -m mobilenet_v2_0.35_224_fft_int8.tflite \
    --target stm32n6 --st-neural-art

# ONNX(QDQ int8)でも同様
stedgeai generate -m model_int8.onnx --target stm32n6 --st-neural-art
```

`--st-neural-art`を付けるとNPU用のコンパイルが走り、NPUで実行できる層はマイクロコードに、非対応の層はCortex-M55用コードに振り分けられます。コンパイル時の最適化方針やメモリ割り当ては、**コンパイルプロファイル（neural_art.json）とメモリプール記述ファイル（stm32n6.mpool）**で制御します。リンカスクリプトでセクション配置を決めるのと同じ感覚で、「重みをどのメモリに」「アクティベーションをどのRAMに」置くかをここで設計します。

生成されたレポートには、各レイヤのNPU/CPU割り当て・メモリ使用量・推定サイクルが出力されます。**ここでCPUフォールバックが多発していたら、モデル側のオペレータを見直すサイン**です。

### Step 3〜4：ビルド・署名・外部フラッシュへの書き込み

N6はフラッシュレスのため、書き込み対象は外部フラッシュです。ブートROM→FSBLと続く署名付きブートチェーンが各段のヘッダを検証するため、アプリケーションバイナリにも署名ツールでヘッダを付与します。ST公式Getting Started（画像分類）の手順は次の通りです。

```
# 1. ビルド済みバイナリに署名（ブートチェーンが検証するヘッダを付与）
# ※パスはプロジェクト構成に合わせて読み替え（公式READMEでは build/Application// 配下）
STM32_SigningTool_CLI -bin build/Project.bin -nk -t ssbl -hv 2.3 \
    -o build/Project_sign.bin

# 2. 外部フラッシュ用ローダを指定して書き込み（STM32N6570-DKの例）
export DKEL="<CubeProgrammer>/ExternalLoader/MX66UW1G45G_STM32N6570-DK.stldr"

# FSBL（第一段ブートローダ）
STM32_Programmer_CLI -c port=SWD mode=HOTPLUG -el $DKEL -hardRst -w FSBL/ai_fsbl.hex
# ネットワーク重みデータ
STM32_Programmer_CLI -c port=SWD mode=HOTPLUG -el $DKEL -hardRst -w Model/network_data.hex
# 署名済みアプリケーション（外部フラッシュ 0x70100000 へ）
STM32_Programmer_CLI -c port=SWD mode=HOTPLUG -el $DKEL -hardRst -w build/Project_sign.bin 0x70100000
```

開発中はボード上のブートスイッチを**デベロップメントモード**（RAMに直接ロードしてデバッグ）に、確認後は**Boot from Flash**に切り替えて電源再投入で起動します。従来のSTM32のように「内蔵フラッシュにELFを焼いて終わり」ではなく、**FSBL・重み・アプリの3点を外部フラッシュの決められたアドレスに配置する**という、MPU（STM32MP1等）に近いブートフローになる点が最初の関門です。

## メモリ制約の現実：4.2MB SRAMとフラッシュレス構成

N6採用可否の8割はメモリ設計で決まります。押さえるべき構造は次の通りです。

### メモリ階層と配置の優先順位

Neural-ARTのコンパイラは、推論中の中間バッファ（アクティベーション）を次の優先順位で割り当てます。
1. **NPU専用RAM（NPURAM/AXISRAM3〜6）：**NPUアクセスに最適化された最速の領域。コンパイラはまずここを使う
2. **汎用AXISRAM（AXISRAM1〜2）：**NPU RAMが埋まった場合の次候補。アプリケーションと取り合いになる
3. **外部メモリ（PSRAM/フラッシュ）：**最終手段。ここに落ちた時点で性能は大きく低下する

重み（読み出し専用）は外部Octo-SPIフラッシュに置くのが標準構成ですが、**外部メモリへのアクセス頻度が推論時間を支配する**ため、頻繁に読むデータをどこまで内蔵SRAMに載せられるかが性能チューニングの本丸です。この配置は前述のmpoolファイルで明示的に制御できます。

### 実務上のサイズ感
- 内蔵SRAMは合計**4.2MB**。ただしカメラフレームバッファ、表示バッファ、アプリのヒープ/スタックもここに同居するため、**アクティベーションに使える量は構成次第で大きく目減り**します。800×480のRGB565ダブルバッファだけで約1.5MBを消費する計算です
- int8量子化後で**数MB級までのCNN**（MobileNet系、YOLO系の小型構成など）が現実的な守備範囲。STM32モデルZooに量子化済みの参照モデルが揃っているので、まず近いモデルの実測値から逆算するのが早道です
- それを超えるモデルは、入力解像度の削減・チャネル削減・蒸留でN6に収めるか、素直に上位プラットフォームへ。**「量子化すれば何でも載る」わけではない**点は顧客説明でも強調すべきポイントです

### フラッシュレスであることの設計影響

STM32N6の内蔵不揮発メモリはOTP（ワンタイムプログラマブル）領域のみで、ユーザーフラッシュはありません。したがって自社基板では、
- XSPI接続の外部NORフラッシュ（DKはMacronix MX66UW1G45G＝1Gbit品を採用）を必ずBOMに載せる
- ブートROM→FSBL→アプリという署名付きブートチェーンを製造工程に組み込む（署名鍵の管理体制を含む）
- 必要に応じてHexadeca-SPI PSRAMを追加し、フレームバッファや大きなアクティベーションを逃がす

という設計判断が必要です。従来のSTM32Fシリーズ的な感覚で基板を起こすと確実に手戻りするため、**メモリ構成は最初のブロック図の段階で確定させる**ことをお勧めします。

## 量産採用の判断ポイント

評価ボードでデモが動くことと、量産製品として成立することの間には距離があります。弊社が受託案件でチェックしている観点を挙げます。
1. **精度の量産条件での検証：**int8量子化後のモデルを、実運用の照明・画角・季節変動を含むデータで再評価する。評価はPC上のシミュレーションだけでなく、stedgeaiのvalidate機能や実機で行う
2. **性能マージン：**目標フレームレートに対して実測で余裕があるか。CPUフォールバック層が将来のモデル更新で増える可能性も見込む
3. **熱設計：**ファンレスが成立するかは筐体条件次第。NPU効率が高いとはいえ、800MHz CPU＋1GHz NPU＋カメラISPをフル稼働させる構成では実測での熱評価が必須
4. **セキュアブートと鍵運用：**署名付きブートは量産では「やるかどうか」ではなく「どう運用するか」の問題。OTPへの鍵情報書き込みは文字通り一度きりのため、製造フローの設計を先に固める
5. **モデル更新の運用設計：**N6ではモデル更新＝外部フラッシュのファーム更新。OTA更新の仕組み（二面化、失敗時のロールバック）を初期設計に含める
6. **部品供給と単価：**MCU単価は数量・パッケージ・セキュリティ機能の有無（N657/N647等）で変わるため、代理店見積もりを早期に取る。外部フラッシュ・PSRAMも含めたセットでBOMを比較する
7. **ツールチェーンのバージョン固定：**ST Edge AI Coreは活発に更新されており、バージョン間でコンパイル結果（性能・メモリ配置）が変わり得る。量産開発ではツールバージョンをプロジェクトで固定し、更新時は回帰確認する

## よくある落とし穴と対策
| 症状・つまずき | 原因 | 対策 |
|  float32のONNXを渡してもNPUで動かない |  Neural-ARTはint8量子化済みモデルが前提 |  QDQ形式のint8 ONNX、またはfull-integer量子化のTFLiteを用意してからstedgeaiに渡す |
|  NPU搭載のはずが推論が想定より遅い |  非対応オペレータのCPUフォールバック多発、またはアクティベーションが外部メモリに溢れている |  stedgeaiの生成レポートでレイヤ割り当てとメモリ配置を確認。対応オペレータ表に合わせてモデルを再設計 |
|  書き込んだのに起動しない |  署名なしバイナリ、アドレス誤り、ブートスイッチがデベロップメントモードのまま |  STM32_SigningTool_CLIでの署名、FSBL/重み/アプリの書き込みアドレス、スイッチ設定を順に確認 |
|  外部フラッシュに書き込めない |  外部ローダ（.stldr）未指定 |  STM32_Programmer_CLIに`-el`でボード対応の外部ローダ（DKならMX66UW1G45G_STM32N6570-DK.stldr）を指定 |
|  量子化後に精度が数％以上落ちる |  校正データが実運用分布とずれている |  現地環境で収集した画像を校正データに追加。per-channel量子化を使用。層単位で精度影響を切り分け |
|  SRAMが足りずビルド構成が破綻 |  フレームバッファ・アプリ領域・アクティベーションの取り合いを設計していない |  mpoolファイルでメモリプールを明示設計。解像度・バッファ数の見直し。必要なら外部PSRAM追加 |       ** デバッグの定石
- **まずST Edge AI Developer Cloudで実機ベンチマーク：**手元にボードがなくても、レイテンシ・メモリ・レイヤ割り当てが確認できる
- **stedgeaiのレポートを読む習慣：**NPU/CPU割り当てとメモリ配置はすべてレポートに出る。感覚ではなくレポートで議論する
- **モデルZooの参照モデルと比較：**自作モデルが極端に遅い場合、同規模の公式モデルの実測値と比べると原因の当たりが付く

## まとめ

###  この記事のまとめ
- STM32N6はST初のNPU搭載MCU。Cortex-M55 800MHz＋Neural-ART（1GHz・最大600 GOPS・約3 TOPS/W）で、マイコン単体の画像AIが実用域に入った
- 0.6 TOPSはJetsonの代替ではなく、「ファンレス・低電力・瞬時起動・制御との同居」が効く単機能ビジョンAIの守備範囲
- 開発はSTM32N6570-DK（約224ドル、カメラ・LCD付属）＋無償のST Edge AI Core（stedgeai CLI）＋STM32モデルZooで始めるのが最短
- モデルはint8量子化（per-channel）が前提。`stedgeai generate --target stm32n6 --st-neural-art`でNPU用にコンパイルし、非対応層はM55にフォールバック
- 内蔵SRAM 4.2MB・フラッシュレス構成が最大の制約。メモリ配置（NPU RAM→AXISRAM→外部メモリ）と署名付きブートフローを初期設計で確定させる
- 量産判断では、量子化後精度の実環境検証・熱・鍵運用・OTA・ツールバージョン固定までを含めて評価する

STM32N6は「マイコンの開発文化のまま画像AIを製品に入れられる」初めての選択肢です。一方で、フラッシュレスのブート設計や量子化前提のモデル設計など、従来のSTM32ともLinuxエッジAIとも違う勘所があります。PoCの段階から量産を見据えた設計でお困りの際は、お気軽にご相談ください。

STM32N6での試作評価、既存STM32製品へのAI機能追加、JetsonやRaspberry Piからの置き換え検討まで、[組込み制御・マイコン開発](https://technosphere.co.jp/embedded)および[AIソリューション開発](https://technosphere.co.jp/ai-solution)として対応しています。   ／エッジAI開発のご相談はこちら＼

### STM32N6・エッジAIの受託開発／PoC支援

モデル選定・量子化・N6実装からJetson/ラズパイとのプラットフォーム比較検証、量産設計まで一貫対応。カメラ×AIの現場実装は、弊社エッジAIプラットフォーム「GENBA IQ」の知見でサポートします。  [GENBA IQを見る](https://technosphere.co.jp/genba-iq) [エッジAI開発の相談](https://technosphere.co.jp/contact)

## よくある質問（FAQ）   ** STM32N6のNeural-ART NPUはどの程度の性能ですか？

Neural-ART Acceleratorは1GHz動作で最大600 GOPS、電力効率は約3 TOPS/WというST内製のNPUです。約300個の構成可能なMACユニットと2本の64ビットAXIバスを持ち、CPU（Cortex-M55 800MHz）だけで推論する従来のSTM32と比べて大幅に高速です。画像分類・物体検出・姿勢推定などのint8量子化済みCNNモデルがマイコン単体で実用速度で動作します。   ** JetsonやRaspberry PiではなくSTM32N6を選ぶべきなのはどんなケースですか？

必要なAI処理が0.6 TOPS以内に収まり、ファンレス・低消費電力・低コスト・起動の速さ・リアルタイム制御との同居が求められるケースです。逆にLLM/VLMの実行、複数カメラの同時解析、頻繁なモデル差し替えが必要な場合は、Jetson Orin Nano（最大67 TOPS）やRaspberry Pi + AIアクセラレータ（Hailo-8Lで13 TOPS）などLinuxベースのプラットフォームが適します。   ** 学習済みのONNXモデルはそのまま動きますか？

そのままでは動きません。重みとアクティベーションをint8（scale/offset形式、per-channel）に量子化したモデルが前提です。量子化済みのONNX（QDQ形式）またはTFLiteモデルを `stedgeai generate -m model.tflite --target stm32n6 --st-neural-art` のようにコンパイルして組み込みます。NPU非対応のオペレータは自動的にCortex-M55側にフォールバックされます。   ** STM32N6に内蔵フラッシュはありますか？

ありません。STM32N6はフラッシュレス構成で、4.2MBの内蔵SRAMと外部シリアルフラッシュ（XSPI接続）を組み合わせて使います。電源投入後はブートROMが外部フラッシュから署名検証済みのFSBLを内蔵RAMにロードして起動します。量産設計では外部フラッシュの選定・署名フローを最初から織り込む必要があります。   ** 開発を始めるには何が必要ですか？

評価ボードはカメラ・LCD付きのSTM32N6570-DK（実売220ドル台）か、安価なNUCLEO-N657X0-Q（実売80ドル弱）。ソフトウェアは無償のST Edge AI Core（stedgeai CLI）、STM32CubeIDE、STM32CubeProgrammerが基本セットで、STM32モデルZoo（GitHub）に学習済みモデルとサンプルアプリが公開されています。ブラウザから実機ベンチマークできるST Edge AI Developer Cloudも利用できます。   ** 動かせるモデルサイズの目安は？

アクティベーションは内蔵4.2MB SRAM内に収めるのが性能上の前提で、重みは外部フラッシュに置けますが、外部メモリアクセスが増えるほど推論は遅くなります。int8量子化後で数MB級までのCNNが現実的な目安です。それを超えるモデルは、アーキテクチャの見直しか上位プラットフォームの検討をお勧めします。      # STM32N6 # Neural-ART # NPU # エッジAI # Cortex-M55 # ST Edge AI # TinyML # マイコン開発

##   次に読む｜エッジAI・STM32関連記事
-  [STM32 シリーズ STM32Cube.AI で TinyML を量産品質に｜メモリ配置最適化の決め技 NPU以前の定番・CPU推論TinyMLの量産ノウハウ](https://technosphere.co.jp/blog/stm32-cube-ai-tinyml)
-  [エッジAI Raspberry Piで動かすvLM完全ガイド N6では届かないVLM級のエッジAIをLinuxボードで実現](https://technosphere.co.jp/blog/raspberry-pi-vlm-edge-ai)
-  [STM32 シリーズ STM32 + FreeRTOS 入門｜タスク・キュー・セマフォ 推論と制御を同居させるタスク設計の基礎](https://technosphere.co.jp/blog/stm32-freertos-intro)
-  [開発実績 組込み制御・マイコン開発 実績紹介 STM32案件を含む20年超の受託開発事例](https://technosphere.co.jp/embedded-achievements)
    [技術コラム一覧に戻る](https://technosphere.co.jp/blog/)