Сеть для GPU-кластера: когда достаточно 25/100GbE

Зачем вообще считать сеть, а не брать «с запасом»

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

В GPU-кластере важны не только гигабиты в спецификации, но и стабильность. Если сеть то «летит», то проседает, обучение замедляется волнами: итерации то ускоряются, то внезапно растягиваются. На практике это выглядит как загадочные провалы в производительности, которые сложно объяснить одними вычислениями.

«Без лишних трат» в терминах сети означает купить ровно то, что дает заметный эффект на ваших задачах, и не платить за лишнее там, где сеть не ограничивает время обучения. Дорогим бывает не только порт 100GbE, но и все вокруг него: коммутаторы нужного класса и их лицензии, оптика и кабели (включая запасные), питание и охлаждение, место в стойке, требования к квалификации команды, а также риски несовместимости и долгие разборы проблем.

Простой пример: команда собирает 8 серверов с GPU для обучения моделей и берет «самое быстрое» подключение везде. Через месяц выясняется, что основная работа - чтение датасета и периодическая запись чекпойнтов, а обмен между узлами идет редко. Деньги ушли в скорость, которая почти не ускоряет обучение, а узким местом осталась система хранения или настройка софта.

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

В проектах уровня дата-центра это особенно заметно: как системный интегратор, GSE.kz часто видит, что одна и та же сумма может дать либо «дорогие порты», либо предсказуемую работу кластера с понятным запасом роста.

Какие нагрузки в GPU-кластере создают сетевой трафик

В GPU-кластере сеть нагружается не «всегда», а в конкретные моменты и по разным причинам. Поэтому сначала полезно понять профиль: обучение или инференс.

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

При распределенном обучении главный потребитель сети - обмен данными между GPU на разных серверах. Это коллективные операции (например, all-reduce), когда градиенты или параметры модели постоянно синхронизируются. Чем больше GPU и чем больше модель, тем чаще и тяжелее эти обмены. Если обмены идут медленно, GPU начинают ждать друг друга, и время обучения растет даже при мощных ускорителях.

Отдельная история - пайплайн данных. Даже если обучение идеально настроено, сеть может упереться в доставку датасета и результаты препроцессинга: чтение из сетевого хранилища, запись чекпойнтов и логов, раздача данных по воркерам (data loader), обмен с кешами и очередями задач, а также «сервисы вокруг» вроде метрик и трекинга экспериментов.

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

Если вы планируете кластер и интеграцию под него, важно заранее разделить потоки: GPU-GPU обмен, доступ к хранилищу и сервисный трафик. Тогда становится ясно, где достаточно 25/100GbE, а где сеть действительно определяет скорость обучения.

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

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

Когда модель активно обменивается градиентами между несколькими GPU на разных серверах, можно упереться в пропускную способность. Признак простой: GPU простаивают и ждут сеть, а трафик держится близко к потолку линка длительное время. Здесь помогают более широкие каналы, меньше oversubscription и правильная схема подключений.

Задержка и джиттер важнее, когда обмен идет короткими «рывками» и часто: много небольших сообщений, синхронизации, барьеров. Тогда даже высокая полоса не спасает, если пакеты приходят с разным временем и процессы постоянно ждут друг друга. На графиках это часто выглядит как «нормальная» средняя задержка, но с редкими всплесками, которые бьют по итерации обучения.

Важно не путать «25/100GbE на порту» и скорость, которую видит приложение. На нее влияют накладные расходы протоколов, настройки MTU, очереди в коммутаторах, конкурирующие потоки и то, как сам фреймворк обучения упаковывает обмен.

Потери пакетов обычно хуже, чем просто «медленнее». Даже доли процента потерь приводят к повторным передачам, провалам по задержке и нестабильному времени итераций. Для распределенного обучения это особенно болезненно: одна отставшая нода тормозит всех.

Практичный способ отличить причины:

• Упор в пропускную способность: длительная высокая загрузка линка и ровное, но низкое ускорение при добавлении GPU.
• Упор в задержку и джиттер: загрузка линка средняя, но время итераций плавает и растет на синхронизациях.
• Потери: появляются редкие, но большие провалы по скорости и всплески задержки.

Если вы планируете кластер, полезно заранее мерить не только гигабиты, но и стабильность задержки под нагрузкой. Именно это часто объясняет, почему одинаковые «100GbE» в спецификации дают разное время обучения на практике.

Когда хватит 25GbE, а когда уже нужно 100GbE

Выбор между 25GbE и 100GbE лучше начинать не с «хочу быстрее», а с вопроса: где именно сеть теряет время - между GPU, между узлами или на пути к хранилищу. Для многих пилотных и средних кластеров 25GbE дает предсказуемую работу без лишних затрат, если задачи не упираются в обмен градиентами и коллективные операции.

