От одного HGX до кластера: как масштабируют ИИ-инфраструктуру

Когда пилоты и первые рабочие модели уже стабильно работают на одном сервере NVIDIA HGX, масштабирование перестаёт быть вопросом закупки ещё одного ускорителя. Нужно понять, в какой момент один сервер становится ограничением — для модели, пользователей и требований к доступности — и заранее спроектировать кластерную инфраструктуру. Это продолжение разговора о запуске LLM на одном HGX: теперь речь о переходе к GPU-кластеру.

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

Когда одного сервера уже недостаточно

Переход к кластеру лучше планировать до того, как очередь запросов начнёт расти. Основные признаки:

Память и размер модели. Веса модели, служебная память для хранения контекста, пакет запросов и служебные буферы не помещаются в суммарный объём видеопамяти одного сервера с восемью видеокартами при выбранной точности и длине контекста. Тогда требуется распределять модель между несколькими серверами.

Время обучения и конкуренция за ресурсы. Обучение или дообучение не укладывается в допустимое время, либо обучение и инференс конкурируют за одни GPU. Для параллельных задач нужны изоляция и отдельная вычислительная ёмкость.

SLA и отказоустойчивость. Требуются параллельная обработка запросов, резерв при выходе сервера из строя и предсказуемое время ответа в пиковые часы. Один сервер остаётся одной зоной отказа, независимо от числа GPU внутри.

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

H200, B200 или B300: от чего отталкиваться

Ориентиры по объему видеопамяти и пропускной способности памяти на один GPU:

Сервер DGX B300 включает восемь карт B300 и 8 × 288 ГБ = 2,3 ТБ видеопамяти HBM3e. Производительность системы:

•       72 PFLOPS FP8
•       144 PFLOPS FP4
•       NVLink/NVSwitch 5-го поколения: 14,4 ТБ/с суммарной пропускной способности для всех восьми GPU внутри сервера
•       Сеть: 8 × ConnectX-8 SuperNIC, 8 × 800 Гбит/с (IB XDR / Ethernet)

Важно: NVLink 5-го поколения обеспечивает 14,4 ТБ/с агрегированно на весь сервер, а не 1 800 ГБ/с на каждый GPU. Цифра 1 800 ГБ/с относится к архитектуре NVL72, где GPU соединены через внешние NVLink Switch со всеми 71 соседними GPU.

Как строится GPU-кластер

Иерархия проекта: GPU → сервер DGX/HGX → Scalable Unit (SU) → SuperPOD. Каждый уровень — это строго определённая единица с тестированной конфигурацией, кабельными схемами и референсной архитектурой NVIDIA.

Рис. 1. Иерархия GPU-кластера: от GPU B300 до DGX SuperPOD. Источник: NVIDIA RA-11339-001

GPU и сервер: NVLink как внутренняя шина

Внутри сервера DGX B300 восемь GPU B300 соединены через два NVSwitch 5-го поколения. Это позволяет каждому GPU обращаться к памяти любого другого GPU с суммарной пропускной способностью 14,4 ТБ/с — в сотни раз быстрее, чем через PCIe. Именно это делает возможным эффективный тензорный параллелизм внутри одного сервера без потерь на межузловую коммуникацию.

Scalable Unit: повторяемый строительный блок

Масштабируемый блок (SU) — атомарная единица DGX SuperPOD. В IB XDR-конфигурации один SU содержит 72 сервера DGX B300, что даёт 576 GPU. Архитектура основана на принципе rail-aligned: трафик между любыми двумя узлами внутри SU требует ровно одного хопа через leaf-коммутатор. Трафик между SU проходит через spine-уровень.

Ключевое свойство: SuperPOD собирается из одинаковых SU, поэтому добавление второго, четвёртого или восьмого блока — воспроизведение уже проверенного паттерна, а не перепроектирование сети.

Рис. 2. Масштабирование DGX SuperPOD B300 (IB XDR). Источник: NVIDIA RA-11339-001, Table 3.1

Стойки и инфраструктура

В эталонной архитектуре AC-версии четыре сервера DGX B300 размещаются в одной стандартной EIA-стойке с PDU. Потребление на стойку — около 56 кВт. Для DC/Busbar-версии применяются MGX-стойки с шинопроводом постоянного тока — более плотная конфигурация.

