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

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

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

Для разработчиков ИИ и команд ML-инфраструктуры практический вопрос обычно таков: могут ли модель, ее максимальный активный контекст и накладные расходы времени выполнения разместиться на одном GPU с достаточным запасом? Если нет, может ли рабочая нагрузка оставаться внутри высокоскоростного узла H200, прежде чем ей потребуется пересечь сеть? Ответ должен определять форм-фактор, план параллелизма и приемочные тесты, а не показатель пиковых TFLOPS.

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

Краткий ответ: когда GPU Nvidia H200 хорошо подходит

Выбирайте GPU Nvidia H200, если верны все или большинство следующих условий:

• Ваша рабочая нагрузка ограничена памятью модели, ростом KV-кеша или пропускной способностью памяти, а не только вычислительной производительностью.
• Вам требуется больше ресурсов для инференса с длинным контекстом или одновременных запросов без немедленного разделения модели между узлами.
• Вы можете проверить фактическую топологию облака — форм-фактор SXM или PCIe/NVL, число GPU на узел и доступное межсоединение, — а не рассматривать «H200» как полную спецификацию развертывания.
• Вы готовы измерять время до первого токена, пропускную способность по выходным токенам, задержку на хвосте распределения, память GPU и очередь при той же форме запросов, которую ожидаете в production.
• Вам нужен достаточный контроль над ПО для обслуживания, весами модели, батчингом или локальностью данных, чтобы оправдать непосредственную эксплуатацию GPU-ресурсов.

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

Архитектура GPU Nvidia H200: спецификации, которые меняют решения по развертыванию

H200 использует архитектуру Hopper от NVIDIA. Hopper включает Transformer Engine и NVLink четвертого поколения; NVIDIA позиционирует эти возможности для работы с трансформерами в смешанной точности и коммуникации между несколькими GPU. Обзор архитектуры Hopper также объясняет, почему топология сервера важна, когда рабочие нагрузки выходят за пределы одного ускорителя.

Источник: спецификации NVIDIA H200. NVIDIA отмечает, что в некоторых опубликованных показателях производительности используется разреженность; используйте эти показатели как справочник по возможностям, а не как обещание производственной пропускной способности.

Объем памяти — это параметр развертывания, а не маркетинговая цифра

Для обслуживания LLM планируйте HBM с учетом полного рабочего набора:

required GPU memory ≈ model weights
                    + peak active KV cache
                    + runtime workspaces
                    + fragmentation and safety margin

Контрольная точка модели — лишь первый элемент. Конфигурация, которая успешно загружается, всё равно может оставлять слишком мало места для активного контекстного окна и параллельных последовательностей, которые вы планируете обслуживать. Поэтому 141 ГБ HBM3e у H200 могут быть полезны, даже если модель технически помещается в конфигурацию класса H100: это даёт развертыванию больше возможностей балансировать размер батча, длину контекста и параллелизм относительно задержки.

Перед резервированием мощностей зафиксируйте следующие параметры рабочей нагрузки:

1. Модель, формат весов и любой режим квантования или точности.
2. Максимальное число входных токенов и максимальное число генерируемых токенов для реального запроса.
3. Ожидаемое количество одновременно активных последовательностей, а не только запросов в секунду.
4. SLO по задержке, включая время до первого токена и задержку на хвосте распределения.
5. Нужны ли приложению один полноразмерный GPU, изолированный раздел или многографическая реплика модели.

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

Пропускная способность и топология требуют отдельных проверок

Пропускная способность памяти может быть не менее важна, чем вычислительная производительность, для авторегрессионного декодирования и нагрузок с интенсивным использованием памяти. Когда модель шардирована, важна и пропускная способность между GPU. Не следует предполагать, что восемь GPU H200 образуют единый общий пул памяти объёмом 1 128 ГБ: распределённое ПО для обслуживания должно размещать тензоры и обмениваться активациями по фактически доступным ему соединениям.

NVIDIA указывает, что NVLink четвёртого поколения обеспечивает 900 ГБ/с двунаправленной пропускной способности на GPU в системах DGX и HGX, а NVSwitch поддерживает домен из восьми GPU. Поэтому топологию одного узла следует оценивать отдельно от многоузлового кластера. Справочник NVIDIA по архитектуре Hopper является источником сведений о возможностях межсоединений; документация по инстансам облачного провайдера — источником сведений о топологии, которую вы фактически получаете.

H200 SXM и H200 NVL: выберите схему развертывания до выбора инстанса

