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

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

GPU NVIDIA H100 — это ускоритель для дата-центров поколения Hopper, созданный для обучения ИИ, высокопроизводительного инференса и технических вычислений. Его ценность в облаке не определяется только заявленным числом FLOPS. Важно, соответствуют ли объём памяти, пропускная способность памяти, поддержка точности, межсоединение GPU и операционная модель тем моделям и сервисам, которые вам необходимо запускать.

Для разработчика ИИ или инженера ML-инфраструктуры решение по GPU NVIDIA H100 имеет три уровня:

1. Поместятся ли модель, KV-кеш, состояние оптимизатора и рабочая область с безопасным запасом?
2. Требуется ли для нагрузки один GPU, тесно связанный многопроцессорный узел или распределённый кластер?
3. Сможет ли развёртывание соответствовать целевым показателям задержки, пропускной способности, надёжности и стоимости после настройки инструментирования в production?

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

Для чего создан GPU NVIDIA H100

GPU NVIDIA H100 основан на архитектуре NVIDIA Hopper. Hopper представила Tensor Cores четвёртого поколения, Transformer Engine с поддержкой FP8, память HBM3 в конфигурации H100 SXM, NVLink и возможность Multi-Instance GPU (MIG). Эти возможности важны по разным причинам:

• Tensor Cores и Transformer Engine влияют на то, какие пути смешанной точности могут использовать фреймворк ИИ или движок инференса.
• Ёмкость и пропускная способность HBM определяют, помещаются ли веса модели, активации и KV-кеш, а также насколько быстро нагрузки, ограниченные памятью, могут перемещать данные.
• NVLink и топология системы влияют на стоимость обмена данными, когда нагрузка распределена между GPU.
• MIG позволяет разделить поддерживаемый GPU на изолированные экземпляры для небольших совместимых нагрузок.

Семейство продуктов H100 — это не единая облачная конфигурация. Перед сравнением предложений определите, рассматриваете ли вы систему H100 SXM, конфигурацию H100 NVL или другое предложение на базе H100 PCIe. Форм-фактор и межсоединение могут изменить оптимальный подход к параллелизму, планированию и бенчмаркингу.

Архитектура GPU NVIDIA H100: факты, важные для развёртывания

NVIDIA указывает для H100 SXM 80 ГБ памяти HBM3, пропускную способность памяти GPU 3,35 ТБ/с, пропускную способность NVLink до 900 ГБ/с и до семи экземпляров MIG по 10 ГБ. NVIDIA отдельно указывает для H100 NVL 94 ГБ памяти, пропускную способность 3,9 ТБ/с, пропускную способность NVLink до 600 ГБ/с, а также двухслотовый форм-фактор PCIe с воздушным охлаждением. Рассматривайте эти характеристики как факты о конфигурациях продуктов, а не как обещание, что каждое облачное предложение предоставляет ту же топологию или полезную ёмкость. Перед развёртыванием подтвердите точную конфигурацию инстанса. Спецификации продукта NVIDIA H100

Подробное описание архитектуры Hopper от NVIDIA объясняет, почему эти компоненты работают вместе: Tensor Cores четвёртого поколения добавляют FP8 и Transformer Engine, тогда как H100 SXM сочетает HBM3 с пропускной способностью памяти более 3 ТБ/с. Обзор архитектуры NVIDIA Hopper

Не используйте пиковую вычислительную производительность как оценку для развёртывания

Пиковая производительность Tensor Cores полезна для сравнения оборудования, но не является SLA приложения. В production измеряемая производительность зависит от архитектуры модели, точности, размера пакета, сочетания длин последовательностей, выбора ядер, кеширования, загрузки данных, накладных расходов на коммуникации и ограничений задержки на уровне сервиса.

Для нового развёртывания GPU NVIDIA H100 сначала определите тест приемки нагрузки. Для сервиса LLM он обычно включает время до первого токена, межтокенную задержку, сквозную задержку p50/p95, количество принятых выходных токенов в секунду, время в очереди, частоту ошибок и проверки качества. Для обучения отслеживайте время на шаг, количество примеров в секунду, время создания контрольных точек, характер сходимости и состояние all-reduce.

Выберите топологию H100 до выбора облачного контракта

Один и тот же ускоритель можно развёртывать совершенно по-разному. Начинайте со схемы коммуникации, а не с названия GPU.

