In Silico

Physical AI

ExecuTorchのCortex-M対応：PyTorchのモデルをマイコンで動かす

2026/11/3

🤖 AIを使用して執筆

  • ExecuTorch
  • マイコン
  • エッジAI
  • TFLM
  • TensorFlow Lite Micro
  • PyTorch
  • Cortex-M
  • CMSIS-NN
  • MLPerf Tiny
  • Cortex-M55
  • メモリ計画
  • インタプリタ
  • アリーナ
  • 量子化
  • カーネル
  • コード生成
  • 重み
  • RAM
  • フラッシュメモリ
  • DSP
  • NPU
  • ISA
  • Ethos-U
目次
背景・問い・要点
背景

マイコン（MCU、Microcontroller Unit）は、家電やセンサー機器に組み込まれる小さな計算機で、使える RAM（Random Access Memory）は数百 KiB ほどしかない。マイコンで機械学習モデルの推論を動かせれば、音声のキーワード検出や異常の検知を、クラウドに送らずに機器の中で済ませられる。推論の途中では、各層の入力と出力の数値の配列（テンソル）が RAM に置かれ、どのテンソルを RAM のどの位置に置くかを決める処理を、メモリ計画と呼ぶ。

学習には PyTorch が広く使われているが、PyTorch で学習したモデルをマイコンに載せるには、これまで別の形式への変換を経る必要があった。マイコン向けの推論ライブラリとして実績のある TFLM（TensorFlow Lite for Microcontrollers）は、TensorFlow Lite 形式に変換したモデルを動かす。

ExecuTorch は、PyTorch のモデルを端末で実行するための PyTorch のプロジェクトである。2026年10月、ExecuTorch に Arm の Cortex-M という CPU（Central Processing Unit）コア向けのバックエンド（書き出しと実行を担う部分）が加わった1。

問い

ExecuTorch の Cortex-M 対応で、PyTorch のモデルをマイコンで動かすことはどう可能になり、開発者は何を得るのか。

要点

ExecuTorch は Cortex-M 向けのバックエンドを加え、PyTorch のモデルを別の形式に変換せずに、CPU だけのマイコンで動かせるようにした。メモリの配置などを PC での書き出し時に決めるので、必要な RAM が書き込む前に分かる。

バックエンドは Beta で、対応しない演算子は高速化されずに動く。TFLM と比べた作り手の測定では、遅延の差は最大 1 割ほどで、RAM とフラッシュの使用量は多くのモデルで少なかった。

モデル・例示

PyTorch のモデルの 3 つのテンソルの配置を、PC での書き出し時に決める

※ この節の例は、説明のために作った架空のものです。

ExecuTorch では、PyTorch のモデルを PC で書き出すときに、テンソルを RAM のどこに置くかまで決まる。マイコンはその計画どおりに実行するだけなので、必要な RAM が書き込む前に分かる。PyTorch で学習した小さなキーワード検出モデルを、Cortex-M55 のボードに載せるとする。モデルは 2 つの層からなり、入力の大きさと層の順序は固定とする。このため、各テンソルの大きさと、どの層の計算中に使われるかは実行前に決まる。テンソルは次の 3 つとする。

  • 入力 A（16 KiB）：層 1 が読む。
  • 層 1 の出力 B（24 KiB）：層 1 が書き、層 2 が読む。
  • 層 2 の出力 C（12 KiB）：層 2 が書く。

A は層 1 が終わると要らなくなり、C は層 2 で初めて作られるので、A と C が同時に RAM にある時点は無い。そこで C を A と同じ位置に置ける。配置は A を 0〜16 KiB、B を 16〜40 KiB、C を 0〜12 KiB とし、必要な RAM は 40 KiB になる。3 つを別々に置けば 16+24+12=5216 + 24 + 12 = 52 KiB である。

ExecuTorch では、この配置を開発者の PC が書き出しの時点で計算し、実行用のファイル .pte に入れる21。

  1. 開発者のPC1. モデルを書き出す。A を 0、B を 16、C を 0 KiB の位置に置く計画を作り、.pte に入れる
  2. 開発者のPC2. 計画した領域が 40 KiB であることを、書き込む前に確かめる
  3. 開発者のPCマイコン3. .pte をファームウェアに入れて書き込む
  4. マイコン4. 推論のたびに、.pte の計画どおりの位置へ A・B・C を書く