«H200» не обозначает единую конструкцию сервера. Два распространённых варианта развертывания имеют разные эксплуатационные последствия.

В таблице спецификаций NVIDIA для обоих форм-факторов указаны 141 ГБ HBM3e и пропускная способность памяти 4,8 ТБ/с. Для многографической нагрузки определяющим фактором часто является сервер и топология соединений вокруг этой памяти. Рассматривайте схему топологии провайдера и проверку топологии внутри инстанса как обязательные артефакты при закупке.

Матрица принятия решений «рабочая нагрузка — топология»

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

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

Практическое руководство по развертыванию рабочих нагрузок Nvidia H200 GPU в облаке

Наиболее безопасный подход к развертыванию — поэтапный. Каждый этап отвечает на один вопрос, прежде чем вы добавите еще один источник вариативности.

1. Составьте контракт рабочей нагрузки

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

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

2. Проверьте узел перед развертыванием сервера модели

После загрузки инстанса определите физическую топологию, а не полагайтесь на его название продукта:

nvidia-smi topo -m
nvidia-smi topo -p2p n

NVIDIA рекомендует эти проверки при диагностике топологии и поведения NVLink. В ее руководстве по производительности и настройке NCCL также рекомендуется использовать nvbandwidth или nvloom, чтобы проверить, соответствует ли измеренная пропускная способность между GPU ожидаемому аппаратному пути.

Зафиксируйте вывод топологии в руководстве по развертыванию. Это делает последующую регрессию производительности проверяемой: вы сможете отличить изменение приложения от другого размещения PCIe, NVLink или сети.

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

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

GPU Operator от NVIDIA может управлять драйвером, NVIDIA Container Toolkit, плагином устройств, DCGM Exporter и MIG Manager как согласованным стеком на рабочих узлах с GPU. Используйте актуальную документацию по установке GPU Operator и убедитесь, что его validator- и operator-поды исправны, прежде чем развертывать сервер модели.

Минимальный запрос ресурсов концептуально прост:

resources:
  limits:
    nvidia.com/gpu: 4

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

4. Начните с теста обслуживания с одной переменной

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

vllm serve <model-identifier> \
  --tensor-parallel-size 4

Это намеренно пример топологии, а не готовая к копированию и запуску команда для production. Зафиксируйте образ контейнера, совместимость драйвера/CUDA, ревизию модели, токенизатор и версию движка обслуживания в собственном манифесте развертывания. Затем изменяйте по одной переменной за раз: размер тензорного параллелизма, максимальное число активных последовательностей, политику выделения кэша или число реплик.

5. Тестируйте prefill и decode отдельно

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

• Время до первого токена для коротких и длинных входных промптов.
• Пропускную способность по выходным токенам после первого токена.
• Сквозную задержку P50, P95 и P99.
• Используемую память GPU, давление на кэш и события нехватки памяти.
• Время в очереди, отмены запросов, повторные попытки и частоту ошибок.

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

6. По возможности добавляйте реплики до добавления узлов

Если один узел H200 вмещает модель и соответствует целевым показателям задержки, добавление реплик может быть операционно проще, чем введение второго узла. Когда вы переходите на несколько узлов, сначала протестируйте сеть и путь коллективных операций. Для многоузлового инференса поддерживайте согласованность среды и артефактов модели между узлами; несоответствие контейнера, драйвера, ревизии модели или токенизатора может выглядеть как аппаратная проблема.

Не задавайте принудительно настройки алгоритмов NCCL до сбора базовых данных топологии. В документации NVIDIA по NCCL указано, что выбор по умолчанию учитывает топологию; ручные настройки являются реакцией на измеренное поведение, а не заменой измерений.

7. Отслеживайте емкость до того, как трафик окажется под угрозой

DCGM Exporter может предоставлять телеметрию GPU в стек мониторинга Kubernetes. NVIDIA документирует его как часть стека под управлением GPU Operator и предоставляет рекомендации по установке для сред Prometheus в своей документации DCGM Exporter.

Создавайте дашборды, связывающие состояние инфраструктуры с результатами работы сервиса:

8. Планируйте поведение при сбоях и обслуживании

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

Производительность: тестируйте нагрузку, а не рекламный буклет

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

Для практического сравнения H200 зафиксируйте следующие переменные:

1. Версия модели, токенизатор, точность и квантование.
2. Распределение длины промптов и выходных токенов.
3. Параллелизм и политика контроля допуска.
4. Схема тензорного/конвейерного параллелизма и фактическая аппаратная топология.
5. Версии движка обслуживания и CUDA/NCCL.
6. Метод измерения SLA, включая прогрев и состояние кэша.
7. Единица тарификации облака и расходы, не связанные с GPU, такие как хранилище, исходящий трафик, CPU и эксплуатация.