25GbE чаще всего достаточно, когда:

• обучение идет на 1-2 GPU в узле или на небольшом числе узлов, и масштабирование не «ломается» при добавлении еще пары узлов;
• модели и батчи умеренные, а время итерации почти не меняется при росте числа GPU;
• параллельных задач немного, нет постоянной конкуренции за один и тот же аплинк;
• трафик к хранилищу идет отдельным путем (или хотя бы не смешивается с GPU-GPU на одном узком месте).

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

100GbE обычно оправдан, когда:

• планируется рост до десятков GPU и дальше, и вы хотите, чтобы добавление узлов давало реальное ускорение;
• используется распределенное обучение на многих узлах с частыми all-reduce и обменами;
• на одном коммутаторе висит много узлов, и аплинки становятся главным ограничением;
• нужно отделить трафик обучения от трафика данных, не усложняя схему множеством сетей.

Оценку роста лучше делать на 12-18 месяцев: сколько узлов, сколько GPU в узле, сколько одновременных задач. Полезный прием - считать «целевую конфигурацию», а затем выбирать сеть так, чтобы она держала не только среднюю нагрузку, но и пики при синхронизациях.

Отдельно учитывайте трафик к хранилищу. Если даталоадеры читают большие наборы и одновременно идет чекпоинтинг, сеть может забить uplink, даже если GPU-GPU обмен сам по себе умеренный. Здесь помогает либо выделение сетевого пути под storage, либо переход на 100GbE для узлов, которые одновременно обучают и активно читают данные.

Где низкая задержка действительно критична

Низкая задержка важна не всегда. Если обмен идет крупными блоками и сеть загружена равномерно, чаще упираются в пропускную способность. Но есть сценарии, где именно задержка и ее разброс напрямую увеличивают время обучения.

Самый частый случай - распределенное обучение с синхронизацией между узлами. Коллективные операции вроде all-reduce или all-gather заставляют все GPU ждать друг друга. Если один узел получает данные чуть позже, вся группа стоит. В итоге вы видите, что GPU загружены не на 100%, хотя «по гигабитам» запас еще есть.

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

Еще один сложный случай - смешанные нагрузки. Когда на тех же линках одновременно идет обучение и, например, выдача результатов (инференс) или загрузка данных, возрастает конкуренция за очереди на портах. Даже если средняя задержка «нормальная», хвостовые значения (p95-p99) могут резко вырасти, и шаг обучения начнет дергаться.

Наконец, «один медленный линк» способен тормозить всю группу. Это не обязательно поломка. Достаточно ошибочной скорости порта, перегруженного аплинка или неудачной раскладки кабелей. Типичные признаки, что задержка стала критичной:

• время шага нестабильное, хотя загрузка GPU и CPU выглядит нормальной;
• при росте числа узлов эффективность падает сильнее ожидаемого;
• мониторинг показывает очереди или дропы на одном-двух портах;
• небольшое ухудшение на одном сервере замедляет весь пул.

В многузловых конфигурациях это проявляется особенно явно: сеть начинает определять, насколько хорошо «склеиваются» GPU в одну команду.

Топология и oversubscription: как не потерять производительность в схеме

Схема подключения в GPU-кластере влияет не меньше, чем цифра на порту. Два кластера с одинаковыми 25/100GbE могут вести себя по-разному, если в одном сеть построена аккуратно, а в другом трафик постоянно упирается в узкие места.

Какие схемы встречаются и чем они отличаются

Самый частый вариант в дата-центрах - spine-leaf: серверы подключаются к коммутаторам в стойке (ToR/leaf), а те сходятся в spine. Такая фабрика хорошо масштабируется и проще прогнозируется по пропускной способности.

Иногда пытаются сэкономить и делают «кольца» или каскады, когда один коммутатор подключен к следующему. В реальной нагрузке это часто превращается в лотерею: один перегруженный линк начинает тормозить целые группы узлов, а отладка затягивается.

Oversubscription, простыми словами, это когда суммарная скорость портов вниз (к серверам) больше, чем скорость вверх (к магистрали). Например, 16 серверов по 25GbE дают 400Gbps вниз, а аплинков всего 200Gbps. Пока трафик локальный и не выходит из ToR, вы этого не заметите. Но как только обучение или инференс начинает активно обмениваться данными между узлами, появятся очереди, потери и скачки задержки.

Где нужна неблокирующая фабрика, а где можно упростить

