Как мы исследовали энергоэффективность инференса нейросетей на планшете

Современные гаджеты невозможно представить без AI-функций. Размыть фон за спиной во время телеконференции, подавить шум от проходящих мимо коллег, вычесть «красные глаза» на фотографии — все это давно стало базовым функционалом любого устройства с камерой и микрофоном. Сейчас вендоры потребительских устройств устраивают настоящую «гонку вооружений», предлагая новые AI-функции, которые выделят устройство среди «собратьев». 

Но у всех AI-функций есть цена, которую приходится «платить» конечному потребителю — более быстрая трата батарейки и перегрев устройства. В итоге производители электроники сталкиваются с дилеммой: фичи нужны, их нужно много, но без значительного ущерба для батарейки.

Меня зовут Павел Буровский, я инженер-разработчик ПО искусственного интеллекта. Вместе с Яной Булиной, инженером отдела проектирования новых поколений технологического стека департамента ИИ в YADRO, мы измеряли энергоэффективность выполнения некоторых AI-функций планшета KVADRA_T. В статье расскажем, как организовали необходимые эксперименты, и покажем много графиков с результатами запусков на CPU, GPU и NPU.

Анатомия AI-функций: что под капотом

Давайте рассмотрим типичный сценарий размытия фона за спиной у пользователя во время видеоконференции. Приложение получает с камеры изображение высокого разрешения и, используя сверточную нейросеть, определяет, где на изображении лицо человека. Дальше оно обрабатывает картинку: там, где фон, картинку размывает, там, где лицо, оставляет без изменений (или подает на вход следующей нейросети, если нужно). 

Для нейросетей входное изображение нужно подготовить. Обычно они работают над изображениями небольшого размера и определенной цветовой кодировки. Так что на этом этапе приложение для видеоконференций должно:

• отмасштабировать изображение к размерности входных данных нейросети,

• переставить цветовые каналы местами, 

• сконвертировать целочисленные интенсивности цвета пикселов в каждом из цветовых каналов в вещественные числа (если инференс нейросети проходит в вещественных числах), 

• откалибровать интенсивности к интервалу [0,1].

Результат инференса следует обработать аналогичным образом до размытия фона: вернуть кодировку цветовых каналов, опять сделать resize к исходному разрешению и так далее.

Какие вычислительные устройства в этом задействованы 

Теперь посмотрим, какие вычислительные устройства (в идеальном сценарии) задействованы и как данные движутся между ними.

Шаг 1. Сначала камера устройства формирует текущий кадр. В этот момент сырые данные с сенсора камеры попадают в ISP (Image Signal Processor). Там производится первичная обработка данных сенсора в изображении и очистка этого изображения от визуальных артефактов. Изображение готово, и передается из ISP в пространство памяти CPU, в запущенное приложение для видеоконференций. Некоторые устройства умеют передавать данные с ISP напрямую в NPU, но мы описываем общий случай и в такие детали уходить не будем.

Шаг 2. Стадия препроцессинга обработки кадра: приложение готовит изображение к инференсу. Для работы с изображениями исходно придумали GPU. Но решение об использовании видеокарты зависит от объема работы, который, в свою очередь, зависит от AI-функции. Если работы относительно немного, приложения могут обработать все на CPU, а не передавать изображения в GPU для короткой цепочки их трансформаций.

Шаг 3. Стадия инференса: обработанная картинка отправляется в NPU (Neural Processing Unit). Это специализированный ускоритель инференса нейросетей, который в теории должен проводить его быстрее и энергоэффективнее остальных устройств (проверим это на практике чуть позже). Если нам не хочется отправлять картинку на обработку в NPU или его нет в устройстве, инференс придется исполнить на том, что есть в наличии.

Шаг 4. Стадия постпроцессинга результатов инференса. Результат отправляется в пространство памяти CPU, где приложение опять производит цепочку трансформаций изображения, выбирая между CPU или GPU.

Шаг 5. Только на этом этапе готовое изображение с размытием фона наконец-то отправляется в видеопамять GPU для отрисовки картинки на экране.

Тут мы рассмотрели «под лупой», пожалуй, самый простой AI-сценарий. Бывают и более сложные случаи обработки одного видеокадра. 

Например, на кадре нужно определить расположение лиц людей и каждое проверить на подлинность: настоящее ли оно или нарисованное на бумаге? Или даже фотореалистичное лицо, показанное с экрана другого устройства? Есть ли красные глаза и где они? А, может, сгладим неровности лица и нанесем макияж?

Кроме того, одновременно с видеопотоком есть аудиопоток. В нем может быть эхо от микрофона рядом с динамиком, звук пролетающего самолета, движущегося мимо автомобиля, или тот самый «непередаваемый» звук дрели в бетонных перекрытиях.

Во всех случаях данные могут бегать туда-сюда между вычислительными устройствами (CPU, GPU, NPU) много раз, а количество одновременно задействованных нейросетей может приближаться к паре десятков. 

Выше мы писали, что для относительно несложной обработки изображений приложение может выбирать между двумя вычислительными устройствами — CPU или GPU. Проще не станет, если учесть, что и инференс нейросетей можно производить на любом вычислительном устройстве. А поскольку софт для инференса пишут один раз для всего «зоопарка» на рынке, то этот софт должен обеспечивать эффективное исполнение нейросетей на всех поддерживаемых устройствах.

