[Анализ исходного кода] Распределенное эластичное обучение PyTorch (1) --- общая идея

0x00 сводка

В предыдущих статьях мы изучили основные распространяемые модули PyTorch и представили несколько официальных примеров.Далее мы представим эластичное обучение PyTorch.Эта статья является первой, знакомящей с ее историей и концепцией дизайна, а также будет делать сравнение с Хороводом.

Примечание: статья Хоровод будет систематически перебираться в будущем, эта статья будет обновляться в это время, и будет добавлен дополнительный сравнительный анализ.

0x01 Болевая точка

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

Болевая точка 1: Отсутствие функции аварийного восстановления.
- вопрос: отказ одного узла приводит к прекращению всей работы по обучению. Несмотря на то, что фреймворк предоставляет функцию контрольной точки, частые вызовы вызовут проблемы с производительностью, поэтому результаты обучения все равно будут потеряны в течение определенного периода времени, а очередь задач будет продолжаться.
- идеальное состояние: Отказ одного узла не повлияет на общее обучение.При отказе узла он автоматически удаляется, и обучение продолжается плавно.
Болевая точка 2: отсутствие эластичного восприятия вычислительной мощности и механизма расширения и сжатия динамической тренировки.
- вопрос: пользователи могут только определять требуемые фиксированные статические ресурсы при отправке задач и не могут выполнять динамическое восприятие ресурсов кластера в реальном времени, что приводит к низкому использованию ресурсов кластера.
- идеальное состояние: Обучение следует начинать, когда есть несколько простаивающих машин.Когда ресурсов больше, эластичная задача и система планирования верхнего уровня могут взаимодействовать с i, так что эти потенциальные ресурсы могут быть эффективно обнаружены, а количество рабочих может автоматически увеличиваться в процессе обучения. Когда у задачи есть свободные вычислительные мощности, ресурсы будут освобождены автоматически. А при изменении количества рабочих задача обучения не будет прерываться, а переход будет плавным.
Проблема 3: механизм конфигурации/планирования ресурсов кластера негибок
- вопрос: В настоящее время не поддерживается динамическая настройка воркеров и не поддерживается вытеснение экземпляров с высоким приоритетом. Поэтому, когда ресурсов недостаточно, ресурсы не могут быть освобождены для других высокоприоритетных служб по мере необходимости, и задача может только ждать, пока задача завершится сама или завершится с ошибкой.
- идеальное состояние: Учебные задачи можно вытеснять, ресурсы можно активно высвобождать, а также перебрасывать их между машинами разного назначения/конфигурации.

0x02 Сложность

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

Сложность 1: нужен механизм, позволяющий узлам/процессам обнаруживать друг друга.

Как другие узлы/процессы обучения воспринимают автоматический вход или выход узла/процесса обучения.

Трудность 2: Как обрабатывать изменения участников

Что делать, когда обнаружено, что член изменился.

Трудность 3: Как зафиксировать неудачу обучения одного процесса.

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

Сложность 4: Как интегрироваться с существующим обучающим кодом.

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

0x03 TorchElastic

Давайте посмотрим на общее состояние механизма устойчивости PyTorch. Эластичный механизм PyTorch объединен с TorchElastic.GitHub.com/py факел/голодный…Факел Эластичный внешний вид.

TorchElastic (TE) был официально представлен в PyTorch 1.9, и мы смотрим на историю обучения эластичности с двух сторон.

3.1 История

3.1.1 PyTorch 1.7

В примечании к выпуску упоминается, что TE был добавлен в PyTorch Docker:

[Stable] TorchElastic now bundled into PyTorch docker image

