Neural Engine の速度とエネルギーの測定

FP16 ANE の書き直しは、コンパイル済み MLX FP16 に対して、complete-predict の速度を 1.39 倍、意思決定あたりの推定システム全体エネルギーを 2.78 倍改善します。別途検証された W8 K-means 候補はそれぞれ 1.42 倍と 3.19 倍に達します。どちらも要求された 10 倍の目標を満たしません。 これらはローカルの M3 Max での結果であり、以下に述べる精度と電力測定の限界を伴います。

実装と変換の実験は ANE_ENGINEERING.md に、数学的な限界と忠実性の契約は ANE_MATH.md にあります。

最終的な持続短意思決定の比較

M3 Max、40 GPU コア、128 GiB、macOS 27.2。同じ多言語ソースチェックポイント、同じ 8 つの請求書 state 変種、リクエストあたり 1 つの 4 択質問、91 の実トークンを 96 にパディング。出力キャッシュや生成トークンはなし。3 つのモデルはすべて常駐し、ロード、コンパイル、ウォームアップは測定区間の外です。

ベースラインは mx.compile、プロンプトプレフィックスキャッシュ、32 トークンのシェイプバケットを有効にします。これは過去の eager MLX ベースラインより高速です。FP16 ANE 候補は元の重みを保持し、完全な Core ML トランスフォーマーボディ、ホスト埋め込みルックアップ、FP32 CPU アクションテールを備えます。W8 はグループ化 K-means の 重みのみのパレット圧縮を使い、W8A8 演算ではありません。そのアクティベーションは依然として FP16 を使い、ホストアクションテールは FP32 のままです。

比率は区間平均を使い、完了したすべての処理を含みます：

FP16: speed 1.394 × average system-power ratio 1.997 = energy gain 2.784
W8:   speed 1.423 × average system-power ratio 2.241 = energy gain 3.189

エネルギー比にさらに速度を掛けると、経過時間を二重計上することになります。アイドル差し引き後の行は別の測定境界を使い、ノート PC 全体の電力が 3.8〜4.7 倍下がるという意味ではありません。これらは飽和スループットの区間です。固定 FPS の電力主張には、等しい要求レートの実験が必要です。W8 はこのセッションで平均速度を FP16 より約 2.1% 改善するだけですが、そのボディパッケージは 251.91 から 129.29 の 10 進 MB に縮みます。パッケージサイズは元のチェックポイント/ホスト埋め込みテーブルを除き、ランタイムメモリ全体ではありません。

各実装は MLX, ANE FP16, ANE W8, ANE W8, ANE FP16, MLX の 3 つのバランスの取れたサイクルで、20 秒のブロックを 6 回実行しました。ブロック間は 10 秒のアイドルサンプリングで区切り、最初の 3 秒のアイドルは破棄し、隣接する安定したアイドル電力を平均します。バックエンドのブロック電力範囲は、MLX が 60.32〜62.38 W、FP16 ANE が 29.28〜35.14 W、W8 ANE が 26.68〜27.95 W でした。他のデスクトップアプリケーションが開いていました。交互配置と隣接アイドルサンプリングは、バックグラウンド負荷とセンサーの不確かさを減らしますが、排除はしません。

65,598 の予測はすべて、対応する状態について、そのバックエンドの丸められたウォームアップ出力と一致します。3 つのバックエンドはすべて、これら 8 つの状態で同じ答えを選びます。別途の忠実性スイートはより広範です：FP16 L96 は 59/59 の適合質問を通過し、最大確率ドリフトは 0.002925。W8 は同じ 59 を、変更されていない 0.02 のゲートの下でドリフト 0.014393 で通過します。完全な 63/63 の結果は、別途エクスポートされた FP16 L1024 モデルのものです。これらは回帰フィクスチャであり、一般的なタスク精度や任意の入力での較正の保持の主張ではありません。

実行では 1,101 の電力サンプルが保持されました。最大ギャップは 0.510 秒、記録された最大システム電力は 74.47 W でした。サンプルは 1 つも破棄されませんでした。ブロックごとの RSS は、すべてのモデルと記録バッファが常駐する共有プロセスについて記録されており、それらの値を個々のバックエンドのモデルメモリに割り当てることはできません。現在のランタイムとパッケージのフィンガープリントはレポートとともに保存されています。

最終的な生の呼び出しと PSTR サンプル · 監査済みサマリーとセッション内ブートストラップ区間

