ExecuTorch：Cortex-M CPUへの直接配備、デバイス別の事前最適化

1. モデル変換ではなく同じツール内で準備する

従来のArm対応がEthos-Uニューラルネットワークアクセラレーター向けだったのに対し、今回はCortex-M CPUでの実行経路が追加された。別のフレームワークへ移行しないという意味であり、デバイスに合わせたエクスポートや数値を小さな整数で表す量子化まで省くわけではない。

バックエンドは実行前に、モデルの演算をCortex-M向けの最適化演算群であるCMSIS-NNの呼び出しに変換する。基本命令のみを使うコアから信号処理命令やベクトル演算に対応したコアまでを対象とし、コアごとの演算選択はコンパイル時に完了する。

2. 実行コストを事前準備に移す

演算の接続構造であるグラフの最適化、重みの配置、メモリ計画も事前に行う。モデルが計算する多次元の数値配列であるテンソルと一時バッファの配置を決め、推論中のテンソル用の動的メモリ割り当てをなくす。実行負担を減らす一方、開発者は対象CPUと対応命令、メモリ容量を把握し、必要に応じて高速メモリに置くデータも指定する。

配備の順序は、エクスポート、キャリブレーションデータによる量子化、再エクスポート、デバイス用演算への変換、ファイル保存となる。専用の量子化器がCMSIS-NNの配置要件に合う8ビット整数のグラフを作成する。以下は原文の例にあるエクスポート部分だ。

# 1. Export
model = MyModel().eval()
example_inputs = (torch.randn(1, 1, 49, 10),)
exported = torch.export.export(model, example_inputs)

出力ファイルをランタイムおよびCMSIS-NNライブラリとともにファームウェアに組み込むと、デバイスが事前に準備されたグラフを実行する。

3. アクセラレーターが処理できない演算も続けて実行する

Ethos-U搭載デバイスでは、対応する演算をアクセラレーターに渡し、残りは同じグラフ内でCPUが担う。CPU演算の量子化・データ配置・形状の条件が合えばCMSIS-NNで実行し、合わなければ非加速の汎用カーネル、つまり演算を実際に実行する実装コードを使う。一部の演算がアクセラレーターの対象から外れても配備経路は残るが、その区間まで加速されるとはいえない。

4. 同じ条件で遅延時間とメモリを確認する

執筆者らは、小型デバイス向け推論ベンチマークMLPerf Tinyの5モデルのうち4モデルを測定した。除外された5番目のテストは連続ウェイクワード検出で、複数フレームを推論するテスト基盤が必要になる。したがって、今回の単一推論の数値が連続入力の処理まで検証したわけではない。下表は、同じハードウェアと量子化条件におけるモデル別の遅延時間とメモリ要件を示す。

表：4モデルの推論遅延時間とメモリ使用量。フラッシュコードは必要な演算のみを含むコードサイズ、フラッシュ合計はモデルも含む総量を示す。

条件：Alif Ensemble E8、Cortex-M55高性能シングルコア400 MHz、Ethos-U NPU不使用、CortexMQuantizerでINT8量子化、Alif ML Embedded Evaluation Kit、必要な演算のみビルド、GCC 15.2.1、コアランタイム-Oz・カーネル-O3、ログ無効。公式提出ではなく独自測定のため、MLCommonsの公開ランキング結果とは直接比較できない。

単位：遅延時間ms、メモリKiB

この条件では、4モデルともRAM使用量は90 KiB未満だった。

5. 実機ではメモリ配置も性能を変える

条件：人物検出デモ、Renesas EK-RA8D1、Cortex-M85 480 MHz、INT8 µYOLO、128×128 RGB入力

最大RAMは254 KiB、フラッシュ合計は640 KiBだった。負荷の高い演算の重みをCPUに密結合されたデータメモリであるDTCMに置き、命令キャッシュを有効にすると、推論遅延時間は191 msから24 msに短縮された。

デモ全体のスループットである毎秒12.7フレームは、推論時間と区別する必要がある。

計算や重みごとに異なるビット数を使う混合精度の適用範囲拡大、浮動小数点カーネルの接続、追加の演算対応とハードウェア検証が今後の課題として示された。

今回の変更の価値は変換ツールを減らす点にあり、実際の配備性能は対象デバイスの演算対応とメモリ配置を併せて検討して初めて判断できる。