От 4 до 128 GPU: практическое руководство по расширению кластера Supermicro в российских дата-центрах
Эта статья адресована техническим руководителям и архитекторам, которые уже запустили 4×GPU‑сервер Supermicro в российском ЦОДе, получили настоящую нагрузку и теперь видят переполненные очереди на обучение, растущую задержку онлайн‑инференса и постоянно «красные» отчёты по загрузке GPU.
В текущих условиях российских дата‑центров расширение GPU‑кластера — это не «поставить ещё пару карт», а поиск баланса между тремя жёсткими ограничениями: мощность на шкаф, пропускная способность сети и свободное место в стойках. Важно понять, где именно для вас сейчас находится разумный потолок — на уровне 8, 32 или 128 GPU — и как спланировать путь до него без дорогих ошибок.
Кому и в чём эта статья помогает
| Параметр | Типичная ситуация | Что даёт статья |
|---|---|---|
| Роль | Техлид / архитектор, управляющий 4×GPU‑узлом Supermicro в российском ЦОДе | Поэтапная карта расширения кластера от 4 до 128 GPU |
| Симптомы | Очереди обучения растут, задержка инференса увеличивается, GPU‑отчёты постоянно «красные» | Понимание, что именно ограничивает вас сейчас: GPU, CPU/диск, сеть или мощность стойки |
| Ограничения | 5–10 кВт на шкаф, 10/25G‑сеть, ограниченное число высокоплотных стоек и доступных GPU | Рекомендации, где переходить к 8 GPU, 32 GPU и когда заранее думать о 64–128 GPU |
Далее шаги расширения будут рассмотрены по ступеням: сначала максимум, что можно выжать из одного узла (4→8 GPU), затем выход на кластер из нескольких серверов (до 32 GPU), и, наконец, подход к уровню мини‑AI‑дата‑центра (64–128 GPU) с отдельными требованиями к электропитанию и охлаждению.
Этап 1: 4 → 8 GPU — выжать максимум из одного сервера Supermicro
1. Базовый 4×GPU‑узел: реальные возможности
Стартовая конфигурация чаще всего такова: один 2U/4U сервер Supermicro с 4 GPU, двумя процессорами Xeon/EPYC, 512 GB–1 TB RAM и набором NVMe‑дисков. На таком узле удобно запускать обучение и дообучение моделей 7B/13B, эксперименты с 34B и обслуживать средний по нагрузке онлайн‑инференс для внутренних сервисов.
- PCIe‑топология: все 4 GPU должны быть подключены к полным x16‑слотам; урезанная по линиям карта будет тормозить даже при мощной модели.
- CPU и память: суммарно 64+ ядер и не менее 512 GB RAM, чтобы подготовка данных и dataloader не превращались в бутылочное горлышко при 4 активных GPU.
- NVMe‑массив: 8–12 SSD корпоративного класса в RAID0/10, чтобы выдерживать поток чтения/записи датасетов и чекпоинтов без простаивания GPU.
Типичное энергопотребление такого узла — порядка 1,5–3 кВт, что укладывается в традиционные 5–10 кВт/шкаф и не требует немедленной модернизации электрики и климатической инфраструктуры. На этом уровне основной резерв — внутренняя оптимизация конфигурации и загрузки, а не расширение кластера.
2. Как понять, что 4 GPU уже не хватает
| Сигнал | Как проявляется | Вывод |
|---|---|---|
| Длинные очереди обучения | Запуски ждут в очереди сутками, отдельный прогон 7B/13B занимает неделю | 4 GPU стали узким горлышком для time‑to‑market |
| Стабильно высокая загрузка GPU | 80–90 % загрузки карт удерживаются часами и днями, I/O не упирается в потолок | GPU действительно работают на пределе, а не простаивают из‑за диска или сети |
| Рост размеров моделей | Переход от 7B к 13B/34B требует урезать batch и снижать эффективность | Текущей памяти и числа GPU уже не хватает для целевых задач |
Если хотя бы два из этих трёх признаков проявляются одновременно, стоит прекратить бесконечно «дотюнивать» один 4×GPU‑узел и начать предметно рассматривать расширение до 8 GPU или добавление второго сервера.
3. 4 → 8 GPU: увеличить throughput или готовиться к 70B‑моделям
Формально расширение до 8 GPU — это установка дополнительных карт, но на практике это выбор архитектурной траектории: вы хотите просто одновременно запускать больше задач или вам нужен узел, где все 8 GPU будут работать как единый ресурс для крупных моделей.
| Критерий | 8×GPU на PCIe | 8×GPU с NVLink/NVSwitch |
|---|---|---|
| Цель | Увеличить количество параллельных экспериментов и сервисов инференса | Обучать 70B+ модели и активно использовать модельный параллелизм |
| Оркестрация | Kubernetes/Slurm, «один GPU — один job/тенант» | Один job держит все 8 GPU, полагаясь на высокоскоростный обмен между картами |
| Стоимость и сложность | Проще и дешевле, достаточно для большинства задач с 7B/13B | Дороже, но даёт запас под собственные крупные LLM и максимум эффективности |
4. Как рост до 8 GPU влияет на мощность и размещение в стойке
Увеличение числа GPU почти линейно тянет за собой рост энергопотребления: если 4×GPU‑узел обычно укладывается в 1,5–3 кВт, то 8×GPU‑сервер может потреблять 3–5 кВт и выше. При двух таких узлах в одной стойке вы быстро выходите на 10 кВт и начинаете упираться в проектный лимит многих российских стоек.
Поэтому перед решением о переходе на 8 GPU стоит запросить у оператора ЦОДа простые цифры: какая максимальная мощность на шкаф, сколько уже потребляется и какой запас по охлаждению есть на выбранной площадке. Это убережёт от ситуации, когда новый узел куплен, но по факту может работать только в «урезанном» режиме.
Этап 2: от 8–16 до 32 GPU — многосерверный кластер и роль сети
1. NVLink работает внутри сервера, между серверами решает сеть
С выходом на 2–4 узла общая ёмкость кластера достигает 16–32 GPU, и тут становится заметно, что NVLink/NVSwitch ускоряет только обмен между GPU внутри одного шасси. Как только тренинг распределён по нескольким серверам, ключевым фактором становится качество сети: скорость линков 100G/200G, топология и задержки в сети.
| Масштаб | Пример конфигурации | Рекомендуемая сеть |
|---|---|---|
| 16 GPU | 4× сервера по 4 GPU | ≥1×100G на узел, один 32‑портовый 100G‑коммутатор |
| 32 GPU | 4× по 8 GPU или 8× по 4 GPU | 2×100G или 1×200G на узел, Fat‑Tree/Clos‑схема |
2. Когда 10G/25G уже тормозят масштабирование
Переход с 10G/25G на 100G/InfiniBand становится оправданным, когда сеть начинает съедать слишком большую долю каждого шага обучения и ограничивать масштабируемость кластера. Ориентиры могут быть такими:
- Ключевые задачи — распределённое обучение 34B/70B‑моделей, а не только одиночных 7B.
- Профилировщик показывает, что общение по сети (All‑Reduce, broadcast) занимает 30–40 % времени итерации.
- В дорожной карте явно фигурирует рост до 64–128 GPU в течение ближайших двух‑трёх лет.
Если два‑три этих пункта совпадают с вашей картиной мира, дальнейшее наращивание числа GPU без модернизации сети будет давать всё меньший эффект. В этот момент стоит рассматривать 100G/InfiniBand не как «опцию для будущего», а как обязательную часть инвестиционного плана.
3. 16–32 GPU: первая жёсткая планка по мощности и охлаждению в российских ЦОДах
Большинство существующих площадок в России проектировались под универсальные нагрузки: 5–10 кВт на шкаф, классическое воздушное охлаждение и стандартные серверные шасси. Когда вы ставите 2–3 мощных GPU‑узла в один шкаф, легко выйти на 15–20 кВт, после чего температура в горячем коридоре и общий PUE начинают заметно расти.
На этом шаге имеет смысл заранее договориться с оператором ЦОДа о «правилах игры»: какая реальная верхняя граница по мощности на шкаф, какие стойки можно использовать под высокоплотные конфигурации и какие дополнительные меры по охлаждению доступны. Это позволит строить план расширения не вслепую, а с пониманием инфраструктурных ограничений.
Этап 3: 64–128 GPU — уровень мини‑AI‑дата-центра
1. Модульный подход: строим кластер из блоков по 32–64 GPU
На уровне 64–128 GPU разговор уже идёт не об «ещё паре серверов», а о самостоятельном AI‑контуре внутри дата‑центра. Здесь хорошо работает модульная концепция: кластер собирается из блоков по 32 или 64 GPU с единообразной архитектурой питания, сети и охлаждения.
| Модуль | Состав | Назначение |
|---|---|---|
| 32 GPU | 4× узла по 8 GPU или 8× по 4 GPU Supermicro | Кластер для отдельного продукта или команды |
| 64 GPU | 8× узлов по 8 GPU | Корпоративный кластер для обучения и обслуживания LLM |
Такой подход упрощает как расширение (добавляем ещё один модуль), так и эксплуатацию (каждый блок можно обслуживать и обновлять независимо, выделяя его под конкретные задачи или подразделения).
2. 40–60 кВт на шкаф: когда жидкостное охлаждение становится обязательным
Для стойки, заполненной современными GPU‑узлами, мощность 40–60 кВт перестала быть экзотикой. Попытка выдерживать такие плотности только на воздушном охлаждении приводит к постоянной борьбе с температурным режимом, резкому росту PUE и риску неожиданных ограничений со стороны эксплуатации ЦОДа.
На этом уровне в игру входят холодные пластины, задние теплообменники и гибридные схемы с частичным погружным охлаждением. В бюджетах это выглядит как перераспределение акцентов: меньше прямых затрат на дополнительные GPU и больше — на создание устойчивой инфраструктуры, которая позволит существующему парку GPU стабильно работать на максимум в течение 3–5 лет.
Дорожная карта: 4 → 8 → 32 → 128 GPU в одной таблице
| Этап | Ключевой вопрос | На что смотреть в первую очередь |
|---|---|---|
| 4 → 8 GPU (один узел) | Правильно ли выбран базовый сервер Supermicro? | Поддержка 8 GPU и NVLink при необходимости; баланс CPU/RAM/NVMe; лимиты по мощности и охлаждению на стойку |
| 8–16 → 32 GPU (несколько узлов) | Выдержат ли сеть и инфраструктура ЦОДа? | Переход на 100G/InfiniBand; наличие высокоплотных стоек 15–20 кВт; масштабирование NVMe‑хранилища под многосерверные нагрузки |
| 32 → 64–128 GPU (модульный кластер) | Это ещё расширение кластера или уже проект AI‑дата‑центра? | Модульный дизайн по 32/64 GPU; внедрение высокоплотных стоек и жидкостного охлаждения; 3–5‑летний план по TCO (GPU + сеть + ЦОД) |
Что сделать прямо сейчас: простой чек-лист и следующий шаг
Чтобы превратить эту схему в конкретный план для вашей компании, начните с трёх простых цифр: сколько GPU у вас есть сейчас (4, 8, 16, 32), к какому уровню вы хотите прийти через 2–3 года (32, 64 или 128 GPU), и какая реальная мощность и охлаждение доступны на ваших стойках в выбранном российском дата‑центре.
Запишите эти три числа на одной странице, добавьте текущие метрики по загрузке GPU, очередям обучения и сети — и у вас появится рабочий черновик карты расширения. С ним уже можно предметно обсуждать с руководством бюджет, а с интегратором и оператором ЦОДа — техническую реализацию.
Если вы хотите получить персонализированный план роста кластера под российские реалии (ограничения по мощности, доступность GPU, требования по локализации данных), соберите короткую сводку по текущей конфигурации (модели GPU, число узлов, используемый ЦОД, целевой масштаб через 2–3 года) и отправьте её партнёру, который работает с Supermicro в вашем регионе. На основе этих данных вам могут подготовить конкретную схему: какие узлы добавлять, когда переходить на 100G/InfiniBand и в какой точке стоит планировать переход к высокоплотным стойкам и жидкостному охлаждению.
Получить план расширения GPU-кластера
