🧑‍🚒 GPU Reliability in AI Clusters: A Study of Failure Modes and Effects

#gpu #failure #nvidia

🥼 Article из #meta platforms

Cтал работать с железом ближе, решил почитать что есть интересного и как часто они выходят из строя GPU.

В статье проанализировали статистику из 1250 Nvidia GPU в 4 кластерах, вот статистика поломок:

🔥 31% Thermal related failures
Чаще всего карты ломаются из-за перегрева, особенно когда температура окружающей среды свыше 24°C.

🔌 22% Power delivery and regulator failures
Это как правило проблемы подачи питания, как в стойке, так и на самой карте.
Так же сюда попадают всплески.

Карта не любит переключний cpu-bound <==> gpu-bound workload, хотя это может быть частой ситуацией когда выполняется checkpoint модели.
Это вызывает временный простой и резкую нагрузку и voltage regulators не всегда справляются с всплесками.

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

The article observed that rapid fluctuations
between compute-intensive and memory-intensive
phases of AI workloads created voltage transients
that exceeded design tolerances. Particularly
concerning were failures during model checkpoint
operations, where synchronized memory writes
across multiple GPUs created power demand
spikes that voltage regulators struggled to
accommodate.

⚠️ 18% Memory subsystem failures
Если в карте начинают появляться single-bit correctable errors, то как правило они потом через время переходят в uncorrectable.
HBM2 карты чаще дают ошибки памяти чем GDDR из-за перегрева, но при этом могут дольше служить.

🏭 13% Manufactoring and silicon defects
Карта может работать стабильно и сбоить только от специфической нагрузки.
Как правило смена специфики нагрузки тут может помочь, либо замена карты по RMA.

🪛10% Firmware & Driver related issues
Я лично думал что этот пункт будет на втором месте.
Возможно это зависит от конкретной карты, драйверов и ядра, возможно исследователям повезло потому что не было разнообразия драйверов и они выровняли версии.

Как правило такие проблемы видны как resource leak и проявляются в продолжительных сценариях или где есть часто-повторяемые операции.
Т.е. в случае с short-lived os это должно быть реже.

📶 6% Interconnect and communication failures
Этот пункт я ожидал третьим, но он тоже в самом конце. Это как раз износ PCI-порта или проблемы с NIC / NVlink.

Интересные факты:

* Как правило карты деградируют сначала по пропускной способности и потом по ошибкам памяти.
* Карты которые деградировали, но работают, потребляют на 25% больше энергии вызывая деградацию соседних.
* В нормальной ситуации gpu uptime 99.2%, но при перегреве падает до 94.7%
* Средний MTBF для GPU около 7250 часов, но когда у тебя большой кластер (1.250), то GPU failure случается каждые 18 часов.

Mitigation strategies:
* Тесты, которые смотрят на соотношения performance (tokens / s) к {TPU, temperature). Это позволяет находить аномалию троттлинга, проседания производительности еще до реальных видимых ошибок
* Охлаждение с избыточностью. Отдельный контур охлаждения между CPU / GPU позволяет снизить число memory issues на 50%.
* Превентивный мониторинг, который следит за картами и находит аномалии раньше чем начинают сбоит и влиять на соседние карты. Reactive Monitoring не отлавливает 42% GPU issues. Будь проактивным, будь как Петя!

Тоже веселый случай, верхняя треть стойки как правило больше перегревается и GPU сбоит в 2.3 раза чаще чем из нижней трети:

The article conducted a detailed analysis of a
production cluster comprising 2,048 GPUs
(NVIDIA A100 80GB) dedicated to large
language model training. Over six months, this
cluster experienced 137 distinct GPU failures
requiring replacement and 412 recoverable
incidents. The primary failure modes were thermal
degradation (41%) and memory subsystem issues
(28%). Notably, failure rates showed significant
positional dependence within racks, with GPUs in
the upper third of racks failing 2.3x more
frequently than those in the lower third. After
implementing enhanced cooling and predictive
maintenance, unplanned downtime decreased by
68%, and training completion time variability
decreased by 47%

Ну и грустная цитата про охлаждение (не хватает инноваций, ожидаем что проблем будет только больше):

The projection models indicate that without
significant architectural changes or cooling
innovations, large-scale AI training clusters may
see reliability decrease by 15-20% per GPU
generation while maintenance costs increase by 25-30%.

У Cloud Providers AFR довольно низкий, в районе 1-2%.

У Edge Computing на consumer железе меньше проблем из-за того что меньше перегрева, но больше с пылью и питанием:)

🧑‍🚒 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, когда он не использовался для расчета задачи и это никак не влияло на пользователя.

🥶 Take 5: GSP errors
GPU System Processor, это отдельный чип отвечающий за инициализацию и управление заданиями.
У него есть отдельная прошивка, и эта штука может отдельно ломаться.

