Выбор GPU-карты для инференса: сравнение H100, A100 и V100

При выборе GPU для инференса важно смотреть не на пиковые терафлопсы, а на три вещи: сколько запросов карта обработает с заданной задержкой, сколько памяти займет модель вместе с KV-кэшем и как инфраструктура поведет себя при росте трафика.

Разберем, чем отличаются NVIDIA H100, NVIDIA A100 и NVIDIA V100 в работе с инференсом, какие модели на них имеет смысл запускать и когда дорогая карта оказывается выгоднее дешевой.

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

Все три карты — серверные ускорители: их не ставят в настольный компьютер, а арендуют или размещают в дата-центре. Проверить сценарий на арендованном оборудовании можно в облачных серверах с GPU Servercore — дата-центры находятся в Алматы и Ташкенте.

Чем инференс отличается от обучения моделей

При обучении (Training) система многократно прогоняет набор данных через модель, обновляет веса и ищет их распределение, дающее наилучший результат. Здесь важны общий объем вычислений, скорость обмена данными между несколькими GPU и устойчивость к длительной нагрузке.

При инференсе веса уже зафиксированы. Сервис получает запрос, формирует ответ и возвращает его пользователю или внешнему приложению. Критерии оценки другие:

• время до первого токена — TTFT, или first latency;
• скорость дальнейшей генерации — количество токенов в секунду, throughput;
• межтокенная задержка — интервал между соседними токенами в потоке;
• число одновременных запросов;
• рост TTFT при длинном промпте: обработка входа масштабируется вместе с его длиной;
• объем видеопамяти под веса, KV-кэш и служебные данные;
• стоимость миллиона сгенерированных токенов или одного обработанного запроса.

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

Механика инференса объясняет, почему для него так важна память. Веса загружаются в видеопамять один раз и остаются там на все время работы сервиса. Но на каждом шаге генерации эти веса нужно прочитать из видеопамяти в вычислительные блоки GPU, и этот путь повторяется для каждого нового токена. Модель на 70 млрд параметров в BF16 занимает около 140 ГБ, которые проходят через шину памяти на каждом токене.

Отсюда простая оценка потолка: разделите пропускную способность памяти на размер модели. Для 140-гигабайтной модели на карте с 3,35 ТБ/с получается порядка 24 токенов в секунду — предел, выше которого одиночный поток не поднимется независимо от количества вычислительных ядер.

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

Внутри инференса сценарии тоже различаются. Диалоговому ассистенту критична низкая TTFT: пользователь не должен ждать несколько секунд до начала ответа. Пакетной обработке документов высокая задержка не мешает, но важна пропускная способность. Ключевой фактор выбора GPU — это не «какая карта быстрее», а «что конкретно требуется от видеокарты в моем сценарии».

Какие требования предъявляют современные AI-модели к GPU

Разные классы моделей нагружают ускоритель по-разному. Задачи Machine Learning на табличных данных, Deep Learning в компьютерном зрении и Generative AI предъявляют к железу почти противоположные требования, и выбирать карту «вообще для ИИ» бессмысленно.

LLM, RAG и AI Agent

LLM (Large Language Model) — ChatGPT, Llama, DeepSeek и другие — требуют максимального объема VRAM и высокой пропускной способности памяти. Во время генерации модель читает веса и накапливает KV-кэш. Чем больше одновременных диалогов, длиннее контекст и выше максимальное число токенов в ответе, тем быстрее растет потребление памяти.

RAG-система добавляет поиск по базе знаний, обработку документов и передачу найденного контекста в модель. Сам поиск может работать на CPU или отдельной GPU, но генератору нужен большой контекст. Если не ограничить размер извлекаемых фрагментов, сервис начнет загружать память KV-кэшем вместо обслуживания новых пользователей.

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

Генерация изображений

Stable Diffusion, Flux и подобные модели создают другую нагрузку. Им нужны вычислительные ресурсы ядер и видеопамять под саму модель, latent-представления и исходное изображение. Одиночная картинка в стандартном разрешении помещается в скромный объем VRAM — память становится ограничением при высоком разрешении, больших батчах, нескольких моделях в пайплайне, ControlNet и генерации видео.

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

Computer Vision и NLP

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

Классические задачи NLP — классификация обращений, извлечение сущностей, поиск по смыслу — работают на моделях меньшего размера. Им редко нужны 80 ГБ VRAM, зато важна возможность держать на одном ускорителе несколько моделей сразу: энкодер, реранкер и генератор.

NVIDIA H100, A100 и V100: обзор и характеристики

