Привет! Меня зовут Андрей Пелешок, я инженер L3 команды PaaS в Cloud.ru. Я отвечаю за работу платформенных сервисов и за поддержку инфраструктуры.

Вы, скорее всего, сталкивались с вопросом: «Какую видеокарту выбрать для Inference, чтобы обеспечить баланс между производительностью, стоимостью и доступностью?» Проблема выбора осложняется тем, что многие материалы сосредоточены на обучении (Training), а для Inference требования отличаются.

В статье попробуем разобраться, в чем разница между Training и Inference и ключевых критериях выбора GPU. Еще я приведу сравнительный анализ решений (H100, A100, V100) и предложу методику выбора на основе реальных кейсов.

План

1. Ключевые факторы при выборе GPU для обучения (Training)

2. Какие требования есть к видеокартам для Inference

3. Какие видеокарты мы будем тестировать

4. Какие бенчмарки мы использовали для сравнения

5. Задача: подбор GPU для AI-ассистента поддержки

6. Задача: выбор конфигурации для анализа больших объемов текстовых данных

7. Заключение

Ключевые факторы при выборе GPU для обучения (Training)

Память (VRAM) 

Чем сложнее модель и чем больше данных вы обрабатываете за один раз, тем больше видеопамяти вам потребуется. Если ее не хватит, придется либо уменьшать размер пакета данных, либо упрощать саму модель, что напрямую скажется на скорости и качестве обучения. Именно поэтому для работы с гигантскими моделями так популярны GPU вроде NVIDIA A100 с их 40 или 80 ГБ памяти. Например, для настройки модели с 65 миллиардами параметров карта A100 на 80 ГБ — это практически необходимость.

Вычислительная мощность (FLOPS и Tensor Cores) 

Процесс обучения модели — это, по сути, бесконечные матричные умножения. Современные видеокарты оснащены специальными тензорными ядрами, которые ускоряют эти вычисления в форматах FP16 и BF16, что сокращает время обучения. Мощность A100 составляет 312 TFLOPS, что делает ее настоящим зверем. H100 идет еще дальше, добавляя поддержку формата FP8 для еще большей скорости.

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

Масштабирование на несколько GPU 

Для действительно больших проектов одного GPU может быть мало. Некоторые карты, такие как A100, имеют специальные высокоскоростные межсоединения (NVLink, Infiniband), которые позволяют им эффективно работать вместе, объединяя память и ресурсы.

Если планируете использовать несколько карт, важно убедиться, что ваша инфраструктура это поддерживает. A100 изначально заточен под такие кластеры. Для экстремально крупных задач важна также сетевая инфраструктура между серверами, но большинству проектов это не требуется.

Точность (Precision Support)

Для ускорения обучения и экономии памяти сегодня повсеместно используются пониженные точности вычислений, такие как FP16 или BF16. Возможности карт в этом плане различаются: старые GPU не имели аппаратного ускорения для FP16, тогда как все современные карты NVIDIA эффективно с ними работают. H100 вообще представляет поддержку FP8. Важно выбирать GPU, который наилучшим образом поддерживает те форматы, что использует ваш фреймворк.

Какие требования есть к видеокартам для Inference

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

Задержка (Latency) 

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

Чтобы этого добиться, важны два момента: высокая тактовая частота чипа и оптимизация. Например, если модель уже заранее загружена в память GPU (закеширована), а не подгружается частями, это сильно ускоряет отклик.

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

Batch

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

Память (для размера модели)

Какую бы модель вы ни запускали, ее сначала нужно целиком загрузить в память GPU. Это главное ограничение. Огромная модель на 20 миллиардов параметров просто не влезет в карту с малым объемом VRAM, и тут вам уже может понадобиться монстр вроде A100 на 80 ГБ. Однако с помощью таких техник, как квантование (снижение разрядности чисел), можно сильно «похудевшую» модель запустить на гораздо более скромном железе. Яркий пример: 7-миллиардная модель, которую после сжатия до 4 бит успешно запускают на обычной игровой карте с 8 ГБ памяти, что было бы невозможно в 16 бит.

Пропускная способность

Когда к вашему сервису приходят тысячи пользователей, на первый план выходит «пропускная способность» — сколько запросов в секунду может обработать система. И тут оказывается, что не всегда самая навороченная и дорогая карта будет самым умным выбором. Часто карты уровня NVIDIA L4 или даже игровая RTX 4090 оказываются выгоднее по соотношению производительность / цена. Они выдают огромное количество операций инференса за каждый вложенный рубль.

Какие видеокарты мы будем тестировать

В таблице представлены полные технические характеристики доступных видеокарт NVIDIA. Я провел тесты на каждой из них.

* — значения с учетом sparsity, без sparsity — вдвое ниже.

Какие бенчмарки мы использовали для сравнения

Во время тестирования будем использовать утилиту от Hugging Face — inference-benchmarker. Ключевые особенности инструмента:

• Профили тестирования: заранее настроенные сценарии для разных задач, таких как:

  • Сhat (чат) — имитирует сценарий многошагового чата, в котором модель отвечает на последовательные запросы пользователя. На каждом шаге модель получает всю историю диалога. Кеширование префиксов существенно повлияет на производительность этого теста.

  • Сode-generation — имитирует написание кода, модели передается большой кусок кода с просьбой завершить его несколькими строчками кода.

  • Сlassification — имитирует сценарии, в которых модель многократно обрабатывает большие объемы бизнес-данных или документов, а пользователи задают простые вопросы об их содержании (суммирование, классификация и т. д.).

  • Fixed-length — модели подаются промпты фиксированной длины, чтобы исключить влияние токенизации переменной длины на тестирование. Это технический бенчмарк для оценки чистой производительности модели.

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

