M4 Apple Neural Engineの内部探究、Part 1: リバースエンジニアリング

 (maderix.substack.com)
4 ポイント 投稿者 GN⁺ 2026-03-03 | 2件のコメント | WhatsAppで共有
  • Apple Neural Engine(ANE) の内部構造を直接分析し、CoreMLを迂回してハードウェアへ直接アクセスする方法を実装
  • CoreMLの抽象化レイヤーを取り除き、_ANEClient APIを通じてモデルのコンパイル・ロード・実行を直接実施
  • MIL(Machine Learning Intermediate Language) と E5バイナリ形式を分析し、ANEが固定演算プリミティブベースのグラフ実行エンジンであることを確認
  • IOSurface共有メモリを用いて、GPU↔ANE間のゼロコピー・データ転送の可能性を実証
  • この研究はM4 ANEの実性能測定と学習可能性を探る3部作の第1弾であり、Appleの非公開ハードウェアに対する初の直接制御事例として意義がある

人間–AI協業によるリバースエンジニアリングのアプローチ

  • 研究は人間の研究者とAnthropicのClaude Opus 4.6の協力で進められた
    • 人間が探索の方向性を提示し、AIがデータ分析とコード作成を担当
  • 目標は「Apple Neural Engine上で直接モデルを学習させられるか」という問いから出発
  • AppleはANEのISA、内部構造、直接プログラミングインターフェースを公開していない
    • CoreML経由でしかアクセスできず、これがハードウェア動作の理解を難しくしている
  • そこでCoreMLからIOKitカーネルドライバまでソフトウェアスタック全体を逆追跡し、ANEを直接制御するコードパスを確保

Neural Engineの構造

  • ANEはGPUやCPUではなくグラフ実行エンジン(graph execution engine) の形態
    • コンパイル済みのニューラルネットワークグラフ全体を1つの原子的演算として実行
  • M4チップのANE（コードネーム H16G）は16コア、127件のリクエストキュー深度、独立DVFS制御、アイドル時0mW電力遮断機能を備える
  • AppleはA11（2017）で2コアANEを初めて導入して以来、世代ごとに拡張してきた

既存研究との違い

  • 既存の公開資料:
    • Matthijs HollemansによるANE動作文書および性能分析
    • mdaiter/aneの初期リバースエンジニアリングサンプル
    • Asahi Linuxのリバースエンジニアリング済みLinuxドライバ
    • apple/ml-ane-transformersの公式トランスフォーマー最適化コード
  • 今回の研究の独自成果:
    • CoreMLなしで**_ANEClient APIへの直接アクセスに成功**
    • MILのインメモリ・コンパイル経路を解読
    • CoreMLオーバーヘッド除去後の実スループットを測定
    • 推論専用ハードウェア上でモデル学習を実行

分析手法

  • クラス探索: dyld_info -objc コマンドで AppleNeuralEngine.framework 内部クラス一覧を抽出
  • メソッドスウィズリング: CoreML呼び出しを横取りし、非公開フレームワークの呼び出し経路を確認
  • バイナリ分析: コンパイル済みE5バンドルを解読してプログラム形式を把握
  • スケーリング分析: 行列サイズ・グラフ深度・チャネル数を変化させてハードウェアトポロジーを推定
  • その結果、_ANEClient, _ANEModel, _ANERequest, _ANEIOSurfaceObject, _ANEInMemoryModel など40個以上の非公開クラスを発見

CoreMLの迂回: _ANEClient への直接アクセス

  • _ANEClient を通じてモデルのコンパイル → ロード → 評価の全パイプラインを直接制御可能
  • CoreMLは単にこの過程を包む利便レイヤーにすぎない
  • ANEは最大127件の同時評価リクエスト(queue depth) をサポートし、高スループットのストリーミング推論に最適化
  • IOSurfaceベースのI/Oバッファを使うことで、GPUとANE間の共有メモリ転送が可能