以前の FP16 のみのパイロットは 1.410 倍の速度と 2.939 倍の総システムエネルギー向上を測定しました。これは最後の入力チェックと呼び出しごとの安定性インストルメンテーションより前のものであり、上記の新しい 3 アーム実行が最終ランタイムの公開比較です。最終的な生レポートのあるメタデータの注意書きは、当初、歴史的な macmon のコンポーネント合計の下限を無条件に記述していましたが、追加の metadata_corrections エントリが、この実行が PSTR のみを使ったことを明確にしています。元のフィールドとすべての計測値は保持されています。

Snake の互換性は別のワークロード

公開されている同じ Snake プランナー、コンパクトなプロンプト、安全ポリシーが、FP16 ANE アダプタとコンパイル済み MLX の両方で実行され、同一のライブ状態に対して評価順序を交互にしました。シード 101 と 102 はそれぞれ 300 ステップを完了しました：提案され実行されたアクションが 600/600 で一致し、死亡ゼロ、シールド介入ゼロ。最終スコアは 9 と 10 で、Snake の長さは 15 と 16 でした。手の確率の最大差は 0.0036 でした。これはこの FP16 軌跡の比較を検証するものであり、圧縮モデルの Snake 挙動や無制限の生存を検証するものではありません。

ANE アダプタは B1/L96 で 3 つの質問を逐次実行し、MLX は最大 L64 で 3 つの質問をバッチ化します。これらのタイミングにはプランナー特徴量と完全な予測が含まれ、もう一方のバックエンドの処理、ゲームステップ、端末レンダリングは除外され、大きなばらつきを示します。一貫した Snake の高速化や、安定した最大レンダリングレートを証明するものではありません。単一質問の 4.98 ms の結果を、Snake のフレーム時間全体として宣伝してはなりません。専用の B3/L64 ANE エクスポートは、別の最適化と検証のタスクになります。

生の Snake 状態、出力、タイミング

python -m benchmarks.snake artifacts/ane-repro/body96/model.mlpackage \
  /path/to/original/laya-multilingual --ane --mlx-compiled \
  --steps 300 --seeds 101 102 --output artifacts/ane-snake.json

測定境界とテレメトリの限界

計時されたすべての呼び出しには、プロンプト構築、トークン化、配列構築、該当する場合はホスト埋め込みルックアップ、同期モデル実行、アクション特徴量、較正、出力フォーマットが含まれます。MLX は遅延出力を評価し、Core ML は完了した NumPy 配列を返します。これは非キャッシュの予測を比較するものであり、孤立したモデルカーネルではありません。

最終的な比較は、小さく非特権の PSTR のみのサンプラーを使います。macmon 0.8.2 の低レベル SMC API を固定し、1 つの読み取り専用接続を開き、元の PSTR 値を 500 ms ごとにサンプリングします。IOReport のコンポーネントカウンタは読みません。これはシステム全体のセンサー推定であり、外部の壁電力やバッテリー測定ではありません。実行ファイルのハッシュとソースの出所は生の結果とともに記録されています。

この別途のサンプラーが必要だったのは、公式の macmon CLI が sys_power = max(PSTR, component_sum) を計算するためであり、それはその ソースに示されています。CPU と ANE のカウンタはこの OS では通常ゼロを返しましたが、あるサンプルが約 38,021 W CPU と 2,068 W ANE に跳ね上がりました。コンポーネントの下限がその障害を 40,089 W のシステム読み取りへ伝播させました。IOReport 異常の正確な原因は未解決で、そのサンプルから元の PSTR 値を復元することはできません。影響を受けたエネルギー実行は全体が却下されましたが、悪いサンプルを除去もクリップもしていません。その 生レコードは引き続き利用できますが、そこに保存されたエネルギー集計を結果として使ってはなりません。

以前の FP16 のみの実行は公式の macmon v0.8.2 リリースを使い、そのアーカイブの SHA256 は 588d5bde79885ba36f693e5150911c10c3ad208a2e418a3f2aa827ac84a2d973 と検証されました。これは後の健全性チェックを通過し、歴史的証拠として残っています。最終的な PSTR のみの実行は、1 つの一貫したサンプラーで全バックエンドを再度測定します。

ハーネスは、単調な受信タイムスタンプにわたって補間した境界でワットを積分します。欠落、非正、非有限、または 500 W を超えるシステム読み取りは実行を却下します。500 W の上限は、この M3 Max に対する意図的に緩い健全性チェックであり、較正された精度の境界ではありません。max(2 seconds, 3 × sample interval) を超えるギャップも実行を却下します。サマリーは、完全なバランスの取れたサイクル、呼び出しごとの安定性、呼び出し回数、アクティブエネルギー、両方の隣接アイドル区間、そして結果としてのアイドル差し引き後エネルギーを、生サンプルに対して検証します。増分エネルギーはその符号を保ち、大きな比率をでっち上げるためにクランプされることはありません。

