Сетевые технологии суперкомпьютеров для ускорения крупномасштабного обучения ИИ05.05.2026 10:00

Обучение передовых моделей зависит от надежных сетей суперкомпьютеров, способных быстро передавать данные между графическими процессорами (GPU). Чтобы сделать этот процесс быстрее и эффективнее, OpenAI объединила усилия с AMD, Broadcom, Intel, Microsoft и NVIDIA для разработки MRC (Multipath Reliable Connection) — нового протокола, который повышает производительность и отказоустойчивость сетевой инфраструктуры GPU в крупных кластерах обучения. Мы выпустили MRC сегодня⁠ через проект Open Compute Project (OCP), чтобы сделать его доступным для всей отрасли. 

Учитывая, что более 900 миллионов человек используют ChatGPT каждую неделю, наши системы становятся ключевой инфраструктурой для искусственного интеллекта, помогая людям и компаниям по всему миру создавать продукты на базе все более мощных моделей. До созданияStargate⁠ мы совместно разрабатывали, запускали и поддерживали первые три поколения наших суперкомпьютеров, уделяя этому огромное внимание и тесно сотрудничая с нашими партнерами на протяжении нескольких лет. Этот бесценный опыт укрепил наше убеждение в том, что для эффективного использования вычислительных мощностей в масштабах Stargate и достижения нашей миссии нам необходимо переосмыслить и кардинально снизить сложность на каждом уровне стека, включая проектирование сети. 

Публикация спецификации MRC является частью общей вычислительной стратегии OpenAI: единые стандарты на ключевых уровнях инфраструктуры помогают масштабировать системы ИИ более эффективно, надежно и в рамках более широкой экосистемы партнеров. В этой статье мы подробно рассмотрим архитектуру MRC, в том числе: i) как она позволяет нам строить многоплоскостные высокоскоростные сети для обеспечения избыточности при сбоях сети, используя при этом меньше компонентов и меньшее энергопотребление; ii) как адаптивная рассылка пакетов (packet spraying) в MRC практически полностью устраняет перегрузку ядра; и iii) как наши развертывания используют статочную маршрутизацию на стороне источника для обхода сбоев и устранения целых классов сетевых проблем. В совокупности эти преимущества позволяют нам быстрее предоставлять каждому более качественные модели.

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

Эти проблемы становятся все более частыми и сложными по мере увеличения размера кластера. Это делает сетевые технологии ключевым элементом проектирования Stargate. 

Чтобы обеспечить текущий масштаб суперкомпьютеров Stargate, мы столкнулись с двумя ключевыми сетевыми задачами. Во-первых, по возможности мы должны минимизировать вероятность сетевых перегрузок. Существуют неизбежные узкие места, например, когда два графических процессора отправляют данные на один и тот же адрес одновременно. Но за пределами таких случаев мы должны избегать перегрузок на этапе проектирования. 

Во-вторых, нам необходимо минимизировать влияние сетевых сбоев на сам процесс обучения. При достаточном масштабе даже в самой лучшей сети будет наблюдаться фоновый уровень сбоев каналов и коммутаторов. Раньше единичный сбой часто приводил к сбою процесса обучения, заставляя перезапускать его из сохраненной контрольной точки или останавливать работу на многие секунды, пока сеть пересчитывала маршруты. Такие прерывания обходятся дорого как в затратах ресурсов GPU, так и во времени. При синхронном претренинге — когда множество графических процессоров на множестве компьютеров работают синхронно для обучения одной модели ИИ — это особенно заметно. Чем масштабнее выполняемая задача, тем сильнее влияние любого сбоя или обрыва канала. Такие рабочие нагрузки действуют как «усилитель сбоев», поэтому предотвращение этого стало критически важным. 

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

Для достижения такой надежности наша команда масштабирования в течение последних двух лет сотрудничала с компаниями AMD⁠, Broadcom⁠, Intel, Microsoft⁠ и NVIDIA⁠, чтобы разработать новый подход к проектированию и эксплуатации наших сетей. Результатом этой работы стала технология, которую мы назвали Multipath Reliable Connection, или MRC⁠. Это новый сетевой протокол, встроенный в новейшие сетевые интерфейсы со скоростью 800 Гбит/с, который позволяет распределять единую передачу данных по сотням путей, обходить сбои за микросекунды и использовать более простые плоскости управления сетью. 

MRC расширяет протокол RDMA over Converged Ethernet (RoCE) — стандарт ассоциации InfiniBand Trade Association (IBTA), который обеспечивает аппаратное ускорение удаленного прямого доступа к памяти (RDMA) между GPU и CPU. Он опирается на методы, разработанные консорциумом Ultra Ethernet Consortium (UEC), и дополняет их маршрутизацией на основе SRv6 для поддержки крупномасштабных сетевых фабрик ИИ.