GPU NVIDIA H100 в однографической VM может быть разумным первым шагом к эксплуатации в production. Развёртывание H100 с несколькими GPU следует рассматривать как систему: топология хоста, межсоединение, сеть, CPU, хранилище, программный стек и планировщик — всё это влияет на результат. Более широкий взгляд на аппаратную систему см. в руководстве Flatkey по развёртыванию GPU-сервера.

Практический процесс развёртывания в облаке

1. Подготовьте краткое описание рабочей нагрузки перед выделением ресурсов

Зафиксируйте сведения, которые делают бенчмарк воспроизводимым:

• Название модели, ревизия, число параметров и точность.
• Целевая длина контекста, соотношение входных и выходных данных и профиль параллельности.
• Цель: обучение, дообучение, пакетный инференс или онлайн-обслуживание.
• SLO по задержке, целевая пропускная способность и порог качества или точности.
• Требуемый регион, граница данных, постоянное хранилище, сетевой доступ и целевое время восстановления.

Для инференса LLM рассчитывайте память как бюджет, а не только исходя из весов модели:

требуемая память GPU = веса модели + KV-кэш при целевой параллельности
                      + рабочее пространство среды выполнения + буферы коммуникации
                      + запас на фрагментацию и вариативность развёртывания

Правильное значение определяется репрезентативным нагрузочным тестом. Модель, которая успешно запускается, всё равно может не выполнить цель по параллельности или длинному контексту при росте KV-кэша.

2. Проверяйте экземпляр, а не только маркировку ускорителя

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

• Вариант H100, количество GPU и объём VRAM на устройство.
• Топология GPU-to-GPU и наличие в предложении NVLink или узла на базе NVSwitch.
• Количество ядер CPU, объём RAM хоста, локальный NVMe и сетевой интерфейс.
• Совместимость драйвера, CUDA, среды выполнения контейнеров и фреймворка.
• Является ли ёмкость выделенной, прерываемой или подпадает под политику отзыва.
• Как работают снимки, контрольные точки, частная сеть и экспорт метрик.

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

3. Проверьте оборудование и сетевую фабрику

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

nvidia-smi
nvidia-smi topo -m

# Запустите внутри того же образа, совместимого с CUDA, который будет использовать ваша рабочая нагрузка.
nvidia-smi --query-gpu=name,memory.total,driver_version --format=csv

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

4. Используйте Kubernetes только тогда, когда он решает эксплуатационную задачу

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

Для развёртываний Kubernetes GPU Operator от NVIDIA автоматизирует драйвер NVIDIA, Container Toolkit, плагин устройств, GPU Feature Discovery, мониторинг на базе DCGM и связанные компоненты GPU. Его стандартная установка также развёртывает MIG Manager на рабочих узлах с GPU. Перед установкой ознакомьтесь с текущей матрицей поддержки и предварительными требованиями к установке: управляемые предложения Kubernetes могут уже предоставлять часть стека. Документация NVIDIA GPU Operator Руководство по установке

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

resources:
  limits:
    nvidia.com/gpu: 1

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

5. Осознанно выберите стек для инференса или обучения

Оборудование H100 не выберет за вас подходящую среду выполнения. Используйте стек обслуживания, поддерживающий вашу модель и эксплуатационные ограничения, затем проверьте его на трафике, приближенном к производственному. Например, TensorRT-LLM предоставляет API и среды выполнения для оптимизированного инференса LLM на GPU NVIDIA; его производительность всё равно необходимо измерять с вашей моделью, точностью, политикой пакетирования и целевыми показателями задержки. Документация TensorRT-LLM

Для развёртывания производственного инференса:

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

6. Инструментируйте GPU NVIDIA H100 как часть сервиса

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

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

Оптимизация производительности: безопасный порядок действий

Если сервис на GPU NVIDIA H100 не достигает целевого показателя, оптимизируйте в следующей последовательности:

1. Подтвердите целевой показатель. Проблема заключается в задержке, пропускной способности, стоимости одной завершённой задачи, качестве или надёжности?
2. Проверьте базовый уровень. Повторно запустите ту же трассу с той же моделью, образом, драйвером, топологией и конкурентностью.
3. Найдите ограничивающий ресурс. Им могут быть VRAM, пропускная способность памяти, вычислительные ресурсы, токенизация на CPU, обмен данными по PCIe/NVLink, сеть, хранилище или политика постановки в очередь.
4. Изменяйте одну переменную. Например, политику пакетирования, максимальный контекст, степень тензорного параллелизма, точность, количество реплик или конфигурацию кэша.
5. Повторно пройдите функциональные проверки и проверки качества. Более быстрый вывод не является успехом, если он увеличивает число тайм-аутов или изменяет качество модели за пределы допустимого диапазона.
6. Документируйте рабочие границы. Зафиксируйте настройки, измеренный результат и условия, при которых результат является валидным.

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