Так, есть NNAPI — стандартный API для инференса нейросетей в Android/AOSP до версий 13. В зависимости от конкретного планшета или телефона и установленных драйверов, он может предлагать 2-4 вычислительных устройства на выбор. Это может быть CPU, GPU, NPU и даже DSP (Digital Signal Processor). Последний часто идет тандемом к NPU, и в некоторых устройствах может быть задействован как самостоятельный вычислительный блок.

Фреймворки для инференса и их влияние на производительность

Итак, инференс нейросетей можно производить на разных вычислительных устройствах. Для этого используют специальные фреймворки, которые реализуют инференс не только на каком-то одном устройстве, но и поддерживают гетерогенный запуск. Производительность инференса на CPU, GPU или NPU зависит не только от характеристик вычислительного устройства, но и качества софта для него.

На устройствах с Android или производных ОС на базе AOSP наиболее часто используемый фреймворк инференса — TFLite. В нем есть механизм «делегатов» — программных слоев поддержки различных вычислительных устройств. Благодаря нему несложно запускать инференс на CPU или встроенном GPU, выбрав соответствующий делегат. Производительность такого инференса будет зависеть не только от характеристик железа, но и от качества оптимизаций в конкретном делегате.

Поддержка NPU чуть более затруднена по нескольким причинам: 

• Не существует фреймворка, который бы поддерживал все необходимые NPU. 

• Для CPU есть C/C++, для GPU — OpenCL/Vulkan. Для NPU же нет единого языка программирования, чтобы сделать компилятор этого языка ответственным за поддержку железа NPU и сфокусироваться в таком фреймворке на логике инференса в едином для всех NPU делегате.

• Каждый NPU обладает собственной архитектурой и поддерживает свое подмножество вычислительных слоев нейросетей. Вендоры NPU нередко предоставляют runtime к своему железу в бинарном виде, открывая только API и некоторое количество документации.

Все это делает эффективную поддержку производительности каждого конкретного NPU нетривиальной задачей, для решения которой часто нужна выделенная команда. 

Для планшета KVADRA_T встроенный NPU идет со своим собственным вендорским фреймворком, в составе которого открытый API и закрытый рантайм. Изучением производительности такого NPU для эффективного применения в AI-нагрузках как раз и занимаются в отделе проектирования новых поколений технологического стека YADRO. Кроме поддержки NPU, целые команды оптимизируют инференс нейронных сетей на CPU и GPU — от программной оптимизации исполнения конкретных слоев до применения тензорных компиляторов.

Ранее наш коллега рассказал, как можно разработать тензорный компилятор для процессора на базе открытой архитектуры RISC-V с помощью OpenVINO и MLIR.

Как измерить энергоэффективность вычислений

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

Какое из доступных устройств планшета KVADRA_T — CPU, GPU или NPU — выгоднее использовать для инференса нейросетей в реальных сценариях? Давайте узнаем. 

Для этого мы проведем эксперимент с исключением фонового энергопотребления от других подсистем планшета. Однако измерить энергоэффективность вычисления отдельных подсистем чипа нельзя. Для надежных данных требуется аппаратная поддержка измерения уровня расхода энергии каждого вычислительного блока на кристалле, и чаще всего ее нет. Поэтому нам придется поставить ряд косвенных экспериментов.

Методология бенчмаркинга

Эксперименты мы проведем на рядовом планшете KVADRA_T из массовой партии. На нем установлена отладочная прошивка kvadraOS, максимально приближенная к публичной версии kvadraOS 1.8.0. Она позволяет запускать консольные приложения в adb shell с правами root, чем мы и воспользуемся. 

Теперь опишем, что мы учитываем в экспериментах. 

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

Будем держать экран всегда включенным. С точки зрения пользователя, при активном использовании планшета экран включен, а в период покоя — выключен. При выключенном экране мобильное устройство на базе kvadraOS уходит в сон и не выполняет полезной работы. Так что, проводя эксперименты, планшет нужно оставлять с постоянно включенным экраном. Расход энергии на него можно считать константой, одинаковой для всех экспериментов вне зависимости от загрузки вычислительных устройств. Запретим автоматическое отключение экрана в соответствующих настройках: Настройки → Экран и яркость → Время отключения экрана и выберем вариант Никогда.

Для оценки константной нагрузки от включенного экрана проведем две простых проверки. 

Сначала зарядим планшет до 100%, выдернем шнур USB и дадим планшету полежать с выключенным экраном ровно 2 часа. У нас планшет за два часа разрядился на 1%.  Так мы получили уровень потребления устройства в состоянии покоя. Значит, все потребление энергии, которое мы измерим потом, будет скорее связано с дополнительными нагрузками.

Затем запретим экрану выключаться, опять зарядим планшет до 100%, выдернем шнур USB и дадим планшету полежать уже со включенным экраном, тоже ровно 2 часа. На этот раз планшет разрядился на 9%. Если первая проверка, с выключенным экраном, проверяла, что нет катастрофических аномалий с железом, то эта проверка говорит, что эти 9%, собственно, накладные расходы от включенного экрана и активного CPU с запущенной на нем ОС этой версии.

