InfiniBand или RoCE для GPU-кластера: как выбрать сеть

Выбор между InfiniBand и RoCE нельзя свести к таблице «latency / bandwidth / цена».

Если один кластер построен как nonblocking fabric с двумя NIC на сервер, а второй имеет одну NIC и oversubscription 2:1, результат benchmark нельзя объяснить только разницей между InfiniBand и RoCE.

То же относится к GPU↔NIC topology, routing, congestion control и collective offload.

Поэтому правильная последовательность выбора выглядит так:

Workload

   ↓

Communication profile

   ↓

Сопоставимые fabric designs

   ↓

GPU↔NIC topology

   ↓

Congestion / routing model

   ↓

NCCL / RCCL collectives

   ↓

Contention test

   ↓

Actual application

   ↓

Operations + failure model + TCO

InfiniBand или RoCE: короткий ответ

Для современного GPU-кластера корректнее сравнивать:

InfiniBand RDMA fabric

vs

RoCEv2 RDMA fabric over Ethernet

а не InfiniBand против обычного TCP/IP Ethernet.

RoCE обеспечивает RDMA поверх Ethernet. Текущая NVIDIA Cumulus Linux documentation различает lossless и lossy RoCE configurations и отдельно задаёт traffic-class mapping, ECN и PFC behavior.

InfiniBand, в свою очередь, представляет специализированную fabric со своим management и routing stack. NVIDIA определяет Subnet Manager как ключевой компонент bring-up и routing InfiniBand fabric; UFM добавляет централизованное управление и monitoring.

Поэтому выбирать нужно законченные network architectures, а не названия протоколов.

Если большая часть этих данных неизвестна, выбирать InfiniBand или RoCE ещё рано.

Сначала проверьте, нужна ли scale-out RDMA fabric

Не любой GPU workload является сетевой задачей.

Если computation полностью помещается в одном сервере, основной GPU↔GPU traffic может проходить через NVLink, NVSwitch или PCIe.

InfiniBand/RoCE становятся критичными после выхода communication между compute nodes.

Тогда появляются операции вроде:

AllReduce

ReduceScatter

AllGather

AllToAll

Send / Receive

NCCL Tests предоставляет отдельные performance tests для различных collective operations, поэтому один all_reduce_perf нельзя считать универсальным представлением distributed workload.

Число GPU не определяет требования к сети

Два кластера по 64 GPU могут требовать совершенно разную fabric.

В одном workload вычислительные фазы длинные, а network synchronization относительно редкая.

В другом короткие compute phases регулярно чередуются с collectives.

Полезная модель:

Step time

≈

compute

+

communication, которое не удалось перекрыть compute

+

other waits

Поэтому перед выбором network technology нужно зафиксировать communication profile:

Если communication почти полностью перекрывается вычислением, двукратный рост синтетической network bandwidth необязательно даст сопоставимое сокращение step time.

Конечная метрика всё равно прикладная:

step time

job throughput

time-to-train

А вопрос, достаточно ли именно 100, 200 или 400 Gbit/s, относится уже к SS-012.

До benchmark нормализуйте hardware и topology

Это главный методологический принцип SS-011.

Нельзя сравнивать:

InfiniBand:

2 × 400G NIC/node

nonblocking

RoCE:

1 × 400G NIC/node

2:1 oversubscription

и делать вывод о superiority самого transport.

Для нормализованного comparison нужно зафиксировать:

Если это невозможно — тоже нормально. Но тогда результат называется сравнением двух production architectures, а не чистым сравнением InfiniBand и RoCE.

Есть два разных вида правильного comparison

Это различие важно зафиксировать ещё до тестов.

Нормализованный network benchmark

Задача — по возможности уменьшить число отличающихся переменных.

same workload

same nodes

same GPUs

same NIC count

comparable port rate

same oversubscription

same test

Такой тест удобен для исследования network path.

Production-design comparison

Задача — выбрать то, что реально будет куплено и эксплуатироваться.