MIL: ANEの入力言語

  • CoreMLはONNXやprotobufの代わりにMIL(Machine Learning Intermediate Language) を使用
    • 静的単一代入(SSA)ベースで、型・形状が明示される
    • 例示コードでは matmul 演算が明確に表現される
  • テンソルレイアウトはNCDHW + Interleave形式で、[Batch, Channels, Depth, Height, Width] 構造

E5バイナリ形式

  • MILプログラムはE5 FlatBufferバイナリにコンパイルされる
    • 1024×1024行列積: 2,688バイト、128×128行列積: 2,680バイト
    • コードサイズがほぼ同一 → 行列演算アルゴリズムではなくパラメータ化された構成情報のみを含む
  • これはANEが固定された演算プリミティブ(Conv, MatMul, Elementwise など) を組み合わせてグラフを実行することを意味する

インメモリ・コンパイル経路

  • _ANEInMemoryModelDescriptor を使ってディスクアクセスなしにメモリ内でMILをコンパイル可能
  • 主な問題点と解決策:
    • milText には NSString ではなく**NSData(UTF-8バイト列)** が必要
    • weights は名前–データ対応の辞書形式
    • 内部的に一時ディレクトリアクセスが必要 → 書き込み権限の確保が必須
  • Apple内部コードで Desctiptor というタイプミスを発見

ハードウェアプロファイル

  • IOKit分析の結果、ANEは独立した電力・クロック管理(DVFS) チャネルを備える
    • ANE_ADCLK_TRIG, ANE_PPT_TRIG など多様なハードウェア/ソフトウェアトリガーが存在
  • ANECompiler.framework で確認された対応演算のうち、Convが中核となる演算プリミティブ
    • Part 2では1×1 ConvをMatMulに変換した際に3倍の性能向上が確認される予定

IOSurfaceプロトコル

  • すべてのデータ入出力はIOSurface共有メモリオブジェクトを通じて行われる
    • GPUテクスチャ共有メカニズムと同じ
    • GPU↔ANEゼロコピー・パイプラインを構成できる可能性がある

コンパイルキャッシュ構造

  • ANEコンパイラはE5バイナリをディスクにキャッシュする
    • パス: ~/Library/Caches/.../com.apple.e5rt.e5bundlecache/.../H16G.bundle/
    • 初回コンパイルは20–40ms、キャッシュヒット時は即時実行
    • 推論には有利だが、学習時は重み変更による再コンパイルが必要

未探索領域

  • まだ分析されていないクラス:
    • _ANEChainingRequest — 複数モデルを単一ディスパッチで連結できる可能性
    • _ANESharedEvents, _ANESharedSignalEvent, _ANESharedWaitEvent — GPU↔ANE同期用のフェンス/シグナル
    • _ANEPerformanceStats — ハードウェア性能カウンタの可能性
    • _ANEVirtualClient — マルチプロセス仮想化アクセスの可能性
  • 未確認事項:
    • ANEコアのマイクロアーキテクチャおよびISA
    • グラフ内演算のコア割り当て方式
    • クロック周波数およびSRAM構造

今後の計画

  • Part 2: 行列積スケーリング、SRAMボトルネック、ConvとMatMulの性能比較、Appleの「38 TOPS」値の検証
  • Part 3: ANEでニューラルネットワーク学習を実行
  • すべてのコードはgithub.com/maderix/ANEの ane/ ディレクトリで公開
  • テスト環境: M4 Mac Mini, macOS 15.x

関連記事