Для калибровки наших измерений обратимся к специализированному измерительному стенду коллег из команды kvadraOS. Коллеги собрали его для детального изучения, сколько энергии под нагрузкой потребляют те или иные компоненты планшета. Стенд состоит из планшета (массовой партии), измерительной аппаратуры и тестовых линий от измерительного прибора к точкам подключения на материнской плате планшета. 

Коллеги, которые разрабатывают kvadraOS, подтверждают, что наши измерения соответствуют наблюдениям на стенде. 

Дисклеймер: дальнейшие обновления kvadraOS могут поменять полученные значения достаточно существенно. За время проведения экспериментов коллеги доработали части операционной системы, влияющие на энергоэффективность, и работа по улучшению kvadraOS, естественно, продолжится. Но для нашего эксперимента достаточно такого замера.

Метод проведения запусков. Для экспериментов мы будем использовать консольное приложение. Но как делать запуски в adb shell, если планшет переведен в авиарежим? Для этого придется подключаться к планшету по USB. Но и тут есть проблема: подключение по USB дополнительно заряжает батарейку.

При каждом запуске приложения мы:

1. Стартуем с полного заряда, чтобы USB-подключение в момент запуска не добавляло неконтролируемый заряд батарейке.

2. Ставим на 2 часа запуск персистентного процесса с помощью утилиты nohup и быстро-быстро вытаскиваем USB-шнур.

3. Затем приходим через два часа, снова подключаемся по USB и инспектируем логи.

Условные 5 секунд, которые планшет в начале эксперимента был еще подключен по USB, дают пренебрежимую погрешность измерений энергопотребления на фоне 2 часов времени работы одного теста. А если в начале эксперимента в скрипте поставить sleep 5 –, то тестируемое приложение даже не начнет запуск, когда мы вытащим USB-шнур. За это время CPU не успеет раскрутиться на полную, и  энергопотребление при подключенном USB будет минимальным.

Небольшое отступление про «научность метода» сбора данных 

Обычно методология бенчмаркинга производительности подразумевает детальный контроль тактовых частот CPU, привязки процессов к конкретным ядрам CPU и исключение всех внешних «раздражителей». Иначе невозможно надежно отличить собственно исследуемую нагрузку от «фоновой». Ведь исследуемое приложение живет не в вакууме, а в операционной системе, активирующей различные фоновые процессы. К тому же в реальности пользователь может (и обязательно будет) одновременно запускать несколько приложений.

Тут мы попробуем проплыть между двумя крайностями. 

С одной стороны, у нас не микробенчмаркинг. Строго контролируемый, научный подход к бенчмаркингу мы не сможем воспроизвести. Наши нагрузки — сложные, большие приложения, состоящие из нескольких фреймворков. И запускаемое приложение вместе со всеми библиотеками тянет на полгигабайта бинарных файлов. Мы не сможем реализовать нагрузки, похожие на реалистичный пользовательский сценарий, в виде изолированных микробенчмарков. И, стараясь сделать процесс запусков приближенным к пользовательскому сценарию, мы не должны ограничивать тактовые частоты CPU и окружение. Точно так же это не будет делать конечный пользователь. Поэтому наши измерения неизбежно будут «плыть» — вопрос лишь в том, насколько сильно. 

С другой стороны, мы не делаем интегральное пользовательское тестирование, которое часто можно увидеть в рецензиях новых гаджетов: техноблогер неделю ходит с девайсом под мышкой на работу и в сауну, стараясь использовать все фичи. У нас задача изолированная: оценить, можно ли достаточно уверенно выбрать конкретный вычислительный девайс (CPU, GPU или NPU) у планшета KVADRA_T для определенного класса нагрузок.

Так как мы проводим относительное сравнение, а не замер абсолютных показателей, в нашем эксперименте мы лишь делаем однотипные запуски повторяющегося вычисления и смотрим на разряд батареи. Проснулась ОС больше или меньше раз? Поднялась ли тактовая частота CPU тут и там? Если делать однотипные запуски на несколько часов, «дрожания» железа и софта выровняются и сгладятся, а влияние «внешних раздражителей» станет более-менее похожим на константное. Для экспериментов, описанных в статье, мы выбрали два часа как минимальное время запуска теста для усреднения «шумящих» показателей (и максимальное для нашего терпения).

Метод контроля разряда батарейки. Расход мы будем контролировать с помощью logcat. В adb shell запустим:

logcat -d | grep healthd | grep = | tail -n 2 

Получим строки вида:

08-29 02:35:11.959   485   485 W healthd : battery l=81 v=8110 t=34.5 h=2 st=3 c=-512000 fc=9000000 chg= 08-29 02:36:41.815   485   485 W healthd : battery l=81 v=8104 t=34.5 h=2 st=3 c=-512000 fc=9000000 chg=

Тут нас интересуют: 

• дата 08-29 02:35:11.959 (месяц, день, час, минуты, секунды), 

• l = 81 — 81% заряда батареи,

• c = –512000: отрицательное значение — идет разряд батареи, положительное — батарея заряжается, ноль — батарея заряжена.

Контроль значений из logcat будем делать в самом начале и конце персистентного процесса (persistent process), запускаемого с помощью nohup. В результате будем смотреть на разницу в заряде батареи.

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