この例から言えること

  1. PyTorch のモデルを別の形式に変換せずに書き出し、そのままマイコンに載せられる。
  2. テンソルの配置は PC での書き出し時に決まるので、この例の 40 KiB という必要な RAM が、書き込む前に分かる。マイコンは実行時にメモリを計画しない。
  3. 計画は対象のコアに合わせて作るので、対象のコアを変えるときは書き出しをやり直す。

Cortex-M バックエンドは、配置・重み・カーネルの決定を書き出し時に済ませ、端末は固定の計画を実行する

ExecuTorch は、PyTorch のモデルを端末で実行するための PyTorch のプロジェクトである。PyTorch Mobile が使う TorchScript に依らず、PyTorch 2 のコンパイラと書き出しの仕組みを使う3。設計の原則は、サードパーティの中間表現へ変換せずにモデルを端末で動かせるようにすることである4。プロジェクトは Meta、Arm、Apple、Qualcomm などの企業が支え、GitHub の星は 5,146 で、リポジトリは 2022年2月に作られた3。

Cortex-M バックエンドは、書き出し時に主に次の処理を行う1。

  1. テンソルと作業用バッファの配置を事前に決める。メモリ計画は書き出しの最後の処理で、値が書き換わる各テンソルの大きさと生存期間（作られてから最後に読まれるまでの区間）から、固定サイズの領域への配置を決める2。
  2. 量子化したモデルで整数と実数の換算に使う係数（スケールとゼロ点）を、整数の乗数とシフトに事前計算して、推論を固定小数点だけで行えるようにする。
  3. 畳み込みの重みを、PyTorch の並びから CMSIS-NN（Common Microcontroller Software Interface Standard – Neural Network）が期待する並びに入れ替える。CMSIS-NN は、Arm が公開する Cortex-M 向けのニューラルネットワーク用カーネル（演算ごとの実装）のライブラリである。
  4. 対象コアの ISA（Instruction Set Architecture、命令セット）に合うカーネルを選ぶ。ISA はコアによって、スカラー命令だけ、DSP 拡張命令まで、ベクトル演算の拡張命令 MVE（M-Profile Vector Extension、別名 Helium）まで、と階層になっている。

端末は、事前に決まった計画を実行するだけで、テンソルのためのヒープも実行時のメモリ管理も使わない1。作り手は、この事前のメモリ計画によって RAM の使用量が決まった値になり、上限を持つと書く1。また、CPU の種類と ISA の階層を書き出し時に指定することを、作り手は実行時にカーネルを選び分ける負担をなくす利点として説明する1。そのため、対象のコアを変えるときは書き出しをやり直す。対象のマイコンが 1 種類に固定された製品では、この手間は小さい。ブログの手順では、書き出した .pte をランタイムと CMSIS-NN とともにファームウェアに結合して書き込む1。

この仕組みにより、PyTorch のモデルをほかの形式へ変換せずに、CPU だけのマイコンで動かせる。従来は、Arm の NPU（Neural Processing Unit）である Ethos-U を経由するか、ほかの形式に変換する必要があった1。

得られるもの：変換が要らず、RAM の使用量が書き込む前に決まる

PyTorch で学習したモデルを、TensorFlow Lite 形式に変換せずに Cortex-M に載せられる。変換の手間は、PyTorch の側の資料が ExecuTorch で解消する課題として挙げていたものである1。端末はテンソルのためのヒープも実行時のメモリ管理も使わず、RAM の使用量は書き出し時に決まった値になる1。

ExecuTorch の作り手（Meta と Arm の開発者）は、同じ Alif E8 の Cortex-M55 で、同じ試験用ソフトウェアと CMSIS-NN 8.0.0 を使い、MLPerf Tiny の 4 モデルを TFLM と比べた。ExecuTorch の推論遅延は 4 モデル中 3 モデルで 2.3% から 10.6% 短く、オートエンコーダではほぼ同じ（0.27% 長い）である。作り手は、両者の差は遅延よりメモリで大きいと書く。フラッシュメモリの使用量は 4 モデルすべてで少なく、差は最大 21.1% である。RAM は ResNet-8 を除く 3 モデルで少なく、オートエンコーダでは 46.1% 少ないが、このモデルの ExecuTorch 側の使用量は 5.2 KiB と小さい。ResNet-8 だけ 1.2% 多い5。この測定は作り手自身のものである。モデルは共通の学習済みの重みから作られたが、量子化と較正の条件はフレームワークごとに異なるので、同一条件の比較ではない5。2026年11月2日の検索で、第三者による比較は見つからなかった。遅延の差は最大 10.6% で、条件のそろわない測定でもあるので、本稿は速度を選択の決め手にしない。速度が製品の要件なら、この測定では優劣を決められないので、自分のモデルで両方を測ることになる。

