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

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

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

Сеть — это, пожалуй, самое недооцененное звено во всей ИИ-инфраструктуре. Когда заказчик закладывает бюджет, в первую очередь он думает о GPU и о серверах. Сеть появляется в расчетах в формате «ну там поставим что-нибудь достаточно быстрое». А потом обнаруживается, что именно сеть убивает производительность при distributed training (распределенном обучении ^[3]), создает непредсказуемые задержки и превращает дорогой 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. Суть вот в чем: один сервер записывает данные напрямую в память ^[4] другого, минуя CPU обоих и операционную систему. Это принципиально меняет картину по сравнению с классической TCP/IP-передачей:

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

Это ключевой технический момент, который нужно понять, чтобы правильно проектировать сеть.  lossless поведение ^[5] при использовании 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-метки коммутатора с реакцией ^[6] сетевой карты (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 ^[7], кластеры на 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 имеет выделенный полный канал для синхронизации.

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