GPU-сервер: архитектура, производительность и развертывание в облаке

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

Это руководство помогает разработчикам ИИ и инженерам ML-инфраструктуры выбрать, развернуть и проверить облачный GPU-сервер, не сводя решение к названию модели или почасовой ставке. Используйте его, чтобы составить описание нагрузки, проверить топологию, которую вы фактически получаете, безопасно выполнить развертывание и привязать затраты к полезному результату.

Краткий ответ: что такое GPU-сервер?

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

• Один или несколько GPU и их высокоскоростную память (HBM или VRAM)
• CPU, системную RAM, линии PCIe и топологию материнской платы
• Локальное NVMe для кэшей или промежуточного размещения данных, а также постоянное хранилище для данных и контрольных точек
• Сетевые интерфейсы для пользователей, объектного хранилища и — в многоузловых системах — коллективной коммуникации
• Драйверы, среду выполнения контейнеров, мониторинг и иногда уровень оркестрации

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

Практический вывод прост: выбирайте GPU-сервер на основе описания нагрузки, а затем проверяйте его на собственной нагрузке. Не предполагайте, что два хоста с одинаковой маркировкой ускорителя будут работать одинаково.

Архитектура GPU-сервера: шесть уровней, определяющих результат

Рассматривайте GPU-сервер как шесть связанных уровней. Слабый уровень может ограничить всю систему.

Ускоритель и память — исходное ограничение, но не полный ответ

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

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

Внутриузловая топология определяет, будут ли несколько GPU работать как команда

Работа с несколькими GPU не становится быстрой автоматически. GPU могут обмениваться данными через PCIe, прямые высокоскоростные соединения или коммутационную фабрику, причем путь может различаться для каждой пары. NVIDIA указывает, что nvidia-smi topo -m помогает выявить внутриузловую топологию, а инструменты измерения пропускной способности позволяют проверить ожидаемые пути между GPU.

Прежде чем выбрать многопроцессорный GPU-сервер, зафиксируйте:

1. Карту топологии для точного типа хоста.
2. Доступность peer-to-peer для пар GPU, которые будет использовать ваш фреймворк.
3. Базовые показатели простой пропускной способности или коллективной коммуникации.
4. Привязку CPU и NIC относительно GPU.

Система на базе NVLink или NVSwitch может предоставлять иную архитектуру коммуникации, чем конфигурация только с PCIe. В документации Fabric Manager NVIDIA описывается роль NVLink и NVSwitch в соединении GPU и управлении фабрикой. Рассматривайте это как вопрос соответствия нагрузке, а не как знак статуса: независимой конечной точке инференса на одном GPU не нужна та же фабрика, что и синхронизированной многопроцессорной GPU-задаче.

Уровень хоста и путь данных часто становятся узкими местами

GPU может простаивать, пока хост выполняет токенизацию, декодирует медиа, загружает сегменты, восстанавливает контрольную точку или копирует данные через неожиданный путь PCIe. Запрашивайте сведения о CPU, RAM, NUMA, локальном диске и сети наряду со спецификацией ускорителя.

Используйте локальный NVMe осознанно — для временных кэшей и промежуточных данных. Артефакты моделей, наборы данных, контрольные точки, рабочие процессы и принятые результаты размещайте в хранилище, сохраняющемся при замене экземпляра, если они должны оставаться доступными. Такое разделение упрощает повторное создание облачного GPU-сервера и снижает риск того, что остановка, изменение размера или сбой хоста удалит работу, которую нужно продолжить.

Программное обеспечение превращает GPU в планируемый ресурс

Для одного сервера минимальный программный стек обычно включает поддерживаемый драйвер, совместимую с CUDA среду выполнения, инструменты контейнеризации, образ рабочей нагрузки, средства наблюдаемости и контролируемый путь доступа. В Kubernetes GPU-серверу также необходимы обнаружение устройств, плагин устройств поставщика и политика планирования.

Kubernetes предоставляет GPU через плагины устройств и пользовательские планируемые ресурсы; в его документации по планированию GPU объясняется, что ресурсы GPU запрашиваются через лимиты контейнеров. GPU Operator от NVIDIA объединяет распространенные компоненты, такие как драйверы, набор инструментов для контейнеров, плагин устройств, маркировка узлов и мониторинг на основе DCGM. Эти компоненты сокращают объем повторяющейся работы по настройке, однако совместимость версий, политика доступа и приемочное тестирование остаются вашей ответственностью.

