AI概要¶

概要¶

本ページでは、SF32でオンデバイスAIを実装する際のデバイス選定、実際の実行経路に合わせたモデルの準備、メモリーの見積もり、製品のエネルギー予算内で推論をスケジュールする方法を説明します。AIアクセラレーターのアーキテクチャで説明するハードウェアの基礎知識を前提としています。アクセラレーターの役割と制約を先に把握したい場合は、まず同記事を参照してください。

SDKでは、NNACC（ニューラルネットワークアクセラレーター）HALを通じて加速対象の演算を実行できます。HALの例とRT-Threadドライバーの例は、チャネルごとの畳み込み演算（depthwise convolution）を個別に検証するもので、学習済みモデル全体の配備例ではありません。まず単一の演算が正しく動くことを確認し、モデルのランタイム、変換ツール、各層の実装との対応は別途選定・検証してください。

以下で触れる実装上の詳細はSDK v2.5.1に限定されます。これらの詳細やファミリー単位のNNACC搭載情報は、特定の品番への対応、モデル全体のランタイムや変換ツール、演算子の互換性、自動CPUフォールバック、カメラ入力のいずれも保証するものではありません。正確なSDKリビジョンと構成、チップのリビジョン、ランタイム、ボードで確認してください。

このページは、AI機能の製品要件と実装・展開を担う方を対象としています。デバイス側で何を判断するか、メモリーと消費電力をどこまで許容するか、実際のセンサーデータに対して機能をどう動かすかを扱います。ハードウェアとの境界を説明するアクセラレーターの記事を補完する内容です。

製品がローカルで判断すべきことを定義する¶

モデルではなく製品の判断から始めてください。

• スマートフォンやクラウドの往復なしに、デバイスが自身で分類または検出しなければならないことは何か。
• その判断に必要なデータは、どのセンサーから得るか。モーション、オーディオ、生体情報、カメラ、またはそれらの組み合わせか。
• その判断はどのくらいの頻度で実行する必要があり、どれだけ迅速に応答しなければならないか。
• オンデバイスモデルが誤判定した場合、どのような影響があるか。偽陽性と偽陰性では、どちらの損失が大きいか。
• 製品出荷後にモデルを更新する必要があるか。必要な場合、どのように更新するか。

これらの答えが、モデルサイズ、メモリー使用量、デバイス選定、推論の合間にどれだけ深くスリープできるかなど、後続の設計判断を左右します。

適切なSF32デバイスを選ぶ¶

すべてのSF32デバイスが同じ方法でAIワークロードを対象としているわけではありません。

この表は評価の出発点であり、モデルがメモリーに収まることや効率よく動くことを保証するものではありません。全体の負荷を踏まえ、選定した型番のメモリー、センサーインターフェース、アクセラレーターのインスタンス、SDK対応を確認してください。SDK v2.5.1のNNACCガイドでは、SF32LB55xとSF32LB56xのHCPUにそれぞれ1基、SF32LB58xのHCPUとLCPUに別々のアクセラレーターがあると説明されています。同ガイドはSF32LB52xまたはSF32LB57xのNNACC搭載状況を示していません。記載がないことを非搭載の根拠にせず、記載された個数だけではモデルの互換性やエネルギー効率を判断できない点にも留意してください。選定全体の考え方はデバイスファミリーにおける位置づけを参照してください。

モデル開発ワークフロー¶

SF32へのモデル配備は、用途が異なっても基本的には次の手順で進めます。

