Appleが再燃させたハードウェア論争：Apple Neural Engineの回顧的リバースエンジニアリング
AppleのM1 Neural Engineが、これを理解するために作られたLinuxドライバープロジェクトが3年間停止していたにもかかわらず、再び注目を集めている。「Retrospectively Reverse-Engineering Apple's Neural Engine」は、このアクセラレータが初期のニューラルネットワークで優れた性能を発揮する一方、今日のトランスフォーマーのワークロードには苦戦する理由を記録したものだ。
元Asahi LinuxコントリビューターのEileen Yoonは、Appleがハードウェアの方向性を変えた後、この中断されていた作業に戻った。M5では、独立した16コアのNeural Engineを維持しつつ、各GPUコアにNeural Acceleratorを搭載している。この組み合わせは、単一の固定機能アクセラレータがAppleの拡大する生成AIワークロードを担うべきだという考え方に疑問を投げかける。
これは単なる遅れてきたハードウェア解析ではない。この調査は、2017年頃の畳み込みニューラルネットワーク、すなわちCNN向けに行われた設計判断と、最新の言語モデルに対するAppleの対応を結び付けている。トランスフォーマーは柔軟なスケジューリングと継続的なメモリ転送に依存するため、GPUは独立型Neural Engineに圧力をかけている。
休眠していたM1ドライバーはハードウェアの検死記録となった
この新たな研究は、未完成のLinuxドライバーを、Appleが当初想定していた機械学習の姿を描く記録へと変えた。
Yoonは以前、M1チップ内のNeural Engineと通信できるLinux ANE driverを開発した。このプロジェクトには、カーネルモジュール、ユーザー空間ライブラリ、テスト、Pythonバインディングが含まれていた。ハードウェアを広くプログラム可能にするものではなかったが、Appleの公開ソフトウェア抽象化を回避する経路を提供していた。
その後、このプロジェクトは3年間沈黙した。Yoonは、ANEはあまりに特化しており、追加のドライバー作業を正当化できないように見えたと記している。ハードウェアインターフェースを開放しても、その固定データパスが効率的に実行できる演算の種類は変わらない。
この違いは重要だ。通常のドライバーは、ハードウェアがすでに持つ機能を公開できる。しかし、特定用途向けのデータフローアクセラレータを汎用プロセッサへ変えることはできない。
したがってYoonのアーキテクチャ回顧は、当初のドライバー開発とは異なる問いを投げかける。Linuxがどのようにジョブを送信できるかではなく、演算アレイ、スケジューラ、メモリシステム、実行モデルを調べる。これらの構成要素は、M1設計に組み込まれたワークロードの前提を明らかにする。
この調査では、中央のローカルメモリブロックを囲む形で16個の演算コアが配置されていると説明されている。各コアには、入力を乗算し、その結果をアキュムレータに加算する並列multiply-accumulateユニット、すなわちMACが含まれる。これらの演算は、畳み込み、行列乗算、注意機構で使われる内積の基盤となる。
ただし、MACユニットだけでNeural Engineの特化性を説明することはできない。CNNとトランスフォーマーはいずれも乗算と加算を必要とする。決定的な違いは、重みと活性化データがどのようにユニットへ到達し、利用可能な状態に保たれ、チップ内を移動するかにある。
Appleは2017年、A11 Bionicで初のNeural Engineを導入した。当時のコンシューマー向けニューラルネットワークは、画像分類、顔分析、その他の高密度なCNNワークロードが中心だった。これらのネットワークは、規則的なテンソル形状と予測可能な再利用を備えていた。
Appleが独自プロセッサをMacへ投入した際、M1はこの設計系譜を受け継いだ。そのNeural Engineは、次元やデータ移動パターンが事前に大幅に分かっているコンパイル済みモデル向けに最適化されていた。この特化により、対応する処理ではレイテンシーと消費電力が抑えられた。
この回顧は、M1 Neural Engineがトランスフォーマー演算を実行できないとは主張していない。周辺のデータフローが、一部のトランスフォーマーパターン、とりわけ自己回帰デコーディングを非効率にすると論じている。この処理は、一度に1トークンを生成しながら、モデルの重みと増大していく注意キャッシュを繰り返し読み込む。
この再構成によって、本稿の中心的な緊張関係が生まれる。Appleは、想定されたワークロードに合わせてデータ移動を制約することで、効率的なエンジンを構築した。最新AIは、固定的なハードウェアアーキテクチャが変化できる速度を上回る速さで、主要ワークロードを変えた。
Apple Neural Engineの回顧的リバースエンジニアリングが明らかにする真の制約
M1 Neural Engineを規定する制約は演算能力ではなく、その演算回路の周囲でデータがたどらなければならない経路にある。
リバースエンジニアリングされたドライバーは、CONV、MATMUL、RELUといった高レベルコマンドをハードウェアへ直接送信することはない。Appleのコンパイラが、実行開始前にこれらのニューラル演算をタスクディスクリプタへ変換済みだからだ。
タスクディスクリプタは、構造化された構成データのブロックである。テンソル次元、メモリアドレス、活性化関数、依存関係、データ転送を制御するレジスタ群を設定する。ドライバーはディスクリプタをメモリに配置し、タスクマネージャをそこへ向け、ハードウェアの「ドアベル」を鳴らす。
送信後は、完了までNeural Engineがジョブを制御する。タスクが終了すると割り込みを発生させる。処理中、ホストプロセッサが各数学命令を指示することはない。
Yoonは、ANEには一般的なCPUやGPUの意味での命令セットが存在しないと結論付けている。そのタスクディスクリプタは任意のプログラムを供給するのではなく、ドメイン特化型のデータパスを構成する。各ディスクリプタは、そのデータパスを一度通過する処理を表す。
タスクは構成レジスタの読み込みから始まる。続いて専用転送ブロックが、重みと入力活性化データをメインメモリから個別のローカルストアへ移す。演算コアがリダクションを実行し、後処理で活性化を適用した後、別の転送ブロックが結果を返す。
このシーケンスは、再利用が予測可能な演算に有利だ。畳み込みでは、同じコンパクトな学習済みフィルタ群を多くの画像領域へ適用できる。アクセラレータは、大量の新しい重みを繰り返し取得することなく、演算レーンを稼働させ続けられる。
トランスフォーマーのデコーディングは、このバランスを変える。新しいトークンごとに、モデルパラメータのかなりの部分をストリーミングする必要がある場合がある。演算そのものは理解しやすいままだが、データ移動がコストを制限する要因となる。
M1のレイアウトは、重みに使われるメモリと活性化タイルに使われるローカルメモリを分離しているため、この問題をさらに深刻化させる。Yoonは、この設計に約1 MiBのカーネルメモリと2 MiBのタイルメモリがあると特定している。この調査は、ローカルで生成されたテンソルを重みとして効率的に再解釈するようには、アーキテクチャが配置されていなかったと論じる。
これは、Appleが2017年に対象としたモデルにとっては妥当な前提だった。CNN推論では通常、学習済みの重みを固定カーネルとして扱い、活性化データを層間で流れるデータとして扱う。トランスフォーマーの注意機構は、実行中に生成された値が後続の行列演算へ入力され得るため、この区別を曖昧にする。
キー・バリューキャッシュがこの問題をよく示している。このキャッシュは、モデルが生成時に再利用できるよう、以前のトークンの表現を保存する。その内容は会話や文書が長くなるにつれて増大するため、効率的なメモリアクセスの重要性も高まる。
固定されたテンソル次元は中心的な障害ではない。コンパイル済みタスクは変化するキャッシュ長に対してループでき、タスク送信のオーバーヘッドも小さく抑えられる。より難しい問題は、CNNの再利用を前提に設計された経路を通じてデータを繰り返し供給することだ。
このため、生の毎秒演算数は不完全な比較指標となる。ピーク演算スループットは、MACアレイが好条件下でどれだけ速く動作できるかを示す。だが、重み、活性化データ、中間結果を待ってユニットがどれほど頻繁に停止するかは明らかにしない。
独立した研究も、別の視点から整合的な結論に至っている。2026年のOrion research paperでは、プライベートインターフェースを通じてANEをプログラムする際に直面した20の制約が説明されている。著者らは、コンパイル、メモリレイアウト、数値的な挙動を実用上の障壁として挙げている。
Orionはそれでも、有意なトランスフォーマーの結果を報告している。M4 Max上で、このシステムは1億2,400万パラメータのGPT-2について毎秒170トークン超を生成した。また、1億1,000万パラメータのモデルを1,000ステップ、22分で学習させた。
これらの測定結果は、ANEが言語モデルのワークロードを実行できることを示している。ただし、あらゆる大規模モデルや推論の全段階にとって最良の対象であることを示すものではない。技術的な可能性とアーキテクチャ上の適合性の区別は、依然として不可欠だ。
Appleの公開ソフトウェアはハードウェアを一定の距離に置く
開発者はCore MLを通じてNeural Engineを利用できるが、ワークロードのコンパイル、分割、ディスパッチの方法は依然としてAppleが制御している。
Appleは、機械学習モデルのデプロイメント向け公開フレームワークであるCore MLを通じて、主にNeural Engineを公開している。開発者は互換性のあるモデルを提供し、個々の演算にCPU、GPU、Neural Engineのいずれを使うかはフレームワークが判断する。
Appleのcompute-unit controlsにより、アプリケーションはこれらのプロセッサの組み合わせを許可できる。開発者は利用可能なすべてのユニットを許可することも、GPUやNeural Engineを除外することもできる。公開インターフェースでは、ANEのタスクディスクリプタを直接プログラムする機能は提供されない。
このモデルは、Appleデバイス間の移植性を守る。アプリケーションは、1世代のチップにおけるレジスタレイアウトを記述せずに、必要な予測を記述できる。Appleは、アプリケーションインターフェースを安定させたまま、コンパイラやスケジューリング方針を改訂できる。
その代償は可視性だ。開発者は、Core MLが対応するすべての演算を特定のエンジンに配置するとは期待できない。また、GPUコンピュートAPIに期待される制御レベルで、最終的な低レベルプログラムを調べることもできない。
Appleは、Core ML executionが、メモリ消費と電力使用を抑えながらCPU、GPU、Neural Engineを利用できると説明している。このアプローチは、ハードウェア固有のチューニングをせずに効率的なオンデバイス推論を求めるアプリケーションに適している。
一方で、アーキテクチャ上の限界を調査する研究者にとっては満足しにくい。ベンチマークが別のプロセッサへフォールバックしたり、グラフを複数のプロセッサへ分割したり、基礎となるハードウェア挙動を見えにくくするコンパイラ変換に遭遇したりする可能性がある。
リバースエンジニアリングの作業は、この不確実性の一部を取り除く。Core MLの下層にあるタスクディスクリプタ、レジスタ書き込み、キュー、割り込み、メモリ経路を調査する。この視点は、ソフトウェアによる制約とシリコンによる制約を区別する助けとなる。
ただし、プライベートインターフェースには別の不確実性がある。Appleの公開互換性保証がなく、OSアップデートで変更される可能性がある。現在動作する研究コードでも、コンパイラ、モデル形式、ランタイムサービスの変更後には失敗するかもしれない。
この隔たりにより、Appleは特異な立場に置かれている。同社は、スマートフォン、タブレット、Mac、ヘッドセットに専用の機械学習ハードウェアを搭載している。しかし独立系開発者が、これらのプロセッサ内でもっとも特徴的なブロックの一つを制御できる範囲は限られている。
主流アプリケーションにとって、この制限は意図的な製品上の選択になり得る。Appleはデバイス全体を最適化し、各演算をどこで実行するかを決定する。多くの開発者にとっては、直接的なレジスタアクセスよりも予測可能なデプロイメントのほうが有益だ。
生成AI開発者には、しばしば逆の要件がある。量子化形式、注意機構カーネル、キャッシュレイアウト、融合演算を実験する。また、急速に変化するモデルアーキテクチャ間で性能を比較する。
GPUは、プログラミングモデルがより汎用的な計算を公開しているため、そのような試行錯誤に対応できる。開発者は専用のコンパイラ経路を待たずに新しいカーネルを実装できる。その代償として、同期、メモリアクセス、性能チューニングに関する責任はより重くなる。
独立型Neural Engineは、その対極に位置する。そのコンパイラと固定データパスは、モデルが適合する場合には効率的な実行を実現できる。ワークロードが変化すると、特化は利点ではなく制約になる。
Appleのソフトウェア戦略は、開発者がこの緊張関係を直接解消することを妨げている。Core MLはハードウェアの違いを隠せるが、CNN指向のメモリシステムを柔軟なGPUのように振る舞わせることはできない。リバースエンジニアリングは、フレームワークが通常は隠している境界を明らかにする。
M5でGPUが主な対抗軸になる
AppleのM5は独立型Neural Engineを廃止してはいないが、同社のAIロードマップにおいてGPUにより直接的な役割を与えている。
Appleは2025年10月、各コアにNeural Acceleratorを備えた10コアGPUを搭載するM5を発表した。このチップには、改良された16コアNeural Engineも引き続き搭載されている。この設計は、アーキテクチャ上の競争の両陣営に特化した行列演算ハードウェアを配置するものだ。
AppleのM5チップ発表によれば、新GPUはM4 GPUの4倍を超えるピークAI演算性能を提供する。Appleはユニファイドメモリ帯域幅も153GB/sへ引き上げ、M4比で約30％向上させた。
これらはAppleが管理した測定値であり、実際のアプリケーション性能はワークロードの詳細によって決まる。それでも、新しいアクセラレータの配置場所は、見出しの倍率よりも多くを物語る。Appleはそれらを、分離されたNeural Engineだけに依存するのではなく、プログラム可能なGPUコア内部に搭載した。
GPUは、特化した行列演算と、変化するアルゴリズムにすでに適した環境を組み合わせる。Appleによれば、開発者はMetal 4のテンソルAPIを通じてNeural Acceleratorsをプログラムできる。これにより、独立型ANEの非公開コマンド形式を公開せずに、GPUベースのAIワークロードへ向かう公的な経路が提供される。
Yoonはこの転換を、独立型NPU、すなわちニューラル処理ユニットの終焉の始まりと解釈する。この表現は意図的に挑発的であり、Appleの製品判断は、実際の廃止をまだ裏付けていない。
M5には依然として独立したNeural Engineが含まれている。Appleはそれを高速化したものとして説明し、写真処理や空間Persona生成などのシステム機能と関連付けている。こうしたタスクは、専用アクセラレータが得意とする、範囲が限定され予測可能な推論ワークロードに似ている。
より妥当な結論は、より限定的だ。Appleは現在、要求の厳しい生成AIワークロードの主要な実行先としてGPUを扱い、Neural Engineには効率的なシステム推論の役割を残している。
この役割分担は、リバースエンジニアリングによる証拠と一致する。GPUは行列アクセラレーションに、柔軟なメモリ操作、汎用カーネル、開発者による直接アクセスを組み合わせられる。固定機能のNPUは、実行パターンが既知の安定したグラフに対してオーバーヘッドを最小化できる。
どちらの設計も、すべてのワークロードで勝つわけではない。汎用プロセッサは、固定パイプラインなら不要な柔軟性を支えるために面積とエネルギーを費やす。特化エンジンは、モデルが新しいデータ移動パターンを求めると適応性を失う。
M5は、Appleが両方を望んでいることを示唆する。独立型Neural Engineは既存のオンデバイス機能を支え、GPU Neural Acceleratorsは、演算子やメモリ挙動が変化し続けるモデルを対象とする。
このハイブリッド戦略は、Appleのソフトウェアスタックにも圧力をかける。Core MLは、能力を増すプロセッサ群から選択しなければならない。Metalは、新GPUユニットを活用できるだけの制御を開発者に提供する必要がある。コンパイラは、プロセッサ間で頻繁にデータを移動して転送コストがアクセラレーションの効果を打ち消さないようにしなければならない。
したがって、この圧力は単純にNvidia対Apple、あるいはmacOS対Linuxという話ではない。Apple自身のシリコン内部で、固定機能の効率性とプログラム可能なアクセラレーションが競い合っている。
この競争は生成AIよりはるか以前に始まっていた。Appleのチップはすでに、CPU、GPU、メディアエンジン、画像プロセッサ、セキュリティハードウェアに作業を分割している。現在の違いは、AIモデル設計が変化する速度によって、長いハードウェア計画サイクルが特に危険になっている点だ。
専用ブロックの設計と検証には数年を要し得る。Transformerアーキテクチャ、Attentionの変種、量子化技術は数か月以内に変化し得る。より適応性の高いアクセラレーションをGPUに組み込むことで、誤った予測をした際のコストを下げられる。
リバースエンジニアリングはNeural Engineの終焉を証明しない
この回顧的分析はアーキテクチャ上の不一致を説明するが、Appleの将来の製品計画を確立したり、すべての新しいANE実装を測定したりすることはできない。
最も深い発見はM1世代に関するものだ。Appleはその後、複数のプロセッサファミリーを投入しており、内部の詳細は公開文書なしに変更され得る。後続チップに関する結論には、外観の類似性やマーケティング名称ではなく、直接測定が必要となる。
Yoonは物理レイアウト分析の一部に不確実性があることを認めている。ダイ画像は主要なメモリブロックや繰り返し現れる演算構造を示せるが、あらゆる配線判断を説明するものではない。一部の結論は、情報に基づく解釈の域にとどまる。
この調査は、包括的なアプリケーションベンチマークではなく、ハードウェア構造にも焦点を当てている。メモリ移動が特定のワークロードを制約する理由は示すが、同一の電力制限下でANE、GPU、CPUを用いてすべてのモデルを比較しているわけではない。
Orionは有用な新しい測定値を提供するが、非公開APIと研究用ソフトウェアを使用している。そのGPT-2およびTinyStoriesの実験は、アクセス可能性と能力を示すものであり、現在の大規模言語モデルに対する幅広い本番運用の準備状況を示すものではない。
別のオープンプロジェクトは、リバースエンジニアリングされた非公開インターフェースを介した直接学習を報告している。そのM4測定では、FP16スループットは毎秒約18.6兆演算、INT8スループットは毎秒約35.1兆演算とされる。これらの数値は選択された畳み込み構成に依存しており、完全なモデルへ一般化すべきではない。
ソフトウェアの成熟度は、ハードウェアと同じくらい重要だ。高度に最適化されたコンパイラは、グラフを再構成し、演算を融合し、転送を削減できる。研究用ドライバはエンジンを正しく公開していても、多くの性能を未活用のままにする可能性がある。
逆のリスクもある。ピークマイクロベンチマークは、理想的な条件下で演算ユニットを稼働させ続けられる一方、実際のモデルのボトルネックを隠すことがある。アクセラレータがアプリケーションに役立つかどうかは、エンドツーエンドのレイテンシ、メモリ使用量、エネルギー消費、コンパイル時間によって決まる。
Appleは、製品名を維持したまま独立型Neural Engineを再設計することもできる。より大きな共有メモリ、改訂されたデータパス、新しいタスク形式によって、M1で見つかった制約に対処できる可能性がある。M5の発表は、その水準の詳細を開示していない。
セキュリティも、アクセスを管理する理由となる。Appleは保護された生体認証ワークフローでNeural Engineハードウェアを利用している。同社のプラットフォームセキュリティ文書は、新しいシステムにおける安全なNeural Engine動作のための状態リセットとメモリ制御を説明している。
この役割は、同じハードウェアを任意のLinuxワークロードに開放することを必要としない。また、このブロックが存続する理由は、消費者向け言語モデルを超えたシステムアーキテクチャにある可能性も示している。
電力効率も、なお比較が不足している要素だ。自己回帰デコーディングはプログラム可能なGPUハードウェア上でより自然に動作するかもしれないが、専用エンジンは視覚、音声、分類タスクでは依然としてそれを上回る可能性がある。Appleは、こうした省電力が重要となるバッテリー駆動デバイスを販売している。
したがって、信頼できる主張はNeural Engineが死んだということではない。その当初の設計前提が、戦略的に重要なAIワークロードの全範囲をもはやカバーしていないということだ。
この区別によって、Retrospectively Reverse-Engineering Apple's Neural Engineは証拠に根ざしたものとなる。このプロジェクトはアーキテクチャ上の分岐を照らし出す一方、Appleがどちらの道をどこまで進むかは、今後の製品リリースが決める。
どのアーキテクチャが勝つかを示す3つのシグナル
Appleの次のAPI、ベンチマーク、チップレイアウトは、M1 Neural Engineが持続的なテンプレートだったのか、それとも特化した分岐だったのかを明らかにする。
最初のシグナルは、M5 GPUのNeural Acceleratorsに対する開発者アクセスだ。Metal 4は、研究者が再びブラックボックスに直面するほどスケジューリングを隠しすぎることなく、有用なテンソル演算を公開する必要がある。
実用的なツールは、Appleが急速に変化するモデル向けにプログラム可能なGPUアクセラレーションを選んだという見方を強める。APIが限定的だったり、対応演算子が狭かったりすれば、その解釈は弱まり、Core MLが管理するハードウェアの役割はより大きく残る。
2つ目のシグナルは、代表的なTransformerワークロードにおけるエンドツーエンド性能だ。有用な比較には、プロンプト処理、トークン生成、長文コンテキストでのメモリ挙動、エネルギー使用量、モデル読み込み時間を含める必要がある。
マイクロベンチマークだけでは、この問題に決着はつかない。プロセッサは行列スループットで先行しても、重み転送、キャッシュ移動、グラフコンパイルに時間を失う可能性がある。測定では、各演算をどの演算ユニットが実行したかも特定すべきだ。
M5アプリケーションの結果は特に重要になる。ローカル言語モデルと拡散ソフトウェアは、Appleが明示的に強調したワークロードの下で新GPUアクセラレータを試せる。一貫した向上が得られれば、プログラム可能なコア内部のアクセラレーションへ移行する判断を裏付けることになる。
3つ目のシグナルは、Appleの次世代独立型Neural Engineのアーキテクチャだ。Appleは16コアという表記を維持したまま、その下にあるメモリ容量、インターコネクト、スケジューリング、対応精度を変更できる。
ローカルメモリシステムの再設計は、独立型ブロックが終焉に近づいているという考えに異議を唱えることになる。より大きなGPU投資と組み合わさった最小限の変更は、Yoonの解釈を支持するだろう。
Linuxの進展は、二次的な検証経路を提供する。Asahiコミュニティは、クリーンルームの観察と実験を通じてAppleシリコンを記録する豊富な経験を持つ。そのリバースエンジニアリングの取り組みは、すでに他の文書化されていないブロック向けのオープンドライバを生み出している。
実用的なANEドライバがあれば、研究者はCore MLの選択を直接タスク送信と比較できる。また、Appleの公開フレームワークが利用不能にしている性能を、代替コンパイラが回復できるかどうかも明らかになる可能性がある。
ただし、Linuxサポートを主要な商業的成果と取り違えるべきではない。ドライバが重要なのは、隠されたハードウェアの挙動を検証可能な証拠へ変えるからだ。アーキテクチャの将来を決めるのは、Apple自身のデバイス、フレームワーク、ワークロードである。
開発者は、Appleが新しい公開プログラム可能性をどこに配置するかを注視すべきだ。また、理論上のスループットと完全なアプリケーション性能を分けて考えるべきでもある。最も大きな見出し数値を持つプロセッサが、必ずしもモデルデータを最も効率的に移動させるとは限らない。
同様の技術調査を行うチームには、実験、レジスタの発見、ベンチマーク、棄却した仮説を持続的に記録する仕組みが必要だ。検索可能なエンジニアリング知識ベースは、ツールやチップ世代が変化しても、その証拠を結び付けて維持できる。
Retrospectively Reverse-Engineering Apple's Neural Engineは最終的に、古いシリコンが新しい戦略を説明する稀有な瞬間を捉えている。M1は、CNNの前提をハードウェアに組み込むことの利点とコストを示す。M5は、特化を直ちに放棄せずに柔軟性を加えるAppleの姿を示している。
次の問いは具体的だ。将来のAppleチップは、Neural Engineを安定したシステムタスクに残しながらプログラム可能なGPUアクセラレーションを拡大するのか、それともTransformer向けに独立型ブロックを再構築するのか。TOPSの数値だけでなく、APIとメモリ挙動を注視すべきだ。