Неблокирующая (или близкая к ней) фабрика нужна там, где ожидаются частые одновременные обмены между многими GPU-узлами (типично для распределенного обучения). В более простых сценариях часто хватает умеренного oversubscription, если большинство потоков остается внутри стойки или пары стоек, межузловой обмен идет короткими фазами, а критичные сервисы отделены в отдельные VLAN или фабрику.

При перегрузке ключевую роль играют буферы коммутатора и очереди. GPU-трафик часто идет рывками (microbursts): на секунду все отправили данные одновременно, и узкое место моментально забивается. Если буферы маленькие или очереди настроены неудачно, вы получаете не просто «меньше скорости», а нестабильность: растущую задержку и повторные передачи.

Практичный ориентир: сначала решите, сколько east-west трафика будет между узлами, затем подберите топологию и коэффициент oversubscription под этот профиль, а не под абстрактное «возьмем с запасом».

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

Начните с простого: вам нужна не «самая быстрая» сеть, а такая, которая не тормозит реальные задачи и не заставляет переплачивать за лишний запас.

1) Опишите сценарии и их «сетевой профиль»

Соберите 3-4 типовых сценария и запишите, что именно происходит с данными. Например: обучение на нескольких узлах (много обмена между GPU), инференс (важнее стабильность и предсказуемость), ETL и подготовка датасетов (упор в хранилище), загрузка и чекпойнты (пики трафика).

Чтобы это было легко согласовать, оформите как короткий список:

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

2) Соберите базовые метрики и задайте цель

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

Дальше зафиксируйте целевой масштаб на 6-12 месяцев: сколько узлов и GPU планируется, и какое «допустимое» время обучения. Пример: сейчас 4 узла, через год 12, и обучение не должно расти по времени больше чем на 15-20% при масштабировании.

3) Выберите скорости линков и план роста

После этого проще принять решение по 25GbE или 100GbE: вы выбираете не скорость «в вакууме», а скорость под конкретные пики (обмен между узлами, чекпойнты, чтение датасета). Заложите резерв на рост, но сразу продумайте модернизацию без полной замены: порты с возможностью апгрейда, запас по оптике и кабелям, понятный путь расширения spine-leaf.

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

Нагрузочные тесты до закупки: как проверить сеть на практике

Покупать сеть «на глаз» рискованно: можно переплатить за 100GbE там, где хватило бы 25GbE, или наоборот упереться в узкое место и потерять время обучения. Нагрузочные тесты переводят разговор в цифры: сколько реально проходит трафика, как ведет себя задержка и что происходит при одновременных потоках.

Что именно измерять

Важны не только пиковые значения, а поведение под нагрузкой, близкой к будущей:

• пропускная способность: один поток и много потоков (aggregate);
• задержка: средняя и хвосты (редкие, но большие значения);
• потери и ретрансляции: даже небольшой процент может «убить» стабильность;
• джиттер: разброс задержки, особенно при смешанных нагрузках;
• повторяемость: одинаковый результат в серии прогонов, без провалов.

Как собрать тестовый стенд

Часто достаточно 2-8 узлов, даже если кластер будет больше. Главное - повторить тип трафика: «все со всеми» для межузлового обмена и отдельный поток к хранилищу.

Практичный набор тестов: iperf3 для throughput (несколько параллельных потоков), ping для базовой задержки, а при наличии RDMA - простые RDMA-тесты, чтобы увидеть разницу по CPU и хвостам задержки.

Полезно сделать тест «в лоб»: одновременно запускаете обмен между узлами (например, 4-8 пар потоков) и параллельно нагружаете сеть к хранилищу. Частая ситуация: по отдельности все «зеленое», а вместе появляются потери и скачки задержки.

Результаты фиксируйте в простой таблице «ожидание vs факт»: цель по Gb/s, допустимая задержка, допустимые потери (обычно 0), фактические значения и условия теста (количество потоков, длительность, размер пакетов). Так проще сравнить 25GbE и 100GbE еще до закупки.

Как интерпретировать результаты тестов и не ошибиться с выводами

Цифры из iperf-подобных тестов сами по себе не отвечают на главный вопрос: будет ли на этой сети нормально жить обучение. Поэтому смотрите не только на «пиковую скорость», а на повторяемость результатов и поведение под нагрузкой.

Сначала сравните тест на «чистой» сети и тест, когда рядом идет фоновый трафик (копирование датасетов, мониторинг, бэкапы). Если на чистой сети все красиво, а при фоне резко растут задержки или падает пропускная способность, это сигнал, что сеть или настройки плохо держат конкуренцию потоков. Для GPU-кластера это часто важнее абсолютного максимума.

Настройки, которые реально меняют картину