echo "sleep 5s" sleep 5s  echo "Fingerprint:" getprop ro.vendor.build.fingerprint  echo "time before benchmarking" date  echo ${EXPERIMENT_NAME} echo  echo "energy before benchmarking: " logcat -d  | grep healthd | grep = | tail -n 2 echo  export RUN="./${APP} ${RUN_OPTIONS} ${THREADING_OPTIONS}" echo ${RUN} ${LIMIT} ${RUN} ${LIMIT}  echo "time after benchmarking:" date  echo echo "energy after benchmarking:" logcat -d  | grep healthd | grep = | tail -n 2

Запускать его будем так:

nohup ./run_script.sh &

Тестовое приложение для нагрузочного тестирования

Для экспериментов возьмем демонстрационное приложение распознавания лиц, функционально эквивалентное сценарию разблокировки планшета по изображению с камеры (face unlock). Обработка каждого изображения из входящего потока состоит из трех стадий:

• Детекция лица (face detection) — поиск лиц на картинке.

• Распознавание лиц (face recognition) — для каждого найденного лица: распознавание относительно заготовленных образцов.

• Проверка подлинности лица (face anti-spoofing, antispoof) — для каждого найденного лица: защита от подделок, проверка на аутентичность. Планшет должен уметь определять, что к нему подошел истинный владелец, а не злоумышленник с его портретом. 

Каждая стадия обработки входящего изображения состоит из:

• препроцессинга изображения (строго на CPU),

• собственно инференса (на CPU, GPU или NPU),

• постпроцессинга (строго на CPU).

Пре- и постпроцессинг изображений делается полностью на CPU. В нашем приложении эти стадии обработки кадра занимают несущественное время (доказывающие это цифры и графики будут в разделе с результатами), и от применения GPU скорее станут медленнее.

А вот инференс для каждой стадии в этом приложении можно отправлять на любое из доступных устройств. Для инференса на CPU и GPU используется TFLite 2.17.0, а на NPU работает вендорский фреймворк (для конкретности ниже его будем обозначать аббревиатурой VFNPU). Стадии обработки кадра используют публичные модели топологий blaze_face, ghostfacenet и minifasnet в форматах .tflite и бинарном формате VFNPU (результат нашей конверсии .tflite моделей в этот формат, используя конвертер моделей из пакета VFNPU). С поддержкой ghostfacenet, в целом, возникли проблемы, которые мы опишем позже.

Размер моделей и их глубина (в формате .tflite):

• blaze_face: объем данных порядка мегабайта, 353 скрытых слоя,

• ghostfacenet: 15.5MB, 241 слой,

• minifasnet: 1.7 MB, 361 слой.

При этом «сложность» инференса существенно варьируется от слоя к слою. Также для каждого типа слоев она зависит от мета-параметров этого слоя: размерности сверток, наличия нетривиальных страйдов и так далее.

В разных фреймворках инференса каждый слой нейросети для каждого типа вычислительного устройства оптимизирован по-разному. Поэтому заранее точно предсказать производительность инференса по глубине сети или ее архитектуре (топологии сети, используемым слоям) почти никогда нельзя.

Есть нюанс в типах данных. Модели для TFLite выполняются в точности fp32, но этот тип данных нативно не поддерживается железом NPU — для него модели конвертированы в fp16 фреймворком от вендора. 

В рамках эксперимента мы не стали сравнивать инференс моделей, «квантизованных» нами в различные типы данных (fp16, int16, int8, …). Для этого потребовалось бы дополнительно проверять качество квантизации. Грубо говоря, проверять, что модель, исходно рассчитанная при инференсе в fp32 определять на изображении котиков, после квантизации в int8 все еще определяет котиков. А это выходит за рамки статьи.

Тем не менее, TFLite позволяет производить наиболее вычислительно нагруженные части вычисления в fp16 при входной модели с весами в fp32. Это некоторый компромисс. Пользователь не должен производить предварительные манипуляции с входной моделью, конвертируя ее из fp32 в fp16. При этом TFLite производит конверсию между fp32 и fp16 «на лету», достигая двукратных ускорений на тех CPU, которые уже поддерживают fp16. Подробнее — здесь.

Выбранное для теста приложение — консольное. Оно должно максимально нагрузить вычислительные устройства работой в сценарии, приближенном к настоящему, но при этом исключить влияние смежных устройств и библиотек. Например, мы не хотим учитывать время на захват кадра с камеры и копирование данных этого кадра между различными HW-устройствами и слоями API в ОС. Поэтому мы заранее приготовили подборку фотографий с различным количеством лиц на каждой (в среднем по одному лицу на изображение) и при запусках будем циклически пробегаться по ней.  

Приложение принимает аргументы командной строки, с помощью которых можно:

• Задать время работы эксперимента (например, 2 часа).

• Для каждой из трех стадий по отдельности: проводить ли инференс на CPU, GPU или NPU,

• Для каждой из трех стадий по отдельности: какое количество потоков использовать на выбранном устройстве. Можно и не указывать, тогда используются настройки по умолчанию.

Пример запуска

Перед тем как перейти к результатам экспериментов, покажем, как они у нас получались. Для примера рассмотрим детальный лог одного из запусков. Этот файл — содержимое файла nohup.out, который можно найти в директории запуска после команды nohup ./run_script.sh &.

