AWS добавила 3 проверки в обучение моделей, чтобы ловить тихие ошибки GPU

Обучение идёт, график ошибки выглядит привычно, GPU не жалуются. А один ускоритель уже посчитал неверное число, и остальные копии модели приняли его в общее обновление. Команда продолжает тратить вычислительное время, хотя результат обучения мог испортиться. AWS описала, как искать такие сбои прямо в цикле PyTorch DDP: повторять часть вычислений на другом узле и сравнивать результаты.

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

Как одна ошибка становится общей

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

Допустим, три GPU рассчитали градиенты 0,20, 0,40 и 0,30. Среднее равно 0,30. Но если второй ускоритель из-за сбоя вернул 4,00 вместо 0,40, все три копии получат уже неверное среднее. После обновления их веса всё равно совпадут. Простая сверка копий покажет порядок, хотя ошибка уже распространилась.

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

В качестве масштаба проблемы AWS приводит данные об обучении Llama 3 405B: за 54 дня Meta связала с тихим повреждением данных шесть из 419 неожиданных прерываний. Эта статистика учитывает обнаруженные случаи, которые удалось связать со сбоем, и не показывает частоту всех незаметных ошибок.

Три проверки в цикле обучения

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

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

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

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

Что учесть перед внедрением

AWS испытала решение на четырёх узлах с 32 NVIDIA H100, программно внося ошибки. Тесты также повторили на трёх узлах — это минимум для предложенной схемы. Такие испытания показывают поведение проверок на заданных сценариях, но не доказывают обнаружение любого аппаратного сбоя.

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

Практический вывод: для дорогих распределённых запусков стоит проверять сами результаты вычислений и заранее готовить восстановление. Начать можно с проверки NaN и Inf перед обновлением и сохранением. Затем — измерить стоимость повторных расчётов на своей нагрузке и определить частоту аудита. Контрольные точки нужно хранить вне заменяемого узла: его локальные диски при замене уничтожаются.