Продолжаем статьи про практические тесты актуальных картонок от Nvidia (RTX 5090, A5000 AdaA1003090 и A10). В этот раз мне уже предложили покрутить на несколько часиков H100 с 80 GB VRAM.

Тренировать ничего не будем, снимем попугаев через gpu-burn , попробуем MIG (multi-instance GPU) и также замерим инференс одной нашей прожорливой сетки.

С A100 мне как-то тоже пришлось поиграться, но я не думал, что в России в принципе появятся H100. Поэтому в этот раз шутка будет про санкции и про сумочку, сделанную из H100.

Также пару слов расскажем про "фишку" MIG, доступную для самых толстых карт в линейках NVIDIA (из "доступных" в основном A100 и H100, но есть и экзотика типа RTX PRO 6000 Blackwell Workstation Edition, GB200, B200, H200, A30).

В конце даже получилась небольшая детективная история.

Запредельная цена и характеристики

Для начала, как обычно дежурная шутка про политику ценообразования Nvidia:

Смешная шутка
Сравнение характеристик всех карточек, которые я тыкал или держал в руках
Сравнение характеристик всех карточек, которые я тыкал или держал в руках

Очевидные вещи:

  • 80 GB VRAM;

  • Пассивная 2-слотовая (!) карта с относительно низким TDP;

  • Новый "плохой" разъем питания (даже я уже писал про это, мало смысла повторяться);

  • Метрики количества CUDA или тензорных ядер тут вряд ли показательны;

Интерес тут представляет примерная цена, за которую её оказывается можно купить в России. Она ровно в 2 раза выше цены на A100 (в момент её выхода) и составляет порядка 3М рублей. Аренда одной такой карточки стоит порядка 300 - 350 килорублей в месяц. Чуть забегая вперёд … цена проиндексирована от цены A100 выгоднее теоретического прироста производительности, но за очень короткий период тестирования мы не смогли раскрыть этот потенциал.

Пара слов про MIG

Для очень толстых серверных видеокарт, у Nvidia есть технология MIG, которая позволяет "разделить" 1 толстую карточку на несколько якобы физически изолированных маленьких. Согласно документации изоляция якобы является полной:

Умная цитата

For Cloud Service Providers (CSPs), who have multi-tenant use cases, MIG ensures one client cannot impact the work or scheduling of other clients, in addition to providing enhanced isolation for customers.

With MIG, each instance’s processors have separate and isolated paths through the entire memory system - the on-chip crossbar ports, L2 cache banks, memory controllers, and DRAM address busses are all assigned uniquely to an individual instance. This ensures that an individual user’s workload can run with predictable throughput and latency, with the same L2 cache allocation and DRAM bandwidth, even if other tasks are thrashing their own caches or saturating their DRAM interfaces. MIG can partition available GPU compute resources (including streaming multiprocessors or SMs, and GPU engines such as copy engines or decoders), to provide a defined quality of service (QoS) with fault isolation for different clients such as VMs, containers or processes. MIG enables multiple GPU Instances to run in parallel on a single, physical NVIDIA Ampere architecture GPU.

With MIG, users will be able to see and schedule jobs on their new virtual GPU Instances as if they were physical GPUs. MIG works with Linux operating systems, supports containers using Docker Engine, with support for Kubernetes and virtual machines using hypervisors such as Red Hat Virtualization and VMware vSphere. MIG supports the following deployment configurations:

  • Bare-metal, including containers

  • GPU pass-through virtualization to Linux guests on top of supported hypervisors

  • vGPU on top of supported hypervisors

MIG allows multiple vGPUs (and thereby VMs) to run in parallel on a single GPU, while preserving the isolation guarantees that vGPU provides. For more information on GPU partitioning using vGPU and MIG, refer to the technical brief.

Технология всё ещё не предназначена для тренировки нейросетей (вспоминая мои извращения на A100), но касательно использования карт есть вот такие соображения:

Ограничения MIG
  • No graphics APIs are supported (for example, OpenGL, Vulkan and so on). The exception to this is RTX Pro 6000 Blackwell GPUs where certain MIG profiles support graphics.

  • No GPU to GPU P2P (either PCIe or NVLink) is supported.

  • CUDA applications treat a Compute Instance and its parent GPU Instance as a single CUDA device. See this section on device enumeration by CUDA.

  • CUDA IPC across GPU instances is not supported. CUDA IPC across Compute instances is supported.

  • CUDA debugging (e.g. using cuda-gdb) and memory/race checking (for example, using cuda-memcheck or compute-sanitizer) is supported.

  • CUDA MPS is supported on top of MIG. The only limitation is that the maximum number of clients (48) is lowered proportionally to the Compute Instance size.

  • GPUDirect RDMA is supported when used from GPU Instances.

MIG supports running CUDA applications by specifying the CUDA device on which the application should be run. With CUDA 11/R450 and CUDA 12/R525, only enumeration of a single MIG instance is supported. In other words, regardless of how many MIG devices are created (or made available to a container), a single CUDA process can only enumerate a single MIG device. CUDA applications treat a CI and its parent GI as a single CUDA device. CUDA is limited to use a single CI and will pick the first one available if several of them are visible. To summarize, there are two constraints:

  1. CUDA can only enumerate a single compute instance

  2. CUDA will not enumerate non-MIG GPU if any compute instance is enumerated on any other GPU

Note that these constraints may be relaxed in future NVIDIA driver releases for MIG. CUDA_VISIBLE_DEVICES has been extended to add support for MIG. Depending on the driver versions being used, two formats are supported:

  1. With drivers >= R470 (470.42.01+), each MIG device is assigned a GPU UUID starting with MIG-<UUID>.

  2. With drivers < R470 (for example, R450 and R460), each MIG device is enumerated by specifying the CI and the corresponding parent GI. The format follows this convention: MIG-<GPU-UUID>/<GPU instance ID>/<compute instance ID>.

Мой надмозг тут выделяет самые важные ограничения:

  • Графические АПИ недоступны;

  • Тренировать нейросети с поддержкой GPU to GPU P2P (PCIe или NVLink) не получится;

  • В рамках одного CUDA-процесса возможно только указать одно MIG-устройство;

  • Нельзя мешать MIG-подустройство и просто обычную карточку в рамках CUDA-процесса;

  • CUDA_VISIBLE_DEVICES теперь поддерживает указывание MIG-устройства по UUID, например MIG-42753a49-5c48-5303-b7fa-1b474afcfe6a.

Как это выглядит на практике

Документация довольно обширная и подробная, но на практике всё сводится к вызову небольшого числа команд, указанных в документации.

Не будем повторять их. Важно отметить, что доступно несколько разных профилей "распиливания" карты на кусочки, и профиль на 4 и 7 "подкарт" имеет разное количество памяти, но одинаковые вычислительные возможности на каждый кусочек. Смешивать разные профили мы не пробовали, но это возможно.

Список доступных профилей
ubuntu@h100-test:~/gpu-burn$  nvidia-smi mig -lgip
 +-------------------------------------------------------------------------------+
 | GPU instance profiles:                                                        |
 | GPU   Name               ID    Instances   Memory     P2P    SM    DEC   ENC  |
 |                                Free/Total   GiB              CE    JPEG  OFA  |
 |===============================================================================|
 |   0  MIG 1g.10gb         19     7/7        9.75       No     14     1     0   |
 |                                                               1     1     0   |
 +-------------------------------------------------------------------------------+
 |   0  MIG 1g.10gb+me      20     1/1        9.75       No     14     1     0   |
 |                                                               1     1     1   |
 +-------------------------------------------------------------------------------+
 |   0  MIG 1g.20gb         15     4/4        19.62      No     14     1     0   |
 |                                                               1     1     0   |
 +-------------------------------------------------------------------------------+
 |   0  MIG 2g.20gb         14     3/3        19.62      No     30     2     0   |
 |                                                               2     2     0   |
 +-------------------------------------------------------------------------------+
 |   0  MIG 3g.40gb          9     2/2        39.50      No     46     3     0   |
 |                                                               3     3     0   |
 +-------------------------------------------------------------------------------+
 |   0  MIG 4g.40gb          5     1/1        39.50      No     62     4     0   |
 |                                                               4     4     0   |
 +-------------------------------------------------------------------------------+
 |   0  MIG 7g.80gb          0     1/1        79.25      No     114    7     0   |
 |                                                               8     7     1   |
 +-------------------------------------------------------------------------------+