sleep 5s  Fingerprint: Kvadra/ts11_consumer/ts11:12/kvadraOS_Nightly_Release_2024-08-21/builduser08210506:userdebug/release-keys  time before benchmarking Sat Aug 24 21:12:05 MSK 2024  Running inferences on: CPU (blazeface, tflite, 4cores), NPU (ghostfacenet, auto), NPU (minifasnet, auto)  energy before benchmarking:  08-25 15:44:58.686   485   485 W healthd : battery l=100 v=8650 t=27.5 h=2 st=3 c=320000 fc=9000000 chg= 08-25 15:45:01.358   485   485 W healthd : battery l=100 v=8518 t=28.0 h=2 st=3 c=-256000 fc=9000000 chg=  ./face_recognition_demo_omit-frame-pointer -dfd CPU -dreid NPU -das NPU --nthreads_fd=4 -i data/images --loop --noshow --detailed_report --db data_base.json --time 7200 [ INFO ] Create face detection model [ INFO ] Inference adapter: TFLite 2.17.0 [ INFO ] Loading model to CPU device [ INFO ] Preparing inputs/outputs for model [ INFO ] Model inputs: [ INFO ] input: FP32 [1,192,192,3] [ INFO ] Model outputs: [ INFO ] reshaped_classifier_face_4: FP32 [1,2304,1] [ INFO ] reshaped_regressor_face_4: FP32 [1,2304,16] [ INFO ] Create face recognition model [ INFO ] Loading model to NPU device [ INFO ] Model inputs: [ INFO ] serving_default_input_5:0: FP16 [1,112,112,3] [ INFO ] Model outputs: [ INFO ] StatefulPartitionedCall:0: FP16 [1,512] [ INFO ] Initialize antispoof model [ INFO ] Loading model to NPU device [ INFO ] Model inputs: [ INFO ] input: FP16 [1,3,80,80] [ INFO ] Model outputs: [ INFO ] Identity: FP16 [1,3] [ INFO ] Time limit: 7200 sec [ INFO ]  [ INFO ] Total elapsed time: 7200.1 s [ INFO ] Total processed frames: 125471 [ INFO ] Total metrics report: [ INFO ] Latency: 56.1 ms [ INFO ] FPS: 17.4 [ INFO ]  [ INFO ] Face Detection Stage [ INFO ] --------------------- [ INFO ] Total Latency: 9.99 ms [ INFO ] Average Detections Count: 1.0 [ INFO ] BlazeFace metrics report: [ INFO ] Average Latency: 9.92 ms [ INFO ] Pre-processing : 1.73 ms [ INFO ] - Color Convert       : 0.15 ms [ INFO ] - Create Tensor       : 0.45 ms [ INFO ] - Interop             : 0.14 ms [ INFO ] - Normalize           : 1.60 ms [ INFO ] - Resize              : 1.43 ms [ INFO ] Inference      : 8.16 ms [ INFO ] Post-processing: 0.02 ms [ INFO ]  [ INFO ] Antispoofing Stage [ INFO ] --------------------- [ INFO ] Total Latency: 5.03 ms [ INFO ] Average Inferences Count: 1.0 [ INFO ] MiniFASNetV2 metrics report: [ INFO ] Average Latency: 4.80 ms [ INFO ] Pre-processing : 0.97 ms [ INFO ] - Create Tensor       : 2.55 ms [ INFO ] - Crop                : 425.97 ms [ INFO ] - Interop             : 3.16 ms [ INFO ] - Resize              : 157.63 ms [ INFO ] - Transpose           : 35.88 ms [ INFO ] Inference      : 3.83 ms [ INFO ] Post-processing: 0.00 ms [ INFO ]  [ INFO ] Face Recognition Stage [ INFO ] ---------------------- [ INFO ] Total Latency: 14.97 ms [ INFO ] Average Inferences Count: 1.0 [ INFO ] GhostFaceNet metrics report: [ INFO ] Average Latency: 14.31 ms [ INFO ] Pre-processing : 1.00 ms [ INFO ] - Color Convert       : 14.95 ms [ INFO ] - Create Tensor       : 5.88 ms [ INFO ] - Interop             : 1.83 ms [ INFO ] - Warp Affine         : 618.56 ms [ INFO ] Inference      : 13.31 ms [ INFO ] Post-processing: 0.00 ms [ INFO ]  [ INFO ] Re-ID Stage [ INFO ] ---------------------- [ INFO ] Total Latency: 0.04 ms [ INFO ] Number of faces in data base: 2 [ INFO ]  [ INFO ] Resources usage: [ INFO ] Mean core utilization: 11.7% 8.8% 8.9% 6.2% 17.7% 32.5% 14.7% 32.0%  [ INFO ] Mean CPU utilization: 16.6% [ INFO ] Memory mean usage: 2.0 GiB [ INFO ] Mean swap usage: 0.0 GiB  time after benchmarking: Sat Aug 24 23:12:06 MSK 2024  energy after benchmarking: 08-25 17:44:49.835   485   485 W healthd : battery l=72 v=7952 t=33.0 h=2 st=3 c=-512000 fc=9000000 chg= 08-25 17:44:58.637   485   485 W healthd : battery l=72 v=7930 t=33.0 h=2 st=3 c=-512000 fc=9000000 chg=

Рассмотрим этот лог сверху вниз: 

1. Видим так называемый fingerprint, то есть строку-идентификатор сборки операционной системы планшета. Это полезно для отслеживания логов во время эксперимента (пока мы готовили статью, сменилось несколько прошивок kvadraOS). 

