Стоечный GPU-сервер — это не просто шкаф, заполненный ускорителями. Это граница развертывания, в пределах которой топология GPU, сетевая фабрика, хранилище, управление, питание, охлаждение и планирование либо работают согласованно, либо создают дорогостоящие узкие места.
Для разработчиков ИИ и инженеров ML-инфраструктуры полезный вопрос заключается не в том, «Сколько GPU помещается в стойке?» Он звучит так: может ли эта стойка обеспечить коммуникацию, пути передачи данных и поведение при восстановлении, необходимые для рабочей нагрузки? Это руководство превращает этот вопрос в контрольный список по архитектуре и план приемки в облаке.
Что такое стоечный GPU-сервер?
Стоечный GPU-сервер — это физическая стойка или управляемое провайдером выделение ресурсов масштаба стойки, содержащее один или несколько GPU-серверов, а также сетевые компоненты, питание, охлаждение и средства управления, необходимые для их эксплуатации. В облачном развертывании вы можете не контролировать сам шкаф, но все равно должны уточнить, какие части топологии гарантированы: количество GPU на хост, межсоединение внутри хоста, фабрика между хостами, путь к хранилищу, домен обслуживания и политика размещения.
Один GPU-сервер — это узел. Стоечный GPU-сервер — это система вокруг нескольких узлов. GPU-кластер может охватывать одну или несколько стоек. Эти различия важны, поскольку сервис инференса может быть ограничен памятью GPU одного хоста и путем PCIe/NVLink, тогда как распределенное обучение или крупномасштабный инференс могут быть ограничены сетевыми путями и путями к хранилищу между хостами.
Эталонная архитектура NVIDIA BasePOD иллюстрирует эту разницу: в ней разделены вычислительная сеть InfiniBand, Ethernet-фабрика управления и хранения данных, а также внеполосная сеть управления. Ваша архитектура не обязана копировать эту эталонную архитектуру, но перед резервированием мощностей она должна явно определять эквивалентные пути. Эталонная архитектура NVIDIA DGX BasePOD
Архитектура стоечного GPU-сервера: шесть аспектов, которые нужно описать
Начните со схемы стойки, показывающей физическое размещение и логические пути. Если провайдер не может раскрыть сведения о каждом компоненте, зафиксируйте то, что гарантируется, и протестируйте остальное в течение периода приемки.
| Уровень | Что документировать | Почему это влияет на результаты |
|---|---|---|
| Вычислительные узлы | Модель GPU, количество GPU на хост, CPU/RAM, локальные NVMe, домен замены | Определяет объем памяти, возможности предобработки на стороне хоста и масштаб последствий отказа узла. |
| Топология внутри узла | Схема PCIe, доступность NVLink/NVSwitch, привязка GPU к NIC | Определяет, могут ли GPU на одном хосте эффективно обмениваться данными. |
| Фабрика между узлами | Тип сети, количество и скорость NIC, уровень коммутаторов, политика переподписки, размещение в одной стойке | Определяет поведение коллективных коммуникаций, когда задача выходит за пределы одного сервера. |
| Путь к хранилищу | Локальный кэш, общая файловая система или объектное хранилище, место назначения контрольных точек, сетевой путь | Не позволяет загрузке данных и сохранению контрольных точек отнимать время у вычислений. |
| Управление и контроль | Доступ BMC/внеполосный доступ, инвентаризация, планировщик, метрики, контроль изменений | Позволяет эксплуатировать стойку при отказе хоста или драйвера. |
| Инфраструктурные ограничения | Выделенная для стойки мощность, резервирование PDU, конструкция воздушного или жидкостного охлаждения, сервисный доступ | Ограничивает устойчивую плотность и обслуживание, а не только то, что физически помещается. |
1. Рассматривайте топологию как входной параметр рабочей нагрузки
Количество GPU — неполное описание емкости. Для одного хоста проверьте, как GPU соединены друг с другом и с NIC. Для нескольких хостов определите, останется ли задача на одном сервере, в одной стойке или будет пересекать стойки. Зафиксируйте ожидаемое правило размещения в спецификации рабочей нагрузки, а не предполагайте, что «восемь GPU» везде описывают одну и ту же машину.
NCCL использует прямые одноранговые пути, когда CUDA сообщает, что соответствующие GPU могут обращаться к памяти друг друга. NVIDIA документирует nvidia-smi topo -p2p как способ проверки однорангового статуса; используйте его как входные данные для валидации, а не как замену бенчмарку рабочей нагрузки. Руководство NCCL по устранению неполадок GPU
2. Разделяйте вычислительный трафик, трафик данных и трафик управления
Стоечному GPU-серверу требуется не только быстрая сеть для обучения. Трафик управления, загрузка артефактов, телеметрия, общее хранилище и пользовательский доступ могут мешать трафику рабочей нагрузки, если они используют общий недостаточно производительный путь. Используйте отдельные логические или физические пути там, где этого требует архитектура, а затем определите, какой путь обслуживает каждый из следующих типов трафика:
- коллективные коммуникации и трафик GPU Direct;
- загрузку образов, весов моделей, наборов данных и контрольных точек;
- трафик Kubernetes, SSH, BMC, журналирования и мониторинга;
- исходящий трафик к API, объектному хранилищу или нижестоящим сервисам.
Это особенно важно для облачных мощностей: уточните, описывают ли показатели пропускной способности пропускную способность между хостами, аплинк стойки, производительность хранилища или агрегированную производительность по принципу best effort. Они не взаимозаменяемы.
3. Проектируйте питание и охлаждение как ограничения емкости
Не рассчитывайте размер стоечного GPU-сервера только по юнитам стойки. Конфигурация, которая помещается физически, может быть ограничена доступной мощностью площадки, резервированием PDU, направлением воздушного потока, требованиями к жидкостному охлаждению, радиусом изгиба кабелей или сервисными зазорами. NVIDIA отмечает, что компоновка стоек зависит от локальной максимальной мощности и инфраструктуры охлаждения; для фактического выделения ресурсов используйте актуальную документацию поставщика серверов и провайдера колокации. FAQ по NVIDIA DGX SuperPOD
Перед развертыванием запросите письменный ответ на следующие вопросы:
- Каков устойчивый допустимый уровень мощности стойки и какое допущение по резервированию включено?
- Какая используется система охлаждения: воздушная, прямое жидкостное охлаждение чипа, теплообмен через заднюю дверь или их комбинация?
- Какой компонент первым вызывает троттлинг или событие обслуживания: хост, PDU, сетевой коммутатор или контур инженерной инфраструктуры?
- Может ли технический специалист обслужить узел, кабель или компонент задней двери без нарушения работы соседних мощностей?
Если развертывание выполняется только в облаке, переведите те же вопросы на термины провайдера: размещение на выделенном хосте, домен обслуживания, политика замены хоста и возможность изменения топологии выделения после подготовки ресурсов.
4. Обеспечивайте планировщику осведомленность о стойках только тогда, когда это полезно
Метки стоек ценны, когда для рабочей нагрузки важны локальность или домены отказа. Задача распределенного обучения может предпочитать размещение в одной стойке, прежде чем расширяться на несколько стоек. Высокодоступный сервис инференса может намеренно распределять реплики между стойками или хостами. Начните с небольшого, проверяемого набора меток, например topology.rack, topology.host-class, topology.fabric и topology.failure-domain, затем убедитесь, что размещение планировщиком следует им.
Для Kubernetes проверяйте весь программный стек GPU на соответствие поддерживаемым операционной системе, Kubernetes, драйверу, среде выполнения и варианту развертывания, а не только версию кластера. Матрица поддержки NVIDIA GPU Operator различает bare metal, виртуальные машины с GPU-passthrough и развертывания vGPU, а также публикует сведения о совместимости для поддерживаемых сред. Поддержка платформ NVIDIA GPU Operator
Как выбрать стойку GPU-серверов для вашей рабочей нагрузки
Используйте описание рабочей нагрузки, чтобы определить, нужен ли вам один высокоплотный хост, одна стойка или кластер из нескольких стоек.
| Тип рабочей нагрузки | Обычно приоритетны | Что спросить у провайдера или команды платформы |
|---|---|---|
| Дообучение или инференс на одном узле | Память GPU, внутривузловая топология, локальное хранилище, надежная замена хоста | Какие GPU и межсоединения подключены к одному хосту? Можно ли выделить все необходимые GPU одновременно? |
| Распределенное обучение | Размещение в одной стойке, сетевая фабрика, привязка NIC, пропускная способность для контрольных точек | Что гарантируется для сети между хостами? Как предоставляется или исключается размещение между стойками? |
| Многоузловой инференс | Хвостовая задержка, обмен данными между частями модели, безопасность развертывания, наблюдаемость | Можно ли распределить реплики по доменам отказа, сохраняя осведомленность рангов model-parallel о топологии? |
| Пакетные задачи или задачи рендеринга | Поведение очереди, локальный кэш, обработка прерываний, подготовка образов и данных | Какова гарантия размещения и как восстанавливаются прерванные задания? |
| Общая внутренняя платформа | Изоляция, квоты, политика планировщика, видимость доступных мощностей, контроль изменений | Как управляются разделы GPU, границы арендаторов, драйверы и обновления? |
Для нового развертывания сравните решение со стойкой с более простой альтернативой. Если для работы не требуется контроль топологии, локальности данных или собственного стека обслуживания, управляемый API модели может обеспечить меньшую операционную нагрузку. Используйте это сравнение GPU-облака и API модели как часть процесса принятия решения, а не рассматривайте стойку GPU-серверов как ответ по умолчанию.
Как оценивать производительность стойки GPU-серверов
Не принимайте стойку GPU-серверов, основываясь только на пиковом показателе ускорителя. Подготовьте краткий приемочный тест, который разделяет основные пути производительности.
Шаг 1: Зафиксируйте базовые данные об инвентаризации и топологии
Для каждого выделенного хоста соберите идентификаторы GPU, версии драйвера и CUDA, топологию GPU-to-GPU, привязку GPU-to-NIC, схему CPU NUMA, локальное хранилище и сетевые интерфейсы. Храните эту запись вместе с ревизией развертывания. Она дает точку сравнения, когда производительность меняется после замены образа, прошивки, драйвера или хоста.
nvidia-smi -L
nvidia-smi topo -m
nvidia-smi topo -p2p p
nvidia-smi topo -p2p n
Не изменяйте настройки ядра, BIOS, IOMMU или контроля доступа PCIe, руководствуясь универсальным чек-листом. NVIDIA документирует зависимое от конфигурации поведение peer-to-peer в Linux-системах bare metal; используйте поддерживаемые настройки для сервера и облачной платформы, которые вы фактически эксплуатируете. Устранение неполадок топологии и peer-to-peer NCCL
Шаг 2: Тестируйте на важных границах
Запускайте репрезентативные тесты в трех масштабах:
- Один узел — для проверки видимости GPU и локального пути NVLink/NVSwitch или PCIe.
- Одна стойка — для проверки размещения между хостами и локальной фабрики.
- Несколько стоек — чтобы понять путь, который будет использовать ваш планировщик при расширении емкости или переключении при отказе.
Руководство NVIDIA по тестированию NCCL явно использует запуски на одном узле, в одной стойке и в нескольких стойках для проверки видимости GPU, внутривузлового межсоединения, межузловой фабрики и размещения. Фиксируйте задержку и пропускную способность вместе с командой теста, дайджестом образа контейнера, списком узлов и метками размещения, чтобы результат можно было воспроизвести. Руководство по проверке NCCL
Шаг 3: Измерьте путь реального приложения
Затем запустите рабочую нагрузку, которую вы планируете обслуживать. Для обучения укажите время на шаг, ожидание данных, время коллективной коммуникации, время создания контрольной точки и поведение при восстановлении. Для инференса укажите время до первого токена, пропускную способность вывода, хвостовую задержку, задержку в очереди, поведение кэша, а также частоту ошибок или перезапусков. При сравнении вариантов размещения сохраняйте одинаковыми модель, профиль пакета/параллелизма, длину контекста и состояние кэша.
Так вы отличите проблему GPU от проблемы с данными, сетью, планировщиком или конфигурацией.
Шаг 4: Проверьте запланированный сбой
Эксплуатационной стойке GPU-серверов необходим путь восстановления. До запуска производственного трафика проверьте, что происходит, когда рабочий узел выводится из эксплуатации, узел становится недоступным, задание вытесняется или контрольную точку требуется возобновить в другом месте. Убедитесь, что постоянные данные отделены от заменяемых вычислительных ресурсов и что учетные данные, образы и средства наблюдаемости по-прежнему работают на пути замены.
Развертывание стойки GPU-серверов в облаке: практическая последовательность
Облачное развертывание меняет границу контроля, но не объем инженерной работы. Вам по-прежнему необходимо сделать допущения об оборудовании и размещении явными.
- Опишите контракт рабочей нагрузки. Укажите размер модели, количество GPU, требования к памяти, SLO по задержке или пропускной способности, чувствительность к сети, источник данных, расположение контрольных точек, целевой уровень доступности и бюджетные ограничения.
- Выберите границу топологии. Решите, должно ли задание оставаться в пределах одного хоста, одной стойки или определенной многостоечной фабрики. Рассматривайте это как требование в запросе к провайдеру, а не как неформальное предпочтение.
- Запросите лист выделения ресурсов. Запросите класс хоста, количество GPU, межсоединение GPU, NIC, сетевую фабрику, варианты хранения, гарантию размещения, политику обслуживания и любые метаданные топологии, доступные вашему планировщику.
- Зафиксируйте программный контракт. Запишите операционную систему, ядро, драйвер NVIDIA, CUDA, среду выполнения контейнеров, версию Kubernetes, версию GPU Operator, образ фреймворка и дайджест образа приложения. Перед развертыванием проверьте совместимость этой комбинации по матрице поддерживаемых конфигураций.
- Создайте узкое окно приемки. Выполните проверки инвентаря, топологии, связи в пределах одного узла/одной стойки/между стойками, хранения, приложения и восстановления до перевода устойчивого трафика.
- Инструментируйте каждый уровень. Настройте отдельные оповещения о состоянии GPU, ошибках фабрики, ожидании хранилища, ожидании планировщика, тепловых событиях или троттлинге и SLO приложения. Один показатель утилизации не может объяснить инцидент масштаба стойки.
- Сохраняйте варианты выхода и восстановления. Поддерживайте определения образов, конфигурацию инфраструктуры, расположения постоянных данных, контрольные точки и план отката независимо от конкретного выделения ресурсов.
Сведения о частях этой последовательности на уровне хоста см. в руководстве по развертыванию GPU-сервера. Сведения о плоскости управления и фабрике в многоузловой среде см. в руководстве по архитектуре GPU-кластера.
Контрольный список приемки стойки GPU-серверов
Используйте этот контрольный список перед приемкой новой стойки GPU-серверов, выделенных облачных ресурсов или решения colocation.
- [ ] В контракте рабочей нагрузки указана граница топологии: один хост, одна стойка или несколько стоек.
- [ ] Лист выделения ресурсов содержит количество GPU на хост, межсоединение ускорителей, NIC, сетевую фабрику и путь хранения.
- [ ] Для питания, охлаждения, резервирования PDU, требований к воздушному или жидкостному охлаждению и сервисных зазоров назначен ответственный.
- [ ] Зафиксированы версии GPU, драйвера, CUDA, ядра, среды выполнения контейнеров и оркестрации.
- [ ] Планировщик предоставляет и соблюдает метки размещения или домена отказа там, где они необходимы рабочей нагрузке.
- [ ] Для каждого класса хостов сохранены результаты инвентаризации и топологии
nvidia-smi. - [ ] Тесты связи охватывают размещение на одном узле, в одной стойке и между стойками, которое может создавать производственный планировщик.
- [ ] Тест приложения использует репрезентативный источник данных и профиль рабочей нагрузки.
- [ ] Проверены пути создания контрольных точек, вывода хостов из эксплуатации, замены и отката.
- [ ] Отчетность о затратах отделяет продуктивное время GPU от затрат на простой, повторы, данные и поддержку, не учитывая одно и то же время дважды. Для более широкой модели затрат начните с этого руководства по аренде GPU.
Часто задаваемые вопросы
Стойка GPU-серверов — это то же самое, что GPU-кластер?
Нет. Стойка GPU-серверов описывает физическую или управляемую провайдером границу развертывания на уровне стойки. GPU-кластер — это логическая группа узлов, которая может охватывать часть одной стойки, целую стойку или несколько стоек. Различие важно, когда сеть, хранилище, домены отказа и планирование пересекают физические границы.
Сколько GPU-серверов помещается в стойке GPU-серверов?
Универсального полезного числа не существует. Глубина сервера и стоечные единицы — лишь первое ограничение. Практический ответ зависит от энергопотребления сервера, конструкции охлаждения, емкости и резервирования PDU, прокладки кабелей, доступа для обслуживания и утвержденной плотности площадки. Проверяйте ответ для точной конструкции хоста, стойки и центра обработки данных, которую вы будете использовать.
Нужен ли каждой стойке GPU-серверов InfiniBand?
Нет. Подходящая фабрика зависит от рабочей нагрузки и топологии. Рабочим нагрузкам на одном хосте межузловая высокопроизводительная фабрика может вообще не требоваться. Распределенные рабочие нагрузки следует тестировать на сетевом пути, который они будут использовать в действительности, включая размещение в одной стойке и между стойками. Не выбирайте фабрику, опираясь только на маркетинговую спецификацию.
Что следует проверить перед приемкой облачных ресурсов стойки GPU?
Протестируйте полученное выделение ресурсов: инвентаризацию оборудования, топологию, привязку GPU к NIC, работу локального и общего хранилища, обмен данными в пределах одного узла, обмен данными в пределах одной стойки, обмен данными между стойками, если он возможен в производственной среде, типичное поведение приложения и восстановление после запланированного сбоя.
Когда следует избегать эксплуатации стойки GPU-серверов?
Избегайте эксплуатации на уровне стойки, если вашей рабочей нагрузке не нужен предоставляемый ею контроль. Если управляемый API модели может удовлетворить требования к модели, задержке, доступности, конфиденциальности и стоимости, он может избавить от работы с оборудованием, фабрикой, драйверами, планировщиком и управлением ёмкостью. Прежде чем переходить к стойке GPU-серверов, осознанно выполните это сравнение.
Проектируйте стойку с учётом рабочей нагрузки
Стойка GPU-серверов успешна, когда её физическая конструкция и облачное выделение ресурсов соответствуют путям обмена данными, передачи данных и восстановления рабочей нагрузки. Явно определите топологию, разделите классы трафика, которые могут мешать друг другу, проверьте производительность на уровне одного узла, одной стойки и нескольких стоек и принимайте ёмкость только после тестирования реального приложения и сценария сбоя.
Если контроль на уровне стойки не требуется, прежде чем брать на себя эксплуатационную нагрузку, сравните вариант с API модели. Если он требуется, используйте это руководство вместе с руководством по GPU-серверам, руководством по архитектуре GPU-кластера и контрольным списком затрат на GPU-облако, чтобы превратить ёмкость в проверяемое развертывание.
