Neural Engine 速度與能耗測量

FP16 ANE 重寫相對編譯後的 MLX FP16，把完整預測速度提升 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。相同的多語言源 checkpoint、相同的八個 invoice-state 變體、每個請求一個四選項問題、91 個真實 token 補齊到 96。無輸出快取、無生成 token。三個模型都常駐；載入、編譯和預熱都在測量區間之外。

基線啟用了 mx.compile、prompt 字首快取和 32-token 形狀分桶。它比歷史的 eager MLX 基線更快。FP16 ANE 候選保留原始權重，包含完整的 Core ML transformer 主體、主機端 embedding 查詢和 FP32 的 CPU action tail。W8 使用分組 K-means 的 weight-only 調色盤壓縮，不是 W8A8 算術；它的啟用仍使用 FP16，主機端 action tail 仍是 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

再把能耗比乘以速度就是重複計算時間。扣除空閒的那一行使用不同的測量邊界；它並不意味著整檯筆記本的功耗下降 3.8–4.7×。這些是飽和吞吐區間。要做出固定 FPS 的功耗結論，需要等請求速率的實驗。W8 在本次會話中相對 FP16 只把平均速度提升了約 2.1%，而它的主體包從 251.91 縮小到 129.29 十進位制 MB。包體積不含原始 checkpoint/主機端 embedding 表，也不等於執行時的總記憶體。

每種實現都在三個平衡迴圈 MLX, ANE FP16, ANE W8, ANE W8, ANE FP16, MLX 中跑了六個 20 秒區塊。區塊之間隔十秒的空閒取樣；前三個空閒秒被丟棄，相鄰的穩定空閒功耗取平均。各後端的區塊功耗範圍為 MLX 60.32–62.38 W、FP16 ANE 29.28–35.14 W、W8 ANE 26.68–27.95 W。當時有其他桌面應用開啟；交替和相鄰空閒取樣會減少但不能消除後臺負載與感測器的不確定性。

全部 65,598 次預測都與各自後端對相應狀態的四捨五入預熱輸出一致。三個後端在這八個狀態上都選出相同答案。單獨的保真度套件更廣：FP16 L96 通過 59/59 個適配問題，最大機率漂移 0.002925；W8 在不變的 0.02 門檻下以 0.014393 的漂移通過同樣這 59 個。完整的 63/63 結果屬於單獨匯出的 FP16 L1024 模型。這些是迴歸夾具，不是對通用任務準確率或任意輸入上保持校準的說法。

該執行保留了 1,101 個功耗取樣；最大間隔為 0.510 秒，記錄到的最大系統功耗為 74.47 W。沒有采樣被丟棄。每個區塊的 RSS 是針對共享程序記錄的，此時所有模型和錄製緩衝都常駐；這些值不能歸給單個後端的模型記憶體。當前的執行時和包指紋隨報告一起儲存。

最終原始呼叫與 PSTR 取樣 · 審計後的摘要與會話內 bootstrap 區間

更早的 僅 FP16 的試點 測得 1.410× 速度和 2.939× 的總系統能耗提升。它早於最後的輸入檢查和逐呼叫穩定性插樁；上面這次全新的三臂執行才是最終執行時的已釋出對比。最終原始報告裡有一處後設資料說明最初無條件地描述了歷史上 macmon 的 component-sum 下限；一條附加的 metadata_corrections 條目澄清本次執行只用了 PSTR。原始欄位和所有測量都保留。

Snake 相容性是一個單獨的工作負載

同一個已釋出的 Snake 規劃器、緊湊 prompt 和安全策略同時跑在 FP16 ANE adapter 和編譯後的 MLX 上，在相同的即時狀態上交替評估順序。種子 101 和 102 各完成 300 步：600/600 個建議動作與執行動作一致，零死亡、零護盾干預。最終分數為 9 和 10，蛇長 15 和 16。最大移動機率差為 0.0036。這驗證的是這次 FP16 軌跡對比，不是壓縮模型的 Snake 行為或無限期存活。

