1. Введение
Являясь национальной платформой туристических услуг с DAU более 100 миллионов человек, AutoNavi ежедневно предоставляет пользователям большое количество услуг поиска, позиционирования и навигации.Для реализации этих услуг требуется точная дорожная информация, такая как электронное положение глаз, информация о состоянии дорог. и информация о местоположении дорожных знаков. Будет ли читателям интересно, как AutoNavi воспринимает дорожную информацию в реальном мире и предоставляет эти данные пользователям?
На самом деле, у нас есть много способов собирать и перерабатывать элементы реальных дорог и обновлять их в приложении AutoNavi Map. Одним из наиболее важных методов является использование компьютерного зрения для развертывания визуальных алгоритмов на клиенте и быстрого восстановления информации о дороге путем обнаружения и идентификации изображений.
Чтобы добиться низкой стоимости и высокой скорости восстановления дорожных элементов в режиме реального времени, мы используемдвигатель МНН(Легкий энтроль глубины нейронного рассуждения), развертывая моллюскому модели нейронной сети к клиенту, и модель рассуждается на стороне клиента, тем самым завершаяКлиенты с низкой вычислительной мощностью и небольшим объемом памятиЗадача на сбор дорожных объектов.
Традиционная CNN (сверточная нейронная сеть) требует очень больших вычислительных ресурсов, и в бизнес-сценариях необходимо развертывать несколько моделей.Как развернуть несколько моделей на устройствах с низкой производительностью и обеспечить, чтобы приложение было «маленьким и хорошим», не влияя на производительность в реальном времени, — очень сложная задача.. В этой статье мы поделимся практическим опытом развертывания приложений глубокого обучения на малопроизводительных устройствах с использованием движка MNN.
2. Развертывание
2.1 Предыстория введения
Как показано на рис. 2.1.1, бизнес-фон заключается в развертывании модели CNN, связанной с распознаванием дорожных элементов, для клиента, выполнении вывода модели на стороне клиента и извлечении информации, такой как местоположение и вектор дорожных элементов.
Из-за потребностей этого бизнес-сценария необходимо одновременно развернуть более 10 или более моделей на конце, чтобы удовлетворить потребности в извлечении информации о большем количестве различных элементов дороги, что является серьезной проблемой для устройств с низкой производительностью. .
Рисунок 2.1.1 Сбор данных AutoNavi
Чтобы получить «небольшое, но отличное» приложение, механизм MNN столкнулся со многими проблемами и трудностями в процессе развертывания модели. Некоторый опыт и решения этих проблем и задач представлены ниже.
2.2 Развертывание MNN
2.2.1 Использование памяти
Рабочая память приложения всегда является темой, которую разработчики не могут обойти стороной, а память, создаваемая выводом модели, занимает большую часть рабочей памяти приложения. Поэтому, чтобы сделать память вывода модели как можно меньше, в процессе развертывания модели разработчик должен знать об основных источниках памяти, генерируемых работающей моделью. Согласно нашему опыту развертывания, в процессе развертывания одной модели память в основном поступает из следующих четырех аспектов:
Рис. 2.2.1 Объем памяти для развертывания с одной моделью
ModelBuffer: буфер для десериализации модели, который в основном хранит параметры и информацию о модели в файле модели, а его размер близок к размеру файла модели.
**FeatureMaps: **память Featuremaps, в которой в основном хранятся входные и выходные данные каждого слоя в процессе вывода модели.
**ModelParams: **Память параметров модели, в которой в основном хранится память весов, смещения, операций и т. д., необходимых для вывода модели. Где веса занимают большую часть памяти в этом разделе.
**Куча/стек: **память стека, созданная работающим приложением.
2.2.2 Оптимизация памяти
Зная об использовании памяти моделью, легко понять, какие изменения памяти происходят во время работы модели. После нескольких практик развертывания модели, чтобы уменьшить пиковый объем памяти развернутой модели, мы предприняли следующие меры:
- После десериализации модели (createFromFile) и создания памяти (createSession) буфер модели освобождается (releaseModel), чтобы избежать накопления памяти.
- Для обработки ввода модели память изображений и inputTensor могут повторно использоваться в памяти.
- Постобработка модели, вывод модели Тензор и мультиплексирование памяти выходных данных.
Рисунок 2.2.2.1 Схема повторного использования памяти при развертывании модели MNN
После повторного использования памяти, взяв в качестве примера развертывание визуальной модели 2,4M, изменения в памяти, занимаемой промежуточными этапами, от загрузки до освобождения во время выполнения модели, могут быть представлены следующими кривыми:
Рисунок 2.2.2.2 Кривая памяти приложения с одной моделью (статистика memoryinfo Android)
- Перед запуском модели память, занимаемая моделью,0M.
- После загрузки модели (createFromFile) и создания памяти (createSession) память поднялась5.24M, от десериализации модели и создания памяти Featuremaps.
- Вызовите releaseModel, чтобы уменьшить память до3.09M, причина в освобождении буфера после десериализации модели.
- InputTensor и память изображения мультиплексируются, а память приложения увеличивается до4.25M, потому что создается тензорная память, в которой хранятся входные данные модели.
- RunSession(), память приложения увеличивается до5.76M, причина в увеличении памяти стека в процессе RunSession.
- После освобождения модели приложение возвращается к значению памяти до загрузки модели.
После нескольких развертываний модели ниже приведена формула оценки пиковой памяти для развертывания одной модели до конца:
MemoryPeak: Пиковый объем памяти во время выполнения одной модели.
StaticMemory: Статическая память, включая память, занимаемую моделью Weights, Bias и Op.
DynamicMemory: Динамическая память, включая память, занимаемую Feature-картами.
ModelSize: Размер файла модели. Память, занятая десериализацией модели.
MemoryHS: Память стека во время выполнения (опытное значение между 0,5M-2M).
2.2.3 Принцип вывода модели
В этой главе изложены принципы построения моделей, чтобы разработчики могли быстро находить и решать проблемы, когда они сталкиваются со связанными проблемами.
Планирование моделей перед выводом модели: Рассуждения механизма MNN поддерживают высокую степень гибкости. То есть можно указать разные пути выполнения модели и разные серверные части для разных путей выполнения, чтобы улучшить параллелизм гетерогенных систем. Этот процесс в основном представляет собой процесс планирования или распределения задач.
Для сетей филиалов можно указать текущую работающую ветвь или запланировать выполнение ветвей для различных серверных частей, чтобы повысить производительность развертывания модели. На рис. 2.2.3.1 показана модель с несколькими ветвями, две ветви выводят результаты обнаружения и результаты сегментации соответственно.
Рисунок 2.2.3.1 Многофилиальная сеть
Во время развертывания можно выполнить следующие оптимизации:
- Указывает путь для запуска. Когда необходимо обнаружить только результаты, требуется только ветвь обнаружения, нет необходимости запускать две ветви и сокращать часы модели.
- Обнаружение и сегментация указаны с разными бэкендами. Например, определить указанный ЦП, сегментировать указанный OpenGL и улучшить параллелизм модели.
Предварительная обработка перед выводом модели: Этот этап будет предварительно обработан в соответствии с информацией о планировании модели на предыдущем шаге Суть в том, чтобы использовать информацию о модели и информацию о конфигурации пользовательского ввода для создания сеанса (содержащего данные вывода модели).
Рисунок 2.2.3.2 Создание сеанса по расписанию
На этом этапе планирование операций выполняется в соответствии с информацией о модели, десериализованной моделью, и информацией о конфигурации планирования пользователя. Используется для создания работающих конвейеров и соответствующих вычислительных серверных частей. Как показано на рисунке 2.2.3.3.
Рисунок 2.2.3.3 Создание сеанса
Вывод модели: Суть вывода модели — это процесс последовательного выполнения операторов в соответствии с сеансом, созданным на предыдущем шаге. Операция выполнит операцию каждого уровня модели в соответствии с путем к модели, заданным предварительной обработкой и указанным бэкендом. Стоит отметить, что если оператор не поддерживается указанным бэкэндом, он по умолчанию будет использовать альтернативный бэкэнд для выполнения вычислений.
Рисунок 2.2.3.4 Схема расчета логического вывода модели
2.2.4 Время развертывания модели
В этой части подсчитывается время, затрачиваемое на каждый этап процесса развертывания одной модели, чтобы разработчики могли понять, сколько времени занимает каждый этап, и лучше спроектировать структуру кода. (Разные устройства имеют разную производительность, данные о длительности приведены только для справки)
Рисунок 2.2.4.1 Схема расчета логического вывода модели
Десериализация модели и создание сеанса занимают относительно много времени. При выводе нескольких графов попробуйте выполнить их один раз.
2.2.5 Анализ ошибок модели
При развертывании модели разработчики неизбежно столкнутся с отклонениями в выходных результатах обучающей модели на стороне развертывания и на стороне X86 (Pytorch, Caffe, Tensorflow). Причины ошибок, идеи позиционирования и решения представлены ниже.
Принципиальная схема модели Inference представлена на рисунке 2.2.5.1:
Рисунок 2.2.5.1 Схема вывода модели
Определение ошибки модели: Самый интуитивно понятный способ проверить, есть ли ошибка модели, — исправить входные значения модели на стороне развертывания и модели на стороне X86, рассуждать отдельно и сравнить выходные значения модели на стороне развертывания. и модель на стороне X86, чтобы подтвердить наличие ошибки.
Расположение ошибок модели: Когда определено, что есть ошибка модели, сначала исключите ошибку вывода модели, вызванную ошибкой ввода модели. Поскольку точность представления с плавающей запятой X86 и некоторых устройств Arm несовместима, ошибки ввода будут накапливаться в некоторых моделях, что приведет к большим ошибкам вывода. Какой метод используется для исключения проблемы, вызванной ошибкой ввода? Мы предоставляем метод для установки входа модели на 0,46875 (причина в том, что это значение одинаково на устройствах X86 и некоторых устройствах Arm, а суть в том, что число с плавающей запятой, полученное сдвигом 1, одинаково на обоих концах). Затем наблюдайте, является ли вывод последовательным.
Идея позиционирования ошибки модели: В случае исключения ошибки ввода модели, вызывающей ошибку вывода модели (то есть, когда ввод модели непротиворечив, вывод модели противоречив), это, вероятно, будет ошибка, вызванная некоторыми операторами модели. Как найти ошибку, вызванную какой ОП модели? Причины ошибок в модели могут быть обнаружены с помощью следующих шагов:
1) Обратный вызов промежуточного результата расчета каждой ОП модели через runSessionWithCallBack. Цель состоит в том, чтобы найти операцию, из которой в модели есть ошибки.
2) После обнаружения этого слоя можно найти оператора, вызвавшего ошибку.
3) После обнаружения оператора соответствующий код выполнения оператора можно найти с помощью указанной серверной информации.
4) После обнаружения соответствующего кода выполнения выполните отладку и найдите строку кода, которая вызывает ошибку, чтобы найти основную причину ошибки модели.
3. Резюме
Движок MNN — очень хороший сквозной механизм рассуждений.Как разработчик, сквозное развертывание и оптимизация производительности модели должны не только фокусироваться на оптимизации бизнес-логики, но и уделять внимание процессу расчета движка. , разработка фреймворка и ускорение модели.В свою очередь, бизнес-код может быть лучше оптимизирован и может быть создано действительно «небольшое и превосходное» приложение.
4. Планирование будущего
С общим улучшением производительности устройств последующие службы будут выполняться на более производительных устройствах, и мы будем использовать более богатые вычислительные серверные части для ускорения моделей, такие как OpenCL, OpenGL и т. д., для ускорения вывода моделей.
В будущем устройство будет передавать клиенту больше моделей, чтобы реализовать восстановление большего количества типов информации об элементах дороги Мы также будем использовать механизм MNN для изучения более эффективной среды развертывания кода в режиме реального времени, чтобы лучше обслуживать коллекцию карт. бизнес.
МыГруппа исследования и разработки картографических данных AutoNavi, в команде большое количество HC, приглашаем присоединиться к небольшим партнерам, которые интересуются бэкэндом Java, архитектурой платформы, разработкой алгоритмов (C++) и фронтенд-разработкой, пожалуйста, отправьте свое резюме по адресуgdtech@alibaba-inc.com, Формат заголовка почты: название - направление технологии - от технологии газеты. Мы просим Sage и с нетерпением ждем вашего присоединения.