Простішi комутатори, швидші моделі: як MRC змінює суперкомп’ютери для AI
OpenAI тренує свої найновіші фронтирні моделі на кластерах із тисячами найшвидших у світі GPU. Щоб така система працювала як єдиний «мозок», мережа між чипами має бути настільки ж надійною й передбачуваною, як самі обчислення. У розмові на OpenAI Podcast інженери Марк Гендлі (core networking) та Грег Штайнбрехер (workload systems) пояснюють, як новий мережевий протокол Multipath Reliable Connection (MRC), розроблений OpenAI разом з AMD, Broadcom, Intel, Microsoft та Nvidia, радикально спростив мережеву інфраструктуру, покращив досвід дослідників і тепер виноситься в статус відкритого стандарту через Open Compute Project.
Цей матеріал зосереджується на тому, як MRC змінює архітектуру дата-центрів, чому OpenAI відмовляється від динамічної маршрутизації в найбільших кластерах, як це відчувають дослідники, та чому відкритий стандарт може прискорити появу нових, потужніших моделей для всіх користувачів.
Інтелект на краях: чому OpenAI спростила «серце» мережі
Класичні дата-центри, побудовані за лекалами інтернету, покладаються на «розумні» комутатори в ядрі мережі. Вони запускають складні динамічні протоколи маршрутизації, постійно обмінюються службовими повідомленнями, перебудовують таблиці маршрутів при кожній відмові лінка чи зміні топології. Для веб-сервісів це працює: трафік від мільйонів користувачів статистично «усереднюється», а короткі збої майже непомітні.
У великих AI-кластерах ситуація протилежна. Тисячі GPU рухаються в жорсткому такті, виконуючи одну велику синхронну обчислювальну задачу. Один повільний або «невдалий» шлях у мережі може сповільнити весь крок тренування. Саме тому OpenAI пішла іншим шляхом: замість ще більш «розумних» комутаторів компанія перенесла більшість мережевої логіки на кінцеві точки — самі GPU-сервери.
MRC побудований так, щоб ядро мережі залишалося максимально простим і статичним. Комутатори в MRC-кластерах не приймають складних рішень у реальному часі, не перераховують маршрути при кожній події. Вони працюють як високошвидкісні, але відносно «тупі» переспрямовувачі пакетів, які виконують наперед визначені інструкції.
Натомість «інтелект» переміщується на кінці: саме хости, що запускають тренування моделей, обирають шляхи, відстежують якість маршрутів, обходять відмови й балансують навантаження. Така інверсія ролей — від «розумного ядра й простих країв» до «простого ядра й розумних країв» — і є ключовою архітектурною зміною, яку приносить MRC.
Статична маршрутизація замість протоколів, що «дрижать» при кожній відмові
Одним із найрадикальніших наслідків впровадження MRC стало те, що OpenAI змогла відмовитися від динамічних протоколів маршрутизації в найбільших кластерах. У традиційних мережах саме ці протоколи — на кшталт BGP чи внутрішніх IGP — відповідають за те, щоб мережа «перебудовувалася» при відмовах лінків або комутаторів. Але кожна така перебудова має ціну: секунди або десятки секунд конвергенції, протягом яких маршрути нестабільні, а пакети можуть губитися або йти в обхід.
Для веб-сервісів це неприємно, але терпимо. Для синхронного тренування AI-моделей, де тисячі GPU чекають одне на одного, кілька секунд паузи — це вже відчутна втрата продуктивності й грошей. Саме тут MRC змінює правила гри.
У MRC-мережах комутатори завантажуються зі статичними таблицями маршрутизації, які не змінюються під час роботи. Вони не запускають динамічні протоколи, не обмінюються оновленнями, не намагаються «зрозуміти», що відбувається в сусідніх вузлах. З погляду мережевого інженера це майже повернення до епохи жорстко прописаних маршрутів, але на масштабах сучасних суперкомп’ютерів.
Ключ у тому, що MRC не покладається на те, що мережа сама «зрозуміє», куди треба спрямувати трафік. Кожен пакет несе в собі явний маршрут, а кінцеві точки самі вирішують, якими шляхами йти. OpenAI використовує для цього IPv6 segment routing: у заголовку пакета закодовано послідовність комутаторів, через які він має пройти. Комутатору не потрібно «думати» — він просто читає наступний сегмент і пересилає далі.
Це дозволяє зробити поведінку мережі набагато більш передбачуваною. Відмовив лінк чи комутатор — статична таблиця в ньому не зміниться, але й не потрібно, щоб змінювалася. Кінцеві точки самі виявлять, що певний шлях більше не працює, і перестануть його використовувати. Мережа перестає «дрижати» при кожній події, а великі тренування не зупиняються через затримки конвергенції.
Як MRC змінює досвід дослідників: «ми виграли, коли вони перестали думати про мережу»
Для команд, які будують протоколи й мережеві стекі, MRC — це складна інженерна система. Але для дослідників, що тренують моделі, ідеальний результат виглядає дуже просто: вони взагалі не повинні знати, який протокол працює під капотом.
Саме цього ефекту OpenAI прагнула досягти, і за внутрішніми оцінками компанії MRC суттєво наблизився до цієї мети. Стабільність GPU-кластерів з точки зору дослідників помітно зросла. Тренування менше перериваються через мережеві збої, менше «зависають» на окремих кроках через повільні або перевантажені шляхи, менше вимагають ручного втручання.
Раніше мережа була одним із головних джерел болю для команд, що відповідають за великі тренування. Інженери workload systems і мережеві фахівці перебували «на телефоні» під час запуску великих експериментів, готуючись до нічних викликів у разі збоїв. MRC проєктувався з урахуванням цієї реальності: мета полягала не лише в підвищенні пропускної здатності, а й у зменшенні кількості інцидентів, які взагалі доходять до людей.
Перенесення логіки на кінцеві точки, мультишляхова передача, швидке виявлення відмов — усе це в сумі означає, що більшість проблем тепер «гаситься» автоматично на рівні протоколу. Для дослідника це виглядає як проста річ: запуск тренування стає більш передбачуваним, а мережа перестає бути фактором, про який потрібно думати щодня.
Абстракція над стійками: коли неважливо, де саме запущено ваші GPU
Ще одна важлива зміна, яку приносить MRC, стосується того, як користувачі взаємодіють із кластерами. У великих AI-системах розміщення задачі — на якій стійці, в якому сегменті мережі, поруч із якими сусідніми задачами — може суттєво впливати на продуктивність. Якщо мережа поводиться непередбачувано, дослідникам доводиться думати про «гарні» та «погані» місця в кластері, уникати певних зон, враховувати можливі конфлікти за пропускну здатність.
MRC покликаний зняти значну частину цих турбот. Завдяки тому, що протокол розподіляє трафік по багатьох шляхах, швидко обходить відмови й не покладається на «щасливий» вибір маршруту, користувачі можуть запускати задачі, не замислюючись, у якій саме стійці опинилися їхні GPU або які сусідні завдання працюють поруч.
Фактично MRC надає більш сильну абстракцію: кластер сприймається як єдиний, відносно однорідний ресурс, а не як мозаїка з «гарячих» і «холодних» зон. Планувальники робіт і системи розподілу навантаження можуть оперувати на рівні логічних ресурсів, не вбудовуючи в себе складні евристики про топологію мережі й можливі «вузькі місця».
Це важливо не лише для зручності. Коли дослідники не змушені оптимізуватися під особливості конкретного кластера, вони можуть швидше переносити експерименти між середовищами, масштабувати їх на більші ресурси й повторно використовувати конфігурації. А інфраструктурні команди отримують більше свободи в тому, як саме будувати й розширювати кластери, не ламаючи користувацькі очікування.
Зняття бар’єрів масштабування: MRC як умова для наступних поколінь моделей
Зі зростанням розмірів моделей і кластерів кожен новий рівень масштабування впирається в конкретні технічні бар’єри. Для OpenAI мережа була одним із таких вузьких місць: синхронні тренування на тисячах GPU робили систему чутливою до найменших збоїв, а традиційні мережеві підходи, успадковані від інтернету, дедалі гірше відповідали цим вимогам.
У компанії прямо говорять, що MRC дозволив прибрати один із ключових бар’єрів для подальшого масштабування фронтирних моделей. Це не означає, що всі проблеми вирішено, але саме мережа перестала бути настільки жорстким обмеженням, як раніше. Замість того, щоб витрачати значну частину інженерного ресурсу на обхід мережевих недоліків, команди можуть зосередитися на інших аспектах — від оптимізації самих моделей до покращення систем розподілу навантаження.
Очікування OpenAI полягає в тому, що MRC дозволить тренувати фронтирні моделі швидше й надійніше. Менше пауз через відмови, менше «хвостів» у часі завершення кроків тренування, менше перезапусків великих експериментів через мережеві інциденти — усе це безпосередньо скорочує час від ідеї до готової моделі.
У практичному вимірі це означає, що користувачі можуть отримувати нові, більш здатні моделі швидше. Якщо мережа перестає бути «пляшковим горлом», цикл «дослідження → масштабний експеримент → продуктова інтеграція» стискається. Для компанії, яка працює на межі можливого в AI, це перетворюється на конкурентну перевагу, але водночас і на фактор, що прискорює прогрес у всій галузі.
Від внутрішнього протоколу до відкритого стандарту через OCP
Ще один принциповий аспект MRC полягає в тому, що OpenAI не залишає його внутрішньою технологією. Протокол розроблявся у співпраці з великими гравцями індустрії — AMD, Broadcom, Intel, Microsoft та Nvidia — і вже використовується в продакшн-дата-центрах для тренування реальних моделей.
Наступний крок — стандартизація через Open Compute Project (OCP) як відкритого стандарту для ширшої індустрії. Це важливий сигнал: мова йде не про пропрієтарне рішення, прив’язане до одного вендора чи одного хмарного провайдера, а про спробу сформувати спільну базу для мереж наступного покоління, орієнтованих на AI.
Відкритий стандарт має кілька наслідків. По-перше, він дозволяє постачальникам обладнання — від виробників комутаторів до постачальників мережевих чипів — оптимізувати свої продукти під конкретні вимоги MRC, знаючи, що це не нішеве рішення однієї компанії. По-друге, він знижує ризики для організацій, які захочуть впроваджувати MRC у власних кластерах: наявність специфікацій і сумісних реалізацій робить технологію більш передбачуваною й довгостроковою.
По-третє, відкритість створює можливість для еволюції протоколу спільними зусиллями. Досвід різних компаній, що тренують великі моделі, може виливатися в покращення стандарту, нові механізми й оптимізації. З огляду на те, що MRC побудований поверх Ethernet і розрахований на масштабування разом зі зростанням швидкостей і можливостей Ethernet-мереж, така колективна еволюція виглядає особливо важливою.
У підсумку MRC стає не лише внутрішнім інструментом OpenAI, а й потенційною основою для того, як у найближчі роки будуть виглядати мережі суперкомп’ютерів для AI у всій індустрії.
Висновок: мережа, про яку не потрібно думати
Multipath Reliable Connection — це не просто ще один протокол у довгому списку мережевих інновацій. Для OpenAI він став способом переосмислити саму роль мережі в AI-суперкомп’ютерах: від складної, крихкої системи, яка постійно вимагає уваги, до більш простої, статичної інфраструктури, поверх якої працює «розумний» край.
Перенесення інтелекту на кінцеві точки, статичні таблиці в комутаторах, відмова від динамічної маршрутизації в найбільших кластерах, краща стабільність для дослідників і абстрагування від деталей розміщення — усе це разом знімає один із ключових бар’єрів на шляху до ще більших моделей. А відкриття MRC як стандарту через Open Compute Project створює можливість, що подібний підхід стане нормою для всієї індустрії.
У світі, де швидкість і надійність тренування фронтирних моделей дедалі більше визначають темп прогресу в AI, мережа, про яку можна не думати, виявляється однією з найважливіших інновацій.