OpenAI представила MRC: протокол сетей для суперкомпьютеров и ускорения масштабного обучения ИИ

Прослушать статью

5 мая 2026 года

OpenAI представила MRC (Multipath Reliable Connection) — новый сетевой протокол для суперкомпьютеров, созданный для повышения надежности и производительности в кластерах, где обучаются крупные модели ИИ. В OpenAI отмечают, что при более чем 900 млн пользователей ChatGPT каждую неделю их системы все больше становятся базовой инфраструктурой для ИИ, а масштаб Stargate требует радикального упрощения и перестройки каждого слоя стека, включая сетевую архитектуру.

Публикация спецификации MRC является частью общей стратегии OpenAI по вычислениям: общие стандарты в ключевых инфраструктурных слоях помогают масштабировать ИИ-системы эффективнее, надежнее и с участием более широкой экосистемы партнеров. В этом материале компания описывает, как MRC позволяет строить многоплоскостные высокоскоростные сети с избыточностью для переживания сбоев, но с меньшим числом компонентов и меньшим энергопотреблением; как адаптивное «распыление» пакетов MRC почти устраняет перегрузку ядра сети; и как в развертываниях используется статическая source routing, чтобы обходить сбои и устранять целые классы отказов маршрутизации. По словам OpenAI, вместе эти преимущества позволяют быстрее доставлять более качественные модели пользователям.

Почему сети потребовали нового дизайна

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

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

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

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

Наш ответ: MRC

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

MRC расширяет RDMA over Converged Ethernet (RoCE) — стандарт InfiniBand Trade Association (IBTA), который обеспечивает аппаратно ускоренный remote direct memory access между GPU и CPU. Протокол опирается на методы, разработанные Ultra Ethernet Consortium (UEC), и дополняет их source routing на базе SRv6, чтобы поддерживать крупномасштабные ИИ-сетевые фабрики.

Основа: многоплоскостные сети

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

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

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

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

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

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

При одно-путевых потоках, как в классическом развертывании RoCE, отдельные линии часто перегружаются. Поскольку collective communications чувствительны к худшей задержке, это особенно мешает нагрузкам обучения ИИ.

Потоки пакетов сталкиваются и вызывают перегрузку. Анимация: Mark Handley.

Сдвиг MRC: распыление пакетов по сотням путей

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

MRC распределяет пакеты сразу по множеству путей, снижая перегрузку, которая может замедлять synchronous AI training.

Распределяя трафик по множеству путей, MRC избегает горячих точек в сети, предотвращая ситуации, когда одни транзакции занимают намного больше времени, чем другие. Это устраняет замедления, влияющие на synchronous AI training.

Распыление пакетов по нескольким путям. Анимация: Mark Handley.

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

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

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

Замена динамической маршрутизации source routing

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

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

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

SRv6 позволяет отправителю закодировать полный путь, по которому пакет должен пройти через сеть. Поскольку это детерминированно, отправитель может независимо реагировать на перегрузку или потерю на конкретном пути.

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

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

Суперкомпьютер Stargate, построенный Oracle Cloud Infrastructure (OCI) в Абилине, Техас

Как это выглядит в продакшене

В обучающих сетях OpenAI — миллионы линий. Хотя эти сети очень качественные, при достаточном масштабе кратковременные обрывы линий неизбежны. Во время обучения компания наблюдала случаи нескольких таких обрывов каждую минуту между коммутаторами Tier 0 и Tier 1, но MRC обеспечил, что это не оказало измеримого влияния на synchronous pretraining jobs. Более того, влияние было настолько небольшим, что даже не потребовалось срочно приоритизировать ремонт этих линий.

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

Реальные данные, записанные во время обучения, показывают, как MRC реагирует на полную потерю коммутатора T1. Обучающая задача испытала кратковременное замедление, но быстро восстановилась.

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

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

Ключевые улучшения

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

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

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

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

Открытие протокола

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

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

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

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

ИИ для бизнеса