Новости

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Выбрано с сайта imbue.com.

Автор: Команда Imbue

Машинное сердце, подборка

Редактор: панда

Мы знаем, что LLM обучается на крупномасштабных компьютерных кластерах с использованием огромных данных. Machine Heart внедрила множество методов и технологий для помощи и улучшения процесса обучения LLM. Сегодня мы хотим поделиться статьей, которая углубляется в базовую технологию и рассказывает, как превратить кучу «голого железа» даже без операционной системы в компьютерный кластер для обучения LLM.

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

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

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

Если вы заинтересованы в создании собственной инфраструктуры обучения LLM или вам интересно, как создается LLM, то эту статью стоит прочитать и собрать.

Ниже приводится оригинальный текст статьи команды Imbue.

введение

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

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

На протяжении всего процесса наша команда инженеров работала с компанией Voltance Park над подготовкой компьютерных кластеров и созданием основы для производственных приложений. Весь этот процесс включает в себя:

1. Настройте каждую машину

2. Настройте InfiniBand

3. Убедитесь, что машина полностью исправна.

4. Диагностика распространенных проблем с тренировками

5. Улучшить инфраструктурные инструменты

Каждый шаг подробно описан ниже.

Предыстория: Как это было сделано

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

В этой статье речь пойдет о кластере, содержащем 4088 графических процессоров H100, распределенных по 511 компьютерам, или по 8 графических процессоров на компьютер. Причина, по которой существует 511 компьютеров с графическими процессорами, заключается в том, что некоторые соединения необходимо зарезервировать для узла Unified Fabric Manager, роль которого заключается в управлении сетью InfiniBand. На 511 хостах, оснащенных графическим процессором, каждый графический процессор напрямую подключен к сетевой карте ConnectX-7, которая может передавать данные со скоростью 400 Гбит/с на любой графический процессор в сети InfiniBand.

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

Обратите внимание, что связь во время обучения сети осуществляется через InfiniBand, а не через Ethernet. Хотя эти машины также подключены к Ethernet, роль этой сети заключается в передаче данных, таких как наборы данных и контрольные точки. Если вы используете Ethernet для отправки данных, скорость будет намного медленнее, поскольку данные сначала будут передаваться от графического процессора к процессору, а затем через карту Ethernet со скоростью 100 Гбит/с. Хотя также возможно обучение через Ethernet с использованием технологии RDMA over Converged Ethernet (RoCE), которая требует большой дополнительной работы как со стороны аппаратного, так и программного обеспечения и, как правило, менее надежна, чем InfiniBand. Более подробную информацию можно найти в этом документе: https://arxiv.org/pdf/2402.15627.

Существует также вторичный Ethernet, используемый только для настройки и управления, обеспечивающий доступ к BIOS (базовой системе ввода-вывода), источнику питания и другим интерфейсам управления для низкоуровневых машинных интерфейсов. Без этой сети управления нам пришлось бы вручную настраивать каждый узел с помощью USB-драйвера, клавиатуры и монитора. Для ситуаций с сотнями машин такой подход не является устойчивым.

Для достижения высокой производительности обучения в этом кластере необходимо, чтобы каждый компонент (InfiniBand, Ethernet, графический процессор и сами узлы) работал почти идеально. Если какое-либо из этих более чем 12 000 соединений немного нестабильно, это может замедлить общий процесс обучения.

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

Процесс: как превратить «голое железо» в полностью работоспособный кластер

Настройте каждую машину

После установления первоначального Ethernet-соединения с кластером через сеть управления получаются учетные данные доступа к контроллеру управления основной платой (BMC). BMC — это выделенный сервисный процессор, который удаленно контролирует хост-системы и обычно подключается к отдельной сети. Он позволяет нам управлять машиной так, как будто мы находимся там лично, а также предоставляет API для проверки работоспособности оборудования, настроек BIOS и управления питанием.

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

Шаг 0. Сначала настройте машину

