Выбор между одним GPU-сервером для ИИ и кластером часто сводят к числу ускорителей. Решение опирается на профиль нагрузки, измеримые ограничения узла и готовность платформы. Один мощный сервер — рациональный старт для пилота и ограниченного продуктивного сервиса. GPU-кластер для ИИ оправдан, когда дефицит ёмкости, распределённая обработка или многузловая доступность подтверждены метриками, а команда готова к отдельным контурам сети, хранения, планирования GPU и эксплуатации.
Почему вопрос нельзя решать по числу GPU
Обучение и инференс предъявляют разные требования к инфраструктуре: к пропускной способности памяти, задержке ответа, характеру обмена данными и допустимому времени простоя. При выборе архитектуры также учитывают объём и рост запросов, требования к доступности, объём данных, совместное использование GPU (графических процессоров) и зрелость эксплуатации.
Наращивание мощности внутри узла и масштабирование наружу — разные задачи с разными контурами. Переход от одного GPU-сервера к кластеру — не только добавление GPU: в эталонных многосерверных архитектурах отдельно проектируются выделенная вычислительная сеть, хранилище, управление и внешняя связность.
Когда одного GPU-сервера достаточно
Одного узла достаточно при ограниченной предсказуемой нагрузке, если ёмкость и модель устойчивости соответствуют требованиям. Типичные сценарии: пилоты и MVP; стабильный инференс в рамках узла; обучение и дообучение, умещающиеся на одном сервере; ранняя операционная зрелость команды.
Путь к результату короче: меньше взаимозависимых компонентов, не нужны межузловая вычислительная сеть и распределённое планирование задач. HGX — референсная платформа NVIDIA: она объединяет GPU, центральные процессоры, NVLink, NVSwitch, сетевые компоненты NVIDIA и программный стек для ИИ и высокопроизводительных вычислений.
HGX H200 — самостоятельный пример: восемь GPU H200 соединены NVLink и четырьмя коммутаторами NVSwitch, образующими полносвязную топологию между ускорителями. Это наращивание мощности внутри одного узла, а не обязательная конфигурация для любой нагрузки. Blackwell B200 и B300 развивают этот подход, однако выбор определяется нагрузкой и требованиями проекта.
Сигналы, что масштабирование ИИ-инфраструктуры назрело
Решение опирается на устойчивые, повторяемые измерения, а не на разовый пик:
- хронический дефицит GPU-ёмкости и свободных слотов;
- рост очередей и времени ожидания задач;
- деградация задержки ответа под рабочей нагрузкой;
- нехватка окна на обучение или дообучение;
- потребность в распределённой обработке, которую один узел не закрывает;
- требование многузловой доступности;
- регулярные конфликты команд за одни и те же GPU.
Необходимость кластера следует подтверждать метриками конкретной нагрузки и требованиями к доступности; конкретные пороги задаёт проект.
Что меняется при переходе к GPU-кластеру
Сеть
Межузловую выделенную вычислительную сеть отделяют от управления, хранилища и внешнего контура. Граница зависит от поколения платформы: в HGX H100/H200 NVLink и NVSwitch объединяют ускорители внутри одного узла, а в Blackwell-системах GB200 NVL72 и GB300 NVL72 домен NVLink через коммутаторы может охватывать до 72 GPU в пределах стойки. Поэтому стоечный сценарий нельзя переносить на любую HGX-систему.
Для тесно связанного межузлового обмена при распределённом обучении и коллективных операциях нужны InfiniBand либо Ethernet с RoCE — RDMA поверх конвергентного Ethernet. Обычный Ethernet без RDMA для таких нагрузок не подходит; для остальных контуров сеть выбирают по роли, поколению платформы и нагрузке.
Кластер — это не только набор GPU-серверов.
Хранилище
Хранилище проектируют как отдельный контур, а не «диск на сервере по умолчанию». Требования подтверждают эталоном тестирования производительности нагрузки, без универсальных IOPS/GB/s.
Планирование GPU
В Kubernetes GPU планируют через плагин устройства производителя оборудования (механизм учёта и выдачи GPU планировщиком); запросы указывают в ограничениях ресурсов. Автоматическое масштабирование нод — функция отдельного автодобавляющего компонента нод, а не свойство «любого GPU-кластера». Плоскость управления проектируют явно.
Эксплуатация
Нужны наблюдаемость, подготовка инфраструктуры, обновления ПО и процедуры восстановления после сбоев. Отказоустойчивость появляется, когда резервирование и перезапуск при сбое заданы проектно.
Линейный прирост производительности от добавления узлов зависит от нагрузки, коллективных операций, топологии и измерений; универсальную гарантию линейности давать нельзя. Растёт сложность и требования к команде.
Практическая матрица выбора и поэтапный план
| Вопрос | Подтверждаемая проверка | Ограничение |
|---|---|---|
| Нужно ли масштабирование наружу? | Очередь задач, загрузка GPU/свободная ёмкость, время ожидания, задержка ответа, доступность | Пороги определяет проект |
| Готова ли сеть? | Выделенная межузловая вычислительная сеть отдельно от управления, хранилища и внешнего контура | Для тесно связанных нагрузок — InfiniBand или Ethernet с RoCE; выбор зависит от платформы и нагрузки |
| Готово ли хранилище? | Хранилище как отдельный контур | Не заявлять IOPS/GB/s без эталона тестирования производительности |
| Готова ли эксплуатация? | Плоскость управления, мониторинг, подготовка инфраструктуры, планирование работы GPU, обновления ПО, процедуры восстановления после сбоев | Плагин учета устройств; автомасштабирование не «само» |
| Что с доступностью? | Явно спроектировать резервирование и перезапуск при сбое | SLA — согласованный уровень сервиса; фиксируется в договоре и описании уровня сервиса |
Поэтапный план
- Зафиксировать профиль нагрузки и исходные метрики на одном узле.
- Исчерпать обоснованное наращивание мощности внутри узла и оптимизацию планирования выполнения задач и очередей.
- Проверить готовность сети, хранилища, плоскости управления, мониторинга и процедур отказов.
- Спроектировать масштабирование наружу под сценарий (обучение / инференс / смешанный), включая доступность.
- Пилот на ограниченном числе узлов → пересмотр метрик → расширение.
Вывод
Масштабирование ИИ-инфраструктуры имеет смысл по подтверждённым потребностям и метрикам. Один GPU-сервер — нормальный этап выбора архитектуры. Кластер — ответ на измеримые ограничения и требования к распределённой обработке или многузловой доступности.
Переход окупает сложность только при готовности сети, хранения, плоскости управления и команды.
Для выбора конкретной конфигурации можно начать с оценки доступных платформ NVIDIA HGX и сопоставить их с профилем нагрузки. Это позволяет определить, достаточно ли одного мощного узла или инфраструктуру уже на этапе проектирования стоит строить с расчётом на кластер.
Если нужно разобрать профиль нагрузки, исходные метрики и готовность контуров перед выбором между одним HGX-сервером и кластером, имеет смысл опереться на экспертизу в проектировании ИИ-инфраструктуры и совместно оценить риски, этапность и модель масштабирования — без решения «взять с запасом» до появления устойчивых сигналов.
Предыдущая статья
