🧑‍🚒 Characterizing GPU Resilience and Impact on AI/HPC Systems

#gpu #failure #nvidia #slurm

🥼 Article

Похоже я в ближайшее время попишу про GPU.

Еще одно исследование на тему стабильности использования GPU в кластере.
Анализ кластера ~1K GPU с использованием A100 и H100 на протяжении 2.5 лет из UIUC вместе со Slurm.

В отличии от прошлой статьи они разбирали software related issues и механизмамы починки.

📚Take 1: Memory Issues
Одна H100 владеет 96GB HMB3 памятью, A100 40GB HBM2e.
Ошибки на H100 возникают в 3 раза чаше и они в целом коррелируют с объемом памяти.

❗Чем больше память на карте, тем больше вероятность Memory Issues.

В основном большая часть проблем с картами это ошибки памяти.
В GPU используется ECC память, но она не всегда помогает.
Есть класс ошибок, при которых драйвер помечает блок как Uncorrectable и требует GPU reset, чтобы карта запомнила что этот блок использовать нельзя.
Для пользователя это выглядит как упавший процесс, при простом перезапуске возможен повтор и помогает только GPU Reset и drain всей ноды.
В качестве примера см pic 1.

🚧 Take 2: Средний uptime карты всего 99.3%
Для A100 -- 99.4%, H100 -- 99.3%.
В H100 есть дополнительные механизмы, которые позволяют часть Memory Issues починить без GPU Reset, но процессы все равно продолжат падать.

❗99.3% это очень мало, это 9-10 минут downtime на каждой карточке.

❗4 gpu -- uptime 97.2%, downtime 40 min / day
❗8 gpu -- uptime 94.5%, downtime 79 min / day

Здесь вопрос к скорости починки, от момента обнаружения (Mean-Time-To-Detect) до самого GPU Reset с освобождением от нагрузки (Mean-Time-To-Recover).
Это напрямую влияет на downtime, и GPU reset на картах не объединенных в кластер делать намного быстрее.

💊 Take 3: Устройство автопочинки

На рисунке 2 изображен путь того как обрабатывают ошибки памяти где есть поддержка online recovery mechanisms в виде error containment и dynamic page offloading.

GPU Memory. Figure 3 shows the uncorrectable ECC memory
error-recovery process [35] for A100 and H100 in more detail. The
primary mechanism for mitigating uncorrectable ECC memory er-
rors for A100 and H100 GPUs is row-remapping, wherein the faulty
memory row is replaced with a spare row, and a row-remapping
event (RRE) is logged. The actual row remapping happens at the
next GPU reset (e.g., during node reboot or maintenance). If there
are no spare memory rows, a row remapping failure (RRF) is indi-
cated [33, 35].
A100 and H100 GPUs support online recovery mechanisms such
as error containment and dynamic page offlining [33, 35] for miti-
gating uncorrectable ECC memory errors with minimal node in-
terruption. The dynamic page offlining marks the faulty memory
page as unusable without requiring a GPU reset to maintain avail-
ability. The error containment procedure terminates user processes
using the faulty memory address to prevent error propagation
to other applications. Successful error containment is logged as
a Contained Memory Error, whereas an unsuccessful error con-
tainment is logged as an Uncontained Memory Error. Failure in
a row-remapping or error containment can cause a GPU failure
that requires a GPU reset or node reboot. Delta SREs monitor row-
remapping failures and replace GPUs that repeatedly emit such
errors.

Т.е. надо внимательно следить за износом и заменять GPU, когда он перестает срабатывать.

🪵 Take 4: System logging

Все события по работе этих меназимов можно взять из системных логов.
Nvidia пишет их в dmesg и исследовали их отбирали прямо по regexp, группируя близкие события.

🔗 Take 5: Nvlink errors has a 54% chance of leading to a job failure
Nvlink нужен для быстрого и прямого обмена данными между GPU.
Nvlink поддерживает CRC и он умеет делать retransmit в случае если CRC не сходится.
Кроме того, у исследователей были случаи ошибок NVlink, когда он не использовался для расчета задачи и это никак не влияло на пользователя.