❗Как правило, пробелемы с GSP приводят карту в inoperable state или hung / freeze state

GSP errors can be caused by either GSP firmware bugs [32] or
demanding workload. For example, Delta SREs observed that these
errors were highly correlated with heavy ML benchmarks, and
they suggested that GSP errors are high-impact errors whose recov-
ery requires manual node draining and reboots. Our propagation
analysis confirm that the GSP is a single point of failure on both
A100 GPUs in part because of their spontaneous nature and high
downstream impact (e.g., GPU hangs) on the GPU.

In fact, AWS recom-
mends disabling GSP for stability over performance benefits [4].

🚌 Take 6: GPU fallen Off the Bus
Это скорее типичный износ и перегрев.

GPU Fallen Off the Bus errors were
logged when the GPU driver could not reach the GPU over the
system bus. This error is an integration error often caused by a
loose GPU-motherboard connection or contact failure because of
thermal cycles [49]. Over 99% of the errors of this type lead to
similar errors in close successions and eventually put the GPU into
an error state.

⏱️ T3: Accurate and Fast Performance Prediction for Relational Database Systems With Compiled Decision Trees
#tum #redshift #execution #pipeline #decisiontree #lleaves

🥼 Article

В статье описан механизм оценки времени выполнения запроса, еще до его непосредственного выполнения.

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

🪨 Intro

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

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

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

Когда запрос прилетает в БД, он проходит через несколько важных фаз:
* Parsing, запрос разбивается на AST дерево
* Построение и оптимизация Logic Plan, где используется информация о таблицах и линейная алгебра чтобы определить в каком порядке узлы графа стоит исполнять и какие можно оптимизировать.
* Execution Plan можно сказать что это непосредственный план выполнения запросов. Даже 1 логический план можно сконвертировать в несколько разных вариантов исполнения, например используя разные алгоритмы для Join (HashJoin vs SortJoin / Memory Join vs Disk Join)
* Execution или непосредственное исполнение.

Execution Plan выглядит как дерево с Pipelines, это участки исполнения запроса на критическом пути между Pipeline Breakers (когда нельзя начать следующий pipeline, не завершив предыдущий). (pic 1)


💡Idea №1: Давайте оценивать каждый отдельный Pipeline, а суммарно запрос как сумму этих Predicted Times.

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


💡 Idea №2: Давайте для каждого pipeline создадим Feature Vector, который будет хранить в себе описание и научим ML оценивать время этой части.

Выглядит это примерно как на (pic 2), вектор довольно большой, под сотню параметров для описания.
Если так получается что конкретный Pipeline мы плохо оцениваем, то можно всегда углубляться и добавлять новых feature для описания и дообучать систему.
Благодрая этому получается оценивать pipelines как генерализированную сущность, которая не зависит от самих таблиц / данных.
Т.е. не надо дообучаться на данных, чтобы корректно оценивать время.


💡 Idea №3: Теперь для каждого из feature-vector нужно оценить примерное время, для этого попробуем натренировать Decision Tree на feature-vector's от синтетических запросов.

Decision Tree это клевый способ, потому что для некоторых задач позволяет написать очень эффективный и быстрый inference на cpu.
Он отлично подходит для задач категоризации/оценки когда есть подготовленный feature-vector.
Автор гонял обучение на ноуте ночью, и на утро у него было много деревьев которые хорошо могли оценивать время исполнения запросов.


💡 Idea №4: Q-Error as Error Function: Q-Error(predicted, observed) = max( predicted / observed, observed / predicted)

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

💡 Idea №5: Компиляция DecisionTree с помощью lleaves

Используемый LightGBM позволил построить несколько DT, и пробегаться по ним чтобы оценивать время и в среднем это занимало ~22us.
Но есть замечательный https://github.com/siboehm/lleaves, который позволяет скомпилировать дерево в код, который будет исполняться заметно шустрее.
⚡ Читать его конечно станет невозможно, но это и ненужно, а время работы 4us. (pic 3)


📝 Conclusions

В результате получилась очень быстрая оценка, которая и по скорости и Q-Error превосходит другие имплементации.
Круто это тем, что теперь в момент построения из Logical Plan -> Execution Plans, можно построить несколько и оценить их все, и выбирать нужный уже по оценке времени исполнения, а не только по фичам как раньше.

Результаты оценок pipelines можно кешировать и так делает AWS Redshift в его реализации Stage. Благодаря этому время оценки удается снизить до ~2us для похожих запросов.

