По мере роста спроса на приложения ИИ мы наблюдаем, как компании прилагают много усилий для создания своих инструментов машинного обучения (MLE), адаптированных к их потребностям. Отрасли сталкиваются с огромным количеством проблем, связанных с наличием хорошо спроектированной среды для их жизненного цикла машинного обучения (ML): создание, развертывание и управление моделями машинного обучения в производственной среде. Этот пост будет охватывать две статьи, объясняющие методы MLE двух ведущих технологических компаний: Google и Microsoft.

Добавляя немного контекста, эта статья является частью курса для выпускников Колумбийского университета: COMS6998 «Практическая производительность системы глубокого обучения», который ведет профессор Париджат Дубе, который также работает в IBM New York в качестве научного сотрудника.

В первом разделе будет представлена ​​статья от Google, в которой будет затронута строительная часть жизненного цикла машинного обучения. У Google есть внутренний инструмент под названием Google Vizier [1], цель которого - облегчить инженерам оптимизацию гиперпараметров для своих моделей машинного обучения.

Второй раздел будет охватывать документ от Microsoft и касается части развертывания жизненного цикла машинного обучения, а также того, как Microsoft управляет моделями машинного обучения в производственной среде. Все эти методы объединены в сервис под названием Microsoft DLIS (Deep Learning Inference Service) [2].

Технический вклад и его значение

Документ [1]: Google Vizier, сервис для оптимизации черного ящика

Вступление

  • Оптимизация черного ящика

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

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

  • Условия использования Google Vizier

При объяснении концепций этой статьи я буду использовать три термина:

  1. Пробная версия, список значений параметра, то есть x, который приводит к однократной оценке f (x)
  2. Исследование, одна оптимизация проводилась по пространству параметров, то есть по набору испытаний.
  3. Работник, процесс / экземпляр, который отвечает за оценку испытаний.

Системный Обзор

  • Базовый рабочий процесс пользователя

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

# Register this client with the Study, creating it if necessary
# Supply the study_config (name, owner, etc.) 
# and the worker handle, i.e. the process ID
client.LoadStudy(study_config, worker_handle)
# Study is not Done if there are pending Trials still
while (not client.StudyIsDone()):
    
    # Obtain a Trial to evaluate
    trial = client.GetSuggestion()    
    # Evaluate the objective function at the trial parameters
    metrics = RunTrial(trial)    
    # Report back the results and mark Trial as Complete
    client.CompleteTrial(trial, metrics)

Архитектура Google Vizier

Ниже представлена ​​архитектура Google Vizier:

Есть 6 основных компонентов:

  1. Evaluation Workers, компонент, предоставляемый клиентом / пользователем, который будет выполнять испытания.
  2. Vizier API, компонент, который связывает сотрудников по оценке с функциями Google Vizier.
  3. Постоянная база данных, внутренний компонент Google Vizier, который хранит текущее состояние всех исследований, то есть завершенных и ожидающих испытаний.
  4. Служба предложений, компонент, который возвращает новое испытание для выполнения специалистами по оценке.
  5. Служба ранней остановки, компонент, который помогает преждевременно завершить испытание, анализируя несколько условий.
  6. Dangling Work Finder, компонент, который перезапускает работу, потерянную из-за прерывания работы

Алгоритмы Google Vizier

Google Vizier предоставляет приведенный ниже алгоритм, который клиенты могут использовать для разработки экспериментов по настройке гиперпараметров.

  • Автоматическая ранняя остановка
  1. Правило остановки кривой производительности, это правило выполняет регрессию на кривых производительности (потери / точность), чтобы предсказать конечное целевое значение испытания с учетом набора предыдущих испытаний, чтобы мы могли основывать наш механизм ранней остановки на этом прогнозируемом значении.
  2. Правило остановки медианы, это правило останавливает ожидающее испытание, когда целевое значение испытания на шаге s строго хуже, чем медианное значение текущих средних значений на шаге s-1.
  • Трансферное обучение

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

Схема следующая:

  1. Создайте стек регрессоров гауссовского процесса, то есть стек исследований.
  2. Приоры размещаются внизу, а их остаток будет использован для исследований в верхней части стопки.
  3. Этот подход работает лучше всего, когда априорные значения имеют много хорошо разнесенных точек данных, но регрессор верхнего уровня имеет относительно мало обучающих данных. Это точно такой же сценарий, как и в целом для трансферного обучения, например используйте ImageNet внизу и небольшой набор данных изображений для конкретной предметной области вверху.
  • Алгоритм площадка

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

