Делегаты обеспечивают аппаратное ускорение моделей LiteRT, используя встроенные в устройство ускорители, такие как графический процессор и процессор цифровых сигналов (DSP) .
По умолчанию LiteRT использует ядра ЦП, оптимизированные для набора инструкций ARM Neon . Однако ЦП — это многоцелевой процессор, который не обязательно оптимизирован для сложных арифметических операций, обычно встречающихся в моделях машинного обучения (например, матричных вычислений, связанных с сверткой и плотными слоями).
С другой стороны, большинство современных мобильных телефонов содержат чипы, которые лучше справляются с этими тяжелыми операциями. Их использование для операций нейронной сети дает огромные преимущества с точки зрения задержки и энергоэффективности. Например, графические процессоры могут обеспечить увеличение задержки до 5 раз .
Каждый из этих ускорителей имеет связанные API-интерфейсы, которые позволяют выполнять пользовательские вычисления, например OpenCL или OpenGL ES для мобильных графических процессоров. Обычно вам придется написать много специального кода для запуска нейронной сети через эти интерфейсы. Ситуация становится еще сложнее, если учесть, что каждый ускоритель имеет свои плюсы и минусы и не может выполнить каждую операцию в нейронной сети. API-интерфейс делегата TensorFlow Lite решает эту проблему, выступая в качестве моста между средой выполнения TFLite и этими API-интерфейсами более низкого уровня.
Выбор делегата
LiteRT поддерживает несколько делегатов, каждый из которых оптимизирован для определенных платформ и определенных типов моделей. Обычно к вашему сценарию использования применимо несколько делегатов, в зависимости от двух основных критериев: целевой платформы (Android или iOS?), и типа модели (с плавающей запятой или квантовой?), которую вы пытаетесь ускорить. .
Делегаты по платформам
Кроссплатформенность (Android и iOS)
- Делегат графического процессора . Делегат графического процессора можно использовать как на Android, так и на iOS. Он оптимизирован для запуска 32-битных и 16-битных моделей с плавающей запятой при наличии графического процессора. Он также поддерживает 8-битные квантованные модели и обеспечивает производительность графического процессора на уровне их версий с плавающей запятой. Дополнительные сведения о делегате графического процессора см. в разделе LiteRT на графическом процессоре .
iOS
- Делегат Core ML для новых iPhone и iPad . Для новых iPhone и iPad, где доступен Neural Engine, вы можете использовать делегат Core ML для ускорения вывода для 32-битных или 16-битных моделей с плавающей запятой. Neural Engine доступен на мобильных устройствах Apple с процессором A12 или выше. Обзор делегата Core ML и пошаговые инструкции см. в разделе Делегат LiteRT Core ML .
Делегаты по типу модели
Каждый ускоритель спроектирован с учетом определенной разрядности данных. Если вы предоставите делегату модель с плавающей запятой, который поддерживает только 8-битные квантованные операции, он отклонит все свои операции, и модель будет полностью выполняться на ЦП. Чтобы избежать таких сюрпризов, в таблице ниже представлен обзор поддержки делегатов в зависимости от типа модели:
| Тип модели | графический процессор | CoreML |
|---|---|---|
| С плавающей запятой (32 бита) | Да | Да |
| Квантование float16 после обучения | Да | Да |
| Квантование динамического диапазона после обучения | Да | Нет |
| Целочисленное квантование после обучения | Да | Нет |
| Обучение с учетом квантования | Да | Нет |
Проверка производительности
Информация в этом разделе служит приблизительным руководством для составления короткого списка делегатов, которые могут улучшить вашу заявку. Однако важно отметить, что каждый делегат имеет заранее определенный набор операций, которые он поддерживает, и может выполняться по-разному в зависимости от модели и устройства. Поэтому обычно рекомендуется провести сравнительное тестирование, чтобы оценить, насколько полезен делегат для ваших нужд. Это также помогает оправдать увеличение размера двоичного файла, связанное с подключением делегата к среде выполнения LiteRT.
LiteRT имеет обширные инструменты для оценки производительности и точности, которые могут дать разработчикам уверенность в использовании делегатов в своих приложениях. Эти инструменты обсуждаются в следующем разделе.
Инструменты для оценки
Задержка и объем памяти
Инструмент тестирования LiteRT можно использовать с подходящими параметрами для оценки производительности модели, включая среднюю задержку вывода, затраты на инициализацию, объем памяти и т. д. Этот инструмент поддерживает несколько флагов, чтобы определить лучшую конфигурацию делегата для вашей модели. Например, --gpu_backend=gl можно указать с помощью --use_gpu для измерения производительности графического процессора с помощью OpenGL. Полный список поддерживаемых параметров делегата определен в подробной документации .
Вот пример запуска квантовой модели с графическим процессором через adb :
adb shell /data/local/tmp/benchmark_model \
--graph=/data/local/tmp/mobilenet_v1_224_quant.tflite \
--use_gpu=true
Вы можете скачать готовую версию этого инструмента для Android с 64-битной архитектурой ARM здесь ( подробнее ).
Точность и правильность
Делегаты обычно выполняют вычисления с точностью, отличной от точности их процессоров. В результате существует (обычно незначительный) компромисс в точности, связанный с использованием делегата для аппаратного ускорения. Обратите внимание, что это не всегда так; например, поскольку графический процессор использует точность с плавающей запятой для запуска квантованных моделей, может быть небольшое улучшение точности (например, улучшение топ-5 <1% в классификации изображений ILSVRC).
LiteRT имеет два типа инструментов для измерения того, насколько точно делегат ведет себя для данной модели: на основе задач и на основе задач . Все инструменты, описанные в этом разделе, поддерживают расширенные параметры делегирования , используемые инструментом сравнительного анализа из предыдущего раздела. Обратите внимание, что в подразделах ниже основное внимание уделяется оценке делегата (работает ли делегат так же, как процессор?), а не оценке модели (подходит ли сама модель для этой задачи?).
Оценка на основе задач
В LiteRT есть инструменты для оценки правильности решения двух задач, связанных с изображениями:
ILSVRC 2012 (Классификация изображений) с точностью высшего класса
Обнаружение объектов COCO (с ограничивающими рамками) со средней средней точностью (mAP)
Готовые двоичные файлы этих инструментов (Android, 64-битная архитектура ARM), а также документацию можно найти здесь:
В приведенном ниже примере демонстрируется оценка классификации изображений с помощью графического процессора на 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 .
Обратите внимание, что интерпретация этих чисел требует более глубокого знания модели и того, что означает каждый выходной тензор. Если это простая регрессия, определяющая какую-то оценку или встраивание, разница должна быть небольшой (в противном случае это ошибка делегата). Однако такие выходные данные, как «класс обнаружения» моделей твердотельных накопителей, интерпретировать немного сложнее. Например, при использовании этого инструмента может быть видна разница, но это не может означать, что с делегатом что-то действительно не так: рассмотрим два (поддельных) класса: «TV (ID: 10)», «Monitor (ID:20)» — If делегат немного отклоняется от истины и показывает монитор вместо телевизора, разница на выходе для этого тензора может достигать 20-10 = 10.