2. Текущая дата эксперимента — обратите внимание на различие в дате и времени от команды date и в логах healthd (пожимаем плечами, идем дальше).

3. Затем лог уточняет, как именно было запущено нагрузочное тестирование. face detection — на CPU в 4 потока с помощью фреймворка TFLite, face recognition и antispoof — на NPU с помощью вендорского фреймворка в автоматических настройках распределения нагрузки по ядрам NPU.

4. Далее идет фрагмент лога демона healthd, запущенного до нагрузочного тестирования: лог показывает, что запуск стартует со 100% заряда батареи, но разряд батареи уже начался (значение c = –256000 отрицательное).

5. Следом видим большой блок запуска нагрузочного теста, за которым идет еще один вывод команды date и фрагмент лога healthd, собранного сразу после вычисления. 

6. Из последних строк лога видно, что вычисление закончилось в 23:12:06 (начавшись в 21:12:05 и заняв два часа) и батарейка разрядилась до 72%.

Заметьте, что бинарное имя консольного приложения содержит omit-frame-pointer. Мы собирали приложения двумя способами, в том числе с опцией -fno-omit-frame-pointer, которая полезна для профилирования приложения и раскрутки стека. Во время «пристрелочных» запусков мы проверили профайлером, что во время запуска на системные вызовы и активность ОС было потрачено пренебрежимо малое количество времени. Запуски, вошедшие в результаты эксперимента, проводились без профайлера и с использованием сборки без опции -fno-omit-frame-pointer.

Тест при запуске выдает детальный лог, показывающий, например, следующее:

• запуск шел с ограничением по времени в 7200 сек,

• за это время было обработано 125 471 кадра,

• достигнуто значение метрики FPS 17.4. Проверка: делим 125 471 кадр на 7 200 секунды, получаем 17.42.

• затем идет детализация запуска для трех стадий обработки кадра; из нее следует, что, например, в случае face detection препроцессинг составил 1.73 мс, постпроцессинг — 0.02 мс, доминировал в запуске инференс в 8.16 мс.

• средняя загрузка CPU при запуске не превышала 17%, что логично, учитывая относительно большое время, потраченное на инференс на NPU.

Обратите внимание, что запуск модели ghostfacenet доминирует по сравнению с инференсом двух других моделей. Было бы здорово объяснить это архитектурой нейросети, но тут начинается сюжет другой статьи. Также интересно, что суммарная задержка на обработку кадра (значение Latency 56.1 мс в разделе Total metrics report) больше, чем сумма задержек трех стадий обработки кадра: куда-то «делись» 56.1 − 9.99 − 5.03 − 14.97 = 26.11 мс. Фактически они ушли на чтение кадра, копирование данных, рендеринг изображения и прочие накладные расходы. 

Не удивляемся: у всякого вычисления есть накладные расходы, они же пространство/возможности для оптимизаций. Выбранное приложение не претендует на оптимальную производительность, это скорее mock функционала разблокировки планшета по лицу. При реализации рассматриваемой AI-функции в каком-то другом приложении и накладные расходы будут другими. Однако в нашем эксперименте такие дополнительные задержки делают менее очевидной связь между производительностью отдельных стадий вычисления и итоговым энергопотреблением.

Результаты

Мы провели запуски приложения в следующих комбинациях:

Запуски на CPU мы проводили для 1, 2 и 4 потоков. Мы не управляли тактовыми частотами и привязкой потоков к ядрам, потому что этого не будет делать пользователь. 

Мы отдаем себе отчет, что в конечном высоконагруженном приложении с большим количеством AI-функций эти нагрузки могут быть размещены на совсем других ядрах. А еще — за время исполнения приложения они бы могли мигрировать с одних ядер на другие (вспоминаем, что у современных мобильных big.LITTLE-устройствах, как правило, CPU-ядра разной производительности). У нас нет цели рассмотреть в рамках статьи все возможные сценарии.

Также для запусков на CPU мы сравнивали инференс в fp32 — нативной точности исходной модели — и в fp16. Для fp16 мы модель не квантизовали, но использовали параметр нашего консольного приложения для вызова XNNPACK-делегата TFLite, предоставляющего возможность принудительного инференса в fp16 независимо от метаданных модели. В таком случае данные «на лету» конвертируются из fp32 в fp16. 

При выборе параметров для наших запусков мы столкнулись с несколькими проблемами, связанными с ограниченной поддержкой модели ghostfacenet для стадии face recognition. Инференс для нее завершается аварийно в двух случаях: 

• при запуске с GPU делегатом TFLite,

• при запуске с XNNPACK в качестве CPU-делегата TFLite в точности fp16.

Изучение причин падений и их исправление — не тема этой статьи. Мы просто отбросили все комбинации неуспешных запусков. Поэтому, запуская другие модели на GPU, инференс именно этой модели мы проведем на CPU или NPU. И при запусках на CPU используем референсный CPU-делегат.

Для запусков на GPU мы использовали настройки по умолчанию. Оптимальным подбором параметров запуска на GPU мы не занимались по двум причинам. Во-первых, это отдельная большая работа. Во-вторых, как мы уже писали, для этой статьи нас интересовала поддержка вычислительных устройств фреймворками «из коробки», без тонкой доводки. 

При инференсе на NPU мы различали следующие запуски: 