1. ワークステーション上でモデルを訓練または選定します。実運用時にセンサーが取得するデータに近いデータを使ってください。ノイズの少ないラボデータと、ノイズを含む実環境のセンサーデータでは、モデルの挙動が大きく異なることがあります。
2. アクセラレーター固有の変換を検討する前に、アーキテクチャの選択、プルーニング、量子化などを通じて、モデルを組み込み制約に合わせて縮小します。
3. 選択した推論ランタイムと、対象SDKが実際に対応する演算、レイアウト、数値形式に合わせて、モデルをエクスポートし、各演算を実装に対応付けます。NNACC HALがあるだけでは、モデル全体の変換ツールや計算グラフのランタイムが提供されているとは限りません。
4. 変換と量子化の後、数値的に検証します。デスクトップでの精度がそのまま引き継がれると仮定しないでください。
5. 前処理、推論、後処理をファームウェアに統合します。モデルは、より大きなパイプラインの一工程にすぎません。
6. シミュレーションだけでなく実際のハードウェア上で、レイテンシ、メモリー、電力、精度をプロファイルします。
7. Bluetooth、ディスプレイ、センサーが推論と同時にアクティブな、実際の製品に近い複合負荷でテストします。推論だけを単独で動かして確認してはいけません。

モデルだけを最適化し、前処理、バッファリング、後処理を測定しないことは、よくある統合上の問題です。これらの処理が加速した推論と同程度のコストになる場合もあるため、経路全体を測定してください。

実行時の仕様を定める¶

モデルを変換する前に、ファームウェアが満たすべき実行時の仕様を明確にしてください。

この仕様は、機械学習担当とファームウェア担当の両方でレビューしてください。モデルのテンソル形状、フォーマット、演算子構成を変更してもファームウェア側を更新していないと、ビルド時の明確なエラーではなく、精度の低下やレイテンシの不安定化として問題が現れることがあります。

演算子とフォールバックのレビュー¶

モデル選定前に、すべての演算とそのパラメーター、実際の実行経路を確認してください。CPU実装や自動フォールバックは、選択したランタイムが明示的に提供する必要があります。未対応の演算があると、配備そのものができない場合もあります。小さなモデルでも、頻繁に実行する層がCPUを使ったり、レイアウト変換を繰り返したりすると処理が遅くなります。

合格基準は「モデルが動く」ことではありません。実運用時と同じデータ分布のもとで、パイプライン全体が精度、レイテンシ、メモリー、エネルギーの各目標を満たすことです。

量子化とメモリー使用量の見積もり¶

MCU向けAIでは、コンパクトな量子化モデルがよく使われます。浮動小数点ではなく8ビット整数を使うことが多いものの、数値形式は実際の実行経路が対応するものを選びます。モデル構成を決める前に、重みだけでなく次のすべてのメモリー使用量を見積もってください。

量子化はメモリーと演算のコストを削減できますが、変換後に実環境を代表するセンサーデータで精度を再確認してください。SDK v2.5.1のガイドが加速対象として挙げるのは、arm_convolve_1x1_HWC_q7_fast_nonsquare、arm_convolve_HWC_q7_basic_nonsquare、arm_depthwise_separable_conv_HWC_q7_nonsquareです。HALの設定は8ビットのバッファーとバイアス・出力のシフト値を使います。これだけでは、現在の任意のint8モデルのゼロポイントやチャネル別スケールに直接対応すると判断できません。数値結果の等価性を確認し、未対応の各層についてCPU実装、変換、または配備不可とする処理を明確にしてください。

バッファー配置とメモリー階層¶

演算能力が足りていても、メモリー帯域がAI性能を制限する場合があります。SRAM、Flash、PSRAM、STAR-MC1の命令/データキャッシュを持つSF32デバイスでは、メモリーへのアクセス可否とバッファー配置のコストを確認してください。

• 頻繁に使うテンソルと中間バッファーは、CPUと選択したアクセラレーターの両方がアクセスできるメモリーに、必要なアラインメントとレイアウトで配置します。
• 大きな重みや使用頻度の低いデータを外部メモリーに置くのは、選択した実行経路がその配置に対応する場合に限ります。アクセラレーターがアクセスできるメモリーへのコピーが必要なら、その分のメモリー、レイテンシ、エネルギーも見積もります。
• 転送中の共有バッファーは、CPUかアクセラレーター/DMAのどちらか一方だけが使用します。ハードウェアに渡す前に、キャッシュライン境界に合わせた範囲全体を準備します。CPUが書き込んだ入力データを含むキャッシュラインをcleanし、出力領域のダーティなキャッシュラインはSDKのデバイス書き込み規則に従って処理します。完了を待ってから出力範囲を無効化し、CPUに所有権を戻してください。ハードウェアが使用中のバッファーや、そのキャッシュラインを共有する別のデータを変更してはいけません。

