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

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

В результате инженерам по машинному обучению (MLE) часто не хватает базовых знаний о возможности развертывания их собственных моделей. Сегодняшнее развертывание модели часто представляет собой собственный конвейер, состоящий из нескольких сценариев Bash/Python, охватывающих разные машины и среды. Он также включает в себя несколько библиотек с открытым исходным кодом или специализированные наборы инструментов для преобразования моделей, квантования, настройки производительности и проверки точности. Это не самый приятный опыт по сравнению с разработкой модели в облачной среде Python.

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

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

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

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

1. Недопустимая задержка/пропускная способность
2. Неподдерживаемые операторы
3. Несоответствие точности

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

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

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

Omnimizer — унифицированная платформа для оптимизации и развертывания моделей

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

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

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

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

Omnimizer Enterprise — Раскройте весь потенциал аппаратного обеспечения ИИ

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

NAS всегда считался дорогостоящим процессом, требующим глубоких знаний в области поиска и проектирования прокси-задач. С помощью Omnimizer каждый пользователь может применять NAS для настройки своих моделей под целевое оборудование. Этот процесс требует изменения всего нескольких строк кода, низких затрат на обучение и, что наиболее важно, не требует быть экспертом в области проектирования моделей и производительности оборудования.

Omnimizer может легко интегрироваться с репозиториями с открытым исходным кодом и ускорять готовые модели с небольшой ручной оптимизацией. На данный момент OmniML и его клиенты продемонстрировали ускорение в 1,2–6,8 раз на платформах NVIDIA и Qualcomm. Эти репозитории будут открыты для корпоративных пользователей в качестве примера:

• YOLO-X (обнаружение объектов)
• EfficientDet (обнаружение объектов)
• YOLO-P (многозадачная модель для автономного вождения)
• DDRNet (семантическая сегментация)
• ResNet (классификация изображений)
• DD3D (обнаружение 3D-объектов)
• ОПЦ (оптический поток)
• DistilBERT (машинный перевод)

Попробуйте Омнимайзер!

Только что вышла бета-версия Omnimizer. Зарегистрируйтесь сейчас на веб- сайте OmniML и начните оптимизировать свой рабочий процесс!

Di Wu, Song Han, Lucas Liebenwein, Riyad Islam, Keval Morabia, 
Asma K.T. Beevi, Henry Guo and Shengliang Xu also contributed to this article.