Ниже представлена ​​архитектура площадки для алгоритмов.

Есть 4 основных компонента:

  1. Vizier API, как и раньше
  2. Постоянная база данных, такая же, как и раньше
  3. Абстрактная политика, абстрактный класс, содержащий два абстрактных метода для реализации
  4. Настраиваемая политика, класс, который наследуется от абстрактной политики и реализует два абстрактных метода.
  5. Playground Binary, двоичный исполняемый файл, скомпилированный из настраиваемой политики, основанной на требованиях, сообщаемых Vizier API.
  6. Сотрудники Evaluation Workers, как и раньше, но обратите внимание, что эти сотрудники не знают о бинарном файле Playground, поскольку он связан с Vizier API, поэтому клиентам не нужно настраивать Evaluation Workers, когда они используют Algorithm Playground.

Клиентам необходимо реализовать два абстрактных метода из класса Abstract Policy таким образом, который соответствует их потребностям. Эти две функции:

# 1. Function to generate num_suggestions number of new TrialsGetNewSuggestions(trials, num_suggestions)
# 2. Function that returns a list of Pending Trials that should be stopped earlyGetEarlyStoppingTrials(trials)

Примеры использования Google Vizier

  1. HyperTune, продукт Google Cloud Machine, использующий Google Vizier и доступный для внешних пользователей.
  2. Автоматизированное A / B-тестирование. Например, чтобы оптимизировать удобство чтения для пользователей, настроив шрифт, цвет и интервал на определенной веб-странице, принадлежащей Google. Другой пример - когда Google нужно найти ответы на такие вопросы, как: «Каким образом результаты поиска, возвращаемые из Карт Google, должны соотноситься с релевантностью поиска в зависимости от расстояния от пользователя?»
  3. Для решения более сложных проблем оптимизации «черного ящика» есть две из них: «Невозможная пробная версия» и «Переопределение предлагаемой пробной версии». Несостоятельное испытание - это когда испытание не может быть оценено из-за гиперпараметрических причин, например скорость обучения слишком высока, поэтому модель не может сходиться. Google Vizier может пометить такое испытание как неосуществимое. Переопределение предлагаемой пробной версии - это случай, когда вам необходимо вручную заменить предлагаемую пробную версию из-за ограничений ресурсов / рабочих, например недостаточно памяти.

Документ [2]: Microsoft DLIS (служба вывода глубокого обучения)

Вступление

Целью Microsoft при создании DLIS является достижение сверхмалой задержки для развернутых моделей DNN. Как многие из вас, возможно, знают, Microsoft использует модели DNN для многих своих продуктов, например, для повышения релевантности поиска для своей поисковой системы Bing. Утверждается, что Microsoft DLIS обладает следующими возможностями:

  1. Обработка 3 миллионов вызовов логического вывода в секунду
  2. Обслуживание 10 тысяч экземпляров моделей
  3. Распространяется по своей природе и развернуто в 20 центрах обработки данных по всему миру.

Microsoft DLIS использует три основных принципа / практики для достижения вышеуказанного:

  1. Интеллектуальное размещение модели
  2. Выполнение модели с низкой задержкой
  3. Эффективная маршрутизация

Системный Обзор

Есть 7 основных компонентов:

  1. Экземпляр модели (MI), это развернутая модель
  2. Контейнер модели (MC), этот компонент является оболочкой для MI, чтобы сделать его гибким для развертывания в различных средах.
  3. Model Server (MS), здесь развернут MC
  4. Model Loader (ML), этот компонент отвечает за загрузку MC, а затем их развертывание в MS.
  5. Model Executer (ME), этот компонент функционирует для обработки процесса вывода
  6. Маршрутизатор, он направляет входящий запрос от клиента к ME.
  7. Model Master (MM), этот компонент содержит всю информацию о других компонентах, указанных выше.

Основные концепции / практики

Интеллектуальное размещение модели

Мотивация, стоящая за этой практикой, заключается в том, что, как многие из нас знают, производительность различных моделей DNN варьируется в зависимости от оборудования. Таким образом, нам необходимо разработать стратегию распределения подходящих ресурсов для различных типов моделей. Модели на основе CNN больше подходят для развертывания на графическом процессоре для оптимизации и распараллеливания операций свертки. С другой стороны, мы могли бы использовать более дешевые ресурсы, такие как FPGA / CPU, для последовательных моделей, таких как RNN, потому что использование GPU здесь не помогает.

В реализации интеллектуального размещения модели есть два основных модуля: размещение модели и управление разнообразным оборудованием.