v2.5.1のHAL実装は各バッファーが1 MiB（1,048,576バイト）のアドレスウィンドウ境界をまたがないことと、入力とバイアスが同じウィンドウにあることを確認します。空きメモリーの総量だけでなく、実際の割り当てアドレスを検証してください。ブロッキング開始処理は完了までポーリングします。割り込み方式では、正しいIRQ処理と完了通知が必要です。戻り値を確認し、モデルのランタイムにタイムアウトがあると仮定せず、アプリケーション側で障害復旧と待ち時間の上限を設計してください。

このような混在するアクセスパターンにおけるキャッシュとメモリーシステムの考慮事項については、STAR-MC1を参照してください。

メモリー使用量の見積もり表¶

ファームウェアを統合する前に、最悪ケースの数値を使ってメモリー使用量を見積もってください。平均値だけで判断しないでください。

スタック、ヒープ、RTOSオブジェクト、ログ、OTAに必要なメモリーも確保してください。他のサブシステムをすべて無効にした場合にしか収まらないモデルは、製品に組み込める状態とはいえません。

パイプライン全体を構築する¶

アクセラレーターは、センサー入力から判断に至るパイプラインの一段階です。以下では三つの代表的な入力経路を説明します。

オーディオと音声¶

キーワードスポッティング、ウェイクワード検出、オーディオイベント分類では、推論の前にマイク入力の取り込み、フレーミング、特徴抽出が必要です。入力の取り込みとバッファリングについては、オーディオ概要を参照してください。アクセラレーターの効果を得るには、入力音声を効率よく取り込み、バッファリングすることが前提です。

モーションとセンサーフュージョン¶

ジェスチャー認識、活動分類、生体信号解析では、通常、加速度センサー、ジャイロスコープなどのデータを使います。センサー動作、取り込み、前処理、推論のエネルギーをそれぞれ測り、どこが支配的かを判断してください。レイテンシと必要な信号の検出を両立できる場合は、まとめ処理や割り込みによる取り込みでウェイクアップ回数を減らせます。ただし、常にモデルのコストより効果が大きいとは限りません。低消費電力設計の概要も参照してください。

カメラと画像入力¶

カメラ入力は、取り込み、バッファー、帯域、推論に大きな負荷をかける場合があります。実際の負荷は解像度、フレームレート、センサー動作、モデル構成によって変わります。精度を維持できる範囲で画像を縮小するか、関心領域だけを処理してください。デスクトップ向けの視覚モデルをそのまま使えると仮定せず、組み込み制約に合うモデルを選びます。

電力を意識した推論スケジューリング¶

必要な信号の検出と応答時間を満たすようにスケジューリングを選びます。定期的な判断が必要な製品では周期推論も有効です。イベントによる実行条件の制限は、必要な信号を見逃さない場合に限って採用します。

• 適した用途では、センサーのしきい値超過や音声フレームの完成など、有用な新しいデータで推論を開始します。必要なら周期処理を維持し、開始条件を変えた後は見逃しと最悪応答時間を検証します。
• レイテンシ要件が許す場合は、多数の小さな推論を実行する代わりにサンプルをバッチ処理します。
• デバイスとSDKがサポートしている場合、サンプルごとにメインCPUを起動する代わりに、軽量な常時稼働センシングを低消費電力プロセッサーに移します。
• 測定区間を明示し、実測した電源電力（電源電圧×電流）を時間積分して推論1回あたりのエネルギーを求めます。機能全体の見積もりには、取り込み、前後処理、ウェイクアップ・スリープ遷移も含めます。高速化で動作中のエネルギーが減る場合や、早くスリープに戻れる場合がありますが、効果は電流、メモリーアクセス、他のシステム動作によって変わります。

システム全体の電力設計については、低消費電力設計の概要を参照してください。継続的またはほぼ継続的に動作するAI機能を設計する際に役立ちます。

精度・レイテンシ・電力のトレードオフ¶

以下はよくある設計上のトレードオフであり、固定的な関係ではありません。実際のモデル精度とパイプライン全体のエネルギーを測定して判断してください。

調整を始める前に、製品で何を優先するか決めてください。ジェスチャー検出では、多少のレイテンシと引き換えにバッテリー寿命を延ばせる場合があります。一方、音声トリガーでは大きな遅延を許容しにくく、電力を浪費する誤検出も避ける必要があります。

モデル更新と実運用での検証¶

AI機能が発売後に改善される可能性がある場合は、早い段階でモデル更新サポートを設計してください。

• 可能な場合はモデルをファームウェアとは別にバージョン管理し、モデルパッケージに想定する入力仕様を記録します。
• 有効化前にパッケージの真正性、完全性、ランタイム・入力仕様との互換性を確認します。更新が中断されても安全に有効化できる設計とし、起動時の検証に失敗した場合は動作確認済みの版に戻せるようにします。
• キャリブレーション値、しきい値、後処理用の定数は、それらを必要とするモデルのバージョンと合わせて保存します。
• プライバシーに関わる生センサーデータを不必要に保存せず、モデルの劣化を診断できるだけの実運用データをログに記録します。
• モデル更新のたびに電力および共存テストを再実行してください。モデルの精度向上でも、システムをより頻繁に起動させるなら製品としては後退になることがあります。

AIの性能と精度のデバッグ¶

よくある間違い¶

• 対象ランタイムが実際に加速する演算子を確認する前にモデルアーキテクチャを選んでしまう。
• 最初から組み込み制約向けに設計するのではなく、デスクトップ規模のモデルを移植してしまう。
• 中間活性化に必要なメモリーを見落とし、モデルの重みだけで見積もってしまう。
• 必要な入力の検出範囲と応答時間を満たすか確認せず、推論頻度や開始条件を決めてしまう。
• ノイズの少ないラボデータだけで精度を検証し、実環境のセンサーノイズを含むデータで確認しない。
• AI機能を単体でテストし、製品への完全な統合後になって初めて共存問題を発見してしまう。
• モデルのレイテンシを最適化する一方で、その前後の前処理・後処理段階を無視してしまう。

立ち上げチェックリスト¶

• 製品がローカルで下す必要のある判断と、許容できるレイテンシ/精度/電力のトレードオフを定義する。
• コスト目標だけでなく、モデルサイズとメモリーニーズに基づいてSF32デバイスを選定する。
• まず最小限のテストモデルで、次に製品版モデルで、パイプライン全体（キャプチャ → 前処理 → 推論 → 後処理）を構築・検証する。
• 実際のモデルを変換・量子化し、現実的なセンサーデータに対して精度を検証する。
• 重み、入出力テンソル、中間活性化に必要なメモリーをまとめて見積もる。
• CPU/アクセラレーター間で共有されるバッファーのキャッシュコヒーレンシ処理を検証する。
• 周期方式またはイベント駆動方式が、必要な検出範囲、最悪レイテンシ、実測したエネルギー予算を満たすか検証する。
• Bluetooth、ディスプレイ、センサーを同時に動作させた状態で、推論あたりのエネルギーを測定する。
• 量子化、モデル、またはスケジューリングの変更後は、精度と電力を再検証する。

要点のまとめ¶

• モデル構成ではなく、製品で必要な判断とセンサーデータから始めてください。モデルは大きなパイプラインの一工程です。
• ファミリーの位置づけで候補を絞り、実際の型番、SDK、演算の対応付け、メモリー割り当て、同時実行負荷を確認してください。
• モデルファイルのサイズだけでなく、パイプライン全体（重み、テンソル、活性化、前後処理バッファー）に必要なメモリーを見積もってください。
• 必要な検出範囲を守るように周期方式かイベント駆動方式を選び、モデルの速度を消費電力の結果とみなすのではなく、機能全体のエネルギーを測定してください。
• 実環境に近いデータで精度を検証し、単独ではなく複数機能を同時に動かした状態で機能全体をテストしてください。

最終更新: 2026-10-19