При проектировании следует учитывать:

•       Мощность: 14,5 кВт на сервер DGX B300; ~56 кВт на стойку при 4 серверах
•       Охлаждение: воздушное для DGX B300 (в отличие от GB200/GB300 NVL72, требующих жидкостного)
•       Место: при планировании расширения нужно резервировать пространство под следующий SU заранее — длина кабелей ограничена физически
•       Надёжность ЦОД: SuperPOD рассчитан на Uptime Institute Tier 3 или эквивалент (TIA-942B Rated 3 / EN50600 Availability Class 3)

Сеть кластера: четыре независимых контура

DGX SuperPOD использует четыре физически и логически разделённых сети. Их смешение снижает производительность и создаёт трудно диагностируемые проблемы.

①  Вычислительная сеть (Compute Fabric)

Коммутаторы: NVIDIA Quantum-X800 (Q3400-RA), 800 Гбит/с InfiniBand XDR.

Топология: rail-aligned fat-tree — каждая группа из 72 узлов подключена к одному набору leaf-коммутаторов; трафик между группами идёт через spine.

Через эту сеть проходит весь GPU-to-GPU трафик: градиенты при обучении, активации при pipeline-параллелизме, данные при тензорном параллелизме. InfiniBand обеспечивает adaptive routing (AR), коллективные операции SHARP и автоматическое восстановление при сбоях SHIELD.

Рис. Вычислительная сеть для всего 576-узлового DGX SuperPOD, источник: docs.nvidia.com, NVIDIA SuperPOD with DGX B300 Systems, NVIDIA Quantum-X800 InfiniBand switching and AC Power Reference Architecture 

② Сеть хранения (Storage Fabric)

DGX SuperPOD поддерживает два варианта:

•       InfiniBand NDR (QM9700, 400 Гбит/с): максимальная производительность, congestion control, adaptive routing. Требование: I/O на узел более 80 ГБ/с
•       Ethernet RoCE (SN5610, 800 Гбит/с): гибкость, единая сеть с in-band management. RDMA минимизирует нагрузку на CPU

Хранилище физически отделено от вычислительной сети — это гарантирует, что операции записи чекпоинтов не блокируют вычислительный трафик.

Рис. Логическая схема сети хранения данных, источник: docs.nvidia.com, NVIDIA SuperPOD with DGX B300 Systems, NVIDIA Quantum-X800 InfiniBand switching and AC Power Reference Architecture 

③ ④ In-Band и Out-of-Band Management

In-band management (SN5610 Ethernet): провизионирование узлов, доступ к NFS-хранилищу, подключение к внешним сервисам (NGC, git, данные). Пользователи попадают на Slurm head nodes и Kubernetes через этот контур.

Out-of-band management (SN2201, 1 GbE): подключены BMC всех серверов, PDU, коммутаторы. Изолирован через VXLAN. Используется для IPMI-операций, управления IB-фабрикой через UFM и замены компонентов без остановки кластера.

Хранилище: локальное и общее

Система хранения в DGX SuperPOD двухуровневая:

•       Локальные NVMe SSD (8 × 3,84 ТБ на сервер DGX B300): кэш первого уровня для датасетов и чекпоинтов. Данные кэшируются в RAM при первом чтении и переиспользуются — критично для итеративного обучения.
•       Высокопроизводительное shared-хранилище: подключается через выделенную storage-сеть. Должно поддерживать POSIX-файловую систему, RDMA, параллельный многопоточный I/O.

Рис. 4. Требования к производительности хранилища. Источник: NVIDIA RA-11339-001, Table 5.2

При проектировании нужно учитывать не только GPU:

•       Питание, плотность размещения и возможности охлаждения
•       Место в стойках, несущую способность пола и кабельные трассы
•       Резерв для следующего SU — планировать заранее
•       Контуры управления, мониторинг и возможность замены серверов без остановки кластера

Практическое правило: кластер может полностью соответствовать расчёту по GPU, но не пройти по электропитанию или охлаждению. Эти ограничения нужно проверить до закупки оборудования. 