2件のコメント

 
GN⁺ 2026-03-03
Hacker Newsのコメント
  • 私はXcodeチームで何年も働いていた。Appleがこういう部分を意図的に難しくしておくやり方はよく知っている
    著者は本当に素晴らしい仕事をしたと思うし、Part 3も楽しみにしている
    • 以前はXcodeのコンソールを別ウィンドウに分離できたのに、なぜその機能を削除したのか気になる
  • オープンソースソフトウェアでNeural Engineがいつ動作しているのか理解できない
    私は主に lightgbm、sklearn、xgboost のような Python ML ライブラリと numpy を使っている
    こうした演算がAppleハードウェアで高速化されるのか、簡単にベンチマークする方法があるのか気になる
    ほとんどのベンチマークはC関数レベルなので、高水準ライブラリでも効果があるのか分からない
    ChatGPTにIntel MacとApple Siliconを比較しろと言われて笑ってしまった。こういう理由で、いまだにAIを嫌う人がいるのだと思う
    • ほとんどのオープンソースではNPUはほとんど活用されていない
      理由は、NPUがメーカーごとに特化していて、オープンソース開発者が対応しづらいからだ
      Apple ANEも例外ではなく、今回の研究はその問題をApple ANEに限定して解決しようとする試みに見える
  • Part 2にはベンチマークが含まれている
    Inside the M4 Apple Neural Engine によれば、6.6 FLOPS/W の性能を出し、使用していないときは完全にオフになって消費電力は 0W だという
    • ただし、Appleが主張する38 TOPSという数値は実態と異なる
      Appleは「38 TOPS INT8」を FP16 19 TFLOPS × 2 として計算しているが、実際のハードウェアは INT8 演算を2倍の速度では実行しない
      この計算方法に従うのは、Appleらしくなく誇張表現のように感じられる
  • 記事では「私たち」が maderix（人間）と Claude Opus 4.6（Anthropic）の協業だとしていたが、正直信じがたい
    LLMは専門家ですらだませるほどもっともらしい虚偽情報を作れる
    すべての事実を手作業で検証したのか疑わしい。そういう点では事前に警告してくれたおかげで、むしろ読まなくて済んで助かった
    • Claude はユーザーに良い結果だけ見せるようにベンチマークを隠す傾向がある
      記事でもそうした奇妙なベンチマークが見られる
    • 人間も昔からもっともらしい嘘の研究を書いてきた
      LLM以前から、学界には捏造論文や再現不可能な研究が多かった
      結局こうした分析は、より多くのエンジニアが検証して初めて信頼できる
  • 私もこういうミスはするが、コメントの大半が「Appleに関する何でもあり」の話に流れているように見える
    話題と関係のない内容が多い
  • ANEのソースコードがMLXチームにも非公開だというのは驚きだ
    おそらく、MLXプロジェクトの責任者だったAwniがAppleを去った理由の一つでもあるのだろう
  • M1/M2 ANEのAsahi Linuxドキュメントを通じて、基本的な内容はすでに知られていた
    ただ、今回の記事はその内容をさらに深く確認し、拡張している点がよい
    CoreML は大規模な matmul 演算ではほとんどオーバーヘッドがないとのことなので、ローカルAIフレームワークで ANE を prefill 用に活用できる余地は大きい
    ただし decode 段階はメモリ帯域幅に制約され、matmul を 1x1 convolution に置き換える過程も非効率なので、明確な利点があるとは言い切れない
  • 最近の報道によると、AppleはCore MLを置き換える新しいフレームワークを準備している
    名前は Core AI で、サードパーティー製 LLM をアプリにより簡単に統合できるようにするという
    関連記事: Bloombergニュースレター
  • この記事は明らかに人間が書いたものだが、いくつかの文にはLLM特有の言い回しが見られる
    それでも非常に有益で興味深く読めた
    記事で言及されていた Githubリポジトリ もあわせて参考になる
    • 今後1年ほど経てば、人々が毎日LLMとやり取りする中で、AIの文体が人間の言語に染み込む現象が起きる気がする
    • 「Prior Art」セクションを見ると、“documenting”、“providing insight into” のような不要に反復する動詞が多い
      この部分は確かにAIが書いた痕跡がある
  • ソフトウェアエンジニアの現在はすでに未来レベルだ
    ANEのリバースエンジニアリングより重要なのは、ManjeetがAIの助けで自分のエンジニアリング能力をどこまで拡張したかだ
    今まさに、AIが開発者の生産性を加速する時代になっている