Тогда InfiniBand architecture может использовать свой production routing и SHARP, а Spectrum-X — соответствующий RoCE/adaptive-routing/congestion-control profile.

В этом случае мы сознательно сравниваем законченные системы, а не пытаемся утверждать, что отличается только transport.

Финальными критериями становятся:

application performance

behavior under contention

failure behavior

operations

TCO

Port rate не равна application bandwidth

Надпись:

400G NIC

означает скорость конкретного link.

Она не говорит, сколько bandwidth получит workload end-to-end.

Между NIC и другим compute node находятся:

NIC count

→ rails

→ leaf

→ uplinks

→ spines

→ path selection

→ oversubscription

→ competing traffic

Поэтому:

400G port ≠ гарантированные 400 Gbit/s application bandwidth.

Особенно опасно просто складывать line rates нескольких NIC. Общий bottleneck выше по topology может появиться раньше.

Что представляет собой InfiniBand fabric

InfiniBand — это не просто RDMA transport.

Для fabric нужен management/routing plane. NVIDIA определяет Subnet Manager как routing engine, используемый для bring-up и routing management; UFM дополняет его централизованным управлением и performance monitoring.

Современные поколения добавляют дополнительные возможности. Например, NVIDIA Quantum-X800 — актуальная 800-Gb/s InfiniBand platform с adaptive routing, telemetry-based congestion control и SHARP v4 in-network computing.

Это делает InfiniBand сильным кандидатом для dedicated AI/HPC fabric.

Но из этого не следует:

установили InfiniBand — сеть автоматически настроена оптимально.

Остаются topology, routing, SM/UFM, firmware compatibility, adaptive-routing configuration, telemetry, rails и, если используется, SHARP.

InfiniBand — специализированный operational stack, а не zero-configuration network.

«У нас уже Ethernet» ещё не означает, что RoCE готов

Existing Ethernet infrastructure действительно может быть аргументом в пользу RoCE.

Можно повторно использовать часть operating model, automation, monitoring и competence.

Но production RoCE fabric требует согласованной configuration NIC и switches.

В текущей Cumulus Linux documentation для RoCE явно задаются traffic priorities, ETS, ECN, PFC в lossless mode и buffer behavior. NVIDIA также предупреждает, что RoCE configuration для одного поколения switch ASIC нельзя механически переносить на другое.

Поэтому:

RoCE-capable NIC + быстрый Ethernet switch ≠ готовая AI RoCE fabric.

Нужно проверять exact hardware, NOS, firmware и congestion-control design.

RoCE не означает «PFC обязательно везде»

Это важная техническая граница.

В текущем Cumulus Linux 5.16 документированы как lossless, так и lossy RoCE modes.

В default lossless configuration для RoCE priority используются ECN и PFC.

В lossy configuration ECN остаётся, а PFC для RoCE priority выключен.

Из этого следует только:

PFC не является универсально обязательной характеристикой любого возможного RoCE design.

Но нельзя сделать обратный вывод:

современный RoCE нужно строить без PFC.

Конкретная architecture может требовать именно lossless configuration.

Например, текущие Spectrum-X profiles содержат versioned настройки RoCE, adaptive routing и congestion control, предназначенные для определённой Reference Architecture.

Правильное правило:

Lossless/lossy mode, ECN, PFC и congestion-control settings выбираются как единый validated design конкретной платформы.

PFC и ECN — разные механизмы

Их не нужно объединять термином «настройка lossless».

PFC выполняет hop-by-hop pause для выбранного Ethernet priority. Затем switch priority сопоставляется traffic class через QoS configuration.

ECN маркирует congestion и позволяет endpoint'ам реагировать на перегрузку без того, чтобы описывать весь механизм как pause.

Текущая Cumulus configuration действительно отдельно задаёт priority→traffic-class mapping, ECN thresholds и PFC state.

Поэтому техническая спецификация RoCE должна хранить отдельно:

Priority / traffic-class mapping

ECN

PFC model

Buffers

Congestion-control profile

Routing / path selection

Строка:

RoCE enabled

не описывает production fabric.

Congestion model нужно проектировать заранее

Distributed training способен создавать синхронные elephant flows.

Если несколько потоков одновременно сходятся на одном output port, один congestion hotspot способен задержать отдельные ranks, а вместе с ними — весь collective.

Поэтому congestion control нельзя оставить как post-deployment tuning.

В Spectrum-X текущий profile содержит runtime parameters для RoCE, adaptive routing, congestion control и других network optimizations.

Общий архитектурный принцип:

Adaptive routing больше не разделяет InfiniBand и Ethernet по принципу «есть / нет»

Quantum-X800 имеет adaptive routing.

Spectrum-X также использует adaptive-routing mechanisms и в актуальной документации имеет single-, dual- и quad-plane architectures для определённых GPU/NIC generations. Конкретные варианты зависят от Reference Architecture, NIC и software release, поэтому всегда проверяется exact supported configuration.

Следовательно, старая таблица:

InfiniBand → adaptive routing

RoCE       → static ECMP

для современных AI fabrics слишком грубая.

Сравнивать нужно конкретные routing mechanisms и конкретные generations.

SHARP нужно явно фиксировать в benchmark

NVIDIA SHARP позволяет переносить часть collective aggregation в switch network. UFM documentation прямо описывает его как offload collective operations в network infrastructure.

Если production InfiniBand architecture будет использовать SHARP, его разумно включить в production-design comparison.

Но benchmark report должен записывать:

SHARP:

enabled / disabled / not applicable

Иначе improvement можно ошибочно объяснить только самим InfiniBand transport.

Особенно осторожно нужно интерпретировать при таких offloads показатель busbw.

GPUDirect RDMA не является эксклюзивным преимуществом InfiniBand

GPUDirect RDMA описывает direct peer communication между GPU memory и PCIe peer, например сетевым адаптером.

Он не означает:

InfiniBand → GPUDirect

RoCE       → CPU copy

Современные Ethernet/RoCE adapters также используются с GPUDirect RDMA при поддерживаемом hardware/software path.

Поэтому для обеих architectures нужно проверять:

GPU

↕

PCIe topology

↕

NIC

↕

RDMA fabric

а не делать вывод из названия network protocol.

GPU↔NIC locality проверяется до сравнения сети

Если InfiniBand NIC находится в удачной PCIe locality относительно GPU, а RoCE NIC — за другим CPU socket, мы уже сравниваем не только network technologies.

В GPUDirect RDMA topology особенно важно размещение GPU и peer network device; NVIDIA, например, отдельно требует соответствующего PCIe topology в virtualized configurations и указывает необходимость общего I/O root complex.

Подробная PCIe/NUMA проверка относится к SS-009.

В SS-011 достаточно правила:

AllReduce не является универсальным network benchmark

Для distributed GPU workload могут быть важны разные operations.

NCCL Tests отдельно определяет AllReduce, ReduceScatter, AllGather, AllToAll и другие tests. Их traffic semantics различаются, поэтому даже busbw вычисляется по разным correction factors.

Значит:

хороший all_reduce_perf

не доказывает автоматически:

сеть оптимальна для любого distributed AI workload

Если фактический communication profile содержит существенный many-to-many traffic, включая некоторые expert-parallel/MoE designs, нужно тестировать именно релевантные AllToAll/AllToAllV operations.

Benchmark выбирается из workload.

Message size тоже должен соответствовать workload

Один результат вида:

AllReduce = 300 GB/s

почти ничего не говорит без message size.

NCCL Tests различает operation time и bandwidth metrics. На малых transfers сильнее проявляется constant overhead; на крупных время всё больше определяется размером и available bandwidth.

Поэтому test должен охватывать production-relevant диапазон:

small messages

       ↓

medium

       ↓

large

И рядом с каждым результатом фиксируются:

collective

message size

ranks

nodes

NICs/node

software version

Как читать algbw и busbw

NCCL Tests определяет:

algbw = message size / operation time

