Почему одна медленная GPU тормозит весь кластер

19 октября Meta рассказала, как устроен Prometheus, её гигаваттный кластер в Нью-Олбани, штат Огайо. На нём обучили модели Muse, включая Muse Wonder. Сейчас в кластере сотни тысяч GPU в нескольких зданиях, а в планах около миллиона. В анонсе Meta вынесла вперёд не флопсы, а надёжность: goodput больше 85% на предобучении и больше 90% на обучении с подкреплением, и около 47 тысяч GPU-часов между прерываниями. С тех пор обновления прошивок подняли этот интервал выше 54 тысяч.

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

Почему все ждут самую медленную GPU

Возьмём обучение с параллелизмом по данным. У каждой копии модели своя порция батча. Копии считают градиенты, затем операция all-reduce складывает и усредняет их по всем копиям, и каждая обновляет веса одинаково. Следующий шаг начнётся, только когда all-reduce закончится, а он закончится, только когда придёт вклад от последнего участника. Время шага равно времени самой медленной GPU плюс обмен.

Отсюда простая арифметика. Если в задании на 10 000 GPU одна из-за перегрева работает на 20% медленнее, весь шаг удлиняется на те же 20%, и 9999 исправных GPU часть времени простаивают. Внутри копии связь ещё теснее: при тензорном и конвейерном параллелизме GPU обмениваются данными много раз за шаг. Поэтому Meta проектирует сеть по этой иерархии: самый быстрый обмен внутри копии, более терпимый к задержкам между копиями.

Отказ хуже медленной GPU. Если GPU пропала, all-reduce не завершится никогда, задание повиснет, сработает таймаут, и обучение придётся перезапускать.

Что ломается

Подробная публичная статистика есть в статье о Llama 3. За 54-дневный период предобучения модели 405B на кластере до 16 тысяч H100 задание прерывалось 466 раз. 47 прерываний были плановыми, например обновления прошивок, остальные 419 неожиданными, примерно одно каждые три часа. Около 78% неожиданных прерываний связаны с подтверждёнными или вероятными проблемами железа. Сами GPU дали 58,7%, в том числе неисправные GPU 30,1% и память HBM3 17,2%. На ошибки софта пришлось 12,9%, на сетевые коммутаторы и кабели 8,4%. Ручное вмешательство понадобилось только трижды, с остальным справилась автоматика.

У Meta в Prometheus картина похожая, но масштаб другой. В середине 2025 года, на старте кластера, число прерываний доходило почти до тысячи в сутки на 8 тысяч GPU. За год его снизили на 99%. Главным источником сбоев на GB200 сначала была целостность сигнала NVLink: в кластере больше 600 000 соединений NVLink, и слабая деградация любого из них запускает цикл восстановления. На GB300 с большей памятью вперёд вышли сбои HBM и LPDDR. Отдельно Meta называет отказы коммутаторов NVLink и события в сети между зданиями.

Новое поколение железа увеличило и радиус поражения. В стойке NVL72 72 GPU связаны NVLink в один домен, у H100 таких было восемь. Сбой в домене теперь задевает в 9 раз больше GPU.

Как находят и выводят плохие хосты

Первая линия защиты работает до старта. Новые узлы проходят прогон под нагрузкой, перед каждым большим заданием идут проверки здоровья, и в задание попадают только прошедшие их хосты. Meta прогоняет стресс-тесты по всем 600 000 путей NVLink до того, как по ним пойдёт трафик, а каждый отремонтированный узел проходит карантин перед возвращением в пул.

Вторая линия работает во время обучения. Медленного участника, страглера (straggler), найти труднее, чем мёртвого: формально он работает. В статье о Llama 3 написано, что один такой узел способен замедлить тысячи GPU и выглядит как медленная, но рабочая связь. Команда записывала длительность каждой коллективной операции с помощью NCCL flight recorder из PyTorch, а собственные инструменты ранжировали подозрительные обмены. Обычно хватало проверить несколько главных подозреваемых. Память Meta отслеживает по телеметрии и выводит деградирующие устройства по характерным паттернам ошибок раньше, чем они уронят задание.

Третья линия решает, чем заменить выведенный хост. В каждой стойке NVL72 Meta занимает заданием 64 GPU, а восемь держит запасными, потому что параллелизм удобнее раскладывается на группы размером в степень двойки. Отказавшую GPU сразу заменяет запасная, стойка остаётся в задании, и рестарт не ждёт ремонта. На случай отказа целой стойки держат ещё около 2% запасных стоек. Для задания на 32 768 активных GPU это 523 стойки, или 37 656 GPU, из которых около 13% запасные. Исправления прошивок Meta раскатывает на 100 тысяч GPU за несколько часов.

Чекпоинт и рестарт

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

Частые чекпоинты уменьшают откат, но запись сама отнимает время. Компромисс описывает формула Янга: оптимальный интервал примерно равен корню из удвоенного произведения стоимости записи на средний интервал между сбоями. Посчитаем на условном примере. Пусть сбой случается раз в 86 минут, запись чекпоинта останавливает обучение на минуту, а рестарт занимает 10 минут. Интервал выходит около 13 минут. Около 8% времени уходит на запись, в среднем ещё 6,5 минуты работы теряется при откате, плюс 10 минут рестарта на каждый сбой. В сумме кластер теряет больше четверти времени.

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

Почему MTBI решает при 100 тысячах GPU

MTBI, среднее время между прерываниями, Meta считает в GPU-часах. Чтобы понять, как часто останавливается конкретное задание, его делят на число GPU. При 47 тысячах GPU-часов задание на 32 768 GPU прерывается примерно раз в 86 минут, на 100 тысяч GPU раз в 28 минут, а на миллион GPU раз в три минуты, наш пересчёт. За три минуты кластер едва успеет подняться после рестарта. Цель Meta, два прерывания в сутки на 8 тысяч GPU, это около 100 тысяч GPU-часов, и даже она даёт миллиону GPU сбой каждые шесть минут. Без обработки сбоев внутри копии и мгновенной замены железа на таком масштабе синхронное обучение не работает.

Goodput, или полезная работа GPU, показывает, какая доля времени ушла на продвижение обучения. В статье о Llama 3 похожую метрику называют эффективным временем обучения и приводят больше 90%. На кластере в 100 тысяч GPU каждый процент goodput равен тысяче GPU, которые весь срок обучения греют воздух впустую.

На надёжность влияет и физика здания. В той же статье о Llama 3 пропускная способность менялась на 1–2% в течение суток: днём жарче, и GPU снижают частоту. А синхронные паузы тысяч GPU дают скачки потребления в десятки мегаватт, мы писали об этом в статье про электричество.

Что из этого следует