Мы начали с установки Ubuntu 22.04 на сервер с помощью iDRAC (контроллера управления основной платой Dell), а затем настроили все остальное на основе этой операционной системы. Одна из возможностей iDRAC — разрешить установку и загрузку образов ISO с локального компьютера и предоставить виртуальную консоль через браузер. В идеале это единственный этап установки вручную.

Шаг 1. Установите операционную систему на каждый компьютер.

После настройки первой машины приступайте к установке программного обеспечения Ubuntu «Metal-as-a-Service» (MAAS), которое поможет настроить остальные серверы. Инструмент загрузки и автоматизации iDRAC использует протокол среды выполнения перед загрузкой (PXE), чтобы дать указание каждому компьютеру загружаться из сети и настроить MAAS для ответа на запросы загрузки PXE. При выполнении начальной сетевой загрузки сервер получает IP-адрес и начальное ядро ​​от MAAS через протокол динамического распределения IP-адресов DHCP без необходимости устанавливать что-либо на локальный диск. Это базовая среда для автоматизации повторяющихся установок операционной системы. Теоретически нам просто нужно дождаться первой загрузки и все будет готово. Но на практике интеграция MAAS с BMC ненадежна, поэтому мы используем API iDRAC для предварительного сбора MAC-адреса каждой машины (уникального физического идентификатора оборудования).

На протяжении всего тренировочного процесса MAAS часто является более надежным компонентом набора позвонков. Однако вначале мы столкнулись с некоторыми проблемами, уникальными для нашей установки. Например, при настройке первых нескольких машин мне не удалось ничего установить через apt из-за проблем с проверкой сертификата HTTPS, поскольку часы были очень разными. Соответственно, поскольку сервер MAAS должен отвечать за множество вещей (DHCP-сервер, DNS-сервер для преобразования имен хостов в IP-адреса, HTTP-прокси между хостом и официальным сервером пакетов Ubuntu, NTP-сервер, управление конфигурацией Cloud-Init, заземление база данных правды, используемая для подключения MAC-адреса к IP-адресу, имени хоста и пользовательским метаданным), поэтому нам сложно решить эти проблемы, исходя из основной причины. Кроме того, существует проблема обучения жизненному циклу конфигурации MAAS, поскольку цель разработки — справиться со сложностью управления развертыванием с нуля и постепенной миграцией узлов и различными отладочными/неработоспособными промежуточными состояниями.

Шаг 2. Диагностика сломанной машины

Мы обнаружили, что около 10% машин не загружались, в основном из-за физических проблем с сервером. Это распространенный сценарий настройки больших кластеров графических процессоров. Ситуации, с которыми мы столкнулись, включают: отсутствие или неправильное подключение сетевых кабелей, аппаратные проблемы в iDRAC, поврежденные блоки питания, поврежденные драйверы NVME (быстродействующая энергонезависимая память), отсутствие внутренних цепей и сбой отображения сетевой карты или графического процессора. Мы автоматически проверили эти проблемы, вернули некоторые машины в Dell для повторного тестирования и отправили соответствующие заказы на работу персоналу центра обработки данных. Одним из преимуществ самостоятельной настройки кластера является то, что мы можем сразу же использовать работоспособные машины, ожидая обслуживания некоторых машин.

Шаг 3: Минимально жизнеспособная наблюдаемая машина

Продолжаем следующие настройки на каждом сервере:

1.Docker (чтобы упростить запуск сервисов и учебных заданий)

2. Драйвер графического процессора центра обработки данных

3. Инструмент экспорта узла Prometheus (используется для экспорта стабильного потока данных индикаторов оборудования/операционной системы)

4. Инструмент экспорта DCGM (используется для экспорта дополнительных данных индикаторов из графического процессора NVIDIA, таких как состояние графического процессора, частота, использование)

5. Пул RAIDZ ZFS для всех драйверов неоперационной системы, который позволяет машине продолжать работу даже в случае сбоя драйвера, а также обеспечивает бесплатное прозрачное сжатие (это особенно полезно для наборов данных в виде простого текста и повторяющихся журналов - относительно Использование этого инструмент обычно увеличивает полезное пространство до 10 раз по сравнению с отсутствием использования этого инструмента)

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

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

