NCCL: чому навчання на кількох прискорювачах не масштабується
Коли модель перестає вміщатися в пам'ять одного прискорювача, її розбивають між кількома, очікуючи кратного прискорення. На практиці друга карта дає приріст помітно менший за подвійний, а на восьми прогін може виявитися довшим, ніж на одній. Причина в тому, що час іде не на обчислення, а на обмін між прискорювачами.
Обмін складається з колективних операцій — розсилання ваг, збору частин тензора, усереднення градієнтів на кожній ітерації. Бібліотека NVIDIA NCCL вирішує, якими каналами й у якому порядку розкласти ці пересилання, щоб жоден прискорювач не чекав на інші довше, ніж потрібно.
Вузьке місце обміну видає себе опосередковано: частка простою прискорювачів зростає разом із розміром кластера, а крива прискорення виходить на плато. Якщо пересилання йдуть через спільну пам'ять і процесор, затримка на кожній ітерації накопичується в години на довгому прогоні.
Налаштування колективних операцій — розмір буфера, кількість одночасних пересилань, пріоритет каналів, прив'язка процесів до пристроїв — змінює картину сильніше, ніж заміна заліза.
Розбираємо, як це закривається: від вимірювання профілю обміну до конфігурації, за якої нелінійне прискорення знову стає лінійним.
Що дає налаштований обмін між прискорювачами
За замовчуванням NVIDIA NCCL сам підбирає топологію обміну — кільце або дерево, кількість каналів, транспорт між вузлами.
На неоднорідній конфігурації цей автовибір помиляється: трафік іде через повільну шину замість прямих лінків між прискорювачами, і утилізація просідає майже вдвічі.
Після явного задання схеми (алгоритм, рівень прямого доступу, потрібний мережевий інтерфейс, прив'язка процесів до лінків) пропускна здатність обміну зростає в 1,5-2 рази, а крок синхронізації перестає бути найдорожчою частиною прогону.
Ефект особливо видно на масштабуванні кластера. Якщо на восьми прискорювачах синхронізація з'їдала частину кроку, то на кількох десятках вона з'їдає весь бюджет часу, і додавання вузлів не дає прискорення.
Налаштований обмін повертає лінійність: час прогону скорочується пропорційно до кількості прискорювачів, а утилізація кожного тримається у верхній частині діапазону замість простою в очікуванні на інших.
Окремо зникає клас відмов «зависання на синхронізації». Один повільний лінк або втрачений пакет змушують чекати всіх учасників, і задача висить до ручного втручання.
Таймаути обміну, діагностичний лог і контроль стану лінків перетворюють це на передбачуваний збій із зрозумілою причиною: процес зупиняється сам, а несправний шлях виводиться з групи обміну.
Контроль тримаємо на чотирьох метриках: пропускна здатність обміну на крок, час прогону, утилізація прискорювачів і кількість перезапусків. Вони показують, де саме втрачається продуктивність — в обчисленнях, у мережі чи в очікуванні.
NCCL: схеми зв'язку прискорювачів, варіанти й обмеження
Вибір схеми обміну в NCCL визначається двома речами: фізичною топологією вузла і профілем навантаження — розміром повідомлень і тим, як часто прискорювачі синхронізуються.
Бібліотека підбирає режим сама, але на нестандартній топології автовизначення помиляється, і навчання починає чекати на обмін замість того, щоб рахувати.
Схеми та їхні межі застосовності
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Кільцева схема | Однорідна топологія, великі повідомлення, багато прискорювачів в одній групі | Чутлива до повільної ланки: один відстаючий учасник задає темп усім |
| Ієрархічний обмін | Прискорювачі розбиті на групи всередині вузла та між вузлами | Потребує явного опису груп; на дрібних задачах накладні витрати вищі за виграш |
| Пряме з'єднання прискорювачів | Пікові задачі, де обмін іде між сусідніми прискорювачами | Працює лише там, де топологія фізично це підтримує, і не виходить за межі вузла |
| Обмін через пам'ять вузла | Неоднорідна топологія, налагодження, невеликий обсяг передач | Пропускна здатність пам'яті вузла нижча за прямі лінії — обмін стає вузьким місцем |
Схеми не взаємовиключні: для дрібних повідомлень розумніший один режим, для великих — інший, і перемикання за порогом дає помітний приріст на змішаному навантаженні.
Ми знімаємо профіль обміну на реальній задачі, звіряємо його з картою топології та фіксуємо режим у конфігурації запуску — так поведінка відтворюється від запуску до запуску, а не залежить від того, що бібліотека вгадала цього разу.
Етапи налаштування: від аудиту вузла до передачі регламенту
Налаштування NCCL — не перебір змінних середовища, а послідовність, де кожен крок спирається на виміряний профіль навантаження.
Без аудиту топології правка колективних операцій перетворюється на вгадування: вузьке місце може бути в шині між прискорювачами, у мережевому транспорті або в коді навчання.
- Аудит кластера. Знімаємо карту зв'язків між прискорювачами та вузлами: де обмін іде напряму, де через проміжну ланку, чи однаковий канал на всіх вузлах. На виході — список вузлів, які поводяться інакше за інших.
- Профіль навантаження. Прогоняємо реальне навчання з вимірюванням часу кроку та частки, яку займає обмін між пристроями — видно, що гальмує: мережа, синхронізація градієнтів чи підготовка даних.
- Схема обміну. Під профіль добираємо алгоритми колективних операцій, розмір буфера та порядок обміну між групами: великий буфер дає рівний потік, малий — меншу затримку на коротких кроках.
- Налаштування. Вносимо правки по одній і після кожної повторюємо вимірювання — так видно внесок зміни, а не сумарний ефект від десятка змінних. Конфігурацію тримаємо в репозиторії.
- Перевірка під навантаженням. Кілька задач одночасно, вимкнення вузла, перепідключення: розкид часу кроку має залишитися в допустимих межах.
- Приймальні випробування. Порівнюємо час кроку та утилізацію прискорювачів до і після, прогоняємо сценарії відмов, фіксуємо контрольні значення, за якими команда перевіряє кластер після змін.
- Передача. Віддаємо регламент: як змінювати параметри, куди дивитися при падінні швидкості, які вимірювання знімати перед релізом.
Конфігурації, схеми топології та регламенти запусків
Після введення кластера в експлуатацію в команди замовника залишається не «набір скриптів від підрядника», а комплект артефактів, за яким запуск повторюється вже без нас.
Нижче — те, що ми передаємо і що перевіряємо на прийманні разом із вашими інженерами: у кожного пункту є власник і місце зберігання у вашому репозиторії.
- Конфігураційні файли навчання: параметри топології каналів NCCL, розміри буферів обміну, таймаути та пороги повторних спроб — з коментарем, чому вибрано саме це значення.
- Схема топології: карта зв'язків прискорювачів, розподіл за доменами та маршрути, задіяні під час обміну градієнтами між вузлами.
- Регламент запуску: порядок прогріву, послідовність перевірок зв'язків і критерії, за яких запуск зупиняють, а не дотягують.
- Політики доступу: ролі на вузлах, обмеження на правку конфігурацій, порядок надання прав на тестовий і продуктивний контури.
- Профілі діагностики та пороги оповіщення: що вважається деградацією обміну і в який момент черговий зобов'язаний втрутитися.
- Експлуатаційна документація: інструкції на випадок деградації, заміни вузла та повернення до попереднього профілю запуску.
- Журнал змін: які правки вносилися в конфігурації, з якою метою і який вимірюваний ефект дали.
- Протокол приймання: що перевірено, ким підтверджено і які пункти залишаються на супровід.
Кейс: як прибрали простій прискорювачів на довгих прогонах
Що ламалося
Кластер на кілька десятків прискорювачів, довгі прогони навчання. Задачі падали на 5–8 годині: колективний обмін градієнтами зависав, ранги чекали один на одного, задачу знімав сторожовий таймаут.
Перезапуск займав 40–60 хвилин — прогрів кешів, повторне завантаження даних, вирівнювання стану; корисного часу на добу залишалося менше половини.
Розбір дав три причини. Частина трафіку між вузлами йшла повільним шляхом: топологія зв'язків не враховувалася під час вибору маршруту. Таймаути стояли заводські й не відображали реальну тривалість операцій.
Запис контрольних точок ішов паралельно з обміном і забирав пропускну здатність, а конфігурації на вузлах розходилися — однаковий код поводився по-різному.
Що змінили
Звели NVIDIA NCCL до єдиного профілю на всьому кластері: зафіксували порядок вибору шляхів між вузлами, розвели обмін градієнтами та запис контрольних точок різними каналами, підняли таймаути до реальних значень і ввімкнули докладний журнал — видно, який ранг відстав і на якій операції.
Прогін з 11 годин проходить без жодного збою синхронізації, частка успішних запусків — 9 з 10 проти 1 з 3. Відновлення після падіння займає близько 6 хвилин: стан піднімається з останньої контрольної точки.
Час епохи скоротився приблизно на п'яту частину, а повторюваність тримається в межах шуму — ті самі дані та зерно дають однакові метрики.
NCCL: що робити, якщо кластер вже розгорнуто, а обмін гальмує
Коротка відповідь: якщо навчання вже йде і кластер працює, перезбирати середовище не потрібно. NCCL обслуговує колективні операції на кшталт all-reduce, і більшу частину втрат знімає підбір транспорту, кількості каналів і параметрів буферизації.
Діагностика обміну починається з порівняння фактичного часу кроку з розрахунковим обсягом передач: розходження в рази означає, що прискорювачі простоюють в очікуванні, а не рахують.
Далі відокремлюємо міжсерверний обмін від внутрішньосерверного. Якщо крок деградує лише під час масштабування на кілька вузлів, причина в мережевому інтерфейсі та маршруті — невдало вибраний адаптер веде трафік в обхід швидкого шляху.
Усередині вузла вузьке місце зазвичай у топології зв'язків між прискорювачами і в тому, як процеси розподілені за обчислювальними лініями.
Покрокова оптимізація йде на короткому прогоні паралельно з робочим навчанням: спочатку фіксуємо базовий час кроку, потім змінюємо по одному параметру — транспорт, кількість каналів, розмір буфера, поріг, з якого вмикається групування передач.
Кожну зміну звіряємо на одному й тому самому наборі даних, щоб відокремити ефект налаштування від випадкового розкиду.
Переналаштування середовища виконується без зупинки навчання: правки у змінні та конфігурацію спочатку перевіряються в резервному запуску і лише потім переносяться в основний.
На практиці частка часу, яку крок витрачає на обмін, падає в рази, і кластер перестає впиратися в стелю під час додавання нових прискорювачів.
Часті технічні сумніви перед початком робіт
Перед стартом виринають ті самі сумніви: чи спрацює налаштування на вже зібраному залізі, чи не доведеться переписувати навчання і що залишиться команді після здачі.
Вузли в кластері неоднорідні — обмін не деградує?
Симметрію не припускаємо, а вимірюємо: знімаємо профіль колективних операцій між усіма парами вузлів і задаємо NCCL явну топологію замість автоматичного вибору. Повільні канали залишаються, але перестають гальмувати інші — обмін вирівнюється передбачувано.
У нас кілька різних моделей навчання — конфігурація одна на всіх?
Профіль підбираємо під тип навантаження: у паралельного навчання великої моделі, донавчання та інференсу розрізняються розміри буферів і схема розподілу роботи за прискорювачами. Тримаємо окремі профілі, щоб правка одного режиму не зачіпала інші.
На довгих прогонах обмін сповільнюється — як це зловити?
Деградація накопичується непомітно: зростають затримки, падає частка корисного часу прискорювачів. Ставимо спостережуваність з перших днів — метрики обміну, журнали таймаутів, порівняння пропускної здатності на початку й наприкінці прогону.
Що залишиться нам після передачі і чи не зламає це сусідні задачі?
Передаємо конфігурації, скрипти перевірки та схему топології з поясненнями — налаштування можна змінювати без нас. Середовища ізолюємо: закріплені версії бібліотек, контейнери, обмеження за ресурсами, тому сусідні задачі на тих самих вузлах не страждають.
Обговоримо задачу: що надіслати для оцінки та плану
Щоб повернутися з оцінкою та планом робіт, а не із загальними формулюваннями, нам потрібні вхідні дані по кластеру та навантаженню. Частину даних знімають прямо з працюючої системи — підкажемо, які метрики та команди для цього знадобляться. Опишіть задачу у вільній формі, навіть якщо частина пунктів поки невідома.
- Топологія: скільки вузлів, скільки прискорювачів на кожному, чим вузли з'єднані між собою.
- Обмін між прискорювачами: чи ввімкнено NCCL, які змінні середовища задано, який транспорт задіяно.
- Профіль навчання: кількість параметрів моделі, розмір батча, цільовий час одного кроку, потрібна тривалість прогону.
- Поточні метрики: скільки займає крок зараз і де втрачається швидкість — на обчисленнях, на обміні чи на читанні даних.
- Середовище: драйвери та бібліотеки актуальної гілки, система керування задачами, контейнери, планувальник.
- Обмеження: допустиме вікно простою, вимоги до відкату на попередню конфігурацію, політики доступу до вузлів.
- Що болить: падіння продуктивності під час масштабування, зависання на старті, помилки в журналах обміну.
- Терміни та приймання: коли потрібен запуск і хто на вашому боці приймає результат.
За цими вхідними даними ми називаємо терміни впровадження та склад команди — скільки інженерів і на який період. Далі обговоримо задачу деталями і повернемося з оцінкою та планом: етапами, точками контролю та варіантами відкату.
