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

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

GPU NVIDIA H200 — это ускоритель для дата-центров поколения Hopper, определяющей особенностью которого при развертывании является память: 141 ГБ HBM3e и 4,8 ТБ/с пропускной способности памяти на GPU. Это меняет подход к планированию инференса с длинным контекстом, больших батчей и HPC-задач, ограниченных памятью, но не отменяет необходимость планирования мощностей или проверки в облаке.

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

Краткий ответ

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

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

Характеристики GPU H200: что меняет ваш план развертывания

NVIDIA указывает H200 как GPU с архитектурой Hopper, 141 ГБ памяти HBM3e и пропускной способностью памяти 4,8 ТБ/с. Он доступен в вариантах H200 SXM и H200 NVL с одинаковыми ключевыми показателями памяти, но разными форм-факторами, энергопотреблением и вариантами масштабирования. Опубликованные NVIDIA пиковые показатели Tensor Core полезны для сравнения конфигураций продуктов, но не являются гарантией пропускной способности приложения: эти значения учитывают заявленные условия тестирования и допущения о разреженности. Перед выбором SKU ознакомьтесь с актуальными спецификациями продукта H200.

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

Почему HBM3e важна для инференса LLM

При обслуживании LLM память GPU используется не только весами модели. Полезное приближенное уравнение для оценки емкости:

required GPU memory = weights + runtime workspace + KV cache at p95 context and concurrency + operational headroom

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

H200 SXM или H200 NVL: выбирайте топологию, а не только карту

Форм-фактор — это выбор развертывания.

• H200 SXM подходит для системных конфигураций HGX H200 и NVIDIA-Certified с четырьмя или восемью GPU. Обычно это правильная отправная точка, когда одной рабочей нагрузке нужна тесно связанная многопроцессорная система, а приложению требуется часто обмениваться данными между GPU.
• H200 NVL — это двухслотовая конструкция PCIe с воздушным охлаждением. NVIDIA указывает конфигурации с мостом NVLink на 2 или 4 GPU, в то время как партнерские и сертифицированные системы могут содержать до восьми GPU. Не делайте вывод, что каждый сервер с восемью GPU предоставляет одинаковый прямой путь между GPU; изучите фактическую топологию и протестируйте коллективные операции, используемые вашей средой выполнения.
• Независимым репликам не всегда нужен наиболее тесно связанный fabric. Если каждая реплика обслуживает собственные запросы, прежде чем платить за топологию, которую рабочая нагрузка не будет использовать, отдайте приоритет емкости, доступности, ресурсам хоста и четкой границе планирования.

NVIDIA документирует емкость MIG для H200, но не считайте режимы совместного использования GPU взаимозаменяемыми. В Kubernetes MIG создает аппаратно изолированные экземпляры GPU, тогда как разделение по времени чередует выполнение задач и не обеспечивает изоляцию памяти или сбоев между репликами. Руководство по совместному использованию GPU Operator объясняет компромисс и ограничения мониторинга.

Более подробное сравнение для выбора доступно в статье H200 vs. H100. Это сравнение полезно для принятия решения; данная страница — руководство по развертыванию, когда H200 уже является кандидатом.

Когда GPU H200 подходит лучше всего

GPU H200 обычно стоит протестировать, если в production актуально одно из следующих ограничений:

1. Инференс LLM, ограниченный памятью. Длина контекста p95 или параллелизм исчерпывают практический бюджет памяти до полного использования вычислительных ресурсов.
2. Чувствительные к пропускной способности ИИ- или HPC-задачи. Профилирование показывает, что задача заметное время ожидает перемещения данных в памяти, а не просто насыщает вычисления Tensor Core.
3. Более крупный рабочий набор, размещаемый в памяти. Вам требуется больше места для модели, контекста поиска, пакета, кэша или научной структуры данных без немедленного добавления еще одного GPU.
4. Тесно связанные многографические задачи. Вы можете использовать систему в стиле H200 SXM/HGX и располагаете подтверждением, что приложение выигрывает от ее фабрики.
5. Требование к контролируемому разделению. У вас есть четкая причина использовать перечисленные конфигурации MIG, а также планировщик и модель распределения затрат, соответствующие им.

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