После распиливания система видит "подкарточки" следующим образом (для разных пресетов):

Подкарточки
ubuntu@h100-test:~/gpu-burn$ nvidia-smi -L
GPU 0: NVIDIA H100 PCIe (UUID: GPU-b7993cf0-88bc-732c-4f8a-12f4234a7cf9)
  MIG 7g.80gb     Device  0: (UUID: MIG-761616d7-1d64-58ca-bd17-0c0134f5e1bb)

ubuntu@h100-test:~/gpu-burn$ sudo nvidia-smi mig -lgi
+---------------------------------------------------------+
| GPU instances:                                          |
| GPU   Name               Profile  Instance   Placement  |
|                            ID       ID       Start:Size |
|=========================================================|
|   0  MIG 3g.40gb            9        1          4:4     |
+---------------------------------------------------------+
|   0  MIG 3g.40gb            9        2          0:4     |
+---------------------------------------------------------+

ubuntu@h100-test:~$ nvidia-smi -L
GPU 0: NVIDIA H100 PCIe (UUID: GPU-b7993cf0-88bc-732c-4f8a-12f4234a7cf9)
  MIG 3g.40gb     Device  0: (UUID: MIG-42753a49-5c48-5303-b7fa-1b474afcfe6a)
  MIG 3g.40gb     Device  1: (UUID: MIG-ae71f6a7-5253-5734-8cbc-5e6ebd157675)

ubuntu@h100-test:~$ nvidia-smi -L
GPU 0: NVIDIA H100 PCIe (UUID: GPU-b7993cf0-88bc-732c-4f8a-12f4234a7cf9)
  MIG 2g.20gb     Device  0: (UUID: MIG-5c355e34-9007-538c-93e8-28d4ceb6d442)
  MIG 2g.20gb     Device  1: (UUID: MIG-457964b3-a935-5f29-bdb7-2699e8ebf53a)
  MIG 2g.20gb     Device  2: (UUID: MIG-003358eb-f6d9-5d95-aa83-313e49258456)

ubuntu@h100-test:~$ nvidia-smi -L
GPU 0: NVIDIA H100 PCIe (UUID: GPU-b7993cf0-88bc-732c-4f8a-12f4234a7cf9)
  MIG 1g.10gb     Device  0: (UUID: MIG-4fb27904-f37d-53eb-a625-6bbc5a2d37fe)
  MIG 1g.10gb     Device  1: (UUID: MIG-9829f3a0-98c5-54a1-8060-8b4f8df7cee4)
  MIG 1g.10gb     Device  2: (UUID: MIG-743a0c03-4b20-5785-8787-35ac6a127f0c)
  MIG 1g.10gb     Device  3: (UUID: MIG-5041ede5-a7ef-5e4b-a22b-65af1b1f6d5e)
  MIG 1g.10gb     Device  4: (UUID: MIG-1d1275b7-1da5-5c1e-aab2-58c6020c595a)
  MIG 1g.10gb     Device  5: (UUID: MIG-75e14770-31e9-5475-9100-7507ebf533ca)
  MIG 1g.10gb     Device  6: (UUID: MIG-59ae9f20-3c64-5e48-b2f2-799246bafeb3)

Сравнение попугаев

Запуск полностью аналогичен запуску из прошлой статьи. В этот раз не нашлись рекомендуемые драйвера *-580, пришлось поставить *-575. Эти метрики снимались с CUDA 12.9.

Никакого оверклокинга не производилось, всё как было "из коробки" как было.

Glop/s как в FP32, так и с использованием тензорных ядер
Glop/s как в FP32, так и с использованием тензорных ядер
Температура карточки на "плато"
Температура карточки на "плато"
Метрики с использованием MIG
Метрики с использованием MIG

Карточка довольно холодная, но это скорее всего свойство низкого TDP, низкой температуры в ДЦ и мощного кулера в сервере (карточка пассивная). Вообще все карточки, что я трогал начиная с поколения Ampere - довольно "холодные".

