Привет, меня зовут Борис Хасанов, я сетевой архитектор в MWS Cloud Platform. 

Решил поделиться с вами обзором новой технологии MRC* для создания сетей для  AI/ML-кластеров, так называемых backend networks. Технология интересная и перспективная — там есть магия SRv6 :)

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

* MRC — Multipath Reliable Connection, расширение RoCE-архитектуры, предложенное коллегами из OpenAI, Microsoft, Nvidia, AMD, Broadcom. Недавно вышло несколько англоязычных публикаций с его анонсом. Вот одна из них на сайте OpenAI.

Масштабирование предобучения LLM и ловушка хвостовой задержки

Производительность синхронных задач (jobs) по предобучению (pretraining) LLM на очень больших масштабах со множеством вовлечённых GPU и комбинаций из pipeline parallelism, data parallelism, tensor parallelism и expert parallelism определяется хвостовой задержкой (tail latency). 

Предобучение LLM — начальное обучение модели на гигантских неразмеченных данных: текстах, изображениях, видео, чтобы получить фундаментальные знания о структуре языка, закономерностях, логике, фактах и прочем.

Предобучение важно для LLM, потому что:

• позволяет использовать колоссальные объёмы доступных неразмеченных данных, например из интернета;

• даёт хорошую начальную инициализацию весов модели — без неё обучить огромную модель с нуля на маленькой размеченной выборке практически невозможно;

• потребляет 99% вычислительных ресурсов в жизненном цикле модели.

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

• каждый ускоритель обрабатывает свою порцию данных (микробатч) — вычисляет градиенты;

• ускорители обмениваются градиентами, обычно через all-reduce, и усредняют их;

• все одновременно применяют одинаковые усреднённые градиенты к весам модели;

• никто не переходит к следующей итерации, пока все устройства не завершат текущую итерацию.

Основные преимущества синхронных задач:

• Гарантированная сходимость и воспроизводимость. 

• Простота использования эффективных алгоритмов. 

• Стабильность скорости сходимости.

Хвостовая задержка (tail latency) — это задержка обработки запроса или выполнения операции на определённом проценте самых медленных вызовов, обычно на последних 1, 5 или 0,1% (99, 95 или 99,9-й перцентиль).

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

Что с этим делать

Коллеги предложили следующий трёхэтапный подход для преодоления проблем, возникающих при синхронных задачах предобучения LLM:

• Новый транспортный протокол для RDMA — MRC для «распыления» (spraying) потоков трафика между множеством путей и балансировки между ними.

• Многоплоскостные (multi-plane) Clos-топологии (100K GPU-кластер на двух уровнях Clos-фабрики).

• Статический SRv6 для детерминированного задания путей через множество физически доступных путей в фабрике и обхода (bypass/безболезненного убирания) вышедших из строя линков или узлов.

Основные цели такой архитектуры:

• Равномерная балансировка трафика между путями для предотвращения перегрузок линков.

• Обработка перегрузок, вызванных incast-эффектом (трафик от многих к одному) без выбросов (аномалий, outliers).

• Корректная обработка выхода из строя линков и узлов фабрики без остановки процесса обучения.

• Максимальное упрощение control plane для минимизации действий при выходе из строя или поиске неисправностей и максимальной автоматизации работы фабрики при наступлении таких событий.

Рассмотрим компоненты предлагаемой архитектуры (протокол MRC, многоплоскостной дизайн фабрики, статический SRv6) подробнее.

Протокол MRC (Multiple Reliable Connections)