Сценарии, в которых кластер оправдан

Обучение и дообучение больших моделей

Если веса модели не помещаются в 2,3 ТБ одного DGX B300, нужен tensor parallelism через несколько узлов. Дополнительный критичный фактор — быстрая запись чекпоинтов: это синхронная операция, обучение блокируется на время записи. Рекомендуемая производительность записи — не менее половины от пропускной способности чтения.

Параллельный инференс

Несколько команд или клиентов с разными моделями, изолированными очередями и независимыми SLA. Кластер позволяет выделить каждой задаче фиксированный пул GPU, не допуская деградации одного сервиса из-за нагрузки другого.

Локальный контур с контролем данных

Данные и модели остаются в инфраструктуре организации. Масштабирование определяется требованиями к аудиту и локальному SLA, а не внешними ограничениями облака. DGX SuperPOD развёртывается on-premise — в собственном ЦОД или в коммерческом, но инфраструктура принадлежит заказчику.

Планирование ёмкости начинают с входных данных: точность вычислений, длина контекста, объём видеопамяти, размер пакета запросов, схема параллелизма, целевое число запросов, допустимое время ответа, время на обучение. Без этих параметров нельзя корректно определить количество серверов.

Чек-лист перед проектированием кластера

•       Профиль нагрузки: обучение, инференс или смешанный режим; пиковая и средняя нагрузка
•       Память и параллелизм: помещается ли рабочий набор в сервер при целевой точности
•       SLA: целевое время ответа, доступность и поведение сервиса при потере сервера
•       Выбор GPU и конфигурации: H200, B200 или B300; AC или DC/Busbar
•       Compute Fabric: InfiniBand XDR или Ethernet Spectrum-X, топология, число портов, резервирование
•       Storage Fabric: IB NDR или Ethernet RoCE, производительность, тип и сертификация хранилища
•       Инфраструктура ЦОД: питание (~56 кВт/стойка), охлаждение, Tier 3, место под расширение
•       Программный стек: Mission Control, BCM, Run:ai / Slurm, AI Enterprise, мониторинг
•       Операционная модель: квоты, очереди, процессы поставки моделей, аварийное восстановление

Вывод

Одного сервера HGX/DGX достаточно, пока задача укладывается в его объём видеопамяти и требования к времени ответа. Кластер становится необходим, когда появляются межсерверный параллелизм, несколько параллельных сервисов и требования к устойчивости работы.

В этом случае проектируют не просто набор серверов, а систему: DGX-узлы в Scalable Unit, вычислительную InfiniBand-сеть, выделенную сеть хранения, два контура управления и программный стек поверх — исходя из профиля нагрузки, а не из максимального числа GPU в спецификации.

Если вы оцениваете переход от одного сервера к мини-кластеру или полному SuperPOD, начните со сбора профиля моделей, SLA и ограничений ЦОД — это позволит выбрать конфигурацию стоек и сетей до закупки оборудования.

FAQ

развернуть все

B300 и GB300 — это одно и то же?

Нет. B300 — GPU архитектуры Blackwell Ultra для серверов HGX/DGX. GB300 — Grace Blackwell Ultra Superchip: платформа с CPU NVIDIA Grace + GPU Blackwell Ultra, используемая в системах NVL72 rack-scale с жидкостным охлаждением. Характеристики, конфигурации и стоимость этих систем существенно различаются.

Сколько GPU в одном масштабируемом блоке для B300?

Зависит от типа сети. В IB XDR-конфигурации (Quantum-X800): 1 SU = 72 сервера × 8 GPU = 576 GPU. В Ethernet-конфигурации (Spectrum-X): 1 SU = 64 сервера × 8 GPU = 512 GPU. Число серверов определяется ограничениями портов вычислительной сети и топологией fat-tree.

Нужно ли строить кластер, если просто не хватает скорости?

Сначала нужно диагностировать узкое место: объём видеопамяти, подготовку данных на CPU, работу хранилища, среду выполнения модели. Часто достаточно изменить точность вычислений или настройки пакетной обработки (batching). Кластер нужен, когда ограничением становятся емкость сервера, параллельная нагрузка или отказоустойчивость.