Представители LiteRT

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

По умолчанию LiteRT использует ядра ЦП, оптимизированные для набора инструкций ARM Neon . Однако этот ЦП является многоцелевым и не обязательно оптимизирован для сложных арифметических операций, типичных для моделей машинного обучения (например, для матричных вычислений, используемых в свёртке и плотных слоях).

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

У каждого из этих ускорителей есть свои API, позволяющие выполнять специальные вычисления, например, OpenCL или OpenGL ES для мобильных графических процессоров. Обычно для запуска нейронной сети через эти интерфейсы приходится писать много кода. Ситуация ещё больше усложняется, если учесть, что у каждого ускорителя есть свои плюсы и минусы, и он не может выполнять все операции в нейронной сети. API Delegate в TensorFlow Lite решает эту проблему, выступая в качестве моста между средой выполнения TFLite и этими низкоуровневыми API.

время выполнения с делегатами

Выбор делегата

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

Делегаты по платформам

Кроссплатформенность (Android и iOS)

GPU delegate — GPU delegate можно использовать как на Android, так и на iOS. Он оптимизирован для работы с 32- и 16-битными моделями с плавающей точкой при наличии графического процессора. Он также поддерживает 8-битные квантованные модели и обеспечивает производительность GPU на уровне их версий с плавающей точкой. Подробнее о GPU delegate см. в статье LiteRT о GPU .

iOS

Делегат Core ML для новых iPhone и iPad . Для новых iPhone и iPad, на которых доступен Neural Engine, можно использовать делегат Core ML для ускорения вывода 32- или 16-битных моделей с плавающей запятой. Neural Engine доступен на мобильных устройствах Apple с процессором A12 или выше. Обзор делегата Core ML и пошаговые инструкции см. в статье LiteRT Core ML delegate .

Делегаты по типу модели

Каждый ускоритель разработан с учётом определённой разрядности данных. Если предоставить модель с плавающей запятой делегату, поддерживающему только 8-битные квантованные операции, он отклонит все операции, и модель будет полностью выполняться на центральном процессоре. Чтобы избежать подобных сюрпризов, в таблице ниже представлен обзор поддержки делегатов в зависимости от типа модели:

Тип модели	графический процессор	CoreML
С плавающей точкой (32 бита)	Да	Да
Квантование float16 после обучения	Да	Да
Квантование динамического диапазона после обучения	Да	Нет
Целочисленное квантование после обучения	Да	Нет
Обучение с учетом квантизации	Да	Нет

Проверка производительности

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

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

Инструменты для оценки

Задержка и объем памяти

Инструмент бенчмарка LiteRT можно использовать с подходящими параметрами для оценки производительности модели, включая среднюю задержку вывода, накладные расходы на инициализацию, объём памяти и т. д. Этот инструмент поддерживает несколько флагов для определения оптимальной конфигурации делегата для вашей модели. Например, --gpu_backend=gl можно указать вместе с --use_gpu для измерения производительности GPU с OpenGL. Полный список поддерживаемых параметров делегата определён в подробной документации .

Вот пример запуска квантованной модели с помощью GPU через adb :

adb shell /data/local/tmp/benchmark_model \
  --graph=/data/local/tmp/mobilenet_v1_224_quant.tflite \
  --use_gpu=true

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

Точность и правильность

Делегаты обычно выполняют вычисления с точностью, отличной от точности их аналогов на центральном процессоре. В результате использование делегата для аппаратного ускорения приводит к (обычно незначительному) компромиссу в точности. Обратите внимание, что это не всегда так; например, поскольку графический процессор использует точность с плавающей запятой для запуска квантованных моделей, может наблюдаться небольшое повышение точности (например, улучшение <1% для Top-5 в классификации изображений ILSVRC).

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

Оценка на основе задач

LiteRT располагает инструментами для оценки корректности двух задач на основе изображений:

ILSVRC 2012 (классификация изображений) с точностью top-K
Обнаружение объектов COCO (с ограничивающими рамками) со средней точностью (mAP)

Готовые двоичные файлы этих инструментов (Android, 64-битная архитектура ARM) вместе с документацией можно найти здесь:

Классификация изображений ImageNet ( подробнее ) * Обнаружение объектов COCO ( подробнее )

В примере ниже показана оценка классификации изображений с помощью графического процессора на Pixel 4:

adb shell /data/local/tmp/run_eval \
  --model_file=/data/local/tmp/mobilenet_quant_v1_224.tflite \
  --ground_truth_images_path=/data/local/tmp/ilsvrc_images \
  --ground_truth_labels=/data/local/tmp/ilsvrc_validation_labels.txt \
  --model_output_labels=/data/local/tmp/model_output_labels.txt \
  --output_file_path=/data/local/tmp/accuracy_output.txt \
  --num_images=0 # Run on all images. \
  --use_gpu=true

Ожидаемый результат — список показателей Top-K от 1 до 10:

Top-1 Accuracy: 0.733333
Top-2 Accuracy: 0.826667
Top-3 Accuracy: 0.856667
Top-4 Accuracy: 0.87
Top-5 Accuracy: 0.89
Top-6 Accuracy: 0.903333
Top-7 Accuracy: 0.906667
Top-8 Accuracy: 0.913333
Top-9 Accuracy: 0.92
Top-10 Accuracy: 0.923333

Оценка, не зависящая от задачи

Для задач, для которых нет установленного инструмента оценки на устройстве, или если вы экспериментируете с пользовательскими моделями, в LiteRT есть инструмент Inference Diff . (Android, 64-битная двоичная архитектура ARM здесь ).

Inference Diff сравнивает выполнение LiteRT (с точки зрения задержки и отклонения выходного значения) в двух условиях:

Однопоточный вывод ЦП
Пользовательский вывод — определяется этими параметрами

Для этого инструмент генерирует случайные гауссовские данные и пропускает их через два интерпретатора TFLite: один из них работает на однопоточных ядрах ЦП, а другой параметризуется аргументами пользователя.

Он измеряет задержку обоих, а также абсолютную разницу между выходными тензорами каждого интерпретатора для каждого элемента.

Для модели с одним выходным тензором выходные данные могут выглядеть следующим образом:

Num evaluation runs: 50
Reference run latency: avg=84364.2(us), std_dev=12525(us)
Test run latency: avg=7281.64(us), std_dev=2089(us)
OutputDiff[0]: avg_error=1.96277e-05, std_dev=6.95767e-06

Это означает, что для выходного тензора с индексом 0 элементы из выхода ЦП отличаются от выхода делегата в среднем на 1.96e-05 .

Обратите внимание, что интерпретация этих чисел требует более глубокого понимания модели и того, что означает каждый выходной тензор. Если это простая регрессия, определяющая какую-либо оценку или встраивание, разница должна быть незначительной (в противном случае это ошибка делегата). Однако выходные данные, такие как «класс обнаружения» из моделей SSD, интерпретировать немного сложнее. Например, этот инструмент может показать разницу, но это может не означать серьёзной проблемы с делегатом: рассмотрим два (фиктивных) класса: «ТВ (ID: 10)», «Монитор (ID: 20)». Если делегат немного не соответствует истине и отображает «монитор» вместо «ТВ», разница выходных данных для этого тензора может быть примерно 20-10 = 10.