Шаг 4. Обучение графического процессора с одним узлом

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

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

Согласно журналам сервера Ubuntu, многие кабели между графическим процессором и шиной PCIe или сетевой картой выдавали эту ошибку: «ограниченная ширина: x4 <x16». После обновления прошивки шины коммутатора PCIe мы обнаружили, что около четверти хостов требуется переподключение внутренних кабелей PCIe — предположительно потому, что кабели между корпусом и графическим процессором довольно хрупкие, то есть при каждом обслуживании графического процессора эти кабели будут быть вытолкнут или вытащен.

Произошло несколько различных сбоев, которые также затронули несколько хостов. Dell помогла нам решить некоторые проблемы с обновлением прошивки:

Диск NVMe не показал никаких сбоев, но при прикосновении к нему зависала вся машина.

Жесткие диски в Linux появляются в случайном порядке, что приводит к путанице в MAAS и приводит к установке операционной системы не на тот диск.

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

Динамическое масштабирование процессора вышло из-под контроля, ограничив частоту рабочих ядер до 2 ГГц.

Прямая связь между графическими процессорами (GDR или клиент одноранговой памяти GPUDirect RDMA) не может быть успешно применена.

Настройка InfiniBand

Шаг 0: Установите УФМ

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

Шаг 1: Переустановка

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

Шаг 2: Десять тысяч температурных сигналов (предупреждение)

После устранения проблем с физической проводкой InfiniBand успешно установила соединения со всеми коммутаторами InfiniBand в сетевой структуре. Однако почти каждый порт коммутатора начал сообщать о чрезмерной температуре, иногда превышающей 70°C, хотя данные не передавались. Мы обнаружили, что проблема связана с открытым пространством между коммутаторами в одной стойке, из-за которого горячий воздух течет обратно вперед. Наш партнер по дата-центру помог нам быстро диагностировать проблему и разработать соответствующее решение.

Шаг 3: 1800 сигналов тревоги

Многие порты также имеют высокий уровень ошибок или переключаются между нормальным и поврежденным состояниями, что называется «колебанием». Эти проблемы возникают только тогда, когда порты действительно используются, поэтому их трудно обнаружить заранее, поскольку вся наша структура состоит из 10 000 сильно избыточных каналов. Наш партнер по центру обработки данных помог очистить и переустановить порты сигнализации, а мы отключили оставшиеся приемопередатчики сигнализации, пока ждали замены.

Несмотря на то, что InfiniBand устойчив к аппаратным сбоям, как только около 10% структуры начинает выходить из строя, такие функции, как адаптивная маршрутизация, не работают надежно, чтобы учесть случайные потери соединения.

За это время мы успешно провели многоузловое обучение на 100–200 машинах. Наш процесс в некоторой степени импровизирован: иногда мы запускаем случайный набор узлов, наблюдаем за их производительностью, а затем пытаемся поддерживать работу как можно большего числа из них. Этот метод позволяет нам найти надежное подмножество сетевой структуры InfiniBand, но он очень сложен, поскольку каждый раз нам нужно менять набор узлов, используемых для обучения, тем самым меняя ссылку InfiniBand по умолчанию.

Шаг 4. InfiniBand горит как сумасшедший

Чтобы более эффективно диагностировать проблемы InfiniBand, мы разработали рабочую нагрузку для всего кластера, которая одновременно пропускала бы как можно больше данных через каждый порт в структуре. Это отличается от выполнения большой рабочей нагрузки с полным сокращением по всему кластеру, которая требует использования NCCL для оптимизации связи между отдельными узлами с помощью NVLink для связи графического процессора через слоты серверного модуля PCIe (SXM).

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

Шаг 5. GPUDirect RDMA

Чтобы обеспечить связь с графическим процессором без увеличения нагрузки на процессор, мы включили функцию GPUDirect RDMA, которая обеспечивает прямую связь между сетевыми картами InfiniBand. Это включает в себя два ключевых шага:

1. Запустите дополнительный модуль ядра.

2. Убедитесь, что служба контроля доступа PCIe (ACS) отключена, чтобы предотвратить немедленное зависание (немедленное зависание).

Шаг 6. Расширьте «золотой» сервер

Чтобы создать кластер графических процессоров с использованием новейшего оборудования, необходимо быть готовым к тому, что примерно 3% ваших компьютеров будут выходить из строя каждую неделю.

Однако следует отметить: не каждая машина имеет единую вероятность отказа в 3%, но у небольшого количества необработанных машин неоднократно возникают различные проблемы, пока они не будут должным образом отремонтированы. Это подчеркивает преимущества наличия большого количества компьютеров в одной сетевой структуре. Поэтому вместо того, чтобы просто находить случайные машины для проведения крупномасштабного обучения, например «Ударь крота, чтобы посмотреть, что сломается», наш подход заключается в том, чтобы сосредоточиться на масштабировании заведомо надежных серверов, «золотых» серверов.

Шаг 7: Обслуживание

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

1. Обновления встроенного ПО, особенно если только половина кластера завершила обновление, могут привести к повреждению состояния UFM и потребовать перезапуска UFM на всех коммутаторах InfiniBand.

2. Блоки графических процессоров одновременно перезапускаются массово, что может привести к внесению большого количества обновлений в состояние UFM, а также потребовать перезапуска службы UFM.

Убедитесь, что машина полностью исправна

Попутно мы обнаружили множество причин, по которым отдельные машины могут работать со сбоями или замедлять обучение. Многие из этих режимов сбоя не проявляются сразу, поэтому мы написали несколько сценариев проверки работоспособности, чтобы проверить, достаточно ли работоспособен хост. Мы опубликовали код здесь: https://github.com/imbue-ai/cluster-health.

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

Проверка работоспособности графического процессора

Мы проверили правильность количества графических процессоров, включенность проверки ECC (кода исправления ошибок) и отсутствие ошибок ECC. Мы также проверили, что топология NVLink (которая соединяет графические процессоры друг с другом) работает без ошибок.

Проверка работоспособности дискового пространства

Мы проверили, превышает ли использование дискового пространства хоста 95%.

Проверка работоспособности докера

Мы проверили, что Docker может запускать контейнеры с подключенным графическим процессором (т. е. среда выполнения контейнеров NVIDIA работает правильно), а также что контейнеры Docker, связанные с мониторингом/анализом, активированы и имеют правильные разрешения хоста.

Проверка работоспособности через Dmesg

Мы проверили dmesg на наличие аппаратных ошибок Xids или SXid (ошибки, вызванные графическими процессорами NVIDIA или переключателями между графическими процессорами NVIDIA). Мы также читаем все строки журнала dmesg, чтобы убедиться, что все они могут быть отнесены к списку общих/ожидаемых строк журнала.

Проверка работоспособности iDRAC

Мы проверили наличие ошибок iDRAC на компьютере, который игнорировал сообщения о нефатальных ошибках. Это проверка, специфичная для компьютеров Dell, поэтому она не включена в наш открытый исходный код.

Проверка работоспособности диска

Мы проверили, что zpool установлен, что Docker правильно подключен к нему и действительно может получить к нему доступ без блокировки процессора.

Проверка работоспособности InfiniBand

Мы проверили, увеличилось ли количество ошибок InfiniBand и/или не устарела ли прошивка драйвера.

Проверка работоспособности Nvlink

Мы проверили наличие ошибок NVLink на машине. На практике это не приводит к сбоям в обучении, но может замедлить обучение.

Проверка здоровья ГДР

Мы проверили, включена ли GDR на машине.

Проверка работоспособности VBIOS

Мы проверили, что версия VBIOS графического процессора и прошивка базовой платы H100 обновлены.

Проверка здоровья Флинта

Мы использовали flint и hca_self_test, чтобы проверить, что драйвер Mellanox OFED, прошивка сетевой карты и прошивка трансивера имеют правильные версии и что они правильно скомпилированы для драйвера NVIDIA.