🚫 Limitations
Не смотря на всю крутость, у подхода все равно есть ограничения:
1️⃣ Обучать нужно каждый hardware profile, т.е. для каждого instance-type нужно гонять тесты, которые будут строить нужное Decision Tree.
У автора оно гонялось около 10 часов, но зато его можно использовать для любых запросов/данных в БД.
Так же можно переиспользовать между разными версиями БД / инастансами, просто отдельный динамический ресурс.
2️⃣ В модели никак не учитывались в обучении запросы, которые делают Spill на диск. Это скорее дополнительный набор свойств для feature vector, который нужно тренировать. В целом подход наверняка можно переиспользовать, просто надо добавлять это в feature-vector.
3️⃣ Не учитывалась конкуренция за ресурсы. Во время обучения запрос исполнялся один за одним и все ресурсы были отданы ему одному, в реальной ситуации нужно как-то дополнительно учитывать это.

📦 AnyBlox: A Framework for Self-Decoding Datasets
#tum #arrow #parquet #wasm #avx

🥼 Article https://www.vldb.org/pvldb/vol18/p4017-gienieczko.pdf
Статья получила премию VlDB'25 Best Paper Award, но я не согласен 😧

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

🪨 Context
Сейчас стандартом для аналитических задач стали несколько комбинаций форматов:
1. Iceberg (+Parquet) для долговременного хранения и использования в разных системах
2. Apache Arrow для быстрой аналитической обрабтки в памяти или передачи между разными системами
3. Свои бинарные форматы: clickhouse, duckdb, bigquery, и т.п.

Apache Iceberg начал становиться стандартом, но с ним есть проблема.
Для каждого ЯП -- своя реализация, поддерживающая разный набор фичей и разную производительность.

Parquet, страдает тем же самым, каждая система пишет его по-своему.
Каждая БД рано или поздно хочет написать свой Reader / Writer, потому что можно более тесно встроить и значительно ускорить работу.

Из-за этого возникает проблема MxN (где у нас M-систем/БД и N-форматов), количество реализаций и форматов растет, а поддерживать их сложнее.

Свои бинарные форматы всегда работают и поддерживаются лучше, но они всегда vendor-lock на конкретной системе.

🧂The Idea
В статье автор предлагает следующее решение проблемы:
* Рядом с самими данными можно подкладывать программу, которая знает как распаковать эти данные в память.
* В качестве такой механизма для исполнения -- WebAssembly (WASM), ограниченная VM, которая может исполнить произвольный код без системных вызовов.
* База данных должна поддержать WASM Engine, который скомпилирует это программу под свой архитектуру и исполнит ее
* Это программа читает данные и маппит их на Apache Arrow формат, который уже поддерживается многими БД
* PROFIT!

🈲 My opinion
WASM предоставляет песочницу, но она нужна если исполнять там произвольный код.
Если формат стандартизирован, то эта песочница не нужна, нужно тестировать input/output формата, гонять fuzzing testing и схема будет проще и надежней.

Основная проблема с реализациями в том, что некоторые ЯП вроде Java (Scala, Kotlin, ...) и Go, не любят использовать внешние C-libs, потому что взаимодействие своего runtime с любой внешней сишной либой вызывает много проблем.
НО WASM никак не решает эти проблемы, все остается на том же месте.
Здорово иметь возможность запустить произвольный код, но скорее всего разработчики продолжат писать свои parquet reader/writer во всех ЯП (C, C++, Rust, Go, Java).

WASM накладывает ограничения на прямую работу с памятью и автор предлагает использовать mmap, и транслировать их в WASM для zero-copy работы.
Это решает проблему с копированием данных между runtime, но полностью будет игнорировать механизм работы BufferManager в самой БД.
БД сама должна иметь свой буффер и mmap это плохая идея https://db.cs.cmu.edu/mmap-cidr2022/

Apache Arrow как в общий формат это лучший из текущих вариантов для этой задачи, но и у него есть ограничения по типам данных и методам обработки.
Нужно ли дальше БД конвертировать в свой формат? Появится ли там data copy? Если все БД будут использовать Arrow, то их производительность будет ограничена этим форматом.
⚡Это просто не выгодно бизнесу, как формат для импортирования данных -- да, для полноценной работы -- нет

WASM поддерживает векторные инструкции, но до 128 bits (bye-bye AVX256/AVX512), а писать код с ними сложнее чем на C/C++.
Из-за этого вариант с WASM всегда будет хуже C-library или своим парсером.

ИМХО, это проблему лучше решить через Change-Data-Capture.
Например как Data Transfer / Airbyte компонента, которая умеет подписываться на Iceberg и конвертировать его сразу в Arrow или свой бинарный формат.
Думаю это более надежный и быстрый вариант.

Автор в статье показывает, что WASM работает медленее нативных форматов с векторизацией, но быстрее parquet. Ну доля правды в этом и есть, именно поэтому и лучше и переписать parquet lib, потому что там еще есть места для ускорений.