Как оценить производительность инференса на мобильных устройствах: методика бенчмаркинга для Android и iOS

1. Что подготовить перед началом бенчмаркинга

Перед любым измерением важно согласовать исходные параметры. Подготовьте: 1) набор тестовых устройств (минимум 2–3 модели с разными чипсетами и версиями ОС); 2) бинарные сборки приложения в конфигурациях debug и release; 3) версии модели в форматах, которые будете тестировать (TFLite, Core ML, ONNX → Core ML и т.д.), а также варианты с и без оптимизаций (квантование, праунинг). Без этих элементов сравнение будет некорректным.

Также заранее зафиксируйте: тестовый датасет (несколько репрезентативных входных примеров), сценарии запуска (одиночный запрос, пакетный режим, параллельные запросы), и процедуру «прогрева» (сколько итераций и как их запускать). Важно согласовать, какие показатели приоритетны — средняя задержка (latency), 95-й перцентиль, пропускная способность (throughput), расход памяти и энергопотребление.

Наконец, определите метрики и формат отчёта: какие логи сохранять, в каком виде будут сравнения (CSV/JSON), и кто отвечает за воспроизведение. Если вы используете CI/систему автоматического тестирования, подготовьте скрипты для автоматического запуска и экспорта результатов — это сократит ручную работу и уменьшит риск ошибок.

• Устройства: модель, ОС, состояние батареи, фоновые сервисы
• Сборки: debug/release, с/без оптимизаций
• Модели: исходный формат и оптимизированные варианты
• Тестовый набор данных и сценарии
• План измерений и формат отчёта

2. Инструменты и SDK для Android: что использовать и зачем

На Android ключевые инструменты для бенчмарка — это adb для базовой работы с устройством и логами, Android Profiler и systrace для трассировки системных показателей, а также simpleperf и perfetto для более глубокой оценки CPU/GPU. Для тестирования inference важно уметь переключать делегаты — CPU, GPU, NNAPI — и измерять поведение каждой комбинации.

Если модель работает через TensorFlow Lite, используйте официальный TFLite Benchmark Tool или встроенный TFLite Interpreter с соответствующими делегатами. Для ONNX и других форматов применяются свои рантаймы и плагины; важно документировать версию рантайма и флаги оптимизации, потому что даже мелкие изменения влияют на производительность.

Не забывайте про сбор метрик энергопотребления: на Android можно получить данные о батарее из adb shell dumpsys battery и использовать внешние измерители (power meter) для точных данных. Для повторяемых измерений автоматизируйте очистку кэша и перезапуск сервисов, чтобы минимизировать влияние фоновой активности.

• adb, Android Profiler, systrace, perfetto
• TFLite Benchmark Tool / TFLite Interpreter + делегаты
• simpleperf для профилирования CPU
• dumpsys battery и внешние power meter для энергии

3. Инструменты и SDK для iOS: что важно настроить

Для iOS центром измерений является Xcode Instruments: Time Profiler, Energy Log, Allocations и GPU/Metal инструменты. Core ML и Metal Performance Shaders (MPS) — ключевые технологии для ускорения инференса. Для моделей, конвертированных в Core ML, фиксируйте версию конвертера и опции оптимизации.

Используйте os_signpost и unified logging для маркирования времени начала/конца инференса внутри приложения — это делает метрики точнее и упрощает анализ в Instruments. При сравнении с вариантами на CPU и GPU важно чётко указывать, используется ли MPSGraph, Metal delegate или чистый CPU-вариант.

Для замеров энергопотребления на iOS Instruments даёт хорошую оценку в обычных условиях; для более точных измерений применяют внешние power-meter устройства. Как и на Android, автоматизация тестов и единый формат экспорта данных (CSV/JSON) ускоряют повторяемость и сравнение результатов.

• Xcode Instruments: Time Profiler, Energy, Allocations
• os_signpost для маркировки операций инференса
• Core ML / MPS / Metal delegate
• Внешние power-meter для точных замеров энергии