Проверка здоровья ПСБ

Мы опросили устройства PCIe, чтобы проверить, соответствует ли скорость и ширина соединения между графическим процессором, PSB (шина коммутатора PCIe) и сетевой картой ожидаемой. Мы также проверили актуальность прошивки коммутатора. Этот сценарий был разработан Dell, а не Imbue, поэтому в настоящее время мы не можем поделиться им.

В дополнение к этим быстрым проверкам работоспособности мы также проводим некоторые более сложные проверки работоспособности, в том числе:

Инициализируйте матричные вычисления с помощью PyTorch и измеряйте пропускную способность NVLink, скорость вычислений и объем памяти графического процессора. Мы установили соответствующие флаги GDR для тестирования InfiniBand и NVLink.

Используйте ib_write_bw и –use_cuda для отправки данных через карту IB и измерения пропускной способности карт PCIe и InfiniBand. Этот процесс длился долго (около 15 минут) для того, чтобы порхающий канал InfiniBand был найден.

Запустите диагностику нескольких узлов, чтобы проверить возможность инициализации NCCL и убедиться в том, что она случайно не зависает. Если есть паузы, наш разветвленный код NCCL добавляет дополнительное журналирование. Для обнаружения проблемы требуется от 12 до 24 часов, поэтому обычно мы запускаем ее только на новых узлах или при подозрении на проблему.

Проверьте экспорт DCGM на наличие событий регулирования частоты графического процессора (за исключением ожидаемых gpu_idle и power_cap). Чтобы проверить эти события питания, лучше всего запустить обучение нескольких узлов, при котором одновременно проверяются все графические процессоры, карты InfiniBand, а также процессоры и диски.

Диагностика распространенных проблем с обучением

Как только оборудование заработает должным образом, можно начинать обучение.

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

Сбой при запуске

В каком-то смысле это лучшая ошибка, с которой вы можете столкнуться, потому что ее (теоретически) легко воспроизвести и исправить.

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

Еще одна базовая проверка, которую мы выполняем, — убедиться, что все машины подключены к сети и что созданные трассировки стека или журналы можно легко агрегировать и проверять. Мы использовали программные стеки Loki, Prometheus и Grafana, но подойдет любой подходящий инструмент SaaS для агрегирования журналов или отслеживания. Поскольку эти обучающие прогоны по своей природе синхронны и распределены, первая ошибка часто приводит к каскаду несвязанных ошибок. Здесь проверки работоспособности также могут помочь немедленно обнаружить такие ошибки, как поврежденный жесткий диск или отсутствующий или недействительный графический процессор.

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

1. Ошибки типа «Прямой порядок различается в зависимости от ранга: ранг 0 — это все 43 параметра, а ранг 1228 — это все 1 параметр». Мы обнаружили, что это странная особенность реализации PyTorch Fully Sharded Data Parallel (FSDP), которая была решена после перезапуска.

2. Ошибка «Недостаточно памяти графического процессора (OOM)», которая выглядит следующим образом: «CUDA недостаточно памяти. Попытка выделить...» Путем многократной проверки нашей конфигурации и кода и отмены недавних изменений кода (из-за неправильных спецификаций устройства PyTorch во время запуска и приводившего к чрезмерному использованию графического процессора № 0), мы устранили эти проблемы.

3. Ошибки CPU/RAM Out of Memory (OOM). Эти ошибки нелегко найти в журнале ошибок, и их обычно можно обнаружить с помощью журнала dmesg хоста вне контейнера Docker. Когда OOM Killer вызывается для остановки разветвленного процесса или сетевого узла, мы видим, что они в основном проявляются как CalledProcessError или ConnectionError. Когда из dmesg обнаруживается вызов OOM Killer, мы предпочитаем просто отказаться от проверки работоспособности и перезагрузить систему. Мы также проверили наши пути кода на предмет адекватной ручной сборки мусора (ниже есть раздел о том, как отключить эту функцию), а также проверили любые неожиданные попытки выполнить вычисления или переместить тензоры в ЦП.

