**M4 Apple Neural Engine の内部 ― 第1部：リバースエンジニアリング**

「私たち」についてのメモ

このシリーズ全体を通じて 「私たち（we）」は、maderix（人間）とClaude Opus 4.6（Anthropic が開発した AI）というペアで働くことを指します。
リバースエンジニアリング・ベンチマーク・トレーニングコードは共同で開発されました――人間の直感が探索を推進し、AI がデータを解析して分析を書き上げます。

私たちはこのような人間–AI の協働がシステム研究にとって新しく自然な方法だと考えています。

• 1 人は直感的な設計者（アーキテクト）
• もう 1 人はコードを書き、実験を構築するエンジニア

すべては「Apple の Neural Engine でモデルをトレーニングできるか？」という単純な質問から始まりました。
Apple はその答えを隠したいと考えており、ANE（Apple Neural Engine）の ISA を公開せず、内部構造も文書化していません。また直接プログラミングする手段すら提供していないため、CoreML という抽象化レイヤーを介さなければなりません。CoreML はさらに最適化パスやオーバーヘッドを加えるため、ハードウェアが実際に何を行っているかを理解するのはほぼ不可能です。

そこで私たちはリバースエンジニアリングに取り組みました。数日間にわたり CoreML から IOKit カーネルドライバーまでのソフトウェアスタック全体をマッピングし、CoreML を介さずに ANE 上でプログラムをコンパイル・実行する方法を発見しました。バイナリフォーマットを解読し、真のピーク性能（Apple の「38 TOPS」という数字は誤解を招く）を測定し、最終的に推論専用に設計されたチップ上でニューラルネットワークのトレーニングが可能となりました。

これは 3 部構成シリーズの第 1 パートです。ここではリバースエンジニアリングの過程―M4 Neural Engine を実際に何があるか、そして直接対話する方法を明らかにした手順について解説します。

ANE は GPU や CPU ではない

ANE は グラフ実行エンジン ― コンパイル済みニューラルネットワークの計算グラフ全体を一括で実行する固定機能アクセラレータです。
個別の乗算加算命令を発行せず、コンパイル済みプログラム（計算グラフ全体）を送信し、ハードウェアがエンドツーエンドで処理します。

Apple は 2017 年に A11 で Neural Engine を初登場させ、2 コア設計でした。以降の世代では次第に拡張されています。

ANE の内部を調査したのは私たちだけではありません。

• hollance/neural‑engine ― Matthijs Hollemans による ANE の挙動・性能特性・サポート操作に関する包括的コミュニティドキュメント。
• aiter/ane ― Python と Objective‑C で動作する早期リバースエンジニアリング例、ANECompiler フレームワークと IOKit ディスパッチの解説。
• eiln/ane ― ANE の Linux ドライバー（Asahi Linux プロジェクト）でカーネルレベルインタフェースを明らかにしたもの。
• apple/ml‑ane‑transformers ― Apple が提供する Transformer 用リファレンス実装で、チャネル優先レイアウトや 1×1 Conv の好みといった設計パターンを確認。

しかし私たちの知る限り、以下は未踏でした。

1. CoreML を介さずに M4 で直接

   _ANEClient

   API にアクセスできること
2. メモリ上の MIL コンパイル経路を解読すること
3. CoreML のオーバーヘッドをバイパスして真のピークスループットを測定すること
4. ANE 上でモデルをトレーニングできること

私たちの手法

• AppleNeuralEngine.framework から

  dyld_info -objc

  を実行し、Objective‑C クラスとメソッドをすべてダンプ。
• CoreML が呼び出すプライベート ANE フレームワークをフックするメソッドスワッピング。
• コンパイル済み E5 バンドルのバイナリ解析でニューラルプログラムフォーマットを理解。
• 行列サイズ・グラフ深度・チャネル数を変化させてハードウェアトポロジーを推測するスケーリング分析。

AppleNeuralEngine.framework には

_ANEClient

_ANEModel

_ANERequest

_ANEIOSurfaceObject

_ANEInMemoryModel

ANE の完全ソフトウェアスタック

パブリック CoreML API からハードウェアまで：

• CoreML ― ONNX/Protobuf → MIL の便宜層
• AppleNeuralEngine.framework ―

  _ANEClient

  を介したコンパイル→ロード→評価パイプライン
• MIL (Machine Learning Intermediate Language) ― 型付き SSA 表現。例：

  function my_matmul(input_a: Tensor[float32, [N, C, D, H, W]],
                     input_b: Tensor[float32, [N, C, D, H, W]]) -> output
  

• E5 バイナリ ― FlatBuffer 構造ファイル。例：1024×1024 の matmul は約 2 688 バイト

E5 バイナリはアルゴリズム自体をエンコードするのではなく、実行時にテンソルディスクリプタで制御されるパラメータ化されたプログラムです。

メモリ上コンパイル経路

_ANEInMemoryModelDescriptor

1. NSData、NSString ではなく ―

   milText

   は UTF‑8 バイト列 (

   NSData*

   ) を期待。
2. NSDictionary、NSData ではなく ― 重みマップは重み名 →

   NSData

   ブロブ。
3. 一時ディレクトリ回避策 ― 内部のテンポラリパスが書き込み可能である必要。

M4 ANE のプロファイリング（IOKit プローブ）

特に、matmul を 1×1 コンボルーションとして表現するとスループットが大幅に向上します。

データ転送

ANE とデータをやり取りする際は IOSurfaces が使用されます ― GPU テクスチャと同じ共有メモリ機構です。
これにより、GPU と ANE の間でゼロコピーのパイプラインが可能になり、両アクセラレータが同一メモリ上で動作します。

ANE コンパイラは E5 バイナリをディスクにキャッシュします（初回コンパイルは 20–40 ms 程度；キャッシュヒットはほぼ無料）。
これは推論には理想的ですが、重みがステップごとに変わるトレーニングでは課題となります。

未調査クラスで示唆される追加機能

• _ANEChainingRequest

  ― 複数コンパイル済みモデルを単一ディスパッチでチェーンできる可能性。

• ANESharedEvents / _ANESharedSignalEvent / _ANESharedWaitEvent

  ― Metal スタイルのフェンス/シグナルプリミティブで GPU↔ANE の同期が取れるかもしれません。

• _ANEPerformanceStats

  ― ハードウェア性能カウンタへのアクセスを可能にするかも。

• ANEVirtualClient

  ― マルチプロセス共有を想定した仮想化 ANE アクセス。

未知の点

• 正確な ANE コアマイクロアーキテクチャと ISA
• グラフ内でコアがどのように操作へ割り当てられるか
• 現在のクロック周波数（DVFS により動的）
• ハードウェア性能カウンタへのアクセス可否
• SRAM トポロジー（バンク化？統合？コアごと？）

今後の展望

• Part 2 ― matmul のスケーリング、SRAM パフォーマンスクリフ、Conv が MatMul より 3 倍速い理由、Apple の「38 TOPS」主張が誤解を招く点、CoreML をバイパスすることで 2–4 倍のスループットが得られることなどをベンチマーク。
• Part 3 ― Neural Engine 上でニューラルネットワークをトレーニング（Apple が「できない」と言っているものを実証）。

すべてのコードは https://github.com/maderix/ANE の

ane/

この投稿についてのディスカッション

もっと知りたい？