4. Пошаговая методика бенчмаркинга — общая последовательность

Следуйте предсказуемой последовательности: 1) подготовка и базовая валидация модели (корректность выводов); 2) формализация сценариев тестирования; 3) настройка окружения на устройствах; 4) запуск прогрева; 5) измерение и сбор метрик; 6) анализ и валидация результатов; 7) итерации оптимизации; 8) финальная проверка перед релизом. Соблюдение порядка минимизирует систематические ошибки.

Каждый шаг должен быть зафиксирован в инструкции: какие команды запускать, какие флаги указывать, сколько итераций прогрева и измерений делать. Прогрев — обязательный пункт: не доверяйте первым измерениям, так как JIT-компиляция, кэши и динамическая оптимизация могут сильно искажать цифры.

Запуск тестов делайте многократно и по разным сценариям: одиночные инференсы, батчинг, параллельные запросы. Зафиксируйте среднее, стандартное отклонение и перцентили (p50, p95, p99). Это позволит понять не только типичную задержку, но и стабильность работы под реальной нагрузкой.

• 1. Валидация корректности модели
• 2. Описание тестовых сценариев
• 3. Прогрев (фиксированное число итераций)
• 4. Многократный сбор данных и расчёт перцентилей

5. Контрольные точки — чеклист перед каждым прогоном

Ниже — набор обязательных контрольных точек, которые нужно проверять перед запуском бенчмарка. Их соблюдение уменьшит рассогласование между прогоном и последующим анализом и позволит корректно сопоставлять результаты между устройствами и сборками.

Обязательно: 1) устройство заряжено и находится в одном температурном диапазоне; 2) фоновые приложения закрыты; 3) режим энергосбережения отключён; 4) сеть в нужном состоянии (если тесты зависят от сети) или полностью отключена для изоляции; 5) сборка приложения соответствует заявленному артефакту.

Также контролируйте параметры ОС и сервисов (автообновления, синхронизация) и фиксируйте версию рантайма и библиотек (TFLite, Core ML, NNAPI). Для сравнения снимайте логи состояния системы — это поможет объяснить неожиданные выбросы в метриках.

• Заряд > 50% / фиксированное состояние батареи
• Режим энергосбережения — выключен
• Фоновые процессы — остановлены
• Фиксация версий билда и библиотек

6. Настройка и запуск тестов на Android: практические рекомендации

Соберите две конфигурации: debug (с символами для профилирования) и release (с оптимизациями). На Android важно тестировать каждый делегат отдельно: CPU, GPU (если доступен), NNAPI. Для TFLite используйте опции детального логирования и TFLite Benchmark Tool для автоматизации замеров, но помните о необходимости прогрева интерпретатора.

Перед замером выполните 20–50 прогревочных итераций (или до стабильности времени), затем запускайте серию из N прогонов (рекомендуется не менее 100 для статистики). Автоматизируйте сбор логов через adb logcat и perfetto, чтобы получить последовательные профили активности CPU и I/O. Для проверки влияния частоты CPU используйте CPU governor и фиксируйте его состояние.

Если вы тестируете на GPU или через NNAPI, документируйте, какие драйверы и версии библиотек применялись. Для проверки памяти используйте dumpsys meminfo, а для отслеживания thermal throttling — sysfs и thermal-engine логи. Все команды и шаги записывайте в исполняемые скрипты для повторяемости.

• Прогрев: 20–50 итераций или пока время не стабилизируется
• Серийные запуски: ≥100 итераций для статистики
• Логи: adb logcat, perfetto, dumpsys meminfo

7. Настройка и запуск тестов на iOS: практические рекомендации

На iOS делайте замеры на реальных устройствах, а не в симуляторе. Включите сбор через Instruments: Time Profiler для CPU, GPU Driver для Metal, Energy для энергопотребления. Пометьте начальные и конечные точки инференса с помощью os_signpost, чтобы инструменты корректно агрегировали метрики по операциям.