Ниже сравнение распространенных серверных SXM-модификаций. Версии PCIe отличаются по TDP, пропускной способности памяти и возможностям NVLink, поэтому переносить показатели SXM-карты на PCIe-конфигурацию нельзя.

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

Обратите внимание на строку с тензорными ядрами: у V100 их 640, то есть больше, чем у A100. При этом A100 быстрее в 2,5 раза. Считать ядра между поколениями бессмысленно — сравнивать нужно производительность в конкретном формате данных.

NVIDIA H100 — для высокой плотности запросов

H100 построена на архитектуре Hopper. Ее сильная сторона — сочетание памяти HBM3, пропускной способности 3,35 ТБ/с и технологии Transformer Engine с поддержкой FP8.

Формат FP8 вдвое компактнее FP16: он сокращает объем передаваемых данных и позволяет разместить в памяти больше полезного. Для крупных трансформерных моделей это напрямую снижает стоимость обработки токена. H100 оправдана для высоконагруженного API, длинных контекстов, больших моделей и сценариев с жестким требованием к задержке.

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

NVIDIA A100: почему ее до сих пор называют Tesla A100

В поиске часто встречается вариант «Tesla A100 NVIDIA» или «Tesla NVIDIA A100». Приставку Tesla компания использовала для серверных ускорителей до поколения Volta и отказалась от нее как раз перед выходом Ampere — название закрепилось по инерции. Официально карта называется NVIDIA A100 Tensor Core GPU.

A100 остается рабочим решением для большинства сценариев инференса: LLM среднего и крупного размера, генерация изображений, RAG, API с умеренной нагрузкой. Поддержка MIG позволяет разделить одну физическую карту на семь изолированных экземпляров — это удобно, когда несколько команд запускают небольшие сервисы и не загружают ускоритель целиком.

Отдельно стоит учитывать, что производство A100 прекращено в начале 2024 года. Купить новую карту сложно, поэтому основной способ получить эту производительность — аренда.

NVIDIA V100 — легаси для нетребовательных задач

V100 подойдет для старых ML-пайплайнов, небольших моделей, экспериментов и инфраструктуры, которая уже закуплена. Карта создавалась в 2017 году, когда моделей с длинным контекстом попросту не существовало, поэтому под современные сценарии она рассчитана плохо.

Ограничения существенные: 32 ГБ памяти, втрое меньшая пропускная способность, отсутствие MIG, FP8, BF16 и TF32. Последнее означает, что часть современных оптимизаций обучения и инференса на V100 просто не запустится.

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

GPU A100 и H100: в чем практическая разница для инференса

Разрыв между поколениями складывается из трех составляющих, и они работают в разных частях сценария.

• Пропускная способность памяти — 3,35 против 2,04 ТБ/с, прирост около 64%. Это транслируется в скорость декодирования почти напрямую, потому что генерация каждого токена упирается в чтение весов.
• Вычислительная производительность — 990 против 312 TFLOPS в BF16, разрыв более чем трехкратный. Он проявляется при обработке входного промпта, на длинных контекстах и при больших батчах.
• Поддержка FP8 — у A100 ее нет вовсе. На моделях, подготовленных к этому формату, разрыв увеличивается еще сильнее, но требует совместимого движка и проверки качества после квантизации.

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

Как размер модели определяет выбор GPU

Первый шаг — оценить память под веса:

• BF16 и FP16 — 2 байт на параметр;
• FP8 и INT8 — 1 байт;
• INT4 — 0,5 байта.

А вот файл модели всегда получается больше этого расчета. Квантизация хранит рядом с весами масштабирующие коэффициенты и метаданные, а часть слоев — эмбеддинги, нормализацию, иногда выходную проекцию — обычно оставляют в более высокой точности. Поэтому модель с маркировкой «4 бита» на практике занимает ближе к 4,5–5 битам на параметр, и умножение числа параметров на 0,5 байта дает заниженный результат.

Это только веса. Дополнительно нужна память под KV-кэш, рантайм и временные тензоры. Расчет вида «70 млрд параметров × 0,5 байта = 35 ГБ» дает нижнюю границу, а не требование к карте: при длинном контексте и нескольких одновременных запросах реальное потребление окажется в полтора-два раза выше.

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

Производительность в популярных моделях

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

Llama 3: Версия на 8B комфортно работает на одной A100 с большим запасом под контекст и параллельные сессии, и на H100 разрыв будет умеренным. Версия на 70B в BF16 требует нескольких карт, в 4-битной квантизации помещается на одну 80-гигабайтную. Именно на 70B преимущество H100 становится наглядным: модель полностью упирается в память.