Выбирайте GPU-сервер на основе описания рабочей нагрузки

Подготовьте это одностраничное описание перед оценкой предложения AI GPU server или dedicated GPU server hosting:

Это описание предотвращает дорогостоящее несоответствие. Рабочей нагрузке обслуживания с низкой задержкой могут потребоваться предсказуемые мощности и заранее загруженные артефакты. Пакетная задача может допускать прерывания, если она корректно сохраняет контрольные точки. Для обучения могут потребоваться проверенная коллективная коммуникация и постоянные контрольные точки. Формулировок «NVIDIA GPU server» или «server GPU» в предложении недостаточно, чтобы ответить на любой из этих вопросов.

Чтобы сравнить компромиссы моделей предоставления мощностей, сопоставьте serverless и выделенные GPU-мощности, определив допустимое время простоя и эксплуатационные потребности рабочей нагрузки.

Как оценивать производительность GPU-сервера

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

1. Измерьте результат для пользователя или задачи

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

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

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

2. Проверьте топологию до настройки фреймворка

Для рабочей нагрузки с несколькими GPU сначала изучите фактическую топологию. Рекомендации NVIDIA по NCCL советуют проверить внутрисерверную схему и измерить ожидаемую пропускную способность между GPU, прежде чем менять параметры настройки. В них также предупреждается, что улучшение в одном бенчмарке может навредить в другом месте.

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

3. Разделяйте время вычислений, коммуникации и передачи данных

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

1. Время в очереди и холодного старта
2. Время загрузки артефактов или модели
3. Предобработка на CPU или токенизация
4. Вычисления на GPU
5. Коммуникация между GPU или между узлами
6. Запись результатов, сохранение контрольной точки или постобработка

Эта декомпозиция делает следующий тест очевидным. Измеряйте производительность хранилища, если преобладает загрузка модели. Измеряйте топологию и коллективные операции, если синхронизированные задания останавливаются. Измеряйте поведение CPU и входного конвейера, если GPU ожидает. Затем повторно тестируйте ту же рабочую нагрузку, а не сравнивайте новую настройку с несвязанным запуском.

4. Используйте проверки работоспособности и активную диагностику для разных задач

Телеметрия в производственной среде показывает, наблюдалось ли на узле определенное состояние во время его работы. Активная диагностика проверяет, может ли выведенный из эксплуатации ресурс выполнить известную рабочую нагрузку. В документации NVIDIA DCGM Diagnostics проводится различие между этими подходами и отмечается, что активные тесты могут потреблять ресурсы вычислений, памяти, PCIe, межсоединений, питания и охлаждения.

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

Развертывание облачного GPU-сервера: последовательность с учетом требований production-среды

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

Шаг 1: Отделите постоянное состояние от заменяемых вычислительных ресурсов

Определите три класса данных:

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

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

Шаг 2: Зафиксируйте и задокументируйте программный стек

Документируйте образ ОС, ветку драйвера GPU, совместимость CUDA/среды выполнения, дайджест образа контейнера, версию фреймворка, редакцию модели и конфигурацию запуска. Не используйте «latest» как единственную ссылку на версию для production-нагрузки.

Эта запись помогает отличить проблему оборудования или топологии от случайного изменения программного обеспечения. Она также дает точку отката после обновления драйвера, среды выполнения или модели.

Шаг 3: Сделайте доступ закрытым по умолчанию

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

Точные меры зависят от вашего облака и границ соответствия требованиям, но принцип остается неизменным: открытый notebook, порт инференса или удаленный рабочий стол не являются стратегией развертывания.

Шаг 4: Проверьте хост перед приемом трафика рабочей нагрузки

Используйте короткий предварительный список проверок:

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

В кластере Kubernetes установите поддерживаемые поставщиком драйвер и device plugin до планирования рабочих нагрузок. Следующий минимальный шаблон иллюстрирует объявление ресурсов; адаптируйте образ, пространство имен, средства контроля безопасности и правила планирования для своей среды.

apiVersion: batch/v1
kind: Job
metadata:
  name: gpu-acceptance-check
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: workload
          image: registry.example.com/your-workload@sha256:replace-with-image-digest
          resources:
            limits:
              nvidia.com/gpu: 1