使う前に確かめること：バックエンドは Beta で、対応しない演算子は高速化されない

ExecuTorch の Cortex-M バックエンドは Beta で、MLPerf Tiny と MobileNetV2 などの小さなモデルで検証されている。バックエンドが対応しない演算子は、32 ビット浮動小数点のまま、高速化されていない汎用のカーネルで動く。そのため README は、書き出し後にグラフを調べて、高速化された割合を確認するよう勧める6。README によれば、バックエンドの書き出しには既定の経路と実験的な経路があり、ブログの手順が使うのは実験的な経路である。この経路では、対応しない構成の畳み込みなどの演算子があると書き出しが失敗し、そのモデルは既定の従来の経路で書き出す6。ブログは、浮動小数点のカーネルと演算子の対応の拡大を今後の予定に挙げるが、これは作り手の計画であり、現時点では成熟度の差が残る1。

TensorFlow Lite Micro との違い：メモリを計画する時点と、対象のハードウェア

TFLM でも、PC で書き出す代わりに、マイコンが起動時の初期化でテンソルの配置を計画する。アプリはアリーナと呼ぶ RAM の領域の大きさを決めて渡し、アリーナが足りなければ初期化がアプリにエラーを返す78。

TFLM は、TensorFlow Lite のモデル形式と変換の仕組みを再利用するマイコン向けの推論ライブラリで、LiteRT か TensorFlow で変換したモデルを動かす79。論文は Google と Harvard の著者が 2020年に arXiv で公開し、2021年の MLSys に発表したもので、TFLM が本番で使われている Google のアプリケーションを支えていると書く7。GitHub の星は 3,141 で、現在のリポジトリは 2021年4月に作られた9。

論文は、インタプリタを採用した理由に、現場にある機器のモデルを更新できることを挙げる。インタプリタは、モデルのファイルを実行時に読み込み、その中の演算を順に呼び出すプログラムである。論文によれば、もう一つの方式であるコード生成はモデルの構成と重みを実行ファイルに埋め込むので、モデルを変えるには実行ファイル全体を入れ替える7。ExecuTorch も、ランタイムが .pte を読み込んで実行する方式であり、コード生成ではない4。どちらの資料もモデルをファームウェアに結合する手順を例に示しており17、現場での更新のしやすさを両者で比べた資料は、本稿が読んだ範囲にはない。

TFLM のメモリ計画は端末の上で行われる。アプリが RAM の領域（アリーナ）を渡し、確保は初期化の間だけで行われ、計画は端末上のモデルの準備の段階で作られる7。既定の計画器 GreedyMemoryPlanner は、モデルのグラフ全体を見て、できるだけ多くの領域を使い回す8。論文は、実行時の計画は事前の計画より準備の負担が大きいが、多くのモデルにそのまま対応できると説明する7。

TFLM で書き込む前に必要な量の目安を得るには、ホスト向けのビルドを使う。アリーナの使用量を記録するインタプリタは、RecordingMicroInterpreter という名前で用意されている8。ただし、TFLM 自身の試験は x86-64 で測った使用量を基準にし、64 ビットでない機器ではその値に許容幅を足した上限を超えないことだけを確かめている10。ホストで記録した値は、端末の値と同じではない。

TFLM にも、配置の一部をホストで決める仕組みがある。ホスト PC で作ったテンソルの配置の計画を、モデルのメタデータに入れて使える8。ただし、ホストの計画が固定するのは指定したテンソルの位置であり、作業用のバッファや持続的な領域は、端末の初期化時に計画器が確保する8。

TFLM が動かすのは変換したモデルなので9、PyTorch で学習したモデルを TFLM に載せるには TensorFlow Lite 形式への変換を経る。PyTorch の側の資料は、この変換の手間を ExecuTorch が解消する課題として挙げている1。