Контроль затрат без ненадёжного сравнения почасовых цен

Цены на облачные H100, доступность и условия выставления счетов различаются в зависимости от поставщика, региона, обязательств и типа ёмкости. Вместо использования устаревшей тарифной сетки в качестве правила принятия решений сравнивайте выполненную работу:

стоимость одного успешного результата =
  (время работы GPU-инстанса + хранилище + сеть + операционные накладные расходы)
  / успешные результаты в том же окне измерения

Для сервиса инференса точно определите «успешный результат»: принятые токены, завершённые запросы, сгенерированные изображения, оценённые документы или другой вывод, соответствующий вашим требованиям к качеству и SLO. Учитывайте оплачиваемое время простоя и повторные попытки. Затем сравните это значение с альтернативой в виде API управляемой модели, если продукту не требуется контроль на уровне GPU.

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

Чек-лист развёртывания GPU NVIDIA H100

Прежде чем объявить сервис готовым, проверьте всё следующее:

• [ ] Точная конфигурация H100, VRAM, топология, CPU/RAM, хранилище и сеть документированы.
• [ ] Бюджет памяти модели включает веса, KV-кеш, рабочее пространство среды выполнения, коммуникационные буферы и запас.
• [ ] Совместимость драйвера, CUDA, фреймворка и образа контейнера протестирована на целевой конфигурации.
• [ ] Тесты на одном GPU, а при необходимости — топологии с несколькими GPU и коллективные тесты успешно пройдены.
• [ ] Трассировка, соответствующая продакшену, отвечает целевым показателям задержки, пропускной способности, качества и ошибок.
• [ ] Метрики GPU, сети, среды выполнения, пользовательского опыта и затрат доступны в едином операционном представлении.
• [ ] Определены постепенное развёртывание, артефакт для отката, стратегия контрольных точек и ответственный за инциденты.
• [ ] Стоимость выполненной работы сопоставлена с наиболее реалистичной альтернативой, а не только с почасовой ценой GPU.

Как H100 вписывается в выбор AI GPU

GPU NVIDIA H100 хорошо подходит, когда рабочая нагрузка выигрывает от возможностей Tensor Core поколения Hopper, высокой пропускной способности HBM, топологии с несколькими GPU или развёртывания, требующего контроля над средой выполнения и потоком данных. Однако это не означает, что она автоматически является правильным выбором для любой задачи ИИ. Меньший ускоритель, более новый GPU с акцентом на память или управляемый API модели могут быть более подходящими, если модель невелика, спрос носит всплесковый характер, команда не может поддерживать GPU-сервис или аппаратно-специфичная оптимизация не меняет результат продукта.

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

Для прямого сравнения H100 и его версии с большей памятью прочитайте H200 vs H100 (2026).

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

Для чего используется GPU NVIDIA H100?

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

Отличается ли H100 SXM от H100 PCIe или H100 NVL?

Да. Могут различаться форм-фактор, конфигурация памяти, пропускная способность NVLink, энергетический профиль, охлаждение и топология системы. Изучайте точную спецификацию облачного предложения, а не считайте «H100» полным описанием конфигурации.

Сколько памяти GPU имеет H100?

NVIDIA указывает для H100 SXM 80 ГБ памяти HBM3, а для H100 NVL — 94 ГБ. При расчёте требуемой ёмкости также необходимо учитывать рабочее пространство среды выполнения, KV-кеш, память активаций или обучения, коммуникационные буферы и запас безопасности. Спецификации NVIDIA H100

Нужен ли Kubernetes для запуска рабочей нагрузки H100 в облаке?

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

Стоит ли выбрать H100 или H200 для инференса LLM?

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

Итог

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

Если вы всё ещё выбираете уровень инфраструктуры, воспользуйтесь руководством Flatkey по выбору AI GPU, чтобы сравнить соответствие рабочих нагрузок различным семействам GPU и моделям развёртывания.