Torchelastic предоставляет расширенный набор интерфейсов командной строки «torch.distributed.launch» с повышенной отказоустойчивостью и отказоустойчивостью. Если пользователя не интересует отказоустойчивость, он может получить точную функциональность/поведение, установив «max_restarts=0» и добавив удобство автоматического назначения портов «RANK» и «MASTER_ADDR» (вместо «torch.distributed.launch " указывается вручную).

3.1.2 PyTorch 1.9

Как видно из репозитория TE, теперь TE объединен с основной версией PyTorch 1.9.

IMPORTANT: This repository is deprecated.

TorchElastic has been upstreamed to PyTorch 1.9 under torch.distributed.elastic. Please refer to the PyTorch documentation here.

3.2 Концепция дизайна

ПЭТ прошел через две версии, отGitHub.com/py факел/голодный…Вы можете увидеть его философию дизайна.

3.2.1 Основные функции

PyTorch Elastic Trainer (PET) предоставляет платформу для обучения моделей в кластерах отказоустойчивым и эластичным образом. ПЭТ обеспечивает эти возможности двумя способами:

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

Для интеграции с PET пользователям PyTorch необходимо внести следующие изменения в свою логику обучения:

Пользователям необходимо включить PET для управления циклом обучения.
- По сути, пользователь предоставляет цикл «внутреннего обучения», который с помощью PET заворачивается в повторяемый цикл.
- Цикл PET — это повторяемый цикл, отвечающий за установление или повторное установление группы процессов и восстановление обучения пользователя до хорошего состояния.
Когда новый рабочий процесс присоединяется к пулу процессов, пользователь должен указать, что такое состояние и как применить это состояние к новому рабочему процессу.

3.2.2 Обзор новой конструкции

PET v0.2 получил большой опыт от v0.1 Давайте поговорим о концепции дизайна v0.2.

Динамический диапазон

В PET v.0.2 мы больше не пытаемся исправить ошибки в обучающей функции. Вместо этого PET пытается поддерживать количество рабочих процессов, чтобы поддерживать их на требуемом уровне [min , max] диапазон. Автор приложения отвечает за загрузку и перезапуск из существующего доступного файла точки восстановления. В отличие от версии 0.1, PET версии 0.2 не определяет порядок управления контрольными точками. Авторы приложений могут свободно использоватьtorch.saveиtorch.loadили фреймворки более высокого уровня, такие какPyTorch Lighteningдля обработки.

локальный прокси

PET v0.2 используетelastic-agentновые процессы, каждый узел имеет независимыйelastic-agent. Каждый процесс агента отвечает только за управление набором локальных рабочих процессов для этого узла и координирует свои действия с эластичными агентами на других узлах задания, чтобы определить изменения в членстве в группе процессов. В частности, как показано на рисунке ниже:

Источник изображения:GitHub.com/py факел/голодный…

Изменение членства

Изменения членства обрабатываются следующим образом: при сбое рабочего процесса эластичный агент, управляющий им, убивает всех рабочих на этом узле, затем устанавливает рандеву с другими агентами и перезапускает рабочие процессы с новой информацией о рандеву. Однако, когда агент завершается с ненулевым кодом ошибки, модуль планирования верхнего уровня (например, Kubernetes) должен перезапустить агент (аналогично, этот агент перезапустит всех рабочих, за которых он отвечает). Тот же механизм восстановления применим и к сбоям на уровне узла. Инструменты оркестрации (например, Kubernetes) планируют задания таким образом, чтобы задание могло выполняться с минимальным количеством реплик агентов, а каждый агент, в свою очередь, координировал сценарий обучения пользователя.

Источник изображения:GitHub.com/py факел/голодный…

совместимый

Чтобы принять PET v0.2, приложение просто должно иметь точку входа или основную функцию сPyTorch distributed launcherСовместимый. Мы ожидаем, что распределенные учебные задания, запущенные с помощью распределенных средств запуска, можно будет беспрепятственно запускать с помощью эластичных агентов без каких-либо изменений кода или с минимальными изменениями кода. Разница лишь в том, что в последнем случае приложение сможет работать, несмотря на некоторые сбои.

3.2.3 bare-bones

Новый дизайн PET должен быть «голым костяком»: он уступает гранулярности восстанавливаемости приложений с точки зрения простоты и надежности.

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

Поскольку PET является «голым костяком», он также дает некоторые рекомендации о том, как работать с пользователями, например, об обработке контрольных точек.

В случае сбоя или смены состава все выжившие рабочие будут немедленно убиты. Таким образом, пользователям необходимо вручную обрабатывать контрольные точки и периодически сохранять ход работы, чтобы обеспечить продолжение обучения после перезапуска. Частота создания контрольных точек должна зависеть от устойчивости задания пользователя к сбоям. Пользовательские скрипты рекомендуется обрабатывать в следующей структуре:

  def main():
    load_checkpoint(checkpoint_path)
    initialize()
    train()

  def train():
    for batch in iter(dataset):
      train_step(batch)

      if should_checkpoint:
        save_checkpoint(checkpoint_path)

3.3 Резюме

Нетрудно заметить, что концепция проектирования ТЭ призвана главным образом решить четыре упомянутые выше трудности.

Сложность 1: нужен механизм, позволяющий узлам/процессам обнаруживать друг друга.

Ответ TE таков: при изменении членства все работники повторно встречаются для создания новой группы процессов. рандеву и есть этот механизм открытия.

Трудность 2: Как обрабатывать изменения участников

Ответ TE таков: при сбое рабочего процесса эластичный агент, управляющий им, убивает всех рабочих на этом узле, затем устанавливает рандеву с другими агентами и перезапускает рабочие процессы с новой информацией о рандеву. Однако, когда агент завершается с ненулевым кодом ошибки, модуль планирования верхнего уровня (например, Kubernetes) должен перезапустить агент (аналогично, этот агент перезапустит всех рабочих, за которых он отвечает).

Сложность 3: Как отловить сбой обучения одного процесса и как управлять всеми процессами обучения на одном узле.

Ответ TE таков: каждый процесс-агент отвечает только за управление набором локальных рабочих процессов для этого узла и координирует свои действия с эластичными агентами на других узлах задания, чтобы определить изменения в членстве в группе процессов.

Сложность 4: Как интегрироваться с существующим обучающим кодом.

Ответ TE таков: приложение просто имеет свою точку входа или основную функцию сPyTorch distributed launcherСовместимый.

0x04 проблема

4.1 VS Horovod

Поскольку у нас уже есть основа эластичной тренировки Horovod, мы используем Horovod в качестве эталона, задаем ряд вопросов, а затем идем в PyTorch, чтобы узнать сравнение.

Как управлять локальным тренировочным процессом?
- Хоровод управляет локальным процессом обучения с помощью фонового процесса водителя.
- TE управляет локальным процессом обучения через фоновый процесс агента.
Как сохранить состояние?
- Horovod предоставляет встроенную реализацию, которая использует state.commit() для выполнения контрольных точек между каждым сеансом обучения.
- TE необходимо реализовать контрольную точку сохранения/загрузки самостоятельно.
Как открывать новые узлы?
- Horovod позволяет пользователям самостоятельно реализовать логику обнаружения узлов, что требует от пользователей предоставленияdiscovery_hosts.sh, который указывает узлы, участвующие в обучении. Horovod будет периодически выполнять этот скрипт для обнаружения текущего узла.
- TE использует промежуточное ПО распределенной согласованности ETCD или собственный бэкэнд C10D (на основе TcpStore) для решения проблемы взаимного обнаружения между узлами.
Как ловить исключения?
- Horovod фиксирует аномалии связи коллекции/аномалии узлов/расширение и сокращение пропускной способности, преобразует их в собственные исключения Horovod, а затем создает новое кольцо на основе конфигурации (например, внутреннего черного списка аномальных узлов) для продолжения обучения.
- TE определяет метод монитора, который регулярно вызывается для мониторинга исключений локального процесса, преобразования их во внутренние значения состояния и обработки.Если есть проблема с рабочим процессом, агент на узле перезапустит все рабочие процессы узла на некоторое время. новый раунд рандеву. , поскольку это новый раунд рандеву, другие узлы также перезапустят своих воркеров, а затем все продолжат тренироваться вместе.

4.2 Проблемы ТЭ

Ниже приведены некоторые внутренние вопросы TE, и наш последующий анализ постепенно ответит на эти вопросы.

RANK и WORLD_SIZE эти поля больше не нужно задавать вручную, как это сделать?
Как определить РАНГ между разными узлами?RANK 0экземпляр будет существовать как главная роль?
Как перезапустить воркера после сбоя воркера?
Что делать после того, как TE обнаружит нового работника?
У каждого агента есть рандеву, есть ли у этих рандеву концепция хозяина и раба? Есть ли мастер, который записывает текущее состояние кластера?
Как поддержать динамично увеличивающееся или уменьшающееся количество работников, участвующих в обучении?