Измерения скорости и энергии Neural Engine

Переписывание под ANE на FP16 улучшает скорость полного предсказания в 1.39×, а оценку энергии всей системы на решение — в 2.78× против скомпилированного MLX FP16. Отдельно проверенный кандидат W8 K-means достигает 1.42× и 3.19× соответственно. Ни один не достигает запрошенной цели 10×. Это локальные результаты на M3 Max, с указанными ниже ограничениями точности и измерения мощности.

Эксперименты по реализации и конвертации — в ANE_ENGINEERING.md; математические границы и контракты точности — в ANE_MATH.md.

Финальное сравнение устойчивых коротких решений

M3 Max, 40 ядер GPU, 128 ГиБ, macOS 27.2. Одна и та же многоязычная исходная контрольная точка, одни и те же восемь вариантов состояния счёта, один вопрос с четырьмя вариантами на запрос, 91 реальный токен, дополненный до 96. Без выходного кэша и сгенерированных токенов. Все три модели остаются резидентными; загрузка, компиляция и прогрев вне измеряемых интервалов.

Базовая линия включает mx.compile, кэширование префикса промпта и корзины форм на 32 токена. Она быстрее исторической eager-базовой линии MLX. Кандидат ANE FP16 сохраняет исходные веса, с полным телом трансформера 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

Умножение отношения энергии на скорость снова даёт двойной учёт прошедшего времени. Строка за вычетом простоя использует другую границу измерения; это не означает, что мощность всего ноутбука падает в 3.8–4.7×. Это интервалы насыщенной пропускной способности. Для утверждения о мощности при фиксированном FPS потребовался бы эксперимент с равной частотой запросов. W8 улучшает среднюю скорость лишь примерно на 2.1% относительно FP16 в этой сессии, тогда как его пакет тела сжимается с 251.91 до 129.29 десятичных МБ. Размер пакета исключает исходную таблицу эмбеддингов контрольной точки/хоста и не является общей памятью рантайма.

Каждая реализация выполнила шесть 20-секундных блоков в трёх сбалансированных циклах MLX, ANE FP16, ANE W8, ANE W8, ANE FP16, MLX. Десять секунд выборки простоя разделяют блоки; первые три секунды простоя отбрасываются, а соседняя устоявшаяся мощность простоя усредняется. Диапазоны мощности блоков бэкендов составили 60.32–62.38 Вт для MLX, 29.28–35.14 Вт для FP16 ANE и 26.68–27.95 Вт для W8 ANE. Были открыты другие настольные приложения; чередование и выборка соседнего простоя уменьшают, но не устраняют неопределённость фоновой нагрузки и датчика.

Все 65 598 предсказаний совпадают с округлённым прогревным выходом своего бэкенда для соответствующего состояния. Все три бэкенда выбирают один и тот же ответ на этих восьми состояниях. Отдельный набор проверок точности шире: FP16 L96 проходит 59/59 подходящих вопросов с максимальным дрейфом вероятности 0.002925; W8 проходит те же 59 с дрейфом 0.014393 при неизменном пороге 0.02. Полный результат 63/63 принадлежит отдельно экспортированной модели FP16 L1024. Это регрессионные фикстуры, а не утверждение об общей точности на задачах или сохранённой калибровке на произвольных входах.

Прогон сохранил 1 101 выборку мощности; максимальный промежуток составил 0.510 секунды, а максимальная записанная мощность системы — 74.47 Вт. Ни одна выборка не была отброшена. RSS по блокам записан для общего процесса со всеми резидентными моделями и буферами записи; эти значения нельзя отнести к памяти модели отдельного бэкенда. Отпечатки текущего рантайма и пакета хранятся вместе с отчётом.

Финальные сырые вызовы и выборки PSTR · Проверенная сводка и бутстрап-интервалы внутри сессии

Более ранний пилот только на FP16 измерил 1.410× скорости и 2.939× валовой энергии системы. Он предшествует последним проверкам входа и инструментарию стабильности по вызовам; свежий прогон с тремя плечами выше — это опубликованное сравнение для финального рантайма. Одна оговорка о метаданных в финальном сыром отчёте изначально описывала исторический нижний порог суммы компонентов macmon безусловно; аддитивная запись metadata_corrections уточняет, что этот прогон использовал только PSTR. Исходные поля и все измерения сохранены.

Совместимость со Snake — отдельная рабочая нагрузка