Интересно сравнить отношение показателя попугаев с тензорными ядрами на 1 рубль в исторической ретроспективе (цены очень примерные на момент появления, понятно, что б/у или new old stock будет дешевле) с момента начала "пузыря". Держим в голове тут, что 5090 памяти чуть недодали, и что она в базе занимает 4 слота. Если сравнивать без тензорных ядер и добавить карточки поколений до "пузыря" … то можно и загрустить. Но у H100 мало обычных CUDA-ядер и она совсем тогда загрустит.

Попугаи на 1 рубль
Попугаи на 1 рубль

Тест на реальном продуктовом инференсе

Тут у нас сначала получилось что-то странное. Мы завели тест из прошлой статьи, надеясь на приключение на 20 минут.

Приключение на 20 минут

Мы поставили самые новые доступные в ppa драйвера, накатили самую последнюю версию всех библиотек, но даже без MIG (чтобы исключить потенциальную "кривизну" нашего кода или эффекты балансировки нагрузки) … карточка показала результаты хуже, чем 5090 и RTX A5000 (мы тестировали разные версии библиотек):

Первый тест - пропускная способность в секундах аудио в секунду
Первый тест - пропускная способность в секундах аудио в секунду

Не может же так быть, чтобы карта за 3000 килорублей была хуже карты за 300 килорублей (а 5090 по нашим тестам получше чем RTX A5000 Ada)? Конечно так быть может и это на языке экономики называется капитализм ценовая дискриминация и сегментация рынка. Игровая карта всегда выгоднее, чем якобы "профессиональная". Поэтому Nvidia лезет из кожи вон, чтобы сделать игровые карты неюзабельными в ML. Но этому была посвящена прошлая статья.

Мем про капитализм

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

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

Мы немного загрустили, что без MIG H100 получается медленнее на этом тесте, чем A5000 Ada (и как следствие 5090). А потом обратили внимание, что при тесте на полной карте она загружена на 30-50%. А карты типа 5090 или A5000 Ada - близко к 100%. Повод задуматься. А потом мы обнаружили … что наш код для отправки тестовых запросов, когда мы поднимаем N инстансов модели с MIG … посылает запросы последовательно. Не беда. Создаём на N MIG-кусочков N процессов с запросами и шлём:

Второй тест - теперь поднимаем N воркеров с запросами на N кусочков MIG
Второй тест - теперь поднимаем N воркеров с запросами на N кусочков MIG

Так, получается, что среднее время ответа почти не меняется, если мы создаём 1, 2 или 3 MIG-подкарты! Изменения начинаются уже на 7 "кусочках". Хм, но это же означает, что если мы посмотрим на пропускную способность, то … Эврика!

Правильно посчитанная пропускная способность
Правильно посчитанная пропускная способность

Получается, что без разбивки на "кусочки", карта имеет более низкую пропускную способность. Но если разбить на максимальное их количество - пропускная способность увеличивается почти до 80 секунд аудио в секунду по сравнению с 35 у Ada A5000 (это средние по всему тесту, на длинных аудио скорость генерации выше примерно в 2 раза).

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

Благодарность

Выражаем благодарность сервису Immers Cloud за возможность протестировать карточку.