Составьте план емкости H200, прежде чем арендовать облачный GPU

Используйте этот одностраничный бриф перед созданием экземпляра или запросом пула узлов кластера.

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

Развертывание в облаке: поэтапный runbook для GPU H200

1. Подтвердите точную облачную конфигурацию

Запросите у провайдера или команды платформы точный форм-фактор ускорителя, количество GPU, выделение CPU/RAM, локальное и постоянное хранилище, характеристики сети и топологию GPU. Зафиксируйте ответ в тикете на развертывание. Одного обозначения «H200» недостаточно для оценки производительности в конфигурации с несколькими GPU.

Перед резервированием емкости проверьте эти сведения в краткосрочном пилотном развертывании:

• H200 SXM или H200 NVL
• количество GPU и вывод nvidia-smi topo -m
• является ли инстанс выделенным, разделённым или использующим разделение по времени
• версии драйвера, CUDA, среды выполнения контейнеров и фреймворка
• доступная оперативная память хоста, ядра CPU, пропускная способность хранилища и сетевой путь
• время загрузки образа, скачивания модели, создания контрольной точки и перезапуска

2. Установите поддерживаемый программный стек

Для развертывания в Kubernetes NVIDIA GPU Operator может управлять драйвером NVIDIA, Container Toolkit, плагином устройств, GPU Feature Discovery, мониторингом на базе DCGM и связанными компонентами. В официальном руководстве по установке отмечается необходимость согласованности операционной системы узлов, когда Operator управляет драйверами, а также предварительные требования к среде выполнения контейнеров и безопасности пространств имён. Следуйте актуальным инструкциям по установке GPU Operator, а не копируйте устаревшую версию чарта.

Начальная установка выполняется по следующему шаблону; замените версию на ту, которую вы проверили в соответствии с политиками вашего кластера и драйверов:

helm install --wait gpu-operator \
  -n gpu-operator --create-namespace \
  oci://nvcr.io/nvidia/cloud-native-charts/gpu-operator \
  --version=<validated-operator-version>

После установки проверьте поды Operator и состояние ClusterPolicy, прежде чем отправлять первую рабочую нагрузку. В руководстве по Operator также показано, как убедиться, что узлы сообщают о доступном для выделения ресурсе nvidia.com/gpu.

3. Явно задайте планирование

Начните с запроса эксклюзивного полного GPU, если только вы намеренно не спроектировали систему для режима совместного использования:

resources:
  limits:
    nvidia.com/gpu: 1

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

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

4. Подтвердите простую рабочую нагрузку, затем — реальную

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

1. Проверка платформы: драйвер и CUDA загружаются; планировщик видит ожидаемое количество GPU; контейнер может создать контекст CUDA.
2. Проверка фабрики: топология соответствует запланированной конфигурации; среды выполнения для нескольких GPU инициализируются и завершают репрезентативный коллективный тест.
3. Проверка приложения: воспроизведение репрезентативных промптов, размеров пакетов, длин контекста, шаблонов контрольных точек или входных данных симуляции достигает требуемых показателей задержки, пропускной способности и ошибок.

Третья проверка является решающей. Общий бенчмарк может показать, что GPU работает; но он не может показать, работают ли ваше распределение трафика, сервер модели и политика кэширования.

Проверьте производительность перед масштабированием

Стройте приёмочные тесты вокруг ожидаемого узкого места, а затем анализируйте результат, который может опровергнуть это предположение.

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

Для сервисов LLM отслеживайте как сигналы приложения, так и сигналы инфраструктуры:

• время до первого токена p50/p95 и межтокенная задержка
• принятые выходные токены в секунду и завершённые запросы в секунду
• глубина очереди, отмены, повторные попытки и частота ошибок
• выделенная и зарезервированная память GPU, загрузка GPU, энергопотребление и температура
• поведение попаданий в кэш/выгрузки и сбои, связанные с кэшем
• насыщение CPU хоста, нагрузка на RAM, ввод-вывод модели/чекпойнтов и задержка сети

Если один показатель улучшается, а другой ухудшается, пока не масштабируйтесь. Более высокая скорость обработки токенов при растущей задержке p95 или количестве повторных попыток может быть регрессией для сервиса, ориентированного на клиентов.

