Как оптимизировать вывод и масштабирование глубокого обучения в облаке
Автор: Парта Дека и Рохит Миттал
Мы говорили о выводе на основе краев в предыдущем блоге https://towardsdatascience.com/ai-accelerator-products-e02cbb698d93
В этом блоге мы сосредоточимся на логическом выводе в облачной среде и уникальных проблемах, которые эта среда влечет за собой по сравнению с периферией. Цель этого блога - поделиться данными о периферии и облаке и методами повышения производительности облака для преодоления разрыва.
Рабочие нагрузки вывода глубокого обучения в облаке имеют две основные характеристики:
- вычислительно интенсивный. Например, типичные алгоритмы вывода изображений или видео на основе CNN требуют миллиардов операций в секунду.
- Интенсивный ввод / вывод. Эти службы полагаются на большие наборы данных, которые имеют множество функций и большое количество точек данных.
Основные показатели производительности для службы вывода глубокого обучения включают задержку ответа, пропускную способность и точность модели. Облачный вывод обычно имеет гораздо более высокую пропускную способность, чем режимы на основе границ, хотя задержка действительно страдает при переходе в облако.
Оптимизацию вывода на CPU можно разделить на три уровня:
- Системный уровень: оптимизацию на уровне компилятора можно выполнить с помощью Intel Distribution on OpenVino toolkit и библиотеки ядра Intel Math для глубоких нейронных сетей (Intel MLK DNN). Эти наборы инструментов для оптимизации системного уровня ускоряют вычисления как на аппаратном, так и на программном уровне. Методы включают ускорение компилятора на основе SIMD, математические библиотеки ядра на основе параллельных вычислений, ускорение глубокого обучения на основе SDK, предоставляемого различными поставщиками оборудования и т. Д.
- Уровень приложения: методы оптимизации, такие как многопроцессорность, параллелизм, асинхронизация и т. Д. Он улучшает выстраивание конвейера данных, параллелизм, различные этапы предварительной и постобработки и т. Д. Для конкретных приложений.
- Уровень алгоритма: оптимизация модели для улучшения отзыва по сравнению с точностью и т. Д. С помощью настройки гиперпараметров.
Пример использования:
Для одного из наших вариантов использования внутреннего дефекта оборудования мы выполнили три уровня оптимизации, как описано выше:
Уровень алгоритма: мы выполнили настройку гиперпараметров, чтобы оптимизировать нашу оценку точности в нашей архитектуре сверточной нейронной сети со случайным поиском гиперпараметров, таких как скорость обучения, снижение скорости обучения, импульс, количество эпох для обучения сети и т. Д. Оптимальная модель всегда точная настройка между FPR (частота ложных срабатываний) и FNR (частота ложных отрицательных результатов) или Точность по сравнению с отзывом. В нашем случае мы успешно автоматизировали обнаружение дефектов с помощью модели, оптимизированной для низкого FPR (высокая точность).
Уровень приложения: для размещения нашей службы вывода в облаке приложение необходимо будет переписать, чтобы оптимизировать его с помощью многопроцессорной обработки, параллелизма и асинхронизации. Это позволит легко масштабировать приложение до нескольких экземпляров виртуальных машин в облачной среде.
Системный уровень: мы использовали программное обеспечение Open Vino, чтобы оптимизировать нашу модель для оптимизации на уровне компилятора для ускорения на CPU, GPU, Intel Movidius, FPGA и т. Д. Оптимизатор модели в наборе инструментов OpenVino создает промежуточные представления, специфичные для компилятора, которые имеют меньше слоев, чем исходная модель. . Это сокращает время вывода.
IR - это пара файлов, которые описывают всю модель:
.xml: описывает топологию сети.
.bin: содержит двоичные данные о весах и смещениях.
Некоторые тесты ниже:
Для облачного вывода был запущен экземпляр Google could. Достигнута задержка от 0,6 до 0,7 секунды (от 600 до 700 миллисекунд), включая предварительную обработку одного образа с обученной моделью, развернутой как приложение RESTFUL в экземпляре общедоступного облака.
Результат и обсуждение:
Задержка облака в 0,6 с была примерно в 15 раз больше, чем у оптимизированных данных на границе 0,04 с. Для многих приложений задержка в 100 миллисекунд будет неприемлемой, что приведет к необходимости перехода к границе. Для остальных приложений облачный вывод может быть более экономичным вариантом.
Масштабирование в облаке:
После того, как модель вывода на основе DL была оптимизирована на всех уровнях, ее можно развернуть в экземпляре виртуальной машины в облаке как веб-приложение.
Простая виртуальная машина с типичной конфигурацией из 16 ГБ ОЗУ, процессора I5 и жесткого диска может обрабатывать небольшое количество запросов.
По мере того, как веб-сервис начинает набирать обороты и начинает получать тысячи запросов в секунду, виртуальная машина не сможет обрабатывать такое количество запросов одновременно, станет ужасно медленной и может также выйти из строя. Возможно, потребуется масштабирование виртуальной машины. Однако вертикальное масштабирование ограничено, и если завтра миллионы пользователей захотят получить доступ к приложению, возникнет та же проблема.
Что необходимо, так это горизонтальное масштабирование, которое создает несколько экземпляров виртуальных машин с собственным процессором, оперативной памятью, твердотельным накопителем и т. Д. Масштабирование потребует изменения архитектуры приложения и использования балансировщиков нагрузки.
Балансировщики нагрузки используют несколько алгоритмов для выполнения следующих задач:
· Каждая виртуальная машина получит возможность ответить на повторяющийся в циклической последовательности HTTP-запрос.
· Перенаправление входящего HTTP-запроса на следующую виртуальную машину, если текущая виртуальная машина не может справиться с большей нагрузкой.
· Перенаправление входящего запроса на виртуальную машину с самым быстрым временем отклика на данный момент
· Перенаправление текущего запроса на виртуальную машину, которая в данный момент обслуживает наименьшее количество активных сеансов.
Таким образом, оптимизируя нашу модель и делая приложение масштабируемым, можно поддерживать производительность в облачной среде.
Вывод:
Это наша часть из серии блогов (которые мы планируем опубликовать в будущем) по оптимизации и масштабированию глубокого обучения. Здесь мы говорили об оптимизации модели глубокого обучения на трех уровнях - алгоритме, приложении и системе, а также о том, как масштабировать службы вывода в облачной среде. В последующих блогах этой серии мы будем рассказывать об архитектурах следующего поколения (например, компонуемая инфраструктура для повышения пропускной способности при более низкой совокупной стоимости владения и т. Д.). Пожалуйста, не переключайтесь.
Источники:
