MRC протокол меняет поведение сетей в AI-кластерах, снижая congestion и повышая устойчивость при сбоях. Это критично для синхронного обучения моделей на десятках тысяч GPU.
Проблема проявляется не сразу — до момента, когда масштаб кластера начинает усиливать каждую сетевую аномалию. В обучении крупных моделей один шаг включает миллионы передач данных. Достаточно одной задержки, чтобы весь шаг начал ждать. Это создаёт эффект «failure amplifier»: единичные потери пакетов, перегрузка (congestion) или отказ линка начинают масштабироваться на весь job. В классических сетях с RDMA (RoCE) каждый поток идёт по одному пути. В multi-plane топологиях это приводит к коллизиям потоков и неравномерной загрузке, что усиливает jitter и снижает throughput.
Решение строится вокруг MRC (Multipath Reliable Connection) — расширения RoCE, которое меняет базовую модель доставки. Вместо одного пути для передачи используется сотни параллельных маршрутов. Это снижает вероятность hot-spot’ов и выравнивает нагрузку. Дополнительно применяется SRv6 source routing, где отправитель явно задаёт маршрут пакета. Это убирает зависимость от динамической маршрутизации и снижает класс ошибок control plane. Компромисс здесь очевиден: система становится более сложной на уровне конечных узлов, но сеть в целом упрощается и становится более предсказуемой.
Архитектурно MRC опирается на multi-plane сеть. Один 800Gb/s интерфейс делится на несколько каналов, например 8×100Gb/s, каждый подключён к отдельному plane. Это позволяет строить топологии с двумя уровнями коммутаторов вместо трёх-четырёх. Меньше уровней — ниже latency и меньше точек отказа. Однако такая избыточность создаёт проблему эффективного использования путей. MRC решает её через packet spraying: пакеты одного потока распределяются по всем доступным маршрутам. Порядок доставки не гарантируется, но каждый пакет содержит конечный адрес в памяти, что позволяет собирать данные без строгой последовательности.
Дополнительно реализована адаптивная реакция на деградацию. Если путь начинает терять пакеты или перегружен, он исключается из использования за микросекунды. При потере пакета система предполагает сбой и сразу переключается. Для избежания ложных срабатываний используется packet trimming: при перегрузке коммутатор обрезает payload и пересылает только заголовок, инициируя точечную ретрансляцию. Это снижает вероятность ошибочной интерпретации congestion как отказа.
Отдельный слой упрощения — отказ от динамической маршрутизации (например, BGP) в пользу статических таблиц и SRv6. Каждый пакет несёт в себе полный маршрут через сеть. Коммутаторы действуют детерминированно и не пересчитывают пути при сбоях. Это устраняет задержки на convergence, которые в традиционных сетях могут занимать секунды. В MRC реакция происходит на уровне соединения и укладывается в микросекунды.
С точки зрения эксплуатации это меняет поведение системы. Сбои линков и даже перезагрузки коммутаторов перестают быть критичными событиями. Сеть продолжает работать, а training job не требует перезапуска. Потеря части пропускной способности приводит к деградации, но она обычно меньше, чем физическая потеря ресурсов. При восстановлении линков они автоматически возвращаются в пул доступных путей.
Результаты носят системный характер. Уменьшается влияние congestion, выравнивается latency между потоками, снижается чувствительность к отказам. Также появляется возможность строить кластеры более чем на 100 000 GPU с меньшим числом сетевых уровней. Это снижает энергопотребление и количество компонентов. Точных метрик в исходных данных нет, но заявлено, что влияние сетевых сбоев на синхронное обучение становится практически незаметным.
В более широком контексте MRC — это попытка сместить сложность из сети в крайние узлы и сделать поведение системы детерминированным. Подобные подходы уже обсуждаются в индустрии, особенно в контексте AI-инфраструктуры, где предсказуемость важнее пиковой производительности. При масштабах, где сеть определяет эффективность использования GPU, такие компромиссы выглядят прагматично.