Проєктування мережевої топології GPU-кластерів: архітектури Fat-Tree, Dragonfly та Rail-Optimized

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

Оновлення грудня 2025: DGX SuperPOD визначає трирівневу fat-tree топологію з комутаторами Quantum-2 InfiniBand (400 Гб/с). Дослідження Meta виявило, що помилки конфігурації мережі спричиняють 10,7% серйозних збоїв GPU-завдань. Повна бісекційна пропускна здатність є критичною для розподіленого навчання, де патерни комунікації динамічно змінюються. TPU-поди Google використовують 3D-тор; AWS Trainium застосовує топології, оптимізовані під робочі навантаження.

Референсна архітектура NVIDIA DGX SuperPOD визначає трирівневу fat-tree мережеву топологію, що з'єднує до 32 систем DGX за допомогою комутаторів Quantum-2 InfiniBand зі швидкістю 400 Гб/с на порт.[^1] Архітектура забезпечує повну бісекційну пропускну здатність, тобто сукупна пропускна здатність між будь-якими двома половинами кластера дорівнює загальній пропускній здатності в кожну з половин. Fat-tree топології домінують у розгортаннях GPU-кластерів, оскільки забезпечують передбачувану продуктивність незалежно від того, які пари GPU комунікують — це критична властивість для розподіленого навчання, де патерни комунікації динамічно змінюються.

Вибір мережевої топології безпосередньо впливає на продуктивність навчання, вартість та операційну складність. Дослідження Meta виявило, що помилки конфігурації мережі спричинили 10,7% серйозних збоїв завдань у їхніх GPU-кластерах, а залежні від топології перевантаження сприяли варіативності продуктивності.[^2] TPU-поди Google використовують 3D-торові топології, що дозволяють прямі з'єднання між сусідніми прискорювачами, тоді як кластери AWS Trainium застосовують інші топології, оптимізовані під їхні патерни робочих навантажень.[^3] Розуміння компромісів топологій дозволяє організаціям обирати архітектури, що відповідають їхнім конкретним вимогам до робочих навантажень та бюджетним обмеженням.

Основи fat-tree топології

Fat-tree топологія походить з роботи Чарльза Лейзерсона 1985 року, яка показала, що деревоподібні структури можуть досягати повної бісекційної пропускної здатності, якщо ємність каналів збільшується до кореня.[^4] Сучасні реалізації використовують канали рівної ємності всюди, досягаючи повної пропускної здатності через множинні паралельні шляхи, а не через товстіші канали.

Трирівнева fat-tree архітектура

Трирівнева fat-tree складається з leaf-комутаторів, що підключаються до серверів, spine-комутаторів, що агрегують трафік від leaf, та core-комутаторів, що забезпечують повну зв'язність між spine.[^5] Кожен leaf-комутатор підключається до кожного spine-комутатора, і кожен spine підключається до кожного core-комутатора. Сітка з'єднань створює множинні рівноцінні шляхи між будь-якими двома серверами.

NVIDIA рекомендує fat-tree для DGX-кластерів через передбачувані характеристики затримки та пропускної здатності.[^6] Топологія забезпечує, що колективні операції, такі як all-reduce, демонструють стабільну продуктивність незалежно від розміщення GPU. Завдання навчання не потребують врахування мережевої топології при плануванні, що спрощує управління кластером.

Коефіцієнти перепідписки

Повна бісекційна пропускна здатність вимагає дорогої ємності комутаторів на верхніх рівнях. Багато розгортань приймають перепідписку, де сукупна пропускна здатність висхідних каналів з нижніх рівнів перевищує доступну ємність на верхніх рівнях.[^7] Коефіцієнт перепідписки 2:1 означає, що лише половина трафіку може одночасно проходити через верхні рівні.

Перепідписка підходить для робочих навантажень з локальністю, де більшість комунікації відбувається в межах стійок або подів. Однак розподілене навчання з патернами all-to-all комунікації насичує перепідписані канали, спричиняючи перевантаження та деградацію продуктивності. AI-кластери для навчання зазвичай вимагають неперепідписаних конструкцій, незважаючи на вищу вартість.[^8]

Radix та масштабування

Radix комутатора визначає, скільки портів надає кожен комутатор, впливаючи як на масштаб, так і на вартість. 64-портовий комутатор, що будує трирівневу fat-tree з 32 низхідними та 32 висхідними каналами, масштабується до 32 768 кінцевих точок.[^9] Комутатори з вищим radix зменшують кількість необхідних комутаторів, але збільшують вартість кожного комутатора.

Комутатори NVIDIA Quantum-2 забезпечують 64 порти на 400 Гб/с, дозволяючи великомасштабні fat-tree розгортання з розумною кількістю комутаторів.[^10] Наступне покоління Quantum-X800 збільшує швидкість портів до 800 Гб/с, подвоюючи сукупну пропускну здатність без зміни структури топології.