А busbw получает из algbw, применяя коэффициент, зависящий от collective и количества ranks. Например, для AllReduce используется 2(n−1)/n, для ReduceScatter и AllGather — (n−1)/n.

Следовательно:

algbw и busbw — не две подписи одной физической скорости.

И особенно важно:

busbw не является hardware counter фактических байтов на проводе.

Это расчётная normalized metric nccl-tests. При in-network collective offload, нестандартном algorithm path или аналогичных optimizations интерпретировать её как буквально измеренную wire bandwidth особенно опасно.

Для выбора architecture основные KPI лучше располагать так:

collective operation time

        ↓

application communication time

        ↓

training step time

А algbw/busbw использовать для диагностики и сопоставления тестов.

Average performance недостаточно для shared cluster

Синхронная distributed operation чувствительна к slow ranks.

Текущий nccl-tests умеет выводить average/min/max across ranks, а при --per_iter_timing — статистику отдельных iterations, включая i_p99. При этом default benchmark выполняет только 20 measured iterations, а документация предупреждает, что при числе samples меньше 100 i_p99 может совпасть с maximum.

Поэтому:

Default 20 iterations нельзя использовать как убедительную характеристику p99 fabric.

Для tail analysis нужен более длительный run и заранее определённая methodology.

Но универсальное число iterations тоже придумывать не нужно.

Нужны baseline и contention tests

Benchmark на пустой fabric показывает только лучший сценарий.

Для shared cluster нужен как минимум второй режим:

BASELINE

target collective

на свободной fabric

и:

CONTENTION

тот же collective

+

background traffic

Сравниваем:

operation time

max-rank behavior

tail

application step time

Именно такой тест показывает, насколько architecture остаётся предсказуемой при congestion.

Не нужно вводить универсальный норматив вроде:

degradation < 5%

SLA должен исходить из реального workload.

Storage traffic может быть частью того же congestion domain

Если через ту же fabric идут:

GPU collectives

+

dataset transfers

+

checkpoint traffic

то storage становится частью network workload.

Это нужно явно зафиксировать:

Storage shares compute fabric:

YES / NO

Если YES, contention test нужно выполнять и при репрезентативной storage нагрузке.

Если compute и storage networks разделены, behavior будет другим.

Multi-rail и oversubscription — часть architecture

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

NICs/node

rails/planes

leaf downlinks

leaf uplinks

spines

oversubscription

Если одна сторона имеет две 400G NIC, а другая одну, difference нельзя приписывать protocol family.

То же относится к oversubscription.

Особенно полезно считать не только normal-state topology, но и degraded state.

Например:

Normal:

1:1

After one spine/link failure:

?

Именно такое поле помогает понять реальную failure architecture.

Failure model обязателен, fault injection — нет

Для каждого проекта заранее фиксируем ожидаемое поведение при:

link failure

NIC failure

rail failure

leaf failure

spine failure

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

Разделяем:

Failure model — описывается всегда.

Fault-injection test — проводится тогда, когда degraded operation входит в SLA и его необходимо доказать.

Это особенно важно для небольших dedicated training clusters, где допустимым результатом крупного failure может быть остановка и перезапуск job.

Greenfield и existing Ethernet дают разные decision paths

В greenfield AI/HPC cluster обе fabrics можно проектировать с нуля:

NIC/HCA

switches

topology

routing

firmware

software

telemetry

Тогда сравниваются две законченные architectures.

В существующем Ethernet data center у RoCE появляется потенциальная возможность reuse infrastructure и operational practices.

Но слово потенциальная здесь критично.

Если существующие switches, QoS, telemetry или congestion features не соответствуют требуемой RoCE architecture, compute fabric всё равно придётся менять.

Поэтому brownfield assessment должен отвечать:

Какие именно существующие components остаются в final validated design?

а не просто:

Ethernet у нас уже есть.

Operational competence — самостоятельный критерий

Fabric должна работать не только во время acceptance benchmark.

Её нужно мониторить, обновлять, расширять и диагностировать.