• Режимы нагрузки: инструмент поддерживает несколько режимов создания нагрузки для разных целей:

  • Sweep (по умолчанию): автоматически находит максимальную пропускную способность и проводит серию тестов.

  • Rate: тестирование при фиксированной частоте запросов.

  • Throughput: тестирование при фиксированной пропускной способности.

• Гибкая настройка запросов: вы можете точно настраивать параметры входных запросов (prompts) и генерации (decoding), задавая среднее количество токенов, разброс и другие опции.

• Можно указывать свой датасет.

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

Задача: подбор GPU для AI-ассистента поддержки

Ситуация первая: внедрение AI-ассистента для автоматизации обработки обращений в службу поддержки интернет-магазина. Модель необходима для анализа входящих запросов от клиентов, их моментальной категоризации и генерации качественных, персонализированных ответов. Это позволит в автоматическом режиме решать до 70% типовых вопросов (о статусе заказа, наличии товара, условиях возврата), значительно сократив нагрузку на живых операторов и повысив скорость реакции на обращения. Была выбрана модель Qwen3-8B. Система должна обслуживать до 30 одновременных чат-сессий, где пользователи отправляют сообщения с интервалом 20-60 секунд. Средняя длина диалога: 5-10 сообщений.

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

Пример команды тестирования:

inference-benchmarker \
    --tokenizer-name Qwen/Qwen3-8B \
    --model-name model-run-cxk9b-just \
    --api-key $API_KEY \
    --url https://29534ffe-c91a-420f-8e54-944a9637bb15.modelrun.inference.cloud.ru/v1 \
    --profile chat  

Доступен выбор из трех видеокарт какую же выбрать.

A100 полностью покрывает технические требования и дает запас производительности.

Наша пиковая нагрузка — 1.5 RPS. A100 обеспечивает 2.85 RPS. Это означает, что система будет стабильно работать даже в часы наибольшей активности без очередей и задержек. V100 (1.1 RPS) уже в пике не справится, что приведет к росту времени ожидания ответа для пользователей и потенциальным сбоям.

A100 обеспечивает наилучшее соотношение цены и производительности.

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

Качество пользовательского опыта.

Задержка до первого токена в 50 мс (A100) против 500 мс (V100) — это принципиальная разница. Пользователь в чате не будет видеть долгую «печать...» в ответе, система будет ощущаться как живой оператор.

Вывод

V100: Карта морально устарела для задач инференса современных LLM под нагрузкой. Не справляется с пиковой нагрузкой, имеет неприемлемо высокую задержку и самую низкую эффективность.

A100: Идеальный баланс. Мощности хватает с запасом, задержки низкие, стоимость самая привлекательная, а эффективность (производительность за рубль) — наивысшая.

H100: мощное и дорогое решение для наших задач. Его потенциал будет использован на 10– 20%. Как показывает метрика «производительность за рубль», мы переплатим за производительность, которая нам не нужна. Его стоит рассматривать для гораздо более крупных систем. Не рекомендуется для текущих требований.

Рассмотрим другой случай, когда требования немного иные.

Задача: выбор конфигурации для анализа больших объемов текстовых данных

Итак, задача вторая: ежедневный анализ потока новостей и пресс-релизов компаний в определенном секторе для выявления ключевых трендов и инвест-поводов. Входящие данные 3000-6000 токенов с небольшим суммирующим выводом в 80 токенов, модель Qwen3-30B-A3B.

Пример команды тестирования:

inference-benchmarker \
  --tokenizer-name “Qwen/Qwen3-30B-A3B" \
  --url https://089ad6d3-2d17-44f8-9838-879a6fb29530.modelrun.inference.cloud.ru/v1 \
  --api-key $API_KEY \
  --model-name model-run-1keln-ship \
  --benchmark-kind sweep \
  --prompt-options "num_tokens=4096,min_tokens=3000,max_tokens=6000,variance=1000" \
  --decode-options "num_tokens=50,min_tokens=30,max_tokens=80,variance=10"  

Если смотреть на голые цифры, то H100 — это монстр: она почти в 2.7 раза быстрее генерирует токены и в 2.6 раза шустрее обрабатывает промпты. Задержка стабильно ниже. Выбор очевиден. Но когда мы добавляем в уравнение стоимость, картина кардинально меняется.

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

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

Для работы с непостоянной нагрузкой оптимальным решением становится serverless-режим с автоматическим отключением инстансов в периоды простоя (например, ночью), что позволяет значительно сократить расходы. 

Вывод

Стартовый выбор для 80% случаев — A100. Он надежен, эффективен по деньгам и отлично подходит под описание нашего кейса. Разница в латентности не является критичной для анализа новостного потока.

Стратегию выключения инстанса — пробуем обязательно. Это не просто можно, а нужно делать при непостоянной нагрузке. Это снизит стоимость в разы. Представьте: если вы работаете только 12 часов в день, вы уже экономите 50%. А если ночью всего пара запросов — можно и подождать, пока инстанс «проснется».

H100 — оставляем для будущего. Он нам понадобится только в двух случаях: если бизнес потребует радикально ускорить анализ («чтобы быстрее всех на рынке реагировать!») или если наш поток новостей вырастет в разы и нам понадобится максимальная производительность на один сервер.

Заключение

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

Как показал наш анализ, ключевые выводы следующие:

• Приоритеты смещаются: для инференса на первый план выходят задержка (latency) и пропускная способность (throughput), а не только объем памяти или пиковая вычислительная мощность.

• Контекст решает все: мощнейшая H100 будет экономически нецелесообразна для обработки одиночных запросов. И наоборот, для больших моделей и пакетной обработки без A100 или H100 не обойтись.

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

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

Делитесь в комментариях, на что смотрели выбирая GPU для своих проектов и что любите использовать для бенчмаркинга?