OpenAI открыла протокол для ИИ-суперкомпьютеров
Ставка на сеть, а не только на ускорители
OpenAI опубликовала технический разбор протокола MRC, Multipath Reliable Connection, предназначенного для сетей суперкомпьютеров, на которых обучают большие ИИ-модели. Материал вышел 5 мая 2026 года. Параллельно компания передала спецификацию в Open Compute Project, чтобы её могли использовать и другие участники рынка.
Для OpenAI эта тема уже вышла за рамки узкой инженерной задачи. В компании прямо связывают сетевую архитектуру с возможностью быстрее обучать frontier-модели, то есть самые крупные и ресурсоёмкие системы в своей линейке. В статье подчёркивается, что при синхронном обучении одна задержавшаяся передача данных может затормозить весь шаг вычислений и оставить часть GPU в ожидании.
По описанию OpenAI, MRC разрабатывался вместе с AMD, Broadcom, Intel, Microsoft и NVIDIA в течение двух лет. Протокол встроен в сетевые интерфейсы класса 800 Гбит/с и рассчитан на крупные кластеры, где обычные схемы маршрутизации начинают создавать слишком много точек отказа и лишнюю сложность.
Как работает MRC
Ключевая идея в том, что одна передача данных больше не привязывается к одному маршруту. MRC разбивает поток на пакеты и распределяет их сразу по сотням путей в сети. Пакеты могут приходить не по порядку, но система умеет собирать их на стороне получателя без обычных для таких сценариев издержек.
Такой подход нужен, чтобы уменьшить перегрузки в «ядре» сети. В классических конфигурациях разные потоки могут столкнуться на одном и том же канале, из-за чего растёт задержка. Для обучения больших моделей это особенно болезненно: синхронная тренировка чувствительна не к средней скорости, а к самым медленным участкам обмена.
OpenAI утверждает, что MRC умеет быстро исключать проблемные пути. Если соединение видит потерю пакета, оно считает, что маршрут мог выйти из строя, перестаёт его использовать и отправляет данные повторно. После этого система проверяет, был ли это реальный сбой или временная проблема. Для борьбы с ложными срабатываниями из-за перегрузки на принимающей стороне компания применяет packet trimming, схему, при которой сеть может передать только заголовок пакета и тем самым запросить корректную повторную отправку.
OpenAI пишет, что MRC позволяет обходить сетевые сбои на масштабе микросекунд, тогда как обычной фабрике могут потребоваться секунды или даже десятки секунд на стабилизацию.
Две ступени вместо трёх или четырёх
Отдельный акцент компания делает на топологии. Вместо того чтобы воспринимать один интерфейс на 800 Гбит/с как единый канал, OpenAI делит его на несколько более мелких линий. В приведённом примере один интерфейс соединяется с восемью разными коммутаторами и образует восемь параллельных плоскостей сети по 100 Гбит/с каждая.
Этот приём меняет саму геометрию кластера. По расчётам OpenAI, сеть с такой многоуровневой разбивкой позволяет связать около 131 тысячи GPU, используя лишь два уровня коммутаторов. Для обычной сети на 800 Гбит/с в сопоставимом масштабе понадобилось бы уже три или четыре уровня. Компания связывает с этим более низкое энергопотребление, меньшее число компонентов и больший запас по отказоустойчивости.
В гонке ИИ-инфраструктуры давно обсуждают не только новые ускорители, но и то, как вообще доставлять данные между ними без потери темпа. Здесь OpenAI показывает, что следующая точка конкуренции проходит на уровне сетевого стека: у кого лучше организован обмен между GPU, тот эффективнее использует уже купленные вычислительные мощности. Это особенно заметно на фоне сверхдорогих обучающих кластеров, где простой даже небольшой доли оборудования быстро превращается в реальную потерю времени и денег.
От динамической маршрутизации к статической
Ещё один заметный шаг, описанный в статье, касается маршрутизации. Традиционно коммутаторы сами пересчитывают доступные пути через динамические протоколы, например BGP. OpenAI решила упростить эту часть и сделала ставку на SRv6, IPv6 Segment Routing, где отправитель сам задаёт путь пакета через сеть.
Практический смысл в том, что сеть меньше зависит от сложной логики внутри самих коммутаторов. Если путь сломался, MRC просто перестаёт им пользоваться. Коммутаторам не нужно срочно перестраивать маршруты и синхронизировать это решение между собой. Для сверхкрупных кластеров такой отказ от динамики выглядит прагматично: меньше движущихся частей, меньше сценариев, в которых сама система управления сетью становится источником сбоя.
Где это уже используется
OpenAI утверждает, что MRC уже развёрнут на всех её крупнейших суперкомпьютерах с NVIDIA GB200, которые задействованы в обучении frontier-моделей. В числе примеров названы площадка Oracle Cloud Infrastructure в Абилине, штат Техас, и суперкомпьютеры Fairwater у Microsoft. Компания также сообщает, что протокол использовался при обучении нескольких моделей OpenAI на оборудовании NVIDIA и Broadcom.
В производственной эксплуатации OpenAI наблюдала множественные «подрагивания» линий связи между уровнями коммутаторов, иногда по несколько случаев в минуту, но пишет, что это не оказывало измеримого влияния на синхронное предобучение. В другом примере во время обучения недавней frontier-модели для ChatGPT и Codex пришлось перезагрузить четыре коммутатора уровня T1. По данным компании, MRC позволил сделать это без отдельной координации с командами, которые в этот момент вели обучение.
Именно здесь проходит главная проверка всей концепции. Красивые схемы в сетевых статьях встречаются часто, но OpenAI пытается доказать ценность MRC не теорией, а эксплуатацией на действующих кластерах, где ремонт линий, деградация портов и обслуживание коммутаторов происходят постоянно. Если протокол действительно сохраняет устойчивость в таких условиях, его открытие через OCP может заинтересовать не только облачных гигантов, но и тех, кто строит собственные ИИ-кластеры следующего поколения.