Rail-optimized топологія

Rail-optimized топологія виникла з усвідомлення того, що GPU-сервери містять множинні GPU, які спільно використовують високошвидкісні внутрішні інтерконекти. Замість того, щоб розглядати кожен GPU незалежно, rail-optimized конструкції вирівнюють мережеві з'єднання з розміщенням GPU всередині серверів.[^11]

Розуміння GPU rails

Система DGX H100 містить вісім GPU, з'єднаних через NVLink, при цьому кожен GPU також підключається до мережевої інтерфейсної карти (NIC).[^12] Вісім NIC відповідають восьми "рейкам", що охоплюють кластер. Rail 0 з'єднує GPU 0 з кожного сервера, rail 1 з'єднує GPU 1 і так далі. Комунікація в межах рейки проходить через меншу кількість комутаторних переходів, ніж крос-рейкова комунікація.

NVIDIA NVLink Switch з'єднує GPU всередині та між серверами з сукупною пропускною здатністю 900 ГБ/с на GPU.[^13] Домен NVLink обробляє більшість комунікації GPU-to-GPU, тоді як мережа InfiniBand обробляє комунікацію між доменами NVLink. Rail-optimized топологія вирівнює шляхи InfiniBand з доменами NVLink для мінімізації трафіку InfiniBand.

Особливості впровадження

Rail-optimized розгортання вимагають ретельного прокладання кабелів для підтримки вирівнювання рейок між стійками та подами.[^14] Неправильно підключені з'єднання порушують локальність рейок, змушуючи трафік проходити через додаткові комутаторні переходи. Дисципліна управління кабелями є суттєво важливою для реалізації переваг rail-оптимізації.

Топологія зменшує вимоги до комутаторів порівняно з повною fat-tree при еквівалентному масштабі. Економія досягається за рахунок усунення крос-рейкової комутаційної ємності, яку rail-optimized робочі навантаження рідко використовують.[^15] Організації повинні переконатися, що їхні патерни робочих навантажень дійсно демонструють рейкову локальність, перш ніж переходити до rail-optimized конструкцій.

Dragonfly топологія

Dragonfly топологія організовує комутатори в групи з щільною внутрішньогруповою зв'язністю та розрідженими міжгруповими каналами.[^16] Конструкція зменшує кількість комутаторів порівняно з fat-tree, зберігаючи при цьому розумну довжину шляхів між будь-якими двома кінцевими точками.

Структура Dragonfly

Dragonfly складається з груп, кожна з яких містить кілька комутаторів, повністю з'єднаних всередині групи. Глобальні канали з'єднують кожен комутатор з комутаторами в інших групах.[^17] Будь-які дві кінцеві точки з'єднуються через не більше ніж три переходи: локальний комутатор до групового комутатора, до комутатора віддаленої групи, до призначення.

Зменшена кількість переходів знижує затримку для великомасштабних розгортань. Менша кількість комутаторів зменшує капітальні витрати та енергоспоживання. Однак dragonfly забезпечує нижчу бісекційну пропускну здатність, ніж fat-tree, що робить її більш вразливою до перевантажень за певних патернів трафіку.[^18]

Вимоги до адаптивної маршрутизації

Продуктивність dragonfly сильно залежить від адаптивної маршрутизації, яка розподіляє трафік між доступними шляхами.[^19] Статична маршрутизація концентрує трафік на конкретних каналах, спричиняючи перевантаження, тоді як інші шляхи залишаються недовантаженими. Комутатори повинні моніторити завантаженість каналів і динамічно перенаправляти трафік на менш завантажені шляхи.

NVIDIA InfiniBand підтримує адаптивну маршрутизацію, придатну для dragonfly розгортань.[^20] Ця можливість вимагає конфігурації та тестування для забезпечення відповідної реакції алгоритмів маршрутизації на патерни трафіку робочих навантажень. Неправильно налаштована адаптивна маршрутизація може працювати гірше, ніж статична маршрутизація.

Чутливість до робочих навантажень

Dragonfly підходить для робочих навантажень з локалізованими патернами комунікації, які утримують більшість трафіку всередині груп.[^21] Робочі навантаження, що генерують рівномірний випадковий трафік між усіма кінцевими точками, навантажують міжгрупові канали понад їхню ємність. Топологія добре працює для обслуговування інференсу з афінітетом запитів, але може мати труднощі з великомасштабним навчанням, що використовує глобальні колективні операції.

Організації, що оцінюють dragonfly, повинні характеризувати очікувані патерни комунікації робочих навантажень перед розгортанням. Інструменти симуляції можуть моделювати очікувану продуктивність при реалістичному трафіку, виявляючи потенційні точки перевантаження, що вимагають коригування топології.[^22]

