Усунення несправностей GPU-кластерів: типові проблеми та керівництво з їх вирішення

Збої рідинного охолодження тепер очолюють категорію інцидентів — проблеми CDU, забруднення теплоносія, повітряні пробки. NVIDIA DCGM 3.3+ покращує діагностичне покриття для H100/H200. Коди помилок XID оновлено для архітектури Blackwell...

Усунення несправностей GPU-кластерів: типові проблеми та керівництво з їх вирішення

Усунення несправностей GPU-кластерів: типові проблеми та керівництво з їх вирішення

Оновлено 8 грудня 2025 року

Оновлення грудня 2025: Збої рідинного охолодження тепер очолюють категорію інцидентів — проблеми CDU, забруднення теплоносія, повітряні пробки. NVIDIA DCGM 3.3+ покращує діагностичне покриття для H100/H200. Коди помилок XID оновлено для архітектури Blackwell. Патерни помилок пам'яті (ECC-корекції, перепризначення рядків) дедалі частіше використовуються для прогнозування збоїв. Діагностика NVLink є критичною для виявлення проблем навчання на кількох GPU.

GPU-кластери виходять з ладу інакше, ніж традиційна обчислювальна інфраструктура. Один деградований GPU у навчальному кластері з 512 вузлів може знизити загальну продуктивність на 40%. Помилки пам'яті, які були б допустимими для CPU-навантажень, спричиняють негайні збої навчання. Мікросекундні затримки в мережі руйнують ефективність розподіленого навчання. Це керівництво надає систематичні підходи до діагностики та усунення унікальних режимів відмов GPU-інфраструктури.

Патерни апаратних збоїв та діагностика

Апаратні збої GPU проявляються через три основні патерни: негайні відмови, зниження продуктивності та періодичні помилки. Негайні відмови зазвичай викликають помилки XID у розгортаннях NVIDIA, при цьому XID 79 (GPU відключився від шини) впливає на 3,2% розгортань H100 протягом першого року, згідно зі звітами про інфраструктуру Meta. Ці збої вимагають систематичної ізоляції для визначення першопричин.

NVIDIA Data Center GPU Manager (DCGM) забезпечує комплексну апаратну діагностику через команду dcgmi diag. Діагностика рівня 3 виконується протягом 12 хвилин, тестуючи пропускну здатність пам'яті, пропускну здатність PCIe, підключення NVLink та термічну поведінку під навантаженням. Microsoft Azure GPU fleet запускає діагностику DCGM на 100 000 GPU щоночі, виявляючи деградоване обладнання до впливу на клієнтів. Їхній автоматизований конвеєр видаляє GPU, що показують 15% зниження продуктивності, з виробничих пулів.

Помилки пам'яті домінують у статистиці відмов GPU. High Bandwidth Memory (HBM) у GPU H100 працює на швидкості 3,35 ТБ/с, що робить її вразливою як до апаратних, так і до програмних помилок. ECC (Error-Correcting Code) виявляє однобітові помилки, але невиправні двобітові помилки (DBE) вимагають негайної заміни GPU. Аналіз Google Cloud показує, що помилки HBM зростають експоненціально вище 75°C, з подвоєнням частоти відмов на кожні 5°C перевищення цього порогу.

Відмови інтерфейсу PCIe проявляються як зниження пропускної здатності або повна втрата зв'язку. Команда nvidia-smi -q показує стан PCIe-з'єднання, відображаючи поточне покоління та ширину. GPU H100 вимагають PCIe Gen5 x16 для повної пропускної здатності 128 ГБ/с. Деградація до швидкостей Gen4 знижує пропускну здатність до 64 ГБ/с, впливаючи на час завантаження моделі на 50%. Lambda Labs виявили, що 8% їхніх GPU-серверів працювали на зниженій швидкості PCIe через неправильну конфігурацію BIOS, що коштувало $2,3 мільйони щорічно через знижене використання.

Відмови системи живлення створюють тонкі проблеми продуктивності до повної відмови. Модулі регулювання напруги (VRM) на платах H100 обробляють 700A при напрузі ядра 1,1V. Деградовані VRM викликають обмеження потужності, знижуючи частоту GPU з 1,98 ГГц до 1,2 ГГц. Інструменти моніторингу повинні відстежувати як миттєве, так і середнє споживання енергії. CoreWeave впровадили диференціальний моніторинг потужності, порівнюючи ідентичні навантаження на GPU для виявлення 5% деградації системи живлення до впливу на клієнтів.

Проблеми драйверів та мікропрограм

Невідповідність версій драйверів спричиняє 31% проблем GPU-кластерів, згідно зі статистикою підтримки NVIDIA. CUDA-застосунки, скомпільовані для конкретних версій драйверів, загадково відмовляють при оновленні драйверів. Інструмент nvidia-smi показує версію драйвера 545.23.08, але застосунки можуть вимагати 535.104.12 для конкретних функцій CUDA. Фіксація версій запобігає автоматичним оновленням, але вимагає ручного управління патчами безпеки.