MRC уже развернут во всех крупнейших суперкомпьютерах OpenAI на базе NVIDIA GB200, которые мы используем для обучения передовых моделей, включая наш объект с Oracle Cloud Infrastructure (OCI) в Абилине, штат Техас, и суперкомпьютеры Fairwater от Microsoft. MRC использовался для обучения нескольких моделей OpenAI, задействуя аппаратное обеспечение от NVIDIA и Broadcom. Сегодня спецификация MRC доступна в качестве вклада в проект Open Compute Project (OCP) для использования и развития сообществом. Мы выступили соавторами научной статьи, подробно описывающей наш опыт: «Отказоустойчивые сети суперкомпьютеров ИИ с использованием MRC и SRv6»⁠.

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

Вместо того чтобы рассматривать каждый сетевой интерфейс как один канал со скоростью 800 Гбит/с, мы разделяем его на несколько более мелких каналов. Например, один интерфейс может подключаться к восьми различным коммутаторам. Вместо единой сети на 800 Гбит/с вы можете построить восемь отдельных параллельных сетей или плоскостей, каждая из которых работает на скорости 100 Гбит/с. 

Это изменение оказывает огромное влияние на форму кластера. Коммутатор, способный подключить 64 порта по 800 Гбит/с, может вместо этого подключить 512 портов по 100 Гбит/с. Это позволяет построить сеть, полностью соединяющую около 131 000 графических процессоров, всего с двумя уровнями коммутаторов. Традиционная сеть на 800 Гбит/с потребовала бы трех или четырех уровней.

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

Однако всю эту диверсификацию путей бывает сложно задействовать в полной мере. Традиционные сетевые протоколы, используемые для обучения ИИ, обычно требуют, чтобы каждая передача следовала по единственному пути, гарантируя прибытие пакетов в правильном порядке. В крупной многоплоскостной сети это создает две проблемы: разные потоки могут сталкиваться на одном и том же канале, создавая перегрузку, и каждый поток может использовать только одну из доступных плоскостей. Если бы мы ничего не меняли, многоплоскостная сеть привела бы к значительным перегрузкам и снижению общей производительности.

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

Каждое соединение MRC хранит небольшой объем состояния для множества используемых им путей. Если оно обнаруживает, что какой-то путь перегружается, оно заменяет его на другой, выравнивая нагрузку по всей сети. Если пакет теряется, система выбирает безопасный вариант: она предполагает, что на этом пути мог произойти сбой, и немедленно прекращает его использование, повторно отправляя все потерянные пакеты. После отключения пути MRC отправляет тестовые пакеты (пробы), чтобы проверить, действительно ли имел место сбой, и если да, то восстановилась ли работоспособность.

Однако сбои — не единственная причина потери пакетов; другой частой причиной является перегрузка в пункте назначения. MRC справляется с этим с помощью усечения пакетов (packet trimming). Если коммутатор в противном случае отбросил бы пакет из-за перегрузки, он отсекает полезную нагрузку (payload) и пересылает в пункт назначения только заголовок, инициируя явный запрос на повторную передачу. Усечение пакетов сокращает количество ложноположительных срабатываний, когда мы ошибочно предполагаем, что потеря означает сбой пути.

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

MRC позволяет нам сделать еще один шаг в упрощении наших сетей.

Традиционно коммутаторы используют протокол динамической маршрутизации, такой как BGP (Border Gateway Protocol), для вычисления доступных путей и обхода сбоев. Но коммутаторы — это сложные устройства, работающие под управлением сложного программного обеспечения. Когда в них возникают скрытые неполадки, их бывает трудно диагностировать, и они могут вызывать сбои соединения до тех пор, пока проблема не будет устранена.

С появлением MRC динамическая маршрутизация стала менее необходимой. Если пакеты теряются на каком-то пути, MRC перестает его использовать. Мы пошли по более радикальному пути: отключили динамическую маршрутизацию и вместо этого задействовали IPv6 Segment Routing (SRv6). SRv6 позволяет отправителю напрямую указывать путь, по которому должен пройти каждый пакет через сеть. Это достигается путем внедрения последовательности идентификаторов коммутаторов в адрес назначения каждого пакета.

Если разбить этот процесс на этапы: при пересылке коммутатор проверяет, присутствует ли его собственный идентификатор. Если да, он удаляет идентификатор, смещая адрес назначения так, чтобы стал виден идентификатор следующего коммутатора. Затем коммутатор ищет этот идентификатор в таблице статической маршрутизации, которая определяет, куда отправить пакет дальше. В отличие от динамической маршрутизации, эта таблица статической маршрутизации настраивается при первоначальной конфигурации коммутатора и в дальнейшем никогда не изменяется.

