Случаи использования прогнозирования машинного обучения в реальном времени включают модели рекомендаций в реальном времени, алгоритмы прогнозирования скачков цен, используемые в приложениях для бронирования билетов на концерты / совместных поездок и т. Д. Такие модели используют недавнюю активность сеанса, закодированную как функции, поэтому требуется вывод в реальном времени. Эта статья посвящена оптимизации таких служб логических выводов в реальном времени по времени отклика.
В большинстве случаев использования в режиме реального времени пользователь-человек ожидает, что результаты или эффекты вашего прогноза будут доступны в мобильном приложении или отображены на веб-странице. Поэтому время отклика имеет первостепенное значение при предоставлении прогнозов в реальном времени.
Проблема поддержания низкого времени отклика усугубляется настоятельной необходимостью добавления уровней функциональности, таких как наблюдаемость, A/B-тестирование, вывод модели глубокого обучения, потоковая передача многомерного набора функций и т. д.
Шаблон для вывода машинного обучения в реальном времени
Ниже приведена упрощенная иллюстрация конвейера логического вывода машинного обучения в режиме логического вывода в реальном времени. Помеченные поля обозначают модули внутри соответствующих микросервисов.
Конвейер вывода — это синхронное расположение вышеупомянутых модулей, распределенных по нескольким микросервисам. Поскольку каждый модуль стоит часть общего времени отклика, давайте внимательно рассмотрим, почему каждый модуль должен существовать в конвейере логического вывода.
Шлюз API. Шлюз API необходим для маршрутизации входящих запросов к одной или нескольким нижестоящим службам. Служба шлюза API абстрагирует «применение маршрута» от «реализации маршрута». «Применение маршрута» становится важным/нетривиальным, когда ваш конвейер вывода включает в себя такие функции, как A/B-тестирование нескольких моделей в производственной среде, внедрение канареечного тестирования, разделение трафика между моделями и т. д.
Обработка данных.Полезная нагрузка входящего запроса на вывод часто должна анализироваться и преобразовываться для создания функций времени запроса. Чтобы оптимизировать этот модуль, сопоставьте свой код с базовой аппаратной архитектурой среды развертывания, используя векторизованные преобразования и используя библиотеки, оптимизированные для графического процессора.
Вывод модели.моделям глубокого обучения могут потребоваться десятки миллисекунд, чтобы предоставить прогнозы многомерных функций, даже если они размещены на новейших графических процессорах. Необходимо минимизировать количество слоев в вашей нейронной сети и видеть если мы сможем поддерживать производительность модели. Существуют также такие методы, как квантование, которые настраивают допуски в точности функций и улучшают производительность логического вывода.
Структурированная потоковая передача. Создание всех функций во время обработки запроса может быть неосуществимым и/или ненужным. Сложность репликации логики преобразования, необходимость обширной агрегации и временная чувствительность функций могут сыграть свою роль в необходимости сохранения некоторых функций с использованием асинхронного конвейера с малой задержкой, передающего структурированные данные в высокодоступную систему хранения, такую как Редис
Функции запроса/поиска. Ожидается, что потоковые функции, которые были сохранены в кэше или другом доступном хранилище, будут запрашиваться менее чем за миллисекунду. На практике это может оказаться затруднительным, когда кеш заполняется одновременно с чтением. Следовательно, доступность может быть очень нестабильной и зависеть от эффективного обновления кэша. Возникает необходимость отслеживать сбои и задержки при поиске запросов, даже если они составляют несколько миллисекунд.
Наблюдение и сбор журналов. Накладные расходы на время отклика почти всегда неравномерно распределяются между различными сегментами конвейера логического вывода. Независимо от того, наследуете ли вы существующую модель для оптимизации или начинаете с нуля, рекомендуемый подход заключается в том, чтобы начать с получения модели, работающей в сквозной моделируемой рабочей среде, прежде чем приступать к оптимизации. После развертывания мы начинаем наблюдать за зарегистрированной производительностью в различных сегментах конвейера вывода. Этот подход позволяет нам сузить наше внимание к тем сегментам конвейера, где наиболее важно вкладывать средства в повышение производительности. Следовательно, необходимо следующее:
1) Процессы логического вывода и маршрутизации передают полуструктурированные данные журнала асинхронно в локальное хранилище. Помните, что нельзя принимать асинхронность как должное из-за преобладания Flask в обслуживающих архитектурах.
2) Независимое развертывание стандартизированных процессов сбора журналов в модулях, в которых размещены службы логического вывода и маршрутизации, без значительного снижения производительности обработки запросов.
Конвейер машинного обучения в реальном времени состоит из постоянно развивающихся междисциплинарных уровней сложности, что затрудняет точное проектирование времени отклика, ограниченного порядка нескольких десятков миллисекунд. Это требует комплексных усилий по проектированию, чтобы оптимизировать конвейер для скорости так же, как вы бы оптимизировали модель для точности. В последующих статьях я намерен более подробно остановиться на проектных соображениях для каждого из перечисленных выше модулей.