Детали размещения модели приведены ниже.

  • MM имеет глобальное представление обо всех аппаратных средствах и ресурсах MS.
  • MM знает предполагаемое использование ресурсов через предварительный проверочный тест
  • Размещение модели является мультитенантным: MS может иметь MI одной или разных моделей (например, она может содержать два ResNet-18 или Resnet-18 и VGG-16)
  • Размещение модели является динамическим: MM считывает доступность ресурсов во время выполнения и при необходимости может перемещать экземпляры на другую MS.
  • Для MS, чтобы разместить MI, есть два требования: MS соответствует минимальным требованиям к оборудованию (известным через предварительный проверочный тест), и MS в настоящее время имеет доступные ресурсы, способные удерживать хотя бы один экземпляр MI (известный благодаря динамическому сканированию).

Подробная информация о разнообразном управлении оборудованием приведена ниже.

  • Этот модуль используется для работы со специализированным оборудованием, таким как GPU и FPGA.
  • Внутри этого модуля есть компонент под названием Machine Configuration Model (MCM), который функционирует для правильной настройки специализированного оборудования и управления им во время выполнения.
  • MCM устанавливает драйверы для GPU и FPGA в самом начале развертывания, то есть когда DLIS порождает новую MS и подключает GPU и FPGA к MS.
  • MCM настраивает MS с регулярными интервалами, то есть пингует каждые 10 минут, чтобы проверить работоспособность графического процессора в MS и при необходимости сбросить тактовую частоту.

Выполнение модели с низкой задержкой

Эта практика мотивирована тем фактом, что модели DNN обычно имеют высокую вычислительную стоимость. Таким образом, нам нужна оптимизация как на уровне системы, так и на уровне модели, чтобы добиться низкой задержки в нашем выводе. Microsoft DLIS в этом случае охватывает только оптимизацию на системном уровне. Microsoft DLIS применяет две важные практики: изоляцию ресурсов и локализацию данных. Детали как показано ниже.

  • Доступ к данным локализован, поэтому MS может использовать различные уровни кеширования.
  • MS изолирует MI в контейнерах с помощью MC, в этом случае Docker используется для сред на базе Linux, в то время как для сред на основе Windows Microsoft реализует настраиваемую оболочку
  • Ресурсы изолированы, чтобы гарантировать, что MI не мешает друг другу.
  • Чтобы изолировать ресурсы для MI, Microsoft DLIS применяет три вещи: соответствие процессору (позволяет критически важным данным модели оставаться в ближайших кэшах процессора), соответствие NUMA (гарантирует, что MI не должен пересекать банки памяти) и ограничения памяти (обеспечивает что MI никогда не требуется доступ к диску, чтобы уменьшить количество операций ввода-вывода).

Кроме того, поскольку мы используем контейнеры, то есть MC, используется связь между сервером и моделью. Таким образом, эффективная связь между MS и MI через MC является обязательной. Таким образом, Microsoft DLIS реализует следующие методы для сред на базе Linux и Windows для достижения этой цели.

  • MI на базе Linux заключен в настраиваемую инфраструктуру, созданную Microsoft, которая обеспечивает очень быструю связь по UDP.
  • MI на базе Windows заключен в настраиваемую инфраструктуру, созданную Microsoft, которая обеспечивает связь через очередь с общей памятью, которая выполняется в течение нескольких сотен миллисекунд для межпроцессного взаимодействия.

Эффективная маршрутизация

И последнее, но не менее важное: нам необходимо принять во внимание, как мы должны направлять клиентские запросы на ME (и, в конечном итоге, на MS). Это вызывает беспокойство из-за некоторых уникальных проблем, связанных с моделями трафика. Например, Microsoft часто сталкивается с частым всплеском трафика, который представляет собой всплеск запросов в течение нескольких миллисекунд, что приводит к длинной очереди запросов.

Чтобы справиться с этим, MS поддерживает практику под названием Backup Request. Это сделано для смягчения последствий, если первый / основной запрос может пропустить SLA (соглашение об уровне обслуживания, которое определяет стандартную / среднюю задержку, которую должна достичь MS). Задержка для запроса резервного копирования может быть статической или динамической.