Один и тот же опубликованный планировщик Snake, компактные промпты и политика безопасности работали на адаптере ANE FP16 и скомпилированном MLX, чередуя порядок оценки на идентичных живых состояниях. Seed 101 и 102 завершили по 300 шагов: 600/600 предложенных и выполненных действий совпадают, ноль смертей и ноль вмешательств щита. Итоговые счета составили 9 и 10, с длинами змейки 15 и 16. Максимальное различие вероятности хода составило 0.0036. Это проверяет данное сравнение траекторий FP16, а не поведение Snake на сжатой модели или неограниченное выживание.

Адаптер ANE запускает три вопроса последовательно при B1/L96; MLX батчит три вопроса вплоть до L64. Эти тайминги включают признаки планировщика и полные предсказания, исключают работу другого бэкенда, шаг игры и отрисовку терминала, и показывают существенную вариацию. Они не устанавливают устойчивого ускорения Snake или максимальной стабильной частоты отрисовки. Результат 4.98 мс для одного вопроса нельзя рекламировать как полное время кадра Snake. Выделенный экспорт ANE B3/L64 был бы отдельной задачей оптимизации и валидации.

Сырые состояния, выходы и тайминги 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. Он закрепляет низкоуровневый API SMC из macmon 0.8.2, открывает одно соединение только для чтения и сэмплирует исходное значение PSTR каждые 500 мс. Он не читает счётчики компонентов IOReport. Это оценка датчика всей системы, а не внешнее измерение мощности из розетки или батареи. Хеш исполняемого файла и происхождение исходников записаны вместе с сырыми результатами.

Этот отдельный семплер был необходим, потому что официальный CLI macmon вычисляет sys_power = max(PSTR, component_sum), как показано в его исходниках. Счётчики CPU и ANE обычно возвращали ноль в этой ОС, затем одна выборка подскочила до примерно 38 021 Вт CPU и 2 068 Вт ANE. Нижний порог компонента распространил эту ошибку в показание системы 40 089 Вт. Точная причина аномалии IOReport не выяснена; исходное значение PSTR из этой выборки восстановить нельзя. Весь затронутый прогон энергии был отклонён, без удаления или обрезки плохой выборки. Его сырая запись остаётся доступной, но её сохранённые агрегаты энергии нельзя использовать как результаты.

Более ранний прогон только на FP16 использовал официальный выпуск macmon v0.8.2, чей архивный SHA256 был проверен как 588d5bde79885ba36f693e5150911c10c3ad208a2e418a3f2aa827ac84a2d973. Он прошёл поздние проверки на здравость и остаётся историческим свидетельством. Финальный прогон только на PSTR измеряет каждый бэкенд заново одним согласованным семплером.

Инструмент интегрирует ватты по монотонным меткам времени приёма с интерполированными границами. Отсутствующие, неположительные, неконечные или выше 500 Вт показания системы отклоняют прогон. Потолок в 500 Вт — это намеренно слабая проверка на здравость для этого M3 Max, а не калиброванная граница точности. Промежутки выше max(2 seconds, 3 × sample interval) также отклоняют прогон. Сводка проверяет полные сбалансированные циклы, стабильность по вызовам, число вызовов, активную энергию, оба соседних интервала простоя и получающуюся энергию за вычетом простоя против сырых выборок. Приращение энергии сохраняет свой знак; его никогда не зажимают, чтобы сфабриковать большое отношение.

Прямой семплер опускает поля мощности CPU/GPU/ANE, потому что не измеряет их. Исторические отсутствующие или нулевые счётчики компонентов не могут установить нулевую энергию или отсутствие исполнения на ANE. Бутстрап пересэмплирует полные сбалансированные циклы; три цикла из одной настольной сессии не характеризуют всю фоновую нагрузку, будущие прогоны или точность датчика. Ни одно из измеренных отношений не близко к 10×.

Действительно ли Neural Engine выполняет работу?

План вычислений Core ML переписанного графа B1/L96 помещает все 6 390 неконстантных операций на MLNeuralEngineComputeDevice; остальные 3 809 неизвестных записей — константы. Это ожидаемое размещение, само по себе недостаточное аппаратное свидетельство. Обычный экспорт SDPA не имел операций с предпочтением NE в этой системе.

Отдельная 15.97-секундная трасса Core ML в Instruments, снятая, пока кандидат работал с CPU_AND_NE, зафиксировала 3 124 активных интервала «Neural Engine Prediction» и одну несвязанную загрузку системной модели из кэша. Экспортированная таблица оборудования поэтому даёт положительное свидетельство активности 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, дождитесь его готового 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 токенах или по всем трём контрольным точкам Laya.