MRC использует SRv6 для распыления пакетов по всем плоскостям сети, а также по множеству путей на каждой плоскости одновременно. Если путь выходит из строя, MRC просто перестает его использовать. Коммутаторам не нужно пересчитывать маршруты или делать что-то еще, кроме слепого следования статическим маршрутам, с которыми они были настроены.

Наши обучающие сети насчитывают миллионы линий связи. Хотя эти сети отличаются высоким качеством, в больших масштабах неизбежны кратковременные обрывы связи (link flaps). Во время обучения мы наблюдали случаи множественных обрывов связи каждую минуту между коммутаторами уровня 0 и уровня 1, однако MRC гарантировала, что они не оказали измеримого влияния на наши задачи синхронного преобучения. Фактически их влияние было настолько незначительным, что нам даже не потребовалось уделять первоочередное внимание срочному ремонту этих каналов.

Проблемы могут возникать не только с линиями связи. Во время обучения недавней передовой модели для ChatGPT и Codex нам пришлось перезагрузить четыре коммутатора уровня 1. Раньше перезагрузка коммутатора потребовала бы от операционной группы предельной осторожности, чтобы не нарушить процесс обучения. С MRC нам даже не пришлось координировать действия с командами, запускающими задачи обучения в кластере. То же самое касается и ремонта многих линий связи. Раньше мы согласовывали с операционными командами отключение канала при необходимости проведения обслуживания. Теперь мы можем ремонтировать каналы прямо во время их работы. Если канал работает достаточно хорошо, MRC будет использовать его. Если нет — MRC избегает его до тех пор, пока он не будет исправлен.

До появления MRC в случае сбоя соединения между сетевым интерфейсом графического процессора и коммутатором уровня 0 задача обучения завершалась бы неудачно. С MRC задача продолжает выполняться с приемлемой производительностью. Если 8-портовый сетевой интерфейс теряет один порт, максимальная скорость снижается на одну восьмую. MRC обнаруживает это, пересчитывает маршруты в обход вышедшей из строя плоскости и немедленно сообщает узлам о том, что эту плоскость не следует использовать для входящего трафика. Большинство вышедших из строя каналов восстанавливаются в течение минуты, после чего MRC возвращает плоскость в работу.

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

В конечном итоге MRC предоставляет нам три критических преимущества при масштабировании наших суперкомпьютеров.

Во-первых, технология позволяет строить многоплоскостные высокоскоростные сети для суперкомпьютеров, насчитывающих более 100 000 графических процессоров, используя всего два уровня коммутаторов Ethernet. Это обеспечивает достаточную избыточность для преодоления сетевых сбоев при меньшем энергопотреблении по сравнению с эквивалентными трех- или четырехъярусными одноплоскостными сетями.

Во-вторых, адаптивное распределение пакетов (packet spraying) в MRC обеспечивает балансировку нагрузки настолько эффективно, что в ядре сети практически не наблюдается перегрузок. Это существенно снижает разброс пропускной способности между потоками во время синхронного обучения, где устранение выбросов имеет ключевое значение для производительности. Это также означает, что когда несколько заданий совместно используют кластер, они не влияют на производительность друг друга.

Наконец, MRC использует маршрутизацию с указанием исходного маршрута SRv6 для быстрого обхода сбоев и отправки пакетов исключительно по работающим путям. Это позволяет нам использовать простую статическую плоскость управления сетью и исключить целые классы проблем динамической маршрутизации.

MRC значительно расширил наши возможности по обучению новых передовых моделей и обеспечению соответствия наших сетей амбициозным планам исследователей в области ИИ. Он обеспечивает значительное улучшение по сравнению с предыдущими подходами и помогает ускорить достижение нашей цели — надежно сделать преимущества искусственного общего интеллекта (AGI) доступными для каждого. Мы гордимся межотраслевым сотрудничеством, которое сделало это возможным.

По мере дальнейшего роста тренировочных кластеров дизайн сети все в большей степени определяет, какая часть доступных вычислительных ресурсов может быть использована на практике. MRC помогает нам обеспечивать слаженную работу графических процессоров в условиях перегрузок, сбоев каналов связи и обслуживания, которые раньше нарушали бы процесс обучения. При значительных масштабах такая надежность и эффективность — не просто приятное дополнение, а важнейшая составляющая, делающая возможным обучение синхронных передовых моделей.

Благодарности

Межотраслевое сотрудничество по-прежнему будет играть важнейшую роль в решении самых сложных задач в области ИИ. Мы признательны нашим партнерам — AMD, Broadcom, Intel, Microsoft и NVIDIA — за участие в разработке MRC, а также компаниям Microsoft Azure, OCI, NVIDIA и Arista за совместную работу по его внедрению в масштабе всей системы. Мы разделяем общую приверженность развитию экосистемы и с нетерпением ждем того, как индустрия применит MRC в будущем.