Проектирование и настройка GPU-кластера для ML (NVIDIA A100/H100)

Настройка GPU-кластера: где ломается обучение моделей

Собранный своими силами контур на бумаге считает всё правильно, а на первой длинной тренировке начинает разваливаться. Настройка GPU-кластера — это не покупка ускорителей и драйверов, а режимы планирования, охлаждение и отказоустойчивость. Они и определяют, сколько эпох в сутки вы получаете на самом деле.

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

Второй сбой — простой очереди обучения. Задачи ждут, пока узел удерживает процесс, который завис или ждёт данные, а распределение по картам задано статически. Ускорители простаивают, и исследователи запускают эксперименты вручную, в обход очереди.

Третий — потеря чекпоинтов при падении узла. Если контрольные точки пишутся только на локальный диск и недостаточно часто, отказ одной машины обнуляет многочасовой прогон. На своих мощностях это самая дорогая категория сбоев: она бьёт не по железу, а по времени команды.

Все три проблемы решаются на уровне архитектуры кластера, а не заменой ускорителей. Разбираем, как это закрывается.

Что даёт выделенный кластер под обучение моделей

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

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

Отказоустойчивость обучения — следствие контроля среды, а не везения. Температуру, питание и обмен между узлами мы отслеживаем постоянно, поэтому отклонения видны до того, как задача упадёт на середине прогона; контрольные точки сохраняются автоматически, и перезапуск идёт с последней, а не с нуля. Класс отказов из-за перегрева и просадок питания уходит вместе с запасом по охлаждению и корректными лимитами по мощности.

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

Варианты организации вычислений: свой контур, аренда, облако

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

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

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

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

Порядок внедрения: от аудита нагрузки до передачи в работу

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

1. Аудит нагрузки на обучение. Снимаем профиль задач: долю простоя ускорителей в ожидании данных, время обмена градиентами между узлами, место, где упирается чтение датасетов. Результат — модель профиля с пиковым числом одновременных запусков.

2. Проектирование инфраструктуры обучения. По профилю определяем число узлов и плотность ускорителей, топологию связей, объём хранилища под датасеты и контрольные точки. Здесь же фиксируем, как задачи раскладываются между узлами.

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

4. Проверка отказоустойчивости. Гасим по очереди узел, сетевой линк и сегмент хранилища прямо во время обучения. Смотрим, переживает ли задача перезапуск сегмента без потери прогресса и за какое время восстанавливается.

5. Замер на эталонной задаче. Сверяем реальную скорость обучения с расчётной и ищем рассинхрон: медленный узел, неверные параметры пакетной обработки, перегрев.

6. Передача кластера в эксплуатацию. Отдаём конфигурации как код, панели мониторинга, регламенты реагирования и инструкции для инженеров заказчика.

Артефакты передачи: конфигурации, схемы, регламенты

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

• Конфигурации инфраструктуры — декларативное описание узлов, сетей, хранилищ и очереди задач. Развёртывание с нуля и восстановление после сбоя воспроизводятся без ручных правок и «донастройки по памяти».
• Схемы вычислительного контура — топология узлов, путь данных от хранилища до ускорителей, точки отказа и узкие места. Новый инженер видит, где предел по пропускной способности, до того как что-то менять.
• Политики доступа к ресурсам — роли, квоты, изоляция команд, правила приоритетов. Одна группа задач не вытесняет другую, а спорные случаи решаются по записанному правилу, а не в переписке.
• Документация ML-инфраструктуры — состав образов, версии драйверов и библиотек, порядок подключения, каталоги наборов данных и промежуточных состояний обучения. Запуск новой модели не превращается в археологию.
• Регламенты обслуживания — окна плановых работ, порядок обновления драйверов, вывод и замена узлов, проверки целостности хранилища. Простой становится предсказуемым вместо аварийного.
• Инструкции по инцидентам — сценарии «узел выпал из очереди», «задача зависла», «закончилось место» с пошаговыми действиями и точками эскалации.

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

Кейс: как распределённое обучение перестало простаивать

Кластер на несколько десятков узлов с ускорителями NVIDIA обслуживал поток задач распределённого обучения — от коротких экспериментов до многодневных прогонов на всех узлах сразу. Формально отказоустойчивость была: задания выдавались через планировщик, данные лежали на общей файловой системе, у каждой задачи был свой набор контрольных точек. На практике падение одного узла останавливало всю группу, а прогресс эпохи терялся целиком.

Что показывали метрики до

Доля полезной загрузки ускорителей держалась около 40%: остальное время железо ждало повторного запуска, освобождения узла или ручного разбора инцидента. Восстановление после сбоя занимало часы — инженер поднимал окружение заново, переносил задачу и запускал обучение с последней сохранённой точки, которая к тому моменту отставала на несколько эпох. Часть задач не возобновлялась вовсе: контрольные точки лежали на локальном диске упавшей машины.

Что изменили

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

После правок доля полезной загрузки выросла с 40% до 87%, время восстановления после сбоя сократилось с часов до единиц минут, а доля задач, потерянных без возможности продолжения, упала до нуля. Появился и учёт по каждому запуску: видно, сколько времени ушло на вычисления, сколько на ожидание в очереди и сколько на перезапуски — деградация замечается до того, как её увидит исследователь.

Чем отличается один узел от распределённого запуска обучения?

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

Граница проходит не по числу ускорителей, а по тому, что ограничивает шаг обучения. Если узкое место — вычисления, а память не переполняется, второй узел не ускорит работу, а добавит ожидание на пересылке. Распределённый запуск нужен, когда модель или пакет данных перестают помещаться либо когда требуется объём вычислений, недостижимый на одном узле.

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

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

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

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

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

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

Как разделяются доступы между командами?

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

Как обновляется контур без простоя?

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

Что входит в поддержку после передачи?

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

Обсудим задачу — вернёмся с оценкой и планом работ

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

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

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

Опишите задачу удобным способом — вернёмся с оценкой и планом работ.