対象ハードウェアの幅は、TFLM に実績がある。TFLM の README は、第 1 階層のテスト環境に Arm Cortex-M（CMSIS-NN）、Cadence Xtensa、Qualcomm Hexagon、x86 を挙げる9。本稿が読んだ資料では、ExecuTorch の Cortex-M バックエンドの対象は Arm のコアである。ExecuTorch にも Cadence の Xtensa 向けのバックエンドがあるが、対応する DSP の一覧には「進行中」と書かれている11。

  1. PyTorch で学習し、対象が Arm の Cortex-M なら、ExecuTorch を候補にする。利点は、TensorFlow Lite 形式への変換が要らないことと、必要な RAM の量を書き込む前に確かめられることである。欠点は、バックエンドが Beta であることと、対象のコアを変えるたびに書き出しをやり直すことである。
  2. 対象が Xtensa や Hexagon などの DSP なら、CI で試験されている TFLM を第一の候補にする。メモリ計画は端末の初期化で行われるので、書き込む前に量の目安を得るには、ホスト向けのビルドで使用量を記録する手順が要る。
  3. TensorFlow で学習したモデルや、MLPerf Tiny のように TensorFlow Lite 形式で配られている参照モデルを使うなら5、変換の手間がない TFLM が候補になる。
出典11件

  1. Ascani ほか「Bringing ExecuTorch to Arm Cortex-M CPUs」PyTorch Blog, 2026-10-15. https://pytorch.org/blog/bringing-executorch-to-arm-cortex-m-cpus/ — 書き出し時の処理、ヒープなしの実行、従来の変換の手間、今後の予定。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13

  2. PyTorch「Memory Planning」ExecuTorch Docs（2026-11-02 取得）. https://github.com/pytorch/executorch/blob/main/docs/source/compiler-memory-planning.md — メモリ計画が書き出し前の最後の処理で、固定サイズの領域に配置すること。 ↩ ↩2

  3. PyTorch「ExecuTorch Overview」ExecuTorch Docs と GitHub リポジトリ（2026-11-02 取得）. https://github.com/pytorch/executorch/blob/main/docs/source/intro-overview.md — PyTorch Mobile との違い。星 5,146、作成は 2022年2月。 ↩ ↩2

  4. PyTorch「How ExecuTorch Works」ExecuTorch Docs（2026-11-02 取得）. https://github.com/pytorch/executorch/blob/main/docs/source/intro-how-it-works.md — 変換を要さない設計原則と、計画を事前に行いランタイムは実行だけを担うこと。 ↩ ↩2

  5. Ascani ほか「Bringing ExecuTorch to Arm Cortex-M CPUs」Arm Community Blog, 2026-10-19. https://developer.arm.com/community/arm-community-blogs/b/ai-blog/posts/bringing-executorch-to-arm-cortex-m-cpus — 同一ボードでの TFLM との比較。作り手の測定で、量子化は別々。 ↩ ↩2 ↩3

  6. PyTorch「backends/cortex_m/README.md」GitHub（2026-11-02 取得）. https://github.com/pytorch/executorch/blob/main/backends/cortex_m/README.md — Beta の位置づけと、未対応の演算子が fp32 のポータブルカーネルで動くこと。 ↩ ↩2

  7. David ほか「TensorFlow Lite Micro: Embedded Machine Learning for TinyML Systems」MLSys, 2021. https://arxiv.org/abs/2010.08678 — インタプリタ採用の理由、アリーナ、初期化時だけの確保、端末上の計画。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  8. TensorFlow「Memory Management in TensorFlow Lite Micro」tflite-micro Docs（2026-11-02 取得）. https://github.com/tensorflow/tflite-micro/blob/main/docs/memory_management.md — アリーナ、貪欲法の計画器、ホストで作る計画、使用量の記録。 ↩ ↩2 ↩3 ↩4 ↩5

  9. TensorFlow「tflite-micro」GitHub（2026-11-02 取得）. https://github.com/tensorflow/tflite-micro — 変換したモデルを動かすこと、第 1 階層の対象。星 3,141、作成は 2021年4月。 ↩ ↩2 ↩3 ↩4

  10. TensorFlow「memory_arena_threshold_test.cc」tflite-micro（2026-11-02 取得）. https://github.com/tensorflow/tflite-micro/blob/main/tensorflow/lite/micro/memory_arena_threshold_test.cc — 基準値は x86-64 で測り、64 ビットでない機器では上限だけを確かめること。 ↩

  11. PyTorch「backends/cadence/README.md」GitHub（2026-11-02 取得）. https://github.com/pytorch/executorch/blob/main/backends/cadence/README.md — HiFi Audio と Fusion G3 への対応が進行中であること。 ↩

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。