Торові та mesh топології

Торові топології з'єднують вузли в регулярні сіткові патерни з обгортковими з'єднаннями на межах. TPU-поди Google використовують 3D-торові топології, що забезпечують прямі з'єднання між сусідами без комутації.[^23]

Прямі vs комутовані мережі

Торові мережі з'єднують кожен вузол безпосередньо з сусідами, усуваючи комутатори з комунікаційного шляху.[^24] Пряме з'єднання зменшує затримку для комунікації сусід-до-сусіда, типової для багатьох паралельних алгоритмів. Однак комунікація між віддаленими вузлами проходить через множинні проміжні вузли, збільшуючи затримку та споживаючи пропускну здатність на кожному переході.

Комутовані мережі, такі як fat-tree, забезпечують рівну затримку між будь-якими двома кінцевими точками незалежно від фізичного розміщення. Ця однорідність спрощує програмування та балансування навантаження. Торові мережі вимагають топологічно-свідомого розміщення для мінімізації комунікаційних відстаней.[^25]

Вибір розмірності

Торові топології вищої розмірності зменшують діаметр (максимальну кількість переходів) ціною збільшеної кількості з'єднань на вузол.[^26] 3D-тор з N вузлами на розмірність має діаметр 3N/2, тоді як 2D-тор має діаметр N. Вибір Google на користь 3D-тору балансує кількість з'єднань проти діаметра.

Фізичні обмеження впливають на вибір розмірності. 2D-тор природно відображається на рядки та стовпці в машинному залі. 3D-тор вимагає або штабельованих стійок, або з'єднань, що охоплюють значні відстані. Довжина кабелів у високорозмірному торі може стати проблематичною при масштабуванні.[^27]

Фреймворк вибору топології

Вибір мережевої топології вимагає оцінки характеристик робочих навантажень, вимог до масштабу, бюджетних обмежень та операційних можливостей.

Аналіз робочих навантажень

Різні робочі навантаження по-різному навантажують мережі. Навчання великих мовних моделей генерує патерни all-to-all комунікації, що вимагають високої бісекційної пропускної здатності.[^28] Обслуговування інференсу з батчингом демонструє більш локалізовану комунікацію всередині груп GPU, що обслуговують запити. Попередня обробка даних може генерувати shuffle-патерни з випадковою комунікацією.

Організації повинні профілювати очікувані робочі навантаження для розуміння патернів комунікації. Моніторинг виробничого кластера виявляє фактичні патерни трафіку для існуючих робочих навантажень. Нові типи робочих навантажень можуть вимагати оцінки на основі аналізу алгоритмів або рекомендацій постачальників.

Міркування щодо масштабу

Малі кластери з десятками GPU можуть не потребувати складної оптимізації топології. Один комутатор з високим radix, що з'єднує всі GPU, забезпечує повну зв'язність без багаторівневої складності.[^29] Вибір топології найбільш важливий для кластерів, що охоплюють сотні та тисячі GPU, де витрати на комутацію та прокладання кабелів стають значними.

Майбутнє зростання впливає на вибір топології. Fat-tree масштабується шляхом додавання leaf-комутаторів та серверів, зберігаючи повну бісекційну пропускну здатність. Dragonfly масштабується шляхом додавання груп, але може вимагати перебалансування глобальних каналів. Планування зростання дозволяє уникнути змін топології, що порушують операції.[^30]

Економічні фактори

Витрати на комутатори та кабелі значно варіюються між топологіями. Fat-tree вимагає більше комутаторів, ніж dragonfly при еквівалентному масштабі. Rail-optimized конструкції зменшують комутацію InfiniBand, але вимагають систем NVLink Switch.[^31] Повний аналіз витрат повинен включати комутатори, кабелі, оптику, електроенергію, охолодження та місце в стійках.

Операційні витрати також варіюються. Складні топології вимагають більш витончених можливостей моніторингу та усунення несправностей. Навчання операційного персоналу специфічним для топології особливостям додає витрат. Простіші топології можуть виправдовувати помірні компроміси в продуктивності через зменшення операційного навантаження.

Впровадження та розгортання

Впровадження мережевої топології вимагає ретельного планування, що охоплює фізичну інфраструктуру, конфігурацію комутації та валідаційне тестування.

Планування фізичної інфраструктури

Розгортання високошвидкісних мереж вимагає структурованого кабелювання, що підтримує тисячі з'єднань на 400 Гб/с або вище.[^32] Маршрутизація кабелів повинна мінімізувати порушення радіуса вигину та деградацію сигналу. Схеми гарячий прохід/холодний прохід повинні враховувати кабельні траси без перешкод

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