Синхронізація мікропрограм між кластерами є критичною для розподіленого навчання. Невідповідність мікропрограм NVLink між GPU викликає збої колективних операцій із загадковими помилками NCCL. Команда nvidia-smi -q | grep "VBIOS Version" показує версії мікропрограм, які повинні точно збігатися для оптимальної продуктивності. Навчальні кластери OpenAI для GPT-4 стандартизовані на конкретних версіях мікропрограм, з автоматичним карантином вузлів при будь-яких відхиленнях.

Витоки пам'яті драйверів накопичуються протягом тижнів роботи. Створення контексту CUDA без належного очищення споживає системну пам'ять, врешті-решт викликаючи помилки нестачі пам'яті, незважаючи на доступну VRAM. Команда nvidia-smi показує 0MB використано, але lsof виявляє тисячі осиротілих файлових дескрипторів. Інфраструктура Anthropic автоматично перезапускає драйвери GPU, що показують більше 1000 відкритих файлових дескрипторів, запобігаючи вичерпанню пам'яті.

Конфлікти модулів ядра між nouveau (відкритим кодом) та пропрієтарними драйверами NVIDIA створюють збої ініціалізації. Команда lsmod | grep nouveau виявляє конфліктуючі модулі, які необхідно заблокувати. Системи Ubuntu 22.04 вимагають явного блокування в /etc/modprobe.d/blacklist-nouveau.conf з подальшим update-initramfs -u для запобігання завантаженню під час завантаження. Ця проблема впливає на 12% нових розгортань, згідно з даними підтримки Canonical.

Неправильні конфігурації середовища виконання контейнерів запобігають доступу до GPU, незважаючи на правильну установку драйверів. NVIDIA Container Toolkit версії 1.14.0 вніс критичні зміни, що вимагають явного вибору пристрою через змінні середовища NVIDIA_VISIBLE_DEVICES. Контейнери Docker, запущені без прапорця --gpus all, виглядають функціональними, але виконують обчислення лише на CPU зі швидкістю в 1/100 від очікуваної. Розгортання Kubernetes вимагають лімітів ресурсів nvidia.com/gpu у специфікаціях pod для належного планування GPU.

Проблеми управління температурою

Термічне обмеження знижує продуктивність GPU перед спрацюванням захисного вимкнення. GPU H100 обмежуються при 83°C, знижуючи тактову частоту на 15 МГц на кожен градус вище порогу. Виробничі розгортання повинні підтримувати температуру нижче 75°C для оптимальної продуктивності. Команда nvidia-smi -q -d TEMPERATURE надає поточну, максимальну та порогову температуру для проактивного моніторингу.

Збої рідинного охолодження створюють унікальні діагностичні труднощі. Деградація швидкості потоку на 20% підвищує температуру GPU на 8-10°C. Датчики тиску на виходах CDU (Coolant Distribution Unit — блок розподілу теплоносія) повинні підтримувати 30-35 PSI для оптимального потоку. Кластери Microsoft з рідинним охолодженням використовують моніторинг диференціального тиску, сповіщаючи, коли перепад тиску перевищує 5 PSI між подавальним та зворотним колекторами. Забруднення частинками спричиняє 60% обмежень потоку, вимагаючи щоквартальної заміни фільтрів.

Гарячі точки виникають через нерівномірне нанесення термопасти або монтаж холодної пластини. Теплове зображення виявляє температурні перепади, що перевищують 15°C по кристалу GPU. Правильний монтаж вимагає крутного моменту 35 in-lbs на кріпильних гвинтах, що затягуються хрестоподібним патерном для забезпечення рівномірного тиску. Виробничий процес Supermicro включає термічну валідацію, що показує менше 5°C варіації по кристалах, з необхідністю повторного монтажу при більших перепадах.

Коливання температури навколишнього середовища між зонами кластера створюють дисбаланс продуктивності. GPU в гарячих коридорах, що досягають 35°C навколишнього середовища, обмежуються на 20% частіше, ніж ті, що при 25°C. Моделювання обчислювальної гідродинаміки (CFD) виявляє зони рециркуляції, де відпрацьоване повітря повторно потрапляє на вхід. Дата-центри Facebook використовують рішення ізоляції, що підтримують однорідність температури 3°C для 10 000 GPU-розгортань.

Відмови вентиляторів поширюються каскадом у щільних GPU-розгортаннях. Кожен GPU H100 покладається на системні вентилятори, що забезпечують 200 CFM повітряного потоку. Відмова одного вентилятора підвищує температуру сусідніх GPU на 5-7°C. Резервні конфігурації вентиляторів (N+1) запобігають тепловим подіям, але вимагають 20% додаткової потужності. Прогностичне обслуговування з використанням варіацій швидкості вентиляторів виявляє несправні підшипники за 30 днів до повної відмови, забезпечуючи проактивну заміну.

Усунення несправностей мережі та інтерконекту

Проблеми InfiniBand-мережі мультиплікуються в завданнях розподіленого навчання. Помилки одного з'єднання викликають нескінченне зависання операцій MPI_Allreduce. Команда ibdiagnet виконує комплексну валідацію мережі, перевіряючи швидкості з'єднань, лічильники помилок та таблиці маршрутизації. Символьні помилки, що перевищують 100 на годину, вказують на деградацію кабелю, який потребує заміни. Інфраструктура Meta автоматично видаляє вузли з надмірними помилками InfiniBand з навчальних пулів.