Оптимизируйте затраты по завершённой работе, а не по почасовому времени GPU

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

fully loaded hourly cost = accelerator + attached CPU/RAM + storage + network + licenses + operating overhead

cost per completed request = fully loaded hourly cost / completed requests per hour

cost per million accepted output tokens = fully loaded hourly cost / accepted output tokens per hour × 1,000,000

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

Есть также вопрос границы ответственности: вам нужно эксплуатировать среду выполнения или нужен надёжный доступ к выходным данным модели? Если вам нужны пользовательские ядра, конкретная среда выполнения, выделенная локальность данных или контролируемые эксперименты с оборудованием, пилотный проект с облачным GPU H200 может быть оправдан. Если вам в основном нужен API модели, перед тем как вкладываться в инфраструктуру, сравните операционную нагрузку с вариантом использования API. Руководство по развертыванию GPU-сервера и руководство по GPU-кластеру Kubernetes помогут явно определить эту границу.

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

Прежде чем считать развертывание H200 готовым, проверьте всё перечисленное ниже:

• [ ] Зафиксированы точные форм-фактор H200, количество GPU и топология
• [ ] Бюджет памяти протестирован при контексте p95 и ожидаемой параллельности
• [ ] Проверена совместимость драйвера, CUDA, фреймворка и образа контейнера
• [ ] Подтверждено состояние GPU Operator/плагина устройств там, где используется Kubernetes
• [ ] Планировщик предоставляет ожидаемую ёмкость nvidia.com/gpu
• [ ] Тест коллективных операций на нескольких GPU проходит на производственной топологии
• [ ] Репрезентативный нагрузочный тест соответствует целевым показателям TTFT, задержки, пропускной способности и ошибок
• [ ] Проверка состояния DCGM и диагностика в подходящие окна обслуживания включены в эксплуатационную документацию
• [ ] Измерены пути хранения, сети, загрузки модели, чекпойнтов и перезапуска
• [ ] Стоимость рассчитана на завершённую полезную единицу с учётом простаивающей и резервной мощности для восстановления

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

Сколько памяти у GPU H200?

NVIDIA указывает 141 ГБ памяти HBM3e и пропускную способность памяти 4,8 ТБ/с как для H200 SXM, так и для H200 NVL. Уточните точный SKU и конфигурацию системы у поставщика, поскольку форм-фактор карты и межсоединение различаются. Спецификации NVIDIA H200 являются источником приведённых в этом руководстве значений.

GPU H200 лучше H100 для инференса LLM?

Это возможно, особенно когда нагрузка ограничена ёмкостью памяти или пропускной способностью памяти. Практический ответ зависит от точности модели, длины контекста, поведения KV-кэша, параллельности, среды обслуживания и топологии системы. Сравнивайте нагрузку на репрезентативной трассе; не считайте бенчмарк поставщика заменой SLO вашего сервиса. См. сравнение H200 и H100, чтобы ознакомиться со схемой принятия аппаратного решения.

Что выбрать: H200 SXM или H200 NVL?

Выбирайте исходя из топологии. H200 SXM подходит для тесно связанных многопроцессорных конфигураций в стиле HGX. H200 NVL — это вариант PCIe с воздушным охлаждением и конфигурациями мостов NVLink на 2 или 4 GPU. Проверяйте топологию, хост и характер обмена данными в нагрузке, а не выбирайте только по объёму памяти.

Поддерживает ли GPU H200 MIG?

NVIDIA указывает до семи экземпляров MIG для H200 SXM и H200 NVL с различающимися заявленными объёмами памяти на экземпляр. Используйте MIG, когда вам нужны аппаратно обеспечиваемая изоляция памяти и изоляция сбоев. Не заменяйте его разделением времени, если требуются эти свойства изоляции.

Сколько GPU H200 мне нужно?

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

Начните с проверенного пилотного проекта на GPU H200

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

Источники

• Характеристики GPU NVIDIA H200
• Руководство по установке NVIDIA GPU Operator
• Документация по планированию GPU в Kubernetes
• Документация по диагностике NVIDIA DCGM