В отличие от UET, MRC — минимальное расширение RoCE и опирается на существующий RoCE Verbs API, поддерживается Queue Pair (QP) и расширяет его, но AI-задачам требуется лишь часть его функциональности, поэтому на транспортном уровне поддерживаются только операции RDMA Write и Write-with-Immediate (Read, Send and Atomic operations are not supported — MRC-спецификация в ОСР с.19 https://www.opencompute.org/documents/ocp-mrc-1-0-pdf).

Операции MRC и используемые RoCE-заголовки

Модификация заголовка BTH

MRC предполагает некоторые модификации стандартного BTH заголовка RoCE:

• Добавлено поле rtx — для индикации повторной передачи — ретрансмит.

• Добавлено поле TSETH — для индикации одноимённого заголовка, используется для измерения RTT — подробнее ниже.

Логика сокращения операций в MRC

Почему же в MRC выбрали только эти две операции?

Сетевая архитектура MRC оптимизирована под специфику распределённого обучения ИИ, где параметры тензоров и адреса буферов известны заранее. Выбор в пользу односторонних операций RDMA Write и Write with Immediate (push-модель) обусловлен отказом от механизмов, которые создавались для классического динамического HPC-трафика, но в ИИ-сетях приносят лишь избыточную нагрузку.

• Отказ от Send/Recv. В традиционных HPC-средах эти операции нужны для передачи пакетов произвольного размера, когда получатель должен динамически выделять память под каждое входящее сообщение. В AI-кластерах это избыточно: адреса буферов согласуются один раз при инициализации, а пошаговое вовлечение CPU-приёмника в координацию передачи лишь увеличивает задержку.

• Отказ от RDMA Read. В отличие от операции Write, которая доставляет данные на удалённый узел за половину цикла RTT, операция Read требует полноценного RTT — сначала для отправки запроса на чтение и только затем для возврата самих данных. В условиях синхронного обучения ИИ, чувствительного к задержкам, такой подход неэффективен.

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

Например:

• Кольцевой All‑Reduce — каждое устройство отправляет свою порцию данных следующему по кольцу через RDMA Write, не ожидая подтверждения от получателя.

All‑to‑All (в MoE-моделях) — при экспертном параллелизме токены должны быть перераспределены между всеми GPU; push-модель позволяет каждому GPU напрямую записывать токены в буферы нужного эксперта на удалённых узлах. Использование исключительно односторонних операций записи порождает проблему координации: при чистом RDMA Write удалённый узел не получает уведомлений о поступлении данных, что может привести к переполнению буферов или преждевременному началу вычислений. 

Архитектура MRC решает эту задачу с помощью операции Write with Immediate:

• Аппаратная доставка данных. Сами данные, тело тензора, записываются напрямую в удалённую память (HBM/память GPU) силами сетевой карты, минуя центральный процессор, как и в обычном Write.

• Аппаратное уведомление (Immediate Data). Вместе с данными отправитель передаёт небольшой 32-битный флаг, например индекс буфера или номер шага. При завершении транзакции сетевая карта получателя автоматически помещает этот флаг в очередь завершения (Completion Queue — CQ).

• Асинхронный контроль потока. Прокси-процесс на CPU или выделенное коммуникационное ядро на GPU (GPU kernel) опрашивает CQ путём непрерывного сканирования (polling). Появление флага служит мгновенным сигналом: данные доставлены, буфер заполнен, можно безопасно запускать следующую стадию вычислений.

Такой подход позволяет MRC реализовать строгий кредитный метод контроля потока (Credit-based Flow Control). Отправитель не начнёт следующую операцию Write, пока через обратное уведомление, также отправленное как Write with Immediate, не получит «кредит» — подтверждение от получателя, что целевой буфер полностью обработан и снова свободен. Напоминаю, что аналогичный кредитный механизм (Receiver-driven Credit-based Congestion Control — RCCC) также используется и в UET в подуровне Congestion Management в Transport Layer.

Как и UET, MRC использует распыление пакетов (packet spraying), адаптивную балансировку нагрузки на основе ECN, допускает приём пакетов не по порядку (out of order packet delivery), внеочередное размещение полученных данных в памяти ( out of order memory placement), выборочную повторную передачу, а также обрезку пакетов (packet trimming) — ключевой механизм для снижения негативного incast-эффекта.

На уровне протокола основные возможности, добавляемые MRC, заключаются в следующем:

• Прямая запись независимо от порядка пакетов: каждый пакет данных содержит виртуальный адрес RDMA и удалённый ключ (remote key), благодаря чему принимающая сетевая карта (NIC) может немедленно записать каждый прибывающий пакет в память, независимо от порядка их поступления.

• Распыление пакетов (packet spraying) для балансировки нагрузки: каждый пакет содержит энтропийное значение (EV, entropy value), которое определяет его путь в сети (EV — путь через определённую плоскость). 32-битное EV в пакете MRC распределяется между полями UDP source port и IPv6 flow label. При запуске QP отправитель генерирует для этого QP набор EV — обычно от 128 до 256 значений. Затем отправитель циклически перебирает этот набор, используя для каждого пакета новое EV, так что все пакеты одного QP распыляются по множеству путей во всех плоскостях многоплоскостной сети (multi-plane network) прозрачно для самого приложения. 

• Отказ от PFC → переход на lossy Ethernet: распыление пакетов плохо сочетается с механизмом Priority Flow Control (PFC), который применяется в lossless Ethernet, поскольку один поток может разойтись в фабрике через сотни путей. Более того, PFC часто создаёт блокировку (head‑of‑line blocking) между разными коллективными операциями, увеличивая хвостовую задержку (tail latency), поэтому MRC отключает PFC и использует Ethernet в режиме best‑effort (lossy).

• Быстрое восстановление потерь: сочетание best‑effort Ethernet и внеочередной доставки (out‑of‑order delivery) повышает требования к скорости восстановления потерь. MRC реализует быструю выборочную повторную передачу (fast selective retransmission), используя пакеты выборочных подтверждений (Selective ACK, SACK) для точного указания, какие пакеты достигли получателя.

• Обрезка пакетов (packet trimming) против incast: для дальнейшего увеличения скорости передачи, особенно в условиях incast, MRC применяет обрезку пакетов (packet trimming). При обрезке пакет, который был бы отброшен из‑за перегрузки, лишается полезной нагрузки (остаётся заголовок) и с приоритетом пересылается получателю. Принимающая NIC генерирует NACK, инициируя быструю повторную передачу. Это также позволяет MRC отличать потери из-за перегрузки от других потерь пакетов, которые в кластерах ИИ в основном связаны с флапами (flaps) и отказами линков.

MRC, для увеличения энтропии, генерирует EV-set — множество (набор, пул) эквивалентных EV-значений для каждой плоскости, что немедленно выравнивает трафик между плоскостями в фабрике. 

ECN как сигнал для балансировки

MRC для каждого EV хранит состояние пути (GOOD, SKIP, ASSUMED_BAD, DENIED), устанавливаемое в EV:

• GOOD: путь исправен и может использоваться для передачи данных. При старте QP все EV по умолчанию находятся в этом состоянии.

• SKIP: путь временно перегружен. Отправитель на неопределённое время избегает его использования, чтобы дать возможность очереди рассосаться. Это прямая реакция на полученный ECN-сигнал (SKIP_ONCE).

• ASSUMED_BAD: путь считается нерабочим (неисправным), например после тайм-аута или потери нескольких пакетов. Отправитель перестаёт его использовать, но периодически отправляет фоновые пробы EV Probes, чтобы проверить, не восстановился ли путь.

• DENIED: путь запрещён административно, отправитель никогда его не использует. Этот переход инициируется не сигналами от получателя (как в случае с SKIP или ASSUMED_BAD), а управляющей плоскостью (MRC Controller).

Таким образом, MRC использует ECN как механизм явного уведомления о перегрузке. Коммутатор при перегрузке не отбрасывает пакет, а «помечает» его — устанавливает биты в IP-заголовке, чтобы получатель знал о перегрузке.

Получатель отражает ECN-сигнал обратно отправителю, указывая, что этот конкретный путь перегружен сильнее других, и отправитель временно избегает его (SKIP). Разные отправители в MRC не синхронизируются при выборе своих наборов EV. Суммарный трафик может быть слегка неравномерным, хотя каждый отправитель хорошо балансирует нагрузку индивидуально. Балансировка на основе ECN сглаживает эту неравномерность, не позволяя внутренним очередям разрастись до такой степени, чтобы вызвать потери из-за перегрузки.

Если пакет не был обрезан (trimmed), а действительно потерян, MRC предполагает, что путь потерян (ASSUMED_BAD), и немедленно прекращает использовать соответствующее EV. 

Разумеется, не все потери вызваны отказами путей (линков) — пакеты могут страдать от битовых ошибок или других проблем, — поэтому окончательное удаление EV после одной потери может оставить нас без достаточного количества рабочих EV. Чтобы избежать этого, MRC отправляет фоновые пробы путей (background path probes), чтобы определить, действительно ли плохи эти пути, а также обнаружить, восстановились ли отказавшие линки. Если достаточное количество проб успешно проходит, EV реанимируется — путь снова становится хорошим (GOOD).

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

Сводная таблица реакции MRC на различные события

Многоплоскостной дизайн IP-фабрики для AI-кластера

Классический дизайн

Коллеги рассматривают в качестве примера гипотетический кластер на 100 000 GPU (да, мы не ослышались — сто тысяч GPU). Каждый GPU подключается к сети через один сетевой адаптер (NIC) на 800 Гбит/с.

Мы хотим достичь полной бисекционной пропускной способности (full bisection bandwidth), чтобы упростить размещение вычислительной нагрузки. Один из вариантов — обычная трёхуровневая топология Clos с использованием самых быстрых современных Ethernet-коммутаторов (64х800G — 51,2 Тбит/с).

Коммутаторы для AI-фабрики в таком дизайне делятся на уровни: T0, T1, T2. К коммутаторам T0 подключаются NIC (32 штуки) — это соответственно ToR/Leaf. T1 — Spine, T2 — Superspine. 

Для организации масштабирования и соответственно количеству портов коммутаторов (radix) мы делим сеть на PoDы, где каждый PoD состоит из 32 коммутаторов Т0 и 32 коммутаторов Т1, всего в один PoD мы можем подключить 1024 NIC (GPU). И наконец, каждый коммутатор Т2 подключается к 64 PoDам, получаем общий размер кластера в 64К NIC (GPU). Как говорится — неувязочка. Соответственно, если нам нужно 100 000 GPU, то надо либо добавлять 4-й уровень коммутации — это, конечно, возможно, но существенно увеличит стоимость решения и задержку, а также потребление электроэнергии и добавит сложности в управлении. Либо делать переподписку, чего очень не хочется делать в случае AI-backend сети, либо делать дизайн со многими независимыми рельсами (rails). 

Альтернативный дизайн AI-фабрики для MRC

В этом дизайне мы делим 800 Гбит/с NIC по линиям (lane) и используем его как 8 портов по 100 Гбит/с. Далее строим восемь параллельных 100 Гбит/с плоскостей Clos, используя те же коммутаторы на 51,2 Тбит/с, но теперь каждый коммутатор имеет 512 портов 100 Гбит/с — radix стал 512 вместо 64, как в предыдущем дизайне. 

Теперь каждый коммутатор T0 подключает снизу 256 портов к NIC, а сверху — 256 коммутаторов T1. Каждый коммутатор T1, в свою очередь, подключает снизу 512 коммутаторов T0, что даёт сеть из 131 072 GPU. В такой конфигурации мы легко можем разместить наши 100 000 GPU, используя только два уровня коммутаторов. Такая многоплоскостная сеть имеет много преимуществ:

• Меньшая задержка, потому что самый длинный путь проходит только через три коммутатора, а не через пять или семь.

• Гораздо больше узлов достижимо за один hop (256 вместо 32), поэтому проще использовать локальность (locality) в задаче, что снижает задержку и уменьшает нагрузку на восходящие линки T0.

• Снижаются стоимость и энергопотребление — для полной бисекционной пропускной способности нам требуется 2/3 оптики и 3/5 количества коммутаторов по сравнению с трёхуровневой сетью (т. к. мы целиком убираем уровень Т2).

• Влияние отказа внутри сети гораздо меньше. Например, потеря линка T0–T1 снижает пропускную способность от узла на 3% в 800‑гигабитной плоскости против 0,4% в 100‑гигабитной плоскости (1/31 vs 1/256).

• Можно потерять линк NIC–T0 без остановки задачи обучения. Мы всё равно теряем 12% пропускной способности NIC (1/8) в этом случае, но легко переживаем флап линка, используя оставшуюся ёмкость.

Таким образом, многоплоскостная топология имеет много преимуществ перед одноплоскостной, однако есть и обратная сторона медали:

• Во-первых, нагрузка должна быть способна переживать отказы линков и портов NIC.

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

Именно здесь на сцену выходит транспортный протокол MRC, который рассмотрели выше.

Сравнение двух дизайнов

Статический SRv6 — третий «кит» MRC

Динамическая маршрутизация: быть или не быть

В традиционной сети ЦОДов используется тот или иной протокол динамической маршрутизации, например, у нас в MWS Cloud Platform — BGP. Его задачи — определять достижимость IP-префиксов, находить к ним оптимальные пути и в случае отказа линка или оборудования оперативно перенаправлять трафик в обход. Это занимает определённое время (детектирование отказа, распространение информации о нём, пересчёт достижимости — сходимость сети). 

К сожалению, двухуровневые топологии с большим радиксом, как в нашем примере с 512 портами из предыдущей таблицы, сильно усложняют маршрутизацию. Каждому адресату соответствует большой набор ECMP (большая ECMP-группа) — до 256 записей в 512-портовом коммутаторе T0, по одной на каждый аплинк. При отсутствии отказов — это не проблема, конечно, если коммутатор поддерживает такую ECMP-группу. Но у большинства коммутаторов T1 может быть хотя бы один отказавший нисходящий линк. В результате конкретный адресат становится недостижимым через некоторые T1 и коммутатор T0 не может использовать набор ECMP по умолчанию, сбалансированный по всем аплинкам. 

Количество больших групп ECMP, требуемых в каждом T0, приближается к общему числу коммутаторов T0 — дополнительный параметр, который надо поверять при выборе коммутаторов. Поддержание такого количества больших наборов ECMP создаёт высокую нагрузку на control plane и, что критичнее, на ASIC коммутаторов. Диагностика проблем маршрутизации на большом масштабе также сложна.

Учитывая, что протокол MRC будет быстро обходить отказавшие пути, как было показано выше, и то, что в MRC используются избыточные (многоплоскостные) топологии, нужна ли вообще динамическая маршрутизация? 

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

Протокол MRC реагирует на отказ первым, избегая отказавшего пути (ASSUMED_BAD); затем динамическая маршрутизация перестраивает маршруты, изменяя ECMP и нарушая балансировку. Можно сравнить это с часами, стрелки которых двигают два разных часовых механизма: 

• Один (MRC) — очень быстрый, он корректирует стрелки каждую микросекунду, чтобы они точно показывали время.

• Второй (BGP) — медленный, но грубый: он раз в минуту берёт стрелки и переставляет их на час вперёд или назад.

В результате стрелки никогда не стоят на месте и часы показывают бессмысленные значения. 

Авторы архитектуры MRC заняли позицию, что при работе MRC динамическая маршрутизация создаёт больше проблем, чем решает, поэтому они просто исключили её. Парадоксальная идея. Возникает вопрос: как без динамической маршрутизации нам отображать значения EV на конкретные пути?

Один из возможных вариантов — запустить MRC со статически сконфигурированными ECMP-маршрутами, полагаясь на MRC в обходе плохих путей. Проблема этого варианта в том, что в нём нет простого отображения энтропии EV на физический путь. Например, если MRC пометил какой-то EV как «плохой», инженер не сможет точно определить, какой именно линк в фабрике отказал, чтобы устранить проблему.

Segment Routing over IPv6 (SRv6) — закрывает пазл в архитектуре MRC

Авторы вспомнили, что есть технология Segment Routing, которая позволяет явно описывать путь пакета в сети от узла источника до узла назначения в виде списка сегментов (Segment List, состоящий из идентификаторов узлов, т. н. сегментов или SID). Они выбрали подход: использовать Segment Routing over IPv6 (SRv6, RFC 8986). 

SRv6 — позволяет использовать разные форматы IPv6 SID; для MRC используется формат micro-segment SID (uSID или NEXT-CSID flavor, RFC 9800 ), где IPv6-адрес назначения состоит из 32-битного префикса локатора, за которым следует последовательность 16-битных uSID (т. н. формат F3216 (32-битный блок + 16-битные uSID, общая длина локатора 48 бит)), каждый из которых соответствует конкретному коммутатору вдоль пути. MRC использует uSID под названием uN (micro Node SID), где каждый коммутатор вдоль пути явно именован.

Когда поступает IPv6-пакет, коммутатор выполняет поиск по самому длинному совпавшему префиксу (Longest Prefix Match, LPM) по адресу назначения, чтобы определить, предназначен ли он для обработки в рамках SRv6. Для этого он сравнивает адрес со своим сконфигурированным локатором. Если совпадение найдено, пакет считается корректным SRv6-пакетом для обработки (шаг 1). 

Далее коммутатор выполняет операцию сдвига: он сдвигает весь uSID‑контейнер влево на 16 бит (шаг 2). Благодаря этому следующий микросегмент (uSID) автоматически перемещается на позицию активного. Новый 128-битный адрес назначения ищется в статической таблице форвардинга коммутатора обычным образом (шаг 3). Эта таблица форвардинга была сконфигурирована при установке («наливке» на сетевом жаргоне) коммутатора и обычно никогда не меняется. Статический маршрут определяет, через какой выходной порт отправить пакет. Во всех коммутаторах этот SRv6-форвардинг с использованием uN может выполняться на полной скорости чипа (line rate).

Для целей мониторинга и диагностики сеть также поддерживает встроенную телеметрию (in‑band telemetry) и SRv6 OAM-инструменты (например, ping/traceroute для uSID), позволяя отслеживать состояние путей в реальном времени.

Пакеты MRC инкапсулируются как IPv6 в IPv6 (IP in IP), причём внешний IPv6-заголовок содержит адрес назначения, сформированный по правилам SRv6 (список uSID). Этот адрес динамически изменяется на каждом коммутаторе в процессе сдвига uSID, как описано выше. Внутренний IPv6-заголовок, который остаётся неизменным на всём пути, содержит собственный (локальный) адрес NIC-получателя. Благодаря этому принимающий NIC может идентифицировать пакет как предназначенный именно ему, декапсулировать его (удалить внешний SRv6-заголовок) и передать внутренний пакет в конвейер обработки RDMA MRC. 

Вопрос о том, как именно значения EV отображаются на конкретные SRv6-пути, мы рассмотрим в следующей главе.

Отображение EV в SRv6

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

В любом случае в каждый пакет встраивается энтропийное значение (EV). Это 32-битное поле, распределённое между номером UDP-порта источника (UDP Source Port) и IPv6 Flow Label. В режиме ECMP это значение служит входными данными для хеш-функции на коммутаторах, а также используется для обратной связи — оно отражается отправителю в пакетах SACK/NACK для сигнализации о перегрузке пути.

В NIC, поддерживающем MRC, при запуске очереди (QP) генерируется набор из 128–256 значений EV —  EV Set (набор энтропийных значений). Ключевое отличие MRC в том, что биты в значениях EV не просто какая-то абстрактная энтропия, а чётко и алгоритмически кодируют возможный выбор пути в сети на каждом шаге. Таким образом, каждое EV из набора отображается на конкретный, уникальный путь через фабрику к целевому NIC.

При использовании SRv6 логика меняется. Очевидно, что по самой своей природе эта технология не использует EV для динамического выбора пути — путь жёстко задаётся списком uSID в IPv6-адресе назначения (IPv6 DA). Однако EV необходимо передавать в пакете, чтобы получатель мог отразить его обратно. Возникает задача: как сопоставить EV с путём, если IPv6-адрес динамически меняется на каждом хопе? Для решения этой задачи авторы MRC применяют подход алгоритмического отображения EV в соответствующий SRv6-адрес.

Суть этого подхода в том, что EV не используется для выбора пути на коммутаторах, а служит «ключом» для конечной системы, которая на его основе конструирует финальный SRv6-адрес назначения. Можно сказать, что EV — это идентификатор предопределённого пути, который NIC отправителя умеет преобразовывать в конкретный список uSID.

SRv6 идентификаторы коммутаторов (uN SID) назначаются согласно выбранной схеме адресации и с учётом сетевой архитектуры, например из диапазона 5f00::/16 по RFC 9602. При этом EV структурировано как набор битовых полей, значения которых варьируются для разных SRv6-путей к одному узлу назначения; также в EV кодируется номер порта на NIC (вспомним, NIC имеет 8 портов по 100 Гбит/с).

Схема выше показывает процесс алгоритмической генерации destination SRv6-адреса для любой QP с путём src Node — T0 — T1 — T0 — dst Node. При запуске NIC считывает destination SRv6-адрес из специального темплейт-файла с конфигурацией. Из схемы видно, что используются три uN uSID для идентификации трёх коммутаторов в одной плоскости, а четвёртый uN (Specific dst uSID на схеме) идентифицирует узел назначения, кодируя номер downlink к нему.

NIC также создаёт при запуске набор  EV для данной QP (EV-set,128–256 значений, как описано выше), распределяя их между плоскостями и путями в каждой плоскости. Более того, при создании финального адреса узла назначения номер плоскости, извлечённый из EV, встраивается во все uSID (красные стрелки на схеме), а также номера аплинка Т0 в uSID для T1 (зелёная стрелка на схеме).

Пример формирования SRv6 DA и uN SID с метаданными MRC 

Моё предлагаемое расширение, не входящее в текущую спецификацию MRC.

• Узел-отправитель (src Node): подключён к Leaf-коммутатору T0_src. Локальный MRC-агент уже сформировал пул энтропии (набор EV), где для конкретной транзакции выбрана Плоскость 2 (физический аплинк № 5 на коммутаторе T0_src, ведущий к T1 Spine).

• Узел-получатель (dst Node): физически находится за Leaf-коммутатором T0_dst (ID: 0B).

• Аппаратный контекст (NIC dst): сетевой интерфейс хоста назначения (ID: FF).

• Контекст MRC-сессии: данный пакет принадлежит логическому соединению QP ID: 0x0AAA и имеет порядковый номер PSN:0x0001AAAA.

Сетевая карта-отправитель на лету компилирует 128-битный IPv6 Destination Address (DA), объединяя статический SRv6-маршрут (EV) и детерминированные метаданные MRC в один заголовок:

{5f00:0502:0b02:ff02:0aaa:0001:aaaa:0000}

Анатомия IPv6-адреса (битовая структура):

• 5f00 — SRv6 Locator (16 бит): общий префикс AI-фабрики.

• 0502 — uSID 1 (Spine T1) (16 бит): аплинк № 5, плоскость 2.

• 0b02 — uSID 2 (Leaf T0_dst) (16 бит): ID коммутатора 0B, плоскость 2.

• ff02 — uSID 3 (NIC dst) (16 бит): терминальный контекст сетевой карты FF, Плоскость 2.

• 0aaa — MRC QP ID (16 бит метаданных): идентификатор Queue Pair на приёмнике.

• 0001:aaaa — MRC PSN (32 бита метаданных): Packet Sequence Number для сборки Out-of-Order.

• 0000 — остаток адресного пространства (зарезервировано).

[ NIC src ] --(DA: 5f00:0502:0b02:ff02:0aaa:0001:aaaa:0000)-----> [ T0_src ]
                                                                       | 
(Left-Shift uSID / Метаданные на месте) 
                                                                       v 
[ T1 Spine ] <--(DA: 5f00:0b02:ff02:0aaa:0001:aaaa:0000:0000)--------+ | 
(Left-Shift uSID / Метаданные на месте) 
                                                                       v 
[ T0_dst ] <--(DA: 5f00:ff02:0aaa:0001:aaaa:0000:0000:0000)----------+ | 
(Финальная доставка с метаданными) 
                                                                       v 
[ NIC dst ] <--(DA: 5f00:ff02:0aaa:0001:aaaa:0000:0000:0000)---------+

Пошаговое продвижение пакета по конвейеру ASIC (uSID Shift)

Хоп 1: обработка на Leaf-коммутаторе источника (T0_src)

• Входной DA: 5f00:0502:0b02:ff02:0aaa:0001:aaaa:0000.

• Действие: коммутатор распознаёт префикс фабрики 5f00::. Так как хост подключён напрямую к порту, T0_src сразу анализирует первый доступный сегмент 0502. В TCAM-таблице срабатывает статическое правило:
  MATCH {5f00:0502::/32} → {ACTION: End.X (Forward to Uplink 5), NEXT (uSID Shift).

• uSID NEXT (Сдвиг): конвейер ASIC сдвигает адрес влево на 16 бит, начиная с 16-го бита (сохраняя префикс 5f00). Метаданные MRC (0aaa...) сдвигаются влево вместе со всей строкой.

• Выходной DA: 5f00:0b02:ff02:0aaa:0001:aaaa:0000:0000.

• Пакет улетает в физический порт аплинка № 5 в сторону Spine (T1).

Хоп 2: обработка на Spine-коммутаторе (T1 в Плоскости 2)

• Входной DA: 5f00:0b02:ff02:0aaa:0001:aaaa:0000:0000.

• Действие: T1 видит локатор 5f00:, активный uSID равен 0b02. По своей локальной таблице коммутатор определяет, что ID 0B — это даунлинк к целевому Leaf-коммутатору.
  MATCH {5f00:0b02::/32}\→ACTION: Forward to Downlink T0_dst, NEXT (uSID Shift).

• uSID NEXT (сдвиг): происходит аналогичный аппаратный сдвиг строки влево на 16 бит. 

• Выходной DA: 5f00:ff02:0aaa:0001:aaaa:0000:0000:0000.

• Пакет уходит на T0_dst.

Хоп 3: доставка на Leaf-коммутатор назначения (T0_dst)

• Входной DA: 5f00:ff02:0aaa:0001:aaaa:0000:0000:0000.

• Действие: T0_dst сопоставляет префикс и видит uSID ff02. По статической таблице хост-портов коммутатор определяет, к какому именно локальному downlink-порту (серверному интерфейсу) подключена целевая сетевая карта с ID FF.

• Финал маршрутизации: на данном этапе цепочка uSID завершена. Коммутатор не выполняет сдвиг, чтобы не перезаписать метаданные MRC, и пересылает пакет в порт назначения в неизменном виде.

Хоп 4: терминация на сетевой карте назначения (NIC dst)

• Входной DA: 5f00:ff02:0aaa:0001:aaaa:0000:0000:0000.

• Аппаратное действие: NIC dst распознаёт 5f00:ff02 как указание на собственный локальный контекст (функция локальной терминации, которая извлекает метаданные и передаёт полезную нагрузку в RDMA-конвейер).

• Парсинг метаданных MRC: сетевой чип (ASIC) на хосте-приёмнике параллельно со считыванием заголовка извлекает данные из фиксированных битовых смещений IPv6 DA:

  • Извлекает 0x0AAA → находит контекст нужной Queue Pair (QP) в аппаратной таблице сетевой карты.

  • Извлекает 0x0001AAAA → передаёт PSN в модуль MRC-сборщика для проверки на пропуски и восстановления правильного порядка пакетов (Out-of-Order Handling).

• Итог: сетевая карта производит RDMA-запись (RDMA Write) полезной нагрузки пакета напрямую в выделенный буфер памяти GPU (через PCIe / NVLink) без какого-либо участия центрального процессора (CPU) хоста.

Выбор рабочих путей

В сети MRC со статической маршрутизацией от источника (source routing) вся ответственность за управление ресурсами и обработку отказов ложится на конечную систему — MRC-транспорт.

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

Разные отправители NIC в одной группе T0 не координируют свой выбор. Координация потребовала бы централизованного контроллера или обмена сообщениями между NIC, что увеличило бы сложность и задержку. Вместо этого MRC полагается на ECN-балансировку. Помним, что ECN используется как сигнал для коррекции балансировки, которая автоматически выравнивает неравномерность, возникающую из-за нескоординированного выбора EV. При запуске задачи предобучения необходимо обеспечить, чтобы все узлы в задаче имели все порты NIC в рабочем состоянии! 

MRC поддерживает чёрный список (denylist), который позволяет избегать путей, которые проходят через заведомо отказавшие линки. Для этого коллеги реализовали сетевой агент — Clustermapper на каждом узле; вместе эти агенты составляют карту того, какие линки в данный момент не работают или имеют чрезмерные потери. 

• Агенты зондируют все линки (NIC–T0, T0–T1), посылая специальные пакеты с SRv6-адресами, которые кодируют конкретный путь (плоскость + аплинк + даунлинк).

• Поскольку маршрутизация статическая и детерминированная (SRv6), тестовый пакет (зонд) идёт точно по тому же пути, что и пакеты MRC для данного EV.

• Результаты со всех узлов собираются в единую карту: какие линки отвечают, какие нет, где повышенные потери.

Статическая маршрутизация SRv6 делает эту задачу очень простой: в отличие от ECMP-хеширования, она позволяет точно знать, через какой путь пройдёт зондирующий пакет Clustermapper, и значит, что это тот же путь, через который пройдёт эквивалентный пакет MRC. По сравнению с телеметрией от коммутаторов (например, gNMI), полученная карта даёт объективную информацию о состоянии forwarding-plane. 

Коллеги сообщают, что на самом деле для предобучения им даже не потребовалось использовать Clustermapper для задания чёрных списков отказавших линков T0–T1, потому что QP-сессии очень долгоживущие и MRC быстро обходит отказавшие пути, используя хорошие пути и ребалансируя EV через другие плоскости. На NIC Nvidia ConnectX-8 на каждый QP запускается MRC с большим набором EV (обычно более 100 записей) плюс резервный набор для отказов. Благодаря этому QP начинает распылять пакеты по этому множеству путей. Если некоторые пути не работают; то пакеты теряются и передаются повторно, а такие EV заменяются на резервные. Даже без предварительного знания MRC достаточно быстро выявляет плохие пути.

Сравнение традиционной архитектуры для AI-фабрики и MRC

Авторы MRC провели измерения потерь пакетов на кластере из 75K GPU в процессе предобучения модели без предварительного заполнения «чёрного списка» путей. На представленном ниже графике показаны суммарные потери в секунду на одной из четырёх сетевых карт (NIC) хоста, просуммированные по всем узлам, выполняющим задачу.

Горизонтальная линия на графике обозначает порог в одну потерю в секунду на NIC с пропускной способностью 800 Гбит/с, что соответствует примерно 1 потерянному пакету на 25 миллионов переданных. Потери по всей задаче превышают этот порог лишь на несколько минут. В течение первой минуты было потеряно менее 5 пакетов на каждую очередь (QP).

Резюме по наблюдаемым потерям на старте

• Первая минута: менее 5 потерянных пакетов на QP. При этом QP может отправлять миллионы пакетов в секунду. 5 потерь за 60 секунд — это меньше 0,1 потери в секунду. То есть уже на первой минуте потери ниже опорной линии 1 потеря/с/NIC.

• Через 2–3 минуты: потери падают значительно ниже опорной линии. MRC  успевает вытеснить все проблемные пути (EV), стабилизиров передачу на надёжных путях.

Медленный разгон (ramp-up) задач

Запуск обучения на 75К GPU — это огромное энергопотребление. Если все GPU одновременно начнут работать на полную мощность, это может вызвать скачок энергопотребления и дестабилизировать энергосеть. Поэтому задачи разгоняют постепенно: сначала включают малую долю GPU, потом увеличивают нагрузку, давая системам электропитания и охлаждения возможность адаптироваться. Этот процесс может занимать минуты.

Сравнение масштабов

Потери и адаптация MRC происходят в течение первых 1–2 минут, то есть в том же окне, когда задача всё равно не вышла на полную производительность из-за медленного разгона. Следовательно, дополнительные потери от «прощупывания» путей не увеличивают общее время ожидания готовности задачи.

Вывод

На основании этого авторы делают вывод, что можно отказаться от предварительного зондирования сети (использования Clustermapper для T0–T1 линков). Даже если не знать заранее, какие пути не работают, MRC сам быстро их обнаружит и обойдёт, а потеря нескольких пакетов на QP в течение первой минуты не страшна и скрывается за медленным стартом синхронного обучения.

Обратные пути и MRC

Зачем нужны обратные пути?

• В MRC управляющие пакеты (SACK, NACK, RoCE ACK) передаются от получателя данных обратно отправителю.

• Эти пакеты несут критически важную информацию о том, какие пакеты доставлены, ECN-метки, состояние перегрузки и т. д.

• Для их отправки получатель должен знать, какой путь (EV) использовать, потому что EV определяет, через какую плоскость и через какие аплинки пойдёт пакет.

Почему возникает проблема?

• Двунаправленный трафик (когда обе стороны одновременно отправляют данные) — редкий случай в коллективных операциях ИИ. Типичный паттерн для коллективных алгоритмов обучения: сначала все отправляют градиенты на один узел (all-reduce, all-gather), потом этот узел рассылает результат. В любой момент времени большинство QP однонаправленны.

• У получателя, который не отправляет данные (только принимает), может не быть активного набора EV для исходящего трафика. Он не генерировал EV при старте QP, потому что предполагалось, что он только принимает.

• Но ему нужно отправлять SACK/NACK обратно. Какой EV взять?

Почему нельзя просто отзеркалировать прямой SRv6-путь

Казалось бы, можно взять путь, по которому пришёл пакет данных, и симметрично отправить управляющий пакет (SACK/NACK) обратно. Но:

• В многоплоскостной топологии путь от A к B не обязательно симметричен пути от B к A. Плоскости могут быть независимыми, а линки — разной загрузки.

• Шаблонов для сборки обратного SRv6-адреса у получателя может не быть.

• Если B просто перешлёт пакет, используя тот же внешний SRv6-адрес, но с заменой src/dst, это может не сработать из-за политик безопасности или отсутствия обратных маршрутов.

Предлагаемое решение в MRC: небольшой обратный набор EV

• Каждый узел — даже если он только принимает, заранее создаёт небольшой набор EV для обратных управляющих пакетов.

• Этот набор включает как минимум одно EV на плоскость (например, 8 EV для 8 плоскостей).

• EV выбираются так, чтобы они соответствовали некоторому гарантированно рабочему пути

Механизмы установки обратного EV

• Пробные пакеты (EV probe): если QP однонаправленный, то раз в RTT получатель отправляет probe packet (пробный пакет, зонд EV) — специальный небольшой пакет, использующий одно из обратных EV. Получив ответ (или подтверждение), узел убеждается, что это EV работает, и затем использует его для SACK/NACK.

• Пассивное отслеживание (Data SACK): если узел сам отправляет данные (т. е. имеет свой активный набор EV), он может использовать любой из них для отправки управляющих пакетов, не прибегая к зондированию.

Почему MRC не очень чувствителен к потерям на обратном пути

Потеря управляющего пакета (SACK/NACK) приводит к тому, что отправитель вовремя не получает подтверждение о доставке данных, что может инициировать их повторную передачу. Однако MRC сводит негативный эффект от таких событий к минимуму по ряду причин:

1. Надёжность управления: протокол предусматривает повторную передачу (ретрансляцию) SACK/NACK-пакетов.

2. Асимметрия потоков: основной поток данных идёт по прямому пути. Трафик управления (SACK/NACK) — это лишь небольшое дополнение к нему.

3. Ограниченное влияние на задержку: потери на обратном пути могут влиять на хвостовую задержку (tail latency), так как отправитель может ожидать подтверждения для освобождения буферов или продвижения окна. Однако это влияние не катастрофично для сквозной производительности, в отличие от потерь на прямом пути.

Измерение RTT в MRC

Ключевым параметром для точной оценки состояния сети и адаптивного управления перегрузкой служит значение Round-Trip Time (RTT). MRC вычисляет RTT аппаратно на уровне NIC, используя специализированный заголовок TSETH (Requestor Timestamp Extended Header). Отправитель помещает в пакет данных метку времени. Получатель, сформировав ответ, например SACK, копирует эту метку в соответствующее поле ответа, что позволяет отправителю вычислить точную задержку. Использование аппаратных меток времени исключает влияние задержек на программную обработку, обеспечивая высокую точность измерений даже на скоростях 800 Гбит/с.

Получатель, сформировав ответ, например SACK, копирует это значение из полученного пакета в соответствующее поле ответа. Отправитель затем вычисляет RTT, зная временные метки отправки и получения пакета.

Эксплуатация многоплоскостной сети MRC

Ключевой целью разработки MRC было радикальное упрощение эксплуатации крупных и сверхкрупных AI-кластеров. Опыт авторов, развернувших сети на 75–100К GPU, показывает, что большинство отказов оборудования не требуют немедленного вмешательства дежурных инженеров. Это достигается за счёт трёх архитектурных решений: 

• полного отказа от динамической маршрутизации в пользу статического SRv6;

• массового распыления пакетов (spraying) по сотням путей; 

• встроенных в транспорт механизмов быстрого обнаружения сбоев и повторной передачи (только потерянные пакеты).

Отказы линки между T0 и T1

В IP-фабриках ЦОДов на основе BGP ( RFC 7938) даже кратковременный флап линка вызывает пересчёт маршрутов протоколом BGP, что может занять секунды и привести к остановке синхронного обучения LLM. 

В MRC динамическая маршрутизация отключена, а транспортный протокол самостоятельно распыляет трафик каждого QP по десяткам и сотням путей. Если какой-либо линк между T0 и T1 перестаёт работать или начинает «дребезжать», через него идёт лишь малая доля пакетов. MRC в течение микросекунд удаляет соответствующее EV из активного набора и повторно отправляет потерянный пакет по другому пути. Общее число потерь на QP при этом составляет единицы, а влияние на производительность задачи пренебрежимо мало.

Коллеги провели измерение общего количества флапов линков между T0- и Т1-коммутаторами во время работы синхронной задачи предобучения:

Более того, в отличие от обычной практики, где «дребезжащий» или флапающий линк немедленно выводится из эксплуатации, в MRC такие линки можно оставлять в работе на всё время ремонта. MRC сам перестаёт использовать их в моменты отказов и автоматически возвращает обратно после успешного прохождения фоновых пробных пакетов (зондов). Оператор может безопасно ремонтировать или заменять отказавший линк, в то время как задача предобучения LLM продолжает выполняться на оставшейся ёмкости. Это не только снижает операционную нагрузку, но и делает систему устойчивой к неизбежным помехам, когда ремонт одного линка задевает соседние.

Отказы коммутаторов T1: перезагрузка без остановки обучения

Программное обеспечение коммутаторов сложно и подвержено ошибкам. Согласно исследованиям, до 17% отказов коммутаторов в ЦОДе вызваны именно программными дефектами. Особенно опасны и коварны случаи, когда control plane продолжает работать, а data plane (форвардинг) останавливается. Традиционные протоколы маршрутизации в такой ситуации не могут правильно обойти отказавший узел, т. к. для них он остаётся рабочим.

MRC, который использует статический SRv6, полностью игнорирует состояние control plane. Если пакеты перестают проходить через T1, MRC просто удаляет все EV, ведущие к этому коммутатору, и перераспределяет трафик. Поэтому оператор может перезагрузить «зависший» T1 без какой-либо координации с  задачами обучения — после перезагрузки MRC восстановит рабочие EV. Влияние на производительность обучения при этом практически незаметно.

Реальный кейс на 75K GPU

Во время 75К GPU предобучения у авторов было четыре случая, когда они были вынуждены перезапускать коммутаторы Т1, график ниже показывает один из таких случаев.

• Коммутатор T1 перестал пересылать пакеты, хотя control plane и линки формально были в состоянии UP. Это классический баг, когда коммутатор зависает на уровне ASIC, но управление (SNMP, CLI) ещё отвечает.

• Обнаружение: Clustermapper (красная линия) показывает резкий рост потерь пробных пакетов при зондировании через этот T1.

• Действие: автоматизация инициирует перезагрузку коммутатора в момент t=0.

• Восстановление: коммутатор полностью восстановил форвардинг в момент t=2.

• Потери: пурпурная линия показывает количество сброшенных пакетов (умноженное на 10 000) в каждую минуту. Около четверти QP были затронуты и около 580К пакетов были сброшены.

• Влияние на обучение: голубая линия показывает общую пропускную способность задачи, она проседает в момент сбоя коммутатора, т. к. многие QP потеряли пакеты, но сбойные пути с «плохим» EV были отброшены MRC и она восстановилась.

• Вывод: ребут коммутатора никакого влияния на задачу не оказал.

Отказы линков между NIC иT0, а также коммутаторов T0: временное снижение пропускной способности

Наиболее чувствительные элементы — линки между сетевыми картами и коммутаторами T0, а также сами T0. Потеря порта NIC, например из-за обрыва кабеля, не приводит к отказу QP, но вызывает заметный спад пропускной способности. NIC обнаруживает обрыв и уведомляет локальный MRC, который начинает переназначать EV в обход отказавшего порта. Кроме того, с помощью битовой маски состояния порта, встраиваемой в пакеты SACK, удалённая сторона также исключает отказавшую плоскость из активного набора EV для соответствующих QP. Этот процесс занимает несколько секунд, в течение которых наблюдается кратковременный сбой (glitch) в пропускной способности задачи. 

После переназначения QP продолжают работу на оставшихся плоскостях с пропорционально сниженной производительностью. В восьмиплоскостной конфигурации (8×100 Гбит/с) потеря одного порта означает уменьшение пропускной способности NIC на 12,5%, тогда как в четырёхплоскостной (4×200 Гбит/с) — на 25%. В большинстве случаев порт восстанавливается без потери целостности данных, благодаря повторной передаче, и задача возвращается к нормальной работе. Только при окончательном отказе порта узел исключается из задания и отправляется в ремонт.

График иллюстрирует инцидент, произошедший при обучении модели на 50К GPU в OpenAI. Сеть была сконфигурирована с четырьмя портами 200 Гбит/с на NIC, и MRC распылял трафик каждого QP по всем четырём портам (в четырёх плоскостях). Оптический трансивер на коммутаторе T0 вызвал флапы всех четырёх своих линков, которые вели к четырём разным узлам (три из них участвовали в обучении). В течение минуты пропускная способность задачи снизилась примерно на 25% — ровно на долю, соответствующую одному потерянному порту NIC из четырёх. 

Несмотря на то что проблема затронула несколько узлов одновременно, задача не упала, ни один QP не перешёл в состояние ошибки и не потребовалось исключать узлы из задания. Как только флапы прекратились, пропускная способность мгновенно восстановилась до 100%. Этот случай показывает, что MRC устойчив даже к редким, но более серьёзным сбоям трансиверов, а не только к одиночным флапам линков. Более того, он демонстрирует, что синхронное обучение может «пережидать» временную деградацию пропускной способности без сбоя задачи.

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

Детерминированная телеметрия для точной локализации проблем

Хотя MRC позволяет переживать отказы без вмешательства control plane, для диагностики и планового обслуживания необходима детальная телеметрия. Авторы разработали сетевой агент Clustermapper, к сожалению, его код не опубликован, он только упоминается в статье про MRC. Ключевое нововведение агента в том, что для зондирования используется SRv6, а значит, путь каждого зонда строго определён и совпадает с путём пакетов MRC для соответствующего EV. В отличие от ECMP, здесь нет неоднозначности хеширования и динамической маршрутизации, способной изменить путь.

• Принцип работы: на каждом узле кластера запущен агент. Агенты раз в несколько  миллисекунд отправляют пробные SRv6-пакеты (зонды) до каждого T0 и T1 и обратно к себе.

• Поскольку зонды обрабатываются в data plane коммутаторов, а не в control plane (как ICMP), возможна их частая отправка выше без перегрузки CPU коммутаторов.

• Точная локализация: если зонды до T0 проходят нормально, а зонды до T1 (через те же T0) показывают потери, проблема локализуется именно в линке T0–T1. Это позволяет немедленно назначать ремонт нужного кабеля или оптического трансивера.

Clustermapper может работать непрерывно даже при отсутствии вычислительной нагрузки; стоимость постоянного зондирования незначительна. Без SRv6 достичь такого уровня объективной информации (ground truth) о состоянии сети было бы невозможно.

Балансировка нагрузки между плоскостями (Inter-Plane LB)

Авторы архитектуры MRC приняли два концептуально важных решения:

Первое решение: замена EV на другое из той же плоскости

Правило: когда EV переходит в состояние ASSUMED_BAD или SKIP и удаляется из активного набора EV, на его место берётся новое EV из той же самой плоскости, а не из какой-либо другой. Новое EV выбирается случайным образом из резервного набора для данной плоскости, что обеспечивает равномерное распределение по доступным путям внутри плоскости.

Цель: сохранить строго равное количество активных EV на плоскость. Например, если всего 256 EV, а плоскостей 8, то на каждую плоскость приходится ровно 32 EV, независимо от отказов, пока в плоскости есть хотя бы один рабочий путь, она получает ровно столько EV, сколько и другие плоскости (если резервный набор не исчерпан). Это обеспечивает идеальную балансировку между плоскостями, пока все NIC имеют все плоскости в рабочем состоянии.

Важность: если бы MRC заменял удалённое EV на EV из произвольной плоскости, например из менее загруженной, то со временем распределение EV по плоскостям стало бы неравномерным. Это привело бы к тому, что одни плоскости получали бы больше трафика, чем другие, и при инкасте (много потоков сходятся к одному получателю) более нагруженные плоскости создавали бы перегрузку на последнем хопе. Авторы называют это «ложным incast» (false incast) — проблема возникает не из-за реального дисбаланса спроса, а из-за неравномерного распределения EV.

Возможное негативное последствие: потеря большого числа линков в одной плоскости.

Потенциальный риск: если в какой-то плоскости отказало так много линков T0–T1, что оставшаяся пропускная способность этой плоскости стала существенно ниже, чем у других, то MRC всё равно будет посылать в эту плоскость долю трафика, пропорциональную количеству EV (равному другим плоскостям). Это приведёт к перегрузке этой плоскости, потерям и снижению общей производительности. На практике авторы утверждают, что не наблюдали такого в продакшене. Вероятно, потому что отказы линков были распределены равномерно, а запас пропускной способности достаточен, чтобы несколько отказов не создавали критического дисбаланса.

Второе решение, следствие первого об эквивалентной загрузке плоскостей

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

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

Решение: делегировать обнаружение такого случая Clustermapper. Clustermapper отправляет SRv6 пробные пакеты от узла до локального T0 и обратно (без участия удалённой стороны) и до T1 и обратно. Если зонды до T0 проходят нормально, а зонды до T1 показывают потери или большую задержку на своей плоскости, проблема локализуется как проблема на стороне отправителя (линк NIC–T0 или сам T0). Если же пробные пакеты до T0 нормальные, а трафик MRC через ту же плоскость теряется, проблема, вероятно, дальше (T0–T1 или удалённая сторона). На основе этой информации оператор (или автоматическая политика) может добавить всю плоскость в чёрный список (denylist) для данного узла, после чего MRC перестанет использовать EV, связанные с этой плоскостью.

Результаты экспериментов в MRC-сети

Авторы провели целую серию различных экспериментов, для краткости я приведу тут наиболее важные из них:

Кластер В, базовая производительность MRC на CX-8

Тесты проводились в двух конфигурациях:

• T0-Local: поток данных между GPU, подключёнными к одному Leaf-коммутатору (T0).

• Cross-T1: поток данных, проходящий через Spine-коммутатор (T1).

Тест по доступной полосе пропускания осуществляет прямые записи фиксированных 32 Кбайт сообщений между GPU. Оба варианта потоков (T0-Local, Cross-T1) показали 96% от теоретически возможной пиковой полосы, что доказывает: в нормальном состоянии полоса пропускания не зависит от типа потока — локального в Т0 или через Т1.

Тест по измерению задержки оперировал 2 Кбайт сообщениями и измерял время между отправлением операции записи (write) до получения отправителем подтверждения этой записи, далее результат делился на 2, чтобы получить значение односторонней задержки. Задержка для T0-Local включает в себя инициализацию QP, обработку операции записи и управление путём. Очевидно, что для  сценария Cross-T1 задержка выше из-за необходимости проходить через дополнительный коммутатор: Т1.

Реакция MRC на падения линков и флапы

Падение линков NIC-T0

Для начала авторы проверили влияние падения линков NIC-T0 на пропускную способность четырёх QP. Методология теста: запуск утилиты ib_write_bw (режим RDMA Write) из набора perftest между двумя T0-Local NIC и последовательное выключение линков NIC-T0.

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

Также MRC делает другое важное дело: меняет битовую маску состояния линков в пакетах SACK, уведомляя удалённую сторону, что соответствующий(е) линк(и) не в рабочем состоянии, чтобы удалённый инстанс MRC перепривязал часть затронутых EV к другим плоскостям.

Одновременный флап линков NIC

Затем коллеги также проверили влияние продолжительного синтетического флапа четырёх из восьми линков на СХ-8 NIC (они эмулировали сценарий сбоя QSFP порта или трансивера), из диаграммы видно, что MRC обеспечил передачу половины доступной полосы и быстро восстановил полный объём, когда 4 линка вернулись в работу. Механизм фоновых проб позволяет MRC автоматически возвращать восстановившиеся пути в активный набор EV.

Сбой линков T0-T1

Коллеги запустили Cross-T1 ib_write_bw и одновременно последовательно выключили 20 линков. Поскольку MRC распыляет трафик каждого QP по множеству путей, потеря 20 линков затрагивает лишь небольшую долю трафика. Как и следовало ожидать, влияние на доступную полосу пропускания оказалось весьма незначительным.

Флап линков T0-T1

Телеметрия, авторы собирали её раз в 200 мс, не зафиксировала какого-либо значимого влияния флапа линков T0–T1 на полосу пропускания. Это ожидаемо: MRC адаптируется к изменениям состояния путей за микросекунды, что значительно быстрее периода сбора статистики.

Выход из строя коммутаторов T0/T1

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

Для генерации трафика также использовалась ib_write_bw.

При выходе из строя коммутатора T0 мы видим кратковременное проседание пропускной способности, после коррекции набора EV (удалений, идущих через сбойный Т0 коммутатор) она восстановилась до уровня приблизительно на 100 Гбит/с меньше первоначальной из-за перераспределения трафика на оставшиеся пути. Этот тест подтверждает, что MRC обрабатывает сбои на основе Е2Е-путей, без привязки к конкретному месту или источнику сбоя.

Выход из строя Т1-коммутатора оказывает ещё меньшее влияние на Cross-T1 трафик:

Проверка MRC на изменение балансировки потоков

 Коллеги проверили это в простом и элегантном тесте: 

• Создали две пары потоков client1-server1, client2-server2, две EV: EV-A и EV-B.

• Привязали client1-server1 к EV-A и выдали ему всю доступную полосу, EV-B осталась пустой.

• Через 65 сек. запустили второй поток client2-server2 также через EV-A, что вызывает перегрузку (congestion).

• Контроллер перегрузок MRC детектирует это и в ответ на сигналы (например, ECN) перестаёт использовать проблемный путь для части трафика. Фактически client2–server2 начинает передачу через EV-B, который к тому моменту уже не пуст, а задействуется для балансировки. Оба потока продолжают работать, эффективно используя доступную полосу.

Тест подтвердил, что MRC может эффективно балансировать потоки трафика через разные EV.

Тесты работы NCCL на большом масштабе в MRC-сети

Коллеги проверили производительность коллективных операций NCCL на кластере из 42К GPU, используя sendrecv-бенчмарк из набора nccl-tests Nvidia. В этом тесте каждый узел отправляет и принимает данные от соседа, а значит, здесь — двухсторонний обмен трафиком.

Сравнение MRC с RoCE

Авторы не имели возможности построить параллельный RoCE-кластер такого же масштаба, чтобы сравнить с MRC. Однако они сделали два небольших тестбеда (кластеры С и Д в таблице) для сравнения двух технологий.

Конфигурация стендов

Кластер С содержит 64 GPU, каждая подключена к 400 Гбит/с NIC AMD Pollara, используя коммутаторы на чипе Tomahawk 5 (они не указывают производителя и модель) с двухуровневой Clos-фабрики.

Для RoCE коллеги собрали одноплоскостную фабрику с 400 Гбит/с и ECMP, были включён PFC и DCQCN. 

Для MRC использовали 4-плоскостную сеть, 4х100 Гбит/с на NIC, PFC был выключены и использовалось SRv6.

Цели сравнения

• Действительно ли MRC будет балансировать лучше, чем RoCE даже с ростом количества QP?

• Действительно ли селективные повторные передачи MRC реально помогут типичным AI-коллективным операциям в случае сетевых проблем?

Эксперименты

• Запускали all-reduce в кольце, где каждый узел отправляет и принимает данные к другому узлу одновременно на полной скорости канала (line rate).

• Запускали all-to-all, требующий, чтобы каждый узел отправлял и принимал от остальных узлов одновременно. Тут хотели проверить балансировку и производительность повторных передач (ретрансмитов) во время коллективной операции, которая может вызвать инкаст-перегрузку.

Результаты

Для MRC использовали 1 QP, для RoCEv2 — 1 и 16 QP. Линии сплошного цвета на графиках выше показывают базовую (baseline) производительность, а пунктирные — с индуцированными потерями пакетов. Для малых размеров сообщений коллективные операции зависят больше от задержки, и поэтому на этих графиках не видно большой разницы между MRC и RoCE. 

С увеличением размера сообщений производительность всё больше и больше зависит от доступной полосы пропускания. RoCE c 1 QP страдает от коллизий ЕСМР-хеширования и в среднем показывает только половину доступной полосы пропускания. Обычный путь улучшения такой ситуации — увеличение количества QP, чтобы увеличить энтропию при балансировке и влияние коллизий потоков.

Для сравнения — MRC с 1 QP (распрыскивая трафик между 256 путями) показывает лучшие результаты, чем RoCE c 16 QP! 

Для эмуляции потерь пакетов авторы сделали специальную Р4-программу на всех NIC, чтобы случайным образом сбрасывать пакеты с заданной частотой. RoCE неустойчив к потерям пакетов и показывает худшую производительность (с 1% потерь использование RoCE практически теряет смысл), MRC — показывает себя намного лучше.

Взаимное влияние коллективных операций или побочный ущерб

Многочисленные коллективные операции, выполняемые при том или ином виде параллелизма при обучении LLM, могут оказывать взаимное влияние друг на друга. Например, lossless-сети могут страдать от инкаст-трафика, когда перегрузка распространяется по сети и задевает другой «невиновный» трафик (victim traffic), вызывая побочный ущерб.

Для эмуляции такого сценария коллеги запускали 7 к 1 cross-spine инкаст-трафик и параллельно запускали другое соединение (victim) в этой же стойке (т. е. в том же Т0-коммутаторе) для оценки влияния на него. Для этого эксперимента использовался кластер Д с 16 серверами с RTX6000 GPU и Broadcom Thor Ultra NIC, использовались такие же не названные коммутаторы на Broadcom Tomahawk 5 ASIC, как и в предыдущих тестах. Коллеги лишь отмечают, что использовали VRF на них для создания 2-уровневой Clos-фабрики с 4 стойками по 4 сервера в каждой, все линки были 400 Гбит/с. 

Результаты

При использовании DCQCN с одной QP производительность victim-соединения проседала на 25%, c 10 QP отмечались неоднократные ~ 1 сек. интервалы, где производительность victim-соединения падала до ~ 100 Гбит/с — 75% от оптимального. Видно, что DCQCN не позволяет полностью избежать влияния на производительность victim-соединения. Авторы отмечают, что, вероятно, необходима его тонкая настройка. 

Вывод

В отличие от RoCE и DCQCN, MRC справляется намного лучше — он практически идеально разделяет перегруженный канал между инкаст-потоками и не влияет на victim-соединения.

Практическая имплементация MRC в Microsoft

Изначально Microsoft думал и предлагал несколько иную, централизованную архитектуру для сети AI-backend на основе SRv6, где центральный контроллер (AI-планировщик) рассчитывал пути между хостами и выдавал им эти пути. Кстати, схожая архитектура на основе SRv6 используется в MWS Cloud Platform. Подробнее об этом — в моём докладе на IETF-123.

Однако позже команда Microsoft переключилась на полностью распределённую архитектуру на MRC. Более того, опубликована библиотека (обёртка), позволяющая стандартным библиотекам NCCL, RCCL перейти на транспорт MRC — здесь ссылка на Github.

Судя по статье, Microsoft, вероятно, сделала уже и тестовую имплементацию полного MRC-стека из всех компонентов: MRC-агент на хосте, Performance Monitoring посредством Clustermapper, программирование коммутаторов SRv6-информацией и статическими маршрутами.

Заключение

Представленный протокол Multipath Reliable Connection (MRC) представляет фундаментальный сдвиг в архитектуре сетей для крупномасштабного обучения ИИ.

Ключевые достижения MRC

MRC демонстрирует следующие важные характеристики:

Многоплоскостная топология: замена одного 800 Гбит/с порта на 8 независимых плоскостей по 100 Гбит/с позволяет сократить количество уровней коммутации с трёх-четырёх до двух и достичь поддержки 131 000 GPU при сохранении полной бисекционной пропускной способности.

Устойчивость к сетевым сбоям: потеря одного линка T0–T1 снижает пропускную способность всего на 0,4% (против 3% в классической одноплоскостной архитектуре), а потеря порта NIC (1 из 8 плоскостей) позволяет задаче продолжать работу на 7/8 пропускной способности без остановки обучения.

Микросекундная отказоустойчивость: MRC перестаёт использовать отказавшие пути и перераспределяет EV за десятки микросекунд, что радикально отличается от секундного (и даже десятков секунд) времени сходимости протоколов динамической маршрутизации, таких как BGP.

Предсказуемая производительность: тесты показывают достижение 96% от теоретического пика пропускной способности как в локальных сценариях T0 в пределах одного коммутатора, так и в сценариях Cross-T1 с прохождением через Spine-коммутатор, что доказывает независимость эффективности от сложности пути.

Архитектурные принципы

Достигнутые показатели стали возможны благодаря трём ключевым архитектурным решениям:

1. Отказ от динамической маршрутизации в пользу статического SRv6 source routing: MRC отключает протоколы динамической маршрутизации на коммутаторах, полностью исключая неопределённость, связанную с ECMP-хешированием и временем сходимости сети. Путь кодируется непосредственно в заголовке пакета, что обеспечивает микросекундное переключение между путями и полную детерминированность.

2. Многоплоскостная физическая топология: параллельное подключение каждого NIC ко всем плоскостям сети вкупе с разбиением высокоскоростных портов (800 Гбит/с) на несколько линий 100 Гбит/с создаёт избыточность и одновременно увеличивает эффективный радикс коммутаторов в 8 раз, что позволяет строить двухуровневые сети на 100 000+GPU и значительно снижает «радиус поражения» (blast radius) каждого отказа.

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

Видится, что MRC в силу своей простоты и универсальности может составить достойную конкуренцию Ultra Ethernet и тем более IB. Если хочется сравнить MRC с другой новой технологией UET — посмотрите мой доклад на OS DevConf25.