ANE adapter 在 B1/L96 上順序執行三個問題；MLX 在最高 L64 上批處理這三個問題。這些計時包含規劃器特徵和完整預測，不含另一個後端的工作、遊戲步和終端渲染，且波動很大。它們並不能證明有穩定的 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

測量邊界與遙測限制

每次計時的呼叫都包含 prompt 構造、分詞、陣列構造、適用時的主機端 embedding 查詢、同步模型執行、action 特徵、校準和輸出格式化。MLX 會求值它的惰性輸出；Core ML 返回已完成的 NumPy 陣列。這比較的是未快取的預測，不是孤立的模型 kernel。

最終對比使用小巧、非特權的 僅 PSTR 的取樣器。它釘住 macmon 0.8.2 的底層 SMC API，開啟一個只讀連線，每 500 ms 取樣一次原始 PSTR 值。它不讀取 IOReport 的元件計數器。這是整機感測器估計，不是外部的牆插功耗或電池測量。執行檔雜湊和原始碼來源隨原始結果一起記錄。

之所以需要這個單獨的取樣器，是因為官方 macmon CLI 按 sys_power = max(PSTR, component_sum) 計算，如它的 原始碼 所示。CPU 和 ANE 計數器在本作業系統上通常返回零，隨後一個取樣跳到約 38,021 W CPU 和 2,068 W ANE。component 下限把這個故障傳播成了 40,089 W 的系統讀數。IOReport 異常的確切原因未解決；無法從那個取樣中恢復原始 PSTR 值。整個受影響的能耗執行都被拒絕，但沒有刪除或裁剪那個壞取樣。它的 原始記錄 仍然可用，但其儲存的能耗聚合不得當作結果使用。

更早的僅 FP16 執行使用官方 macmon v0.8.2 釋出版，其歸檔 SHA256 被驗證為 588d5bde79885ba36f693e5150911c10c3ad208a2e418a3f2aa827ac84a2d973。它通過了後來的健全性檢查，仍是歷史證據。最終的僅 PSTR 執行用一個一致的取樣器重新測量每個後端。

測試裝置在單調接收時間戳上用插值邊界對瓦特做積分。缺失、非正、非有限或高於 500 W 的系統讀數都會使該執行被拒絕。500 W 上限是為此 M3 Max 刻意設定的寬鬆健全性檢查，不是校準過的準確度邊界。超過 max(2 seconds, 3 × sample interval) 的間隔也會使該執行被拒絕。摘要會對照原始取樣，驗證完整的平衡迴圈、逐呼叫穩定性、呼叫計數、活動能耗、兩個相鄰空閒區間以及由此得到的扣除空閒後的能耗。增量能耗保留其符號；它絕不會被鉗制去製造一個大比值。

直接取樣器省略 CPU/GPU/ANE 功耗欄位，因為它不測量它們。歷史上缺失或為零的元件計數器不能證明零能耗或 ANE 未執行。bootstrap 對完整的平衡迴圈重取樣；一次桌面會話的三個迴圈不能刻畫所有後臺負載、未來的執行或感測器準確度。所測得的比值沒有一個接近 10×。

Neural Engine 真的在執行工作嗎？

重寫後的 B1/L96 圖的 Core ML 計算計劃把全部 6,390 個非常量運算元放在 MLNeuralEngineComputeDevice 上；其餘 3,809 個未知條目是常量。這是預期的放置，單憑它本身不足以作為硬體證據。普通的 SDPA 匯出在本系統上沒有任何 NE 首選運算元。

在候選模型以 CPU_AND_NE 執行時，另取了一份 15.97 秒的 Instruments Core ML trace，捕獲到 3,124 個活動的 “Neural Engine Prediction” 區間和一次無關的快取系統模型載入。因此，匯出的硬體表在計算計劃之外，還提供了執行時 ANE 活動的正面證據。該表是全域性的，並沒有給每次預測附上 PID 或模型身份；本次錄製中 Core ML 的 model-signpost 表為空。我們不會把每個硬體區間都單獨歸給 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

原始 checkpoint 和較短的匯出有各自的上下文上限。L96 執行時會拒絕放不下的輸入；一個短負載的速度結果不能證明在 512/1024 token 或跨全部三個 Laya checkpoint 的效能。