Сеть для ИИ-нагрузок: не как обычно. RoCEv2, RDMA и почему InfiniBand — не единственный правильный ответ (часть 1)

Привет, Хабр! Продолжаем цикл про инфраструктуру для ИИ-задач. В первой статье мы разобрали, что заказчик узнает о самосборе не на этапе закупки, а через полгода. Во второй прошлись по аппаратному стеку: GPU, питание, охлаждение, хранение — и почему для ИИ-задач это принципиально другая история, чем для обычного сервера.

Сегодня же — про сеть.

Сеть — это, пожалуй, самое недооцененное звено во всей ИИ-инфраструктуре. Когда заказчик закладывает бюджет, в первую очередь он думает о GPU и о серверах. Сеть появляется в расчетах в формате «ну там поставим что-нибудь достаточно быстрое». А потом обнаруживается, что именно сеть убивает производительность при distributed training (распределенном обучении), создает непредсказуемые задержки и превращает дорогой GPU-кластер в систему, в которой карты большую часть времени ждут, а не считают.

Покажем, как мы проектировали сетевую архитектуру «Скала^р МИИ» и какие вопросы пришлось решить заранее, чтобы заказчик с ними не столкнулся. Про ограничения InfiniBand, его сравнение с RoCEv2 и многое другое — под катом.

Сначала главное: InfiniBand и почему его нет в нашем ПАК

Если вы читали что-то про сети для ИИ-кластеров, почти наверняка натолкнулись на InfiniBand — проприетарную фабрику от NVIDIA (после поглощения Mellanox). Технически это великолепное решение с задержками 0,9–2 мкс и аппаратной поддержкой lossless transport (транспорт без потерь) «из коробки». Именно InfiniBand используется в большинстве крупных западных GPU-кластеров.

Но в реестре российской радиоэлектронной продукции Минпромторга оборудования InfiniBand нет. Это означает, что для государственных заказчиков, организаций с требованием КИИ, закупок по 44-ФЗ и любых проектов с требованием к российскому происхождению оборудования — InfiniBand закрыт. Не «дорого», не «сложно», а именно закрыт регуляторно.

Поэтому для нашего ПАК выбор был однозначным: RoCEv2 (RDMA over Converged Ethernet, версия 2) — технология RDMA поверх стандартного Ethernet, которая реализована на доступном в России сетевом оборудовании.

Дальше разберем, что это означает технически, когда RoCEv2 справляется так же хорошо, как InfiniBand, а когда есть разница, — и как мы построили сетевую архитектуру ПАК с учетом всего этого.

Почему ИИ-сеть — это не просто «Ethernet побыстрее»

Обычные enterprise-сети спроектированы под tolerant workloads (толерантные нагрузки): если пакет потерян — TCP переотправит, пользователь не заметит. ИИ-нагрузка работает по-другому.

При distributed training (распределенном обучении) GPU-карты разных узлов постоянно обмениваются градиентами — операция all-reduce, которая синхронизирует веса модели между всеми участниками итерации. Это огромный одновременный поток данных: в кластере из 8 узлов на 8 GPU каждый из 64 GPU участвует в синхронизации после каждого шага обучения. Потеря одного пакета в этом потоке означает retransmission (ретрансляцию, Go-Back-N ARQ) — и пока идет восстановление, все участники GPU кластера стоят. Не один, не узел — все. Потому что all-reduce — это операция коллективного вычисления и связи. Она собирает данные со всех процессов, применяет к ним математическую операцию (например, сумму или поиск максимума) и отправляет итоговый результат обратно всем процессам.

RDMA: зачем обходить CPU при передаче данных

RoCEv2 использует технологию RDMA — Remote Direct Memory Access. Суть вот в чем: один сервер записывает данные напрямую в память другого, минуя CPU обоих и операционную систему. Это принципиально меняет картину по сравнению с классической TCP/IP-передачей:

Какие стандарты протоколов обеспечивают lossless качества сети Ethernet для работы RoCEv2

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

PFC — Priority Flow Control (802.1Qbb)

PFC — это механизм «поставь на паузу» на уровне линка. Когда буфер коммутатора на определенном приоритете трафика начинает переполняться, коммутатор отправляет PAUSE-фрейм соседу: «притормози на этом приоритете». Сосед перестает отправлять — пакеты не теряются.

Это работает как hard stop: грубый, но надежный. Основная опасность при неправильной настройке — PFC storm: цепочка PAUSE-фреймов распространяется по всей фабрике и блокирует не только проблемный поток, но и все остальное.

ECN — Explicit Congestion Notification

ECN — проактивный механизм. Когда очередь на коммутаторе начинает расти (но еще не достигла критического порога), коммутатор ставит метку в заголовок пакета: «я испытываю нагрузку». Получатель видит метку и отправляет CNP (Congestion Notification Packet) отправителю. Отправитель плавно снижает скорость.

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

DCQCN — Data Center Quantized Congestion Notification

DCQCN — алгоритм, который связывает ECN-метки коммутатора с реакцией сетевой карты (NIC). Коммутатор видит перегрузку → ставит ECN-метку → получатель отправляет CNP → NIC-отправитель по алгоритму DCQCN снижает скорость передачи → очередь разгружается → NIC постепенно восстанавливает скорость.