Деградація продуктивності RDMA (Remote Direct Memory Access) відбувається без очевидних помилок. PCIe Access Control Services (ACS) повинні бути вимкнені для peer-to-peer передач між GPU. Команда setpci модифікує простір конфігурації PCIe, але зміни не зберігаються після перезавантаження без модифікацій BIOS. Вимірювання затримки за допомогою ib_write_lat повинні показувати 1,8 мікросекунди для локальних з'єднань, з 10% варіацією, що вказує на перевантаження або неправильну конфігурацію.

Неправильні конфігурації топології NVLink знижують пропускну здатність між парами GPU. Команда nvidia-smi topo -m відображає топологію з'єднань, з NV12, що вказує на повну пропускну здатність NVLink, та PHB, що показує з'єднання лише через PCIe. Оптимальні конфігурації створюють повнозв'язні NVLink-меші всередині вузлів. Інстанси Amazon p5.48xlarge забезпечують двонаправлену пропускну здатність NVLink 900 ГБ/с при правильній конфігурації, але неправильні конфігурації знижують її до швидкостей PCIe 64 ГБ/с.

Мережеве перевантаження від трафіку сховища впливає на комунікацію GPU. Змішані розгортання Ethernet/InfiniBand вимагають ретельної конфігурації Quality of Service (QoS). Трафік сховища, що споживає 40% доступної пропускної здатності, збільшує час колективних операцій MPI у 3 рази. Виділені мережі сховища або формування трафіку з 60% зарезервованої пропускної здатності для комунікації GPU запобігають уповільненню навчання.

Помилки синхронізації часу викликають збої розподіленого навчання. Розбіжність годинників, що перевищує 1 мілісекунду між вузлами, викликає помилки таймауту NCCL. Precision Time Protocol (PTP) підтримує субмікросекундну синхронізацію, але вимагає підтримки апаратних міток часу. Команда chrony sources показує стан синхронізації, з величинами зсуву вище 100 мікросекунд, що вимагають негайної корекції. Інфраструктура Google підтримує 100-наносекундну синхронізацію між глобальними GPU-кластерами, використовуючи атомні годинники як еталон.

Виявлення та усунення помилок пам'яті

Помилки HBM (High Bandwidth Memory) слідують передбачуваним патернам, що дозволяють проактивне втручання. Однобітові помилки, виправлені ECC, вказують на деградацію комірок пам'яті. Команда nvidia-smi -q -d ECC повідомляє як волатильні, так і сукупні підрахунки помилок. Волатильні підрахунки скидаються при перезавантаженні, тоді як сукупні зберігаються. GPU, що показують більше 10 однобітових помилок на годину, повинні бути заплановані на заміну під час наступного вікна обслуговування.

Збої виділення пам'яті, незважаючи на доступну VRAM, вказують на фрагментацію. Функція torch.cuda.memory_stats() у PyTorch показує виділену порівняно із зарезервованою пам'яттю. Зарезервована пам'ять може бути вдвічі більшою за виділену через поведінку кешуючого алокатора. Змінна середовища PYTORCH_CUDA_ALLOC_CONF налаштовує стратегії виділення, з max_split_size_mb=512, що зменшує фрагментацію для моделей з тензорами різного розміру.

Пороги вилучення сторінок визначають термін служби GPU. GPU NVIDIA вилучають сторінки пам'яті з невиправними помилками, зменшуючи доступну пам'ять. Команда nvidia-smi -q -d PAGE_RETIREMENT показує кількість вилучених сторінок та наявність додаткових сторінок. GPU H100 можуть вилучити до 512 сторінок перед необхідністю заміни. Автоматизований моніторинг повинен ініціювати заміну при вилученні 400 сторінок, запобігаючи повній відмові під час критичних навчальних запусків.

Деградація пропускної здатності пам'яті вказує на термічні проблеми або проблеми живлення. Тест bandwidthTest CUDA sample повинен досягати 3,35 ТБ/с на GPU H100. Продуктивність нижче 3,0 ТБ/с вказує на обмеження. Команда nvidia-smi -q -d PERFORMANCE показує поточні тактові частоти пам'яті. Знижені швидкості часто корелюють з температурою вище 75°C або споживанням енергії, що наближається до лімітів TDP.

Помилки CUDA out of memory (OOM) вимагають систематичного налагодження. Змінна середовища CUDA_LAUNCH_BLOCKING=1 примусово виконує синхронне виконання, надаючи точне розташування помилок. Профілювання пам'яті за допомогою nsys profile виявляє патерни виділення та терм

[Вміст скорочено для перекладу]

Запросити пропозицію_

Розкажіть про ваш проект і ми відповімо протягом 72 годин.

> ПЕРЕДАЧА_ЗАВЕРШЕНА

Запит отримано_

Дякуємо за ваш запит. Наша команда розгляне його та відповість протягом 72 годин.

В ЧЕРЗІ НА ОБРОБКУ