Используйте метки узлов, affinity, taints и квоты, чтобы несовместимые рабочие нагрузки не конкурировали за одни и те же мощности GPU. В руководстве по GPU-кластеру Kubernetes подробнее рассматриваются многоузловое планирование, очереди и операционные механизмы контроля.

Шаг 5: Создайте приемочный барьер перед production-средой

Используйте один и тот же барьер для каждого нового типа хоста, обновления образа или существенного изменения топологии.

Контроль затрат: платите за выполненную работу, а не за впечатляющую простаивающую машину

Стоимость облачных GPU — лишь одна строка в общей стоимости GPU-сервера. Сопоставляйте оплачиваемый период с полезным результатом:

стоимость выполненной работы = вычисления + хранилище + передача данных + накладные расходы платформы/эксплуатации + неудачная/повторно выполненная работа

Затем задайте следующие вопросы:

• Сервер остаётся запущенным, потому что обслуживает полезный трафик, или только потому, что его неудобно выключать?
• Создаёт ли нагрузка контрольные точки и предсказуемо очищает временные данные?
• Не копируются ли артефакты модели многократно вместо монтирования из специально организованного кэша или постоянного хранилища?
• Не перезапускаются ли неудачные задания без бюджета или классификации ошибок?
• Действительно ли многопроцессорная топология GPU улучшает важную для вас работу?

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

Когда GPU-сервер — подходящий инструмент, а когда нет

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

Выбирайте управляемую модель/API, когда прямой контроль над системой не является требованием, а приоритет — внедрить возможности модели без самостоятельного управления драйверами, выделением мощностей, обслуживанием среды выполнения и диагностикой оборудования. Решение следует принимать на основе стоимости выполненной работы и операционной нагрузки, а не просто сравнения «облачных GPU» и «API» по тарифной карточке. Подробнее об этой границе см. в статье облачные GPU и API модели.

Контрольный список развертывания GPU-сервера

Прежде чем одобрить сервер для production, убедитесь, что можете ответить «да» на каждый вопрос:

• Достаточно ли конкретно в описании нагрузки указаны модель, память, параллелизм и метрика успеха?
• Протестировали ли вы точную топологию GPU-сервера, а не только модель ускорителя?
• Можете ли вы воспроизвести программный стек по зафиксированным версиям и дайджестам образов?
• Отделено ли постоянное состояние от заменяемых вычислительных ресурсов?
• Есть ли у нагрузки ограниченный путь доступа и управляемые секреты?
• Есть ли у вас базовые показатели приложения, а также подтверждения по топологии и пути данных?
• Может ли оператор видеть состояние работоспособности, ошибки, утилизацию и активность, влияющую на стоимость?
• Протестировали ли вы перезапуск или замену, используя тот же план постоянного состояния?
• Останавливается, масштабируется или перепрофилируется ли сервер, когда он не выполняет полезную работу?

Часто задаваемые вопросы

Для чего используется GPU-сервер?

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

Всегда ли выделенный GPU-сервер быстрее бессерверных GPU-ресурсов?

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

Как выбрать подходящий GPU-сервер для LLM?

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

Нужен ли Kubernetes для одного GPU-сервера?

Нет. Один хорошо контролируемый хост может быть самым простым и надежным вариантом развертывания. Kubernetes становится полезнее, когда вам нужны воспроизводимое планирование, изоляция, политики, координация между несколькими узлами или общая емкость для разных команд. Добавляйте его потому, что он решает операционную проблему, а не потому, что используются GPU.

Как протестировать GPU-сервер перед вводом в эксплуатацию?

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

Стройте систему вокруг задачи

Правильный GPU-сервер — тот, который стабильно преобразует ваши предполагаемые входные данные в принятый выходной результат с измеримой производительностью, восстанавливаемым состоянием и контролируемой стоимостью эксплуатации. Начните с описания рабочей нагрузки, проверьте полученную систему и связывайте архитектурные решения с доказательствами, а не с названием оборудования.

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

Источники

• Kubernetes: планирование GPU
• NVIDIA GPU Operator
• NVIDIA DCGM Diagnostics
• NVIDIA NCCL: производительность и настройка
• NVIDIA Fabric Manager