直接サンプラーは、CPU/GPU/ANE の電力フィールドを測定しないため省略します。歴史的な欠落またはゼロのコンポーネントカウンタは、エネルギーがゼロであることや ANE 実行の不在を証明することはできません。ブートストラップは完全なバランスの取れたサイクルをリサンプリングします。1 つのデスクトップセッションの 3 サイクルは、すべてのバックグラウンド負荷、将来の実行、センサー精度を特徴づけるものではありません。測定された比率はいずれも 10 倍に近くありません。

Neural Engine は実際に処理を実行しているのか？

書き直した B1/L96 グラフの Core ML 計算計画は、6,390 の非定数演算をすべて MLNeuralEngineComputeDevice に配置します。残りの 3,809 の未知のエントリは定数です。これは想定された配置であり、それ自体では十分なハードウェアの証拠ではありません。通常の SDPA エクスポートは、このシステムで NE 優先の演算を持ちませんでした。

候補が CPU_AND_NE で実行されている間に取得した、別途の 15.97 秒の Instruments Core ML トレースは、3,124 のアクティブな「Neural Engine Prediction」区間と、無関係な 1 件のキャッシュ済みシステムモデルのロードを捉えました。したがって、エクスポートされたハードウェアテーブルは、計算計画に加えて、実行時の ANE 活動の積極的な証拠を提供します。テーブルはグローバルであり、すべての予測に PID やモデル識別子を付与するものではありません。この記録では Core ML のモデルサインポストテーブルは空でした。すべてのハードウェア区間を排他的に Laya に帰属させたり、ホスト側の処理が ANE で実行されるとは主張しません。

許可リストに載ったハードウェアイベントは、タイムスタンプ、期間、デバイス、ラベル、状態のみを含みます。完全な Instruments アーカイブとプロセス環境のメタデータは、無視される artifacts/ ディレクトリにとどまります。トレースはエネルギー試験とは別であり、インストルメントされたハードウェア区間はエンドツーエンドのレイテンシ結果として使われません。

再現する

まず、エンジニアリングレポートのコマンドで、固定 L96 の FP16 と W8 K-means のパッケージを作成し検証します。それらのコマンドは artifacts/ane-repro/ 配下の新しいディレクトリに書き込みます。直接センサーサンプラーはローカルでビルドします。システムデーモンや特権サービスはインストールされません。

pip install -e '.[convert,dev,compare,research]'
cargo build --release --locked --manifest-path benchmarks/pstr_sampler/Cargo.toml
python -m benchmarks.energy \
  --source /path/to/original/laya-multilingual \
  --candidate artifacts/ane-repro/body96-w8km/model.mlpackage \
  --fp16-candidate artifacts/ane-repro/body96/model.mlpackage \
  --candidate-factory experiments.ane_engineering.runtime:ANEAgent \
  --sampler benchmarks/pstr_sampler/target/release/pstr-sampler --pstr-only \
  --cycles 3 --seconds 20 --idle-seconds 10 \
  --output artifacts/energy.json

python -m benchmarks.energy_summary artifacts/energy.json \
  --output artifacts/energy-summary.json

独立したランタイム診断には、benchmarks.trace_ane を起動し、その ready PID ファイルを待ってから、他のモデルワークロードを実行せずに Instruments をアタッチします：

python -m benchmarks.trace_ane \
  --source /path/to/original/laya-multilingual \
  --package artifacts/ane-repro/body96/model.mlpackage \
  --seconds 90 --ready artifacts/trace.pid
# From another terminal; use the PID written to that file.
xcrun xctrace record --template 'Core ML' --attach <PID> \
  --time-limit 15s --output artifacts/ane.trace
xcrun xctrace export --input artifacts/ane.trace --toc \
  --output artifacts/toc.xml
xcrun xctrace export --input artifacts/ane.trace \
  --xpath '/trace-toc/run[@number="1"]/data/table[@schema="ane-hw-intervals"]' \
  --output artifacts/hardware.xml
python -m benchmarks.trace_summary --hardware-xml artifacts/hardware.xml \
  --toc-xml artifacts/toc.xml --output artifacts/hardware-summary.json

元のチェックポイントと短いエクスポートは別々のコンテキスト上限を持ちます。L96 ランタイムは収まらない入力を拒否します。短いワークロードの速度結果は、512/1024 トークンでの性能や 3 つの Laya チェックポイントすべてにわたる性能を証明するものではありません。