Однако есть проблемы с запросом на резервное копирование. Рассмотрим следующий сценарий. Предположим, что наша задержка SLA составляет 15 мс, и на основе данных, которые мы собираем в ходе эксперимента за определенный период времени, мы знаем, что средняя задержка составляет 8 мс, а задержка 95-го процентиля - 10 мс. Допустим, мы используем статический запрос на резервное копирование, а затем рассмотрим два варианта ниже.

  • Если статические запросы резервного копирования настроены на 10 мс, запрос, скорее всего, будет истекать по таймауту, потому что мы отправляем запросы на резервное копирование через 10 мс после первого запроса, но у нас есть задержка SLA 15 мс.
  • Если мы выберем какое-то время раньше, скажем, 2 мс, тогда рабочая нагрузка фактически удвоится, и MS перегрузит

Чтобы смягчить указанную выше проблему, Microsoft DLIS вводит практику, называемую межуровневой отменой, которая сопровождает практику запросов на резервное копирование. Запрос на резервное копирование с межуровневой отменой имеет следующие механизмы.

  • Всегда отправляйте запрос на резервное копирование раньше, например Задержка 2 мс после первого запроса
  • Когда MS успешно удаляет первый запрос из очереди, она уведомляет все остальные MS через MM об отказе от предстоящего запроса с тем же идентификатором, который в основном является запросом на резервное копирование.

Наблюдения и выводы

Документ [1]: Google Vizier, сервис для оптимизации черного ящика

  1. Стратегия размещения модели важна для экономии ресурсов. Всегда используйте соответствующее оборудование для размещения модели и отслеживайте доступность ресурсов во время выполнения.
  2. Вывод с малой задержкой может быть достигнут как внутри (оптимизация модели), так и извне (оптимизация системы). Методы оптимизации системы в Microsoft DLIS включают использование кэша и изоляцию ресурсов, чтобы избежать помех между экземплярами модели.
  3. Задержка также может быть заражена одновременными запросами. Убедитесь, что у нас есть стратегия преодоления одновременных запросов, например использование запроса на резервное копирование с перекрестной отменой.

Документ [2]: Microsoft DLIS (служба вывода глубокого обучения)

  1. Настройка гиперпараметров, особенно в настройках черного ящика, - нетривиальное вычисление. Чаще всего нам нужно настроить сложную модель, например DNN, поэтому нам нужно эффективно искать пространство параметров.
  2. При создании фреймворка / сервиса автоматизации всегда полезно оставлять места для настройки, например Google Vizier со своей игровой площадкой для алгоритмов.
  3. Всегда останавливайте дорогостоящие вычисления, например, задействуя механизм ранней остановки или отмечая определенные испытания как невыполнимые, например Испытания, прогнозируемые объективные значения которых не совпадают. Это может помочь повысить производительность нашего механизма гиперпараметрической настройки с точки зрения скорости.

Заключение

При разработке механизма настройки гиперпараметров нам необходимо:

  1. Определите, какой алгоритм лучше всего подходит для данного исследования, у Визиря есть алгоритмы по умолчанию с учетом характеристики исследования.
  2. Найдите подходящее пространство параметров (т. Е. Исследование) и хорошую отправную точку (т. Е. Какие испытания следует оценивать в первую очередь)
  3. Оставьте место для пользователей, чтобы настроить указанную выше стратегию.
  4. Избегайте дорогостоящих вычислений, которые не имеют смысла

При обслуживании моделей нам необходимо:

  1. Определите схему эффективного использования ресурсов
  2. Оптимизируйте процесс вывода модели как по модели, так и по системе, чтобы добиться низкой задержки
  3. Составьте стратегию для эффективной обработки одновременных запросов

использованная литература

[1] Даниэль Головин, Бенджамин Сольник, Субходип Мойтра, Грег Кочански, Джон Карро и Д. Скалли. 2017. Google Vizier: сервис для оптимизации черного ящика. В материалах 23-й Международной конференции ACM SIGKDD по открытию знаний и интеллектуальному анализу данных (KDD ‘17). Ассоциация вычислительной техники, Нью-Йорк, Нью-Йорк, США, 1487–1495.

URL: https://research.google/pubs/pub46180/

[2] Джонатан Сойфер, Джейсон Ли, Минцинь Ли, Джеффри Чжу, Иннан Ли, Юйсюн Хе, Элтон Чжэн, Ади Олтян, Майя Мосяк, Крис Барнс, Томас Лю и Цзюньхуа Ван. 2019. Служба вывода глубокого обучения в Microsoft. В материалах конференции USENIX 2019 года по оперативному машинному обучению (OpML ’19). USENIX, Санта-Клара, Калифорния, США, 15–17 лет.

URL: https://www.microsoft.com/en-us/research/publication/deep-learning-inference-service-at-microsoft/