Почему GPU выбирается последним, и H100 подходит далеко не всегда

Когда клиент написал с запросом на H100, задача звучала стандартно: локальный сервер под LLM на 30 миллиардов параметров, постоянная нагрузка в продуктиве, данные нельзя выносить в облако. H100 в таких проектах встречается часто, и на первый взгляд выбор казался очевидным.

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

H100, A100 и H200 в типовых конфигурациях – пассивно охлаждаемые карты, рассчитанные на работу внутри серверной стойки с организованным воздушным трактом. Шасси гонит воздух через карту в заданном направлении с нужным давлением. Убрать карту из этой среды и поставить в обычный офисный корпус значит оставить ее без нормального теплоотвода.

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

Условия эксплуатации сделали H100, A100 и H200 нерабочим вариантом для этого проекта до любого разговора о спецификациях.

Модель класса Qwen 30B в формате BF16 требует порядка 65 GB видеопамяти только на хранение весов. Это фиксированная нагрузка, которая присутствует всегда независимо от входящего запроса. Сверху идет KV-cache – буфер, в котором хранятся промежуточные вычисления для обработки контекста. Его размер растет пропорционально длине входящего текста и в случае длинных последовательностей становится сопоставим с объемом самой модели.

Клиенту был нужен контекст до миллиона токенов. При таких параметрах KV-cache в BF16 добавляет значительный объем сверху весов модели. Сумма выходит за пределы любой одиночной карты в разумном бюджете. Переход на FP8 снижает вес модели примерно вдвое, до 30 с небольшим GB, но KV-cache при миллионе токенов все равно требует сопоставимый объем. Расчет устойчиво указывал на минимум 96 GB видеопамяти в едином пуле.

RTX A6000 – 48 GB на борту и поддержка NVLink Bridge. Две карты с мостом объединяются в единый пул 96 GB: операционная система и фреймворк видят его как одно устройство, веса модели и KV-cache размещаются в нем непрерывно без разбивки на части.

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

Клиент спрашивал про RTX 6000 Ada – она новее и по ряду задач быстрее. Проблема в том, что в Ada поколении NVIDIA убрала поддержку NVLink Bridge для профессионального сегмента. Мост сохранился только в картах серий A/H/B, которые стоят кратно дороже и возвращали к вопросу бюджета. RTX A6000 оказалась последним поколением с нужным мостом в диапазоне, который укладывался в проект.

Важно понимать, что NVLink Bridge – физический мост, который устанавливается между двумя картами в слотах. Для работы нужна материнская плата с правильным расположением слотов и достаточным расстоянием между ними. Это один из технических параметров, который нужно проверять при выборе платформы под такую сборку, а не только сами карты.

Три RTX A6000 48GB в корпусе Full Tower с активным охлаждением. Full Tower с хорошей вентиляцией решал именно ту задачу, которую не могли решить пассивные серверные карты: обеспечивал нужный теплоотвод без серверной стойки. Две карты через NVLink образуют пул 96 GB под основную LLM, запускается в FP8 через vLLM. Третья карта работает отдельно под Gemma 27B, BERT и ResNet в изолированной виртуальной машине с проброской GPU. Процессор AMD EPYC 9354P на 32 ядра, 256-512 GB DDR5, два NVMe по 3.84 TB. Уложились в бюджет до 4 млн рублей.

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

Если бы бюджет был выше, логично смотреть на RTX PRO 6000 Blackwell 96GB: 96 GB на одной карте, более современная архитектура, без компромиссов с объединением через мост. Но это другой ценовой диапазон, в данном проекте он не рассматривался.

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

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