Прогрев для iOS также обязателен — выполните фиксированное число прогревочных запросов и убедитесь, что температура устройства не растёт резко. Для сопоставимости тестов используйте build configuration Release с символами для профилирования, и фиксируйте режим производительности (например, Low Power Mode должен быть отключён).

Скачивайте и сохраняйте trace-файлы из Instruments для последующего разбора. При тестировании Core ML фиксируйте параметры модели (quantized/int8/float16), используемые опции и версию iOS — это часто критично для производительности и поведения MPS.

• Real device testing: выключить Low Power Mode
• Instruments: Time Profiler, Energy, Metal GPU tools
• os_signpost для точного тайминга операций

8. Тестирование и сбор метрик: какие данные собирать и как

Собирайте набор ключевых метрик: пиковая и средняя задержка (latency p50/p95/p99), throughput (запросы в секунду при заданном батче), использование CPU/GPU, потребление памяти, энергопотребление и стабильность (variance). Для каждого показателя сохраните метаданные: устройство, версия ОС, build, делегат, конфигурация модели и сценарий теста.

Форматируйте результаты в машиночитаемый вид (CSV/JSON) и сохраняйте трассы профайлеров отдельно. При сборе логов указывайте временные метки и id прогона — это упростит сопоставление с trace-файлами и анализ причин выбросов. Обязательно фиксируйте условия эксперимента: температура, заряд батареи, активность сети.

Не ориентируйтесь только на среднее значение: подпирайтесь перцентилями и наглядными графиками распределения. Если во время прогона наблюдаются выбросы, сверяйте их с системными логами — возможно, причиной стали фоновые процессы, thermal throttling или аварийные сборки.

• Latency: p50, p95, p99
• Throughput: запросы/сек при разных батчах
• Resource usage: CPU, GPU, RAM, energy
• Трассы профайлеров для глубокого анализа

9. Анализ результатов и сравнительная таблица метрик

При анализе начните с агрегирования результатов по конфигурациям (например, CPU vs NNAPI vs GPU). Рассчитывайте не только средние значения, но и перцентили и коэффициент вариации. Сравнивайте относительные изменения (процент выигрыша/падения) и сопоставляйте их с требованиями продукта — иногда стабильность важнее пикового времени отклика.

Ищите закономерности: у одной модели может быть лучше p50, у другой — p95; одна конфигурация выигрывает по энергопотреблению, но проигрывает по пропускной способности. Выявляйте узкие места через профилирование: hotspots в коде, действия с памятью или задержки на I/O. На основе профилей решайте, какие оптимизации (квантование, батчинг, делегаты) стоит применять.

Ниже приведена простая таблица с ключевыми метриками и рекомендациями по интерпретации — используйте её как шаблон для отчёта и как первую точку сравнения между прогоном на Android и iOS.

10. Запуск в продакшен и что проверить после релиза

После релиза контролируйте ключевые метрики и сигналы в реальном времени: latency, error rate, частоту падений и потребление ресурсов на устройствах пользователей. Инструменты мониторинга (remote logging, APM) должны уметь собирать lightweight-тайминги инференса; добавьте эвристики для выявления регрессий и триггеров для автоматических алертов.

Сравнивайте реальные данные с бенчмарком в контролируемой среде — ожидаемые абсолютные значения могут отличаться из-за разнообразия устройств и пользовательских сценариев. При обнаружении отклонений сначала проверьте корреляции с версиями ОС, апдейтами драйверов и изменениями в модели или рантайме.

В первые недели после выпуска проведите ретроспективу: сопоставьте данные A/B тестов, метрики реального использования и внутренние бенчмарки. Если нужно — подготовьте патч с исправлениями и повторно прогоняйте бенчмарки по тому же регламенту, чтобы убедиться в устранении регрессий.

• Remote logging: lightweight timing для инференса
• Алерты на отклонение p95/throughput
• Сопоставление с версиями ОС и билдов

Частые вопросы