Без «магии» проверьте несколько переключателей: MTU, очереди на портах и настройки драйверов NIC.

• MTU: если при большем MTU растет стабильная скорость и падает загрузка CPU, это хороший знак. Если появляются потери или «рваная» задержка, лучше откатить и разбираться по шагам.
• Очереди и RSS: если один поток упирается в одно ядро CPU, тест может показать «плохую сеть», хотя проблема на хосте.
• Драйверы и прошивки: после обновления иногда меняется стабильность задержки даже при той же средней скорости.

Что считать тревожным сигналом

Обычно настораживают не разовые пики, а повторяющиеся симптомы:

• просадки скорости на 20-30% и больше при повторе тех же условий;
• нестабильная задержка (скачки в разы), особенно на фоне трафика;
• потери пакетов, ретрансмит на TCP или «дырки» в UDP;
• сильная разница между направлениями (туда нормально, обратно плохо).

Если тесты «падают», не спешите обвинять сеть. Пример: вы копируете данные с NVMe, и все упирается в CPU шифрования или дисковую подсистему. Проверьте загрузку CPU, скорость дисков и то, что приложение не делает лишние копии данных в памяти.

На практике удобно фиксировать результаты в двух режимах: «сеть как есть» и «как будет в жизни» (с параллельными задачами). Так проще понять, достаточно ли 25/100GbE, или проблема не в ширине канала, а в стабильности и настройках.

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

Самая дорогая ошибка - покупать сеть «по максимуму», не проверив, куда реально уходит время. В итоге бюджет сгорает на портах, а обучение почти не ускоряется.

Типичные ситуации:

• Берут 100GbE «везде», хотя упор не в сети между GPU, а в хранилище, CPU или настройках стека. Пример: узлы с 8 GPU получают данные с хранилища по 10GbE, и ускорение сети между узлами почти не меняет итоговое время эпохи.
• Делают слишком высокий oversubscription и получают «случайные» узкие места. На бумаге суммарная полоса красивая, но в пике несколько узлов попадают в одну и ту же «бутылку», и тренировка то летит, то проседает.
• Смотрят только на среднюю задержку и пропускают джиттер и потери под нагрузкой. Даже редкие микропотери или скачки задержки дают длинные хвосты в синхронизации градиентов, и вы видите это как странные паузы на GPU.
• Не планируют рост. Добавили 4-8 узлов, поменялась картина east-west трафика, и сеть стала вести себя непредсказуемо, хотя формально портов и гигабит хватает.
• Тестируют синтетику, а не свой сценарий. Iperf на одном потоке или короткий тест «на ночь» не показывает, что будет при вашем размере батча, числе GPU и реальном I/O.

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

Это решается дисциплиной до закупки: фиксируете 1-2 типовых тренировочных задания, прогоняете их на тестовом стенде и смотрите не только скорость, но и стабильность. Если вы собираете кластер через интегратора, имеет смысл включить в план приемки именно такие «живые» проверки, а не только паспортные цифры коммутаторов.

Короткий чеклист и следующие шаги

Если вы подбираете сеть для GPU-кластера, важнее всего зафиксировать реальные потоки: между GPU-узлами, к хранилищу и к сервисам (логирование, метрики, контроль).

Короткий чек, который помогает быстро отсеять лишнее и не забыть критичное:

• Скорости: какая доля трафика идет east-west (между узлами) и north-south (к хранилищу).
• 25GbE или 100GbE: сколько одновременных потоков будет в пике. Один тяжелый job с большим числом GPU может забить 25GbE на аплинке быстрее, чем несколько мелких задач.
• Задержка: какие задачи чувствительны к микрозадержкам. Для распределенного обучения важна не только средняя, но и хвосты (p95/p99).
• Топология spine-leaf и oversubscription: какой коэффициент вы допускаете на аплинках.
• Нагрузочное тестирование: прогон на пропускную способность, задержку и потери под параллельной нагрузкой (не один iperf, а несколько потоков плюс фон к хранилищу).

Чтобы требования прошли тендер и потом помогли на приемке, описывайте их как измеримые критерии: целевая пропускная способность между узлами при N параллельных потоках, допустимые p95/p99 задержки на размере сообщения X, отсутствие потерь пакетов при заданной нагрузке, а также подтвержденная схема (количество leaf/spine, скорости портов, коэффициент oversubscription).

Следующий шаг - пилот под ваши сценарии: прогнать типовые задачи и синтетические тесты на выбранной топологии и скоростях. Это удобно делать вместе с интегратором, например с GSE.kz (gse.kz), чтобы одновременно подобрать серверы, коммутаторы и настройки под целевую нагрузку, а не под «среднюю температуру по рынку».