Сбой во время тренировки

Первым приоритетом является автоматизация системы, чтобы она могла автоматически перезапускать все проверки работоспособности, а затем перезапускаться, если неработоспособный хост не найден. Мы столкнулись с некоторыми случайными аппаратными ошибками, включая ошибки Xid и SXid; эти ошибки могли привести к сбою выполнения без создания значимой трассировки стека Python. Некоторые проблемы, такие как переназначение строк, можно устранить путем перезагрузки. Другие проблемы, такие как неисправимые ошибки ECC, часто требуют обслуживания оборудования или замены деталей.

Кроме того, мы заметили, что неверные данные обучения также могут вызывать сбои. Например, если в корпусе имеется очень большой одиночный документ, это может вызвать ошибку нехватки памяти на графическом процессоре или процессоре. Чтобы предотвратить эту проблему, мы используем полностью детерминированный загрузчик данных, благодаря которому каждый сбой легко воспроизводится благодаря привязке к эпохе или номеру шага. Мы обнаружили, что отключение загрузки данных или замена поддельных данных (например, нулевых данных) помогает подтвердить, являются ли основной причиной ошибки данные.

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

Зависание без трассировки стека (позже могут возникнуть проблемы с тайм-аутом)

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

Один из самых запоминающихся типов ошибок сопровождается такими сообщениями об ошибках:

Сторожевой таймер обнаружил коллективную операцию тайм-аута: WorkNCCL (SeqNum=408951, OpType=_ALLGATHER_BASE, … , Timeout (мс)=600000) работал в течение 600351 миллисекунды до тайм-аута

И все работники графического процессора, участвовавшие в тренировочном прогоне, выдавали такие сообщения об ошибках.

Это означает, что одному или нескольким хостам не удалось завершить операцию NCCL или произошел сбой соединений NCCL и InfiniBand, в результате чего все остальные хосты одновременно зависли в тензорной операции до тех пор, пока не истечет тайм-аут NCCL_TIMEOUT. К сожалению, из-за особенностей библиотеки программного обеспечения NCCL сложно определить, на каком хосте возникла проблема.

Мы внесли некоторые изменения в журналирование программной библиотеки NCCL, см. нашу разветвленную версию: https://github.com/boweiliu/nccl. Это может лучше выявить сообщения или операции, выполняемые при возникновении сбоя, и, таким образом, определить, какой хост или графический процессор может препятствовать его запуску.

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

Другие ситуации отсутствия ответа и отсутствия доступных сообщений об ошибках обычно связаны с проблемами, связанными с оборудованием, например, с ранее упомянутыми ошибками Xid/SXid/ECC, которые приводят к блокировке драйвера NVIDIA или коммуникационного драйвера NVIDIA Docker. Чтобы отличить зависания NCCL от зависаний драйвера, условий гонки или взаимоблокировок в коде Python, мы используем такие инструменты, как Py-Spy и GNU Project Debugger (GDB), для отладки встреченных зависших процессов в реальном времени. При использовании этого подхода была обнаружена одна конкретная проблема: из-за ошибки конфигурации в настройках потока Python мы не смогли правильно запустить восемь многопоточных процессов NCCL GPU на некоторых хостах, которые столкнулись с состоянием гонки на этапе кода инициализации перед PyTorch.

Замедление обучения (измеряется МФУ)

Отсутствие инструментов делает этот тип проблемы еще более неприятным, чем предыдущий. Помимо использования Py-Spy, проверки трассировки стека и GDB, мы также использовали NVIDIA Nsight и инструменты профилирования, некоторые из которых сложно использовать в сильно распределенных средах.

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

Во-первых, оказывается полезным несколько раз проверять конфигурацию, код и переменные среды. Ошибки, с которыми мы столкнулись, включают использование неправильной модели, неправильного размера пакета, неправильных настроек UFM или NCCL, ошибок CUDA_DEVICE_MAX_CONNECTIONS. Это приведет к неоптимальной производительности.

