Введение. Приложения ИИ следующего поколения должны постоянно взаимодействовать с окружающей средой и учиться на основе этих взаимодействий. Это предъявляет новые требования к производительности и гибкости системы, которым не может удовлетворить большинство существующих вычислительных сред машинного обучения. С этой целью проектная группа Калифорнийского университета в Беркли разработала новую распределенную среду Ray и недавно опубликовала соответствующую статью об Arvix: «Ray: распределенная среда для новых приложений ИИ».
Первыми авторами статьи являются Филипп Мориц и Роберт Нишихара, аспиранты лаборатории AMP в Калифорнийском университете в Беркли, также перечислены имена Майкла И. Джордана и Иона Стойки.
Michael I. Jordan: Заслуженный профессор кафедры электротехники, компьютерных наук и статистики Калифорнийского университета в Беркли. Он является академиком Национальной академии наук, Национальной инженерной академии и Американской академии искусств и наук. Он единственный ученый, который добился этого достижения в области машинного обучения. В 2016 году Semantic Scholar назвал его «Самым влиятельным компьютерным ученым».
Ion Stoica: Профессор компьютерных наук Калифорнийского университета в Беркли, соучредитель AMPLab, основной автор гибкого P2P-протокола Chord, среды вычислений кластерной памяти Spark и платформы управления кластерными ресурсами Mesos.
Недостатки текущей вычислительной среды
Сегодня большинство приложений ИИ разрабатываются на основе более ограниченной парадигмы обучения с учителем, когда модели обучаются в автономном режиме, а затем развертываются на серверах для онлайн-прогнозирования. По мере развития отрасли приложения машинного обучения должны больше работать в динамичных средах, реагировать на изменения в среде и использовать последовательность действий для достижения поставленной цели. Эти требования естественным образом встроены в парадигму обучения с подкреплением (RL), то есть непрерывного обучения в неопределенной среде.
Приложения RL отличаются от традиционных приложений для контролируемого обучения тремя способами:
1) Приложения RL в значительной степени полагаются на моделирование для изучения состояния и результатов операций. Это требует большого количества вычислений, и в действительности приложение требует сотни миллионов симуляций.
2) Вычислительный граф приложений RL неоднороден и динамически изменяется. Моделирование может занять от нескольких миллисекунд до нескольких минут, а результаты моделирования определяют параметры будущих симуляций.
3) Многие приложения RL, такие как управление роботами или автономное вождение, требуют быстрых действий в ответ на изменение окружающей среды.
Поэтому нам нужна вычислительная среда, которая может поддерживать гетерогенные и динамические вычислительные графы при обработке миллионов задач в секунду с миллисекундной задержкой. Текущие вычислительные платформы либо не могут удовлетворить требования к задержке обычных приложений RL (MapReduce, Apache Spark, CIEL), либо используют статические графы вычислений (TensorFlow, Naiad, MPI, Canary).
Приложения RL предлагают системеТребования к гибкости, производительности и простоте разработки, система Ray разработана с учетом этих требований.
Пример
Псевдокод классического обучающего приложения RL
Пример кода Python, реализованный с помощью Ray
В Ray удаленные функции и актеры объявляются через @ray.remote. При вызове удаленной функции и методов актора немедленно возвращается будущее (идентификатор объекта).Используя ray.get(), объект, соответствующий идентификатору, может быть получен синхронно, который может быть передан последующим удаленным функциям и методам актора для кодировать зависимости задач. У каждого актора есть объект окружения self.env, который разделяет состояние между задачами.
На приведенном выше рисунке показана карта задач, соответствующая вызову train_policy.remote(). Удаленные функции и методы акторов вызывают задачи в соответствующем графе задач. В графе есть 2 актора, и ребра с состоянием между каждым актером означают, что они имеют общее изменяемое состояние. Существуют границы управления от train_policy до вызываемой задачи. Чтобы обучать политики параллельно, train_policy.remote() можно вызывать несколько раз.
принцип
Для поддержки гетерогенных и динамических требований к рабочей нагрузке, вызванных приложениями RL, Рэй использует вычислительную модель динамического графа задач, аналогичную CIEL. В дополнение к упрощению параллельных задач CIEL Ray обеспечивает упрощение кода поверх модели выполнения, обеспечивая поддержку структур состояния, таких как стороннее моделирование.
Структура лучевой системы
Чтобы соответствовать строгим требованиям к производительности при поддержке динамических вычислительных графов, Ray использует новую горизонтально масштабируемую распределенную архитектуру. Структура Ray состоит из двух частей: прикладного уровня и системного уровня. Уровень приложений реализует API и вычислительные модели для выполнения распределенных вычислительных задач. Системный уровень отвечает за планирование задач и управление данными для удовлетворения требований производительности и отказоустойчивости.
Структура лучевой системы
Структура основана на двух ключевых идеях:
1) Глобальное хранилище состояний GSC (Global Control Store). Все состояние управления системой хранится в GSC, так что другие компоненты системы могут не иметь состояния. Это не только упрощает поддержку отказоустойчивости (при возникновении ошибки компонент может прочитать самое последнее состояние из GSC и перезапустить), но также позволяет горизонтально масштабировать другие компоненты (репликации или сегменты этого компонента могут совместно использоваться через GSC). состояние ГСК).
2) Распределенный планировщик снизу вверх. Задачи отправляются в локальный планировщик снизу вверх водителями и рабочими. Локальный планировщик может выбрать локальное планирование задач или передать задачу глобальному планировщику. Разрешая локальное принятие решений, сокращается задержка выполнения задачи, а за счет снижения нагрузки на глобальный планировщик увеличивается пропускная способность системы.
Восходящий распределенный планировщик
представление
1) Масштабируемость и производительность
Сквозная масштабируемость.Основным преимуществом GCS является повышение горизонтальной масштабируемости системы. Мы можем наблюдать почти линейный рост пропускной способности задач. На 60 узлах Ray может достичь пропускной способности более 1 миллиона задач в секунду и линейно превышает 1,8 миллиона задач в секунду на 100 узлах. Точка данных справа показывает, что Рэй может обработать 100 миллионов задач (54 секунды) менее чем за минуту.
Основной обязанностью глобального планировщика является поддержание баланса нагрузки в системе. Драйвер отправляет 100 000 задач на первый узел, который балансируется и распределяется между 21 доступным узлом глобальным планировщиком.
Производительность объектного хранилища.Для крупных объектов пропускная способность одного клиента превышает 15 ГБ/с (красный), а для небольших объектов IOPS объектного хранилища достигает 18 КБ (голубой), а каждая операция занимает около 56 микросекунд.
2) Отказоустойчивость
Восстановление после сбоя объекта.Когда рабочие узлы закрываются, активный локальный планировщик автоматически запускает восстановление потерянных объектов. Во время перестроения задачи, первоначально представленные драйвером, были приостановлены, поскольку их зависимости не могли быть удовлетворены. Но общая пропускная способность задач остается стабильной, полностью используя доступные ресурсы, до тех пор, пока отсутствующие зависимости не будут перестроены.
Полностью прозрачная отказоустойчивость для распределенных задач. Пунктирная линия представляет количество узлов в кластере. Кривая показывает пропускную способность новых задач (голубой) и повторно выполненных задач (красный).На 210 с в систему добавляется все больше и больше узлов, и Рэй может полностью восстановить исходную пропускную способность задачи.
Восстановление после отказа актера.Кодируя вызовы методов каждого актора в граф зависимостей, мы можем повторно использовать один и тот же механизм рефакторинга объектов.
В момент времени t=200 с мы остановили 2 из 10 узлов, в результате чего 400 из 2000 участников кластера необходимо было восстановить на оставшихся узлах. (a) показывает крайний случай, когда состояние промежуточного узла не сохраняется. Методы, вызывающие потерянных акторов, должны выполняться повторно последовательно (t = 210–330 с). Потерянные роли автоматически распределяются по доступным узлам, а пропускная способность полностью восстанавливается после перестроения. (б) показывает, что при одинаковой рабочей нагрузке каждый актор автоматически выполняет сохранение контрольной точки каждые 10 вызовов метода. После отказа узла большая часть реконструкции заключается в восстановлении состояния актера путем выполнения задач контрольной точки (t = 210-270 с).
Потребление репликации GCS.Чтобы сделать GCS отказоустойчивым, мы реплицируем каждый сегмент базы данных. Когда клиент записывает в сегмент GCS, он реплицирует запись на все реплики. Уменьшая количество шардов в GCS, мы искусственно делаем GCS узким местом рабочей нагрузки, а накладные расходы на двунаправленную репликацию составляют менее 10%.
3) RL-приложения
Мы реализовали два алгоритма RL с Ray, и по сравнению с системами, разработанными для этих двух алгоритмов, Ray мог догнать или даже превзойти некоторые системы. Кроме того, использование Ray для распределения этих алгоритмов по кластеру требует лишь нескольких модификаций кода в реализации алгоритма.
Алгоритм ES (Эволюционные стратегии)
Сравнение времени, необходимого Рэю и эталонной системе для достижения 6000 баллов в задании Humanoid v1 за счет реализации алгоритма ES.
Алгоритм ES, реализованный в Ray, хорошо масштабируется до 8192 ядер, в то время как специально созданная система не работает после 1024 ядер. На 8192 ядрах мы достигли среднего значения 3,7 минуты, что в два раза быстрее текущего лучшего результата.
Алгоритм PPO (оптимизация проксимальной политики)
Чтобы оценить производительность Ray на одном узле и небольших рабочих нагрузках RL, мы реализовали алгоритм PPO на Ray для сравнения с алгоритмом, реализованным OpenMPI.
Сравнение времени, необходимого MPI и Ray для достижения алгоритма PPO в задаче Humanoid v1 для достижения 6000 баллов.
Алгоритм PPO, реализованный с помощью Ray, выходит за рамки специальной реализации MPI и использует меньше GPU.
Управляйте роботом-симулятором
Эксперименты показывают, что Рэй может удовлетворить требования мягкого реального времени для управления смоделированными роботами в реальном времени. Драйвер Рэя может запускать смоделированного робота и выполнять действия с фиксированными интервалами времени от 1 мс до 30 мс, чтобы имитировать различные требования в реальном времени.
будущая работа
Учитывая повсеместное распространение рабочих нагрузок, оптимизация ad hoc затруднена. Например, решения о планировании должны приниматься без полного знания вычислительного графа. Решения Рэя о расписании могут потребовать более сложных настроек. В дополнение к этому, линия хранения для каждой задачи должна применять стратегию сборки мусора, чтобы ограничить затраты на хранение в GCS, функция, которая в настоящее время находится в стадии разработки.
Когда потребление GCS становится узким местом, глобальный планировщик можно масштабировать, добавляя дополнительные сегменты. В настоящее время также необходимо вручную задавать количество шардов GCS и глобального планировщика, а в будущем будет разработан адаптивный алгоритм для автоматической корректировки их количества. Учитывая преимущества, которые структура GCS дает этой системе, авторы считают, что состояние централизованного управления является ключевым элементом дизайна будущих распределенных систем.
Посмотреть исходный текст статьи:Ray: A Distributed Framework for Emerging AI Applications
Сайт проекта с открытым исходным кодом:Рэй.прочитайте документ S.IO/ru/latest/i…