RoCE environment требует компетенций вокруг Ethernet/RDMA QoS, ECN, PFC там, где он используется, buffers, congestion telemetry, routing и NIC-switch interaction.

InfiniBand требует компетенций вокруг SM/UFM, routing, fabric telemetry, HCA/switch firmware, adaptive routing и дополнительных mechanisms вроде SHARP.

Subnet Manager действительно является частью bring-up и routing InfiniBand fabric, а UFM содержит performance/fabric management components.

Поэтому поле:

Есть сетевой инженер:

YES

ничего не гарантирует.

Нужно отдельно понимать:

RoCE production competence

InfiniBand production competence

Hardware и software являются одной configuration

Benchmark бессмысленно сохранять без software matrix.

Минимальная запись:

GPU model

NIC/HCA model

NIC firmware

switch model

switch NOS/firmware

GPU driver

NCCL/RCCL

UCX/MPI — если используются

IB/RoCE configuration profile

Spectrum-X наглядно показывает этот принцип: текущий NIC profile напрямую привязывается к конкретной Reference Architecture и содержит runtime settings для RoCE, adaptive routing и congestion control.

Acceptance: четыре уровня вместо одного benchmark

Приёмку удобно разделить:

На RDMA layer можно использовать verbs/perftest. Пакет perftest предоставляет отдельные bandwidth и latency benchmarks и позволяет работать с RDMA path как на IB, так и на Ethernet link types.

Но результат:

ib_write_bw высокий

ещё не означает:

distributed training быстрый

Следующий слой — NCCL/RCCL.

А последний — реальная задача.

Минимальный NCCL/RCCL acceptance

Набор tests выбирается из workload.

Базовая форма:

Single-node test при этом нужно хранить отдельно.

Он может преимущественно характеризовать NVLink/NVSwitch/PCIe topology внутри одного сервера.

Для выбора InfiniBand/RoCE важен multi-node result на целевом масштабе.

Финальный критерий — реальный workload

Даже NCCL/RCCL являются synthetic collective tests.

Финальное сравнение выполняется на:

same workload

same parallelism

same batch/config

same software stack

и измеряет:

training step time

communication time

GPU utilization

job throughput

time-to-train

Возможна ситуация, когда одна fabric существенно выигрывает в synthetic network benchmark, но почти не меняет application throughput.

Это означает не то, что benchmark «неправильный».

Это означает:

И это важный результат для закупки.

TCO считаем после технической нормализации

Сравнивать цену одного switch port недостаточно.

В TCO входят:

Поэтому универсальное:

Ethernet дешевле InfiniBand

не является достаточным архитектурным аргументом.

Сравнивать нужно стоимость двух designs, которые уже способны выполнить одинаковый workload SLA.

Decision Matrix: InfiniBand или RoCE

Главный рабочий элемент статьи:

Эта таблица не должна превращаться в балльный рейтинг.

Некоторые требования — hard constraints.

Когда InfiniBand становится сильным кандидатом

InfiniBand особенно логично рассматривать, когда строится dedicated greenfield AI/HPC fabric, communication находится в critical path, требуется специализированная validated architecture и команда готова эксплуатировать собственный IB stack.

Современные поколения дают специализированные возможности. Например, Quantum-X800 объединяет 800-Gb/s connectivity с adaptive routing, congestion control и SHARP v4.

Но покупать InfiniBand только потому, что «так делают HPC-кластеры», недостаточно.

Нужно доказать преимущество именно для своего workload и production design.

Когда RoCE становится сильным кандидатом

RoCE особенно логично рассматривать, когда Ethernet является стратегическим infrastructure standard, нужную architecture можно построить на совместимых components, команда умеет эксплуатировать RDMA Ethernet и collective SLA подтверждается на целевой topology.

Современные Spectrum-X reference architectures показывают, что такой Ethernet уже является специализированной AI fabric с versioned NIC tuning, congestion control, adaptive routing и поддержкой разных plane configurations.

Поэтому RoCE сегодня нельзя описывать как:

обычный Ethernet, на котором включили RDMA.

Это самостоятельный high-performance network design.

Когда вопрос InfiniBand или RoCE задан слишком рано

Если неизвестны:

critical collectives

message sizes

communication share

NIC count

rails

topology

oversubscription

выбирать protocol family преждевременно.

Сначала определяется network workload.

Затем строятся две candidate architectures.

И только после этого возникает осмысленный InfiniBand-vs-RoCE comparison.

Полный порядок выбора fabric

1. Зафиксировать multi-node workload

              ↓

2. Определить parallelism

              ↓

3. Найти critical collectives

              ↓

4. Измерить communication share

              ↓

5. Зафиксировать message-size range

              ↓

6. Определить target scale

              ↓

7. Построить candidate IB/RoCE designs

              ↓

8. Нормализовать NICs / rails / topology

              ↓

9. Проверить GPU↔NIC locality

              ↓

10. Определить routing/congestion model

              ↓

11. Определить failure model

              ↓

12. Зафиксировать software/firmware stack

              ↓

13. Проверить physical/RDMA layer

              ↓

14. Выполнить NCCL/RCCL baseline

              ↓

15. Выполнить contention test при необходимости

              ↓

16. Проверить real workload

              ↓

17. Сравнить operations и TCO

              ↓

18. Выбрать fabric

Worksheet для выбора InfiniBand или RoCE

WORKLOAD

Application/model:

Framework:

Nodes:

GPUs/node:

PARALLELISM

DP:

TP:

PP:

EP:

COMMUNICATION

Critical collectives:

Message-size range:

Communication time/step:

Compute/communication overlap:

SERVER

GPU:

NIC/HCA:

NICs/node:

GPU↔NIC locality:

GPUDirect required:

GPUDirect verified:

FABRIC

Candidate: InfiniBand / RoCE

Link class:

Rails:

Planes:

Leaf/spine topology:

Normal oversubscription:

Degraded oversubscription:

Storage shares fabric:

ROCE

Lossy / lossless:

Priority / traffic-class mapping:

PFC model:

ECN:

Congestion-control profile:

Buffers:

Routing/adaptive routing:

Reference architecture/version:

INFINIBAND

Subnet Manager/UFM:

Routing:

Adaptive routing:

SHARP:

Telemetry:

SOFTWARE

GPU driver:

NIC firmware:

Switch firmware/NOS:

NCCL/RCCL:

UCX:

MPI:

VALIDATION

Link health:

RDMA path:

Collectives tested:

Message-size sweep:

Iterations:

Operation time:

algbw:

busbw:

Max-rank result:

Tail metric:

Baseline:

Contention:

Actual training step:

FAILURE MODEL

Link:

NIC:

Rail:

Leaf:

Spine:

Fault-injection required:

OPERATIONS

RoCE competence:

InfiniBand competence:

Monitoring:

Upgrade process:

Incident process:

RESULT

Chosen fabric:

Hard blockers:

Unresolved risks:

InfiniBand или RoCE: итоговый критерий

Корректного универсального ответа:

InfiniBand быстрее

не существует.

Так же недостаточно:

RoCE дешевле и проще интегрировать.

Сначала две candidate architectures должны пройти одинаковый workload и сопоставимую methodology.

После этого решение выглядит так:

Подходящая GPU fabric

=

подходящая topology

+

достаточная collective performance

+

предсказуемость при contention

+

приемлемый failure model

+

совместимый software stack

+

поддерживаемая operations model

+

приемлемый TCO

Короткое правило:

Получить схему сети GPU-кластера

Для проектирования нужны число compute nodes и GPU, используемый parallelism, critical collectives и message sizes, количество NIC на node, предполагаемая topology и oversubscription, требования к GPUDirect RDMA, concurrent/storage traffic и отказоустойчивости.

По этим данным можно построить сопоставимые InfiniBand и RoCE designs, определить потенциальные bottlenecks и подготовить программу приёмочных RDMA/NCCL/RCCL-тестов до закупки fabric.