• в настройке по умолчанию, 

• запуск всего инференса на одном ядре NPU, 

• запуск на трех ядрах сразу.

Пояснение. Фреймворк от вендора различает четыре вида управления потоками: автоматический, где распределение нагрузки между тремя ядрами NPU определяется фреймворком, и три режима распределения нагрузки между одним, двумя и тремя ядрами сразу. Тут мы проверили три варианта из четырех.

Время обработки одного кадра

Сначала посмотрим, куда тратится время в процессе обработки одного кадра. На примере запуска H, лог которого мы уже приводили в предыдущей секции:

Здесь цветовая гамма (синий, оранжевый, серый, зеленый) соответствует цветовой гамме диаграмм, приведенных в следующем разделе:

• зеленый обозначает инференс на NPU, 

• серый — инференс на CPU, 

• остальные цвета (синий, оранжевый) — исполнение различных подготовительных и иных вычислений на CPU. 

• розовый — суммарные накладные расходы на обработку кадра, специфичную для этого демо-приложения, которую мы обсуждали в предыдущей секции.

Сравнение производительности инференса на различных устройствах

Следующие три графика для каждой стадии обработки кадра (face detection, face recognition, antispoof) сравнивают производительность инференса на различных вычислительных устройствах (CPU, GPU и NPU). Для наглядности, кроме времени инференса, мы также добавили время выполнения препроцессинга и постпроцессинга соответствующей стадии обработки кадра.

Что мы видим на этих графиках? 

Во-первых, для всех трех стадий обработки кадра доминирует инференс, а производительность инференса моделей для разных стадий измеримо отличается. Посмотрим на запуск E: для face detection инференс составляет 5.45 мс, для face recognition — 13.7 мс, для antispoofing — 3.92 мс. 

Во-вторых, разница в производительности инференса для «хороших» (более быстрых) и «плохих» (более медленных) запусков составляет в среднем 3-4 раза. Сравним запуски О и Е для face detection: время работы инференса 14.11 мс против 5.45 мс — разница в 2.5 раза. Для face recognition разница между запусками A и M составляет уже 3.2 раза, а для antispoofing разница между запусками О и H и вовсе 4.4. 

Для antispoofing и face recognition виден существенный разрыв в производительности между «хорошими» и «плохими» запусками: почти все «плохие» столбики очень высокие, а «хорошие» — низкие. Для face detection это менее заметно, тут спектр значений более равномерный.  

Также для AI-сценария разблокировки планшета по изображению с камеры препроцессинг составляет небольшую (чаще — незначительную) часть вычисления, а постпроцессинг и вовсе вносит микроскопический вклад (NB: для других AI-сценариев это может быть совсем не так). Лишь для face detection препроцессинг составляет сколько-нибудь значимую часть времени от обработки кадра. Мы даже убрали числовые значения для постпроцессинга с графиков для antispoofing и face recognition: значения там не более 0.01 мс. 

Соотношение FPS и разряда батарейки

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

Такое отображение данных скорее мешает понять происходящее, чем помогает. Для метрики FPS чем больше значение, тем лучше. А для метрики Discharge (разряд батареи) наоборот. Из-за этого трудно на глазок сравнивать запуски друг с другом. Тем не менее, отсюда видно, что запуски с бо́льшим значением FPS могут давать худшее значение разряда. Иными словами, быстрее не всегда значит лучше для батареи. Например, FPS у запуска E (значение 18.0) выше, чем у запуска F (значение 9.7), но для времени жизни от батареи запуск F лучше (20% разряда против 23.5%).

Для лучшей наглядности построим график с этими двумя метриками по разным осям и обозначим для полученных точек фронт Парето. 

Такие диаграммы строят, когда есть две равнозначно полезные метрики и нужный пользователю баланс между показателями этих метрик зависит от контекста. Невозможно заранее выбрать, что пользователю важнее: максимальная производительность (FPS) с неважно каким значением разряда (battery discharge) или, наоборот, минимальный разряд при неважно каком значении производительности. 

Каждый запуск, дающий пару (FPS, значение разряда батареи), изображается точкой на диаграмме. При этом идеальный запуск — это такой, для которого значение FPS максимально, а разряд батареи минимален — обозначался бы точкой в правом нижнем углу диаграммы. 

Все точки, оказывающиеся выше и левее очерченной огибающей наших измерений (так называемому фронту Парето), заведомо хуже точек, которые попали на эту огибающую. Те запуски, что выше и левее фронта Парето, в равной степени неудовлетворительны и по значению разряда, и по значению производительности. В то же время запуски, попавшие на фронт Парето, оказываются в равной степени неплохи — как минимум до тех пор, пока пользователь не озвучит свои предпочтения.

К каким выводам и ответам нас приводит диаграмма

Запуски с самым быстрым инференсом в отдельных стадиях (запуск Е для face detection, запуск M для face recognition и запуск H для antispoofing) не попали на фронт Парето. Быстро в отдельных стадиях — не всегда хорошо для запуска в целом.

Помогает ли энергоэффективности использование GPU?

Запуски K, L и M c использованием GPU даже близко не подходят к фронту Парето. По «плохости» они сравнимы с запуском A (CPU работает в один поток на всех трех моделях) и запусками S, H и C (во всех трех запусках CPU обрабатывает инференс как минимум одной модели в 4 потока, производя вычисления в fp32). 