Такой план тестирования ценнее общего сравнения «токенов в секунду», поскольку он показывает, меняет ли Nvidia H200 GPU SLO, заметный для клиента, или стоимость завершенного запроса.

Чек-лист развертывания H200

Используйте этот чек-лист как критерий готовности к публикации новой нагрузки H200.

• [ ] Зафиксируйте модель, точность, максимальную длину контекста, длину вывода и целевой уровень параллелизма.
• [ ] Рассчитайте бюджет памяти для весов, KV-кэша, рабочего пространства среды выполнения и запаса безопасности.
• [ ] Подтвердите, является ли выделенная H200 версией SXM или NVL, и сохраните nvidia-smi topo -m.
• [ ] Проверьте совместимость драйвера, CUDA, контейнера, фреймворка и движка обслуживания.
• [ ] Запросите требуемое количество GPU с ограничениями на размещение в оркестраторе.
• [ ] Выполните проверку работоспособности CUDA/операторов перед загрузкой модели.
• [ ] Проведите проверку топологии и пропускной способности коллективных операций перед принятием результата для нескольких GPU.
• [ ] Отдельно измеряйте трафик с коротким и длинным контекстом.
• [ ] Отслеживайте TTFT, пропускную способность выходных токенов, задержку P95/P99, время в очереди, ошибки и память GPU.
• [ ] Протестируйте сценарии перезапуска, вывода узла из эксплуатации и сокращения емкости.
• [ ] Сравните результат с базовым уровнем управляемого API модели при той же нагрузке и SLO.
• [ ] Сохраните топологию, конфигурацию бенчмарка и допущения по стоимости вместе с решением о развертывании.

Когда API модели — лучший выбор для развертывания в облаке

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

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

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

Каков объем памяти GPU Nvidia H200?

По данным NVIDIA, каждый GPU H200 оснащен 141 ГБ памяти HBM3e с пропускной способностью 4,8 ТБ/с. Это показатели одного ускорителя, поэтому, если модель и активный кэш превышают доступный объем памяти одного GPU, вам потребуется план распределенного обслуживания запросов.

H200 предназначен в первую очередь для инференса или для обучения?

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

В чем разница между H200 SXM и H200 NVL?

Это разные форм-факторы H200 и способы интеграции в серверы. NVIDIA указывает, что системы SXM используют соединение NVLink в конфигурациях типа HGX с 4 или 8 GPU, тогда как H200 NVL имеет двухслотовый форм-фактор PCIe с документированными вариантами мостового соединения. Прежде чем рассчитывать на эквивалентное поведение систем с несколькими GPU, уточните фактическую топологию у облачного провайдера.

Можно ли запускать рабочую нагрузку на H200 в Kubernetes?

Да, при условии, что в кластере установлены совместимый драйвер NVIDIA, среда выполнения контейнеров с необходимой конфигурацией и плагин устройств. Kubernetes планирует выделение GPU как расширенных ресурсов, а NVIDIA GPU Operator может управлять программным стеком GPU и компонентами телеметрии. Прежде чем направлять производственный трафик, проверьте метки узлов, запрос ресурсов GPU, работоспособность оператора и целевые показатели уровня обслуживания (SLO) на уровне приложения.

Стоит ли выбрать H200 вместо H100?

Выбирайте исходя из узкого места системы. Больший объем памяти HBM3e и более высокая заявленная пропускная способность памяти H200 могут быть полезны при обслуживании запросов с ограничениями по памяти, но H100 по-прежнему может удовлетворять требованиям менее ресурсоемкой нагрузки и лучше подходить с эксплуатационной или коммерческой точки зрения. Сравнивайте одинаковые форм-факторы и тестируйте обе конфигурации на одной и той же рабочей нагрузке. В нашем руководстве по сравнению H200 и H100 изложены критерии выбора.

Обеспечьте воспроизводимость решения о развертывании

Архитектура H200 особенно привлекательна, когда реальные ограничения связаны с памятью и топологией. Чтобы решение об использовании GPU Nvidia H200 можно было воспроизвести, храните вместе описание требований рабочей нагрузки, план использования памяти, топологию оборудования, версии программного обеспечения и результаты нагрузочного тестирования. Эти сведения помогут следующему инженеру объяснить, почему развернутая система работает, и определить, что изменилось, если она перестанет работать.

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