Введение

Традиционный подход к машинному обучению заключался в том, чтобы работать с набором данных в автономном режиме, создавать модели с использованием контролируемых методов обучения, а затем использовать эти обученные модели для вывода в онлайн-среде. Хотя в прошлом это имело большой успех, появляется новый класс приложений. Эти приложения должны делать выводы в режиме реального времени, реагировать на сенсорные входы, выполнять непрерывные небольшие микросимуляции, а затем предпринимать действия. Это типичный поток в подходах, основанных на обучении с подкреплением. Как правило, обучение в реальной среде может быть очень ресурсоемким или может быть ограничено пропускной способностью. Следовательно, один из подходов заключался в обновлении смоделированных сред и выполнении множества таких симуляций с использованием таких методов, как поиск по дереву Монте-Карло. Это означает, что система должна иметь возможность выполнять моделирование быстрее, чем в реальном времени. Некоторых существующих фреймворков, таких как Spark или TensorFlow, недостаточно для такой рабочей нагрузки. В основном эти фреймворки поддерживают построение статических графов потоков данных, поскольку они, как правило, плохо подходят для расширения этих графов потоков данных в реальном времени. Кроме того, ориентированные на данные среды, такие как MapReduce, ориентированы на массовые параллельные операции, а не на массовое распараллеливание для коротких задач, которое необходимо для этого нового класса приложений. В этой статье из RISELab Калифорнийского университета в Беркли исследуются принципы проектирования фреймворка, который может понадобиться для поддержки таких потребностей в реальном времени. Прототип, реализованный для агента на основе обучения с подкреплением, который играет в Atari, с использованием принципов, изложенных ниже, работает в 63 раза быстрее, чем spark.

Требования к новому фреймворку

Требования к новой среде, которая может планировать такие приложения нового поколения и их задачи, можно разделить на три категории: производительность, модель выполнения, практичность.

Производительность

  1. Низкая задержка: поскольку эти приложения ML должны реагировать в режиме реального времени, необходим быстрый сквозной ответ, порядка миллисекунд. (Р1)
  2. Высокая пропускная способность: поскольку моделирование методом Монте-Карло, используемое в RL, может создавать до миллионов небольших задач, структура планировщика должна обеспечивать высокую пропускную способность. (Р2)

Требования к модели исполнения

3. Динамическое создание задач: новые задачи будут создаваться динамически (например, с помощью поиска по дереву Монте-Карло) на основе потока выполнения других задач, а также продолжительности задач. (Р3)

4. Неоднородные задачи. Задачи будут различаться по размерам необходимых ресурсов и продолжительности выполнения. (Р4)

5. Произвольные зависимости потока данных: новые небольшие задачи будут зависеть от выполнения других задач и создавать график задач, которые зависят друг от друга и слишком динамично. (Р5)

Практические требования к использованию

6. Отказоустойчивость. Это особенно сложно в средах с высокой пропускной способностью и малой задержкой. Но это необходимо в любой распределенной среде (R6)

7. Отладка и профилирование. Приложения машинного обучения и те, которые полагаются на одно обучение с подкреплением, требуют больших вычислительных ресурсов. Поэтому важно быстро профилировать проблемы с производительностью. Точно так же возможности отладки в распределенных и стохастических средах полезны для более быстрого устранения неполадок. (Р7)

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

Пример из реального мира

Давайте рассмотрим пример из реальной жизни, который сделает требования с R1 по R5 более конкретными. Посмотрите репрезентативную систему, которую может использовать робот, передвигающийся с использованием видео и ввода LIDAR.

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

Как видим, R1 необходим для оперативных нужд системы. R2 необходим для поддержки поиска по дереву MC. R3 необходим, так как вы берете разные ветки дерева и порождаете задачи, соответствующие им. R4 очевиден из-за необходимости поддержки задач вывода RNN — различных функций на разных уровнях, обработки сенсорных входных данных, различных физических симуляций. Как видно из диаграммы, R5 необходим из-за сложной зависимости потока данных, присутствующей в системе.

Архитектура

Основываясь на приведенных выше требованиях R1-R7 и примере из реальной жизни, давайте сначала посмотрим, какие примитивы необходимо построить, чтобы сформировать основу архитектуры машинного обучения в реальном времени.

Системные примитивы

  1. Создание задачи должно быть неблокирующим, а «будущее» может быть возвращено после создания задачи. Задачи будут выполняться асинхронно, а фьючерсы могут быть получены по мере необходимости.
  2. Любой вызов функции можно рассматривать как удаленное выполнение для поддержки различных типов задач и их выполнения на различных типах оборудования. Вызов функции может принимать простые значения данных или фьючерсы в качестве аргументов. Когда в качестве аргумента используется будущее, это означает, что существует зависимость потока данных (DAG) между задачей, которая предоставляет будущее, и задачей, которой нужно будущее в качестве входных данных.
  3. Любая задача может создавать новые задачи, которые, возможно, потребуется выполнять удаленно. Это также помогает устранить зависимость от пропускной способности конкретного работника/задачи, в которой выполняется исходная задача.
  4. Метод «get» в будущем вернет значение задачи, когда она будет готова, и это блокирующий вызов.
  5. Метод «ожидание» может использовать несколько фьючерсов в качестве входных данных и значение тайм-аута. Он возвращает фьючерсы, которые завершились по тайм-ауту или если уже выполнен определенный порог задач. Такие примитивы ожидания могут помочь с требованиями к задержке, поскольку они дают возможность игнорировать определенные задачи, которые могут занять много времени, и могут обеспечить лишь незначительные улучшения, которые могут быть распространены в алгоритмах ML.

Архитектура

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

Централизованный планировщик

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

Гибридное планирование

Учитывая R1 и R2, имеет смысл иметь возможность принимать решения о локальном планировании, чтобы использовать локальность данных. Рабочий на данном узле может отправлять задачи локальному планировщику. Локальный планировщик может решить запланировать задачу на данном узле или передать ее глобальному планировщику, если есть перелив. Глобальные планировщики смотрят на общее глобальное состояние, размещение данных и доступность ресурсов и принимают решения по планированию. Поскольку задачи могут создавать некоторые другие задачи, их можно запланировать локально для оптимального выполнения.

Вывод

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