Мы также считаем полезным измерять мгновенную (т. е. для каждой партии) MFU (а не сглаженные или оконные средние значения), поскольку несглаженные кривые MFU часто помогают диагностировать классы проблем. Проблемы, которые приводят к замедлению тренировок, включают в себя:

Немедленно начинайте тренировку с очень низкого MFU (менее одной десятой ожидаемого) и сохраняйте стабильность.

Скорее всего, это аппаратная проблема с сетевым подключением InfiniBand, например, сбой коммутатора уровня T2 или T3. Проблемы с аппаратным обеспечением между графическим процессором и сетевой платой также могут вызвать такую ​​ситуацию, в случае чего dmesg сообщит об ошибке следующего вида: Количество линий PCIe x16 ограничено…

Начинайте тренировку немедленно с 30 % ожидаемого MFU и сохраняйте стабильный уровень.

Это может быть вызвано неправильными настройками GDR на одном хосте (одноранговая память NVIDIA) или неправильными переменными среды GDR.

Начинайте тренировку немедленно примерно с 60-80% ожидаемого MFU и держите стабильно.

Наиболее распространенной причиной является плохое или ошибочное качество канала InfiniBand, в частности, сбой сетевого адаптера InfiniBand на одном графическом процессоре, из-за которого NCCL пытается маршрутизировать трафик через собственный NVLink и использовать сетевой адаптер на другом графическом процессоре на том же хосте. Регулирование ЦП также может вызвать эту проблему, что требует настройки параметров BIOS на некоторых хостах.

Внезапное огромное замедление (в 10 раз) при обработке определенных пакетов данных, и это случается довольно часто.

По сути, это все, что касается контрольных точек или оценки — это можно проверить, проверив количество эпох или шагов. Досадно то, что если вы настроите автоматический сигнал тревоги в случае неисправности MFU, появится много ложных сигналов тревоги.

Внезапное огромное замедление (падение в 10 раз) при обработке определенных пакетов данных.

Это происходит случайным образом и довольно редко (примерно раз в 15 минут) и сразу же следует полный возврат к исправному MFU.

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

MFU постепенно тормозит во время работы, но после каждой перезагрузки возвращается к 100%

Теоретически причиной может быть перегрев коммутатора, но мы никогда не видели такого случая. Однако мы использовали профилировщики Python и NVIDIA, чтобы определить, что причиной снижения производительности является автоматическая сборка мусора.

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

Мы использовали синхронный алгоритм распределенного обучения FSDP на базе ZeRO-3. Во время операции блокировки один рабочий процесс, выполняющий сбор мусора, может замедлить работу всех остальных рабочих процессов. Если у вас сотни рабочих процессов, это может привести к значительному замедлению работы.

Производительность сначала хорошая, затем внезапно падает (до 70% от ожидаемой) и продолжает работать с высокой частотой (каждые 15 секунд).

Мы заметили, что это связано с «причинами регулирования тактовой частоты» на графических процессорах NVIDIA, которые можно устранить с помощью соответствующих настроек NVIDIA DCGM. Эту проблему могут вызвать проблемы с перегревом (высокая температура графического процессора или отказ/снижение эффективности охлаждающего вентилятора хоста) или сбой источника питания. Кроме того, когда мы максимально используем все 8 графических процессоров и 8 сетевых карт InfiniBand вместе с ЦП/ОЗУ/диском, у некоторых наших хостов со специальным оборудованием питания возникают проблемы с напряжением, но они используют их только все (обычно только в реальный тренировочный забег).

Хорошая производительность, но больше шума, чем обычно (отклонение высокочастотного белого шума от 90% до 100% от ожидаемого MFU)

Это также связано с аппаратным обеспечением InfiniBand, но обычно происходит из-за некоторой степени снижения производительности или дрожания на каналах выше в сети, а не на менее избыточных хостах уровня T2.

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

Вот простая сводка/блок-схема/контрольный список полноты для устранения проблем с пропускной способностью:

Раньше эта система работала нормально?

Какие изменения вы внесли недавно (например, объединили код, обновили драйверы)?

Исправен ли хост, на котором вы работаете? Все ли ваши зависимые службы работают нормально, включая сторонние SaaS, такие как Docker Hub, GitHub и т. д.?

Можете ли вы быть уверены, что код, среда, конфигурация, версия, список хостов, порядок ранжирования и случайное начальное число, которые вы используете сейчас, точно такие же, как и в прошлый раз? (Если бы такая проверка могла быть реализована.)

Воспроизводима ли проблема?

Как это связано с другими вещами? Другие процессы? Ежедневные запланированные задачи crontab? Индикатор хоста, DCGM или UFM?

Правильно ли ваш инструмент измеряет эти показатели?

Сохраняется ли проблема при запуске урезанной версии кода (с использованием меньших моделей, поддельных данных, без сохранения или загрузки контрольных точек)?

Улучшение инструментов инфраструктуры

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

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

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

неисправность машины

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

Сбой сетевого компонента

Все наблюдаемые нами сетевые сбои были обнаружены UFM и зарегистрированы в журнале событий UFM, поэтому ответ был простым: проанализировать журнал UFM и предпринять соответствующие действия.

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

локальная зеркальная файловая система

Для этих крупных распределенных тренировок на ранней стадии было обнаружено, что скорость обмена данными между кластером и Ethernet является основным узким местом. Пропускная способность общего Ethernet-соединения составляет примерно 10 Гбит/с; эта полоса пропускания может быстро насытиться, если сотни сотрудников одновременно загружают наборы данных и моделируют контрольные точки.

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

Локальный распределенный реестр Docker

Мы использовали Kraken, отличное программное обеспечение с открытым исходным кодом для передачи образов Docker «точка-точка». Проблем с программным обеспечением у нас практически не было, что для нас было весьма удивительно, учитывая сложность наших задач и реализации. Адрес инструмента: https://github.com/uber/kraken.

Различные инструменты мониторинга производительности

Мы установили анализатор Torch по умолчанию, а также систему Nsight от Nvidia. Последнее помогает нам понять точное время, необходимое для прямых/обратных проходов и связи NCCL, а также помогает определить, станет ли данный размер модели и количество рабочих узким местом. Однако Nsight Systems немного сложен в использовании, поскольку он требует запуска Docker в привилегированном режиме, что требует отключения проверок безопасности, связанных с событиями мониторинга производительности, а сохранение его конфигурации часто требует остановки всего процесса обучения.

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

Разделите машины на разные группы, чтобы найти вышедшие из строя хосты.

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

Например, если тренировочный прогон на 48 машинах не удался, то проведите меньшее обучение на 6 группах по 8 машин в каждой, а затем проведите меньшее обучение на 8 группах по 6 машин в каждой. Обычно только один из двух этапов выходит из строя, что дает нам уверенность в том, что машина, отказавшая на обеих фазах, неисправна.

Размышления и извлеченные уроки

В процессе настройки и обслуживания инфраструктуры мы извлекли несколько полезных уроков:

Один из полезных подходов — поменять местами машины. Во время выполнения может быть полезно использовать на 10–20 % больше машин, чем требуется, чтобы можно было легко возобновить обучение в случае сбоя машины. Настройка кластерной сети таким образом, чтобы каждая машина была тесно связана с каждой другой машиной, позволяет нам использовать любое рабочее подмножество этих машин.

Стоит писать тесты и автоматизированные решения для каждого сбоя аппаратного или программного обеспечения, с которым вы сталкиваетесь, потому что каждая проблема, возникшая в процессе обучения, будет повторяться. Аналогично, для каждого неоднозначного сообщения об ошибке стоит написать инструмент, который лучше объясняет ошибку.

Воспроизводимость является ключом к хорошему научному исследованию. Одним из главных принципов, которые мы сразу же приняли, было: «Изменяйте только одну вещь за раз», даже в самых простых вещах.

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

Подведем итог

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

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

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