Вывод: GPU этого конкретного планшета, с текущим драйвером и качеством оптимизаций в GPU-делегате TFLite, скорее мешает экономить батарею, чем помогает.

Помогает ли переход от fp32 к fp16 при инференсе на CPU?

• Запуск D против E: запуск Е с вычислением в fp16 оказался прямо на фронте Парето — он и быстрее, и менее прожорливый для батареи.

• F против G: ничего сказать нельзя — оба плохи.

• H против I: запуск I оказался на фронте Парето.

• Q против R: ничего сказать нельзя  — оба плохи.

• S против T: запуск T оказался чуть менее прожорливым для батареи.

Вывод: инференс в fp16 скорее помогает, чем нет.

Сколько ядер CPU лучше использовать?

• Сравним запуски R и T: запуск R, исполняющий antispoofing в два потока, оказался более удачным, чем запуск T, делающий то же самое в четыре потока.

• В паре запусков K и L хуже запуск, исполняющий face recognition в четыре потока, — хотя, для справедливости, оба запуска плохи (очень далеки от правого нижнего угла диаграммы).

• В паре запусков A и C аналогичный вывод сделать нельзя: у запуска А лучше энергоэффективность, но хуже показатель FPS, у запуска C — наоборот. Они несравнимы. 

Вывод: Запуск в один поток явно плох. Однозначный выбор между запусками в два и четыре потока сделать нельзя. Пояснительная бригада: закончить вычисление на CPU побыстрее и дать CPU побыстрее заснуть — внешне разумная идея, объясняющая неудачу запусков в один поток (у CPU велико статическое потребление энергии, запуск в один поток просто оттягивает уход в сон). Но выигрыш во времени запуска, в отличие от электропотребления, растет не пропорционально числу используемых потоков. Для подробных и точных выводов нам тут не хватает данных. Для этой статьи ключевое наблюдение в том, что CPU хотя бы иногда, для некоторых моделей, оказывается разумным выбором по сравнению с NPU — об этом чуть ниже.

Помогает ли управление числом ядер для данного NPU и его фреймворка?

• Точно не помогает выбор всех трех ядер NPU: запуски F, G и О проводились именно так — итог печальный. Запуск О оказался на фронте Парето, но при одинаковом разряде с запуском N (17%) запуск О дает практически вдвое меньший FPS, чем запуск N. А нам FPS и так не хватает.

• Запуски N и P оказались на диаграмме очень близки друг к другу. Запуск P, проводившийся с указанием одного ядра NPU, оказался чуть лучше запуска N, проводившегося с указанием автоматического распределения нагрузки между ядрами NPU. 

• Аналогично, запуски E и I оказались весьма близки друг к другу на диаграмме — тут разница в позициях на графике может быть близка к порядку ошибки измерений.

Вывод: В нашем эксперименте запуски нагрузки на трех ядрах NPU дали стабильно неудовлетворительные результаты. А вот использование одного ядра или автоматическая балансировка нагрузки показали себя одинаково хорошо.

Какие запуски в итоге попали на фронт Парето и оказались максимально близки к нему?

• Запуски, максимально задействующие NPU (O, N, P) для всех трех стадий обработки кадра: минимальный разряд батареи (17–18%) и инференс порядка 15 FPS (для N и P).

• Запуски E и I, оставляющие face detection на CPU, а остальные две стадии — на NPU: тут разряд батареи порядка 24%, но и частота обработки кадра подросла до 18 FPS.

Добавим к этому, что разница в пару FPS вряд ли окажет существенное влияние на user experience. Получили 15 FPS или 18 FPS при обработке кадра — это все равно примерно вдвое меньше показателя, при котором пользователь вообще не заметит процесса обработки (для этого нужно как минимум 30 FPS). А вот 15 FPS против 8.6 FPS — это уже почти вдвое лучше. Вот так мы только что озвучили свои экспертные предпочтения для выбора «наилучшей» точки на фронте Парето.

Наилучшими запусками стали N и P, дающие 15 FPS и 17–18% разряда батареи за 2 часа эксперимента. В запусках N и P мы используем только NPU. Если же мы хотим использовать CPU для инференса, то наилучший вариант использовать CPU — в 4 потока, в точности fp16 и только для стадии face detection с моделью blaze_face.

Также интересно, что запуски c NPU стабильно более энергоэффективны. Несмотря на то, что задержка в случае обработки инференса на стадии face detection на NPU выше (12.19–14.11 мс), чем на CPU (от 5.45 мс)!

В заключение

Для инференса нейросетей придумали специальное устройство — NPU, и в большинстве случаев выполнять его желательно именно на нем. 

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

Наш эксперимент показывает, что эффект от использования GPU c GPU-делегатом фреймворка TFLite 2.17.0 на планшете KVADRA_T строго отрицательный (если мы оцениваем энергоэффективности таких запусков). Возможно, будущие оптимизации GPU-делегата исправят ситуацию, однако в нашем случае для этого как минимум необходима поддержка модели ghostfacenet и ей подобных.

Мы также подтвердили экспериментально, что во всех случаях использовать NPU выгоднее для энергоэффективности. Но, если очень хочется «поднажать», для некоторых нейросетей можно использовать CPU: чуть выиграем в FPS, чуть проиграем во времени жизни планшета от батареи.