Комментарии (5)


  1. NKulikov
    09.09.2025 16:16

    Мой надмозг тут выделяет самые важные ограничения:

    • Графические АПИ недоступны;

    Это потому, что вы читаете про:

    1.) C-profiles. В них по определению нет графических API. Графические API есть в W/Q/etc профилях, которые входят в vGPU и покрываются MIG-Backed vGPU https://docs.nvidia.com/vgpu/19.0/grid-vgpu-user-guide/index.html#changing-vgpu-scheduling-policy И/ИЛИ

    2.) В H100/H200/B200/B300 вообще нет графики толком, поэтому графические API для них не актуальны. За графикой это к L40/L40S/RTX PRO 6000 Blackwell Server Edition. И вот как раз RTX Pro 6000 BSE (в отличии от L40) поддерживает, и MIG, и графические API через vGPU.

    • Тренировать нейросети с поддержкой GPU to GPU P2P (PCIe или NVLink) не получится;

    • В рамках одного CUDA-процесса возможно только указать одно MIG-устройство;

    • Нельзя мешать MIG-подустройство и просто обычную карточку в рамках CUDA-процесса;

    ИМХО, написанное выше - логично. Зачем вам multi-GPU, если вы еще не выросли из одной карты? Там правило другое - сначала вы растете по профилям, доходите до полной карты, потом переходите на Multi-GPU (Scale-Up) в рамках одной ноды (до 8 карт на сервер), затем на Multi-Node (Scale-Out), если в одну ноду уже не влезаете.

     Если сравнивать без тензорных ядер и добавить карточки поколений до "пузыря" … то можно и загрустить. Но у H100 мало обычных CUDA-ядер и она совсем тогда загрустит.

    Это странное сравнение, потому что вы принципиально не учитываете то, для чего эта карта нужна. H100/H200/B200/B300 - карты как раз для тензорных ядер, супербыстрой памяти (HBM vs GDDR) и NVLINK (для Multi-GPU). Ну и разрядность здесь не маловажна - L40S быстрее H100 в FP32 (92 vs 67 TFLOP), медленнее в FP16 (733 vs 1979 TFLOPS), а в FP64 так вообще L40/RTX Pro/GeForce не могут (точнее технически могут, но там вообще нет производительности).

    Для примера B300

    Не может же так быть, чтобы карта за 3000 килорублей была хуже карты за 300 килорублей (а 5090 по нашим тестам получше чем RTX A5000 Ada)?

    А вы попробуйте, например, запустить тренинг/fine-tune. Можно еще с моделью, которая не влезает в 20GB VRAM. Можно еще сделать TP на 8 карт в одном NVLINK домене с TP8 и FP16. Тогда сразу станет видна разница.

    Получается, что без разбивки на "кусочки", карта имеет более низкую пропускную способность. 

    Это очевидно, какой-то косяк с настройкой, конфигурацией или самим тестом. Большинство H100/H200 работают без MIG на полной скорости. Вот примеры тестов и результатов - https://mlcommons.org/benchmarks/inference-datacenter/ (Тут есть и H100, и RXT 4090, и RTX Pro 6000 BSE (ближайший аналог RTX 5090 c т.з. compute). Вопрос почему у вас система шлет запросы последовательно и не может утилизировать одну карту - хз.


    1. snakers4 Автор
      09.09.2025 16:16

      А вы попробуйте, например, запустить тренинг/fine-tune. Можно еще с моделью, которая не влезает в 20GB VRAM. Можно еще сделать TP на 8 карт в одном NVLINK домене с TP8 и FP16. Тогда сразу станет видна разница.

      Разница будет как минимум в 10 раз?

      Зачем вам multi-GPU, если вы еще не выросли из одной карты?

      Тут вопрос не в том, выросли мы на инференсе или не выросли. А в том, можно ли получить из этой карты хоть что-то, что хоть как-то коррелирует с её ценником. Один из "извращенных" способов это сделать - рассматривать её как N карт.

      А вы попробуйте, например, запустить тренинг/fine-tune. Можно еще с моделью, которая не влезает в 20GB VRAM.

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

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

      На рынке есть 2-х слотовые 5090 от умельцев с нормальным охладом и большой памятью по цене около игровых. Но насколько это надежно - вопрос отдельный, может кто-то тыкал такие франкенштейны)

      Вопрос почему у вас система шлет запросы последовательно и не может утилизировать одну карту - хз.

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


      1. igor_suhorukov
        09.09.2025 16:16

        На рынке есть 2-х слотовые 5090 от умельцев с нормальным охладом и большой памятью по цене около игровых.

        Уже начали перепаивать чипы памяти, как было для RTX4090 с 48Гб? У этих 64 Гб?


        1. snakers4 Автор
          09.09.2025 16:16

          Сам в руках не держал, видел объявления на площадке б/у товаров, проверкой не занимался


  1. bolk
    09.09.2025 16:16

    …но я не думал, что в России в принципе появятся H100…

    Ну вы даёте. Их довольно много и даже B200 встречаются.