Итого: ECN + DCQCN держат очереди мелкими и трафик плавным, PFC — страховка на крайний случай. Если PFC срабатывает часто — это сигнал, что ECN/DCQCN настроены неправильно, а не что нужно «побольше PFC».

Почему это важно для понимания самосборки: настройка этой троицы на реальном кластере — нетривиальная инженерная задача. Неправильные пороги ECN → PFC-шторм. Разные настройки на разных коммутаторах → непредсказуемые задержки. Отсутствие мониторинга PFC-событий → проблема обнаруживается только когда обучение «тормозит непонятно почему».

RoCEv2 vs InfiniBand: честный разговор о производительности

Итак, InfiniBand регуляторно недоступен. Но честности ради — давайте разберем, что именно мы теряем технически, а что нет.

Латентность (задержки)

InfiniBand NDR: ~0,9 мкс. RoCEv2 400G (хорошо настроенный): 2–5 мкс. Разница реальная, но в контексте GPU-вычислений она значима только для специфических задач с очень частыми небольшими операциями синхронизации. Для типовых all-reduce при обучении — задержка сети не является определяющим фактором: GPU все равно дольше считает, чем ждет сеть.

Пропускная способность

На уровне спецификаций — паритет: 400G InfiniBand NDR и 400G RoCEv2 работают на одинаковых физических скоростях. По эффективной пропускной способности при NCCL all-reduce на 8-узловом кластере: InfiniBand NDR дает примерно 350 ГБ/с, RoCEv2 400G — 270–290 ГБ/с. Разница около 20–25%.

Реальный эффект на обучении

По данным MLCommons MLPerf Training 2024, кластеры на InfiniBand NDR показывают примерно 15–20% более высокую пропускную способность по токенам в секунду по сравнению с аналогичными RoCEv2-кластерами того же размера. Это при предобучении масштабных LLM (уровня Llama 3 405B).

Важное уточнение: этот разрыв значим при предобучении крупных моделей на сотнях GPU, где коммуникация занимает существенную долю времени итерации. Для задач, которые решает наш типовой корпоративный заказчик — fine-tuning и inference, а также предобучение моделей умеренного размера (до 30–70B параметров) на кластере из 8–32 узлов — разница либо незначима, либо полностью нивелируется правильной настройкой RoCEv2.

Крупнейшие гиперскейлеры — Meta, Microsoft, AWS (а также российские – Сбер, Yandex и не только) — уже несколько лет строят свои ИИ-кластеры в том числе с использованием RoCEv2/Ethernet именно по операционным соображениям: более широкая экосистема, нет vendor lock-in, стандартная инфраструктура.

Как требования к сети различаются по типу задачи

Это один из ключевых моментов, который часто теряется при проектировании: inference (инференс), fine-tuning и предобучение предъявляют принципиально разные требования к межузловому интерконнекту.

Inference (инференс): высокоскоростной интерконнект почти не нужен

При инференсе модель (если она помещается на GPU-узел) работает на одном узле. Межузловое взаимодействие нужно только для:

• балансировки запросов между репликами (HTTP/gRPC — стандартный 25 GbE более чем достаточно);

• disaggregated inference (разделение prefill и decode на разные узлы) — там нужна передача KV-cache, но ее паттерны гораздо менее требовательны, чем all-reduce при обучении.

Для инференс-конфигурации в ПАК «Скала^р МИИ» мы максимально используем PCIe-слоты под GPU: при размещении восьми карт на узле для задач инференса все высокопроизводительные слоты PCIe x16 отдаются под GPU-карты, а на клиентскую сеть используются порты 25 GbE и/или 100 GbE. Высокоскоростной интерконнект для inference-нагрузки — это подчас переплата за возможность, которую задача не использует.

Fine-tuning: умеренные требования, 100/400 GbE RoCEv2 закрывает задачу

Fine-tuning — это обучение на базе предобученной модели с заморозкой большей части весов. Обмен градиентами происходит только по дообучаемым слоям, а значит — объем синхронизации между узлами существенно меньше, чем при предобучении. 100/400 GbE RoCEv2 с правильной настройкой PFC/ECN для задач дообучения достаточно в большинстве практических сценариев.

Предобучение: здесь сеть становится определяющим фактором

Предобучение крупных моделей — единственный сценарий, в котором межузловой интерконнект напрямую определяет скорость обучения. При tensor parallelism на нескольких узлах более 75% всех байт, передаваемых между GPU при 3D-параллелизме, приходится именно на tensor-параллельную синхронизацию. Одиночный запрос к модели Llama 3.1 70B может требовать передачи до 20 ГБ данных синхронизации с каждого GPU.

Именно для этих задач в ПАК «Скала^р МИИ» при конфигурации под обучение в сервер устанавливается отдельный сегмент из четырех GPU-карт, а все высокопроизводительные PCIe-слоты, не занятые GPU, отдаются под сетевые карты 400 GbE — по одному 400 GbE порту на каждую GPU-карту. Это исключает конкуренцию карт за пропускную способность: каждая GPU имеет выделенный полный канал для синхронизации.

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