DeepSeek: Семейство включает и небольшие distilled-версии на 7–8B, и крупные MoE-модели V3 и R1. Distilled-варианты по требованиям близки к Llama 3 8B. Полноразмерные MoE держат в памяти все веса, хотя активируют лишь часть, поэтому для них нужен многокарточный узел.

Mistral и Mixtral: Mistral 7B — одна из самых нетребовательных моделей своего класса, она запускается даже на V100 при разумном контексте. Mixtral 8x7B — MoE-архитектура с суммарным объемом весов на уровне модели около 47B, поэтому по требованиям к памяти он ближе к классу 30–70B, чем к 7B.

Qwen и Gemma: Обе линейки дают широкий диапазон размеров — от компактных моделей на 1,5–4B до Qwen 72B. Для небольших вариантов ключевым становится не объем памяти, а возможность обслуживать много параллельных запросов. Здесь пригождается MIG: одна A100 или H100 делится между несколькими сервисами.

Stable Diffusion и Flux: Генерация изображений зависит от вычислительной производительности сильнее, чем от пропускной способности, поэтому разрыв между поколениями ближе к разнице в терафлопсах. Flux заметно тяжелее классических версий Stable Diffusion и на V100 может не запуститься в полной точности.

Как правильно тестировать GPU для инференса

Чтобы тест можно было воспроизвести и сравнить с другой конфигурацией, в отчете нужно зафиксировать параметры запуска. Минимальный набор:

• model_name и ревизия модели;
• формат весов: BF16, FP8, INT8 или INT4;
• tokenizer и версия inference-движка;
• длина входного контекста, min_tokens и max_tokens в ответе;
• число одновременных запросов;
• TTFT, скорость декодирования и суммарная пропускная способность;
• конфигурация GPU: модель, объем памяти, подключение PCIe или SXM;
• версии CUDA и драйвера.

Если модель работает не локально, а через внешний сервис, добавьте в отчет провайдера и регион: результат через API key стороннего сервиса зависит от его загрузки и не характеризует вашу карту.

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

Выбор GPU для прикладных задач

Чат-боты и AI-ассистенты. Для внутреннего ассистента с моделью до 14B достаточно A100: она дает запас памяти под контекст и обслуживает несколько десятков пользователей. H100 нужна, когда запросов много, а ожидание первого токена должно быть минимальным. Для ассистента, который заменяет живого оператора в поддержке, требования к задержке жестче, чем для справочного бота.

AI-поиск и RAG. Основной риск здесь не размер модели, а неконтролируемый контекст. Ограничьте размер извлекаемых фрагментов, настройте реранкинг и тестируйте систему на реальных документах. Иначе даже мощная карта будет тратить память на текст, который не влияет на качество ответа.

API с большим числом запросов. Для публичного API важна не максимальная скорость одного ответа, а способность стабильно обрабатывать очередь. H100 здесь часто выигрывает по стоимости результата: один дорогой ускоритель заменяет несколько более медленных, упрощает масштабирование и снижает операционные расходы. Но вывод нужно подтверждать замером — сначала определите целевой SLA, затем измерьте стоимость миллиона токенов.

Генерация изображений и Computer Vision. Начните с расчета нагрузки: разрешение, размер батча, число операций в секунду, допустимая задержка. Для умеренного потока A100 — рациональная база. H100 выбирают, когда нужно значительно сокращать время обработки, обслуживать много параллельных задач или держать в памяти несколько тяжелых моделей.

Сравнение стоимости инференса

Стоимость часа и стоимость результата

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

Стоимость 1 млн выходных токенов = цена часа GPU / (выходных токенов в секунду × 3600) × 1 000 000

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

Формула упрощенная: в полный расчет стоит добавить входные токены, длину контекста и реальную конкуренцию запросов. Но даже в таком виде она полезнее сравнения прайс-листов.

Производительность на доллар

Здесь работает правило, которое ломает интуицию: чем выше утилизация, тем выгоднее дорогая карта. Ускоритель, загруженный на 15%, обходится за полезный GPU-час дороже, чем более дешевый с загрузкой 80%.

Поэтому одна и та же пара карт может дать противоположный ответ в разных проектах. Для круглосуточного API с очередью запросов H100 обычно дешевле в пересчете на токен. Для сервиса с редкими обращениями выгоднее A100 или даже меньший ускоритель с возможностью остановки.

Энергоэффективность

H100 SXM потребляет до 700 Вт против 400 Вт у A100 и 300 Вт у V100. В пересчете на выполненную работу более новая карта эффективнее: она потребляет вдвое больше энергии, но считает втрое быстрее.

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

Как развернуть инференс в облаке

Облачный GPU против собственного сервера

Аренда в облаке (GPU Cloud) рациональна, когда нужно быстро проверить гипотезу, запустить сервис без закупки серверов или масштабировать нагрузку по мере роста. Собственное оборудование выигрывает при ровной круглосуточной загрузке, строгих требованиях к локальности данных и наличии команды эксплуатации.

Базовый порядок развертывания:

1. Выберите модель, формат весов и inference-движок.
2. Проведите анализ конфигурации: объем памяти, контекст, число пользователей, целевой SLA.
3. Запустите нагрузочный тест на одной GPU.
4. Определите порог, при котором понадобится второй экземпляр сервиса.
5. Настройте мониторинг TTFT, пропускной способности, использования VRAM, ошибок и длины очереди.
6. При необходимости подключите Kubernetes и автоматическое масштабирование.

Kubernetes и автоматическое масштабирование

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

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

Inference на GPU Servercore

Какие GPU доступны

В облачных серверах с GPU Servercore доступны NVIDIA RTX A5000 и NVIDIA RTX PRO 6000 — карта для умеренных нагрузок и старшая модель с большим объемом видеопамяти для крупных моделей. Ускорители подключаются к виртуальной машине как выделенные PCI-устройства, поэтому приложению доступны все их ресурсы.

Дата-центры расположены в Алматы и Ташкенте. Размещение соответствует локальным требованиям к хранению данных: закону № 94-V в Казахстане и ЗРУ-547-сон в Узбекистане, а также стандартам ISO 27001, PCI DSS и GDPR.

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

Для каких задач подойдет H100

H100 имеет смысл рассматривать, когда совпадает несколько условий: высокая конкуренция запросов, длинный контекст, крупная модель и жесткое требование по задержке. Типичные сценарии — публичный API с постоянной очередью, ассистент с большой пользовательской базой, обработка потока документов с высокими требованиями к скорости.

Если утилизация ускорителя будет невысокой, разница в цене не окупится: карта проведет большую часть времени в простое.

Когда выбрать A100

A100 рациональна для умеренной и средней нагрузки: внутренние ассистенты, RAG-системы, модели до 70B в квантизованном виде, генерация изображений с предсказуемым потоком задач. Поддержка MIG позволяет разделить карту между командами, если каждая из них не загружает ускоритель целиком.

Это разумный выбор и на этапе, когда профиль нагрузки еще неизвестен: A100 закрывает большинство сценариев, а перейти на H100 можно после того, как замеры покажут упор в производительность.

Как быстро развернуть AI-сервис

Развертывание сервера занимает от двух минут. При создании виртуальной машины доступен образ DSVM (Data Science Virtual Machine) с предустановленными CUDA, PyTorch, TensorFlow, Keras и JupyterLab — можно приступить к тестам без настройки окружения. Для продакшена подойдут кластеры Managed Kubernetes с GPU.

Полезная деталь для проектов с неравномерной нагрузкой — заморозка ресурсов. Во время отладки, подготовки данных и перестройки пайплайна сервер работает, а GPU простаивает. Заморозка возвращает vCPU, RAM и GPU в пул и прекращает их тарификацию: оплачиваются только диски и IP-адреса. Функция доступна для серверов с сетевым загрузочным диском.

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

Что лучше для инференса — H100 или A100?

Технически H100 быстрее почти в любых задачах: выше пропускная способность памяти, втрое выше производительность в BF16, есть поддержка FP8. Экономически она оправдана при высокой конкуренции запросов, длинном контексте, крупных моделях и жестком SLA по задержке. A100 рациональнее для умеренной нагрузки, моделей среднего размера и случаев, когда разница в цене не окупается утилизацией.

Сколько VRAM нужно для 70B-модели?

В BF16 — более 140 ГБ только под веса, то есть минимум две 80-гигабайтные карты. В 4-битной квантизации ориентируйтесь на 40–48 ГБ с учетом служебной памяти, а для продакшена закладывайте запас: реальное потребление зависит от длины контекста и числа одновременных запросов.

Можно ли запускать LLM на одной GPU?

Да, если веса вместе с KV-кэшем помещаются в видеопамять. Модели до 14B комфортно работают на одной A100 или H100. Модель на 70B в BF16 на одну карту не поместится, в квантизованном виде — возможно на 80 ГБ с ограничениями по контексту и числу пользователей.

Что важнее: Tensor Cores или объем памяти?

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

Стоит ли использовать квантование моделей?

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